AI에게 “앱을 만들라”고 계속 묻지 마세요
Source: Dev.to
“AI에게 앱을 만들라고 요청”하는 문제점
많은 사람들이 코드를 먼저 시작합니다. 채팅을 열고 반쯤 구상된 아이디어를 던진 뒤 MVP를 요청하죠. 모델은 폴더, 컴포넌트, 라우트, 심지어 인증까지 빠르게 반환합니다. 몇 분 동안은 진전이 있는 것처럼 보입니다.
그런데 현실이 찾아옵니다:
- 앱의 형태가 명확하지 않다.
- 기능 경계가 흐릿하다.
- 스택 선택이 우연에 맡겨진다.
- 각 후속 프롬프트가 프로젝트를 미묘하게 바꾼다.
세 번째 혹은 네 번째 라운드가 되면, 이제는 코드를 만드는 것이 아니라 가정을 계속해 주는 기계와 협상하고 있는 겁니다.
더 신뢰할 수 있는 워크플로우
내가 사용하는 워크플로우는 눈에 띄지는 않지만 훨씬 효과적입니다. AI가 코드를 건드리기 전에 매번 같은 순서를 강제합니다:
1. 아이디어 조사
- 누구를 위한 제품인지 정의한다.
- 버전 1이 해야 할 일을 명확히 한다.
- 무엇을 미룰 수 있는지 파악한다.
- 속도, 비용, 유지보수성에 맞는 스택을 선택한다.
2. 계획을 적어두기
제품 정의, 제약 조건, 고수준 아키텍처를 문서화한다. 이는 막연한 아이디어를 구체적인 목표로 바꾸고 AI에게 명확한 경계를 제공한다.
3. 작업을 단계별로 나누기
탄탄한 계획이 있으면 AI는 현재 단계에 집중해 코드를 조각조각 생성할 수 있어, 무작위 기능으로 흐트러지지 않는다.
4. 출력물 검토하기
AI가 만든 결과물을 검토해야 하지만, 이제는 계획 기반 구현을 검토하는 것이며, 혼란스러운 코드베이스를 해독하려 애쓰는 것이 아니다.
왜 이렇게 하면 좋은가
컨텍스트 소멸 최소화
AI 세션은 이전 결정을 잊고, 삭제된 요소를 다시 도입하거나 전체 프로젝트 컨텍스트를 무시하는 경향이 있다. 중요한 사고를 프로젝트 문서에 보관함으로써 다음을 할 수 있다:
- 도구를 바꾸거나 새 세션을 시작해도 컨텍스트를 잃지 않는다.
- 모델의 단기 컨텍스트 밖에 지속적인 메모리를 유지한다.
대화보다 산출물이 중요
채팅은 빠르기 때문에 생산적으로 느껴지지만, 문서, 제약 조건, 명시적 지시가 프로젝트가 엉망이 되는 것을 막는다.
초보자에게 주는 이점
신입 개발자는 생성된 양을 모멘텀으로 착각하기 쉽다. 파일이 가득한 저장소는 진행처럼 보이지만, 사실 “마케팅이 더 좋은 자동완성”일 뿐이다. 연구 → 범위 → 설계 → AI에게 조각별로 빌드하도록 넘기는 간단한 구조는 이러한 착각을 방지한다.
요약
AI를 사용해 사이드 프로젝트를 만들 때, 기계가 당신의 사고를 이어받게 하고, 당신이 사고를 제공하도록 하라. 눈에 띄게 화려하지는 않지만, 결과물은 다음 주에도 여전히 작업할 수 있는 형태가 된다.