AI를 잘 쓰는 법은 일을 잘 설명하는 법이다

이 글은 일반인편과 개발자편이 함께 읽는 챕터 0입니다. 이후 챕터에 나오는 프롬프트와 실습은 복사할 정답이 아니라, 원리를 꺼내기 위한 실험 도구로 씁니다.

1. 같은 메모, 같은 AI, 다른 결과

월요일 운영회의가 끝났습니다. 메모에는 이런 대화가 남았습니다.

지수: 지난달 신청서 입력 오류가 많았어요. 신청 안내문을 고쳐야 할 것 같아요.
태오: 안내문 고치는 건 좋은데, 신청 마감이 다음 주라 그 전에 바뀌어야 의미가 있어요.
지수: 그럼 초안은 제가 한번 볼게요. 법무 검토가 필요한지는 잘 모르겠네요.
은비: 작년에 안내문 바꿨을 때 법무 확인을 받았던 것 같아요. 확실하진 않아요.
태오: 고객센터 FAQ도 같이 바꿔야 하나요?
지수: 그건 다음 회의에서 정하죠.
은비: 오류 유형 통계는 제가 뽑아 둔 게 있어요. 공유 드릴게요.
태오: 좋아요. 일단 안내문을 수정하는 방향으로 가죠.

이 메모를 AI에 넣고 두 번 요청했습니다. 한 번은 “정리해 주세요”라고만 썼고, 한 번은 무엇을 나누고 무엇을 지어내면 안 되는지 세 줄을 덧붙였습니다. 메모는 실제 회의가 아닌 합성 자료이고, 같은 모델로 한 번씩 실행했습니다.

요청 A — “아래 회의 메모를 정리해 주세요.”

결과는 깔끔했습니다. 결정 사항과 미해결 사항을 나누고, 마지막에 “담당자·기한이 명확히 정해지지 않은 항목이 있다”는 경고까지 붙였습니다. 그런데 할 일 표에는 이런 행이 있었습니다.

회의에서 누구도 법무 확인을 맡지 않았고, 기한도 정하지 않았습니다. 표는 그 빈칸을 “전체”와 “마감 전”으로 채웠습니다. “전체”가 맡은 일은 누가 챙길지 불분명해지기 쉽습니다.

요청 B — 같은 요청에 세 줄을 더했습니다.

- 여러 사람의 발언에서 결정 사항, 근거, 담당자, 기한, 미결 질문을 분리합니다.
- 원문에 없는 담당자와 기한은 추정하지 말고 "미정"으로 표시합니다.
- 외부에 공유하기 전에 참석자 확인이 필요한 항목을 표시합니다.

이번에는 법무 검토가 담당자 표가 아니라 “미결 질문”으로 갔습니다. 그리고 요청 A에는 없던 행이 하나 생겼습니다(표는 일부 줄였습니다).

지수는 초안을 “한번 보겠다”고 했을 뿐, 안내문을 실제로 고칠 사람은 정해지지 않았습니다. 요청 B는 이 빈칸을 드러냈습니다. 다음 주 마감이 걸린 일에서 가장 먼저 물어야 할 질문입니다.

두 번째 요청에 들어간 세 줄은 AI 전용 주문이 아닙니다. 경험 많은 팀원이 회의록을 정리할 때 머릿속에서 쓰는 기준을 글로 꺼낸 것입니다. 이 글은 그 기준을 꺼내는 방법에 관한 이야기입니다.

한 번씩 실행한 비교이므로 요청 A가 항상 빈칸을 채운다거나 요청 B가 항상 더 낫다고 말할 수는 없습니다. 다만 이번 차이가 어디서 왔는지는 분명합니다. AI가 바뀐 것이 아니라, 요청에 담긴 일의 구조가 바뀌었습니다.

2. 이 글에서 얻을 것

AI를 잘 쓰는 법을 검색하면 대개 프롬프트 작성법이 나옵니다. 역할을 부여하고, 배경을 자세히 쓰고, 출력 형식을 정하라고 합니다. 더 나아가면 에이전트(Agent, 도구를 써 가며 여러 단계를 스스로 진행하는 AI 시스템)를 만들고 역할을 나누는 방법으로 이어집니다.

