인수인계를 하지 않았다

새로 합류한 사람에게 인수인계를 하지 않았다. 자리에 앉혀 두고 우리 시스템이 어떻게 생겼는지 설명하지도, 무엇부터 깔아야 하는지 순서를 일러주지도 않았다. 온보딩 페이지 링크 하나를 건넸을 뿐이다.

얼마 뒤 그 사람의 개발 환경은 서 있었다. 자격 증명이 제자리에 들어갔고, 사내 서비스에 붙었고, 팀이 쓰는 업무 워크플로우를 그대로 돌리고 있었다. 그런데 그 셋업을 수행한 것은 그 사람이 아니다. 그 사람은 온보딩 페이지를 AI 에이전트에게 넘기고 ‘이대로 세워줘’ 라고 말했고, 에이전트가 처음부터 끝까지 실행했다.

이것은 사고가 아니라 의도한 설계였다. 다만 의도했다는 것과, 그 결과가 무엇을 뜻하는지 아는 것은 다른 일이다. 그 페이지를 만들기까지 반년이 걸렸고, 그 반년이 끝나고 나서야 내가 만든 것이 무엇이었는지 정리됐다. 나는 사람을 위한 안내서를 쓴 줄 알았는데, 실제로 완성된 것은 에이전트가 실행하는 절차였다.

인수인계라는 마찰

인수인계는 오랫동안 지식을 사람의 머리에서 사람의 머리로 옮기는 일이었다. 시스템의 지도를 상대의 머릿속에 복제하고, 복제가 충분한지 대화로 확인한다. 잘 됐는지는 대개 시간으로 쟀다. 얼마나 빨리 이해했는가.

이 방식의 비용은 인계하는 쪽에 집중된다. 설명하는 시간, 같은 질문에 다시 답하는 시간, 설명을 빠뜨려 나중에 사고로 돌아오는 시간. 그리고 이 비용은 사람이 늘 때마다 그대로 반복된다. 문서를 아무리 써 둬도 줄지 않는데, 문서는 늘 현실보다 뒤처져 있고 그 사실을 아는 사람만 문서를 신뢰하지 않기 때문이다.

내가 풀고 싶었던 문제는 문서를 잘 쓰는 방법이 아니었다. 인계라는 절차 자체를 없앨 수 있는가였다.

마찰이 물건을 부른다

돌아보면 반년 동안 지은 것들은 계획표에서 나오지 않았다. 앞의 것을 쓰다가 아팠던 자리에서 다음 것이 나왔다.

처음 지은 것은 빌드와 배포를 보여주는 화면이었다. 서버를 손으로 오가며 산출물을 나르는 일이 병목이었다. 그다음이 이슈와 작업을 모으는 대시보드였는데, 무엇이 밀렸는지 팀이 같은 화면을 보고 있지 않았기 때문이다. 그다음에 통합 게이트웨이를 세웠다. 도구마다 자격 증명을 따로 들고 있어서, 새 도구를 붙일 때마다 같은 비밀을 한 번 더 복사해야 했다.

게이트웨이가 서고 나니 다음 결핍이 드러났다. 에이전트가 한 일이 흔적 없이 흘러가서 팀 기록과 회고를 붙였고, 제품 지식이 사람 머리에만 있어서 문서 발행 파이프라인을 만들었다. 그리고 마지막에 온보딩 부트스트랩이 왔다. 이 전부를 남에게 넘겨야 했기 때문이다.

앞의 다섯이 반년이고, 마지막 하나는 하루 만에 나왔다. 이 비대칭이 이 글의 첫 번째 결론으로 이어진다.

표면을 줄이는 방향

지은 것들의 목록보다 중요한 것은 방향이다. 돌아보면 결정은 늘 같은 쪽을 향해 있었다. 도구를 늘리는 대신 표면을 줄이는 쪽이다.

사내 서비스 다섯 종 — 위키, 이슈 트래커, 파일 서버, 코드 호스팅, 제품 운영 대상 — 을 게이트웨이 하나 뒤로 모았다. 별도의 명령줄 도구를 따로 만들지 않았고, 부를 곳을 하나로 유지했다. 자격 증명도 마찬가지다. 흩어져 있던 것을 사용자 홈의 파일 하나로 모으고, 소비하는 쪽은 비밀을 읽지 않게 했다. 권한이 느슨하면 경고를 남기는 대신 기동을 거부하도록 했다. 볼 사람이 없는 경고는 검사가 아니다.

부트스트랩을 쓸 때도 같은 원칙을 지켰다. 다른 저장소의 설치 로직을 복사하지 않고 소유자에게 위임한다. 사본을 하나 만드는 순간 그 둘은 갈리기 시작하고, 갈린 사본은 반드시 오래된 쪽이 먼저 실행된다.

되돌린 것도 있다. 대시보드의 정보 구조를 전면 개편했다가 통째로 되돌리고, 값어치가 증명된 두 가지만 남겼다. 성능도 그런 식으로 잡혔다. 사용자가 페이지를 여는 순간 외부 API 를 긁어 오던 경로를 걷어내고 배경 루프가 미리 모아 두게 바꾸자, 화면 하나가 5.3 초에서 10 밀리초로 내려왔다. 요청 경로에서 수집하면 그 지연은 전부 사용자가 부담한다.

지금 업계에서 이 방향을 뒷받침하는 자료가 DORA 의 2025년 보고서다. AI 는 증폭기라서 잘하는 팀은 더 잘하고 무너지는 팀은 더 빨리 무너지며, 성과를 여는 역량 가운데 하나가 ‘양질의 내부 플랫폼’ 이라는 관찰이다. 내 경험에 비추면 전환점은 도구를 늘린 날이 아니라 표면을 줄인 날이었다.

