최종학 | Kyle Choi NotesFaith · AI · Learning
교육

업무 하나만 정하세요 — 도구 고르기부터 점검까지

디딤 · 2026년 8월 31일

창가 책상 위에 같은 서류 한 장이 네 단계를 거치며 놓여 있는 모습을 담은 차분한 수채화

시작하기 전에 하나만 정해 주세요. 이번 주에 다시 돌아올 업무 중 하나입니다. 회의록 정리든, 메일 초안이든, 자료 요약이든 상관없습니다. 작을수록 좋습니다.

이 글은 그 한 건을 데리고 끝까지 갑니다 — 어떤 도구를 고를지, 무엇을 어떻게 지시할지, 실제 업무에 어떻게 얹을지, 그리고 잘 됐는지 무엇으로 확인할지. 네 단계가 같은 업무 하나를 관통합니다.

읽는 데 15분, 실습에 85분입니다. 오늘 다 하지 않으셔도 됩니다. 대상은 코드를 쓰지 않는 실무자입니다.

이 채널에는 이미 AI 도구 사용법을 다룬 글이 열여섯 편 있습니다. 프롬프트 쓰는 법, 맥락을 설계하는 법, 프로젝트 기능을 쓰는 법, 무엇을 자동화할지 고르는 법까지 있습니다. 그런데 그 열여섯 편 중 어느 것도 업무 한 건을 처음부터 끝까지 같이 가 보지는 않았습니다.

저는 이게 우연이 아니라고 봅니다. 기법을 하나씩 아는 것과, 내 업무 한 건을 도구 고르기부터 점검까지 끌고 가 보는 것은 다른 일입니다. 배울 것이 없어서가 아니라 순서가 없어서 못 붙이는 것입니다. 이 글은 그 순서를 다룹니다.

그래서 이 글은 열일곱 번째 기법 글이 아닙니다. 읽고 끄덕이는 글도 아닙니다. 따라 하면 손에 산출물이 남는 글입니다. 각 단계 끝에 실습이 있고, 그 실습을 하지 않으면 다음 단계로 이어지지 않게 짜여 있습니다.

1. 도구부터 고릅니다 — 세 갈래와 세 질문

AI 도구를 크게 나누면 세 갈래입니다. 제품 이름은 다양하지만, 하는 일의 성격으로 나누면 이렇게 갈립니다.

  • 대화형 — 채팅창에 묻고 답을 받습니다. 매번 맥락을 새로 줘야 하고, 한 걸음씩 사람이 확인하며 진행합니다.
  • 문서·작업공간형 — 프로젝트나 워크스페이스에 지침과 자료를 저장해 두고 반복해서 불러 씁니다. 매번 처음부터 설명하지 않아도 됩니다.
  • 에이전틱 — 찾기→쓰기→보내기처럼 여러 단계를 도구가 대신 수행합니다. 사람은 시작만 시키고, 중간 과정은 도구가 넘나듭니다.

한 실무자는 이 차이를 이렇게 비유합니다. 대화형 도구는 “한 걸음씩, 기다렸다가, 한 도구 안에서만” 움직이는 방식이고, 에이전틱 도구는 사람이 “이메일 하나 써 줘”라고만 해도 “맞는 사람을 찾고, 초안을 쓰고, 적절한 때 보내고, 답이 없으면 알려 주고, 시스템까지 갱신”하는 방식이라고 씁니다(Ryan Marfone, Medium, 2025-11-14).

문서·작업공간형은 이 둘 사이에 있습니다. 국내 실무자 대상의 한 정리 글은 “AI에게 ’나는 보험 스타트업 기획자야, 답할 때는 항상 타겟 고객 관점에서 생각해줘’처럼 상시 지침을 저장해 두는 방식”을 이 갈래의 예로 듭니다(네이버 블로그, kokiorea — 이 글은 해외 필자의 글을 재구성한 2차 콘텐츠라, 프레임만 가져오고 함께 실린 수치는 이 글에 쓰지 않았습니다).

