우리는 AI 에이전트를 '직원'으로서 기업에 파견하는 BPO 플랫폼 TechHive Agent를 개발하고 있습니다. 이 기사에서는 그 핵심에 있는 업무 구조화 방법론 — 똑똑한 LLM에게 기반 업무를 맡기기 위해 '업무 측면'을 어떻게 정비할 것인가 — 를 설계 판단과 함께 소개합니다. 실행 기반(Anthropic의 Claude·보안)에 관한 이야기는 별도의 기사로 나누었습니다.

이 기사의 요점

• LLM이 아무리 똑똑해져도, 비구조화되고 개인에게 종속된(属人化) 업무는 그대로 맡길 수 없다
• 효과적인 것은 '모델의 똑똑함'보다 '업무를 AI가 다룰 수 있는 형태로 구조화했는가'이다
• 이를 위한 3종 세트:
  비즈니스 펑션 차트(Business Function Chart, 이하 BFC)(업무의 좌표계) / 업무의 Skill화 / 4단계 리스크 티어(AI와 사람의 경계)

Claude가 '똑똑해질'수록, 이런 생각이 들고 싶어집니다 — "이 정도 똑똑함이라면, 인사나 경리 같은 기반 업무도 그대로 맡길 수 있지 않을까?"라고.

하지만 실제로 업무에 투입하려고 하면, 대개 첫걸음에서 멈추게 됩니다. "그래서, 어떤 업무를 어디까지 맡겨도 되는 거지?" — 이 부분이 결정되지 않습니다.

이유는 명확합니다. 많은 기반 업무가 구조화되어 있지 않기 때문입니다. 절차도, 판단 기준도, 예외 대응도 담당자의 머릿속에만 있습니다(=개인 종속화). 구조화되지 않은 업무는 모델이 아무리 똑똑해도 '안전하게 맡길 수 있는 단위'로 잘라낼 수 없습니다.

즉, AI 에이전트에게 기반 업무를 맡기는 데 있어 정말 효과적인 것은 모델의 똑똑함 그 자체보다, 업무를 'AI가 다룰 수 있는 형태'로 구조화하고 있는가 입니다.

이하에서는 우리가 HR 업무를 대상으로 만든 구조화 방법론을 세 가지 도구를 통해 설명합니다.

우리의 설계 사상은 심플하며, '에이전트를 만들지 않는다' 입니다. 추론·도구 실행·샌드박스 같은 '에이전트의 내부'는 Claude에게 맡기고, 우리가 만드는 것은 업무를 AI가 안전하게 다룰 수 있도록 하는 인터페이스 계층에 집중합니다.

Amazon Aurora = PostgreSQL에 클라우드 규모의 운용과 DX를 입힌 것 (내용물은 Postgres)
AWS = 물리 인프라에 추상화와 DX를 입힌 것 (내용물은 서버 / 네트워크)
TechHive = Claude에 '업무 구조·권한·HITL'을 입힌 것 (내용물은 Claude)

성숙한 플랫폼의 대부분은 강력한 커모디티(Postgres, 서버, 그리고 지금은 LLM) 위에 '운용·권한·DX' 계층을 입힘으로써 가치를 창출하고 있습니다. 우리의 입장도 마찬가지로, 엔지니어링의 주전장은 '천재 모델에 프롬프트를 덧입히는 것'이 아니라, 무질서한 수작업 업무를 타입이 지정되고 테스트 가능한 단위로 변환하는 것이 됩니다. 이후의 세 가지는 그 변환을 수행하기 위한 도구입니다.

업무를 '맡길 수 있는 단위'로 잘라내기 위해서는 먼저 전체를 측정하기 위한 공통의 좌표계가 필요합니다. 우리는 그것을 **BFC(Business Function Chart)**라고 부릅니다.

• 일본 기업의 HR 업무를 **8개의 기능 축·186개 펑션(Function)**으로 체계화
• 국제 표준인 APQC PCF v7.4를 베이스로, 일본 고유의 프로세스(36협정, 연말정산의 각종 공제, 마이넘버 관리 등)를 추가
• ISO 30414 / SHRM BoCK과도 정합

기능 축별 내역은 다음과 같습니다.

기능 축	펑션 수
채용	32
...	합계 186

중요한 것은 설계 원칙으로, **1 펑션 = 1 스킬(Skill)**이 될 때까지 분해하고 있다는 점입니다. 입도를 맞추면 다음 네 가지 '단위'가 일치합니다.

• 추출의 단위 — 어디서부터 어디까지를 하나의 업무로 다룰 것인가
• 테스트의 단위 — 기대하는 입출력을 어디서 고정할 것인가
• 권한 부여의 단위 — 어떤 펑션에 어떤 도구 권한을 부여할 것인가
• 교체의 단위 — 제도 변경 시 어디를 교체할 것인가

"업무를 AI에게 맡길 것인가/맡기지 않을 것인가"의 논의는 이 입도가 맞지 않으면 반드시 모호해집니다. BFC는 그 모호함을 없애기 위한 척도입니다.

BFC로 잘라낸 1 펑션을 실제로 AI가 실행할 수 있는 형태로 만든 것이 Skill입니다. 베테랑의 머릿속에 있는 암묵지를 다음 4가지 요소로 구조화합니다.

skill: 채용 / 지원자 스크리닝
├── prompt … 판단 방법 (역할, 절차, 출력 포맷)
├── policy … 허용/불허의 경계 (리스크 티어, PII 처리)
...

