코드는 빨리 쌓이는데, 설계 이유를 아는 사람이 없다

AI 코딩의 성과를 출시 건수로만 평가하면 다음 수정에 필요한 설계 이해를 놓칠 수 있습니다. Claude Code를 쓰는 팀이 담당자와 검토 시간을 남겨야 하는 이유를 살펴봅니다.

가상 주문 A의 예상 청구 1건, 주문번호 중복 차단 결정 기록, 다음 재시도 간격 변경의 관계
가상 업무 적용 예시. 주문 A의 청구, 중복 차단 결정, 다음 재시도 간격 변경을 연결했다. 실제 실행 결과가 아니다.

AI가 코드를 빨리 써 주면 제품도 더 빨리 만들 수 있다. 다음 달에 요구사항을 바꿀 때는 그 코드가 왜 그렇게 만들어졌는지 설명할 사람이 필요하다. 데이터 엔지니어 시몬 슈페티(Simon Späti)는 9월 26일 작성하고 30일 갱신한 글에서 AI 코드의 품질보다 팀의 설계 이해가 사라지는 상황을 더 큰 문제로 지목했다.

슈페티는 Anthropic의 AI 코딩 도구인 Claude Code로 구현 속도를 높이면서도 사람이 제품의 구조와 선택 이유를 계속 알아야 한다고 본다. PM과 창업자가 생성한 코드량과 출시 건수만 세면, 이후 수정할 수 있는 제품인지 놓칠 수 있다.

테스트까지 자동으로 만들면 무엇이 남는가

슈페티가 인용한 익명 개발자는 새로 합류한 회사에서 명세와 코드, 테스트, 제품 요구사항 문서까지 Claude Code로 만들고, 팀에는 그것들을 읽을 시간이 없다고 호소했다. 경영진은 코드 작성이 더 이상 병목이 아닌데 왜 일이 느리냐고 물었다고 한다. 슈페티는 이 개발자의 경험담을 팀의 검토 시간이 사라지는 사례로 소개했다.

도구는 실제로 파일을 읽고 작업을 진행한다. Anthropic의 공식 Claude Code 데모에는 프로젝트의 package.json과 서버의 package.json을 읽는 과정이 나온다. 화면에 보이는 작업은 파일 두 개를 찾아 읽는 과정이다.

Claude Code 공식 데모에서 프로젝트와 서버의 package.json을 읽는 실제 화면과 원문 기반 한글 번역
원문 기반 한글 번역. 공식 데모 207번 프레임의 두 파일 읽기 로그. 출처: Anthropic Claude Code

자동으로 만든 테스트가 통과하는 것과, 팀이 그 테스트가 제품의 어떤 약속을 확인하는지 아는 것은 다른 일이다. 예컨대 결제 재시도 기능은 정상 결제가 되는지 외에 중복 청구를 막아야 하는 이유를 이해해야 수정할 수 있다. 결제 재시도는 글의 문제의식을 업무에 적용한 예시다.

코드를 설명하는 것과 선택 이유를 아는 것은 다르다

AI에게 코드를 설명해 달라고 하면 현재 구현이 어떻게 움직이는지 파악하는 데 도움을 받을 수 있다. 그러나 팀이 왜 다른 방법을 버렸는지까지 코드에서 자동으로 복구되지는 않는다. 고객과 합의한 예외, 당시의 운영 제약, 아직 구현하지 않기로 한 범위는 코드 밖에 있을 수 있다.

슈페티는 시스템 구조를 이해하고 의도를 가지고 설계하는 일이 여전히 필요하다고 본다. 간단한 앱이나 데이터 처리 흐름을 빨리 만들수록 유지해야 할 대상도 늘어난다는 주장이다. 그래서 생성 품질이 좋아지는 것만으로 유지보수 문제가 해결되지는 않는다고 설명한다.

가상 결제 재시도에서 주문 A의 예상 청구 1건, 주문번호 중복 차단, 재시도 한도를 구현과 결정 이유로 대비한 표
설계 이유가 코드 설명과 구분되는 지점을 정리했다. 출처: Simon Späti

슈페티는 무엇을 만들고 싶은지 아는 제품 담당자의 능력을 인정한다. PM이 프로토타입을 직접 만들어 사용자 반응을 보는 일과, 고객 데이터가 쌓인 제품을 운영하는 일은 요구하는 책임이 다르다. 운영 제품으로 옮길 때는 수정 범위와 실패 조건을 설명할 담당자를 정해야 한다.

검토 시간을 출시 일정 안에 넣어야 한다

팀 운영에서는 AI가 구현을 끝낸 뒤 사람이 변경을 검토할 시간을 따로 잡는 방법이 있다. 담당자가 변경 내용을 읽고 제품 요구사항과 대조하는 시간도 출시 일정에 포함하는 것이다. 검토를 기다린다는 이유로 바로 다음 기능을 붙이면, 읽지 않은 변경이 계속 쌓인다.

Anthropic의 공식 권장 사항도 먼저 탐색하고 계획한 뒤 구현하라고 안내한다. AI가 실행할 수 있는 테스트나 빌드 같은 확인 수단을 주고, 검사가 통과한 뒤에는 실행 중인 앱에서 변경을 다시 확인하라고 설명한다. 도구 제공자의 지침에도 구현 뒤 검토 단계가 남아 있다.

예를 들어 결제 재시도 변경을 맡은 엔지니어가 중복 청구를 막기 위해 택한 방법과 제외한 방법을 짧게 적고, 이를 확인하는 테스트를 연결한다. PM은 그 예외 처리로 사용자가 겪을 대기나 안내가 요구사항에 맞는지 확인한다. AI가 문서 초안을 써도 최종 설명과 승인에는 담당자의 이름이 남아야 한다.

가상 결제 재시도 변경의 결정 기록과 테스트 명세가 엔지니어에서 제품 담당자의 검토와 승인을 거쳐 다음 담당자에게 인계되는 스윔레인
결제 재시도는 편집부의 적용 예시이며, 단계 길이는 소요 시간을 뜻하지 않는다. 출처: Claude Code 권장 사항

AI 도입 성과는 다음 수정에서도 확인된다

창업자는 이번 주 출시 건수가 늘었는지와 함께, 다음 변경을 맡을 사람이 이전 선택을 설명할 수 있는지 확인할 수 있다. 담당자가 자리를 비웠을 때 다른 사람이 결정 기록을 찾아 수정 범위를 이해할 수 있는지도 살펴볼 만하다. 팀이 이런 설명에 계속 실패한다면 구현 속도만 높이고 인계 비용을 뒤로 미뤘을 가능성이 있다.

다음 출시 계획에 설계 검토 담당자와 검토 시간을 명시하면, 팀이 제품의 구조를 이해하고 있는지 변경마다 확인할 수 있다.


출처: Simon Späti, The Problem is not the AI Code, but Nobody Knows Anything Anymore · Claude Code 권장 사항