마거릿 해밀턴이 남긴 질문: AI가 쓴 코드, 누가 안전을 책임질까

핵심 요약

• 마거릿 해밀턴은 MIT 계측연구소에서 아폴로 비행 소프트웨어 개발팀을 이끌었습니다.
• AI가 작성한 코드도 정상 작동뿐 아니라 오류가 나거나 중단됐을 때의 동작까지 검증해야 합니다.
• 테스트를 통과했다고 해서 테스트 기준까지 올바르다고 볼 수는 없습니다.
• 배포 승인과 장애 대응을 누가 맡을지는 코드를 운영하기 전에 정해야 합니다.

AI에게 기능을 설명하고 코드를 받아보면, 개발에서 가장 어려운 고비를 금세 넘긴 듯합니다. 하지만 서비스가 멈추거나 데이터가 사라지면 코드를 만드는 동안에는 미처 생각하지 못했던 문제를 마주하게 됩니다. 아폴로 비행 소프트웨어 개발을 이끈 마거릿 해밀턴의 작업은 이런 문제를 살펴보는 데 도움이 됩니다.

아폴로의 소프트웨어는 임무를 수행하는 장치였습니다

마거릿 해밀턴은 MIT 계측연구소에서 아폴로 비행 소프트웨어 개발팀을 이끌었습니다. 당시 소프트웨어는 우주선이 임무를 수행하는 데 필요한 구성 요소였습니다. 잘못 작동했을 때 그 여파가 화면 속 오류로 끝나지 않는 환경이었죠.

이런 시스템에서는 원하는 기능을 구현했다고 일이 끝나지 않습니다. 예상과 다른 입력이 들어오거나 여러 작업이 한꺼번에 몰렸을 때 어떻게 동작할지도 정해야 합니다. 어떤 작업을 계속하고 어떤 작업을 미룰지 판단할 기준이 필요합니다. 사람에게 알려야 할 시점도 설계할 때 정해두어야 합니다.

해밀턴의 작업에서 오늘의 개발에 가져오고 싶은 것은 실패를 다루는 설계입니다. 소프트웨어를 만들 때는 제대로 작동하는 상황뿐 아니라 예상에서 벗어났을 때 어떻게 대응할지도 함께 정해야 하기 때문입니다.

아폴로와 쇼핑몰 서비스의 위험 수준은 다릅니다. 그래도 “예상한 조건이 깨지면 어떻게 할 것인가”라는 질문은 양쪽 모두에 필요합니다.

코드가 맞아 보여도 서비스는 실패할 수 있습니다

AI에게 쇼핑몰의 주문 기능을 만들어달라고 했다고 가정해보겠습니다. 상품을 선택하고 주문 버튼을 누르면 주문 내역이 저장됩니다. 시연에서는 다 만든 것처럼 보입니다.

그런데 사용자가 버튼을 누른 직후 연결이 끊기면 어떨까요. 서버에는 주문이 저장됐는데 사용자 화면에는 실패했다고 나올 수 있습니다. 사용자가 다시 누르면 같은 주문이 두 번 만들어질 수도 있죠.

이럴 때 필요한 개념이 멱등성입니다. 같은 요청이 반복돼도 의도한 효과가 중복해서 발생하지 않도록 하는 성질입니다. 예를 들어 주문 요청에 고유한 식별자를 붙이면 이미 처리한 요청인지 확인할 수 있습니다.

AI에게 이런 처리를 구현해달라고 할 수 있습니다. 다만 팀이 먼저 정해야 할 것이 있습니다. 어떤 요청을 같은 주문으로 볼지 기준을 세우고, 언제 재시도를 허용할지 정해야 합니다. 그때 사용자에게 어떤 상태를 보여줄지도 결정해야 합니다.

코드를 얻는 일과 시스템이 어떻게 동작할지 정하는 일은 맞물려 있습니다. 운영 중에 생길 수 있는 상황을 프롬프트에서 빠뜨리면, 그 상황에 필요한 설계도 빠질 수 있습니다.

테스트 통과보다 먼저 확인할 것은 테스트의 기준입니다

“AI가 작성했어도 테스트를 통과하면 괜찮지 않을까요?”

테스트는 반드시 필요합니다. 다만 테스트로 확인하는 것은 정해둔 조건에서 기대한 결과가 나오는지입니다. 기대 결과 자체가 틀렸다면 테스트를 통과해도 문제는 그대로 남습니다.

예를 들어 할인율이 100%를 넘는 쿠폰을 시스템이 받아들여도 되는지부터 정해야 합니다. 코드가 할인 금액을 정확히 계산하더라도, 허용하면 안 되는 쿠폰을 처리한다면 서비스 규칙을 어긴 것입니다.

잘못된 전제를 그대로 둔 채 AI에게 구현과 테스트를 모두 맡기면, 코드도 테스트도 같은 방향으로 틀릴 수 있습니다. 그래서 요구사항을 검토할 때는 다음과 같은 상황도 살펴봐야 합니다.

• 허용 범위를 벗어난 값이 들어오면 어떻게 처리할까요.
• 외부 서비스가 응답하지 않으면 얼마나 기다릴까요.
• 작업 도중 중단되면 어디까지 완료된 것으로 볼까요.
• 같은 요청이 반복되면 어떤 결과를 돌려줄까요.

AI는 이런 사례를 제안하고 테스트로 만드는 데 도움을 줄 수 있습니다. 팀은 그 제안이 실제 서비스의 규칙에 맞는지, 어떤 위험이 있는지 검토해야 합니다. 코드와 테스트가 서로 맞아떨어지더라도, 둘 다 실제 요구사항에 맞는지는 따로 살펴봐야 합니다.

책임은 배포하기 전에 정해야 합니다

“AI가 그렇게 작성했습니다”라는 말만으로는 장애를 해결할 수 없습니다. 운영 중에는 누군가 변경을 멈추고 어디까지 영향을 미쳤는지 확인해야 합니다. 복구할지 판단하는 일도 사람의 몫입니다.

이런 책임을 개인이 알아서 주의를 기울이는 데 맡겨두기는 어렵습니다. 요구사항을 확인할 사람과 배포를 승인할 사람을 업무 절차에 명시해야 합니다. 장애가 났을 때 누가 먼저 대응할지도 정해두어야 하죠. 작은 팀이라면 한 사람이 여러 역할을 맡을 수도 있습니다.

권한을 정할 때도 이 절차를 함께 고려해야 합니다. 코드를 제안하는 AI 도구와 운영 데이터를 직접 수정하는 AI 도구는 잘못 작동했을 때 미치는 영향이 다릅니다. 운영 데이터를 직접 수정한다면 접근 범위를 제한하는 일이 더 중요해집니다. 변경 내역을 남기고 복구할 수 있는지도 확인해야 합니다.

얼마나 꼼꼼히 검토할지는 변경이 미치는 영향에 따라 정하면 됩니다. 버튼 문구를 바꾸는 작업과 고객 데이터를 삭제하는 작업에 같은 절차를 적용할 필요는 없습니다. 되돌리기 어렵거나 피해가 큰 변경일수록 검증에 더 공을 들여야 합니다.

해밀턴의 작업을 돌아보면 소프트웨어를 만드는 능력에 실패를 예상하고 대비하는 능력도 포함된다는 생각이 듭니다. AI가 코드 작성을 도와줄수록 요구사항을 정하고 검증할 책임을 더 구체적으로 나눠야 합니다. 운영 중에 누가 무엇을 맡을지도 분명해야 합니다. AI가 제안한 변경에 문제가 생겼을 때 멈추고 되돌릴 사람이 누구인지, 배포 전에 정해두어야 합니다.