2026년 들어 바뀐 것은 이 경계선의 위치입니다. 한 필자는 “프롬프트가 대화의 상징이 된 건 채팅이 가장 먼저 익숙해진 인터페이스였기 때문일 뿐이다. 워크플로가 한 번 이해되면, 프롬프트는 보통 그 뒤로 사라져야 한다”고 씁니다(zchmael, Substack, 2026-08-08). 반복되는 업무일수록 매번 새로 지시하는 대화형보다, 한 번 설정해 두면 알아서 도는 문서·작업공간형이나 에이전틱 쪽으로 무게가 옮겨 가고 있다는 뜻입니다.

다만 같은 글은 탐색적이고 모호한 업무에는 지금도 대화형이 가장 낫다고 함께 씁니다. 도구가 나아진 게 아니라, 업무 성격에 따라 맞는 자리가 갈린다는 이야기입니다.

이 흐름을 모두가 낙관적으로 보는 것은 아닙니다. 한 커뮤니티 글타래에서는 “이건 90%가 마케팅이고 과대광고다”라는 댓글이, 다른 글타래에서는 “누구나 이걸 쓸 수 있다는 게 아니다 — 모두가 그만큼 기술에 익숙한 건 아니다”라는 반박이 함께 달립니다(Reddit r/productivity, r/smallbusiness, 익명 이용자 댓글 — 조사 아닌 개인 의견입니다). 저는 이 상충을 정리하지 않겠습니다. 도구를 고르기 전에, 기대와 회의가 같이 있다는 것 자체는 알아 두시는 편이 낫습니다.

세 질문으로 고릅니다

세 갈래 중 무엇을 쓸지는 아래 세 질문으로 정합니다. 자기 업무 한 건을 앞에 두고 답해 보세요.

  1. 이 업무는 한 번의 답으로 끝나는가, 아니면 배경지식을 계속 쌓아 가며 반복해야 하는가?
  2. 텍스트만 만들면 끝나는가, 아니면 여러 단계(찾기·쓰기·보내기 등)를 도구가 대신 수행해야 하는가?
  3. 틀렸을 때 내가 바로 알아채고 멈출 수 있는 자리인가, 아니면 도구가 스스로 진행해 버려 늦게 알아채는 자리인가?

1번에 “반복”으로, 2번에 “여러 단계”로 답할수록 문서·작업공간형이나 에이전틱 쪽입니다. 3번에서 “늦게 알아챈다” 쪽으로 답했다면, 지금 단계에서는 그 업무를 에이전틱에 통째로 맡기지 않는 편이 낫습니다. 이유는 3절에서 다룹니다.

실습① 도구 고르기 · 15분

앞에서 정한 반복 업무(또는 이 글이 예로 드는 “반복적으로 오는 문의 답장 초안 쓰기”)를 놓고, 위 세 질문에 직접 답을 적으세요. 답을 바탕으로 대화형·문서작업공간형·에이전틱 중 하나를 고릅니다.

손에 남아야 하는 것: 세 질문에 대한 답과, 거기서 고른 도구 유형 한 개가 메모나 문서에 적혀 있으면 된 것입니다.

2. 지시는 네 가지만 채웁니다

프롬프트를 깊이 다루는 글은 이미 이 채널에 있습니다. 그 글은 여섯 요소(역할·맥락·과제·형식·예시·제약)로 프롬프트 자체를 가르칩니다. 여기서는 오늘 바로 쓸 수 있는 최소 네 가지만 잡습니다 — 맥락, 역할, 형식, 검사기준.

  • 맥락 — 이 일이 어떤 상황에서 왔는지. (예: “이 문의는 이용료 환불 관련 메일입니다.”)
  • 역할 — 어떤 입장에서 답할지. (예: “차분하고 공감하는 고객 담당자로서.”)
  • 형식 — 길이·톤·문단 수. (예: “3~4문장, 존댓말, 첫 문장은 공감, 마지막 문장은 다음 단계 안내.”)
  • 검사기준 — 이 결과가 틀렸다는 걸 무엇으로 알아챌지. (예: “환불 가능 여부와 처리 기한이 빠지면 틀린 것.”)

네 가지 중 가장 자주 빠지는 건 검사기준입니다. 맥락·역할·형식은 대개 어느 정도 채우는데, “무엇이 맞는 결과인가”는 정하지 않고 넘어갑니다. 검사기준이 없으면 결과를 받고도 잘 됐는지 스스로 판단할 방법이 없습니다.

