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

왜 이 강의를 들었나#

처음에는 이 강의를 그냥 가볍게 보려고 했다. AI 관련 강의가 워낙 많기도 하고, 프롬프트 잘 쓰는 법 정도 아닐까 싶었기 때문이다.

그런데 예전에 Claude한테 최신 Text-to-SQL 동향을 정리해달라고 했다가, 나중에 존재하지 않는 사례가 섞여 있는 걸 보고 식은땀 난 적이 있었다. 그럴듯했기 때문에 더 위험했다.

그 일을 겪고 나서는 관심이 좀 달라졌다. 어떻게 잘 시킬까보다, 어디까지 맡기고 어디서부터는 의심해야 하는지가 더 중요해졌고, 4D 프레임워크는 그걸 정리하는 언어처럼 느껴졌다.

마침 사내에서 격주로 기술세션을 돌아가며 하고 있었는데, 제 차례에 이 내용을 가져갔다. 개발자뿐 아니라 기획자도 참석하는 30분 세션이었고, 강의 내용을 설명한 뒤 직접 프롬프트를 고쳐보는 실습까지 병행했다. 실습에서는 Langfuse에 LLM-as-judge를 세팅해두고, 프롬프트를 수정할 때마다 점수 변화를 눈으로 확인할 수 있게 했다.

이 글은 AI Fluency: Framework & Foundations 과정의 1~3강과 Deep Dive 1의 내용인데, 단순 요약보다는 세션에서 동료들과 실습하면서 느낀 점을 같이 적어두는 쪽에 가깝다.

수강 링크: anthropic.skilljar.com

AI Fluency란#

강의에서 말하는 AI Fluency는 AI 도구 사용법이 아닙니다. AI 시스템과 효과적으로, 효율적으로, 윤리적으로, 안전하게 협업하는 능력을 말합니다.

처음에 이 정의를 들었을 때 "그냥 프롬프트 잘 쓰는 거 아닌가?" 싶었는데, 들어보면 범위가 훨씬 넓습니다. 프롬프트를 잘 쓰는 건 4D 중 하나인 Description에 해당하고, AI Fluency는 그 바깥까지 포함합니다. 뭘 맡길지 판단하는 것(Delegation), 결과를 의심하는 것(Discernment), 윤리적으로 쓰는 것(Diligence)까지.

특정 도구에 종속되지 않는, AI가 바뀌어도 계속 통하는 프레임워크를 세우자는 겁니다. 도구는 6개월이면 바뀌니까 이게 맞는 것 같습니다

기술세션에서도 이 부분을 처음에 강조했습니다. "오늘 배우는 건 Claude 사용법이 아니라, AI랑 일하는 방법론입니다"라고. 이게 세션의 톤을 잡는 데 중요했습니다. 특정 도구 튜토리얼이 아니라 사고방식을 다루는 세션이라는 걸 먼저 인지시켜야 "왜 이론부터 하냐"는 반응이 안 나옵니다.

AI 협업 3가지 모드#

4D로 들어가기 전에 먼저 같이 본 건, AI와 일하는 방식을 세 가지로 나눠보는 일이었습니다. 뒤에서 나오는 4D도 사실 이 세 가지 위에서 돌아갑니다.

Automation (자동화) — 사람이 지시하면 AI가 그대로 실행합니다. "이 CSV 정리해줘", "타입 에러 고쳐줘" 같은 단방향 작업입니다.

Augmentation (증강) — 사람과 AI가 주고받으며 함께 작업합니다. 가장 많이 쓰는 모드입니다. 기획 구체화할 때 Claude한테 질문 던지고, 답변 보고 다시 질문하는 식입니다.

Agency (에이전시) — AI가 독립적으로 판단하고 행동하도록 설정합니다. 하나하나 지시하는 게 아니라 규칙과 맥락을 세팅해두면 AI가 알아서 움직입니다.