여기서 엔지니어 관점의 핵심 포인트는 왜 tests를 Skill의 일부로 가지는가입니다. LLM은 비결정적(non-deterministic)이며, 프롬프트나 모델을 업데이트하면 동작이 조용히 어긋납니다. 업무 로직을 단순히 "프롬프트에 작성한 문장"만으로 관리하면, 이러한 "조용한 어긋남"을 알아차릴 수 없습니다. Skill에 대표 케이스의 기대 동작을 동봉해둠으로써, 업데이트할 때마다 업무로서의 회귀(regression)를 감지할 수 있습니다. 즉,

업무 로직을 소프트웨어와 동일한 선상에서 관리하기 위한 구조입니다.

우리에게 있어 이 Skill이야말로 최대의 납품물입니다. 모델은 빌려 쓰는 것이며 매일 똑똑해지지만, "그 회사의 업무를 어떻게 운영할 것인가"라는 지식은 Skill로서 자사에 남습니다.

Skill화를 현장에서 실행하는 프로세스는 다음 3단계입니다. 순서에 의미가 있습니다.

단계	할 일	결과물
MAP	HR 현장에 들어가 업무 프로세스, 판단 기준, 암묵지를 가시화한다. 필요하다면 RPO/BPO로서 실무도 담당하며 AI화해야 할 업무를 판별한다	업무 맵 (무엇을 맡기고, 무엇을 사람에게 남길 것인가)
BUILD	정형화할 수 있는 업무를 Skill로 구현. 기존의 HR SaaS나 사내 플로우와 연결하고, 필요한 부분에 사람의 확인을 삽입한다	가동되는 Skill
SCALE	실행 로그와 현장 피드백으로 Skill을 지속적으로 개선. 제도 변경에도 대응하도록 한다	자율 운영

MAP 단계를 건너뛰고 BUILD부터 시작하면, "구조화되지 않은 업무를 그대로 자동화하는" 결과가 되어, 서두에 언급한 "어디까지 맡겨도 될지 모르겠다"는 상황으로 되돌아가게 됩니다. 따라서 가시화가 먼저, 구현은 그다음입니다.

도달점은 담당자가 바뀌어도 업무 품질이 유지되는 상태 — 즉, 우리가 철수해도 계속 돌아가는 메커니즘을 현장에 남기는 것입니다.

업무를 구조화하더라도 그것만으로는 맡길 수 없습니다. 각 펑션(Function)에 **"AI에게 맡겨도 되는 상한선"**을 정의해야 합니다. 우리는 모든 조작을 결과의 "돌이킬 수 없음(irreversibility)"에 따라 4단계로 분류하고 있습니다.

Tier	유형	기본 처리	예시
1	Read Only (읽기 전용)	자동 실행	지원 데이터 가져오기, 스크리닝, 근태 집계
2	Internal Write (내부 쓰기)	자동 실행 (감사 포함)	ATS 업데이트, Sheets 쓰기, 월간 리포트
3	External Action (외부 조작)	사람의 승인 필요	메일 발송, 스카우트, 면접 일정 제안
4	Irreversible (비가역 조작)	반드시 사람이 승인	합격/불합격 통지, 내정 통지, 퇴직 발령

원칙은 **"AI는 준비, 최종 판단은 사람"**입니다. Tier가 올라갈수록 사람의 승인을 강제합니다. 여기에 더해, 분류에만 의존하지 않기 위한 가드레일(guardrail)을 겹겹이 쌓았습니다.

• PII 자동 탐지: 개인정보(PII)를 탐지하면 해당 조작의 리스크 레벨을 자동으로 격상시킵니다.
• 듀얼 채널 승인: 승인은 Web UI와 Slack 양쪽에서 모두 가능합니다 (승인만을 위해 관리 화면을 열게 하지 않습니다).
• 방치 방지 에스컬레이션: 승인이 타임아웃되면 알림 및 재할당을 통해 정체를 방지합니다.

참고로, 현재 실제 운영 중인 persona는 다음과 같습니다.

채용이 첫 단계이며, 노무 등은 순차적으로 확장 중입니다. BFC는 HR 전체를 커버하도록 설계되었으나, "설계상 가능한 것"과 "현재 작동하고 있는 것"은 구분해서 이해해 주세요. 마이넘버(My Number)와 같이 가장 민감한 영역은 애초에 Tier 3–4로 분류하여 사람의 승인 영역에 두고 있습니다.

• 똑똑한 모델 ≠ 맡길 수 있음. 비구조화되고 개인의 역량에 의존하는(siloed) 업무는 그대로 AI에게 넘길 수 없다 — 효과가 있는 것은 업무 측면의 설계다.
• BFC로 좌표계를 만들고, 업무를 Skill화하며, 리스크 티어로 경계를 긋는다.
• Skill에 tests를 포함함으로써, 비결정적인 LLM 위에서도 업무 로직의 회귀 관리를 할 수 있다.

다음 기사에서는 이렇게 구조화된 업무를 어떻게 안전하게 실행하고 있는지(Anthropic의 Claude를 사용한 실행 기반, Permission Policy, 테넌트 분리, 감사)에 대해 다루겠습니다.

저희는 이 메커니즘을 실제로 기업에 도입할 β 파트너 기업을 모집하고 있습니다. HR 업무의 개인화(属人化) 및 자동화에 관심이 있는 분들은 TechHive Agent를 살펴보시기 바랍니다.

집필: 사사키 타츠야 (佐々木 龍也)