tl;dr

1. AI는 계획이 필요하다. 계획이 있고 없고는 중요한 차이가 있다.
2. 그러나 계획은 반드시 검토해야 한다. 아니면 오버엔지니어링 문제를 일으킬 수 있다.
3. 그런데 계획이 너무나 장황해서 인내심을 바닥낸다. 그럴 때에는 PLAN을 생성할 때 글자수를 제약하도록 하자.
4. AI로 개발을 시켜도 여전히 사람의 지식은 유효하다.

AI는 계획의 고수가 아니라 계획 통과의 고수라고 할 수 있다. 왜냐하면 계획을 보고 싶지 않게 만들어 덮어놓고 통과되는 계획을 만들기 때문이다.

그러나 계획은 언제나 필요하다. 계획이 있고 없고의 산출물의 차이는 크다. 하지만 계획을 검토하지 않으면 오버엔지니어링(overengineering)된 결과물을 만들어 낼 수 있다.

계획은 필요하다

아주 단순하게 PLAN.md가 어떤 차이를 만드는지 실험해보자. 같은 요구사항을 준비하고, 한 쪽에는 PLAN.md 문서를 먼저 쓰게 하고, 그 문서를 토대로 구현하게 한다. 다른 한 쪽에는 그냥 요구사항을 던지고 ’구현해’라고 말한다. 두 경우 모두 아키텍처에 대해서는 명세를 넣지 않는다.

내가 이것을 실험했을 때에는, 한 쪽은 파일 하나에 모든 것을 쑤셔넣은 결과물을 낳았고 다른 한 쪽은 그럴듯해 보이는 구조를 가진 결과물을 낳았다. 예상했듯이 후자가 PLAN.md를 통한 결과물이다.

후술할 오버엔지니어링이 언제 발생하는지 보기 위해서 한 가지 간단한 실험을 한 적이 있다. 두 프로젝트 a,b가 같은 기능 A,B,C,D를 구현한다. 이때 한 쪽은 4개 기능을 한 개의 프롬프트로 제공하고 다른 한 쪽은 4개로 나눠서 제공한다. 결과적으로 얼마나 오버엔지니어링이 일어났는지 실험한다. 나는 전자가 후자보다 오버엔지니어링이 더 일어날 것이라고 가설을 세웠다.

결과는 두 경우 모두 형편 없었다. 두 경우 모두 겨우 몇 개에 파일에 모든 작업물을 쑤셔 넣었고, 계층 분리나 책임 분리와 같은 개념은 전혀 찾아볼 수 없었다. 프롬프트를 몇 번 나눠서 넣는가보다는 계획이 있는지 없는지가 더 중요했던 것이다.

그러나 너무 울창하다

그러나 겉보기에는 그럴듯해 보여도, 속은 그렇지 않을 수 있다. 오버엔지니어링은 바로 그런 경우이다. 오버엔지니어링을 한 문장으로 정의하자면 “지금 있지도 않은 상황을 고려해서 공연히 복잡한 결과물을 낳는 행동”이라고 할 수 있다.

AI는 오버엔지니어링된 결과를 낳는 계획을 짤 때가 굉장히 많다. 더 큰 문제는 계획을 읽기 힘든 언어로 장황하게(verbose) 기술해서 읽으려는 의지를 바닥낸다는 것이다.

grill-me와 같은 스킬을 사용해서 요구사항을 명확히 하더라도, 오버엔지니어링의 문제는 피해갈 수 없다. 요구사항을 명확히 하는 것과 그 구조를 어떻게 짜는지를 정하는 것은 다른 일이기 때문이다.

가지치기를 해야 한다

그렇기 때문에 PLAN.md의 내용을 검토하는 과정이 필요하다. 그러나 검토하는 과정은 우리의 인내심을 시험한다. 일단은 이렇게 해 보자. PLAN.md의 글자 수를 제한하는 것이다.

간단하게 실험을 해봤다. 다음과 같은 프롬프트를 주고, PLAN.md의 점수를 상대평가 해보았다. (실험 표본이 적은 점은 미리 고지를 해야겠다.)

