한화생명 Project Based Learning — 현업이 직접 빌드한 에이전트

과제

한화생명의 출발점은 명확했습니다. 개발 경험이 없는 현업 전문가들이 자기 도메인의 문제를 직접 정의하고, Claude Code를 활용해 실제로 동작하는 에이전트 산출물까지 만들어야 했습니다. 이 과제의 핵심 긴장은 도구 사용법을 익히는 수준이 아니라, 현업이 스스로 만들고 이후에도 이어갈 수 있는 상태를 6주 안에 남기는 데 있었습니다.

대상은 한화생명 현업 전문가 20명이었습니다. 5개 유닛, 유닛당 4명으로 구성됐고, 모두 해당 도메인 7~10년차 이상의 실무자였습니다. 다만 개발 경험은 없는 분들이었습니다. 따라서 프로그램은 코딩 교육만으로 설계할 수 없었습니다. 무엇을 만들지 정하는 일, 필요한 데이터를 확인하는 일, 구현 가능한 구조로 줄이는 일, 막히는 코드 지점을 넘는 일이 한 흐름 안에 있어야 했습니다.

운영상의 제약도 분명했습니다.

• 기간은 6주였습니다. 정의, 데이터, 빌드, 발표까지 한 번에 닫아야 했습니다.
• 5개 유닛이 서로 다른 주제로 동시에 움직였습니다. 구체 프로젝트 내용은 비공개로 유지해야 했습니다.
• 평일 08시부터 18시까지 AX LABS가 현장에 상주했습니다. 막히는 순간을 다음 강의로 미루지 않는 구조가 필요했습니다.
• 데모용 가짜 데이터가 아니라, 현업 데이터팀과 협업한 실 데이터 환경에서 작업해야 했습니다.

단발 강의나 단일 미션으로는 이 긴장을 풀기 어렵다고 판단했습니다. 현업 전문가가 자기 업무 언어를 코드와 데이터 구조로 옮기는 과정은 설명을 듣는 시간이 아니라, 실제 프로젝트를 붙들고 여러 번 판단을 고치는 시간 안에서 만들어진다고 봤습니다.

접근

전체 설계는 Project Based Learning(PBL)로 잡았습니다. 강의를 앞에 길게 두고 마지막에 실습을 붙이는 방식이 아니라, 첫 주부터 각 유닛이 만들 대상을 정하고 6주 동안 하나의 프로젝트를 끝까지 밀고 가는 구조로 설계했습니다. 흐름은 정의 → 데이터 → 빌드 → 발표였습니다. 이 순서를 지킨 이유는 개발 경험이 없는 현업 전문가에게 코드부터 요구하면, 빠르게 손은 움직이지만 정작 무엇을 만들고 있는지 흔들릴 가능성이 크다고 봤기 때문입니다.

AX LABS의 역할도 처음부터 분명히 나누었습니다. 코드는 대신 작성하지 않았습니다. 현업 전문가가 Claude Code로 직접 작성하고, AX LABS 컨설턴트는 데이터, 아키텍처, 코드가 막히는 지점에서 옆에서 판단을 보조했습니다. 6주 뒤에 남아야 하는 것은 외주 산출물이 아니라, 현업이 자기 손으로 이어서 디벨롭할 수 있는 작업 상태라고 봤습니다.

코드보다 먼저 기능의 경계를 합의했습니다

1주차에는 Claude Code 사용법보다 디자인씽킹 워크숍을 앞에 두었습니다. 개발 경험이 없는 참여자에게 가장 먼저 필요한 것은 문법 지식이 아니라, 에이전트가 맡을 일과 맡지 않을 일을 가르는 기준이라고 판단했습니다.

각 유닛은 문제 정의에서 출발해 페르소나와 사용자 여정 지도를 작성했습니다. 이후 에이전트 기능 정의서에 에이전트가 수행할 업무, 역할과 권한의 경계, 사람이 개입해야 하는 지점을 명시했습니다. Human-in-the-loop를 초기에 적어 둔 것은 중요했습니다. 현업 과제는 대체로 예외와 판단이 많기 때문에, 모든 과정을 자동화 대상으로 놓으면 구현 범위가 급격히 커집니다. 사람이 확인해야 할 지점을 남겨야 6주 안에 구현 가능한 구조가 됩니다.

이 단계에서 워크플로우도 함께 그렸습니다. 입력이 무엇이고, 에이전트가 어느 지점에서 판단하며, 어떤 도구를 호출하고, 어떤 형태로 산출하는지를 도식화했습니다. 이 초안이 2주차 데이터 요건과 아키텍처 논의의 기준선이 됐습니다.

실 데이터 환경을 2주차에 먼저 고정했습니다