기술세션에서 이 세 가지를 설명할 때, 기획자분이 바로 자기 업무에 매핑했습니다. 프로덕트에 LLM 관련 기능이 많이 들어가면서 직접 프롬프트 튜닝을 하고 있었기 때문입니다. "CSV 정리는 Automation이고, 내가 프롬프트 고치면서 결과 확인하는 건 Augmentation이네요" — 이런 식이었습니다.

재밌었던 건, 같은 세 가지 모드를 듣고도 개발자와 기획자가 떠올리는 예시가 달랐다는 점입니다. 개발자는 "코드 리뷰 자동화 → Automation, 아키텍처 상담 → Augmentation" 이렇게 생각하고, 기획자는 "문서 포맷팅 → Automation, 기능 스펙 구체화 → Augmentation"으로 가더군요. 같은 프레임워크인데 직군별로 적용 지점이 다르다는 걸 세션 초반부터 확인할 수 있었습니다.

여기서 한 가지 느낀 점이 있었는데, Agency 모드를 설명할 때 대부분 "그건 아직 먼 얘기 아닌가요?" 하는 반응이었습니다. Automation이나 Augmentation은 이미 하고 있으니까 바로 와닿는데, AI가 알아서 판단하고 움직인다는 건 아직 경험이 없으니까 피부에 안 닿는 겁니다. 근데 CLAUDE.md에 규칙을 정의해두고 Claude Code가 그에 맞게 행동하게 하는 것도 Agency입니다. 이렇게 설명하니까 "아, 그런 것도 Agency구나" 하고 이해하더군요.

4D 프레임워크#

Delegation (위임)#

말 그대로 "AI한테 뭘 넘길 것인가"를 정하는 영역입니다.

• Problem Awareness: 내가 뭘 하려는지 명확히 이해하기
• Platform Awareness: AI가 뭘 잘하고 못하는지 파악하기
• Task Delegation: 강점에 맞게 일을 분배하기

Text-to-SQL 프로젝트에서 "설계는 내가, 코드 초안은 Claude한테" 이렇게 나누고 있었는데, 그게 Delegation이었습니다. 의식하지 않고 하고 있었던 건데, 이름이 붙으니까 더 체계적으로 할 수 있게 됩니다.

다만 Platform Awareness가 부족했습니다. 대표적인 게, Text-to-SQL 리서치 초기에 Claude한테 "이 기술의 최신 동향을 정리해줘"라고 한 적이 있습니다. 그럴듯한 답이 나와서 그대로 기획 문서에 반영했는데, 나중에 확인해보니 존재하지 않는 오픈소스 프로젝트를 실제 사례처럼 언급하고 있었습니다. Knowledge Cutoff 이후의 정보를 물어봤으니 당연히 모르는 건데, Hallucination이라는 한계를 미리 알고 있었으면 "이건 맡기되 출처를 반드시 확인해야겠다" 하고 방어할 수 있었을 겁니다.

결국 Platform Awareness를 가지려면 이 기술이 대충이라도 어떻게 동작하는지는 알아야 합니다. 세션도 4D를 훑고 나서 바로 생성형 AI의 원리와 한계 쪽으로 넘어갔습니다.

실습: Delegation 적용하기

Delegation 개념을 설명한 뒤 바로 실습으로 넘어갔습니다. 세션의 공통 과제는 프로덕트의 특정 기능을 유저에게 소개하는 프롬프트를 작성하는 것이었습니다. 제품에 LLM 기반 기능이 여러 개 있어서 실무에 바로 연결되는 주제였습니다.

첫 번째 실습에서는 Delegation 관점에서 "이 작업의 어디를 AI한테 맡기고, 어디를 내가 해야 하는지"를 먼저 정리하게 했습니다.

