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

개요#

사실 AI 관련해서 따로 정리해둘 만한 거리들이 좀 쌓여있었다. 프롬프트를 어떻게 나누면 잘 되는지, 어디까지 맡겨도 되는지, 반대로 어디서부터는 꼭 사람이 붙어야 하는지 같은 것들이다.

그러던 중에 쿠폰 정책을 정리할 때 Claude에 초안을 맡겼다가 한 번 꽤 어긋난 적이 있었다. 얼핏 보면 그럴듯했는데, 막상 뜯어보면 우리 서비스랑은 결이 달랐다. 카페 구독 모델인데 일반적인 이커머스 할인 규칙처럼 풀어버린 것이다.

그때 느낀 게, AI를 잘 쓰는 문제는 결국 말을 예쁘게 하는 문제가 아니라 일을 어디까지 넘길지 정하는 문제라는 점이었다. 이번 세션에서 다룬 Delegation과 Description도 결국 그 얘기였다.

Delegation (위임) 심화#

1편에서 Delegation의 세 가지 하위 역량을 정리했었습니다.

• Problem Awareness (문제 인식): 내가 뭘 하려는지 명확히 이해하기
• Platform Awareness (플랫폼 인식): AI가 뭘 잘하고 못하는지 파악하기
• Task Delegation (작업 위임): 강점에 맞게 일을 분배하기

막상 강의에서 말하는 것도 거창한 자동화 이야기는 아니었습니다. 결국 같은 작업 안에서 사람 쪽이 맡아야 할 부분과 AI가 맡으면 더 빠른 부분을 어떻게 나눌지 보자는 쪽에 가깝습니다.

막상 흐름을 적어놓으면 Delegation은 이렇게 흘러갑니다:

1. 전체 목표가 뭔지 파악한다 (문제 인식)
2. AI가 이 작업에서 뭘 잘하고 못하는지 판단한다 (플랫폼 인식)
3. 사람이 할 일과 AI가 할 일을 나눈다 (작업 위임)

여기서 중요한 건, 이걸 혼자 하지 말고 AI한테 "같이 생각해줘"라고 하는 방식입니다. "이 작업을 너한테 시키려면 어떤 정보를 줘야 해?"라고 먼저 물어보면 Claude가 필요한 맥락을 역으로 질문해줍니다. 이 접근이 생각보다 효과적인데, 내가 빠뜨리고 있던 맥락을 AI가 짚어줍니다.

과제: 프로젝트 기획#

과제도 비슷한 방식이었습니다. 주제를 하나 정해놓고 강의 끝날 때까지 끌고 가는데, 조건은 1시간 안에 어느 정도 굴릴 수 있고 본인이 실제로 흥미 있는 주제여야 했습니다.

Claude랑 같이 목표를 정리하고, 필요한 작업을 나누고, 내가 할 일과 AI에 넘길 일을 구분해보는 식입니다. 그냥 일방적으로 "이거 해줘" 하고 끝내는 게 아니라, 질문을 주고받으면서 빠진 가정을 찾아내는 쪽에 가까웠습니다.

내 경험에 비추면#

Dayner 프로젝트에서 쿠폰 시스템 리팩터링할 때를 돌이켜보면, 비슷한 과정을 거쳤습니다. 전략 패턴 설계 자체는 내가 했지만, 코드 초안이나 엣지 케이스 나열은 Claude한테 맡겼습니다. "이 부분은 도메인 맥락을 아는 내가 판단해야 하고, 저 부분은 패턴 적용이니까 Claude가 빠르다" 이런 식으로.

근데 이때 한 가지 실수가 있었습니다. 쿠폰 할인 정책의 비즈니스 규칙을 Claude한테 "알아서 정리해줘" 했는데, 도메인 맥락 없이 일반적인 이커머스 쿠폰 로직을 뽑아낸 겁니다. 우리 서비스는 카페 구독 모델이라 할인 적용 방식이 다른데, 그걸 AI가 알 리 없었죠. 결국 내가 비즈니스 규칙을 정리해서 넣어준 뒤에야 쓸 만한 코드가 나왔습니다.

내가 받아들인 Delegation도 결국 이거였습니다. 뭘 맡길지만 정하는 게 아니라, 맡기더라도 어떤 맥락까지 같이 넘겨야 하는지를 같이 보는 것입니다.

세션에서의 실습#

세션에서는 1편의 공통 과제(기능 소개 프롬프트)를 이어가면서, 이번에는 Delegation 관점을 더 깊이 파고들었습니다.

