세 AI에게 같은 일을 맡긴 2주, 개발을 다시 시작한 이유

세 가지 AI가 서로의 작업을 검토하게 하면 더 안전하게 개발할 수 있을 것이라고 생각했다. 하지만 약 2주 뒤 남은 것은 비슷한 문서와 내가 판단하지 못한 결정들이었다.

20Springs 개발을 시작하면서 Codex, Claude Code와 Gemini가 서로의 결과를 검토하는 구조를 만들었다. 한 AI가 작업하면 나머지 두 AI가 확인하고, 검토 결과를 다시 원래 AI에게 전달했다. 의견이 다를 때에는 내가 최종 결정을 맡았다.

처음에는 여러 AI가 서로의 부족한 부분을 보완하고 있다고 생각했다. 작업과 검토가 끊임없이 이어졌고, 화면에는 긴 답변과 새로운 문서가 계속 나타났다.

하지만 약 2주가 지나도 내가 눈으로 확인할 수 있는 서비스는 보이지 않았다.

나는 개발보다 전달 작업을 반복하고 있었다

매일 하는 일은 비슷해졌다.

1. 한 AI에게 다음 작업을 요청한다.
2. 작업 결과가 나오면 다른 AI에게 보낼 검토 요청서를 받는다.
3. 요청서를 복사해 각각의 AI에게 전달한다.
4. 검수 결과를 다시 원래 AI에게 복사해 보낸다.
5. 의견이 다르면 권장안을 선택한다.
6. 수정된 결과를 다시 검토한다.

겉으로 보면 협업 과정처럼 보였다. 실제로는 내가 세 AI 사이에서 문서를 옮기는 역할을 반복하고 있었다. 각 AI는 자신에게 전달된 자료를 기준으로 성실하게 답했지만, 세 도구가 하나의 기억과 작업 공간을 공유하는 것은 아니었다.

분명 어제 결정한 것 같은 내용을 오늘 다시 검토했고, 이름만 다른 비슷한 문서가 계속 생겼다. 많은 일을 처리한 것 같은데 어느 기능이 실제로 끝났는지는 알기 어려웠다.

상반된 의견을 판단할 지식이 없었다

처음 세운 원칙에는 “AI들의 의견이 다르면 내가 결정한다”는 문장이 있었다. 최종 책임을 사람이 가져야 한다는 점에서는 맞는 생각이었다.

문제는 결정권만 정했을 뿐 판단 기준은 준비하지 않았다는 것이었다. 내가 이해할 수 있는 제품 방향이나 화면 구성이라면 선택할 수 있었지만, 개발 방식이나 구조에 관한 결정은 어느 쪽이 20Springs에 더 적합한지 알기 어려웠다.

결국 질문을 이해해서 판단하기보다 각 AI가 제시한 권장안을 고르게 됐다. 결정을 했다는 기록은 남았지만 왜 그 안을 선택했는지 내 말로 설명할 수는 없었다.

처음 기대한 모습	실제로 겪은 모습
여러 AI가 오류를 줄여 준다	같은 문제를 서로 다른 기준으로 반복 검토했다
내가 의견을 비교해 결정한다	판단할 지식이 없어 권장안을 선택했다
작업을 작게 나누면 진척이 보인다	문서는 나뉘었지만 완성된 화면은 보이지 않았다
검토가 끝나면 다음 단계로 간다	결정과 문서가 공유되지 않아 비슷한 작업으로 돌아왔다
세 AI가 하나의 팀처럼 움직인다	메인 역할과 공통 기준이 없어 충돌이 계속됐다

메인 역할과 하나의 기준 문서가 없었다

원인을 확인하면서 가장 먼저 보인 문제는 중심이 없다는 점이었다.

모든 AI에게 같은 작업을 맡겼고, 모두에게 서로를 검토하게 했다. 하지만 어느 AI가 최종 작업물을 관리할지 정하지 않았다. 한 모델에서 결정한 내용이 다른 모델의 문서에 바로 반영되지도 않았다.

그 결과 각 AI가 알고 있는 현재 상태가 조금씩 달라졌다. 이미 끝난 결정을 다시 제안하거나, 이전 문서와 다른 기준으로 새 문서를 만들기도 했다. 검토가 많아질수록 정확해질 것이라고 생각했지만, 동기화되지 않은 문서가 늘면서 오히려 충돌할 지점도 많아졌다.

문제를 정리하면 네 가지였다.