대부분 처음에는 "전부 AI한테 맡기면 되지 않나요?" 했는데, 직접 해보면 금방 알게 됩니다. AI가 기능의 기술적 동작은 설명할 수 있지만, "이 기능이 유저한테 왜 필요한지"라는 비즈니스 맥락은 우리가 넣어줘야 합니다. 기능 소개 문구의 초안은 AI, 핵심 메시지와 톤은 내가 — 이런 분배가 자연스럽게 나왔습니다.

Description (설명)#

Description은 원하는 걸 AI한테 어떻게 넘길지를 다루는 파트입니다. 프롬프트 엔지니어링이 여기에 들어갑니다.

• Product Description: 결과물의 형식, 대상, 스타일
• Process Description: AI가 따라야 할 단계나 접근법
• Performance Description: AI의 태도와 행동 방식

기획 문서 작성할 때 "마크다운으로, 개발자가 읽을 수 있게, 기능 목록과 예외 케이스 포함해서"가 Product Description이고, "먼저 요구사항 분석하고, 기능 나열하고, 우선순위 정해줘"가 Process Description입니다.

근데 Performance Description은 잘 안 쓰고 있었습니다. "간결하게 답해줘", "비판적으로 검토해줘" 같은 행동 지시를 의식적으로 넣으면 결과가 꽤 달라집니다. 이걸 왜 이제야 알았는지,,

기술세션에서도 이 세 가지를 설명하고 나서 "본인이 평소에 쓰는 프롬프트에서 뭘 빠뜨리고 있었는지 생각해보세요"라고 했는데, 대부분 Performance Description을 안 쓰고 있었습니다. Product(뭘 만들지)와 Process(어떤 순서로)는 직관적이라 자연스럽게 넣게 되는데, AI한테 태도를 지정한다는 발상 자체가 없는 겁니다.

개발할 때 비유하면, Product Description은 API 스펙, Process Description은 비즈니스 로직 순서, Performance Description은 로깅 레벨이나 에러 핸들링 전략 같은 겁니다. 기능은 돌아가는데 로깅이 없으면 운영에서 힘든 것처럼, Performance Description이 없으면 결과는 나오는데 톤이나 깊이가 원하는 것과 자꾸 어긋납니다.

실습: Description 세 가지를 프롬프트에 넣기

Description 설명이 끝나고 바로 실습을 했습니다. 각자 아까 작성한 프롬프트를 열어보고, Product / Process / Performance 중 뭘 빠뜨렸는지 체크한 뒤 수정하는 방식이었습니다.

대부분 이 수준에서 시작했습니다:

AI 자연어 검색 기능을 소개하는 문구를 작성해줘.

이 프롬프트를 Langfuse에 넣으면 명확성 2.8, 톤 적절성 2.5 수준이 나왔습니다. "기능 소개 문구"가 뭔지도 모호하고, 누구한테 보여줄 건지, 어떤 톤이어야 하는지 전부 빠져있으니까 당연한 결과입니다.

Description 세 가지를 의식적으로 넣으면 이렇게 바뀝니다:

우리 HR 시스템에 자연어 검색 기능이 추가됐습니다.
이 기능을 처음 쓰는 인사팀 실무자에게 소개하는 문구를 작성해주세요.

대상: 기존에 조건 필터로 검색하던 인사팀 담당자
형식: 200자 이내, 사용 전/후 비교 형식
톤: 전문 용어 없이, 처음 보는 사람도 이해할 수 있는 수준

먼저 기존 검색 방식의 불편함을 짚고,
자연어 검색이 이걸 어떻게 해결하는지 보여주세요.
과장하지 말고 실제로 가능한 것만 써주세요.

명확성 4.2, 톤 적절성 4.5까지 올라갔습니다. 대상과 형식, 분량을 넣은 게 Product Description이고, "먼저 불편함을 짚고, 해결 방식을 보여주세요"가 Process Description이고, "전문 용어 없이", "과장하지 말고"가 Performance Description입니다. 동료들이 이 차이를 직접 눈으로 보니까 바로 체감하더군요.

Discernment (판별)#