"이 작업을 AI한테 100% 맡기면 어떤 문제가 생기는가?"를 먼저 논의했습니다.

동료들 의견은 세 가지로 모였습니다.

• 기능의 실제 스펙을 AI가 모르니까 없는 기능을 소개할 수 있다 (Hallucination)
• 유저가 겪는 pain point를 AI가 모르니까 엉뚱한 포인트를 짚을 수 있다 (도메인 부재)
• 내부 용어를 AI가 모르니까 유저가 쓰는 말과 다른 표현이 나올 수 있다 (컨텍스트 부재)

이걸 정리하고 나니까, "그러면 뭘 내가 넣어줘야 하는지"가 자연스럽게 도출됩니다. 기능 스펙, 유저 pain point, 내부 용어 매핑 — 이 세 가지는 사람이 넣어줘야 하고, 문장 구성과 톤 조절은 AI 몫입니다.

1편에서 Platform Awareness를 배운 효과가 여기서 나왔습니다. "AI가 뭘 모르는지"를 알고 있으니까, "내가 뭘 넣어줘야 하는지"가 바로 따라오더군요.

Description (설명) 심화#

Description은 1편에서 세 가지로 나눈다고 정리했었습니다.

• Product Description (결과물 설명): 뭘 만들고 싶은지
• Process Description (과정 설명): 어떤 순서로 접근할지
• Performance Description (행동 설명): AI가 어떤 태도로 작업할지

Description 파트로 넘어오면 이야기가 더 단순해집니다. 강의가 계속 강조하는 건 **"AI는 당신의 머릿속을 읽을 수 없다"**는 사실이었습니다. 결과가 애매하게 나오면 생각보다 많은 경우가 모델 문제가 아니라 설명을 덜 했던 쪽에 가까웠습니다.

이건 개발자로서 좀 뜨끔한 부분이었습니다. 코드 리뷰에서도 "이거 왜 이렇게 짰어?"라는 피드백 대부분이 요구사항 전달이 부족해서 생기는 문제인데, AI한테도 마찬가지인 겁니다. 명확하게 전달하면 명확한 결과가 나오고, 모호하게 전달하면 모호한 결과가 나옵니다.

Product Description (결과물 설명)#

뭘 만들고 싶은지 명확히 정의합니다. 출력 형식, 대상 독자, 톤, 분량 같은 걸 미리 지정합니다.

이 시리즈 초안을 잡을 때도 "마크다운으로, 개발자 블로그 톤으로, 취소선 혼잣말 넣어서" 같은 식으로 먼저 틀을 줬는데, 그게 Product Description입니다.

세션에서 "Product Description을 빼고 프롬프트를 돌려보세요"라고 했더니, 결과물의 형식이 매번 달라졌습니다. 어떤 때는 목록으로, 어떤 때는 장문으로, 어떤 때는 마크다운으로. AI가 형식을 자기 맘대로 정하니까 일관성이 없어집니다. Product Description은 "이 틀 안에서 만들어줘"라고 경계를 그어두는 역할입니다.

Process Description (과정 설명)#

AI가 어떤 순서로 접근할지 가이드합니다. "먼저 ~하고, 그다음 ~해줘" 같은 단계 지정이 여기 해당합니다.

이건 복잡한 작업일수록 차이가 확연합니다. 기획 문서를 뽑을 때 그냥 "기획서 써줘"보다 "요구사항 분석 → 기능 목록 → 우선순위 → 일정" 순서를 지정하면 결과가 확 다릅니다.

Text-to-SQL 프로젝트에서도 이걸 체감했습니다. "이 자연어 질문을 SQL로 변환해줘"보다 "1. 질문에서 필요한 테이블을 파악하고, 2. 조인 조건을 정리하고, 3. WHERE 절 조건을 구성하고, 4. 최종 SQL을 작성해줘" 이렇게 단계를 나눠주면 복잡한 쿼리에서도 정확도가 올라갔습니다. AI한테 한번에 다 하라고 하면 중간 과정을 건너뛰거나 순서가 꼬이는데, 단계를 명시하면 각 단계에서 검증이 가능해집니다.

Performance Description (행동 설명)#

AI의 행동 방식을 정의합니다. 간결하게 / 상세하게, 비판적으로 / 지지적으로 — 어떤 태도로 작업할지를 지정하는 겁니다.

세 가지 중에서 가장 안 쓰이는데, 효과는 제일 크다고 느낀 부분입니다. "내 의견에 동의만 하지 말고 빠진 점을 지적해줘"라고 하면 Claude가 실제로 반론을 제시합니다. 기획 리뷰할 때 이걸 쓰면 혼자서는 못 잡는 허점이 나옵니다.

