Anthropic Academy AI Fluency 사내 기술세션 [3]

개요#

세션에서 가장 재밌었던 건 같은 기능 소개 문구를 프롬프트만 바꿔서 여러 번 돌려본 부분이었다.

처음에는 그냥 "자연어 검색 기능 소개 문구를 작성해줘" 정도로 넣었는데, 결과가 너무 범용적이었다. 틀린 건 아닌데 그렇다고 실제 서비스에 바로 붙이기엔 좀 애매한 문장들이 나왔다.

반대로 대상 사용자, 말투, 분량, 예시까지 넣어주니 결과가 갑자기 훨씬 쓸 만해졌다. 결국 모델이 달라진 게 아니라, AI가 추측해야 하는 부분을 얼마나 줄였느냐의 차이였다. 이번 글은 그때 효과가 컸던 방식들만 중심으로 정리해보려고 한다.

프롬프트 엔지니어링이란#

프롬프트 엔지니어링을 막 엄청 특별한 기술처럼 보지는 않았습니다. 오히려 사람끼리도 애매하게 말하면 애매한 답이 오고, 명확하게 말하면 명확한 답이 온다는 아주 기본적인 얘기에서 시작합니다.

개발로 치면 더 익숙합니다. API 스펙을 대충 던지면 프론트와 백이 따로 놀고, 스펙이 선명하면 한 번에 맞아떨어집니다. 프롬프트도 결국 AI에게 보내는 요청이라는 점에서는 비슷했습니다.

강의 자료에서도 Before/After 예시를 꽤 많이 보여줬는데, 그게 직관적이어서 이번 글도 예시 위주로 정리해보려고 합니다. Anthropic의 공식 프롬프팅 가이드도 같이 참고했습니다.

Before/After: 한 줄 프롬프트 vs 기법 적용 프롬프트#

6가지 기법을 설명하기 전에, 실제 차이부터 보겠습니다.

Before — 한 줄 프롬프트의 결과:

After — 6가지 기법을 적용한 프롬프트의 결과:

같은 모델인데도 이 정도 차이가 났습니다. 결국 바뀐 건 모델이 아니라, 내가 AI한테 넘긴 정보량과 방식이었습니다. 그래서 이 차이를 만든 요소들을 6가지 기법으로 나눠서 보려고 합니다.

6가지 기법#

1. 맥락을 줘라 (Give Context)#

[Before]
기후변화에 대해 알려줘.

[After]
열대 지역 농업에 기후변화가 미치는 주요 영향 3가지를
최근 10년 사례와 함께 설명해줘.

범위, 대상, 시간, 목적 같은 맥락을 구체적으로 넣으면 원하는 답에 가까워집니다. 당연한 얘기 같지만, 실제로 프롬프트를 쓸 때 "알아서 해주겠지" 하고 빼먹는 경우가 많습니다.

세션에서 역으로 실험해봤습니다. 공통 과제 프롬프트에서 "맥락"에 해당하는 부분을 전부 지우고 "기능 소개 문구를 써줘"만 남겼더니, AI가 아예 다른 제품의 기능을 소개하는 문구를 내놨습니다. 맥락이 없으면 AI는 추측할 수밖에 없고, 추측은 높은 확률로 틀립니다.

Anthropic 공식 문서에서도 맥락 제공의 중요성을 강조합니다. "Claude는 독심술을 할 수 없다"는 표현이 인상적이었습니다.

2. 예시를 보여줘라 (Show Examples)#

[Before]
이 기술 문장을 쉽게 바꿔줘:
"The platform implements end-to-end encryption protocols
to safeguard data integrity."

[After]
기술 용어를 쉬운 말로 바꾸는 예시야:

1. "The quantum algorithm exhibits quadratic speedup."
   → "새로운 방법이 기존보다 대략 2배 빠르게 문제를 푼다."

2. "The interface leverages intuitive design paradigms."
   → "디자인이 이해하기 쉽고 사용하기 편하다."

이제 이 문장을 같은 방식으로 바꿔줘:
"The platform implements end-to-end encryption protocols
to safeguard data integrity."

2편에서도 썼는데, 예시 하나가 설명 열 줄보다 낫습니다. 패턴, 스타일, 형식을 말로 설명하는 것보다 보여주는 게 빠릅니다. 공식 문서에서는 이걸 few-shot prompting이라고 하고, <example> 태그로 감싸라고 권장합니다.

이 블로그 시리즈 톤을 잡을 때도 기존 글을 통째로 읽게 한 게 이 방법입니다. "경어체로, 기술블로그 톤으로, 취소선 혼잣말 넣어서"라고 말로 설명하는 것보다, 기존 글 하나를 보여주고 "이 톤으로 써줘"가 훨씬 정확합니다.

