잘못된 프롬프트로 시간을 낭비하지 마세요: AI로부터 결과를 얻어내기 위한 개발자 가이드

Claude에게 코드를 리팩터링(Refactor)해달라고 요청했는데 쓰레기 같은 결과만 돌아오고 있나요? ChatGPT에 같은 문제를 세 번이나 다른 문구로 붙여넣고 있지는 않나요? 처음 두 번의 시도가 목표를 벗어났기 때문이죠. 팀원들은 AI 도구를 사용하고 있지만, 실제로 아무도 더 빨라지지 않고 있습니다.

문제는 AI가 아닙니다. 바로 당신의 프롬프트(Prompt)입니다.

진짜 문제: 당신이 충분히 구체적인 인간이 되지 못하고 있다는 것

AI 도구는 매우 똑똑한 인턴과 같습니다. 당신이 요청한 것을 정확히 수행할 것입니다. 하지만 오직 당신이 명확하게 요청했을 때만 말이죠. 대부분의 개발자들은 어머니에게 문자를 보내는 것처럼 프롬프트를 작성합니다. 모호하고, 맥락(Context)이 부족하며, AI가 그냥 '알아서 알아듣기를' 바랍니다.

나쁜 프롬프트: "이 코드 수정해줘"
더 나은 프롬프트: "이 JavaScript 함수는 엔드포인트(Endpoint)가 느려질 때 5초 후에 타임아웃(Timeout)이 발생하는 API 호출을 수행합니다. 에러를 발생시키기 전에 지수 백오프(Exponential backoff)를 사용하여 최대 3번까지 재시도하도록 수정해야 합니다. 현재 코드는 다음과 같습니다: [code]"

두 번째 프롬프트가 작동하는 이유는 AI에게 무엇이 고장 났는지, 왜 중요한지, 그리고 _성공적인 결과가 어떤 모습인지_를 알려주기 때문입니다. 더 길어진 것이 아니라, 단지 정밀해진 것입니다.

실제로 효과가 있는 세 가지 규칙

1. 작업을 요청하기 전에 맥락(Context)을 제공하세요

도움을 요청하기 전에 문제를 설정하세요. 무엇을 만들고 있나요? 무엇을 위한 것인가요? 이미 시도해 보았지만 효과가 없었던 것은 무엇인가요?

서버 간의 설정 파일(Config files)을 동기화하기 위한 CLI 도구를 만들고 있습니다.
현재는 셸 스크립트(Shell scripts)를 사용하고 있지만, 취약하고 테스트하기 어렵습니다.
더 나은 에러 핸들링(Error handling)과 크로스 플랫폼(Cross-platform) 지원을 위해 Go로 전환하고 싶습니다.
...

이것은 단 6문장입니다. 당신은 방금 30분의 질의응답 시간을 절약했습니다.

2. 형식(Format)과 제약 사항(Constraints)을 명시하세요

AI가 당신에게 "도움"이 무엇을 의미하는지 추측하게 두지 마세요. 직접 말해줘야 합니다.

"스크립트가 아닌 재사용 가능한 함수(Reusable function)로 작성해줘"
"100줄 이내로 유지해줘"
"Node 18+ 환경이라고 가정해줘"
"디버깅이 가능하게 만들어줘 — 주요 지점에 로깅(Logging)을 추가해줘"
"테스트 코드도 작성해줘"

이것이 없다면, 코드가 맞을 수는 있어도 실제 워크플로우(Workflow)에는 쓸모없는 코드를 받게 될 것입니다.

3. 중요할 때는 예시를 보여주세요

특정한 스타일이나 패턴을 원한다면, 그것을 보여주세요:

React 컴포넌트에 대한 테스트를 작성하고 있습니다. 이 프로젝트에서 제가 다른 테스트들을 구성하는 방식의 예시입니다:

...

패턴 매칭 (Pattern matching)은 AI가 정말 잘하는 분야입니다. 이를 활용하세요.

실제 사례: 쓰레기에서 황금으로

엉망인 프롬프트: "데이터베이스 쿼리를 어떻게 하면 더 빠르게 만들 수 있나요?"

더 나은 프롬프트:

"users 테이블(50만 행)과 purchases 테이블(200만 행)이 있는 PostgreSQL 데이터베이스를 사용 중입니다.
사용자의 구매 내역을 보여주는 쿼리가 3~4초 정도 걸립니다.

현재 쿼리:

SELECT * FROM purchases WHERE user_id = \$1 ORDER BY created_at DESC;

이미 user_id에 인덱스 (index)를 생성했습니다. 그 외에 무엇을 시도해 볼 수 있을까요? 또한, 저는 생 SQL (raw SQL)이 아닌 TypeORM을 사용하고 있습니다."

짜잔. 이제 AI는 당신의 제약 조건 (PostgreSQL, TypeORM), 규모 (200만 행), 그리고 이미 시도해 본 것 (인덱싱)을 알고 있기 때문에 실제로 도움을 줄 수 있습니다.

이를 더 쉽게 만들어주는 도구들

Claude (웹 또는 API) - 시간이 지남에 따라 문맥 (context)을 쌓아가는 긴 대화에 가장 적합합니다.
GitHub Copilot - 에디터 내에서 빠른 코드 스니펫 (code snippets)을 작성할 때 좋습니다. 대규모 리팩터링 (refactor)에는 어려움을 겪습니다.
Cursor - 코드베이스의 문맥을 파악하는 IDE입니다. 본격적인 작업을 하고 있다면 사용할 가치가 있습니다.
Perplexity - 조사나 "X의 최신 소식은 무엇인가요?"와 같은 질문에 더 적합합니다.

이것저것 옮겨 다니는 대신, 하나를 선택해서 그것을 사용하는 법을 실제로 _학습_하세요.

효과적인 워크플로우 (Workflow)

먼저 나쁜 프롬프트를 작성하세요 - 너무 깊게 생각하지 말고 질문을 밖으로 꺼내세요.
문맥 (context)을 추가하세요 - 실제 시나리오, 실제 수치, 그리고 이미 시도해 본 것들을 포함하세요.
성공적인 결과가 어떤 모습인지 명시하세요 - 형식, 제약 조건, 예시를 포함하세요.
구체적으로 후속 질문을 하세요 - "너무 복잡합니다" 또는 "이 엣지 케이스 (edge case)를 처리해야 합니다"와 같이 말이죠.

이것이 전부입니다. 대부분의 개발자는 2~3단계를 건너뛰고 나서 AI를 탓합니다.

한 가지 더

"쉬운 일에는 그냥 AI를 쓸게요"라는 말은 그만두세요. 쉬운 일에는 AI가 필요 없습니다. 실제로 어려운 일들, 즉 아키텍처 결정 (architecture decisions), 리팩터링 (refactoring), 테스트 커버리지 (test coverage), 새로운 프레임워크 이해하기, 보안 검토 (security review) 등에 AI를 사용하세요. 바로 그런 부분에서 AI가 당신의 시간을 실질적으로 아껴줄 것입니다.

여러분이 겪은 가장 큰 프롬프트 실패 사례는 무엇인가요? 댓글로 남겨주세요. 무엇이 사람들을 가장 힘들게 하는지 정말 궁금합니다.