세션에서 이 효과를 보여주기 위해, 같은 프롬프트를 Performance Description만 바꿔서 두 번 돌렸습니다. 하나는 "친절하고 긍정적인 톤으로", 하나는 "비판적으로, 빠진 부분을 짚어서". 같은 기능 소개 프롬프트인데 결과물의 성격이 완전히 달라졌습니다. 전자는 마케팅 문구에 가깝고, 후자는 기술 문서에 가깝더군요. Performance Description 한 줄이 결과물의 성격을 결정합니다.

내가 쓰면서 찾은 팁들#

강의 내용은 여기까지인데, 이 과정을 듣다 보니 그동안 웹에서 찾아보면서 익힌 것들이 결국 Description의 하위 카테고리에 다 들어간다는 걸 알게 됐습니다.

XML 태그로 구조 잡기#

Claude는 XML 태그를 의미 단위로 해석합니다. Anthropic 공식 문서에서도 권장하는 방식인데, 프롬프트가 길어질수록 효과가 눈에 띕니다.

<instructions>기능 명세서를 작성해줘</instructions>
<context>Spring Boot 기반 쿠폰 시스템이고 현재 전략 패턴으로 분리되어 있다</context>
<output_format>마크다운, 표 포함</output_format>

이렇게 넣으면 지시사항과 맥락이 섞이지 않아서 Claude가 훨씬 정확하게 따릅니다.

프롬프트가 짧을 때는 굳이 안 써도 되는데, 맥락이 길어지거나 여러 종류의 정보가 섞이기 시작하면 XML 태그로 분리하는 게 좋습니다. 특히 코드와 지시사항이 같이 들어가는 경우에 효과가 큽니다. 코드가 지시사항의 일부인지 참고 자료인지를 태그로 명확하게 구분해줄 수 있습니다.

세션에서도 이 팁을 소개했는데, 개발자들은 바로 "아 HTML 태그처럼 구조 잡는 거구나" 하고 이해했습니다. 기획자한테는 "제목/본문/참고자료를 명확히 나누는 거라고 생각하면 됩니다"라고 했고요.

"모르면 모른다고 해" 한 줄 추가#

Hallucination 줄이는 데 제일 효과적이었던 건 이겁니다. "확실하지 않으면 추측하지 말고 모른다고 말해줘" 한 줄만 넣으면 됩니다. Anthropic 블로그에서도 언급하는 건데, 실제로 써보면 "~일 수 있습니다" 같은 애매한 답변 대신 "이 부분은 확인이 필요합니다"로 바뀝니다.

1편에서 Platform Awareness를 다루면서 Hallucination 얘기를 했는데, 이 한 줄이 그 한계에 대한 가장 실용적인 대응입니다. AI의 근본적인 한계를 없앨 수는 없지만, "모르면 모른다고 해"라고 명시하는 것만으로도 체감하는 Hallucination 빈도가 확 줄어듭니다.

세션에서 이걸 before/after로 비교했더니 정확성 점수가 평균 0.3점 올라갔습니다. 한 줄 추가한 것치고는 꽤 큰 효과입니다.

예시 하나가 설명 열 줄보다 낫다#

원하는 출력 형식이 있으면 말로 설명하지 말고 예시를 하나 주는 게 빠릅니다. 이걸 few-shot prompting이라고 하는데, 공식 문서에서는 <example> 태그로 감싸라고 합니다. 블로그 글 톤을 맞출 때도 "이런 톤으로 써줘" 대신 기존 글을 통째로 보여주는 게 훨씬 정확합니다. 이 시리즈 쓸 때도 기존 블로그 글을 읽게 한 게 이 방법입니다

세션에서 이걸 실습할 때, 같은 프롬프트에 예시를 하나 추가하는 것만으로 톤 적절성 점수가 0.5점 올라간 경우가 있었습니다. "비개발자도 이해할 수 있게"라고 말로 설명하는 것보다, 실제로 비개발자에게 잘 통했던 문구 하나를 예시로 넣는 게 훨씬 효과적이었습니다.

긴 문서는 위에, 질문은 아래에#

20K 토큰 이상의 긴 문서를 다룰 때는 문서를 프롬프트 상단에, 질문이나 지시사항을 하단에 배치하면 성능이 올라갑니다. Anthropic 테스트 기준으로 최대 30% 성능 향상이 있다고 합니다.

