Molayo

© 2026 Molayo

Zenn헤드라인2026. 06. 01. 22:54

AI에게 맡기기 전에, 업무를 관측 가능하게 만들기 ― Work Receipt로 리뷰할 수 있는 AI 개발로

요약

AI 에이전트에게 업무를 위임할 때 결과물뿐만 아니라 작업 과정의 맥락을 남기는 '관측 가능성(Observability)'의 중요성을 강조합니다. 'Work Receipt(작업 영수증)' 설계를 통해 AI의 입력, 전제, 변경 사항, 검증 내용, 리스크를 기록하여 리뷰 효율을 높이는 방법을 제안합니다.

핵심 포인트

  • AI 에이전트 활용 시 결과물 중심이 아닌 과정 중심의 설계 필요
  • Work Receipt를 통한 5가지 핵심 정보(입력, 전제, 변경, 검증, 리스크) 기록
  • 맥락이 결여된 AI 결과물은 리뷰 비용을 증가시키고 자산 가치를 떨어뜨림
  • 관측 가능한 업무 설계는 미래의 개발자가 업무를 재개할 수 있는 기반 제공

TL;DR

AI 에이전트(AI Agent)에게 업무를 맡기는 흐름은 아마 이제 멈추지 않을 것입니다. GitHub Copilot coding agent처럼 AI가 일시적인 개발 환경에서 작업하고 PR(Pull Request)을 제출하는 세상도 평범해졌고, Agents SDK처럼 도구 이용, 가드레일(Guardrail), 트레이스(Trace)까지 포함하여 에이전트를 만드는 흐름도 강해지고 있습니다.

하지만 여기서 중요한 것은 "AI가 똑똑해졌으니까 이제 확인하지 않아도 된다"가 아닙니다.

오히려 반대로, AI에게 맡기는 업무가 늘어날수록 업무를 관측 가능하게 만드는 설계가 중요해진다고 느끼고 있습니다.

이 기사에서 말하는 "관측 가능(Observable)"은 어려운 모니터링 기반의 이야기가 아닙니다. 훨씬 실무에 가깝습니다.

나중에 확인했을 때, 무엇을 요청했고 어떤 전제를 두었으며, 무엇이 변했고, 어떻게 검증했으며, 남은 리스크가 무엇인지 알 수 있는 상태를 말합니다.

이번에는 그것을 Work Receipt, 즉 "작업 영수증"으로서 설계합니다.

  • AI에게 전달한 입력
  • AI가 설정한 전제
  • 변경한 파일
  • 실행한 검증
  • 남아있는 리스크

이 5가지를 남기는 것만으로도 AI의 결과물 리뷰는 상당히 달라집니다.

AI에게 맡길수록 "무엇을 했는지"가 보이지 않게 됩니다

솔직히 AI 코딩 도구는 정말 편리합니다.

"이 버그 고쳐줘", "이 화면 만들어줘", "테스트 추가해줘"라고 부탁하면 코드를 작성해 줍니다. 최근에는 단발적인 채팅뿐만 아니라, 리포지토리(Repository)를 읽고, 브랜치(Branch)를 따고, 테스트를 돌리고, PR까지 만드는 워크플로우도 늘어나고 있습니다.

이거 정말 미래적인 느낌이죠.

하지만 실무에서 다루다 보면 또 다른 두려움이 생깁니다.

그것은 바로 결과물은 있는데, 작업의 과정이 보이지 않는다는 점입니다.

예를 들어 AI가 PR을 제출했다고 가정해 봅시다. 차이점(Diff)을 보니 그럴싸하게 동작하는 것 같습니다. 테스트도 추가되어 있고, 코멘트도 친절합니다. 그래서 순간적으로 "오, 괜찮네"라고 생각하게 됩니다.

하지만 리뷰하는 입장에서는 다음과 같은 점들이 신경 쓰입니다.

  • 어떤 사양(Specification)을 근거로 구현했는가
  • 어떤 전제를 두었는가
  • 무엇을 검증했고, 무엇을 검증하지 않았는가
  • 기존 사양을 망가뜨리지는 않았는가
  • 위험한 파일이나 설정에 손을 대지는 않았는가