이런 방법은 유용합니다. 다만 순서가 거꾸로 되면 문제가 생깁니다. 형식부터 외우면 무엇을 알려야 하는지는 늘어나는데 왜 알려야 하는지는 남지 않습니다. 모델이나 업무가 바뀌면 다시 “좋은 프롬프트”를 찾게 됩니다.

이 시리즈의 출발점은 다음 한 문장입니다.

AI를 잘 쓴다는 것은 특별한 주문을 외우는 일이 아니라, 내가 하는 일을 설명하고 나누고 확인할 수 있는 형태로 전달하는 일입니다.

이 글을 읽고 나면 다음을 할 수 있습니다.

• AI가 내 의도를 모르는 이유를 “프롬프트 실력” 하나로 돌리지 않고, 양쪽의 지식 차이로 설명합니다.
• 반복하는 업무 하나에서 목적·입력·판단 기준·예외·완료 조건을 꺼내 적습니다.
• 앞으로 이 시리즈에 나올 프롬프트와 실습을 “복사할 정답”이 아니라 “원리를 꺼내는 실험”으로 읽습니다.

특정 AI 제품의 사용법이나 성능 비교는 다루지 않습니다. 마지막 실습은 AI 없이 15~30분이면 할 수 있고, 원하면 AI로 전후 비교까지 해 볼 수 있습니다.

3. AI가 똑똑한데 왜 내 마음은 모를까

오늘의 AI는 한 사람이 평생 읽기 어려운 범위의 지식과 표현을 다루고, 요약·번역·분류·초안 작성처럼 많은 일을 사람보다 훨씬 빠르게 해냅니다.

그렇다고 AI가 지금 내 회사에서 왜 이 일이 생겼는지까지 아는 것은 아닙니다. 폭넓은 일반 지식과 현장의 맥락은 다른 문제입니다. 빠르게 답을 만드는 능력과 그 답의 결과를 책임지는 일도 다릅니다.

AI는 여러분이 지난달 회의에서 한 약속을 모릅니다. 상사가 “적당히 정리해 주세요”라고 할 때 기대하는 형식도, 문서에 적히지 않은 조직의 금기도, 틀렸을 때 감당할 비용도 알려 주지 않으면 알 수 없습니다. 앞의 회의 메모에서 요청 A가 “전체”라는 담당자를 적은 것도, 이 팀에서 누가 법무 확인을 챙기는지 알 방법이 없었기 때문일 수 있습니다.

반대 방향의 빈칸도 있습니다. 사용자는 AI가 어떤 자료를 볼 수 있는지, 어디까지 추정하는지, 무엇을 실행할 수 있는지 모를 때가 많습니다.

그래서 AI가 의도를 모르는 이유를 전부 “프롬프트를 못 썼기 때문”이라고 볼 수는 없습니다. 모델의 한계일 수도 있고 과업 자체가 모호할 수도 있습니다. 다만 내가 원하는 일을 나조차 구조적으로 설명하지 못한다면, 어떤 모델을 써도 안정적으로 맡기기 어렵습니다.

미국 국립표준기술연구소(NIST)의 AI 위험관리 프레임워크도 AI의 성능만 보지 말고, 사용 목적과 맥락, AI가 지원할 과업, 사람이 결과를 감독하는 방법을 함께 정의하라고 권합니다. 조직을 위한 지침이지만, 개인이 AI에 일을 맡길 때도 방향은 같습니다.

4. 먼저 내 일을 추상화합니다

여기서 개발에서 자주 쓰는 단어 하나를 빌리겠습니다. 추상화(abstraction)입니다. 어렵게 들리지만 우리는 이미 매일 하고 있습니다.

