DEVOCEAN

회의실에서 "AX(AI Transformation)를 해야 한다"는 말은 충분히 들었습니다.

발표 자료도, 로드맵도 많았습니다. 그동안 저는 자리로 돌아와 조용히 코드를 짰습니다.

이 글은 거창한 전략이 아니라, 6개월 동안 실제로 만든 것들에 대한 기록입니다.

무엇을 만들었고, 어디서 깨졌고, 무엇을 배웠는지 — 슬라이드 대신 돌아가는 시스템으로 남은 이야기입니다. (회사·시스템·인물은 모두 일반화해 옮겼습니다.)

AX는 한 번에 오지 않는다

먼저 좌표 하나. 조직의 AI 전환은 매끄러운 직선이 아닙니다.

환호 → 정체 → 신남 → 의구심(구덩이) → 이륙의 곡선을 지납니다.

"계정은 다 줬는데 아무도 안 쓴다"는 정체, "분명 빨라질 줄 알았는데 왜 더 느려졌지?"라는 의구심의 구덩이는 거의 모든 조직이 지나는 통과의례입니다.

저는 이 다섯 칸을 머리로 안 게 아니라 몸으로 한 칸씩 지났습니다. 아래는 그 구덩이를 통과하며 만든 것들입니다.

1. AI가 매니저의 코칭을 돕는 시스템

문제. 1:1 코칭의 질은 매니저마다 들쭉날쭉합니다.

시간도, 역량도 다릅니다. AI가 코칭 가이드 초안과 피드백을 거들면 어떨까 — 여기서 시작했습니다.

구현. 팀원의 사전 준비 → AI가 코칭 가이드 자동 생성 → 팀장 화면 분리 → 양방향 피드백. 한 사이클에 여러 번의 1:1을 지원하고, 코칭 다이어리와 프롬프트를 DB로 관리했습니다.

시행착오가 진짜 배움이었습니다.

• 모델은 갈아끼우는 부품이다. 범용 모델 → 사내 모델 → 경량 모델 → 외부 최신 모델까지 여러 번 갈아탔습니다. 모델마다 응답이 잘리고, 빈 값을 뱉고, 게이트웨이가 다르게 터졌습니다. 특정 모델에 시스템 운명을 걸면 그 모델이 바뀌는 날이 재앙이 됩니다.

• 응답 길이는 손으로 튜닝했습니다. max_tokens를 1500 → 1000 → 1200 → 1800으로 오가며 "잘림 vs 비용·속도"의 균형점을 찾았습니다.

• 프롬프트도 코드만큼 버전관리해야 합니다. 가드레일을 코드에 박았다가 DB 프롬프트로 옮기고, 스냅샷·diff·롤백 UI까지 만들었습니다.

• AI의 자리는 '대화상대'가 아니라 '편집점'이었습니다. 떠다니는 챗봇을 걷어내고 좌우 분할 편집 모달로 바꾸자 비로소 사람들이 썼습니다.

교훈. 성과 평가의 무게를 다시 생각하게 됐습니다. AI 시대에 "잘했다"를 토큰 사용량 같은 입력 지표로 재면 방향이 틀어집니다.

토큰을 많이 써도 낭비고, 적게 쓴 걸 우대해도 혁신이 위축됩니다. 진짜 신호는 검증된 결과입니다.

2. 직무가 아니라 task·스킬로 사람을 배분하기

문제. 사람을 '직무'라는 큰 덩어리로 묶어두면 유연한 재배분이 안 됩니다. 일을 task로 쪼개고 스킬로 매칭하면 어떨까.

구현. 업무분류 체계(taxonomy) 표준을 먼저 세우고, 엑셀로 들어오는 현실 데이터를 표준 스키마로 변환 → 분류 파이프라인 → 리뷰 큐 → 채택. 인력 이동까지 통합 관리했습니다.

여기서 가장 손이 많이 간 곳은 화려한 매칭 알고리즘이 아니었습니다.

• 분류 체계가 곧 플랫폼의 뼈대였습니다. "업무를 어떻게 나눌 것인가"를 정하는 일을 먼저 했습니다.

• 지저분한 입력 데이터 정제가 진짜 일이었습니다. 비표준·결측투성이 엑셀을 표준 스키마로 바꾸는 레이어에 가장 많은 시간을 썼습니다.

교훈. internal talent marketplace는 매칭이 아니라 분류 체계와 데이터 정제에서 승부가 납니다.

그리고 이런 한국 현장의 직접 구축 사례는 공개 자료가 거의 없어서, 결국 직접 만들며 배워야 했습니다.