이건 1편에서 다룬 Context Window의 "lost in the middle" 현상과 관련됩니다. 프롬프트 앞뒤의 정보가 중간보다 recall이 높으니까, 긴 참고 자료는 위에 두고 실제 지시사항은 아래에 두는 거죠. 간단한 건데 의외로 안 지키는 경우가 많습니다.

세션에서의 종합 실습#

이번 세션에서는 1편의 before/after 프롬프트를 가져와서, 위의 팁들을 하나씩 적용해봤습니다.

팁 적용 전후 비교#

1편에서 Platform Awareness까지 적용했던 프롬프트에 이번에 배운 팁들을 추가로 적용했습니다:

<instructions>
우리 HR 시스템에 자연어 검색 기능이 추가됐습니다.
이 기능을 처음 쓰는 인사팀 실무자에게 소개하는 문구를 작성해주세요.
</instructions>
 
<context>
대상: 기존에 조건 필터로 검색하던 인사팀 담당자
기능 스펙:
- "2024년 입사한 개발팀 직원" 같은 자연어로 검색 가능
- 부서명, 직급, 입사일 기준 필터링 지원
- 복합 조건도 자연어로 조합 가능
- 급여, 인사고과 등 민감 데이터는 검색 제외
</context>
 
<output_format>
형식: 200자 이내, 사용 전/후 비교 형식
톤: 전문 용어 없이, 처음 보는 사람도 이해할 수 있는 수준
</output_format>
 
<example>
좋은 예시:
"매번 부서, 직급, 입사일을 하나씩 필터 걸어서 검색하셨죠?
이제 '작년 입사한 마케팅팀' 이렇게 말로 검색하면 바로 나옵니다."
</example>
 
먼저 기존 검색 방식의 불편함을 짚고,
자연어 검색이 이걸 어떻게 해결하는지 보여주세요.
위 스펙에 명시된 기능만 언급하고, 그 외 기능은 추측하지 마세요.
확실하지 않은 내용은 포함하지 마세요.

XML 태그로 구조를 분리하고, 예시를 하나 넣고, "추측하지 마세요"를 추가한 겁니다.

Langfuse 점수 변화:

1편 대비 평균 0.2점 추가 상승입니다. 큰 차이는 아니지만, 행동 유도(Actionability) 점수가 4.3에서 4.6으로 뛴 게 예시 하나 넣은 효과입니다. 예시가 있으니까 AI가 "유저가 바로 써볼 수 있는" 톤과 구체성을 더 잘 잡아냈습니다.

동료들의 변화#

2회차 세션에서 느낀 가장 큰 변화는, 동료들이 "왜 이 점수가 나왔는지"를 스스로 분석하기 시작했다는 점입니다.

1회차에서는 점수를 보고 "오 올랐다" 수준이었는데, 2회차에서는 "명확성이 안 오르는 건 Product Description이 부족한 거 아닌가?" 같은 진단이 나왔습니다. 4D 프레임워크의 용어를 써서 문제를 짚고 있는 거죠.

기획자분은 이번에 "Performance Description만 바꿔서 같은 프롬프트를 두 번 돌려봤는데, 결과가 이렇게 다를 줄 몰랐다"고 했습니다. 비판적 톤으로 설정했을 때 기획 허점이 드러났는데, "이걸 기획 리뷰에 쓰면 혼자서도 사전 검토가 가능하겠다"는 피드백이었습니다.

Description과 Delegation의 관계#

이번 내용을 정리하면서 더 분명해진 건, Delegation과 Description은 따로 놀지 않는다는 점입니다.

막상 해보면 "어떻게 전달해야 할지 모르겠다"는 순간은 대부분 "애초에 뭘 맡길지 정리가 안 됐다"는 뜻에 가깝습니다. 넘기는 일의 경계가 흐리면 설명도 같이 흐려집니다. 반대로 경계가 분명하면 프롬프트도 자연스럽게 짧아지고 정확해집니다.

Text-to-SQL 프로젝트에서도 비슷했습니다. 프롬프트를 계속 고쳐도 정확도가 안 오르길래 한참 들여다봤는데, 문제는 설명 방식보다도 SQL 생성을 통째로 AI에 넘긴 구조 자체였습니다. 스키마 선택은 RAG가, SQL 구조는 AI가, 비즈니스 로직 검증은 내가 맡는 식으로 다시 나누고 나서야 그 다음부터 Description이 제대로 먹히기 시작했습니다.

다음 글에서는#

다음 글에서는 프롬프트 엔지니어링 6가지 기법 쪽으로 넘어갑니다. Description이 "뭘 전달해야 하는가"였다면, 다음 강의는 "어떻게 전달하는가"에 대한 실전편입니다.