3. 출력 제약을 걸어라 (Specify Constraints)#

[Before]
포트폴리오 웹사이트 만들어줘.

[After]
싱글 페이지 포트폴리오 웹사이트를 만들어줘.
섹션: Hero, About Me, Skills, Projects, Experience, Contact
네비게이션은 sticky, 모바일에서는 햄버거 메뉴.
색상은 sunset 팔레트, 다크/라이트 모드 토글 포함.

출력 제약을 건다는 건 형식, 길이, 구조, 스타일 같은 울타리를 먼저 쳐두는 일입니다. 1편에서 말한 Description 중 Product Description에 가장 직접적으로 닿아 있습니다.

막상 써보면 자유도를 많이 주는 게 꼭 좋은 결과로 이어지진 않았습니다. 제약이 없으면 AI가 매번 다른 형식으로 결과를 내놓고, 제약이 있으면 그 안에서 훨씬 안정적으로 답을 만듭니다.

4. 복잡한 작업은 단계로 쪼개라 (Break into Steps)#

[Before]
이 분기 매출 데이터 분석해줘.

[After]
이 분기 매출 데이터를 분석해줘. 순서는 이렇게:
1. 매출 상위 제품 파악
2. 전 분기 대비 비교
3. 이상 패턴이나 트렌드 식별
4. 트렌드의 원인 추정

이건 Process Description에 해당합니다. 복잡한 작업일수록 순서를 나눠주는 것만으로도 결과가 꽤 안정됩니다.

2편에서 썼던 Text-to-SQL 경험도 비슷했습니다. "이 질문을 SQL로 변환해줘"라고 한 번에 던지는 것보다, 필요한 테이블 파악 → 조인 조건 정리 → WHERE 절 구성 → 최종 SQL 작성으로 끊어주면 정확도가 눈에 띄게 올라갔습니다. 한번에 다 시키면 중간 과정을 건너뛰는데, 단계를 나누면 어느 지점에서 틀렸는지도 같이 보입니다.

5. 먼저 생각하게 하라 (Think First)#

"답하기 전에, 이 문제를 신중하게 생각해줘. 관련 요소들, 제약 조건, 다양한 접근법을 고려한 후에 최선의 방안을 추천해줘."

chain-of-thought prompting이라고도 하는데, AI한테 바로 답을 내지 말고 사고 과정을 거치게 합니다.

Claude의 경우 extended thinking 기능이 있어서 내부적으로 단계별 추론을 할 수 있습니다. 프롬프트에서 명시적으로 "먼저 생각해줘"를 요청하면 더 깊이 있는 답이 나옵니다.

세션에서 같은 아키텍처 설계 질문을 "Think First" 유무만 달리해서 나란히 비교했습니다. 없는 쪽은 바로 "이렇게 하세요"로 시작하는데, 있는 쪽은 "먼저 고려할 사항이 몇 가지 있습니다: 1. ... 2. ... 이를 종합하면..."으로 분석 자체가 달라지더군요. 특히 트레이드오프가 있는 결정에서 차이가 큽니다.

6. 역할을 정의하라 (Define Role)#

"경험 많은 과학 교사의 관점에서, 과학에 관심 있는 영리한 10살 아이에게 무지개가 어떻게 만들어지는지 설명해줘."

이건 Performance Description 쪽 이야기입니다. 역할, 톤, 스타일을 같이 정해주면 AI가 접근하는 방식 자체가 달라집니다.

2편에서 같은 프롬프트에 Performance만 바꿔서 두 번 돌렸더니 결과가 완전히 달라졌다고 썼는데, 역할 정의가 딱 그 핵심입니다. "시니어 백엔드 개발자로서"와 "주니어를 가르치는 멘토로서"는 같은 질문에도 전혀 다른 깊이와 말투를 만듭니다.

비밀 무기: AI한테 프롬프트를 고쳐달라고 하기#

강의에서 가장 강력한 기법이라고 소개하는 게 이겁니다.

"Claude, 나는 [목표]를 하고 싶은데 어떻게 요청해야 좋은 결과가 나올지 모르겠어. 효과적인 프롬프트를 같이 만들어줄 수 있어?"

프롬프트를 잘 쓰는 방법이 막막하면, 그 방법 자체를 AI한테 되묻는 방식입니다.

실제로 세션에서 이걸 시연해봤습니다:

