업무를 그래프로 설계하면 AI가 덜 틀린다: Claude·Codex를 위한 업무 그래프 가이드

AI에게 일을 시킬 때 많은 팀이 프롬프트부터 고친다. "더 정확하게 써줘", "우리 회사 스타일을 지켜줘", "앞의 내용을 참고해줘"라고 문장을 늘린다. 그런데 결과가 계속 흔들린다면 프롬프트의 길이보다 업무의 구조가 보이지 않는 것이 문제일 수 있다.

예를 들어 제안서를 만들 때 필요한 것은 문장 생성 능력만이 아니다. 고객의 요구, 과거 제안서, 가격표, 담당자, 승인자, 제출 마감, 근거 문서가 서로 연결되어야 한다. 이 연결을 업무 그래프라고 부르자. 이 글에서 말하는 업무 그래프는 새 제품을 사야 한다는 뜻이 아니라, 팀이 이미 가진 업무를 AI가 읽을 수 있는 구조로 정리하는 실무 모델이다.

이렇게 생각하면 Claude나 Codex를 사용할 때도 질문이 바뀐다. "좋은 코드를 써줘"가 아니라 "이 이슈는 어떤 파일과 테스트에 의존하고, 어떤 검증을 통과해야 PR이 되는가"라고 묻게 된다.

프롬프트·컨텍스트·업무 그래프는 무엇이 다른가?

개념	쉽게 말하면	해결하는 문제
프롬프트 엔지니어링	AI에게 질문과 지시를 잘 쓰는 일	한 번의 요청에서 원하는 형식과 방향을 맞춘다.
컨텍스트 엔지니어링	AI가 참고할 정보를 골라 전달하는 일	잘못된 자료나 빠진 정보를 줄인다.
업무 그래프	업무의 객체·관계·상태·승인선을 설계하는 일	다음 행동, 책임자, 근거, 완료 조건을 재현한다.

세 가지는 경쟁 관계가 아니다. 좋은 질문을 쓰고, 필요한 정보를 골라 주고, 그 정보가 업무에서 어디에 연결되는지 정의해야 한다. 그래프는 그중 가장 바깥의 운영 구조다.

업무 그래프를 구성하는 5가지 노드

처음부터 복잡한 지식 그래프를 만들 필요는 없다. 아래 다섯 가지를 카드로 적는 것부터 시작한다.

1. 목표: 이번 업무가 끝났다고 말할 수 있는 결과는 무엇인가?
2. 사람: 누가 요청하고, 누가 실행하고, 누가 승인하는가?
3. 정보: 필요한 문서·데이터·정책·이전 결과는 어디에 있는가?
4. 도구: 읽기·쓰기·검색·계산·알림을 어떤 시스템에서 하는가?
5. 상태: 대기·초안·검수·승인·반려·완료·보류 중 어디에 있는가?

그리고 카드 사이에 관계를 적는다. "고객 요구는 제안서 초안의 근거다", "가격표 변경은 재무 승인에 의존한다", "테스트 통과는 PR 병합의 조건이다"처럼 쓰면 된다. 이 문장들이 업무 그래프의 선이 된다.

업무 그래프를 먼저 만들면 무엇이 달라지나?

AI가 틀리는 이유를 모델의 문제로만 생각하면 매번 모델을 바꾸게 된다. 그래프를 그리면 어떤 연결이 비어 있는지 보인다.

문제 증상	빠진 연결	AX에서 고칠 것
AI가 최신 가격을 사용하지 않는다.	가격표의 버전과 유효일이 없음	문서에 소유자·버전·만료일을 붙인다.
같은 고객에게 다른 답을 보낸다.	고객 상태와 이전 접점이 분리됨	CRM 기록과 현재 요청을 하나의 작업 카드로 묶는다.
코드 변경 범위가 계속 커진다.	이슈와 허용 파일·테스트의 관계가 없음	작업 계약에 범위와 금지 영역을 명시한다.
승인자가 매번 처음부터 다시 읽는다.	초안에 근거·변경점·위험도가 없음	승인 카드에 근거와 차이를 구조화해 넣는다.
실패한 작업을 계속 재실행한다.	실패 상태와 중단 조건이 없음	재시도 횟수·담당자·수동 전환을 상태로 만든다.

