정명구 님이 2026년 9월 28일에 공개한 출시 과정
아정당 기술 블로그에 2026년 9월 28일 게시된 「코드 한 줄 직접 쓰지 않고 서비스를 런칭하기까지」는 아정네트웍스 플랫폼 챕터의 백엔드 개발자 정명구 님이 쓴 글입니다. 저자에 따르면 이사/청소 스쿼드는 AI와 함께 6개월 동안 서비스를 개발해 9월 1일 출시했고, 첫날 1,000건이 넘는 오더 접수 요청을 처리했습니다. 원문에는 이 요청 가운데 성공 비율이나 오류율은 적혀 있지 않습니다.
저자는 코드 작성을 AI에 맡기고, 사람은 요구사항을 구체화하고 아키텍처와 검증 기준을 정하며 구현 결과를 검토했다고 밝혔습니다. 이 글에서는 그 사례를 에이전트 업무 설계 관점에서 읽습니다. 사례와 수치는 저자 팀의 것이고, 제 해석은 "제가 보기에는"으로 구분했습니다. 원문 본문에는 어떤 AI 모델이나 코딩 도구를 썼는지 적혀 있지 않아 이 글에서도 다루지 않습니다.
용어와 경계를 먼저 정하고, 규칙은 테스트로도 검사합니다
저자는 구현에 앞서 도메인 주도 설계(DDD)의 유비쿼터스 언어부터 정의해, 개발자·기획자·AI가 같은 개념을 같은 말로 부르게 했습니다. 오더, 매칭, 견적, 계약, 작업, 결제의 의미와 상태를 정리했고, '신청'과 '오더'로 섞어 부르던 대상은 '오더'로 통일했습니다. 이어서 용어마다 상태와 규칙을 책임지는 경계(BC, Bounded Context)를 정해 업무 영역별로 나눴습니다. 저자는 DDD를 처음 적용해 이 경계가 맞다는 확신은 없었고, 판단과 근거를 기록해 두었다고 썼습니다.
문서만으로는 부족했던 사례도 소개합니다. 구현 에이전트 지시에 "커밋하지 말 것"이라고 썼더니, 에이전트가 커밋이 하나도 없는 상태를 만들라는 뜻으로 받아들여 기존 커밋까지 되돌린 일이 있었다고 합니다. 그래서 저자 팀은 코드 구조처럼 자동으로 확인할 수 있는 규칙을 테스트로도 검사합니다. 여러 BC가 함께 쓰는 shared 패키지에 특정 BC의 로직을 두지 않는다는 규칙은 ArchUnit 테스트로 검사하며, AI가 오더 조회 코드를 shared에 넣고 오더 영역의 클래스를 참조하면 테스트가 실패합니다. 저자는 테스트로 지킬 수 있는 것은 이미 정한 경계까지이고, 어떤 기능을 어느 영역에 둘지는 여전히 설계와 리뷰에서 정해야 한다고 덧붙였습니다.
Anthropic의 스킬 작성 가이드도 스킬 안에서 같은 대상을 하나의 용어로 부르라고 권하며, 용어를 일관되게 쓰면 Claude가 지시를 해석하고 따르기 쉬워진다고 설명합니다. 제가 보기에는 저자의 사례가 그다음 단계를 보여 줍니다. 용어를 통일해도 에이전트는 문장을 다르게 해석할 수 있으니, 자동으로 검사할 수 있는 규칙은 문서와 테스트 양쪽에 함께 둬야 합니다.
설계·구현·리뷰를 스킬 3개로 나누고 단계마다 멈춥니다
저자는 AI가 따를 작업 절차와 참고 자료를 스킬 3개로 묶었습니다. strategy-checklist가 설계, tdd-helper가 구현, code-review가 검토를 맡습니다. 설계 스킬은 요구사항을 되묻는 grill me 방식을 빌려, 관련 자료를 먼저 확인한 뒤 사람이 놓친 제약과 예외를 질문하도록 다듬었다고 합니다. 선택지와 추천안은 AI가 내고, 최종 판단은 사람이 합니다.
저자 팀은 단계 사이를 일부러 끊었습니다. 한때는 설계에서 구현까지 자동으로 이어졌지만, 지금은 체크리스트가 완성되면 멈추고 사람이 설계를 확인한 다음 구현을 새 세션에서 시작한다고 합니다. 저자는 AI가 한 세션에서 참고할 수 있는 컨텍스트에 한계가 있어, 합의한 요구사항과 근거, 검증 기준을 체크리스트에 정리해 다음 단계로 넘긴다고 설명했습니다.
Anthropic 공식 문서는 스킬을 작업 흐름, 맥락, 모범 사례를 담아 범용 에이전트를 특정 분야의 전문가로 만드는 재사용 가능한 파일 기반 자료로 설명합니다. 같은 회사의 작성 가이드는 복잡한 작업을 순서가 분명한 단계로 나누고, 특히 복잡한 흐름에는 체크리스트를 주라고 권합니다. 이 문서들은 스킬이라는 형식의 일반 설명으로만 인용합니다. 아래 도식에 저자가 밝힌 절차를 에이전트와 사람의 역할로 나눠 정리했습니다.
에이전트의 보고는 결과 파일로 다시 확인합니다
저자는 에이전트의 보고를 그대로 믿을 수 없었던 사례도 적었습니다. 구현 에이전트가 테스트 전체 통과라고 보고했는데, 빌드 도구가 예전 실행 결과를 다시 쓰는 바람에 테스트 코드의 컴파일 실패가 드러나지 않았고 실제로 실행된 테스트는 0건이었습니다. 이후 저자 팀은 에이전트가 테스트 결과 파일에서 실제로 실행된 건수를 확인하고 나서 보고하도록 바꿨습니다. 저자에 따르면 출시 시점 테스트 코드는 약 22만 줄이었습니다.
리뷰 지적도 다른 에이전트가 다시 확인합니다. code-review가 의심 지점을 찾으면, 그중 중요한 건은 별도의 검증 에이전트가 맡습니다. 이 에이전트는 앞선 대화 내용을 모르는 새 컨텍스트에서 코드와 프로젝트 규칙을 다시 읽고, 지적이 실제 문제인지 판단합니다. 첫 리뷰의 결론에 영향을 받지 않도록 심각도·확신도 점수와 수정안은 전달하지 않고, 근거가 모자라면 불확실한 상태로 둡니다. 반영할지는 사람이 마지막에 정합니다.
Anthropic은 2024년 12월 19일 공개한 「Building effective agents」에서 에이전트가 실행 중 단계마다 도구 호출 결과나 코드 실행 같은 환경의 실제 결과를 확인해야 진행 상황을 판단할 수 있다고 썼습니다. 같은 글은 자동 테스트가 기능 확인에 도움이 되지만, 해법이 시스템 전체 요구사항에 맞는지 확인하려면 사람의 리뷰가 여전히 중요하다고 했습니다. 제가 보기에는 저자 팀이 이 원칙을 실제 작업 규칙으로 옮겼습니다. 문장 보고 대신 결과 파일을 보게 했고, 검증자에게는 앞선 결론을 넘기지 않았습니다. 아래 표의 오른쪽 칸은 제가 점검 항목으로 바꿔 적었습니다.
| 저자가 밝힌 문제 | 저자 팀이 바꾼 방식 | 점검 항목(작성자 해석) |
|---|---|---|
| "커밋하지 말 것"을 다르게 해석해 기존 커밋까지 되돌림 | 자동으로 확인할 수 있는 규칙은 테스트로도 검사 | 금지 규칙을 문서에만 적어 두지 않았는가 |
| "테스트 전체 통과" 보고, 실제로는 한 건도 실행되지 않음 | 결과 파일에서 실제 실행 건수를 확인한 뒤 보고 | 에이전트의 완료 보고를 결과 파일로 확인하는가 |
| 리뷰 중 수정한 코드는 다시 리뷰가 필요 | 수정과 리뷰의 역할을 분리 | 고치는 에이전트와 검토하는 에이전트를 나눴는가 |
| 첫 리뷰의 판단에 끌려갈 위험 | 새 컨텍스트에서 검증, 점수와 수정안은 넘기지 않음 | 검증자에게 앞선 결론을 넘기지 않는가 |
경계가 바뀌어도 변경 비용을 작게 유지한 방법
저자는 처음 정한 경계가 한 번 바뀌었다고 밝혔습니다. 통화 기능을 처음에는 CRM BC에 두었다가 안심번호 연동을 계기로 Call BC로 분리했고, 이 과정에서 114개 파일을 변경했습니다. 저자는 BC 사이의 연결을 이벤트와 Port(인터페이스)로 좁혀 둔 덕분에 내부 구현을 옮기기 수월했고, ArchUnit으로 의존 관계를 확인하며 진행해 하루가 채 걸리지 않았다고 썼습니다.
새로 합류한 백엔드 팀원에게는 티켓을 확인하고 스킬 3개를 순서대로 쓰면 된다고 안내했고, 별도로 설명하거나 도와야 할 부분은 크게 없었다고 합니다. 저자는 남은 과제로 작업 시작부터 리뷰 완료까지 걸리는 시간을 꼽았습니다. 품질을 높이려다 에이전트의 검증 단계를 필요 이상으로 늘린 적이 있어, 앞으로는 결제 흐름처럼 오류가 나면 영향이 큰 변경에는 검증을 더 깊게 하고, 범위가 작고 쉽게 되돌릴 수 있는 변경에는 시간에 비해 효과가 적은 추가 검증을 덜 하겠다고 밝혔습니다.
제가 보기에는 다른 팀이 이 사례를 참고할 때 이 남은 과제부터 살펴보는 편이 좋습니다. 검증 단계를 늘릴수록 기다리는 시간도 늘어나므로, 오류의 영향과 되돌리기 쉬운 정도에 따라 검증 깊이를 정하는 기준을 처음부터 함께 적어 두어야 합니다.
이번 주에 해 볼 첫 단계
에이전트에게 맡기고 있는 개발 작업 1건을 골라 설계, 구현, 리뷰 단계를 나눠 적어 보십시오. 단계마다 에이전트가 멈추고 사람이 확인할 위치를 정하고, 에이전트가 "완료"나 "통과"라고 보고하는 항목은 어떤 결과 파일이나 로그로 확인할지 옆에 적습니다. 그다음 이번 주에 받은 에이전트 보고 1건을 골라, 보고 내용이 결과 파일의 실제 실행 건수와 맞는지 직접 대조해 보십시오.