대규모 AI 보조 애플리케이션 구축을 위한 프롬프팅 전략은 무엇인가요?

무엇을 만들고 싶은지, 어떤 컴포넌트가 필요한지 파악해. 만약 힘들다면 Claude한테 도와달라고 하고 레드팀 테스트를 시켜봐.

스코프를 유지 못 하는 건 전적으로 네 문제임. CLAUDE.md는 이미 엄청난 비계(scaffolding)를 제공하고 있으니까.

재작업을 가장 많이 만드는 습관은 단연코 '코드를 작성하기 전에 아키텍처를 설명하고 AI에게 비판받는 단계'를 건너뛰는 거야. 왜냐하면 AI가 의문을 제기하지 않은 구조적 가정에 기반해 수천 줄의 코드를 짜고 나면, 나중에 모든 걸 리팩토링하거나 나중에 더 큰 문제로 번질 결정을 안고 살아야 하거든. 반면에 시작 전 한 시간 동안 아키텍처 리뷰를 하는 건 나중에 며칠씩 걸릴 골치 아픈 엉킴을 방지해 줌.

무엇을 만들고 싶은지 아이디어를 잡고 글로 써봐. 작동하게 만들기 위해 가장 중요한 기능부터 시작하고, 나중에 있으면 좋은 기능들을 덧붙이는 거야. 나는 3개월째 앱을 만들고 있는데 원래 의도했던 것과는 전혀 다른 모습이 됐음. 정확히 어떤 모습이어야 하는지 안다면 한 번에 프롬프팅할 수 있겠지만, 나는 기능별로 개발하는 걸 선호함. 그래야 빌드가 진행되면서 어떤 모습이어야 할지 알게 될 때까지 초기 단계에서 정신적으로 유연할 수 있거든...

다들 추천하는 프로젝트 메모 파일은 조용히 썩어감. 기능 6개 정도 만들고 나면, 첫 주에 없애버린 제약 사항이 여전히 남아있고 모델은 계속 그 죽은 제약 사항을 따르고 있음. 첫 프롬프트를 어떻게 구성하느냐보다 그 파일에서 뭘 쳐내느냐가 훨씬 중요함.

인수 기준(acceptance criteria)을 적어두기도 전에 코드부터 짜는 게 재작업을 유발하는 주범임. 모델이 5번째 턴에서 네이밍, 인터페이스 형태, 에러 핸들링 같은 마이크로한 결정들을 내려버리는데, 15번째 턴쯤 가면 그게 다 굳어져 버리거든. 도움이 됐던 습관은 아키텍처 문서를 모델이 결정을 내릴 때마다 업데이트하는 '살아있는 문서'로 취급하는 거임. 그래야 쌓인 컨텍스트랑 싸울 필요 없이 한곳에서 방향을 수정할 수 있으니까.

규모가 어떻든 간에, 작은 단위로 작동하게 만드는 게 핵심임. 가장 어려운 건 보통 그 작은 단위들을 다 합치는 통합 과정이지.

그리고 시스템의 참신함에 따라 다르기도 함. 만약 AI나 Claude가 이전에 본 적 없는 시스템이라면, 처음 보는 스택으로 바로 옮기기 전에 자기가 잘 아는 스택으로 먼저 POC를 해보게 해야 함.