2주차의 핵심은 데이터와 아키텍처였습니다. 단순한 화면 시연으로 끝낼 프로젝트가 아니었기 때문에, 필요한 데이터 소스와 스키마, 접근 권한, 갱신 주기를 먼저 확인했습니다. 이 과정을 뒤로 미루면 3~4주차 빌드 단계에서 기능은 보이지만 실제 업무 맥락과 연결되지 않는 위험이 생긴다고 봤습니다.

개발자 출신 컨설턴트가 이 구간을 집중 지원했습니다. 1주차의 아키텍처 초안을 구현 가능한 구조로 구체화하고, 현업 데이터팀과 협업해 실 데이터 작업 환경을 마련했습니다. 데모용 가짜 데이터를 쓰지 않은 것도 의도적인 선택이었습니다. 실제 데이터는 접근 권한, 컬럼 의미, 갱신 주기, 예외값이 함께 따라옵니다. 현업 전문가가 이 조건을 마주한 상태에서 빌드해야, 최종 산출물이 발표용 화면에 머물지 않는다고 판단했습니다.

현업이 직접 코드를 쓰도록 운영 방식을 고정했습니다

3~4주차에는 Claude Code로 본격적인 빌딩을 진행했습니다. AX LABS가 대신 개발하면 속도는 빨라질 수 있지만, 프로그램 종료 후 현업이 이어서 고치고 확장하기 어렵습니다. 그래서 코드 작성의 주체는 처음부터 현업 전문가로 두었습니다.

현장에서는 다음 원칙을 지켰습니다.

• 정의서와 아키텍처를 보며, 먼저 핵심 기능 한 줄기를 동작하게 만들었습니다.
• 화면과 데이터 연동은 한꺼번에 넓히지 않고, 유닛별 속도에 맞춰 순서를 조정했습니다.
• 코드가 막히는 지점에서는 정답 코드를 넘겨주기보다, 왜 막혔는지와 다음 프롬프트를 어떻게 잡을지를 함께 확인했습니다.
• 풀스택에 가까운 흐름을 만들되, 6주 안에 닫을 수 없는 범위는 중간 발표 이후 개선 과제로 재정리했습니다.

이 운영 방식은 참여자의 개발 숙련도를 전제로 하지 않았습니다. 오히려 현업 도메인 지식이 충분한 분들이 자기 업무의 판단 기준을 코드 구조로 옮기도록 돕는 데 초점을 두었습니다.

5개 유닛을 병렬로 보되, 같은 속도를 강요하지 않았습니다

프로그램에는 AX LABS 컨설턴트 4명이 투입됐습니다. 1명은 전체 총괄 PM을 맡았고, 나머지 3명이 현장을 지원했습니다. 현장 3명은 2인 1조로 유닛들을 돌며 지원하는 방식과, 1개 유닛을 컨설턴트 1명이 전담하는 방식을 섞어 운영했습니다.

5개 유닛은 주제도 다르고, 데이터 조건도 다르며, 구현에서 막히는 지점도 달랐습니다. 그래서 모든 유닛을 같은 진도로 밀어붙이지 않았습니다. 평일 08시부터 18시까지 상주한 이유도 여기에 있습니다. 막힘이 생긴 뒤 며칠 뒤에 피드백을 받는 구조가 아니라, 코드와 데이터의 병목이 생긴 자리에서 바로 확인하는 운영이 필요했습니다.

중간 발표는 이 병렬 운영의 기준점이었습니다. 4주차 중간에 5개 유닛이 현재까지의 산출물과 막힌 지점을 공유했고, 방향, 범위, 구현 완성도에 대한 피드백을 5주차 개선 과제로 정리했습니다. 마지막 6주차에는 각 유닛이 완성한 에이전트를 경영진에게 발표하고, 현업이 직접 만든 결과물과 그 과정을 본인 언어로 설명했습니다.

결과

이번 프로그램의 결과는 산출물의 존재보다 제작 주체에 의미가 있었습니다. 개발 경험이 전혀 없던 한화생명 현업 전문가들이 6주 만에 풀스택에 가까운 결과물을 직접 만들어 냈습니다. 5개 유닛은 각각의 주제로 산출물을 도출했고, 구체 업무 내용은 비공개로 유지한 상태에서 경영진 발표까지 마쳤습니다.

AX LABS가 코드를 대신 작성하지 않았다는 점도 중요했습니다. 참여자들은 Claude Code로 직접 코드를 쓰고, 데이터와 아키텍처 판단을 거치며 자기 도메인 과제를 구현했습니다. 그래서 프로그램 종료 시점의 결과물은 외부에서 만들어 전달한 파일이 아니라, 현업이 이후에도 이어서 디벨롭할 수 있는 상태로 남았습니다.

이 사례는 현업 전문가의 도메인 지식을 AI 코딩 환경과 연결하려면 강의보다 프로젝트 한 사이클을 닫는 운영이 더 중요하다는 점을 보여줍니다. 관련 접근은 AX Ops 방법론 →에서 더 보실 수 있습니다.