프롬프트를 줄였더니 결과가 나아졌다 — 최신 AI 모델 활용법 3단계

한줄 요약

제약 프롬프트를 걷어내고 맥락을 주면, AI는 더 잘 움직인다.

최신 고성능 AI 모델을 제대로 쓰려면 프롬프트 작성 방식 자체를 바꿔야 한다. 우리 팀이 외주 개발 프로젝트에 AI를 붙여보면서 가장 크게 바뀐 건 "하지 마라"는 지시를 줄이고, 배경과 맥락을 주는 쪽으로 방향을 튼 것이었다. 결과는 꽤 달랐다.

모델이 못 하는 게 아니라, 우리가 막고 있는 거다

AI 모델은 설계된 게 아니라 학습으로 길러진 시스템이다. 그 말은 곧, 성능의 상한선이 모델 자체가 아니라 우리가 씌운 프롬프트에 의해 결정된다는 뜻이기도 하다.

"이건 하지 마", "저건 빼", "반드시 이 형식으로만" 같은 제약 목록이 늘어날수록 모델이 보여줄 수 있는 창의성과 판단력은 좁아진다. 특히 최근 세대 모델일수록 짧고 맥락 중심적인 프롬프트에서 더 잘 작동하는 경향이 있다.

실제로 우리 팀은 클라이언트 프로젝트에 쓰는 내부 시스템 프롬프트에서 금지 조항 목록을 대폭 줄였다. 처음엔 불안했지만 결과물의 품질은 오히려 올라갔다. 모델이 우리가 생각한 예시보다 더 나은 선택을 하는 경우가 생겼다.

구현 전: 모르는 걸 먼저 털어야 한다

AI를 쓰면서 가장 많은 비용이 낭비되는 구간은 "한참 진행한 뒤에 방향이 틀렸다는 걸 아는 순간"이다. 외주 개발도 마찬가지다. 스펙을 그대로 넘기는 것보다, 먼저 내가 모르는 걸 찾아내는 과정이 필요하다.

실무에서 유용하게 쓰는 방식은 세 가지다.

블라인드 스팟 먼저 찾기. 모르는 걸 모를 때 쓴다. "이 코드베이스에서 내가 놓치고 있는 전제나 위험 요소가 뭔지 짚어줘"처럼, AI에게 내 사각지대를 먼저 물어보는 것이다. 익숙하지 않은 레거시 시스템이나 처음 다루는 도메인에서 특히 효과적이다.

역인터뷰 방식. "나한테 한 번에 질문 하나씩 해줘. 아키텍처 결정에 영향을 미칠 질문을 먼저"라고 시키면, AI가 나를 인터뷰하면서 내 머릿속에 있던 막연한 요구사항을 구체화해준다. 기획 미팅 전에 혼자 이걸 한 번 돌려보면 클라이언트와의 커뮤니케이션도 훨씬 명확해진다.

스펙 대신 레퍼런스 던지기. 말로 설명하기 어려운 동작 방식이나 UI는 스펙 문서보다 실제 코드 샘플이나 화면 목업 하나가 훨씬 정확하게 전달된다. 언어가 달라도 괜찮다. "이 Python 코드와 같은 방식으로 TypeScript에서 구현해줘"처럼 쓰면 된다.

구현 중: 결정을 기록하게 해야 나중에 설명할 수 있다

AI가 긴 작업을 혼자 진행하다 보면 중간에 판단이 필요한 갈림길을 만난다. 그 결정들이 쌓여서 최종 결과물을 만드는데, 나중에 결과만 보면 왜 그렇게 됐는지 파악이 안 된다.

클라이언트에게 결과물을 설명하거나 팀원에게 인계할 때 이 부분이 발목을 잡는다. 특히 외주 개발 환경에서는 코드보다 맥락이 더 중요할 때가 많다.

해결책은 단순하다. 작업 지시에 이 한 줄을 붙이는 것이다.

"내 지시에 없는 판단을 내려야 하는 상황이 생기면, 보수적인 방향을 선택하고 진행해. 어디서 어떤 결정을 왜 했는지는 별도 파일에 로그로 남겨줘."

이 로그 파일은 단순한 기록이 아니다. 프로젝트가 끝난 후에도 팀의 지식 자산으로 남는다. 같은 패턴의 프로젝트를 다음에 할 때 초기 셋업 시간을 크게 줄여준다.

구현 후: 퀴즈를 통과해야 머지한다

AI가 만들어준 결과물을 그대로 납품하거나 배포하면 안 된다. 담당자가 그 변경 사항을 직접 설명하지 못하면, 유지보수 단계에서 반드시 문제가 생긴다.

우리 팀이 쓰는 방식은 이렇다.

"이번 작업 내용을 내가 이해할 수 있게 요약해줘. 왜 이 방식을 택했는지, 어떤 트레이드오프가 있었는지 포함해서. 맨 아래엔 이 변경에 대한 확인 퀴즈도 붙여줘."

퀴즈를 통과하지 못하면 그 코드는 아직 내 코드가 아니다. 빠르게 만드는 것과, 그걸 책임지고 설명할 수 있는 것은 다른 문제다. AI 시대에 개발자와 개발사의 가치는 후자에서 나온다.