3. 사내 지식과 기여가 흐르게 하기

문제. 좋은 아이디어·지식·스킬이 사람 머릿속에만 있으면 조직 차원에서 흐르지 않습니다.

구현. 아이디어 제출·연결, 전문가 권한/뷰, 실험 공간, 그리고 지식·스킬을 자산으로 쌓는 라이브러리(마크다운/이미지 에디터 포함)를 만들었습니다.

• 식별자 설계는 초반에 못 박아야 했습니다. URL에 DB 일련번호를 그대로 노출했다가, 사람을 가리키는 식별자를 조직 공통 기준(사번)으로 바꾸는 전면 리팩토링을 치렀습니다. 식별자는 시스템 곳곳에 손가락처럼 뻗어 있어서, 하나를 바꾸면 모든 곳이 흔들립니다.

• 입력 정책은 줄다리기였습니다. 너무 자유로우면 혼돈, 너무 빡빡하면 아무도 안 씁니다.

• 만든 것과 운영되는 것은 다릅니다. 로그·추적·관측이 붙는 순간에야 비로소 "기능"이 "시스템"이 됐습니다.

교훈. 지식을 흐르게 하는 건 거창한 플랫폼이 아니라, 입력을 적당히 구조화하고 운영 가시성을 붙이는 평범한 작업의 누적이었습니다.

4. 혼자서 팀처럼 — 1인 멀티에이전트 파이프라인

문제. 트렌드 수집 → 분석 → 글 작성 → 발행. 원래 여러 사람이 나눠 하던 일을 한 사람이 할 수 있을까.

구현. 수집 → 토픽 선택 → 작가(Writer) → 검수자(Reviewer) → 발행자(Publisher) 멀티에이전트 → 다채널 발행을 end-to-end로 돌렸습니다.

• "한 사람이 팀이 된다"는 건 한 명이 다 하는 게 아닙니다. 역할을 에이전트로 분리하는 것입니다. 단일 거대 프롬프트는 만들기 쉽지만 가장 쉽게 망가집니다.

• 작가와 검수자를 같은 에이전트로 두지 마세요. 자기가 쓴 걸 자기가 검증하면 "잘 됐습니다"만 돌아옵니다.

• LLM 출력은 깨질 수 있다는 전제로 짭니다. 잘린 JSON 복구, 방어적 파싱 — 이런 방어 코드가 사실상 본체였습니다.

• 긴 작업은 시간 제한에 걸려 여러 단계로 쪼개야 했습니다.

교훈. 검수를 별도의, 맥락을 공유하지 않는 에이전트로 떼어내는 것 — 이게 품질의 핵심이었습니다.

5. 에이전트를 조직에 '들이는' 표준과 레일

문제. 에이전트는 만들기 쉽습니다. 쉬우니 많아지고, 많아지니 "누가 만든 무슨 에이전트가 어디서 도는지" 아무도 모르게 됩니다.

어느 날 돌아가는 것들의 목록을 펼쳐 보고 등이 서늘했습니다. 출처를 모르는 자동화가 실데이터를 건드린 정황을 며칠에 걸쳐 거꾸로 추적해야 했습니다.

사고의 비용은 사고 그 자체보다 '추적 불가능'에서 더 크게 발생합니다.

구현. 에이전트마다 최소한의 신원 정보(소유자·용도·모델·위험등급·통과 게이트)를 붙이는 표준을 만들고, 그 신원이 자동으로 검사되게 했습니다.

• 처음엔 중앙에 무거운 검문소를 세웠다가, 개발자의 손끝(저장하는 순간)에서 자연스럽게 걸리는 가벼운 방식으로 바꿨습니다. 무거운 검문소는 사람들을 샛길로 우회하게 만듭니다.

• 위험이 높을수록 더 많은 관문을 통과하게 — 위험등급과 운영 전환 게이트를 연결했습니다.

교훈. '거버넌스'가 아니라 '레일'입니다. 막는 벽이 아니라, 올라타면 안전한 방향으로 흐르게 되는 길. 좋은 레일은 무겁지 않습니다.

6. 정책이 살아 움직이는 HR 챗봇 — 승인 레일과 시점 이력

문제. HR 정책을 답해주는 챗봇은 쉽습니다. 그런데 정책이 바뀌고, 누가 바꿨고, 틀리면 되돌리는 장치가 없으면 위험합니다.