예시: AI가 제안서를 만드는 것이 아니라 제안서 흐름을 운영하게 하려면?

나쁜 요청은 "우리 회사 스타일에 맞는 제안서를 작성해줘"다. 좋은 요청은 업무 그래프에서 각 단계를 분리한다.

1. 요청 접수: 고객 문제, 대상 팀, 예산 범위, 마감일을 입력한다.
2. 근거 수집: 승인된 사례, 가격표, 서비스 범위 문서만 검색한다.
3. 적합성 확인: 고객 요구와 우리가 제공할 수 있는 범위를 비교한다.
4. 초안 생성: 근거 문서의 링크와 버전을 함께 기록한다.
5. 검수: 사실·가격·일정·표현을 담당자가 확인한다.
6. 승인: 할인이나 커스텀 범위가 있으면 별도 승인한다.
7. 발송: 승인된 버전만 고객에게 전달하고 다음 후속일을 기록한다.

이제 에이전트는 제안서를 잘 쓰는 역할만 하지 않는다. 어떤 문서를 읽어야 하고, 언제 멈추며, 누가 승인해야 하는지까지 포함한 흐름 안에서 움직인다. 결과물이 좋지 않아도 어느 연결에서 문제가 생겼는지 찾을 수 있다.

Claude·Codex 코딩 작업을 업무 그래프로 바꾸는 방법

코딩 에이전트에도 같은 구조를 적용할 수 있다. 이슈를 하나의 노드로 보고, 저장소 규칙·관련 파일·테스트·PR·리뷰를 연결한다.

이슈: CSV 업로드 오류 재현과 최소 수정
  ├─ 근거: 재현 로그, 관련 이슈, 저장소 규칙
  ├─ 범위: src/importer.ts, importer.test.ts
  ├─ 금지: 마이그레이션, 의존성 추가, 운영 데이터 접근
  ├─ 검증: 단위 테스트, 린트, 기존 회귀 테스트
  ├─ 상태: 계획 → 수정 → 테스트 → 사람 리뷰 → 병합
  └─ 산출물: diff, 테스트 결과, 남은 위험, PR 설명

이 구조는 특정 코딩 에이전트에 종속되지 않는다. Claude Code든 Codex든, 이슈와 완료 조건이 명확하면 결과를 비교할 수 있다. 반대로 작업 그래프가 없는 상태에서 같은 프롬프트를 여러 번 돌리면 무엇이 바뀌었는지 설명하기 어렵다.

컨텍스트 패킷은 어떻게 만들까?

그래프 전체를 매번 AI에게 전달할 필요는 없다. 현재 작업에 연결된 노드만 뽑아 짧은 컨텍스트 패킷으로 만든다. 패킷에는 다음을 넣는다.

• 현재 목표와 완료 조건
• 현재 상태와 바로 전 단계의 결과
• 승인된 근거 문서와 버전
• 허용된 도구와 접근 범위
• 금지 영역과 사람에게 넘겨야 하는 조건
• 출력 형식과 다음 단계의 수신자

이렇게 하면 매번 긴 회사 소개를 붙이지 않아도 된다. 필요한 정보가 부족하면 에이전트가 추측하는 대신 "근거 부족" 상태로 멈출 수 있다. 멈추는 것은 실패가 아니라 그래프에 안전한 상태를 하나 추가하는 일이다.

업무 그래프를 만드는 7단계

1. 최근 실제 업무 한 건을 고른다.
2. 요청부터 완료까지의 상태를 포스트잇으로 나눈다.
3. 각 상태에서 쓰는 문서·시스템·사람을 적는다.
4. 다음 단계로 넘어가는 조건과 반려 조건을 적는다.
5. AI가 읽기만 해도 되는 단계와 쓰기 권한이 필요한 단계를 나눈다.
6. 근거·버전·승인자·시각을 남길 위치를 정한다.
7. 가장 반복적인 한 구간만 자동화하고 10건으로 검증한다.