AI 결과를 비판적으로 평가하는 겁니다.

• Product Discernment: 결과물의 정확성, 적절성 평가
• Process Discernment: AI가 어떤 논리로 결과를 냈는지 검토
• Performance Discernment: AI의 소통 방식이 효과적이었는지 평가

기획 구체화에 Claude를 쓸 때 이게 제일 중요했습니다. "이 기능의 예외 케이스 정리해줘" 하면 그럴듯한 목록이 나오는데, 도메인 맥락을 모르니까 빠지는 게 있습니다. 그래서 항상 결과를 한 번 더 보고 빠진 부분을 추가 질문으로 채웠습니다.

나중에 보니 이런 반복을 Description-Discernment 루프라고 부르고 있었습니다. 설명하고, 결과를 보고, 다시 설명을 고치는 흐름인데, 이름이 붙으니까 내가 막연하게 하던 행동이 좀 더 또렷하게 보였습니다.

그리고 이걸 루프라고 인지하고 있으면 언제 멈춰야 하는지도 보입니다. 의식 없이 하면 "한 번만 더 고쳐볼까?" 하다가 끝없이 들어가게 되는데, 루프라고 생각하면 "지금 두세 바퀴 돌았는데도 안 오르면 프롬프트 말고 다른 걸 봐야겠다"는 판단이 생깁니다.

Text-to-SQL 프로젝트에서 프롬프트를 튜닝할 때 정확히 이 함정에 빠진 적이 있습니다. SQL 생성 정확도가 70% 언저리에서 안 올라가는데, 프롬프트 문구만 계속 바꾸고 있었습니다. 나중에 돌아보니 프롬프트 문제가 아니라 RAG에 넣어주는 메타데이터 품질 문제였습니다. 루프를 돌리되, "이 루프가 수렴하고 있는가?"를 같이 봐야 합니다. 안 수렴하면 프롬프트가 아니라 다른 걸 바꿔야 합니다.

실습: 결과 판별하기

Discernment 실습에서는, 앞에서 수정한 프롬프트의 출력 결과를 서로 교차 검토하게 했습니다.

"이 소개 문구가 실제 인사팀 담당자한테 보여줬을 때 이해가 되겠는가?" — 이 질문을 기준으로 동료의 결과물을 검토했습니다. 기획자는 유저 관점에서, 개발자는 기술적 정확성 관점에서 봅니다.

여기서 재밌는 현상이 나왔습니다. LLM-as-judge 점수가 높은 결과물인데, 기획자가 보기에는 "이건 유저한테 안 통할 것 같아요"라는 피드백이 나온 겁니다. LLM-as-judge가 문장의 명확성이나 톤은 잘 잡았지만, "실제 유저가 이걸 보고 기능을 써보고 싶어할까?"라는 판단은 사람이 더 잘한다는 걸 보여주는 순간이었습니다.

이게 Discernment의 핵심입니다. AI 채점 결과도 결국 판별 대상이라는 거죠.

Diligence (책임)#

이건 AI를 얼마나 책임 있게 쓰고 있느냐의 문제에 가깝습니다.

• Creation Diligence: 어떤 AI를 쓸지 신중하게 선택
• Transparency Diligence: AI 기여를 투명하게 공개
• Deployment Diligence: AI 결과물을 검증하고 책임지기

솔직히 네 가지 중에서 제일 놓치기 쉬운 파트였습니다. AI가 만든 코드를 그대로 커밋하거나 문서를 검증 없이 공유하면 결국 책임은 내 쪽으로 돌아오는데, 이걸 머리로는 알면서도 속도에 치이면 쉽게 흐려집니다.

세션에서 이 파트를 설명할 때 좀 뜨끔했습니다. Hallucination이 섞인 기획 문서가 그대로 나가면 그건 AI 잘못이라기보다 검증하지 않은 내 잘못이니까요. 당연한 얘기인데 막상 바쁠 때는 자꾸 잊게 됩니다.

