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

이 글은 일반인편과 개발자편이 함께 읽는 첫 글입니다.

1. AI가 정리한 회의록, 어디가 이상할까요

월요일 운영회의가 끝났습니다. 메모에는 이런 대화가 남았습니다. 실제 회의가 아니라 설명을 위해 만든 합성 자료입니다.

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

이 메모를 AI에 넣고 “아래 회의 메모를 정리해 주세요.”라고만 요청했습니다. 결과는 깔끔했습니다. 논의 배경, 결정 사항, 미해결 사항, 할 일 표가 나왔고, 끝에는 담당자와 기한이 명확하지 않은 항목이 있다는 참고 문구도 붙어 있었습니다.

할 일 표는 이랬습니다.

메모와 한 줄씩 맞춰 보면 아래 두 줄이 걸립니다.

• 법무 검토 필요 여부 확인: 회의에서 이 일을 맡은 사람은 없었습니다. 표에는 담당자가 “전체”, 기한이 “마감 전”으로 적혀 있습니다.
• FAQ 수정 여부 결정: 회의는 “다음 회의에서 정하죠”로 끝났는데, 표에서는 “전체”가 맡은 할 일이 됐습니다.

함께 회의에 들어갔던 팀원이 정리했다면 누가 맡기로 했는지 기억나지 않는 칸을 비워 두거나 “아직 안 정함”이라고 적었을 겁니다. 요청에는 그런 기준이 한 줄도 들어 있지 않았습니다.

2. 평소 쓰던 기준을 요청에 적어 봤습니다

회의록을 정리할 때 우리가 말하지 않고 지키는 기준이 있습니다. 메모의 발언과 짝지어 보면 세 가지가 보입니다.

실제로 보낸 요청은 다음과 같습니다.

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

3. 같은 메모에서 무엇이 달라졌을까요

같은 메모와 같은 모델로 두 요청을 한 번씩 실행했습니다. 두 결과에서 담당자와 할 일 부분만 옮기고, 달라진 곳에 번호를 붙였습니다.

②가 특히 쓸모 있습니다. 지수는 초안을 “한번 보겠다”고만 했고, 안내문을 실제로 고칠 사람은 정해지지 않았습니다. 요청 A의 표만 봐서는 이 빈칸이 보이지 않습니다. 요청 B는 이 밖에도 법무 검토 이력처럼 외부에 공유하기 전에 참석자에게 확인할 항목을 따로 모아 두었습니다.

그 결과 다음 회의에서 물을 질문이 분명해졌습니다.

• 안내문을 실제로 고칠 사람은 누구인가요?
• 다음 주 마감 전 언제까지 고쳐야 하나요?
• 법무 검토가 필요한가요? 필요하다면 누가 확인하나요?

조건마다 한 번씩 실행한 결과라서, 세 줄을 덧붙인 것이 이 차이를 만들었다고 단정할 수는 없습니다. 다만 요청 B의 결과는 덧붙인 세 줄이 요구한 모양을 그대로 따랐습니다.

4. 3분 연습: 기준 한 줄 덧붙이기

[가게 운영 메모 — 연습용 합성 자료]
사장님: 다음 달부터 토요일 영업을 한 시간 늘릴까 해요. 매출 좀 보고 정하죠.
수진: 그러면 아르바이트 시간표는 제가 짤게요.
민호: 단골손님들한테 미리 알려야 할까요?
사장님: 그건 좀 더 생각해 봐요.

- "늘릴까 해요", "생각해 봐요"처럼 확정되지 않은 말은 결정 사항이 아니라 검토 중인 일로 분류합니다.

5. AI는 왜 그 기준을 몰랐을까요

AI는 회의록이 보통 어떤 모양인지 잘 압니다. 요약하고, 결정 사항을 뽑고, 할 일 표를 만드는 일은 빠르고 능숙합니다. AI가 알 수 없는 것은 이 팀의 사정입니다. 법무 확인은 원래 누가 챙기는지, 담당자를 “전체”로 적으면 이 팀에서 어떤 일이 벌어지는지, 이 회의록을 누구에게 보낼지 같은 것들입니다.

사람끼리는 이런 기준을 말하지 않습니다. 같은 팀에서 일하며 이미 알고 있기 때문입니다. AI에게는 그 말하지 않던 기준을 적어 줘야 합니다. 이 글에서는 이것을 업무 기준이라고 부릅니다. 결과가 쓸 만한지 판단할 때 내가 실제로 쓰는 기준입니다.

내 업무 기준은 어떻게 찾나요

업무 기준은 대개 결과를 받아 보고 “이건 아닌데” 싶을 때 드러납니다. 다음 네 질문으로 미리 꺼낼 수 있습니다.

• 이 결과를 누가 받아서 무엇을 하나요? 목적을 알려 줍니다.
• 어떤 상태면 끝났다고 보나요? 완료 기준을 알려 줍니다.
• 모르면 비워 둬야 하는 것은 무엇인가요?
• 밖에 보내기 전에 확인할 것은 무엇인가요?

목적과 완료 기준은 비슷해 보이지만 쓰임이 다릅니다. 회의록이라면 목적은 “다음 회의 전까지 각자 할 일을 알게 한다”입니다. 완료 기준은 “모든 할 일에 담당자와 기한이 있거나 ‘미정’으로 표시돼 있다”입니다. 목적은 요청의 방향을 정하고, 완료 기준은 결과를 받았을 때 바로 점검하는 데 씁니다.

모든 요청에 기준을 붙일 필요는 없습니다. 아이디어를 넓게 뽑거나 문장을 다듬는 일처럼 틀려도 다시 쓰면 되는 일은 짧게 요청해도 충분합니다. 결과를 다른 사람이 쓰거나, 틀리면 곤란한 일일 때 기준을 덧붙이면 됩니다.

