AI에게 개발과 영업을 맡겨보고 알게 된 것: 인간의 판단을 어디에 남길지 기록한 운영 일지

저는 개인적으로 소프트웨어를 개발하는 엔지니어입니다.

2026년 7월에는 개발 업무를, 9월에는 영업의 정형 작업을 AI에게 맡기는 시스템을 직접 구축하여 운영해 왔습니다.

이 글에서는 시스템의 전체적인 개요와 실제로 운영하며 부딪혔던 난관들, 그리고 인간의 판단을 어디에 남겨두었는지 기록합니다.

소스 코드는 공개하지 않기 때문에, 구성과 생각하는 방식, 그리고 운영 기록으로 설명하겠습니다.

무엇을 만들었는가

만든 것은 두 가지입니다.

개발 시스템

첫 번째는 백로그에 과제를 쌓으면 AI가 설계부터 머지(merge)까지 진행하는 개발 시스템입니다.

Claude Code를 헤드리스(headless)로 자식 프로세스(sub-process)로 실행하고, 각 공정을 연결했습니다.

• 작업은 태스크별로 git의 worktree를 잘라 격리하며, 사람이 직접 사용하는 작업 트리는 건드리지 않습니다.
• 리뷰는 구현과는 별도의 세션, 다른 모델, 읽기 전용 도구(read-only tool)를 사용하여 진행하며, 판정 결과를 정해진 형식의 JSON으로 반환받습니다.
• 머지 후에 개발 브랜치를 재검증하고, 문제가 있으면 복구 태스크를 자동으로 쌓습니다.
• 백로그가 비면 개선 제안 담당자가 다음 과제를 생각하고, 야간에는 그 제안을 자동 승인하여 구현까지 진행합니다.

이 시스템은 저 자신을 개발 대상으로 삼았습니다.

기록된 태스크는 243건이며, 그중 239건이 완료되었습니다.

243건 중 207건은 사람이 아닌 개선 제안 담당자가 생성한 것입니다.

2026년 7월 3일부터 8월 27일까지 만들어진 PR(Pull Request)은 325건이며, 모두 머지되었습니다.

그중 269건은 하네스(Harness)가 자동으로 만든 브랜치에서 나왔습니다.

이 외에도 직접 만든 앱 몇 개에 도입하여 사용해 왔습니다.

AI 영업부

두 번째는 위탁 개발의 영업을 진행하는 'AI 영업부'입니다.

2026년 9월 16일에 출범했습니다.

업무별로 담당자를 정하고, 직원으로 설정했습니다.

정의된 역할은 부장, 영업 1과, 영업 2과, 법무부, 기획부의 총 5개 부서에 걸쳐 25명입니다.

주요 업무는 다음과 같습니다.

• 수집 담당자와 선별 담당자가 여러 클라우드 소싱 사이트에서 신규 프로젝트를 모아 규칙과 AI의 채점으로 후보군을 압축합니다.
• 초안 작성 담당자가 제안서를, 문의 응대 담당자가 회신 초안을 작성합니다.
• 법무 담당

대책으로, 작업 트리 상태뿐만 아니라 분기 지점과의 커밋된 차이(diff)에서도 성과를 판정하도록 했습니다.

AI의 자체 신고와, 작업 후에 남는 사실은 구분해서 다룰 필요가 있었습니다.

완료 여부는 '완료했다'라는 보고가 아니라, 차이가 있는지, 테스트가 통과했는지로 결정해야 했습니다.

2. 예산 상한에 도달하자 결과 전체가 사라졌다

리뷰 담당자가 승인을 내렸음에도 불구하고, 하네스(Harness)에는 빈 응답만 돌아왔고, 같은 작업이 여러 번 실패 처리되었습니다.

원인은 한 번의 실행마다 설정했던 예산 상한 때문이었습니다.

AI가 결과를 작성한 직후라도, 마지막 교환 전에 상한에 도달하면 결과가 출력에 실리지 않고 끝났습니다.

중단(打ち切り)되는 방식은 두 가지였는데, 한쪽은 종료 코드상으로는 정상 종료였습니다.

대책으로, 두 가지 반환 방식을 모두 '예산 초과'로 분류하고, 설계, 구현, 리뷰 어느 공정에서든 상한을 늘려 재시도하도록 했습니다.

더 나아가, 구현 도중에 중단될 때는 작업 트리의 중간 경과를 임시 커밋으로 저장하여, 다음 시도를 이어서 시작할 수 있도록 했습니다.

