프롬프트 엔지니어링

AI 모델에서 원하는 결과를 안정적으로 얻기 위해 입력 텍스트를 체계적으로 설계하는 기술. 같은 모델이라도 프롬프트를 어떻게 짜느냐에 따라 결과가 크게 달라진다.

왜 프롬프트를 설계하는가

같은 모델에게 같은 질문을 던져도, 어떻게 묻느냐에 따라 결과의 품질이 크게 달라진다. 그냥 "요약해줘"라고 하면 두루뭉술한 답이 나오지만, 누구에게 보여줄 요약인지, 몇 문장으로, 어떤 톤으로 써야 하는지를 알려주면 훨씬 쓸 만한 답이 나온다. 모델은 우리 머릿속을 읽지 못하기 때문에, 원하는 결과를 안정적으로 얻으려면 그 조건을 말로 정확히 풀어줘야 한다. 이렇게 입력을 다듬는 요령을 몇 가지 반복되는 패턴으로 정리한 것이 프롬프트 엔지니어링이다.

실제로 어떻게 쓰나

가장 기본은 역할과 맥락을 먼저 정해주는 것이다. "너는 꼼꼼한 코드 리뷰어야"처럼 역할을 부여하면 모델이 그 관점에서 답을 만든다. 여기에 원하는 출력의 예시를 두세 개 보여주는 방식을 흔히 쓴다. 정답 형식을 직접 보여주면 모델이 그 패턴을 따라 하기 때문에, 말로 규칙을 길게 설명하는 것보다 훨씬 잘 통한다.

복잡한 추론이 필요할 때는 "단계별로 생각해봐"라고 덧붙여 중간 사고 과정을 펼치게 한다. 곧장 답부터 내면 틀리던 문제도, 풀이 과정을 거치게 하면 정답률이 올라간다. 개발 현장에서는 이런 지시를 매번 손으로 입력하지 않고 프로젝트 규칙 파일에 적어둔다. 예를 들어 Claude Code에서는 CLAUDE.md에 "커밋 메시지는 한국어로", "테스트 없이 PR 올리지 마" 같은 규칙을 써두면, 에이전트가 매 작업마다 그 지시를 반영해 행동한다. 프롬프트가 일회성 질문을 넘어 도구의 기본 성격을 정하는 설정이 되는 셈이다.

알아둘 점

예시가 항상 도움이 되는 건 아니다. 스스로 추론을 잘하는 최신 모델에게 풀이 예시를 주면, 오히려 그 예시의 방식을 그대로 베끼느라 제 실력을 못 내는 경우가 있다. 그래서 요즘은 예시를 얼마나, 언제 넣을지 자체가 판단거리다.

더 큰 흐름의 변화도 있다. 에이전트가 여러 단계를 거쳐 스스로 도구를 쓰고 파일을 읽는 시대가 되면서, 질문 한 줄을 잘 다듬는 것보다 모델이 매 순간 어떤 정보를 보게 할지를 설계하는 일이 중요해졌다. 이렇게 모델에게 주어지는 맥락 전체를 관리하는 접근을 맥락 엔지니어링이라 부르며, 프롬프트 엔지니어링을 감싸는 더 넓은 개념으로 자리 잡는 중이다.