재작성 루프

지시문을 처음부터 완벽하게 쓰려 하지 마세요. 초안을 받고, 검사기준과 어긋나는 부분을 짚고, 다시 요청하는 짧은 루프가 기본입니다.

예를 들어 위 지시로 받은 초안에 처리 기한이 빠졌다면 이렇게 되묻습니다 — “여기가 검사기준과 다릅니다, 처리 기한만 추가해 주세요.” 전체를 다시 쓰게 하지 않고, 어긋난 한 곳만 짚는 것이 핵심입니다.

실습② 지시 쓰기 · 20분

실습①에서 고른 도구를 열어 놓고, 지시문을 네 요소로 채웁니다. 초안을 도구에 넣어 보고, 검사기준과 어긋나면 위 방식으로 재요청을 한 번 해 봅니다.

손에 남아야 하는 것: 네 요소가 한 줄씩 채워진 지시문과, 재요청 전후 결과를 비교한 기록입니다. 네 요소 중 하나라도 빈칸이면 아직 끝난 게 아닙니다.

3. 실제 업무에 얹습니다 — 이 코스의 심장

여기까지는 준비였습니다. 이제 실제로 오늘 온 업무 한 건에 지시문을 적용합니다.

이 글이 예로 드는 업무는 반복적으로 오는 문의성 이메일에 답장 초안을 쓰는 일입니다. 다른 업무로 바꾸셔도 됩니다. 다만 아래 세 가지 기준에 맞는 업무를 고르시길 권합니다. 이 세 기준은 이 글이 처음 쓰는 말이니 여기서 한 번만 정의하겠습니다.

  1. 반복성 — 한 번 하고 끝나는 일이 아니라 매주 비슷한 형태로 다시 옵니다. 그래야 오늘 고른 도구와 지시문을 다음 주에도 다시 쓸 수 있고, 4절의 점검이 성립합니다.
  2. 검증 가능성 — 결과가 맞았는지 본인이 즉시 판단할 수 있습니다. 업무 지식이 없어도 요청한 정보가 빠졌는지는 읽으면 보입니다.
  3. 낮은 위험 — 초안이 틀려도 즉시 되돌릴 수 있습니다. 발송 전 검토 단계가 있고, 법적·금전적 구속력이 없습니다. 계약서 검토나 급여 계산처럼 되돌리기 어려운 업무는 첫 실습감이 아닙니다.

할 일은 이렇습니다. 실습②의 지시문으로 오늘 실제로 온 문의 한 건을 처리해 답장 초안을 만듭니다. 결과를 받으면 그대로 쓰기 전에 한 번 더 물어봅니다 — “왜 이렇게 답했는지”, “이 부분이 맞는지”. 시키고 끝내지 않는다는 뜻입니다.

이 한 걸음이 왜 중요한지는 근거가 있습니다. 처음 보는 라이브러리를 배우는 과정을 지켜본 한 실험(성인·프리랜서 또는 현직 개발자 52명)에서, AI를 쓴 사람들 안에서도 이해도가 갈렸습니다. 가른 것은 무엇을 물었느냐가 아니라, 결과를 받은 뒤 자기 이해를 한 번 더 점검했느냐였습니다. 고득점 무리 중 한 갈래는 “겉보기엔 AI에게 맡긴 그룹과 거의 같았지만, 생성된 결과에 대해 자기 이해를 점검하는 데 AI를 한 번 더 썼다”는 사람들이었습니다(arXiv:2601.20245 · 성인·개발자 52명 · 무리별 인원이 2~7명으로 매우 적어 “이런 패턴이 있었다” 정도로만 읽어야 합니다).

에이전틱에 맡길 때, 사람이 확인할 지점

세 갈래 중 에이전틱 도구를 골랐다면(예: 메일함을 직접 조회·발송까지 하는 도구), 아래를 확인 지점으로 정하고 표시하기 전에는 결과를 그대로 쓰지 마세요.