이전에는 상한을 늘리더라도 처음부터 다시 해야 했기 때문입니다.

나중에 개선 제안 등 다른 경로에서도 같은 문제가 발견되어, 동일한 대책을 적용했습니다.

중단은 실패의 일종으로 명시적으로 분류하고, 중간 경과를 버리지 않는 것이 중요함을 배웠습니다.

3. 데이터베이스 읽기 상한 때문에 반나절이 멈췄다

영업부 장부는 클라우드 데이터베이스의 무료 사용량으로 운영하고 있습니다.

하루 읽기 제한은 500만 행까지이며, 일본 시간 오전 9시에 초기화됩니다.

평소에는 하루 300만 행 전후였으나, 어느 날 530만 행에 도달했습니다.

오후 5시 반부터 다음 날 아침 9시까지 관리 화면을 열 수 없게 되었고, 영업부 장부 작업도 모두 실패했습니다.

원인은 관리 화면의 구조였습니다.

누군가 작업 중이면 30초마다 화면 전체를 다시 읽어오는 방식으로 만들어져서, 영업부가 쉬지 않고 움직이자 항상 누군가가 작업 중인 상태가 되었습니다.

그때마다 인덱스가 적용되지 않은 집계로 1~2만 행을 읽고 있었습니다.

매분 순찰(見回り)도 표 전체를 검색하고 있었습니다.

대책은 다음과 같습니다:

• 인덱스를 추가하고, 무거운 집계를 업데이트할 때마다 기록하는 작은 표로 대체했습니다.
• 관리 화면은 변화의 표시만

최근에는 경쟁사가 적고 점수가 높은 건에 한해서, 선택하는 단계까지 자동화했습니다.

그 경우에도 보내는 것은 사람이 승인한 후에 이루어집니다. - 제안서나 회신은 모두 승인 대기 목록에 쌓입니다.

법무 담당자가 수정이 필요하다고 하는 문구는 자동으로 반송되어 다시 작성하게 하고, 그것이 2회를 넘으면 사람에게 맡깁니다. - 사람이 이유를 적어 반송하면, 담당자가 그 이유와 이전 문구를 읽고 다시 작성하여 새로운 승인으로 쌓아 올립니다.

반송은 1분 간격으로 처리하므로, 대기 시간은 거의 없습니다.

'불필요', '보류'로 시작하는 이유라면, 재작성하지 않고 닫습니다. - 가격 변경은 기획 담당자가 제안만 할 뿐, 결정하는 것은 사람입니다.

도입할 때 유의할 점

개발팀이나 회사에서 같은 것을 도입한다면, 다음 다섯 가지를 처음부터 설계에 포함시키는 것을 권장합니다.

이 모든 것은 운영하면서 얻은 경험을 바탕으로 합니다.

• 작업별로 격리하고, 병합(merge)의 관문을 기계가 갖게 하는 것입니다.

worktree에서 격리, 테스트, 다른 모델을 통한 읽기 전용 검토, 병합 후 검증을 거치면, AI의 오류가 본류에 도달하기 어려워집니다. - AI의 자체 진술이 아니라, 차이점(diff)이나 테스트 결과 같은 남겨진 사실로 판단하는 것입니다.

• 외부로 나가는 처리는 기본적으로 승인 대기 목록에 쌓는 것입니다.

결정된 문구라도 예외 없이, 망설여지면 보내지 않고 사람의 판단으로 넘기는 쪽으로 기울입니다. - 중단, 상한선, 멈춘 상태의 처리를 처음부터 예상해 두는 것입니다.

상한선에 도달해도 중간 경과를 남기는 시스템과, 읽기 양이나 처리 시간 감시가 필요합니다. - 사람의 판단 대기 시간을 줄이고, 반송 이유를 다음 작업 입력으로 활용하는 것입니다.

승인이 빠르게 돌아갈수록, AI에게 맡길 수 있는 범위를 안심하고 넓힐 수 있습니다.

맺음말

이 글은 완성품 소개가 아니라, 작동시키면서 고치고 있는 과정의 기록입니다.

AI에게 맡기는 범위가 넓어질수록, 사람이 어디서 판단할지 미리 정해두는 것의 중요성을 느끼고 있습니다.

개발팀에 AI 구동 개발(AI-driven development) 도입이나 업무 자동화에 대해 상담이 필요하시면, 프로필에서 연락 주십시오.

Discussion