Transparency도 비슷했습니다. 회의에서 "제가 조사해봤는데요" 하고 말한 내용이 사실은 Claude가 뽑아준 초안이었다면, 어디까지 밝혀야 하는가? 세션에서는 밝히는 쪽이 맞다는 얘기가 나왔습니다. "AI를 활용해서 초안을 잡았습니다" 정도만 말해도 되는데, 그걸 생략하면 역량에 대한 오해가 생기고 나중에 더 곤란해질 수 있다는 논리였습니다. 이 부분은 꽤 와닿았습니다.

생성형 AI의 원리와 한계 — Platform Awareness 채우기#

4D 중 Delegation을 제대로 하려면 Platform Awareness가 필요하고, Platform Awareness를 갖추려면 이 기술이 어떻게 동작하는지 알아야 합니다. 그래서 세션도 4D 다음에 바로 이 파트로 이어갔습니다.

솔직히 "생성형 AI가 뭔데" 수준의 내용이라 가볍게 넘기려 했는데, 기획자가 섞여있는 세션에서는 이 배경이 없으면 뒤의 실습이 안 붙더군요. "왜 AI가 이런 실수를 하는지"를 이해하려면 원리를 알아야 합니다.

어떻게 가능해졌나#

기존 AI가 데이터를 분석하는 데 집중했다면, 생성형 AI는 새로운 콘텐츠를 만들어냅니다.

1. Transformer 아키텍처 — 2017년에 등장한 Transformer가 핵심입니다. 긴 텍스트에서 단어 간의 관계를 병렬로 처리할 수 있게 해준 구조입니다. 개발자라면 "Attention Is All You Need" 논문 제목 정도는 들어봤을 겁니다

기술세션에서 이걸 설명할 때, 기획자한테는 "이전에는 문장을 앞에서부터 한 단어씩 읽었는데, Transformer 이후로는 문장 전체를 한 번에 보면서 단어 간 관계를 파악하게 됐다"고 했습니다. 개발자한테는 "RNN의 sequential 처리가 attention 기반 병렬 처리로 바뀐 거"라고 했고요. 같은 개념을 청중에 맞게 바꿔 설명하는 것 — 생각해보면 이것도 Description의 Performance Description입니다.

2. 대규모 학습 데이터 — 인터넷에 축적된 방대한 텍스트가 학습 재료가 됐습니다.

3. 컴퓨팅 파워 — GPU 성능이 올라가면서 수십억 개의 파라미터를 가진 모델을 학습시킬 수 있게 됐습니다.

학습 과정#

LLM은 두 단계로 학습합니다.

Pre-training (사전학습) — 수십억 개의 텍스트에서 패턴을 학습합니다. 언어의 구조, 지식, 맥락 파악 능력이 여기서 형성됩니다.

Fine-tuning (미세조정) — 사전학습 이후에 지시를 따르고, 유용한 응답을 하고, 유해한 콘텐츠를 피하도록 추가 학습합니다.

세션에서 비유를 하나 들었습니다. Pre-training은 대학에서 전공 지식을 쌓는 과정이고, Fine-tuning은 회사에 입사한 뒤 "이 회사에서는 이렇게 일해" 하고 온보딩 받는 과정입니다. Pre-training에서 아무리 많이 알아도, Fine-tuning 없이는 "유저가 원하는 형식으로 답변하기"가 안 됩니다. 전공 지식이 아무리 뛰어나도 실무에서 커뮤니케이션을 못하면 곤란한 것과 비슷합니다.

Context Window#

AI가 한 번에 고려할 수 있는 정보의 양입니다. 대화 내역, 공유한 문서 등이 전부 이 창 안에 들어가야 합니다.

2026년 3월에 Claude Opus 4.6과 Sonnet 4.6의 1M 토큰 Context Window가 GA됐습니다. 약 75만 단어, 소설 10권 분량입니다. GPT-3.5가 4,096 토큰이었던 게 2022년인데, 3년 만에 약 250배 늘어난 겁니다.