골든패스는 설계물이 아니라 포장이다

플랫폼 엔지니어링 교과서는 골든패스를 먼저 깔고 사람을 그 위에 태우라고 말한다. 나는 정반대 순서로 갔다. 온보딩은 맨 마지막에 왔다.

그런데 그것이 실수였다고 생각하지 않는다. 온보딩 스크립트가 하루 만에 나온 이유는 앞의 반년 동안 내가 그 길을 여러 번 걸었기 때문이다. 어디서 넘어지는지, 무엇이 순서를 타는지, 무엇을 두 번 실행해도 안전해야 하는지를 이미 몸으로 알고 있었다. 검증도 그래서 가능했다. 깨끗한 계정에서 처음부터 끝까지 두 번 통과시켰는데, 걸어본 적 없는 길이었다면 무엇을 검증해야 하는지조차 몰랐을 것이다.

골든패스는 설계해서 까는 것이 아니라, 이미 걸어본 길을 넘겨야 할 때 포장하는 것이다. 표준을 먼저 세우고 사람을 태우려 하면 대개 아무도 걷지 않은 길에 아스팔트를 붓게 된다.

독자가 사람이 아니었다

여기서 생각이 한 칸 움직인다. 그 포장도로를 실제로 걸은 것이 사람이 아니었다.

에이전트가 문서를 읽고 실행하려면 그 문서와 시스템이 갖춰야 하는 성질이 사람용과 다르다. 그리고 그 성질들은 이미 앞의 결정 안에 들어 있었다.

# what the onboarding page had to guarantee for an agent to run it
1. one surface to call     - a single entry point, discoverable in one look
2. names that never move   - renaming a tool is a breaking change, not a cleanup
3. rerun-safe by default   - install and upgrade are the same command

부를 곳이 하나여야 에이전트가 무엇을 호출할지 헤매지 않는다. 이름이 계약이어야 호출이 안정된다. 멱등해야 중간에 실패해도 그냥 다시 돌리면 된다. 나는 이 셋을 사람의 편의를 위해 정했다고 믿고 있었는데, 실제로는 에이전트가 그 페이지를 실행하기 위한 조건이었다.

업계는 이것을 에이전트 경험(Agent Experience) 이라고 부른다. 2025년 초에 제안된 개념으로, 에이전트가 발견하고, 안정적으로 호출하고, 실패에서 회복할 수 있어야 한다는 세 가지를 든다. 우리가 아팠던 순서가 정확히 그 셋이었다.

여기서 흥미로운 것은 같은 두 글자가 국내에서는 다른 뜻으로 쓰인다는 점이다. 국내에서 AX 는 대체로 AI 전환, 곧 조직과 업무 방식을 AI 전제로 재설계하는 이야기다. 해외에서 AX 는 에이전트 경험, 곧 시스템의 표면을 에이전트가 쓸 수 있게 깎는 이야기다. 하나는 사람의 일하는 방식을 바꾸고, 하나는 시스템의 표면을 바꾼다.

내가 한 일은 후자였다. 조직을 개조해서 전환에 도달한 것이 아니라, 표면을 깎았더니 사람이 일을 시작하는 방식이 바뀌었다.

그러면 무엇을 재야 하나

인수인계의 목적이 이해의 전달이었으므로, 온보딩의 성공도 이해로 쟀다. 얼마나 빨리 파악했는가, 질문이 얼마나 줄었는가.

그런데 앞의 사례에서 그 사람은 시스템을 이해하지 않은 채로 일을 시작했다. 이해는 나중에, 필요한 만큼만 왔다. 그렇다면 재야 할 것이 바뀐다.

온보딩의 지표는 ‘사람이 이 시스템을 이해했는가’ 가 아니라, ‘사람이 AI 를 써서 이 시스템 위에서 일할 수 있는가’ 다.

이것은 온보딩만의 이야기로 끝나지 않는다. 문서 품질의 기준도 같은 축으로 옮겨간다. 좋은 문서란 이제 사람이 읽고 이해되는 문서인 동시에, 에이전트가 읽고 실행되는 문서다. 셋업 안내서를 쓸 때 확인할 항목이 하나 늘었다는 뜻이고, 그 항목은 검수로 확인되지 않는다. 실제로 에이전트에게 던져 보면 십 분 안에 드러난다.

마무리

물론 이 결론을 성과로만 읽으면 위험하다. 사람이 시스템을 이해하지 않고도 일할 수 있다는 것은, 이해가 필요해지는 순간에 대비가 없다는 뜻이기도 하다. 에이전트가 세운 환경이 이상하게 동작할 때, 그 사람은 무엇부터 봐야 하는지 모른다.

그러니 실행 가능성이 이해를 대체한 것은 아니다. 이해를 뒤로 미룬 것이고, 미뤄진 이해는 사고가 났을 때 이자까지 붙어 청구된다. 더 정확히 말하면 이해가 진입 조건에서 운영 조건으로 옮겨갔다. 시작하는 데는 필요 없어졌지만, 계속하는 데는 여전히 필요하다.

이전 글에서 나는 자동화의 방향이 사람을 사슬에서 들어내는 것이 아니라 사람이 서 있는 자리를 실행에서 감독으로 옮기는 것이라고 썼다. 이번 일은 그 이동이 신규 합류자에게까지 닿은 경우다. 새로 온 사람은 셋업을 실행하지 않았고, 실행된 결과를 감독하는 자리에서 시작했다.

부트스트랩은 환경을 세우지만 판단은 세우지 않는다. 그 자리를 무엇으로 채울지가 다음 과제다.