이 부분이 보이지 않으면 결국 사람이 전부 다시 읽어야 합니다.

AI에게 맡겨서 빨라졌을 텐데, 리뷰에서 막히는 상황. 흔히 있는 일이라고 생각합니다.

왜 이렇게 되느냐 하면, AI의 업무는 "완성품"만 남기 쉽기 때문입니다.

사람 사이의 업무라면 Slack 대화, Issue 코멘트, PR 설명, 구두 상담 같은 맥락(Context)이 남습니다. 하지만 AI에게 대충 부탁하면 그 맥락이 희박한 채로 결과물만 나옵니다.

그리고 맥락이 희박한 결과물은 자산이 되기 어렵습니다.

미래의 내가 다시 봤을 때, "이거 왜 이렇게 했더라?"라고 하게 됩니다. 팀원이 봤을 때, "이 변경 사항, 믿어도 되는 건가?"라고 하게 됩니다. 장애가 발생했을 때, "이 시점에 무엇을 검증하고 있었던 거지?"라고 하게 됩니다.

즉, AI 시대의 개발에서 중요한 것은 단순히 코드를 빠르게 쓰는 것이 아니라, 빠르게 작성한 업무를 나중에 설명할 수 있는 형태로 남기는 것입니다.

여기서 필요해지는 것이 관측 가능한 업무입니다.

관측 가능한 업무는 미래의 내가 재개할 수 있는 업무

"관측 가능성(Observability)"이라는 용어는 원래 시스템 운영 문맥에서 자주 사용됩니다. 로그(Log), 메트릭(Metric), 트레이스(Trace)를 보고 시스템 내부에서 무엇이 일어나고 있는지 이해할 수 있는 상태를 말하죠.

하지만 이 기사에서는 조금 더 넓게 사용하겠습니다.

업무에도 관측 가능성이 있다는 생각입니다.

관측 가능한 업무란, 미래의 나나 팀원이 보았을 때 중간부터라도 재개할 수 있는 업무를 의미합니다.

반대로 관측할 수 없는 업무는 다음과 같습니다.

  • "적절히 수정했습니다"라고만 적혀 있음
  • 무엇을 검증했는지 불명확함
  • 어떤 사양을 참조했는지 불명확함
  • 에러가 났는지 안 났는지 불명확함
  • 실패한 시행착오가 사라져 있음

이것은 AI뿐만 아니라 사람의 업무에서도 일어나는 일이죠.

하지만 AI의 경우 속도가 빠른 만큼, 관측할 수 없는 업무가 대량으로 쌓이기 쉽습니다. 이 점이 무서운 부분입니다.

저는 AI에게 업무를 맡길 때일수록 "미래의 나를 위한 인수인계"를 세트로 묶는 것이 좋다고 생각합니다. 비난하기 위한 감시가 아니라, 돕기 위한 기록입니다.

예를 들어, 다음 날 아침의 내가 작업을 이어간다고 가정해 봅시다. 그때,

  • 무엇을 요청했는가
  • 어디까지 끝났는가
  • 어떤 테스트가 통과했는가
  • 무엇이 수상한가
  • 다음에 무엇을 보면 되는가

이것을 한 장으로 알 수 있다면 정말 큰 도움이 됩니다.

AI 시대의 컨텍스트 설계(Context Design)에는 여기에 상당히 본질적인 부분이 있다고 느낍니다.

AI에게 좋은 입력을 전달하는 것만으로는 부족합니다. AI가 수행한 업무를 다음 의사결정에서 사용할 수 있는 형태로 되돌려 놓아야 합니다. 입력의 컨텍스트(Context)뿐만 아니라, 출력 이후의 컨텍스트도 정돈해야 합니다.

이렇게 해두면 개발이 '그때뿐인 작업'에서 '쌓여가는 자산'으로 변합니다.

Work Receipt는 5개의 상자로 생각하면 이해하기 쉽습니다

그렇다면 무엇을 남겨야 할까요?

저는 우선 Work Receipt를 5개의 상자로 나누어 생각하는 것이 이해하기 쉽다고 생각합니다.

상자작성 내용리뷰 시 효과
InputAI에게 전달한 의뢰, Issue, 사양어떤 문제를 해결하는 작업이었는가
...