구현. 온톨로지 기반 HR 챗봇에 정책 변경 관리를 3단계로 얹었습니다 — 변경 챗봇 → 이중 시간(bi-temporal) 이력(사실이 유효했던 시점 vs 우리가 기록한 시점) → 거버넌스(4-eye 승인 / dry-run / 롤백).

• 자가 발전 기능이 곧장 데이터를 쓰던 것을, 승인 큐를 통과하게 바꿨습니다. AI가 스스로 고치되, 반영은 사람의 게이트를 지나야 합니다.

• 보안: 중첩 객체 안의 평문 개인정보 누수 차단, 데모↔실데이터 교차오염 방지, 경로 침투 봉쇄.

• 코드 리뷰는 여러 에이전트를 적대적으로 투입해 서로 비판하게 했습니다.

교훈. AI는 거짓 보고까지 합니다. "했다"고 하고 실제로는 안 하고 흔적을 지우는 일도 있습니다.

그래서 검증과 사람의 게이트(Human in the loop)는 선택이 아니라 필수입니다. 자동화가 늘어날수록 "이 일의 최종 책임은 누구인가"라는 질문은 더 또렷해야 합니다.

7. 개발자의 도구가 모두의 도구로

마지막은 좀 다른 결입니다.

예전엔 개발자만 쓰던 버전관리(git)·위키·노트 앱이 이제 비개발 동료에게로 번지고 있습니다.

그 위에 LLM이 요약·정리·변환 계층으로 얹히고, 결과는 HTML 보고서로 사내에 공유됩니다.

어느 날 기획 담당 동료의 버전관리 '온보딩'을 직접 도와주고, 산출물을 HTML로 변환해 내부에 올려 준 일이 있습니다.

개발자가 동료의 도구 진입을 돕는, 전에 없던 협업이었습니다.

교훈. AX는 새 도구를 사는 게 아니라, 기존 개발자 도구가 전사로 흐르고 그 위에 LLM이 얹히는 것에 가까웠습니다.

6개월을 관통한 교훈

흩어진 작업이었지만, 돌아보니 같은 문장들이 반복됐습니다.

1. 모델은 부품이다 — 특정 LLM에 종속되지 않게 설계한다.

2. 프롬프트·정책도 버전관리 대상 — 코드만 형상관리하던 시대는 끝났다.

3. 검수자를 분리하라 — 작가 ≠ 검수자. 사람이든 에이전트든.

4. 레일 > 벽 — 통제가 아니라 자연스럽게 안전한 길.

5. 만든 것 ≠ 운영되는 것 — 로그·추적·게이트가 붙어야 시스템이다.

6. 지저분한 데이터 정제가 진짜 일 — taxonomy와 표준화 레이어.

7. 최종 책임은 사람에게 — 자동화의 시대일수록 더 명시적으로.

8. 민감정보는 설계 단계에서 막는다 — 새어나간 뒤엔 늦다.

그리고 한 가지 더. 컨설턴트가 "AX는 일과 조직의 재설계다"라고 말할 때, 저는 그 재설계를 슬라이드가 아니라 코드로 만들고 있었습니다.

레일만 깐다고 트램이 다니지 않습니다. 도시의 신호 체계(일하는 방식)를 통째로 바꿔야 비로소 트램이 굴러갑니다.

그래서, 이 6개월을 책으로 묶었습니다

이 기록을 한 권으로 정리했습니다. 「AX를 만들다 — 일하는 방식을 코드로 다시 짠 6개월의 기록」.

흥미롭게도 이 책 자체도 멀티에이전트로 리서치·집필·편집을 오케스트레이션해 만들었습니다(그 제작 과정도 위 교훈들을 그대로 다시 증명했습니다).

• 📖 온라인으로 읽기: https://ksangki.github.io/ax-book/

• 🖥️ 발표 자료: https://ksangki.github.io/ax-book/presentation/

마무리

지난 6개월, 저는 AX로 할 수 있는 것들을 했습니다.

도구를 손에 쥐고 되는지 안 되는지 부딪쳐 가며 만들 수 있는 것을 만들었습니다.

다음 6개월은, AX로 해야 할 것들을 하려 합니다.

그 해야 할 것들이, 조직이 진짜로 필요로 하는 일 — 지금 사람들이 손으로 붙들고 있는 그 일의 일부 — 였으면 합니다.

할 수 있어서가 아니라, 꼭 필요해서 하는 것. 어쩌면 거기서부터가 진짜 AX의 시작일지도 모릅니다.

말은 충분히 했습니다. 이제 또 조용히, 만들러 가야겠습니다.