실패에서 나온 규칙이 하나 있습니다. 석 달간 에이전틱 도구를 상시로 돌린 한 사용자는 이렇게 적었습니다 — “’메일 확인해’가 스팸에 답장하는 일로 바뀌었다. ’소셜미디어 모니터링해’가 무작위 게시물에 좋아요를 누르는 일로 바뀌었다.” 처방은 이렇습니다. “모호하게 시키지 말고, 무엇을 하고 무엇을 하지 말지 구체적으로 적어라” — 예를 들어 “먼저 물어보지 않고는 답장하지 마”처럼요(Reddit r/AI_Agents, 익명 이용자 1인 사례). 같은 글타래의 댓글은 한 가지를 더 짚습니다. 도구가 이메일이나 웹페이지처럼 사람이 통제하지 않는 내용을 읽는다면, 그 내용 안에 “이전 지시는 무시하고 이걸 해”라는 식의 숨은 지시가 섞여 있을 수 있다는 겁니다.

이 문의 답장 예시로 옮기면, 도구가 메일함을 직접 조회해 답장까지 보내는 방식을 골랐을 경우 최소한 “내용을 확인하기 전에는 발송하지 않는다”는 정지선이 있어야 합니다.

확인 관행은 대개 세 층위로 나타납니다. 현장 사례를 모아 보면 이렇습니다.

  • 개인 습관 — 답장을 보내기 전에 반드시 한 번 읽어 봅니다.
  • 팀 규칙 — 복붙 금지, 검토를 거친 뒤에만 발송. 한 인사팀은 이 규칙을 새로 만들었다고 밝혔습니다(Reddit r/humanresources, 익명·팀 규율 사례).
  • 조직 정책 — 아예 용도를 좁게 제한합니다. 한 비영리단체는 “맞춤법 검사 외에는 쓰지 않는다”는 정책을 채택했다고 밝혔습니다(Reddit r/nonprofit, 익명·조직 정책 사례).

어느 층위든, 정하지 않으면 아무도 확인하지 않습니다.

같은 이야기의 반대쪽 사례도 있습니다. 한 인사 담당자는 발송 전 직설적인 초안을 AI로 톤만 다듬는 방식으로, 평소 마감을 미루던 상사가 마감을 지키게 만들었다고 적었습니다(Reddit r/humanresources, 익명·저위험 사례). 반면 한 마케팅 커뮤니티에서는 “챗봇에 ’마케팅 계획 짜줘’라고 쳐서 나온 걸 읽지도, 실행하지도 않은 채 그대로 쓰는” 사례가 실패로 지적됩니다(Reddit r/marketing, 익명·실패 사례). 같은 도구, 비슷한 저위험 업무인데 결과가 갈린 지점은 결과를 확인했는가였습니다.

마지막으로 하나 더 짚겠습니다. 기술적으로 잘 작동해도, 원래 그 일을 하던 사람이 확인 기준을 정하는 자리에 함께 있지 않으면 나중에 조용히 안 쓰이게 되는 경우가 보고됩니다(Reddit r/AI_Agents, 익명·팀 사례). 이메일 답장처럼 작은 업무에서도 마찬가지입니다. 검사기준은 그 메일에 원래 답하던 사람이 정해야, 나중에도 계속 쓰입니다.

이 코스는 계약서 검토나 급여 계산처럼 위험이 큰 업무의 확인 절차는 다루지 않았습니다. 그런 업무일수록 확인할 지점이 더 무겁고 많아지므로, 여기서 다룬 저위험 예시보다 신중한 절차가 필요합니다.

실습③ 업무에 붙이기 · 35분 (코스의 심장)

실습②의 지시문으로 오늘 실제로 온 문의 한 건을 처리해 산출물(답장 초안 등)을 만듭니다. 에이전틱 도구를 썼다면 사람이 확인할 지점 한 곳을 정하고 표시합니다. 산출물을 받으면 최소 한 번은 “왜 이렇게 답했는지”를 도구에 되물어 확인합니다.

손에 남아야 하는 것: (a) 실제 업무 산출물 한 건이 파일이나 문서로 남아 있고, (b) 에이전틱 도구를 썼다면 확인 지점이 한 곳 이상 표시돼 있고, (c) 산출물에 대해 최소 한 번 되물은 질문과 답이 남아 있으면 된 것입니다.

4. 잘 됐는지는, 느낌이 아니라 결과물로 봅니다