요리를 처음 배울 때는 “팬을 30초 달군 뒤 양파 반 개를 넣는다”처럼 그대로 따라 합니다. 경험이 쌓이면 “수분을 날려 단맛을 끌어낸다”는 원리를 알게 됩니다. 그러면 팬이 바뀌고 양파 양이 달라져도 불과 시간을 조절할 수 있습니다. 구체적인 행동에서 반복되는 목적과 판단 기준을 꺼낸 것, 그것이 추상화입니다.

AI에게 일을 맡기려고 “나를 추상화한다”는 말은 내가 아는 모든 것을 입력한다는 뜻이 아닙니다. 내가 그 일을 처리할 때 반복해서 쓰는 구조를 밖으로 꺼내는 일입니다.

• 이 업무의 목적은 무엇인가?
• 어떤 입력을 믿는가?
• 어떤 순서로 판단하는가?
• 무엇을 예외로 다루는가?
• 결과가 맞는지 무엇과 대조하는가?
• 어디까지 하면 끝인가?
• 어떤 결정은 반드시 내가 내려야 하는가?

“회의록을 정리한다”는 업무의 이름입니다. 앞에서 요청 B에 덧붙인 세 줄이 이 업무를 추상화한 설명입니다.

여러 사람의 발언에서 결정 사항, 근거, 담당자, 기한, 미결 질문을 분리한다. 원문에 없는 담당자와 기한은 추정하지 않는다. 외부 공유 전에는 참석자가 확인한다.

이 설명에는 특정 회의의 문장이 하나도 없습니다. 대신 다음 회의에도 쓸 목적, 판단 기준, 예외, 확인 절차가 들어 있습니다. 좋은 프롬프트는 이런 추상화의 결과일 수 있지만, 프롬프트 문장 자체가 원리는 아닙니다. 모델이 바뀌면 문장은 달라져도 “없는 담당자를 만들지 않는다”는 판단은 그대로 남습니다.

5. 책임을 나누는 기준은 ‘바뀌는 이유’입니다

회사는 재무·인사·개발·운영을 아무 이유 없이 나누지 않습니다. 급여 계산 규칙은 재무 사정 때문에 바뀌고, 개인정보 보관 규칙은 법무 사정 때문에, 서버 접근 방식은 보안 사정 때문에 바뀝니다. 서로 다른 이유로 바뀌고 서로 다른 사람이 책임지는 판단을 한 덩어리로 묶으면, 하나를 고칠 때 관계없는 부분까지 흔들립니다.

소프트웨어 설계에서는 이 생각을 단일 책임 원칙(Single Responsibility Principle, SRP)이라고 부릅니다. 흔히 “한 번에 한 가지 일만 한다”로 알려져 있지만, 이 원칙을 정리한 Robert C. Martin의 설명은 조금 다릅니다. 같은 이유로 바뀌는 것은 모으고, 다른 이유로 바뀌는 것은 나누라는 것입니다.

이 생각을 AI 업무에 옮기면 “AI를 여러 개 만들라”는 결론이 나오지 않습니다. 중요한 것은 개수가 아니라 경계입니다. 예를 들어 AI 하나에 다음을 한꺼번에 맡길 수 있습니다.

1. 자료를 찾는다.
2. 사실인지 판단한다.
3. 보고서를 쓴다.
4. 공개해도 되는지 승인한다.
5. 고객에게 보낸다.

한 화면에서 모두 할 수 있다는 사실과 한 책임으로 묶어도 된다는 판단은 다릅니다. 검색 기준, 사실 확인 기준, 문체, 공개 승인, 발송 권한은 모두 다른 이유로 바뀌고 다른 사람이 책임집니다. 나눈다고 AI를 다섯 개 만들 필요는 없습니다. 같은 대화 안에 확인 단계를 두거나, 발송 권한만 막아 두는 것으로도 충분할 수 있습니다. 핵심은 다음 질문입니다.

이 판단은 무엇 때문에 바뀌고, 누가 그 결과를 책임지는가?

6. 자연어로 일을 설계하는 시대

우리는 운전하려고 엔진을 직접 조립하지 않고, 프로그램을 쓰려고 0과 1을 읽지 않습니다. 복잡한 내부를 감추고 목적에 맞는 조작 방법이 생길 때 기술은 더 많은 사람에게 내려옵니다.

