작년에 처음 AI와 대화하며 코딩할 때는 질문이 아주 단순했다.
웹페이지 만들어줘.
화면에 달력 컴포넌트 만들어줘.
백엔드에 인증과 인가 만들어줘.
이렇게 말해도 AI는 꽤 그럴듯한 코드를 만들어줬다. 체감으로는 처음부터 80~90% 정도 완성된 것처럼 보일 때도 있었다.
처음에는 그게 신기했다. 직접 만들었다면 꽤 오래 걸렸을 기능이 몇 분 만에 화면에 나타났다.
“해줘”를 반복할수록 코드가 망가졌다
문제는 남은 10~20%를 고도화하기 시작하면서 생겼다.
이것도 추가해줘.
여기만 수정해줘.
아까 만든 코드에 이 기능도 넣어줘.
요청을 반복할수록 코드는 좋아지기보다 조금씩 이상해졌다. 앞에서 정한 구조와 뒤에서 추가한 기능이 충돌했고, 한쪽을 고치면 다른 쪽이 깨졌다. 처음에는 간단했던 코드가 어느 순간 왜 이렇게 됐는지 설명하기 어려운 상태가 되기도 했다.
AI가 코드를 못 만들어서라기보다, 내가 무엇을 만들고 있는지 충분히 합의하지 않은 채 계속 구현만 시키고 있었던 것 같다.
명세를 만들었는데도 대화는 그대로였다
이 문제를 해결하기 위해 여러 방법을 찾아봤다. 그중 하나가 SDD, 즉 Spec-Driven Development였다.
먼저 요구사항을 정리하고, 설계를 만들고, 작업을 나눈 다음 구현하는 방식이다. 팀이나 도구에 따라 PRD, TRD, 상세 기능 명세서, 요구사항 문서, 설계 문서처럼 이름과 형식은 조금씩 다르다.
AWS가 Kiro를 소개한 글에서도 비슷한 문제를 이야기한다. AI 에이전트로 작동하는 애플리케이션을 빠르게 만들 수는 있지만, 의사 결정이 문서화되지 않고 요구사항이 모호하면 프로덕션 수준으로 이어가기 어렵다는 것이다. Kiro는 이를 요구사항, 기술 설계, 구현 작업으로 연결한다.
나도 PRD와 TRD를 만들고 기능 명세를 정리하기 시작했다. 확실히 이전보다 나아졌다.
그런데 문득 이상한 점이 보였다.
문서는 자세해졌는데 AI와 대화하는 방식은 여전히 비슷했다.
이 PRD대로 만들어줘.
이 TRD를 보고 구현해줘.
이 기능 명세에 맞게 수정해줘.
문서가 생겼을 뿐, 나는 여전히 AI에게 바로 답을 요구하고 있었다.
PRD와 TRD가 있다고 해서 모든 결정이 끝난 것도 아니었다. 내가 빠뜨린 조건이 있을 수 있고, 서로 충돌하는 요구사항도 있을 수 있었다. 실제 코드베이스에는 문서에 적히지 않은 제약도 있었다.
그런데 “해줘”라고 말하는 순간, AI는 그런 빈칸을 질문하기보다 스스로 채우고 구현해버리는 경우가 많았다. 코드는 나왔지만 그 코드 안에는 내가 결정하지 않은 가정도 함께 들어 있었다.
이전에 Gemini CLI로 시작한 바이브 코딩 1년을 돌아보며 이제는 구현 속도보다 설계를 고민하게 됐다고 적었다. 질문하는 방식이 바뀐 것도 그 과정의 일부였다.
내가 질문을 모르면, 질문부터 부탁하기
그래서 질문하는 방식을 조금씩 바꿔봤다.
예전에는 이렇게 말했다.
웹페이지 만들어줘.
이제는 이렇게 묻기 시작했다.
이 웹페이지를 만들려면 어떻게 해야 할까?
먼저 현재 코드와 필요한 기능을 조사해줘.
빠진 요구사항이나 내가 결정해야 할 것이 있다면 구현하기 전에 물어봐줘.
차이는 문장 끝이 “해줘”에서 “어떻게 해야 할까”로 바뀐 것만은 아니었다. AI에게 바로 구현자의 역할을 주는 대신, 먼저 조사하고 질문하는 역할을 맡긴 것이었다.
내가 알고 있는 것만 자세히 설명하려고 하면 내가 모르는 것은 계속 빠진다. 반대로 AI에게 빈칸을 찾아달라고 하면 이야기가 달라진다.
누가 사용하는지, 기존 데이터와 호환되어야 하는지, 실패했을 때 어디로 돌아가야 하는지, 무엇을 기준으로 완료됐다고 판단할지 묻기 시작한다.
처음부터 내가 이 질문들을 모두 떠올릴 수 있었다면 직접 명세에 적었을 것이다. 하지만 실제로는 무엇을 질문해야 하는지조차 모를 때가 많았다.
그래서 질문을 질문하는 방식으로 바꿨다.
내가 놓치고 있는 질문은 무엇인가?
지금 결정하지 않으면 구현 중 문제가 될 내용은 무엇인가?
내가 답해야만 하는 질문부터 물어봐줘.
이렇게 했더니 결과물의 품질이 좋아졌다. AI가 무조건 정답을 내놓아서라기보다, 구현 전에 서로 다른 전제를 확인할 시간이 생겼기 때문인 것 같다.
Google Cloud의 프롬프트 작성 전략에서도 명확하고 구체적인 요청, 컨텍스트 추가, 프롬프트 구조화, 복잡한 작업의 분할과 반복을 별도의 전략으로 다룬다. Microsoft Learn의 프롬프트 엔지니어링 기술도 프롬프트가 단순한 명령 하나보다 여러 구성 요소와 반복을 필요로 할 수 있음을 보여준다.
내가 받아들인 것은 “완벽한 프롬프트 한 줄을 외워야 한다”는 이야기가 아니다. 오히려 반대에 가깝다.
한 번에 완벽하게 지시하려고 하지 말고, 모르는 부분을 드러내면서 대화를 통해 범위를 좁혀가는 것이다.
지금 바로 구현하지 말아줘.
먼저 현재 코드와 요구사항을 조사하고 다음 내용을 정리해줘.
1. 내가 만들려는 기능을 어떻게 이해했는지
2. 구현 전에 확인해야 할 기존 구조와 제약
3. 빠져 있거나 서로 충돌하는 요구사항
4. 가능한 접근 방법과 각각의 장단점
5. 내가 결정해야만 하는 내용
정보가 부족하면 추측해서 구현하지 말고 질문해줘.
질문에 대한 답이 모이면 구현 계획과 완료 기준을 먼저 제안해줘.
내가 계획을 확인한 뒤 구현을 시작하자.물론 이것만으로 모든 문제가 해결되는 것은 아니다.
AI가 불필요하게 많은 질문을 할 수도 있고, 그럴듯하지만 중요하지 않은 선택지를 늘어놓을 수도 있다. 질문을 받았다고 해서 사람이 검토하지 않아도 되는 것도 아니다.
테스트, 코드 리뷰, 변경 범위 확인, 완료 기준 같은 검증 과정은 여전히 필요하다. SDD 역시 문서를 한 번 만들고 끝내는 방식이라기보다, 구현하면서 드러난 내용을 다시 명세와 설계에 반영해야 의미가 있다.
그래도 “해줘”를 반복할 때보다는 훨씬 덜 헤맨다.
좋은 질문이란 내가 원하는 답을 정확하게 받아내는 문장이라고 생각했다.
그런데 요즘은 조금 다르게 생각한다.
좋은 질문은 정답을 이미 아는 사람이 쓰는 완벽한 명령문이 아니라, 내가 모르는 것이 무엇인지 함께 발견하기 위한 대화의 시작일지도 모르겠다.
내가 어떻게 질문해야 할지 모르겠다면, 그 질문부터 AI에게 물어보는 것.
일단 지금은 그 방식으로 대화하고 있다.
답글 남기기