Compaction이라는 기능도 있습니다. Context Window 한계에 도달하면 이전 대화를 자동으로 요약해서 압축하는 건데, 이전에는 Context Window가 차면 새 대화를 시작해야 했습니다. 1M + Compaction 조합이면 사실상 무한 대화가 가능하긴 하지만, 압축 과정에서 디테일이 빠질 수 있습니다.

블로그 만들 때 이걸 직접 겪었습니다. Claude Code로 긴 세션을 돌리면서 "코드 스타일은 이렇게, 커밋 메시지는 저렇게"라고 초반에 정해놨는데, Compaction 이후에 그 규칙을 까먹고 다른 스타일로 코드를 생성한 적이 있습니다. 그래서 중요한 규칙은 대화에서 한 번 말하고 끝내는 게 아니라, CLAUDE.md 같은 영속적인 곳에 적어두는 게 맞습니다.

뭘 잘하고 뭘 못하는가#

이 파트가 Platform Awareness에서 가장 중요한 부분입니다. 기술세션에서도 여기에 가장 많은 시간을 할애했습니다.

잘하는 것:

• 요약, 번역, 코드 작성, 분석 등 다양한 작업을 별도 학습 없이 수행
• 이전 대화를 기억하면서 자연스럽게 이어감
• 검색, 코드 실행, MCP 등 외부 기능과 결합 가능

못하는 것:

세션에서 Hallucination을 직접 보여주기 위해 실험을 하나 했습니다. Claude한테 "우리 제품의 2024년 4분기 MAU를 알려줘"라고 물어본 겁니다. 당연히 내부 데이터를 모르는데, "정확한 수치는 확인이 어렵지만, 일반적으로…" 하면서 그럴듯한 숫자를 만들어냈습니다. 이걸 라이브로 보여주니까 기획자분이 "이걸 기획서에 그대로 넣을 뻔했다" 하더군요. 개발자들도 "라이브러리 추천받을 때 실제로 존재하는 건지 npm에서 확인 안 하고 쓴 적 있다"고.

Hallucination의 핵심이 바로 이겁니다 — 모르는 걸 모른다고 말하지 않는다는 것. 사람이라면 "그건 모르겠는데요"라고 하겠지만, LLM은 패턴 매칭으로 답을 생성하니까 "모른다"는 답이 자연스럽게 나오지 않습니다. 프롬프트에 "확실하지 않으면 모른다고 해"를 넣는 게 효과적인데, 이건 3편에서 조금 더 풀어둡니다.

실습: Platform Awareness 적용하기#

한계를 배운 뒤, 아까 Description까지 적용한 프롬프트를 Platform Awareness 관점에서 다시 점검했습니다.

Description까지 적용된 프롬프트에서는 "과장하지 말고 실제로 가능한 것만 써주세요"라고 했지만, AI가 기능의 실제 스펙을 모르면 Hallucination이 나올 수 있습니다. 그래서 기능 스펙을 명시적으로 넣고, 제약을 더 구체적으로 바꿨습니다:

우리 HR 시스템에 자연어 검색 기능이 추가됐습니다.
이 기능을 처음 쓰는 인사팀 실무자에게 소개하는 문구를 작성해주세요.

대상: 기존에 조건 필터로 검색하던 인사팀 담당자
형식: 200자 이내, 사용 전/후 비교 형식
톤: 전문 용어 없이, 처음 보는 사람도 이해할 수 있는 수준

기능 스펙:
- "2024년 입사한 개발팀 직원" 같은 자연어로 검색 가능
- 부서명, 직급, 입사일 기준 필터링 지원
- 복합 조건도 자연어로 조합 가능
- 급여, 인사고과 등 민감 데이터는 검색 제외