AI가 만든 큰 변화 중 하나는 자연어가 강력한 조작 방법이 됐다는 점입니다. 예전에는 컴퓨터에 일을 시키려면 메뉴를 누르거나 프로그래밍 언어로 절차를 써야 했습니다. 이제는 목적, 입력, 제약, 출력 형식, 완료 기준을 말로 전달할 수 있습니다.

그래서 이 시리즈는 이것을 자연어로 하는 개발이라고 부르려 합니다. 공식 용어는 아닙니다. 모든 대화가 프로그래밍이라는 뜻도, 말 한 줄이 코드처럼 정확하다는 뜻도 아닙니다. 다만 하는 일의 모양은 점점 닮아 가고 있습니다.

모두가 개발자가 되어야 한다는 말이 아닙니다. 개발에서 오래 다뤄 온 목적·추상화·책임·확인이라는 사고를 이제 누구나 자기 일에 쓸 수 있게 됐다는 뜻입니다.

7. 이 시리즈의 예시는 정답이 아니라 실험 도구입니다

앞으로 각 챕터에는 프롬프트와 실습이 나옵니다. 요청 카드를 만들고, 자료를 조사하고, 반복 업무를 자동화합니다. 그 예시를 그대로 복사해 같은 결과를 얻는 것이 목표는 아닙니다. 프롬프트는 특정 시점의 모델·자료·업무에 맞춘 구체적인 구현이라서, 자료가 달라지면 결과도 달라집니다.

각 챕터에서 가져갈 것은 예시 뒤에 남는 구조입니다. 이 시리즈는 모든 챕터를 같은 흐름으로 씁니다.

1. 구체 사례: 어떤 자료로 무엇을 요청했는가?
2. 직접 관찰: 실제로 무엇이 나왔고 무엇이 비었는가?
3. 추상화한 원리: 제품명과 문구를 지워도 남는 판단은 무엇인가?
4. 경계와 반례: 이 원리는 어떤 업무에서 깨지는가?
5. 내 업무로 전이: 내 일에 옮기려면 무엇을 다시 정해야 하는가?

한 사례에서 원리를 꺼내는 것이 추상화라면, 그 원리를 다른 사례에 적용해 보는 것은 전이(transfer)입니다. 회의록 원리를 고객 상담 기록에 옮겼는데 맞지 않는다면, 원리를 잘못 꺼냈거나 새 업무의 중요한 조건을 빠뜨린 것입니다. 어느 쪽이든 실패는 원리를 고칠 재료가 됩니다.

그렇다고 일반론만 반복하지는 않겠습니다. 구체적인 사례 없이는 원리가 실제로 작동하는지 확인할 수 없습니다. 그래서 각 챕터는 실제 자료나 안전한 합성 자료로 작은 실험을 하고, 관찰한 것과 해석한 것을 나눠 적습니다.

8. 독자 실습: 내 업무를 한 단계 추상화하기

최근 두 번 이상 반복한 업무 하나를 고릅니다. 1530분이면 충분합니다. 13단계는 종이로 해도 됩니다. 실제 개인정보나 내부 자료는 외부 AI에 넣지 마세요.

1단계: 가장 최근의 한 건을 적습니다

• 무엇이 들어왔습니까?
• 무엇을 만들었습니까?
• 어떤 순서로 처리했습니까?
• 어디서 망설였습니까?
• 누가 결과를 확인했습니까?

2단계: 반복되는 구조를 꺼냅니다

예를 들어 이번 한 건이 “9월 둘째 주 영업회의 발표 정리”였다면, 남을 원리는 “발언자별 요약”이 아닐 수 있습니다. 회의의 목적이 실행 관리라면 “결정·담당자·기한·미결 질문을 나누고 원문에 없는 값은 미정으로 둔다”가 더 맞는 원리입니다.

3단계: 경계를 적습니다

• 이 원리를 쓰면 안 되는 업무는 무엇입니까?
• 자료가 부족할 때 추정하면 안 되는 것은 무엇입니까?
• 결과를 밖으로 보내기 전에 어디서 멈춰야 합니까?