{{PROMPT}}

# 기능
- 사용자가 이메일과 비밀번호로 회원가입하고 로그인할 수 있는 기능. 사용자는 여러 조직에 속할 수 있고, 각 조직에서 owner, admin, member 중 하나의 역할을 가진다. 사용자는 조직을 생성하고 다른 사용자를 이메일로 초대할 수 있다.
- 조직에 속한 사용자가 프로젝트를 생성할 수 있는 기능. 프로젝트는 이름, 설명, 상태를 가진다. owner와 admin은 모든 프로젝트를 수정하거나 삭제할 수 있고, member는 자신이 생성한 프로젝트만 수정할 수 있다.
- 사용자가 프로젝트 안에 작업을 생성할 수 있는 기능. 작업은 제목, 설명, 담당자, 상태, 우선순위, 마감일을 가진다. 작업의 상태는 todo, in_progress, done 중 하나이며 변경 이력을 확인할 수 있어야 한다.
- 프로젝트에서 발생한 주요 활동을 확인할 수 있는 기능. 프로젝트 생성, 작업 생성, 담당자 변경, 상태 변경을 활동 내역에 기록한다. 자신에게 작업이 할당되면 애플리케이션 내 알림을 받을 수 있고, 읽음 처리할 수 있다.

	프롬프트	글자 수	가독성 점수 (1-10)	충실성 점수 (1-10)	적정 설계 점수 (1-10)	총점
A	PLAN.md를 작성해라.	13,371	4	10	5	19
B	PLAN.md를 5000자 이내로 작성해라.	4,373	7	9	9	25
C	PLAN.md를 2500자 이내로 작성해라.	2,219	10	7	10	27
D	PLAN.md를 1000자 이내로 작성해라.	940	10	4	10	24
E	PLAN.md를 13,000자 이내로 작성해라.	7,963	5	10	5	20

AI에게 블라인드 테스트를 시켜보기도 했는데, 매긴 순위는 B> C=D > E > A로 비슷한 경향을 보였다. 이 실험에서 특이한 점은 글자 수 제약이 없는 A가 13,371자를 작성했기 때문에 E에서 13,000자를 매긴 것인데, 생성된 PLAN.md의 글자 수는 그에 턱없이 부족한 7,963자였다. 글자 수를 제약하는 것 자체가 AI의 장황함을 줄일 수 있음을 알려주는 결과이다.

위의 실험에서는 C가 A보다 6배 간결한 문서임에도 불구하고 총점은 가장 높았다. 따라서 PLAN.md에 적절한 글자수 제약을 거는 것은 문서의 가독성과 품질을 향상시킬 수 있다.

위 실험 결과와 별개로 사람이 검토하는 일은 반드시 필요하다. 그리고 검토하는 사람은 YAGNI라는 개념을 알고 있어야 한다. 귀찮아서 코드도 안 보는 사람이라면 이것이 되돌릴 수 있는 마지막 기회라고 생각해야 할 것이다.

YAGNI는 You Ain’t Gonna Need It의 줄임말이다. 즉, “너는 그것이 필요하지 않아”라는 뜻으로 오버엔지니어링을 경계하는 익스트림 프로그래밍의 원칙이다.

결론: 여전히 공부해야 한다

AI는 정말 놀랍다. 다만 그 놀라운 결과물이 AI 혼자서 만들어 내는 것이 아니라는 점을 알아야 한다. 프롬프트를 입력하는 사람이 없으면 AI는 아무것도 하지 않는다. 그리고 그 프롬프트가 AI의 산출물에 큰 영향을 끼친다는 것은 이 글이 짚은 주요한 지점이 될 것이다.

그렇다면 좋은 소프트웨어를 만들기 위해서는 소프트웨어를 설계하는 법을 공부해야 한다는 원칙은 아직 유효하다. 너무 많은 것을 AI에게 맡겨서는 안 된다.

끝으로, “나 혼자 쓸 프로젝트인데 대충 해도 되지 않느냐”라고 한다면 오산이다. 미래의 자신이 디버깅하며 고통받는 모습을 상상해보자.