• 최종 결과를 책임질 메인 AI가 없었다.
• 결정과 변경 사항을 모아 둔 하나의 기준 문서가 없었다.
• 세 AI에게 같은 작업을 반복해서 맡겼다.
• 작업 완료를 확인할 화면이나 명확한 기준이 없었다.

여러 도구를 썼다는 사실 자체가 문제는 아니었다. 역할과 기준 없이 모두에게 같은 일을 시킨 방식이 문제였다.

약 2주간의 작업을 중단하기로 했다

비슷한 작업이 반복되자 점점 지쳤다. 무엇을 만들고 있는지 이해하기보다 다음 프롬프트를 전달하는 데 시간을 쓰고 있었다. 계속 진행하면 이미 쓴 시간이 아깝다는 이유로 같은 구조를 더 오래 유지하게 될 것 같았다.

그래서 약 2주간 진행한 개발을 중단하고 처음부터 다시 시작하기로 했다.

그렇다고 그동안 만든 모든 것을 버리고 싶지는 않았다. Claude Code를 메인으로 정하고, 2주간 만들어진 자료와 코드를 전체적으로 검토해 달라고 요청했다. 실제로 사용할 수 있는 기능 단위의 코드를 찾고, 다른 서비스를 만들 때도 활용할 수 있는 공통 부분은 따로 분류하도록 했다.

이 작업의 목적은 실패한 개발을 억지로 이어 붙이는 것이 아니었다. 다시 시작할 때 혼란까지 그대로 가져가지 않으면서, 재사용할 수 있는 부분만 남기는 것이었다.

다음 개발은 목업부터 시작하기로 했다

첫 시도에서 가장 답답했던 점은 내가 진행 상황을 눈으로 확인할 수 없다는 것이었다. 문서와 코드가 계속 생겨도 서비스가 어떤 모습으로 완성될지는 상상하기 어려웠다.

또 하나는 내가 알지 못하는 기술 결정을 계속 요청받았다는 점이다. 작은 단위로 나누면 모든 문제를 판단할 수 있을 것이라고 생각했지만, 질문의 범위가 작아져도 판단에 필요한 지식이 저절로 생기는 것은 아니었다.

다시 시작할 때에는 순서를 바꾸기로 했다. 먼저 화면 목업을 만들고, 내가 직접 보면서 서비스의 흐름과 완성될 모습을 확인한 뒤 개발을 시작하는 방식이다.

다음 시도에서는 이런 원칙을 적용하려 한다.

1. 먼저 목업을 만들어 눈으로 확인할 결과를 정한다.
2. 전체 작업을 관리할 메인 AI를 하나 정한다.
3. 다른 AI는 같은 작업을 다시 만드는 대신 필요한 검토만 맡는다.
4. 결정 사항은 하나의 기준 문서에 바로 반영한다.
5. 각 작업에는 완료 여부를 확인할 수 있는 결과물을 정한다.
6. 내가 이해하지 못한 기술 선택은 권장안만 고르지 않고 이유와 영향부터 확인한다.

처음 2주의 작업으로 완성된 서비스는 얻지 못했다. 대신 여러 AI를 많이 사용하는 것보다 역할과 기준을 분명하게 정하는 일이 먼저라는 것을 알게 됐다.

개발을 중단한 것은 20Springs를 포기한 일이 아니었다. 내가 확인할 수 있는 방식으로 다시 시작하기 위해 작업 방법을 바꾼 결정이었다. 다음 개발은 코드보다 목업에서 시작한다.

🖼 이미지 추천 3 — 다시 시작하는 개발 순서
제작 방식: 직접 제작 필요 · AI 생성 이미지 사용하지 않음
포함할 내용과 구성: 서비스 설명 → 화면 목업 → 사용자 확인 → 작은 개발 작업 → 화면에서 검증 → 다음 작업을 한 방향의 흐름으로 정리한다. 아래에는 메인 AI 1개·검토 AI는 필요할 때·기준 문서 1개를 원칙으로 표시한다.
권장 대체텍스트: 화면 목업을 먼저 만든 뒤 작은 개발 작업과 화면 검증을 반복하는 새로운 20Springs 개발 순서

20Springs 서비스

• 이전 글: 비개발자가 세 가지 AI 도구로 20Springs 개발을 시작한 방법
• 전체 목차: 20Springs

이 글은 개발 경험이 없는 상태에서 여러 AI 도구로 서비스를 만들며 겪은 개인적인 시행착오입니다. 결과는 작업 환경과 경험, 프로젝트 구조에 따라 달라질 수 있으며 특정 AI 도구의 성능을 평가하거나 일반화하려는 글은 아닙니다.