[AI 8편] AI Fluency 4D 프레임워크와 LLM 오류 유형별 검증 방법
이 글에 나오는 용어 개
목차
참고자료
- Anthropic Academy - AI Fluency: Framework & Foundations
- Anthropic Academy - AI Capabilities and Limitations
- Rick Dakan, Joseph Feller, A Framework for AI Fluency (2025)
- Claude Code Docs - Memory (CLAUDE.md)
- Claude Academy - 엔지니어링 과정 목록 (AI Fluency for Builders, The AI Fluency Index, Discernment Toolkit, Writing an AI Diligence Statement, Getting Good at Claude)
배경
스터디 8주차는 AI Fluency 강의와 AI Capabilities and Limitations 강의였다. 앞의 강의가 API, MCP(Model Context Protocol, AI 앱과 외부 도구를 잇는 표준 프로토콜), Claude Code 기능을 다뤘다면, 이 두 강의는 AI에 작업을 맡기는 방법과 모델이 오류를 내는 원인을 다룬다.
두 달 동안 Claude Code를 쓰면서 겪은 오류를 이 강의 내용에 대입해 봤다. 존재하지 않는 kubectl 플래그를 제시한 경우, 긴 장애 분석 대화 후반에 폐쇄망 조건을 반영하지 않고 외부 저장소에서 패키지를 받으라고 한 경우, 사용자가 잘못된 가정을 말했는데 그대로 동의한 경우다. 각각 다른 원인으로 생각했지만 강의에서는 같은 모델 특성으로 설명한다.
정리하면서 확인하고 싶었던 것들이다.
- AI를 잘 활용하는 능력에는 무엇이 포함되는가?
- AI에 맡길 작업과 직접 할 작업은 어떤 기준으로 나누는가?
- 결과가 그럴듯하지만 틀렸을 때 무엇을 먼저 확인해야 하는가?
- 모델이 사용자의 잘못된 가정에 동의하는 이유는 무엇인가?
- 운영 환경에 적용하기 전에 무엇을 검증해야 하는가?
- (보완) 실제 사용 대화를 분석한 연구는 어떤 행동이 부족하다고 보는가?
- (보완) 확인과 공개는 어떤 도구와 문서로 남기는가?
큰 그림
AI Fluency 강의는 사람이 수행하는 4단계(4D)를, AI Capabilities 강의는 모델의 4가지 특성을 다룬다. 결과 검증(분별) 단계에서 모델 특성을 알아야 오류 원인을 판단할 수 있다.
flowchart LR
subgraph Human[사람]
D1[위임<br/>맡길 작업 결정] --> D2[설명<br/>요구사항 전달]
D2 --> D3[분별<br/>결과 검증]
D3 -->|요구사항 수정| D2
D3 --> D4[책임<br/>결과 보증]
end
subgraph Model[모델]
P1[다음 토큰 예측]
P2[학습 지식]
P3[컨텍스트 윈도우]
P4[지시 이행]
end
Model -.오류 원인 판단.-> D3
1절과 2절은 4D, 3절과 4절은 모델 특성과 오류 유형, 5절은 Claude Code 작업에 적용한 내용이다.
1. AI Fluency 정의와 작업 위임 방식
강의에서 AI Fluency는 AI와 효과적, 효율적, 윤리적, 안전하게 일하는 능력으로 정의한다. 프롬프트 작성은 그중 일부이고, 작업을 맡길지 결정하는 일, 요구사항을 전달하는 일, 결과를 검증하는 일, 결과에 책임지는 일이 모두 포함된다.
AI에 작업을 맡기는 방식은 3가지로 나눈다.
| 방식 | 의미 | 예 | 사람의 검증 부담 |
|---|---|---|---|
| Automation | 정해진 작업 하나를 AI가 처리 | 로그 100줄을 표로 정리 | 낮음 |
| Augmentation | 사람과 AI가 함께 판단 | 장애 원인 분석 | 최종 판단은 사람 |
| Agency | AI가 이후 작업을 자율적으로 수행 | 스케줄러, 자율 에이전트 | 가장 높음 |
Automation에서 Agency로 갈수록 사람의 작업량은 줄지만 검증과 책임 부담은 커진다. 자율 실행 에이전트(Agent, 도구를 골라 쓰며 스스로 다음 행동을 정하는 반복 구조)가 잘못된 판단을 하면 사람이 확인하지 않는 동안 같은 오류가 반복되기 때문이다.
2. 4D: 위임, 설명, 분별, 책임
4D는 Delegation(위임), Description(설명), Discernment(분별), Diligence(책임)의 약자다.
2.1 위임
위임은 직접 할 작업, AI에 맡길 작업, 함께 할 작업을 나누는 단계다. 확인할 항목은 3가지다.
- 해결하려는 문제가 무엇인가(Problem Awareness)
- 사용하는 AI의 강점과 약점은 무엇인가(Platform Awareness)
- 작업을 어떻게 나눌 것인가(Task Delegation)
업무 지식과 AI 특성에 대한 이해가 모두 필요하다. 업무를 모르면 맡길 범위를 정할 수 없고, AI 특성을 모르면 AI가 약한 작업을 맡기게 된다. 이전에는 이 단계 없이 바로 작업을 요청하는 경우가 많았다.
2.2 설명
AI는 전달받은 내용만 반영한다. 설명 단계에서는 3가지를 명확히 전달한다.
| 항목 | 내용 | 예 |
|---|---|---|
| Product(결과물) | 형식, 대상, 분량 | “ConfigMap YAML, STG용, 주석 포함” |
| Process(과정) | 작업 순서 | “현재 매니페스트 확인, 변경 사항 비교, 검증 명령 제시” |
| Performance(작업 방식) | 협업 시 동작 방식 | “단계마다 확인 요청, 파괴적 명령은 실행하지 않고 제시만” |
이전에는 결과물 형식만 지정했다. “잘못된 가정은 먼저 반박할 것”처럼 작업 방식도 지정할 수 있다.
2.3 분별
분별은 결과를 검증하는 단계로, 설명과 같은 3개 항목으로 확인한다. 결과물이 정확하고 요구사항에 맞는지, 작업 과정에 누락된 논리가 없는지, 작업 방식이 요청과 맞았는지 본다.
검증 결과 요구사항 전달이 부족했던 부분이 드러나면 설명 단계로 돌아가 수정한다.
2.4 책임
책임은 AI로 만든 결과를 보증하는 단계다. AI 도구를 선택할 때(Creation), AI 사용 사실을 공유해야 하는 사람에게 알릴 때(Transparency), 결과를 배포하거나 공유할 때(Deployment)로 나눈다.
인프라 운영에서는 배포 단계의 책임이 가장 크다. AI가 작성한 매니페스트나 스크립트를 운영 환경에 적용하면 그 결과는 적용한 사람이 책임진다. 장애 보고서에 “AI가 제시한 명령”은 원인으로 쓸 수 없다.
3. 모델의 4가지 특성
AI Capabilities 강의에서는 모델의 강점과 약점이 같은 원리에서 나온다고 설명한다. 학습한 텍스트 패턴을 이어서 생성하기 때문에 자연스러운 문장을 쓰고, 같은 이유로 사실이 아닌 내용도 자연스럽게 생성한다.
3.1 사전학습과 미세조정
모델은 두 단계로 만들어진다.
| 단계 | 내용 | 결과 |
|---|---|---|
| 사전학습 | 대량의 텍스트로 다음 토큰을 예측하는 학습을 반복 | 입력된 문서를 이어서 작성하는 모델 |
| 미세조정 | 좋은 응답 예시와 사람의 선호 평가로 추가 학습 | 입력을 요청으로 해석하고 답변하는 어시스턴트 |
사전학습만 마친 모델에 “미국 대통령이 누구야?”를 입력하면 답변하지 않고 이 문장이 들어갈 만한 문서를 이어서 작성한다. 질문에 답하는 동작은 미세조정 단계에서 학습한 것이다.
사용자의 잘못된 가정에 동의하는 현상은 미세조정의 영향이다. 사람이 선호하는 응답에 보상을 주는 과정에서 사용자 의견에 동의하는 응답이 높은 평가를 받는 경향이 학습된다. 이를 아첨(sycophancy)이라고 한다.
3.2 4가지 특성
강의는 모델의 특성을 4가지로 나누고, 작업이 각 특성의 강점 영역에 있는지 약점 영역에 있는지에 따라 결과 품질이 달라진다고 설명한다.
| 특성 | 강점 영역 | 약점 영역 | 확인할 질문 |
|---|---|---|---|
| 다음 토큰 예측 | 학습 데이터에 많은 패턴(요약, 형식 변환) | 드물거나 새로운 작업, 사실 확인이 필요한 작업 | 흔한 유형의 작업인가? |
| 학습 지식 | 자주 다뤄지고 최근까지 일관된 주제 | 드물거나, 최신이거나, 의견이 갈리는 주제 | 학습 데이터에 충분히 있었을까? |
| 컨텍스트 윈도우 | 입력이 한도 안에 여유 있게 들어가는 대화 | 긴 문서, 긴 대화, 이전 세션 이어 가기 | 필요한 정보가 모두 입력에 들어가는가? |
| 지시 이행 | 짧고 구체적이고 검증 가능한 지시 | 긴 추론, 추상적 지시, 정확한 계산 | 지시 내용과 실제 의도가 일치하는가? |
다음 토큰(Token, 언어 모델이 텍스트를 처리하는 단위) 예측은 검색과 다르다. 저장된 답을 찾아오지 않고, 이전 토큰을 기준으로 다음에 올 가능성이 높은 토큰을 하나씩 생성한다. 학습 지식에는 학습 데이터 수집 시점(knowledge cutoff)이 있어서, 그 이후 정보는 별도 도구로 제공하지 않으면 알 수 없다.
컨텍스트 윈도우는 모델이 한 번에 처리하는 입력의 최대 크기다. 지시, 첨부 문서, 이전 응답이 모두 포함된다. 다른 특성은 조건이 나빠질수록 품질이 점진적으로 낮아지지만, 컨텍스트 윈도우는 한도를 넘는 순간 정보가 누락된다.
지시 이행은 지정한 역할, 형식, 길이를 따르는 정도다. 지시도 다른 텍스트와 같은 방식으로 처리하기 때문에 지시를 문자 그대로 따르면서 실제 의도는 반영하지 못하는 경우가 생긴다.
4. 오류 유형과 확인 방법
실제 오류는 대부분 2가지 특성이 겹쳐서 발생한다. 그동안 겪은 오류를 강의의 분류에 대입하면 다음과 같다.
| 오류 사례 | 관련 특성 | 확인 방법 |
|---|---|---|
존재하지 않는 kubectl 플래그 제시 |
다음 토큰 예측, 학습 지식 | 공식 문서로 교차 확인 |
| 긴 대화 후반에 폐쇄망 조건 누락 | 컨텍스트 윈도우, 지시 이행 | 제약 조건 재입력, 안 되면 새 세션 시작 |
| 세션 초반 지시가 후반 지시에 덮어써짐 | 컨텍스트 윈도우, 지시 이행 | 항상 지킬 제약은 CLAUDE.md에 작성 |
| 잘못된 가정에 동의 | 아첨, 다음 토큰 예측 | 반박하도록 명시적으로 요청 |
| 리소스 요청량 계산 오류 | 다음 토큰 예측, 지시 이행 | 직접 계산하거나 도구로 검산 |
결과가 틀렸을 때 전체를 다시 검토하지 않고, 오류 유형에 해당하는 특성을 기준으로 확인할 부분을 정한다.
환각(사실이 아닌 내용을 생성하는 현상)은 일반 개념 설명보다 이름, 날짜, 버전, 인용, URL 같은 구체적인 값에서 자주 발생한다. 명령어 플래그, 차트 버전, 문서 링크가 이에 해당한다. 이 블로그 글의 참고 링크도 직접 열어서 확인한 뒤 넣는다.
강의에서는 이를 calibrated trust라고 설명한다. 모든 결과를 같은 수준으로 검증하지 않고, 작업 유형에 따라 검증 강도를 조정한다. 흔한 YAML 문법 같은 작업은 가볍게 확인하고, 출시된 지 몇 달 안 된 기능이나 특정 버전에만 있는 옵션은 공식 문서로 반드시 확인한다.
5. Claude Code 작업에 적용한 내용
강의 내용을 회사 PC의 Claude Code 설정과 작업 프롬프트에 반영했다.
5.1 세션 시작 프롬프트
새 작업 세션의 첫 메시지로 입력한다. 아첨을 줄이고 환각이 자주 발생하는 항목을 미리 지정한다.
작업 방식:
- 내 가정에 동의하지 말고 틀린 부분은 먼저 지적해라.
- 추측, 사실, 미확인을 구분해서 표시해라. 모르면 모른다고 해라.
- 명령 플래그, 버전, 옵션, URL은 공식 문서로 확인한 것만 제시해라.
- 폐쇄망, 온프레미스, 특정 버전 제약은 대화가 끝날 때까지 유지해라.
제약을 반영했는지 확실하지 않으면 먼저 질문해라.
5.2 작업 요청 템플릿
[위임] 이 작업을 맡길지, 함께 할지, 내가 할지 먼저 정하자.
목표는 X다. AI가 처리할 부분과 내가 판단할 부분을 나눠 줘.
[설명] 결과물: 형식, 대상, 분량
과정: 작업 단계
방식: 단계마다 확인 요청, 파괴적 명령은 실행하지 않고 제시만
[책임] 결과는 STG에서 검증한 뒤 운영에 적용한다.
검증 명령과 롤백 절차를 함께 제시해라.
마지막 항목의 효과가 가장 컸다. 결과에 롤백 절차가 함께 포함되어 검증 시 롤백 방법을 따로 정리하지 않아도 된다.
5.3 CLAUDE.md에 상시 규칙 작성
세션 시작 프롬프트를 매번 입력하는 방식은 컨텍스트 윈도우와 지시 이행 특성의 영향을 받는다. 항상 지켜야 하는 규칙은 매 요청에 포함되는 프로젝트 CLAUDE.md에 작성했다.
## AI 협업 규칙
- 위임: 작업 시작 전 맡길지, 함께 할지, 직접 할지 정한다.
- 검증: AI가 작성한 명령, 매니페스트, 스크립트는 STG 검증과 롤백 절차 없이 운영에 적용하지 않는다.
- 환각: 플래그, 버전, URL은 공식 문서로 교차 확인한다. 확인하지 못한 항목은 미확인으로 표시한다.
- 컨텍스트: 긴 세션에서 제약 조건이 누락되면 다시 입력하거나 새 세션으로 시작한다.
- 아첨: 가정을 검토 없이 따르면 반박하도록 다시 요청한다.
5.4 프롬프트를 AI와 함께 작성
강의에서 가장 효과가 크다고 소개한 방법은 작업 지시문을 AI와 함께 작성하는 것이다. “이 목표에 맞는 프롬프트를 같이 작성하자. 빠진 정보가 있으면 먼저 질문해라.”로 시작하면, 위임 단계에서 누락한 정보를 AI가 질문으로 확인한다.
6. 보완: 실제 대화 연구와 확인 도구
이 절은 같은 Claude Academy에서 이후에 정리한 튜토리얼과 강좌를 더한 것이다. 모델 동작 원리는 Claude Academy 1편에 따로 있다.
6.1 AI Fluency Index
Anthropic Education Report가 Claude.ai 대화 9,830건(2026년 1월 20일부터 26일, 여러 차례 주고받은 대화)에서 유창성 행동 11개의 출현 비율을 쟀다.
측정 틀은 Rick Dakan과 Joseph Feller가 Anthropic과 개발한 4D AI 유창성 프레임워크(4D AI Fluency Framework)다. 이 틀이 정의하는 행동 24개 중 대화에서 관찰 가능한 11개만 측정했다.
아래 표의 %p(퍼센트포인트, 두 비율의 차이)는 비율이 몇 포인트 늘거나 줄었는지를 나타낸다.
| 관찰 | 수치 |
|---|---|
| 반복과 개선이 있는 대화 | 85.7%다. 다른 유창성 행동이 평균 2.67개 더 나타났다. |
| 목표 명확화, 좋은 결과 예시 제공 | 51.1%, 41.1%다. |
| 사실 확인 | 8.7%로 가장 드물다. |
| 결과물(코드, 문서, 대화형 도구 등)을 만든 대화 | 12.3%다. 지시 행동은 늘고 맥락 누락 확인(-5.2%p), 사실 확인(-3.7%p), 추론 의문 제기(-3.1%p)는 줄었다. |
완성된 것처럼 보이는 결과물이 비판적 평가를 줄일 가능성이 있다는 해석이다. 결과물 대화에서 늘어난 지시 행동은 목표 명확화 +14.7%p, 형식 지정 +14.5%p, 예시 제공 +13.4%p, 반복 +9.7%p다.
반복과 개선이 있는 대화는 없는 대화보다 추론에 의문을 제기할 가능성이 5.6배, 누락된 맥락을 짚을 가능성이 4배 높았다.
이 관계에서 반복과 개선이 있는 대화는 단발 대화보다 숙련 행동이 약 2배라고 토론 가이드 영상은 설명한다.
같은 영상은 반복하는 대화가 단발 대화보다 숙련 행동이 약 2배이고, 추론 질문은 5배 이상, 누락 맥락 파악은 4배 높다고 한다.
토론 가이드 영상은 약 10,000건의 대화를 분석했다고 소개한다. 평가 행동은 드물어서 추론 질문이 약 16%, 시작 전 접근 방식 상의가 약 10%, 사실 확인이 9% 미만이다.
AI에 협업 방식을 지시한 대화는 30%에 그쳤다. 협업 조건은 “가정이 틀리면 반박해 달라”, “답 전에 추론 과정을 설명해 달라”, “불확실한 부분을 알려 달라” 같은 요청이다. 위 5.1절의 세션 시작 프롬프트가 이 협업 조건에 해당한다.
보고서의 개선 방향은 세 가지다. 대화에 머물며 반복하기, 완성돼 보이는 결과물에 의문 제기하기, 협업 조건을 직접 정하기다.
토론 가이드는 결과물이 있는 대화에서 평가가 줄어드는 원인 후보를 세 가지 든다. 완성돼 보이는 외형이 끝을 암시하는 점, 사실 정밀도가 덜 필요한 과제라는 점, 대화 밖에서 평가하는 점(코드 실행, 동료 공유 등)이다.
영상은 조직 차원의 권고로 점검 주기, 공통 용어 만들기, 작업에 덧붙이는 diligent statement(성실성 고지문, 6.3절)를 제시한다.
표본이 한 주, Claude.ai 다회 대화, 조기 사용자에 치우쳐 있어 일반 인구의 기준이 아니다.
상관관계라서 한 행동이 다른 행동의 원인이라고 읽으면 안 된다.
행동을 있음과 없음 두 값으로만 분류해서 부분적 행동의 뉘앙스가 빠진다. 사용자가 머릿속으로 하는 확인과 대화 밖의 코드 실행, 테스트는 관찰되지 않았다.
관찰할 수 없는 13개 행동(AI 사용 사실 공개, 결과 공유의 영향 고려 등)은 이번 측정에 포함되지 않았다.
Chat, Claude Code, Cowork 50,000건 이상으로 넓혀 같은 11개 행동 지표를 분석한 연구도 있다. 제품마다 시작 행동(signature move, 다른 지표를 가장 안정적으로 끌어올리는 관문 행동)이 다르다.
Chat의 시작 행동은 후속 턴으로 다듬는 반복이다. Claude Code와 Cowork는 시작 전에 목표를 밝히는 것이고, 이렇게 시작하는 사용자는 형식 지정, 상호작용 방식 설정, 작업 분해도 더 자주 한다.
교육은 시작 행동을 먼저 가르쳐야 한다. 반복을 안 가르친 Chat 교육과 목표를 안 가르친 에이전트 교육은 효과가 낮다.
지시(Description) 범위는 효과가 유지되는 기간으로 나눈다. 기본은 한 응답에 영향을 주는 반복, 맥락, 파일 업로드다. 고급은 Project, CLAUDE.md, 예약 워크플로우처럼 설정으로 모든 응답에 영향이 가는 것이다.
지시 기술은 사용 기간이 길수록 비선형적으로 늘어난다.
그래서 교육 시간이 짧으면 다양한 지시 방법을 접하게만 해도 된다.
분별력은 사용 기간과 기능 숙련도로 늘지 않는다. 지시 방법은 연습으로 늘지만 분별력은 가르쳐야 늘어난다. diff(코드 변경 전후의 차이)를 보거나 테스트를 돌리는 관찰형 확인은 보이는 오류만 잡는다.
잘못된 가정, 빠진 맥락, 그럴듯한 거짓 주장은 놓친다.
초급 직원 업무가 자동화되면서 좋은 결과가 무엇인지 가르치는 프로그램이 필요해진다. 교육 시간이 제한적이면 분별력에 집중한다.
그래서 교육은 시작 행동, 지시 범위 확장 순서로 가되 모든 단계에서 분별력을 다시 점검한다. 단계마다 이제 의심해 보라는 확인을 넣는다.
Claude Code에서는 diff를 받기 전에 무엇을 가정했는지 묻는 질문이 예로 나온다. Cowork에서는 결과를 쓰기 전에 무엇이 틀리게 만들까를 묻는 질문이 예로 나온다.
제품별 표에는 단계별 기능, 교육 방식, 분별력 확인 질문 칸이 있다. 위 두 예 외의 칸 내용은 요약에 없어서 원문 확인이 필요하다.
지표 측정은 입력된 문장을 기반으로 하므로 눈으로 보고 확인하는 행동은 완전히 포착하지 못한다.
6.2 분별 도구
Claude Academy 참가자 129명을 Anthropic Interviewer로 인터뷰한 보고서다(완료한 인터뷰 94건, 설문 수치는 95~98명 기준).
참가자의 51%가 외부 기준으로 대조했다. 출처 문서, 공식 문서, 자기 데이터, 다른 사람, 다른 AI가 그 기준이다.
이 중 10%는 독립적인 확인 방법을 여러 개 결합했다.
작업 유형별로 방법이 갈렸다.
| 작업 | 확인 방법 |
|---|---|
| 코드 | 테스트다. |
| 연구와 분석 | 출처 교차 대조와 두 번째 의견이다. |
| 글쓰기 | 도메인 지식과 동료의 읽기다. |
장벽을 말한 62명 중 1위는 시간이 아니라 도메인과 기술 전문성 부족(23%)이었다. AI 사용량 한도 19%, 맥락과 프롬프트 부족 13%가 뒤를 이었다.
놓친 오류 사례 18건의 절반은 이후 작업 방식이 바뀌었다. 추천 전에 원문 인용을 요구하고, 단계마다 승인 관문을 두고, 한 AI가 작업하고 다른 AI가 부분별로 점검하는 구조가 나왔다.
보고서가 제안한 도구는 다섯 가지다.
- 자주 만드는 결과물용 점검표를 스킬로 만든다. 프롬프트는 질문 4~5개로 정보를 모은 뒤 질문 5~8개짜리 점검표와 시각 점수표 artifact(Claude가 대화와 별도로 띄우는 결과물)를 만들게 한다.
- Anthropic이 공개한
discernment-nudge스킬을 설치한다. 복잡한 작업 뒤에 추가 확인 질문을 띄운다. - Claude Code의 서브에이전트(하위 에이전트)로 적대적 리뷰(adversarial review, 결과를 일부러 반박하는 관점에서 검토하는 방식)를 한다.
- 이메일을 바탕으로 두 번째 확인자를 찾는 전문가 패널을 구성한다.
- 사실 주장마다 출처 원문, 링크 또는 쪽수를 달게 하고 일반 지식은 “unsourced”로 표시하게 한다.
표본은 자발적으로 참여한 숙련 사용자 위주이고 일반 사용자 비율을 주장하지 않는다. 모든 데이터가 자기 보고라서 극적인 실패가 과대 대표될 수 있다.
주제 분류에는 LLM을 썼고, 사람이 각 주제의 10% 이상을 점검하고 기준을 수정한 뒤 전체를 다시 분류했다.
위 4절의 오류 유형 표를 점검표 스킬로 옮기는 것이 이 보고서에서 바로 가져올 만한 부분이다.
6.3 성실성 고지문
AI 성실성 고지문(AI diligence statement)은 AI가 한 일, 내가 한 일, 결과를 어떻게 확인했는지를 밝히고 최종 책임을 지겠다고 적는 글이다. 연구 논문의 방법 절에 해당하며, 신뢰 형성, 판단 기록, 조직 학습에 쓴다.
생명과학, 금융, 교육 같은 규제 산업에서는 AI 사용 공개가 요구되거나 기대되는 경향이 커지고 있다.
고지문은 다섯 요소로 구성한다.
| 요소 | 쓸 내용 |
|---|---|
| AI가 도운 작업 | “AI가 기여함”이 아니라 초안 작성, 연구 종합, 편집처럼 구체 작업명으로 쓴다. |
| 사용한 도구 | AI 도구 이름이다. |
| 내가 확인한 내용 | 관여 정도다. |
| 내가 바꾼 부분 | 수정 내용이다. |
| 책임 소재 | 최종 책임자다. |
작성은 프로젝트와 AI의 역할 설명, 초안 확인과 수정, 독자별 버전 조정, 고지문 자체의 사실 확인 4단계다.
독자별 버전은 내부 보고서용 2~3문단, 경영진 요약 슬라이드용 2~3문장처럼 길이를 달리한다.
고지문은 내 작업 과정에 대한 주장이므로 “모든 인용을 확인함” 같은 문장이 실제 행동과 일치하는지 직접 확인한다.
프로젝트마다 구조는 같게 쓰되 내용은 실제 과정에 맞게 채운다. 복사한 일반 문구는 가치가 낮다.
결과물을 책임지는 수준은 작성자가 정한다. 요약만 요청했다면 그 사실을 밝히고 독자가 신중히 읽도록 안내하는 방식도 가능하다.
조직에서 쓰려면 템플릿과 워크플로우에 고지문을 포함한다.
AI 사용 공개가 위험하게 느껴지는 조직에서는 사람들이 AI 사용을 멈추거나 사실대로 말하지 않게 된다. 그래서 관리자가 자기 결과물에 먼저 붙여 공개가 정상임을 보인다.
AI 사용을 본질적으로 의심하는 정책은 책임 있는 사용에 필요한 정직성을 떨어뜨린다.
정책이 없는 조직에서도 개인 기준으로 먼저 쓰면 이후 조직 정책에 영향을 줄 수 있다. 이 글의 5.2절 템플릿 마지막 항목에 고지문을 붙이는 방식으로 쓸 수 있다.
6.4 AI Fluency for Builders
AI Fluency for Builders 강좌는 제품 담당자, 엔지니어, 메이커를 위한 과정이다. 같은 4D를 고객 문제 정의부터 출시까지 적용한다.
하나의 사례(진료소 대기 시간 확인 도구)를 레슨마다 이어서 만들고, 첫 레슨의 빌더 브리프(builder brief, 제품, 역할, 제약, AI 개입 범위를 적은 시작 문서)를 이후 실습에서 재사용한다.
Anthropic과 CodePath가 공동 제작했고 8문항 퀴즈에서 80% 이상이면 수료 배지를 받는다.
코드가 동작해도 제품이 틀릴 수 있으므로 설명, 분별, 성실 단계에서 원인을 거슬러 올라가 확인한다. 단계마다 자동화, 증강, 대리 중 협업 방식을 고른다.
퀴즈는 4D와 빌더 도구상자, AI로 제품 요구사항과 인수 테스트(acceptance test, 요구사항 충족 여부를 합격과 불합격으로 가리는 테스트) 쓰기, AI 결과물 평가를 다룬다. 빌더는 문제 발견부터 출시까지 전 과정을 맡고, 4D가 모든 레슨의 기준이다.
4D 프레임워크는 두 고리로 나뉜다. 설명과 분별은 일상 대화의 안쪽 고리이고, 위임과 성실은 AI 사용 필요성과 책임을 다루는 바깥 고리다.
4D 레슨의 실습은 빌더 브리프를 4D로 분류하는 것이다. 연구에서 설명 기술은 가장 자연스럽게 익히지만, AI 추론 의문 제기, 사실 확인, 누락 맥락 파악은 가장 드문 행동으로 관찰됐다.
같은 레슨 영상은 기밀 데이터를 다룰 때 AI 시스템의 개인정보와 보안 기능을 따져야 한다고 설명한다.
영상은 AI를 능력은 있으나 매우 글자 그대로 따르는 협업자로 소개한다. 새벽 2시 장애 같은 출시 현실은 AI가 먼저 알려주지 않는다고 경고한다.
4D를 만든 교수 두 명의 인명 철자가 자막에 Heller, de Kony로 적혀 있어 정확한 표기는 확인이 필요하다.
핵심 관점은 빌더 도구상자다. 도구상자는 공감, 설계, 아키텍처, 구현, 판단, 출시의 6가지이고, AI는 중간인 구현에 가장 강하며 양 끝인 공감, 판단, 출시에 약하다.
구현이 빨라질수록 사람의 가치는 주변 작업으로 이동한다.
| 단계 | 내용 |
|---|---|
| 위임 | 위임은 AI 사용 필요성이 아니라 문제를 분해하고 단계별 AI 역할을 정하는 일이다. 구현 위임은 대체로 안전하고 판단 위임은 권하지 않는다. 위임은 일 자체와 도구를 함께 보는 일이다. 일상 상태 보고 초안은 AI에 맡기고 민감한 협상 이메일의 어조는 직접 쓰는 예가 나온다. 진료소 사례에서는 문제 브리프, 위임 계획, 인수 테스트(acceptance test, 요구사항 충족 여부를 합격과 불합격으로 가리는 테스트) 5~7개를 작성한다. 접수 직원이 환자 문의 때문에 하루 40번 휴대폰을 확인하는 모습은 AI가 관찰할 수 없는 공감의 사례이고, 구현 단계에서 테스트와 성공 기준이 없으면 앞 단계를 건너뛴 것이라고 지적한다. |
| 설명 | 사용자 음성, 제품 요구사항, 기술 명세, AI 지시, 테스트로 이어지는 번역 사슬의 각 연결에서 빌더가 번역자다. 대기 시간 요구를 모바일 웹페이지, 추정치, 5분 업데이트 주기로 좁히는 과정이 예로 나온다. 인수 테스트는 통과 여부가 분명해 오독되지 않는 가장 강한 설명이다. 실무에서는 코드 작성 전에 외부인이 합격과 불합격을 가릴 수 있는 인수 테스트를 쓰고 AI 프롬프트와 함께 전달한다. 요약 지시를 임원 대상, 가장 영향 큰 발견 3개, 300단어 이내로 구체화하는 예도 있다. |
| 분별 | 코드 분별은 5가지 관점으로 AI 결과물을 평가한다. 파트너 사용자 테스트로 나온 개선점 세 가지를 관점별로 분류하는 실습이 있다. |
| 성실 | 결과물이 아니라 결과 전체를 소유하는 일이다. AI가 내린 가정과 트레이드오프, 보안 위험을 AI에게 질문하고, PR 설명에 AI 작성 사실과 작성 비율을 정보로 밝히며, 테스트, 관측성, 기능 플래그를 빠른 출시의 안전망으로 둔다. |
레슨 요약은 사용자 음성에서 AI 지시까지를 4단계 사슬로 부르고, 과정 소개는 테스트까지 포함해 5개 항목으로 나열한다. 두 표현이 달라서 정확한 경계는 확인이 필요하다.
설명 레슨 실습은 요구사항, 명세, 테스트를 쓰고 처음 구현해 파트너에게 시연하는 것이다.
설명 사슬에서 테스트가 통과하는데 사용자가 불만이면 실패 위치는 사용자 이해, 요구사항, 명세, 프롬프트 중 하나다. 대개 프롬프트 상류다.
코드 분별의 5가지 관점은 기능 완전성, 운영 준비, 문제 적합성, 경험 품질, 책임 있는 영향이다. 기능 완전성에서 그치지 않고 나머지 네 관점까지 본다.
과거 데이터의 편향을 AI가 표시 없이 숫자로 재현할 수 있는 점도 사례로 든다.
테스트는 코드와 함께 작성하게 하고, 부하와 지연 같은 운영 가정을 AI에게 직접 물어 드러낸다.
대기 시간이 10분에서 90분으로 급변하는 경우, API 응답이 5초 지연될 때 화면이 멈추거나 오래된 값을 보이는 경우가 예다.
환자가 실제로 원한 것은 20분 내 소아과 진료 가능 유무였다는 문제 적합성 사례도 나온다.
결함을 발견했을 때 직접 고치는지, 설명을 다시 쓰는지를 스스로 관찰하라는 점이 분별 레슨에 있다.
UX 분별은 구현이 빨라질수록 경험이 차별점이 된다는 전제에서 출발한다. 원칙은 명확성, 위계와 점진적 공개, 접근성, 피드백과 응답성의 4가지다.
“보기 좋게”는 소망일 뿐 명세가 아니라서 가장 큰 글자로 대기 시간 표시 같은 구체 지시가 필요하다. 대기 시간을 가장 큰 글자로, 상태는 한 가지 색으로, 업데이트 시각을 보이게 하라는 지시가 좋은 설명이다.
“복잡해 보인다”는 동료용 비평은 AI에게는 쓸모없는 지시다. 접근성은 AI가 기본으로 챙기지 않으므로 명시하고 점검한다.
성실 레슨은 AI가 결정을 숨기지 않게 가정과 트레이드오프, 보안 위험을 질문하라고 한다. 사용자가 다른 사용자의 파일을 볼 수 없는지 AI에게 재확인시키는 예가 나온다. 폐기된 API를 자신 있게 쓰거나 코드베이스와 어긋나는 AI 특유의 실수를 리뷰어가 알도록 PR에 AI 작성 사실을 밝힌다.
관측성(observability, 로그, 오류 추적, 대시보드로 시스템 상태를 확인하는 것)과 기능 플래그(feature flag, 코드를 배포한 뒤 기능 공개 여부를 설정으로 켜고 끄는 방식)는 AI 시대에도 안전망이다. 이해하지 못한 코드의 소유자가 될 수 있다는 점이 문제로 제시된다.
마지막 레슨은 이번 주에 처리할 실제 업무 하나를 4D로 처리하는 최종 과제를 낸다. 3개월째 요청된 기능, 프로토타입, 스프레드시트의 사용자 피드백 중 하나를 고르라고 안내하고, 자료 섹션의 청사진을 시작점으로 안내한다.
4D는 순서가 아니라 오가며 쓰는 것이다.
증거가 부족하면 만든 것을 스스로 폐기할 수 있어야 한다. 이미 들인 비용(매몰 비용) 때문에 만든 것을 놓지 못하는 점을 경계한다.
출시 전에는 이해 정도, 엣지 케이스 테스트, 출시 후 확인 방법을 점검한다. 프로젝트 시작 시 제품, 역할, 제약, AI 개입 범위를 적은 빌더 브리프를 매 세션 첫 입력으로 붙여 넣는 방식이 실무 적용으로 제시된다.
생성형 AI 레슨은 트랜스포머(Transformer, 문장 속 단어 사이 관계를 한꺼번에 계산하는 신경망 구조), 방대한 데이터, 연산 자원이 LLM을 가능하게 했다고 설명한다. 강좌는 성능이 확장 법칙(scaling law, 규모를 키우면 성능이 예측 가능하게 오르는 경향)으로 오른다고 설명한다.
다루는 한계는 지식 기준일과 환각(hallucination, 없는 사실을 그럴듯하게 지어내는 현상)이다. 이어서 컨텍스트 창(context window, 모델이 한 번에 볼 수 있는 텍스트 길이) 한계, 비결정성(같은 입력에도 출력이 달라지는 성질), 복잡한 추론 약점이다. 익숙한 코딩 주제로 모델의 한계를 직접 시험하는 실습을 포함한다.
영상은 2017년 트랜스포머, 데이터 폭증, GPU와 TPU 연산의 세 요인이 겹쳤다고 설명한다. 단계적 추론 같은 능력은 규모가 커지며 창발했다고 한다.
한계 완화책으로 temperature(출력의 무작위성을 조절하는 설정값) 설정을 소개한다. 검색 증강 생성(RAG, 외부 자료를 찾아 모델 입력에 넣는 기법)과 추론 특화 모델도 소개한다.
6.5 AI Fluency 강좌 세부
Framework & Foundations 강좌는 Rick Dakan 교수와 Joseph Feller 교수가 만든 프레임워크를 Anthropic과 함께 강의로 만든 과정이다. 유행하는 프롬프트 기법보다 오래 쓰이는 역량에 초점을 둔다.
레슨은 개념 소개, 생성형 AI 기술 배경, 4D별 심화, 프로젝트 실습, 수료 퀴즈 순서다.
10문항 퀴즈에서 80% 이상이면 수료 배지를 받는다. 퀴즈는 AI 유창성의 의미, 4D 각 역량의 내용, 문제 인식 같은 하위 요소를 묻는다.
영상 자막은 Joe Feller, Drew Bent, Rick Dacon, Maggie Vo 네 명이 소개하는 형식이고 레슨마다 발표자가 달라진다. 자막의 Rick Dacon 표기는 Dakan과 달라서 정확한 표기는 확인이 필요하다.
소개 영상은 조직이 전략 없이 AI를 도입하는 현상, 사용자가 이해하지 못한 시스템에 좌절하는 현상, 가능한 일과 편한 일 사이의 간극을 배경으로 제시한다.
AI 접근 권한이 있다고 책임 있게 쓰는 것은 아니라는 점이 출발점이다.
이 강좌는 AI 기술 자체가 아니라 사람이 AI와 협업하는 방식을 다룬다. 첫 실습은 언어 모델에 접근할 준비를 하고 지금까지의 AI 사용 경험을 되돌아보는 것이다.
Framework & Foundations 강좌는 4D를 세 하위 요소씩으로 나눈다. 위 2절의 표는 이 구조의 요약이다.
| 역량 | 하위 요소 | 내용 |
|---|---|---|
| 위임 | 문제 인식, 플랫폼 인식, 작업 위임 | 목표와 필요한 작업을 먼저 정의하고, 여러 AI 시스템의 강점과 한계를 알고, 자동화, 증강, 대리, 사람 전담으로 나눈다. 모델마다 프롬프트 지시 이행 정도가 가장 크게 갈릴 수 있어서 여러 모델을 써 보는 것도 연습이다. 문제 인식이 부족하면 AI 결과를 평가하거나 사람이 개입할 시점을 알기 어렵다. 위임의 기반은 AI가 아니라 본인 전문성이며, 단순하지만 시간이 드는 영역, 사고 파트너가 필요한 영역, 자료가 부족한 영역, 비판적 판단이 필요한 영역으로 일을 나누라고 안내한다. AI 시스템은 가능한 한 직접 써 보며 파악하라고 권한다. |
| 설명 | 제품, 과정, 행동 설명 | 결과물의 내용, 형식, 대상, 스타일. AI가 접근할 방식(매뉴얼식 일반 지침, 요리책식 단계 지시, 예시 시연). 간결함이나 비판적 태도 같은 상호작용 방식이다. 로고 만들어 달라고 하는 대신 회사 가치, 대상, 색상을 설명하는 예, 튜터 AI에게 정답 대신 단계별 풀이를 요청하는 예가 나온다. AI는 데이터베이스나 자판기가 아니라 맥락에 따라 다르게 행동하는 상호작용 시스템이라고 강조한다. |
| 분별 | 제품, 과정, 행동 분별 | 정확성과 적합성, 추론 오류나 순환 논리 같은 사고 과정, 소통 방식을 평가한다. 피드백은 문제, 이유, 개선 제안, 지시나 예시 수정으로 구성한다. 문제가 보이면 설명을 고치고 경우에 따라 위임 결정도 다시 세운다. 과정 분별의 사례로 다섯 개 개요 중 하나를 다듬는 중 버린 아이디어가 다시 들어오는 현상이 나온다. |
| 성실 | 생성, 투명성, 배포 성실 | AI 시스템과 입력 데이터의 선택, AI 역할의 공개, 공유하는 결과물의 사실 확인과 책임이다. 법과 규제가 형성 중이어서 조직 정책과 최신 법규를 계속 확인하는 일이 성실에 포함된다. 민감한 회사 정보를 AI에 넣기 전에 서비스의 데이터 보호 정책과 조직 허용 여부를 확인하는 예, 팀 제안서에서 AI가 도운 부분을 동료에게 알리는 예, 기자가 AI 초안의 모든 사실과 출처를 확인하는 예가 나온다. 채용 공고 작성 시 편향 통제도 성실의 사례로 든다. |
성실 심화 영상은 운전할 때 안전과 규칙을 함께 살피는 것에 빗대어 설명한다.
AI와의 상호작용 세 방식은 자동화(지시한 작업 실행), 증강(함께 생각하는 협업), 대리(지식과 행동 패턴을 설정해 독립 작동)다. 자동화로 시작하는 사람이 많지만 증강과 대리가 AI의 고유 능력을 더 살려 창의적 결과로 이어지는 경우가 많다고 한다.
대리에서는 사용자가 대본 작가보다 감독에 가까워진다.
영상은 자동화의 예로 문서 요약, 이메일 초안, 여행 일정을, 증강의 예로 막힌 소설 인물 설정 구상을, 대리의 예로 수신 이메일의 주제와 긴급도 분류를 든다. 4D는 이 세 방식 모두에 적용된다.
AI는 도구, 매체, 파트너, 공동 창작자로 동시에 작동할 수 있고, 이 역할 변화 때문에 사용자에게도 새 기술이 필요하다고 설명한다.
프로젝트 실습은 약 1시간 분량의 중간 규모 프로젝트를 골라 이후 레슨 내내 쓴다. Claude와 비전과 성공 기준을 정하고 작업을 쪼개 위임 결정을 담은 계획을 저장한다.
설명과 분별의 반복 고리에서는 그 계획을 불러와 설명, 분별, 개선, 직접 판단 결합의 순환으로 작업을 끝낸다. 최종 결정과 책임은 사용자에게 있다.
레슨별 실습도 따로 있다. 4D 소개에서는 마케팅 이메일, 연구, 창작 시나리오에 4D를 적용해 보고 좋아하는 주제와 새 주제로 Claude와 대화한다. 위임 심화에서는 AI와 대화하며 위임 계획을 세운다.
설명 심화에서는 나쁜 프롬프트를 서로 고쳐 준다. 분별 심화에서는 전문 분야 주제로 세 가지 설명을 받아 비교한다. 성실 심화에서는 프로젝트용 성실 선언문을 쓴다.
효과적인 프롬프트 기법은 여섯 가지다.
- 맥락을 제공한다.
- 예시를 제시한다.
- 출력 제약을 지정한다.
- 단계로 분해한다.
- 먼저 생각하게 한다. 답 뒤가 아니라 답 앞에 생각 공간을 준다. 추론 모델은 기본으로 먼저 생각한다.
- 역할과 어조를 지정한다.
영상 예로는 기후 변화 질문에 인도네시아 농업 연구소 면접 준비라는 목적과 배경을 붙여 구체화하는 경우가 나온다. 기술 문구를 쉬운 말로 바꾸는 예시를 두 가지 제시하는 경우도 나온다.
대표적인 실수는 AI가 의도를 읽는다는 가정, 한 프롬프트에 무관한 과제를 여럿 넣는 일, 성공 기준이 모호한 일, 이전 응답에 피드백이 없는 일이다.
프롬프트 개선을 AI에게 맡기거나, 변형을 요청하거나, 확신도를 묻거나, 새 대화를 시작하는 방법으로 고친다.
기술 배경으로는 2017년 트랜스포머(Transformer, 문장 속 단어 사이 관계를 한꺼번에 계산하는 신경망 구조), 데이터 증가, 연산 증가가 겹쳐 확장 법칙(scaling law, 규모를 키우면 성능이 예측 가능하게 오르는 경향)과 창발 능력(규모가 커지며 갑자기 나타나는 능력, 단계적 추론 등)이 나타났다고 설명한다. 같은 질문도 답이 달라질 수 있는 비결정성이 있고 temperature 설정으로 조절한다.
생성형 AI는 새 콘텐츠를 만들며, LLM은 수십억 개 매개변수를 가진 언어 모델이다. 사전학습(pre-training)으로 다음 텍스트를 예측하고, 미세 조정으로 지시 이행과 무해성을 학습한다.
영상은 프롬프트를 모델이 이어 쓰는 텍스트로 설명한다. 학습된 모델은 데이터베이스에서 답을 꺼내는 것이 아니라 통계적으로 이어질 텍스트를 생성한다고 강조한다. 연산 자원의 예로 GPU, TPU, 클러스터를 든다.
능력 쪽 강점은 다양한 언어 작업, 대화 맥락 유지, 외부 도구 연동이다. 한계는 지식 기준일과 환각, 컨텍스트 창 제한, 비결정성, 다단계 추론 약점이다. 검색 증강 생성(RAG, 외부 자료를 찾아 모델 입력에 넣는 기법) 같은 보완 기법이 연구되고 있다.
영상은 2024년 11월 기준일 모델은 그 이후를 모른다는 예로 설명한다. 인터넷이 없는 수련회에 들어간 사람과 사내 데이터베이스에 접근하지 못하는 유능한 동료를 한계의 비유로 든다.
인간의 판단력과 AI의 속도와 규모가 서로 보완한다고 정리한다.
결론 레슨은 4D가 한 번에 익혀지지 않고 연습으로 자란다고 말한다.
목표는 완벽이 아니라 인식과 의도를 계속 키우는 일이다. 전문성과 판단이 위임의 기반이고 분별은 생략할 수 없는 책임이다.
AI는 만능 해법이 아니라 사용자가 만든 만큼만 유용하고 안전하다고 맺는다.
마무리 실습은 Claude와 과정을 토론하고 개인 AI 정책과 학습 계획, 프롬프트와 패턴 라이브러리를 만드는 것이다. 추가 활동으로 개인 AI 유창성 계획, 수수께끼 교환, 협력 십자말풀이, 단어 연상, 스무고개 같은 게임이 설명과 분별 연습으로 제시된다.
Builders 강좌의 설명 사슬과 연구 결과는 6.4절에 있다. AI Fluency Index 토론 가이드는 45~60분 분량으로 주제 2~3개와 선택 활동 1개를 고르는 구성이다.
모든 질문을 다룰 필요 없이 팀에 맞는 섹션만 고른다. 선택 활동은 반복 챌린지(15분, 후속 메시지 3회 이상), 허점 찾기(15분), 협업 서문 작성(10분)이다.
반복과 개선이 있는 대화는 다른 행동 비율이 높았다. 목표 명확화 +23.6pp, 예시 제공 +22.6pp, 누락 맥락 파악 +17.1pp, 형식 지정 +16.3pp, 추론 질문 +14.7pp다. 이 관계는 상관이며 인과가 입증되지 않았다. 복잡한 과제가 반복과 숙련 행동을 함께 요구하는 경우도 가능하다.
4D 행동 지표 튜토리얼은 AI Fluency Index가 인용한 행동 전체를 모은 빠른 참조 자료다. 각 행동의 모습과 일상 업무에서 시도할 방법을 담는다. 다만 본문이 위젯이라 행동별 세부를 수집하지 못했고 원문 페이지에서 확인해야 한다.
정리하며
처음 던진 질문들에 대한 답이다.
- AI 활용 능력에는 무엇이 포함되는가? 작업 위임 결정, 요구사항 전달, 결과 검증, 결과에 대한 책임이 모두 포함된다. 프롬프트 작성은 그중 일부다.
- 맡길 작업은 어떻게 나누는가? Automation, Augmentation, Agency로 나누고, 자율성이 높을수록 검증과 책임 부담이 커진다는 점을 기준으로 정한다.
- 틀린 결과는 무엇부터 확인하는가? 오류 유형에 해당하는 모델 특성을 기준으로 확인한다. 이름, 버전, URL 같은 구체적인 값을 먼저 확인한다.
- 잘못된 가정에 동의하는 이유는? 사람의 선호 평가로 학습하는 미세조정 과정에서 생긴 아첨 경향이다. 반박하도록 명시하면 줄어든다.
- 운영 적용 전 무엇을 검증하는가? STG 검증과 롤백 절차다. 이 검증은 적용하는 사람이 수행한다.
- 실제 대화 연구가 보는 부족한 행동은? 사실 확인, 추론 의문 제기, 맥락 누락 확인이다. 결과물이 완성돼 보일수록 줄어든다.
- 확인과 공개는 무엇으로 남기는가? 점검표 스킬,
discernment-nudge스킬, 서브에이전트 적대적 리뷰, 전문가 패널, 출처 표시 프롬프트, 성실성 고지문이다.
이 강의로 8주 스터디를 마쳤고, 이후 AI Engineering 책 스터디를 이어서 진행했다.