여기서 중요한 것은 그래프를 예쁘게 그리는 일이 아니다. 팀원이 같은 질문을 받았을 때 같은 다음 행동을 선택할 수 있는지 확인하는 일이다.

업무 그래프가 너무 복잡해지는 것을 막는 법

그래프라는 단어를 들으면 거대한 데이터 모델부터 만들고 싶어진다. 그러나 첫 파일럿에는 다음 규칙이면 충분하다.

• 노드는 10개 이하로 시작한다.
• 한 노드는 한 가지 책임만 가진다.
• 모든 연결에는 다음 행동이나 판단 조건이 있어야 한다.
• 읽기 전용 정보와 실행 가능한 도구를 구분한다.
• 상태가 바뀔 때 담당자와 시각을 기록한다.
• 두 번 연속 실패하면 자동 재시도 대신 사람에게 넘긴다.

그래프가 복잡해질수록 정확도가 자동으로 올라가는 것은 아니다. 설명할 수 있고 고칠 수 있는 정도가 실제 운영의 기준이다.

2주 업무 그래프 파일럿

1~3일차: 현재 업무 그리기

회의실에서 이상적인 흐름을 만들지 말고 실제로 지난주에 처리한 사례를 따라간다. 누구에게 물었고, 어떤 문서를 열었고, 어디에서 다시 작업했는지 기록한다.

4~5일차: 상태와 승인선 고정

대기·초안·검수·승인·완료·보류 상태를 정하고, 상태를 바꿀 수 있는 사람을 정한다. AI가 상태를 추천할 수는 있지만 책임자를 대체하지는 않는다.

6~9일차: 컨텍스트 패킷 적용

에이전트에게 전체 폴더나 모든 대화를 주지 말고 현재 노드에 연결된 근거만 제공한다. 누락된 근거를 추측하지 않고 요청하도록 규칙을 넣는다.

10~12일차: 10건 반복

같은 업무를 10건 이상 실행하며 누락된 연결, 잘못된 상태 전환, 승인 지연을 기록한다. 성공 사례만 모으면 그래프가 좋아 보이는 착시가 생긴다.

13~14일차: 유지할 구조 결정

자동화할 단계, 사람이 맡을 단계, 더 이상 기록하지 않아도 되는 항목을 정한다. 업무 그래프의 목표는 모든 것을 기록하는 것이 아니라 중요한 판단을 재현하는 것이다.

성과는 AI 답변 점수가 아니라 흐름으로 측정한다

지표	측정 방법	좋은 신호
컨텍스트 재수집 시간	작업 시작 전 자료를 찾는 데 걸린 시간	반복 설명과 자료 찾기가 줄어든다.
상태 누락률	필수 상태나 담당자가 비어 있는 건수	다음 행동이 명확해진다.
근거 누락률	결과에 원문·버전·출처가 없는 비율	사람이 검증할 수 있다.
승인 대기시간	검수 요청부터 승인·반려까지의 시간	승인 카드가 짧고 비교 가능해진다.
재작업률	이전 단계로 되돌아간 작업 비율	그래프의 조건과 입력이 개선된다.

결론: AI에게 일을 설명하는 대신 일이 움직이는 방식을 설계하자

업무 그래프는 새로운 유행어를 붙이는 프로젝트가 아니다. 업무의 책임자, 근거, 도구, 상태, 승인선을 눈에 보이게 만드는 방법이다. 이 구조가 있으면 프롬프트를 짧게 만들어도 AI에게 필요한 정보가 더 정확히 전달된다.

처음에는 종이와 스프레드시트로 시작해도 된다. 한 업무를 10개의 노드 안으로 표현하고, 그중 한 구간만 에이전트에게 맡겨 보자. 업무 그래프가 사람에게도 이해되고, AI가 다음 행동을 선택할 때 근거가 된다면 이미 AX의 중요한 기반을 만든 것이다.

공식 참고 자료

• Anthropic: Building effective agents
• Claude Code 공식 문서
• OpenAI Codex 공식 문서
• Microsoft GraphRAG 문서
• Model Context Protocol 소개