"이 작업을 너한테 시키려면 어떤 정보를 줘야 해?" 라고 먼저 물어보면 Claude가 필요한 맥락을 역으로 질문해줍니다. 2편에서 Delegation을 다룰 때 "AI한테 같이 생각해달라고 하라"고 했는데, 이게 그 구체적인 방법입니다.

세션에서도 "그러면 프롬프트를 잘 못 써도 되는 거 아닌가요?"라는 질문이 나왔습니다. 반은 맞고 반은 틀립니다. AI가 만들어준 프롬프트도 결국 Discernment 단계에서 한 번 걸러야 하니까 기본기는 여전히 필요합니다. 그래도 시작점으로는 정말 좋습니다. 빈 화면에서 처음부터 끙끙대는 것보다, 초안을 하나 받고 거기서 고치는 쪽이 훨씬 빠릅니다.

6가지 기법과 Description의 관계#

정리해보면 이 6가지는 전부 1편에서 다룬 Description의 하위 카테고리에 매핑됩니다.

강의에서도 이번 Deep Dive가 Description 역량의 실전 확장이라고 말합니다. 개별 기법을 외우는 것보다, 내가 지금 Product / Process / Performance 중 뭘 빠뜨리고 있는지 체크하는 게 더 실용적입니다.

이 매핑 테이블을 세션에서 보여줬을 때 반응이 좋았습니다. "6가지를 다 외울 필요 없이, 세 가지 카테고리만 기억하면 되는 거구나"라는 피드백이었습니다. 실제로 세 가지 카테고리를 체크리스트처럼 쓰면, 6가지 기법 중 뭘 빠뜨렸는지 자동으로 잡힙니다.

세션에서의 실습#

이번 세션에서는 6가지 기법을 하나씩 누적 적용하면서 점수 변화를 추적했습니다.

Langfuse LLM-as-judge 설정#

실습에 사용한 Langfuse의 LLM-as-judge 설정 화면입니다:

평가 기준은 1편에서 정의한 5가지 항목(명확성, 명료함, 정확성, 톤 적절성, 행동 유도)을 그대로 사용했습니다. Langfuse에서 Evaluator를 한 번 세팅해두면, 이후에는 프롬프트를 실행할 때마다 자동으로 채점됩니다.

평가 실행 결과#

기법별 점수 변화#

2편까지의 프롬프트를 베이스라인으로 잡고, 6가지 기법을 하나씩 추가해봤습니다:

2편 최종에서 이미 4.70이었기 때문에 상승폭이 크지 않습니다. 5점 만점에 가까워질수록 올리기가 어렵습니다.

그래도 눈에 띄는 건, "Think First"를 추가했을 때 정확성이 5.0을 찍은 겁니다. "답하기 전에 먼저 기능 스펙을 다시 확인하고, 유저 관점에서 이해가 되는지 검토한 뒤 작성해줘"를 넣었더니, AI가 스펙에 없는 기능을 언급하는 경우가 완전히 사라졌습니다.

반면 명료함은 계속 4.5~4.6 사이에 머물렀습니다. 기법을 추가할수록 프롬프트가 길어지는데, 그게 출력의 명료함에는 크게 영향을 안 준 겁니다. 프롬프트의 길이와 출력의 명료함은 별개라는 걸 확인한 셈입니다.

가장 효과적이었던 조합#

결론부터 말하면, 여섯 가지를 다 외워서 매번 넣는 식은 실무에서 잘 안 쓰이게 된다. 막상 자주 손이 가는 건 몇 가지 조합으로 수렴했다.

정확성이 중요한 작업 (기술 문서, SQL 생성 등): → 맥락 + 출력 제약 + Think First

톤/스타일이 중요한 작업 (유저 대면 문구, 마케팅 등): → 예시 보여주기 + 역할 정의 + 출력 제약

복잡한 분석 작업 (아키텍처 설계, 기획 검토 등): → 단계 쪼개기 + Think First + 역할 정의

세션에서 이걸 공유했더니 기획자분이 "그러면 내가 자주 하는 기능 스펙 작성은 첫 번째 조합이겠네요"라고 바로 자기 업무에 붙여보더군요. 결국 중요한 건 기법 이름을 외우는 게 아니라, 작업 성격에 따라 어떤 조합이 잘 먹히는지 감을 잡는 쪽이었다.

다음 글에서는#

다음 글에서는 Discernment 심화와 Description-Discernment 루프 쪽으로 이어집니다.

이번 글에서 본 6가지 기법이 "어떻게 전달하는가"였다면, Discernment는 "어떻게 평가하는가"에 가깝습니다. 이 루프를 의식적으로 돌리는 게 AI 협업의 핵심이었고, 다음 글은 그 나머지 절반에 대한 얘기입니다.