이 5가지만 있어도 AI PR(Pull Request)의 가시성이 달라집니다.

예를 들어 Verification에 npm test라고 적혀 있어도, 실제로 실패했다면 의미가 없겠죠. 따라서 성공했는지 실패했는지, 혹은 스킵(Skip)했다면 왜 스킵했는지까지 작성합니다.

Risks도 중요합니다.

AI뿐만 아니라 사람이라도 "이 부분은 시간이 부족해 확인하지 못했습니다", "이 케이스는 미검증 상태입니다"라고 말할 수 있는 사람의 업무는 리뷰하기 쉽습니다. 반대로, 모든 것이 완벽해 보이지만 근거가 희박한 업무는 두렵습니다.

Work Receipt는 AI의 자기 신고를 그대로 믿기 위한 종이가 아닙니다. 리뷰를 위한 지도입니다.

지도가 있다면 리뷰하는 사람은 길을 잃지 않습니다.

어디를 봐야 하는지, 어디가 위험한지, 어떤 검증 결과를 확인해야 하는지 알 수 있습니다.

Work Receipt의 최소 Markdown 템플릿

## Work Receipt
### Input
- Request:
...

처음에는 이것으로 충분합니다.

갑자기 전용 도구를 만들 필요는 없습니다. AI에게 "마지막에 이 템플릿을 채워줘"라고 부탁하는 것만으로도 상당히 달라집니다.

다만, 매번 Markdown을 수동으로 정리하는 것은 번거로우므로, 다음부터 조금씩 코드화해 나가겠습니다.

AI에 대한 의뢰문을 영수증(Receipt) 전제로 바꾸기

AI에게 일을 맡길 때 흔히 하는 의뢰는 다음과 같습니다.

태스크 목록 화면에 검색 기능을 추가해 주세요.

물론, 이렇게 해도 동작하는 결과물은 나올 수 있습니다.

하지만 관측 가능한 업무로 만들고 싶다면, 의뢰문의 형태를 조금 바꿉니다.

포인트는 처음부터 "마지막에 Work Receipt를 제출해줘"라고 전달하는 것입니다.

태스크 목록 화면에 검색 기능을 추가해 주세요.
전제 조건:
- 기존의 UI 컴포넌트를 우선적으로 사용할 것
...

이것만으로도 AI의 출력은 상당히 달라집니다.

"구현해줘"라고만 하면 AI는 구현에 치중합니다. 하지만 "마지막에 영수증을 남겨줘"라고 말하면, AI는 작업에 대한 설명도 의식하게 됩니다.

설계 리뷰(Design Review)를 받고 싶을 때는 다음과 같이 합니다.

다음 사양을 구현하기 전에 설계 리뷰를 해주세요.
리뷰 관점:
- 현재의 코드 구조와 일치하는가
...

코드 리뷰(Code Review)라면 다음과 같습니다.

다음 차이점(Diff)을 리뷰해 주세요.
확인 요청 사항:
- 사양과 어긋나지 않는가
...

디버깅(Debugging) 시에는 다음과 같이 하면 사용하기 좋습니다.

이 에러를 조사해 주세요.
제약 사항:
- 추측으로 단정 짓지 말 것
...

여기서 중요한 것은 AI를 의심하는 것이 아니라, AI와 인간이 같은 지도를 보는 것입니다.

AI에게 기분 좋게 업무를 맡기기 위해, 맡긴 결과를 관측할 수 있는 형태로 만드는 것. 이것이 실무의 요령이라고 생각합니다.

TypeScript로 Work Receipt를 타입화하기

Markdown 템플릿만으로도 시작할 수 있습니다.

다만, 팀에서 운용한다면 약간 타입(Type)으로 만들어 두는 것이 편리합니다. 형식이 통일되고, 나중에 검색, 집계, 자동 체크를 하기 쉬워지기 때문입니다.

여기서는 TypeScript로 최소한의 타입을 만듭니다.

type VerificationStatus = "passed" | "failed" | "skipped";
type VerificationItem = {
  command: string;
  ...
};

나아가 실행 시점에도 체크하고 싶다면 Zod를 사용할 수 있습니다.

import { z } from "zod";
export const WorkReceiptSchema = z.object({
  id: z.string().min(1),
  ...
});

