Claude Code로 코딩 작업을 이어 갈 때 결과를 확인하고 다음 지시를 입력하는 일이 사람에게 반복해서 돌아옵니다. 이 부담을 줄이기 위해 설계된 코딩 agent(목표에 맞춰 코드 작성과 도구 실행을 맡는 AI 작업자)는 중간 결과를 평가하는 별도의 반복 담당 agent를 둡니다. 작업 등록부터 실행, 검증, 변경 사항 반영까지 한 흐름으로 묶되, 실제로 확인된 동작과 설계상 기대하는 효과는 나눠 볼 필요가 있습니다.
사람이 다음 지시를 쓰지 않아도 이어지는 작업
기본 구상은 사람과 코딩 agent 사이에 중간 결과를 살피고 다음 지시를 이어 가는 반복 담당 agent를 두는 것입니다. 사용자가 요구 사항과 완료 조건을 정하면 코딩 agent가 작업하고, 반복 담당 agent가 결과를 검토해 다음 단계를 지시합니다. 계획이 기준에 맞지 않으면 반복 담당 agent가 이를 거절할 수도 있습니다. 목표는 매 단계마다 사람이 개입하는 대신, 완료 조건을 확인한 뒤 결과를 돌려주는 것입니다.
여기에 작업 상태를 대기·계획·진행·차단·완료로 관리하는 보드를 결합했습니다. 상태나 자동화 규칙을 자유롭게 늘리는 방식보다는, 코딩 작업에 필요한 경로를 좁게 정한 설계입니다. 설정의 자유도보다 작업을 이어 가는 데 필요한 조작을 줄이는 쪽을 택한 것으로 보입니다.
음성으로 등록한 작업은 어디까지 진행됐나
음성 명령으로 작업 보드를 열고, 세션 목록에 Git 상태를 색상 점으로 표시하는 작업 카드를 만들었습니다. 요청에는 원격 저장소에 올리지 않은 상태는 빨강, 아직 병합하지 않은 상태는 노랑, 병합을 마친 상태는 초록으로 구분하라는 조건이 담겼습니다. 음성 도우미는 이를 카드 26으로 등록하고 사용자 관점의 요구 사항과 검사 기준을 정리했습니다. 단순히 말을 입력란에 받아 적는 역할을 넘어, 작업을 구조화하고 보드 화면을 조작한 셈입니다.
카드에서 auto plan(자동 계획 수립)과 auto build(자동 구현)를 켠 뒤 계획 상태로 옮기자, agent가 코드를 읽고 구현 단계를 작성하기 시작했습니다. 이전 작업을 찾는 기능도 확인됐습니다. 음성으로 16시간 전의 ASCII 문자 아이콘 디자인 작업을 요청하자 관련 세션을 찾아 열고 당시 대화 내용을 다시 불러왔습니다.
▲ 음성 기반 작업 등록
실행을 서버로 분리한 이유
작업을 맡은 agent는 로컬 터미널 안에서 실행되지 않습니다. 세션과 대화 기록은 서버에 보관하고, 파일 읽기·수정·명령 실행은 작업별 Docker container(서버에서 작업을 격리해 실행하는 공간)에서 처리합니다. 각 카드에 별도의 Git(코드 변경 이력을 관리하는 도구) 브랜치와 작업 공간을 연결하므로 여러 작업이 같은 로컬 파일을 직접 건드리지 않도록 설계했습니다. 기기를 바꿔도 같은 세션을 이어 쓰고 실행 환경의 도구와 의존성을 일정하게 유지하려는 구조입니다.
이 분리는 뜻밖의 오류에서 효과를 드러냈습니다. 터미널 인터페이스가 ‘Maximum update depth exceeded’ 오류로 종료됐지만 서버의 작업은 계속 실행됐습니다. 인터페이스를 다시 열어 진행 중인 세션에 연결할 수 있었습니다. 다만 데스크톱에서 노트북이나 모바일 환경으로 실제 작업을 옮기는 과정까지 확인된 것은 아닙니다. 기기 간 연속성은 이 사례에서 확인된 동작이라기보다 서버 중심 설계가 제공하려는 기능입니다.
▲ 터미널 오류와 서버 작업
검증 결과와 자동 반영의 범위
코딩 agent와 반복 담당 agent에는 같은 여섯 가지 작업 원칙을 적용했습니다.
- 수정 전에 코드를 읽고 작동 방식을 이해합니다.
- 새로 만들기 전에 기존 구현과 문서를 찾습니다.
- 복잡성을 늘릴 이유가 없다면 단순하게 만듭니다.
- 추측 대신 코드 실행과 테스트로 확인합니다.
- 요청받은 범위를 지키고 다른 문제는 분리합니다.
- 코드 구조뿐 아니라 최종 사용자 경험을 고려합니다.
단순성과 사용자 경험처럼 원칙이 충돌하면 agent끼리 검토하고, 판단이 모호할 때는 사람에게 결정을 넘기도록 했습니다. 이 원칙들이 실제 성능을 얼마나 높였는지 따로 측정한 결과는 없지만, 작업과 검토에 공통 기준을 주려는 설계 의도는 분명합니다.
색상 상태 표시 작업에서는 총 337개 테스트를 실행해 334개가 통과했습니다. 실패한 3개는 기존 실행에서도 실패하던 항목으로 분류됐습니다. 따라서 ‘모든 테스트 통과’가 아니라, 기존 실패를 구분해 결과를 확인한 사례입니다. 완료된 카드를 옮긴 뒤에는 자동 동기화 절차를 작동시켜 원격 변경 사항을 확인하고 코드를 반영했습니다. GitHub에서도 5개 파일의 변경 사항을 확인했습니다. 충돌이 해결되지 않으면 작업을 차단 상태로 표시하고 사람의 개입을 받도록 설계했지만, 이번 작업이 모든 충돌 상황을 검증한 것은 아닙니다.
적용할 때 확인할 점
이 구조에서 확인된 개선은 음성으로 작업을 등록하고 과거 세션을 찾은 일, 터미널 종료 뒤에도 서버 작업이 이어진 일, 한 작업의 테스트와 코드 반영까지 연결된 일입니다. 반면 작업 시간 단축이나 기기 간 전환의 효과를 수치로 확인한 결과는 없습니다. 비슷한 흐름을 설계한다면 먼저 카드에 완료 조건과 검사 기준을 적고, 자동 계획·구현을 켜더라도 기존 테스트 실패와 새 실패를 구분해야 합니다. 실행 공간과 터미널을 분리하되, 병합 충돌처럼 자동으로 결론 낼 수 없는 단계는 사람이 확인하도록 남겨 두는 것이 핵심입니다.