AI 여러 개를 쓰다가 내가 전달자가 된 이유

1인 개발 AI 자동화를 위해 AI를 여러 개 쓰기 시작했다. 한 AI만 쓸 때 놓치는 부분이 있었고, 두 AI를 쓰니 검토가 나아졌다. 그러나 AI 사이에서 결과를 옮기는 일은 전부 사람 몫으로 남았다. 이 글은 그 전달 역할이 어떻게 생겼는지, 이를 줄이려고 로컬 환경에 무엇을 만들려 했는지 정리한다.

사내 해커톤에서 GPT 단독 사용의 한계

4월 무렵 사내 해커톤에 참가했다. 만든 것은 배치 프로그램이 남기는 정보를 벡터 DB에 저장하고, 오류가 나면 LLM에게 원인을 추론하게 하는 프로그램이다. 범위가 넓어서 GPT와 함께 작업했다.

진행 방식에서 반복이 생겼다. 수정하면 오류가 나고, 오류를 고치면 의도와 다르게 구현되고, 다시 물으면 같은 가설 사이를 맴돌았다. 그때 든 물음은 이랬다. AI가 아직 이 수준은 아닌 건가, 내가 맞게 활용하고 있는 건가.

막판에 작업을 기능 단위로 나눴다. 전체를 한 번에 맡길 때는 어디가 틀렸는지 찾기 어려웠다. 기능 하나씩 맡기니 고치는 범위가 줄었고, AI가 앞선 작업을 기억하지 못하는 일도 줄었다. 결과물은 완성했다. 성능은 재지 않았다.

소스 분석 도구에서 Claude가 GPT 설계를 짚었다

6월 무렵 개인 프로젝트로 소스 분석 도구를 설계했다. 설계는 GPT에게 받았고, 같은 설계를 Claude에게 검토시켰다. GPT에게서는 나오지 않던 부분을 Claude가 짚었다. 하나의 AI만 쓰면 찾지 못할 부분이 있다는 것을 이때 확인했다. 이후 두 AI를 함께 쓰기 시작했다.

역할 분담에는 사용 한도가 영향을 줬다. Claude는 주말에 몰아서 작업할 때 5시간 제한에 자주 걸렸다. 그래서 설계와 반복 작업은 GPT에게 맡기고, 논의가 꼭 필요할 때만 Claude에게 검토를 받았다. 검토 구멍을 찾은 것은 Claude였지만, 역할을 나눈 이유는 결국 사용 한도였다.

검토는 나아졌지만 옮기는 일은 사람 몫으로 남았다

두 AI를 쓰면서 검토의 질은 올라갔다. 반면 작업 방식은 단순해지지 않았다. 한쪽 결과를 받아 다른 쪽에 붙여넣고, 다시 가져와 확인하는 과정이 반복됐다. 단순 작업을 사람이 하고 있었고, AI가 사람에게 일을 시키는 구조처럼 보였다. 편하려고 AI를 쓰는데, 단순 업무는 결국 사람이 하고 있는 게 아닌가 하는 물음이 남았다.

이 흐름을 그리면 가운데 사람이 있다.

운영 환경을 만들면 사람의 개입이 줄 것이라고 봤다. 이 판단은 틀렸다. 플랫폼이 없으니 AI들 사이의 연결을 사람이 계속 맡고 있었다.

2026년 10월 설계 교차에서 확인된 것

2026년 10월에는 같은 방식으로 설계를 교차했다. GPT와 Claude가 각자 독립 초안을 만들고 서로의 설계를 반증했다. 그 과정에서 양쪽 제안이 실제로 바뀌었다. Claude는 검증 기준을 작업자가 바꿀 수 있는 자리에 두고 있었다는 허점을 인정하고, 독립된 검증 경계를 요구하는 쪽으로 고쳤다.

최종 결과는 두 AI가 합의한 설계가 아니었다. 공통 원칙과 사람이 정해야 할 쟁점을 나눈 정리였다. 자동 병합을 언제 허용할지, 일반 변경을 얼마나 독립 검토할지는 아직 정하지 않았다. 교차 과정에서 여러 채팅을 오가며 결과를 옮긴 것도 사람이었다. 개입을 줄이려던 설계를 만드는 과정이 다시 개입을 만든 셈이다.

지금 상태는 목표보다 한 단계 뒤에 있다

목표는 AI끼리 주고받는 과정을 환경이 맡고, 검토는 독립된 AI가 하게 만드는 것이다. 2026년 11월 8일 기준으로는 아직 그렇지 않다. 로컬 LLM은 쓰지 않고, Ollama만 설치돼 있다.

그래서 사람의 개입을 최소화하면서 AI를 쓰는 방법을 찾는 중이다. 지금 답하지 못하는 질문은 하나다. AI를 여러 개 쓸 때 사람은 어디까지 전달자 역할을 맡아야 하는가.

이 글은 내 작업 기록과 인터뷰 답변을 바탕으로 Claude가 초안을 쓰고 내가 고쳐 썼다.