6. 완성 예시: 회의록 정리 업무 카드

업무 기준을 한 번 적어 두면 비슷한 일을 할 때마다 다시 쓸 수 있습니다. 1절의 회의록 정리를 카드로 만들면 이렇습니다.

카드를 요청으로 옮기면 다음과 같습니다. 2절의 실제 요청에 목적 한 줄을 더한 형태입니다. 이 요청 자체는 따로 실행해 보지 않은 예시입니다.

아래 회의 메모를 정리해 주세요. 참석자들이 다음 회의 전까지 각자 할 일을 알 수 있어야 합니다.
- 여러 사람의 발언에서 결정 사항, 근거, 담당자, 기한, 미결 질문을 분리합니다.
- 원문에 없는 담당자와 기한은 추정하지 말고 "미정"으로 표시합니다.
- 외부에 공유하기 전에 참석자 확인이 필요한 항목을 표시합니다.

결과를 받으면 카드의 “끝났다고 볼 조건”으로 바로 점검합니다. 할 일마다 담당자와 기한이 있거나 “미정”인지 훑어보면 됩니다.

7. 실습: 내 업무 카드 만들기

15분 정도 걸립니다. 완성 예시를 보고, 빈칸 두 개를 채운 다음, 내 업무로 한 장을 만듭니다.

1단계: 완성 예시 다시 보기

6절의 회의록 카드를 봅니다. 칸마다 한 줄이면 충분합니다.

2단계: 빈칸 두 개 채우기

4절의 가게 메모로 만든 카드입니다. 비어 있는 두 칸을 채워 보세요.

3단계: 내 업무로 한 장 만들기

AI에게 두 번 이상 부탁했거나 부탁하고 싶은 반복 업무를 하나 고릅니다. 회의록, 주간 보고 요약, 고객 문의 분류 같은 일이면 좋습니다.

1. 카드 칸 가운데 내 업무에 필요한 칸만 채웁니다.
2. “요청에 넣을 문장” 칸을 평소 요청 뒤에 붙입니다.
3. (선택) AI를 쓸 수 있다면 기준 없이 한 번, 기준을 붙여 한 번 요청해 두 결과를 나란히 놓습니다. 이때는 회사 내부 자료나 개인정보 대신 이름과 숫자를 바꾼 연습용 자료를 씁니다.

다 했는지 점검하기

• 요청에 덧붙일 기준 문장이 한 줄 이상 있다.
• “모르면 비워 둘 것”을 하나 이상 적었다.
• (3단계 선택을 했다면) 두 결과에서 달라진 줄을 찾았다. 달라진 곳이 없었다면 그 사실도 적어 두었다.

8. 다음 챕터: 기준을 알려 줘도 AI가 할 수 없는 일

이 글에서 한 일을 한 문장으로 줄이면 이렇습니다. 내가 결과를 판단할 때 쓰는 기준을 요청에 적어 주면, 결과에서 사람이 채워야 할 빈칸이 보이기 시작합니다.

그런데 기준을 잘 적어도 AI가 대신할 수 없는 일이 남습니다. 회의록의 “미정” 칸을 채우는 사람은 결국 참석자입니다. 사내 문서를 열어 대조하는 일, 배포를 승인하는 일, 고객에게 메일을 보내는 일도 마찬가지입니다.

일반인편 챕터 1에서는 한 업무 안에서 AI가 만들 부분, 사람이 확인할 부분, 사람이 결정할 부분을 나눕니다. AI가 쓴 환불 답장에서 “즉시 진행 가능”처럼 아무도 확인하지 않은 약속을 찾아 표시하는 장면도 나옵니다.

개발자편 챕터 1(준비 중)에서는 모델이 만든 결과와 프로그램이 실제로 실행하는 동작이 어떻게 나뉘는지 봅니다.

보충: 개발에서 쓰는 말로 보면

이 부분은 읽지 않아도 다음 챕터로 넘어가는 데 지장이 없습니다.

구체적인 사례에서 반복해 쓰는 판단 기준을 꺼내 적는 일을 개발에서는 추상화(abstraction)라고 부릅니다. 2절에서 요청에 덧붙인 세 줄에는 이번 회의의 내용이 들어 있지 않고, 다음 회의록에도 그대로 쓸 수 있는 기준만 들어 있습니다.

목적, 판단 기준, 끝났다고 볼 조건을 말로 적어 일을 맡기는 과정은 개발자가 요구사항을 정리하는 일과도 닮았습니다. 이 시리즈에서는 이것을 자연어로 하는 개발이라고 부르기도 합니다. 공식 용어는 아니고, 요구사항을 정하고 결과를 점검하는 일의 모양이 닮았다는 뜻입니다.

출처와 확인 환경

회의 메모 비교 실험(1~3절)

• 자료: 합성 운영회의 메모(실제 인물·조직 아님)
• 도구: Claude Code CLI 2.1.270 비대화형 모드, 도구 사용 끔, 사용자·프로젝트 설정 제외
• 모델: claude-sonnet-5, 시스템 지시 “당신은 업무를 돕는 AI 어시스턴트입니다.”
• 반복: 조건별 1회, 실행일 2026-09-14
• 표기: 1절 표와 그림 2는 출력에서 발췌했고, 입력과 출력 전문은 원고 기록에 보존했습니다.

4·7절의 가게 메모, 6절의 업무 카드와 목적을 더한 요청은 설명을 위해 만든 예시이며 AI로 실행한 결과가 아닙니다.