이렇게 하면 AI가 내놓은 JSON을 그대로 신뢰하지 않고, 최소한의 형식 체크를 할 수 있습니다.

예를 들어, 검증 결과가 비어 있거나 status: "ok"와 같이 모호한 값이라면 걸러낼 수 있습니다.

import { readFileSync } from "node:fs";
import { WorkReceiptSchema } from "./work-receipt-schema";
const raw = JSON.parse(readFileSync("work-receipt.json", "utf8"));
...

여기까지 하면, "AI가 제대로 했다고 말하고 있다"에서 한 걸음 나아가, "적어도 형식으로서 리뷰 가능한 증적(Evidence)이 있다"는 상태가 됩니다.

물론 이것만으로 안전해지는 것은 아닙니다. 하지만 리뷰의 입구로서는 상당히 강력합니다.

CLI로 차이점(Diff)과 검증 결과를 자동으로 남기기

다음으로, 차이점과 검증 결과를 영수증(Receipt)화하는 작은 CLI를 만듭니다.

여기서는 심플하게, 변경된 파일 목록과 검증 명령어의 결과를 JSON으로 만듭니다.

import { execSync } from "node:child_process";
import { writeFileSync } from "node:fs";
type VerificationStatus = "passed" | "failed";
...

사용법은 다음과 같습니다.

WORK_TITLE="Add task search" \
WORK_REQUEST="Add keyword search to the task list page" \
npx tsx scripts/create-work-receipt.ts

이 CLI는 완벽하지 않습니다.

변경 이유는 인간이나 AI가 나중에 채워 넣어야 하며, 수동 확인(Manual confirmation)까지는 포착할 수 없습니다. 하지만 첫걸음으로는 충분합니다.

중요한 것은, 검증에 실패한 사실도 남는다는 점입니다.

AI 운영에서 가장 위험한 것은 실패가 사라지는 것입니다. 테스트가 실패했는데 최종 코멘트에는 "완료했습니다"라고만 적히는 경우. 수동 확인을 하지 않았는데 왠지 모르게 OK처럼 보이는 경우.

이러한 모호함을 줄이기 위해, CLI로 기계적으로 남길 수 있는 부분은 남깁니다.

그리고 남겨진 빈칸을 인간이 확인합니다.

이 정도의 역할 분담이 현실적이고 지속하기 쉬울 것이라고 생각합니다.

리뷰에서는 3가지 적신호를 확인하라

Work Receipt가 있으면 리뷰가 편해집니다.

단, 영수증이 있다는 것만으로 안심해서는 안 됩니다. 영수증에도 적신호가 있습니다.

첫 번째는, Verification(검증)이 전부 모호한 것입니다.

예를 들어, 다음과 같은 방식입니다.

동작 확인했습니다.
문제 없습니다.

이것은 약합니다.

무엇을 실행했는지, 어떤 화면을 보았는지, 어떤 케이스를 확인했는지. 이것이 없으면 리뷰할 수 없습니다.

좋은 작성 방식은 다음과 같습니다.

- npm run typecheck: passed
- npm test -- task-search: passed
- Manual: search by title, search by description, empty keyword reset: passed
...

두 번째는, Assumptions(가정)이 비어 있는데 변경 사항이 큰 것입니다.

큰 변경에는 대개 전제가 따릅니다.

  • 기존 API는 변경하지 않는다
  • DB 스키마는 변경하지 않는다
  • 이 화면만 대상으로 한다
  • 기존 컴포넌트를 사용한다

이러한 전제가 아무것도 적혀 있지 않은데 여러 파일이 크게 바뀌어 있다면, 리뷰를 중단하는 것이 좋습니다.

세 번째는, Risks(리스크)가 제로인데 검증이 부실한 것입니다.

리스크가 제로인 작업은 거의 없습니다. 작은 문구 수정이라면 몰라도, 기능 추가나 로직 변경이라면 반드시 무언가 미확인된 지점이 있습니다.

리스크를 적는 것은 약함을 드러내는 것이 아닙니다.

오히려 제대로 파악하고 있다는 증거입니다.