먼저 기존 검색 방식의 불편함을 짚고,
자연어 검색이 이걸 어떻게 해결하는지 보여주세요.
위 스펙에 명시된 기능만 언급하고, 그 외 기능은 추측하지 마세요.
확실하지 않은 내용은 포함하지 마세요.

AI가 모르는 정보를 추측하지 않도록, "이게 실제로 가능한 범위"를 프롬프트에 직접 넣어준 겁니다. Hallucination의 원인 자체를 줄이는 접근이고, "실제로 가능한 것만 써주세요"보다 "위 스펙에 명시된 기능만 언급하고, 그 외 기능은 추측하지 마세요"가 훨씬 구체적인 제약입니다.

Langfuse 점수는 정확성이 4.4에서 4.8로 올라갔고, Hallucination이 눈에 띄게 줄었습니다.

기술세션 실습 설계#

여기서 세션 전체의 실습 구조를 정리합니다.

왜 Langfuse를 골랐나#

실습에서 제일 중요한 건 "잘됐는지 안됐는지"를 감이 아니라 숫자로 볼 수 있어야 한다는 부분이었습니다. "이게 더 나은 것 같은데?" 수준으로는 뭐가 나아진 건지 모릅니다.

프롬프트 실험 도구는 여러 가지가 있는데 Langfuse를 고른 이유는 간단합니다. 오픈소스라서 사내 인프라에 올려서 쓰고 있었고, LLM-as-judge 기능이 내장되어 있어서 별도 파이프라인을 만들 필요가 없었습니다. 프롬프트 넣고 → 실행하고 → 점수 확인하는 사이클을 하나의 화면에서 돌릴 수 있다는 게 세션용으로 딱이었습니다.

LLM-as-judge 평가 기준#

미리 판단 기준을 만들어뒀습니다. 5점 만점 기준입니다:

명확성 점수가 낮으면 맥락이 부족한 거고, 톤 점수가 낮으면 Performance Description을 안 넣은 겁니다. 점수 항목 자체가 "뭘 고쳐야 하는지"를 알려주는 셈입니다.

세션 진행 구조#

30분을 이론/실습 반반으로 나눈 게 아니라, 스킬 하나를 설명할 때마다 바로 실습으로 넘어가는 구조입니다.

Delegation 설명 (5분) → 실습: 작업 분배 정하기 (3분)
→ Description 설명 (5분) → 실습: 프롬프트에 3가지 넣기 (5분)
→ Discernment 설명 (3분) → 실습: 결과 교차 검토 (4분)
→ Diligence 설명 (2분) → 정리 및 논의 (3분)

이론을 한꺼번에 쭉 하고 마지막에 실습하면, 앞에서 배운 건 이미 날아가 있습니다. 하나 배우고 바로 써보는 게 핵심이었고, 실제로 이 구조에서 동료들의 집중도가 훨씬 좋았습니다.

점수 변화 추이#

세션 동안 한 사람의 프롬프트가 어떻게 변했는지, 평균적인 흐름입니다:

초기 한 줄짜리 프롬프트에서 시작해서, 스킬 하나 적용할 때마다 평균이 오릅니다. Description 단계에서 점프가 가장 큰데, Product/Process/Performance 세 가지를 의식적으로 넣는 것만으로 거의 1점이 뜁니다. Platform Awareness 단계에서는 정확성이 두드러지게 올라갔고요.

명료함(Conciseness)은 좀 다른 양상이었습니다. 맥락을 많이 넣을수록 프롬프트가 길어지면서 오히려 점수가 떨어지는 경우가 있었습니다. "맥락은 충분히, 하지만 군더더기는 빼고" — 이 밸런스를 잡는 게 Description의 진짜 어려운 부분입니다.

실제 반응#

기법을 배우고 프롬프트에 적용할 때마다 점수가 올라가는 게 눈에 보이니까, 잘 안 되는 경우에도 "왜 안 됐는지"를 감이 아니라 근거로 얘기할 수 있었습니다.

