결론부터 말하자면, AI 주도 개발 (AI-driven development)의 워크플로 설계에서 가장 먼저 결정해야 할 것은 '사용할 도구'도 '프롬프트 작성법'도 아닌, 어느 공정에서 AI를 멈추고 인간이 판정할 것인가입니다. 완전 자동인지 수동인지의 이분법으로만 생각한다면 설계는 끝나지 않습니다.

대상은 개인~소규모 인원이 Web 서비스를 만드는 것을 전제로 합니다. Claude Code와 같은 에이전트형 코딩 도구를 사용하여, 사양 책정부터 배포까지 혼자서 진행하는 케이스를 상정하고 있습니다. 팀 개발의 리뷰 체계가 갖춰진 환경이라면 이야기는 달라집니다.

「멈추는 지점」을 정하지 않으면 어떤 일이 벌어지는가

AI가 실수하는 것은 전제 조건이며, 문제는 자신이 정답 여부를 판정할 수 없는 영역에서 AI를 사용해 버리는 것입니다. 이 판정 가능성이 곧 멈추는 지점의 설계 기준이 됩니다.

실제로 Sitemora라는 자신의 서비스를 만들기 시작했을 때, LLM과 대화하며 하루 만에 구성을 마칠 수 있었습니다. 속도는 예상 이상이었지만, 빠른 것과 옳은 것은 별개입니다. 구성을 하루 만에 할 수 있다는 것은, 잘못된 구성도 하루 만에 할 수 있다는 뜻이기도 합니다. 판정을 거치지 않고 앞으로 나아가면, 오류와 함께 고속으로 쌓여가게 됩니다.

멈추는 지점의 설계는 공정마다 "인간이 검증할 수 있는가"를 묻는 것만으로 거의 결정됩니다.

공정별 위임 레벨 표

제가 실제로 사용하고 있는 구분입니다. 3단계로 나누었습니다.

표의 요점은, "테스트가 판정자가 되는 공정"은 AI에게 맡겨도 괜찮고, "인간만이 판정자가 될 수 있는 공정"에서 멈춘다는 하나의 기준입니다. 도구의 성능으로 선을 긋지 않은 것이 포인트이며, 모델이 똑똑해져도 이 선은 움직이지 않습니다. 요구사항 정의는 모델이 똑똑해졌다고 해서 AI에게 위임할 수 있게 되는 것이 아니기 때문입니다.

검토했으나 선택하지 않은 설계

안 A: 모든 공정에 승인 프롬프트를 삽입한다

처음에 시도했던 방식입니다. 파일 편집을 할 때마다 확인을 요청하도록 설정하면 위험한 조작은 모두 막을 수 있다는 발상이었습니다.

기각 이유는, 인간이 익숙해져서 대충 훑어보기 때문입니다. 10번 연속으로 Yes를 누른 후의 11번째를 사람은 읽지 않습니다. 승인 횟수가 늘어날수록 승인의 질은 떨어집니다. 멈추는 지점이 적을수록 한 번당 주의력은 집중됩니다.

안 B: 풀 오토(Full-auto)로 돌리고 결과만 확인한다

반대로, 전부 맡기고 마지막에 결과물만 확인하는 방식도 검토했습니다. 속도는 최대화됩니다.

기각 이유는, 설계의 오류가 마지막까지 드러나지 않기 때문입니다. 구현이 동작하는지 여부는 마지막에 보면 알 수 있지만, 설계가 틀렸다는 것은 동작하고 있어도 알 수 없습니다. 설계만큼은 구현이 진행되기 전에 확인해야 합니다. 역으로 말하면, 설계만 승인해 버린다면 구현 공정을 들여다볼 가치는 낮다는 판단이기도 합니다.

안 C: 도구를 하나로 압축하여 설정을 통일한다

이것도 검토했지만 선택하지 않았습니다. 용도에 따라 나누어야 한다고 생각하기 때문입니다. 하나로 압축하면 그 도구의 약점까지 모두 떠안게 됩니다. 설계 브레인스토밍에 적합한 모델과, 대량의 파일 편집을 묵묵히 수행하는 도구는 별개이며, 통일의 편의성보다 약점 집중 리스크가 더 크다고 판단했습니다.

멈추는 공정의 플로

빨간색으로 표시한 3곳만이 인간의 정지점입니다. 그 외에는 루프 안에서 AI와 테스트가 돌아갑니다. 정지점을 3개로 압축한 이유는, 이 이상 늘리면 안 A와 같은 '대충 훑어보기' 현상이 발생하기 때문입니다.

불가역점은 배포가 아니라 설계에 있다

이 부분이 가장 전달하고 싶은 내용입니다. 위험한 공정은 배포라고 생각하기 쉽지만, 실무에서 되돌릴 수 없게 되는 것은 설계입니다.

Sitemora 개발 중, 크롤링할 수 없는 사이트가 20개 중 1개 정도의 비율로 나타났습니다. 이는 구현의 버그가 아니라, 어떤 사이트를 수집 대상으로 할 것인가라는 설계의 문제였습니다. 구현이 진행된 후에 이런 문제를 깨달으면 수정 범위가 구현 전체로 넓어집니다. 배포는 롤백(Rollback)할 수 있지만, 설계의 전제가 틀렸을 경우 되돌려야 하는 범위는 작성한 코드 전부입니다.

그러므로 승인을 거친다면 설계 단계여야 합니다. 구현의 한 줄 한 줄을 확인할 시간이 있다면, 설계안을 읽는 시간으로 돌리는 것이 복구 속도가 더 빠릅니다.

문서의 역할이 변하고 있다

이 설계를 돌리기 위해 문서 작성 방식도 바꾸었습니다. 인간이 읽기 위해서가 아니라, AI에게 문맥(Context)을 전달하기 위해 쓰고 있습니다.

요건과 설계의 판단 이유를 파일에 남겨두면, 다음 세션에서 AI가 그 부분부터 읽기 시작합니다. 반대로 이것을 작성해두지 않으면, 매번 구두로 전제 조건을 다시 설명해야 하며, 설명의 흔들림이 곧 구현의 흔들림으로 이어집니다. 멈추는 지점(Stop point)을 줄일 수 있느냐는 전달된 문맥(Context)의 양에 의해 결정됩니다.

프롬프트(Prompt) 작성법을 고안하는 이야기는 이러한 문맥 설계 앞에서는 거의 효과가 없습니다. 전문 기술로서 남는 것은 기발한 표현 방식이 아니라, 무엇을 시키고 싶은지를 언어화하는 능력이라고 생각합니다. 모델이 똑똑해질수록 전자는 필요 없게 됩니다.

다음에 결정할 것

멈추는 지점을 3개로 좁힌 단계까지는 확정되었지만, 아직 답이 나오지 않은 것은 "되돌리기(差し戻し, Rollback) 횟수에 상한을 둘 것인가"입니다. 설계안이 2번, 3번 되돌려질 때, 그것은 AI의 출력이 나쁜 것이 아니라 요건의 언어화가 부족할 가능성이 높습니다. 몇 번 만에 요건 공정으로 돌아가야 하는지에 대한 기준은 아직 경험칙의 범위를 벗어나지 못했습니다.

이를 결정하기 위해서는 자신의 프로젝트에서 되돌리기 횟수를 기록하는 수밖에 없다고 생각합니다. 기사 100개를 읽는 것보다, 한 번 직접 움직여서 세어보는 것이 더 빠른 부분입니다.

출처

Discussion