여기서 흔히 하는 실수는 “이제 좀 익숙해진 것 같다”는 느낌으로 점검을 대신하는 것입니다. 그 느낌은 근거가 아닙니다.

숙련된 오픈소스 개발자 16명에게 실제 이슈 246건을 무작위로 맡긴 한 실험에서, AI를 쓴 쪽이 실측으로는 19% 더 오래 걸렸습니다. 그런데 참가자들은 작업을 끝낸 뒤에도 20% 더 빨라졌다고 답했습니다(arXiv:2507.09089 · 성인·숙련 개발자 16명). 다 마친 뒤에도 반대로 느꼈다는 뜻입니다.

이 수치는 2025년 초 실험 결과이고, 같은 연구팀이 2026년 2월 후속 글에서 “이 값이 실제 생산성 영향의 부정확한 대리지표일 가능성이 높다”고 스스로 밝히며 실험 설계를 바꾸는 중이라고도 적었습니다. 그러니 19%를 지금도 유효한 결론으로 옮기지는 않겠습니다. 다만 체감과 실측이 반대로 나올 수 있다는 사실 자체는 남습니다.

배치를 다루는 다른 연구는 진단을 이렇게 요약합니다 — “AI를 넣었더니 그 일이 수월하게 느껴진다면, 그 자리는 틀린 자리일 수 있다”(arXiv:2606.26181). 이 연구는 고등학생을 대상으로 한 실험이라, 수치는 성인에게 옮기지 않고 이 진단 문장만 가져왔습니다.

그래서 이 점검은 “익숙해졌는가”를 묻지 않습니다. 남아 있는 산출물을 나란히 놓고 묻습니다.

점검 3문항

점수나 등급은 매기지 않습니다. 목적은 평가가 아니라 다음 주에 손댈 항목 하나를 고르는 것입니다.

  1. 도구 선택 대조: 실습①에서 고른 도구 유형과, 실습③에서 실제로 쓴 도구가 같습니까? 다르다면 무엇이 바꾸게 했습니까? (대조: 실습① 메모 ↔ 실습③ 실행 기록)
  2. 지시 반영 대조: 실습②의 네 요소 중 실습③ 산출물에서 실제로 지켜진 요소는 몇 개입니까? 빠진 요소가 있다면 무엇입니까? (대조: 실습② 지시문 ↔ 실습③ 산출물)
  3. 실사용 대조: 실습③ 산출물을 실제로 썼습니까(그대로 보냈다 / 손을 봐서 보냈다 / 안 썼다)? 손을 봤다면 어디를 고쳤습니까? (대조: 실습③ 초안 ↔ 실제로 나간 최종본)

세 문항 모두 “잘 쓰게 된 것 같다”는 느낌이 아니라, 남아 있는 두 산출물을 나란히 놓고 답하는 구조입니다.

실습④ 점검 · 15분

실습①~③에서 남긴 기록(도구 선택·지시문·산출물)을 앞에 두고, 위 세 문항을 산출물과 직접 대조하며 답합니다.

손에 남아야 하는 것: 세 문항에 대한 대조 기록과, 다음 주에 손댈 항목 한 가지가 문서에 적혀 있으면 된 것입니다.

5. 정리

세 갈래(대화형·문서작업공간형·에이전틱) 중 하나를 고르고, 지시를 네 요소로 채우고, 실제 업무 한 건에 얹고, 결과물로 점검하는 것 — 같은 업무 한 건이 이 네 단계를 관통했다면 오늘 할 일은 끝입니다.

이 코스에서 가장 자주 무너지는 지점은 대개 기법이 아니라 순서였습니다. 도구를 안 고르고 아무 창이나 열거나, 지시문에서 검사기준만 빠뜨리거나, 에이전틱 도구의 결과를 확인 없이 그대로 쓰는 것들입니다. 막히면 그 지점으로 돌아가시면 됩니다.

AI를 어디에 붙이고, 어디서 떼는가.

이 채널의 다른 글은 언제 떼는지를 다뤘습니다. 이 글은 어떻게 붙이는지를 다뤘습니다. 붙일지 뗄지를 정하는 근거가 느낌이면, 그건 판단이 아니라 기분입니다. 이번 주에는 업무 하나만 정해서, 끝까지 가 보시면 좋겠습니다.

참고 자료