4단계(선택): AI로 전후를 비교합니다

개인정보가 없는 연습용 자료를 하나 만듭니다. 먼저 업무 이름만으로 요청하고(“정리해 주세요”), 다음에는 2단계에서 적은 원리를 덧붙여 요청합니다. 두 결과에서 다음을 비교합니다.

• 원문에 없는데 채워진 값이 있습니까?
• 사람이 결정해야 할 빈칸이 드러났습니까?
• 원리를 덧붙였는데도 달라지지 않은 부분은 무엇입니까?

완료 기준

• 이번 한 건의 내용과 반복해서 남을 원리를 구분했습니다.
• 원리에 목적·판단 기준·예외·완료 조건이 들어 있습니다.
• AI가 맡을 부분과 사람이 확인·결정할 부분을 표시했습니다.
• 이 원리를 그대로 쓰면 안 되는 조건을 하나 이상 적었습니다.

4단계를 했다면 결과가 예상과 달라도 괜찮습니다. 무엇이 달랐는지 적어 두는 것이 이 실습의 결과물입니다.

9. 핵심 정리와 다음 연결

• AI가 내 의도를 모르는 것은 양쪽 모두에 빈칸이 있기 때문입니다. 나는 맥락을 알려 주고, AI가 어떤 조건에서 답했는지 확인해야 합니다.
• 좋은 요청은 업무를 추상화한 결과입니다. 목적·판단 기준·예외·완료 조건을 먼저 꺼내면 문장은 따라옵니다.
• 책임은 개수가 아니라 “바뀌는 이유와 책임자”를 기준으로 나눕니다.
• 이 시리즈의 프롬프트와 실습은 정답이 아니라 원리를 꺼내는 실험 도구입니다.

AI를 잘 쓰는 사람은 프롬프트를 많이 외운 사람이 아니라, 자신의 일을 설명하고 경계를 정하고 결과를 확인할 수 있는 사람입니다.

일반인편 챕터 1에서는 첫 번째 구체적인 질문으로 들어갑니다. “그래서 AI에게 무엇을 맡길 것인가?” 업무를 AI에게 맡길 것, 사람이 확인할 것, 사람이 직접 결정할 것으로 나누면서 이 글의 추상화와 책임 나누기를 실제 표로 바꿉니다.

개발자편 챕터 1(준비 중)에서는 같은 전제를 시스템 구조로 봅니다. 모델이 만들어 내는 것과 프로그램·도구가 실제로 실행하는 것을 나눠, 말로 한 요청이 어디까지 실제 행동이 되는지 살펴봅니다.

출처와 확인 환경

소프트웨어 설계 자료는 AI 사용법의 직접 증거가 아닙니다. 일반 업무에 비유할 때 원래 의미를 벗어나지 않았는지 확인하는 데 사용했습니다.

1절 회의 메모 비교 실험

• 자료: 합성 운영회의 메모(실제 인물·조직 아님)
• 도구: Claude Code CLI 2.1.270 비대화형 모드, 도구 사용 끔, 사용자·프로젝트 설정 제외
• 모델: claude-sonnet-5
• 시스템 지시: “당신은 업무를 돕는 AI 어시스턴트입니다.”
• 반복: 조건별 1회, 실행일 2026-09-14
• 한계: 한 번씩 실행한 설명용 비교입니다. 다른 모델이나 채팅 서비스에서는 결과가 다를 수 있습니다. 본문의 표는 출력에서 발췌했습니다.

검증 정보

1절의 실험은 직접 실행해 입력과 출력 전문을 보존했습니다. 추상화·단일 책임 원칙·NIST 관련 내용은 원자료를 확인해 일반 업무 비유와 구분했습니다.

“자연어로 하는 개발”과 “나를 추상화한다”는 표현은 외부 자료의 정식 정의가 아니라 이 시리즈의 관점입니다. AI와 사람의 능력을 하나의 순위로 비교하는 주장은 쓰지 않았습니다.