특히 기획자분은 평소에 프롬프트를 감으로 고치고 있었는데, 점수 기준이 생기니까 "아 내가 맥락을 안 줘서 그랬구나" 같은 피드백이 스스로 나오기 시작하더군요.

돌이켜보면 이 실습 구조 자체가 Description-Discernment 루프입니다. 프롬프트를 쓰고(Description) → 점수를 확인하고(Discernment) → 다시 고치는(Description) 반복. 강의에서 말하는 루프를 Langfuse 점수로 시각화한 겁니다.

과제를 해보면서#

3강에 연습 과제가 있습니다. 잘 아는 주제와 모르는 주제 각각으로 Claude와 대화해보고 차이를 관찰하라는 건데, 해보면 확실히 다릅니다.

아는 주제 — 예를 들어 Spring의 DispatcherServlet 동작 과정 — 으로 대화하면, Claude 답변에서 "이건 맞는데 저건 좀 다른데?" 하는 감이 바로 옵니다. "아 DispatcherServlet이 HandlerMapping 찾는 순서가 저건 아닌데" 같은 식으로. 반대로 모르는 주제에서는 그 감이 안 옵니다. Claude가 말하는 걸 그냥 그대로 받아들이게 됩니다.

이 차이가 꽤 무섭습니다. 모르는 영역에서 AI를 쓸 때가 가장 편리하지만, 동시에 가장 위험한 순간이기도 합니다. 틀린 답을 잡아낼 도메인 지식이 없습니다.

블로그 만들 때도 겪었는데, Next.js 최신 버전의 API를 Claude한테 물어봤더니 deprecated된 방식을 자신 있게 알려준 적이 있습니다. Next.js에 익숙했으면 바로 잡았을 텐데, 처음 쓰는 프레임워크라 그대로 따라갔다가 빌드에서 터졌습니다. 아는 영역에서는 자연스럽게 하던 판별이, 모르는 영역에서는 그게 안 됩니다.

모르는 영역일수록 교차 검증이 중요하다는 걸 직접 느꼈고, 4D가 왜 모든 협업 모드에 걸쳐서 필요한지 이 과제를 하면 와닿습니다.

나는 어디가 부족한가#

강의 마지막에는 자기 점검 질문이 있다. 듣고 나서 나도 좀 돌아보게 됐다.

• 자신 있는 쪽: Description. 프롬프트 작성 경험이 있어서 원하는 걸 전달하는 건 익숙한 편이다.
• 부족한 쪽: Platform Awareness와 Diligence. AI 한계를 어디까지 알고 있는지, 또 AI 기여를 얼마나 투명하게 드러내고 있는지는 아직 더 신경 써야겠다는 생각이 들었다.

기술세션을 진행하면서 한 가지 더 분명해진 건, Delegation이 생각보다 어렵다는 점이었다. "AI한테 뭘 시킬지"를 정하려면 작업을 쪼갤 줄 알아야 하고, 작업을 잘게 나누려면 결국 문제 자체를 꽤 잘 이해하고 있어야 한다.

세션에서 동료들을 보면서 더 확실히 느꼈는데, 프롬프트를 잘 쓰는 사람과 못 쓰는 사람의 차이는 문장력이 아니었다. 자기가 뭘 원하는지 명확히 아는 사람이 프롬프트도 잘 썼다. 결국 AI를 잘 쓰려면 먼저 그 도메인을 어느 정도는 알고 있어야 한다는, 꽤 당연하지만 자꾸 잊게 되는 결론으로 돌아오게 된다.

다음 글#

다음 글은 Delegation과 Description을 실제 프로젝트에 붙여보는 쪽으로 넘어가는 글입니다. 4D 중 첫 번째와 두 번째 역량을 실무 문맥에서 다시 풀어본 글이고, 그때 써먹었던 팁들도 같이 적어두었습니다.