AI에게도 똑같은 것을 요구하는 것이 좋습니다. 하지 못한 것을 한 것처럼 적지 않기. 모르는 것을 아는 것처럼 적지 않기. 미확인 상태라면 미확인이라고 적기.

이러한 정직함이 AI 시대의 품질을 상당히 지탱해 줄 것이라고 믿습니다.

우선 Markdown 한 장부터 시작하면 된다

여기까지 읽으면, "제대로 하려면 힘들 것 같다"라고 느낄지도 모릅니다.

하지만 처음부터 전부 할 필요는 없습니다.

오히려 처음에는 Markdown 한 장이면 충분합니다.

예를 들어, .ai/work-receipts/2026-06-01-task-search.md

같은 파일을 만들고, 마지막에 AI가 내용을 채우도록 하면 됩니다.

# Work Receipt: Add task search
## Input
- Request: Add keyword search to task list
...

이것만으로도 미래의 자신은 큰 도움을 받게 됩니다.

내일 작업을 이어서 할 때, 어디서부터 보면 좋을지 알 수 있습니다. 리뷰하는 사람도 무엇을 믿고 무엇을 의심해야 할지 알 수 있습니다.

그리고 익숙해지면, PR (Pull Request) 템플릿에 넣습니다.

## Summary
## Work Receipt
### Input
...

이를 팀의 규칙으로 만들 필요도, 처음부터 그럴 필요도 없습니다.

자신의 AI 작업에만 시도해 봅니다. 일주일 정도 해봅니다. 리뷰하기 쉬워졌다면 팀에 공유합니다.

그 정도의 온도감이면 충분하다고 생각합니다.

결국, 지속 가능한 메커니즘으로 만들지 않으면 의미가 없습니다. 완벽한 운영 규칙을 만들어도 번거로워서 아무도 쓰지 않는다면 그것은 부채가 됩니다.

우선은 65점이면 충분합니다.

AI에게 맡긴 업무를 미래의 자신이 재개할 수 있는 형태로 남긴다. 이것만으로도 내일의 개발 경험 (Developer Experience) 은 상당히 달라집니다.

요약

AI 에이전트 (AI Agent) 시대에 중요한 것은 "AI를 어디까지 믿을 것인가"만이 아니라고 생각합니다.

그보다 더 중요한 것은, 믿기 전에 관측 가능한 형태로 만드는 것입니다.

AI가 무엇을 입력 (Input) 으로 받았는지, 어떤 전제 (Assumptions) 를 두었는지, 어떤 파일 (Files) 을 변경했는지, 무엇을 검증 (Verification) 했고, 무엇을 미확인 상태로 남겼는지.

이것이 보이는 것만으로도 리뷰는 상당히 현실적이 됩니다.

이번 포인트들을 정리합니다.

  • AI에게 맡길수록 결과물뿐만 아니라 작업의 경로를 남길 필요가 있다
  • 관측 가능한 업무란, 미래의 자신이나 팀이 재개할 수 있는 업무이다
  • Work Receipt는 Input / Assumptions / Changes / Verification / Risks의 5개 항목으로 시작할 수 있다
  • AI에게 보내는 요청문에 처음부터 Work Receipt 출력을 포함시킨다
  • TypeScript나 CLI를 통해 형식 체크와 검증 결과 기록을 조금씩 자동화할 수 있다
  • 영수증 (Receipt) 은 믿기 위한 종이가 아니라, 리뷰하기 위한 지도이다

AI에게 업무를 맡기는 것은 앞으로 더욱 보편화될 것입니다.

그렇기에 인간의 업무는 "모든 것을 손으로 하는 것"에서 "맡긴 업무를 관측할 수 있는 형태로 설계하는 것"으로 옮겨갈 것입니다.

오늘의 작업을 내일의 내가 보고 재개할 수 있도록 남긴다.

우선은 그 한 장부터 시작해도 괜찮을 것 같습니다.

참고 링크

  • OpenAI: New tools for building agents

https://openai.com/index/new-tools-for-building-agents/ - OpenAI: The next evolution of the Agents SDK

https://openai.com/index/the-next-evolution-of-the-agents-sdk - GitHub Docs: About GitHub Copilot coding agent

https://docs.github.com/en/copilot/concepts/coding-agent/coding-agent - Model Context Protocol

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0