AI가 만든 코드, 동작을 설명하면 선택한 이유도 남을까요
Sphinx는 개발자에게 코드의 동작을 묻고, 여기어때 개발팀은 선택의 이력을 함께 검토합니다. 동작을 예측하는 능력과 구현을 택한 이유를 보존하는 일은 서로 다른 증거를 요구합니다.
공개 개발 도구 Sphinx의 설명서는 검사 대상으로 설정한 브랜치에 코드를 보내는 절차를 보여줍니다. 전송을 마치기 전에 질문지가 개발자의 답을 기다립니다. 검토용 AI가 변경한 코드를 읽고, 개발자에게 그 코드가 어떤 결과를 낼지 묻습니다. 코드를 만든 대화는 검토 모델에 전달하지 않습니다. 검토 모델은 작성 대화 없이 커밋된 변경 내용과 관련 파일 등을 읽습니다. Sphinx 설명서
여기서 개발자가 제출하는 것은 코드만이 아닙니다. 코드가 움직일 방식에 대한 자신의 설명도 내놓습니다. 다만 동작을 설명하는 일과 그 구현을 선택한 이유를 설명하는 일은 같지 않습니다. AI와 코드를 만들 때 어떤 이해를 사람에게 남겨야 하는지 보려면, 두 질문을 나누어 볼 필요가 있습니다.
전송을 멈추는 것과 이해를 판정하는 것
Sphinx가 묻는 대상은 파일명이나 함수명 암기가 아닙니다. 변경 뒤의 동작, 실패할 수 있는 조건, 계속 성립해야 하는 규칙입니다. 설명서에 따르면 답하는 동안 코드를 읽어도 됩니다. 답이 부족하면 설명을 듣고 다른 상황으로 다시 질문받을 수 있습니다. 설치해 시험한 결과가 아니라, 공개 설명서에서 확인한 설계입니다. Sphinx 설명서
전송 앞에 이런 절차를 놓는 기술적 장치는 Git에 이미 있습니다. 공식 문서의 pre-push는 원격 저장소로 변경을 보내기 전에 실행할 수 있는 프로그램입니다. 이 프로그램이 실패 상태로 끝나면 전송도 중단됩니다. 그러나 전송을 막을 수 있다는 기능 설명에는, 질문이 적절한지나 답한 사람이 이해했는지를 보장한다는 뜻이 들어 있지 않습니다. Git 공식 문서
Sphinx도 이 선을 분명히 긋습니다. 로컬 훅은 우회할 수 있고 검토 모델도 틀릴 수 있으므로, 통과가 혼자 이해했다는 증명은 아니라는 것입니다. 따라서 이를 사람을 가려내는 자격시험으로 읽으면 도구가 약속한 범위를 넘어섭니다. 사용자가 답을 생각하도록 잠시 멈추게 하는 연습과, 이해 여부를 믿고 권한을 부여하는 검증은 서로 다른 일입니다. Sphinx 설명서
코드는 같아도 선택의 사정은 다릅니다
코드의 동작을 제대로 예측해도 풀리지 않는 질문이 있습니다. 왜 다른 구현을 버렸는지, 어떤 요구사항 때문에 이 방법을 택했는지입니다. 같은 결과를 내는 구현이 여럿이라면, 현재 코드만 읽어서는 당시의 비교 과정을 복원하기 어렵습니다. 이 차이가 중요해지는 순간은 나중에 조건이 바뀌었을 때입니다. 구현의 원리를 아는 것만으로는 어느 선택부터 다시 검토해야 하는지 충분히 알 수 없습니다.
여기어때 유저혜택개발팀의 개발자 윌비는 10월 10일 기술블로그에서 그 과정을 남기는 운영 사례를 소개했습니다. 팀은 공유 저장소에 작업 지침과 이력을 모으고, 코드 리뷰에서 이력을 함께 참조합니다. 작업 중 판단은 먼저 기록하되, 팀 검토를 거친 내용을 공통 지침으로 반영한다고 설명합니다. 한 팀의 운영 경험이며, 이 방식이 결함을 얼마나 줄였는지 입증하는 비교 실험은 아닙니다. 여기어때 기술블로그
이 글에서 주목할 대목은 기록을 많이 남기자는 제안보다, 기록할 사실과 AI의 추측을 구분하자는 경고입니다. 사람이 AI의 선택지 하나를 골랐다는 사실만으로 AI가 그 사람의 의도를 추측해 적으면, 밝히지 않은 이유가 다음 작업의 전제가 될 수 있다는 것입니다. 저자는 선택과 명시적으로 밝힌 의도를 구분하고, 판단을 곧바로 공통 규칙으로 굳히지 않는 방식을 제시합니다. 여기어때 기술블로그
두 사례를 함께 보면 필요한 설명의 종류가 드러납니다. Sphinx의 질문은 지금의 코드가 무엇을 할지 답하게 합니다. 팀의 작업 이력은 어떤 조건과 선택을 거쳐 그 코드에 도착했는지 검토할 재료가 됩니다. 하나가 다른 하나의 증거를 대신하지는 못합니다. 동작을 잘 설명한다고 팀의 요구에 맞는 선택이었다는 뜻은 아니며, 선택 이유가 기록돼 있다고 실제 동작을 이해했다는 뜻도 아닙니다.
남은 검증 과제 역시 구체적입니다. 질문에 답한 사람이 시간이 지난 뒤에도 실패 조건을 설명할 수 있는지, 기록을 받은 동료가 작성자의 도움 없이 이전 선택을 재검토할 수 있는지를 확인해야 합니다. 지금 확인한 자료만으로 두 방식의 효과를 결론 낼 수는 없습니다.
질문지 뒤에 멈춰 있던 코드 전송은 검사를 통과한 뒤에도 사용자가 진행 여부를 선택합니다. 그때 살필 것은 통과 표시만이 아닙니다. 개발자가 실제로 설명한 동작과, 팀이 나중에 다시 물을 수 있도록 남긴 선택의 이유는 별도로 살펴야 합니다.