이관: 지식은 문서가 아니라 사람 안에 있다 (03/08)

AI 시대의 운영·유지보수 · Ep.03

인수인계서는 서른 장이었다.
질문은 서른한 번째부터 나왔다.

이관: 지식은 문서가 아니라 사람 안에 있다 · HFC Consulting

---

운영 이관 문서는 서른 장이었다. 화면 목록, 배치 스케줄, 장애 이력, 연락망까지 빠짐없이 정리되어 있었다. 운영팀이 투입 2주 차에 처음 겪은 장애 앞에서, 그 서른 장 어디에도 답이 없었다. 필요한 것은 "왜 이 로직을 이렇게 짰는가"였다. 그 질문의 답은 이미 프로젝트를 떠난 개발자의 머릿속에만 있었다.

이번 화는 이관 문서가 채우지 못하는 자리에 관한 이야기다.

오픈 전 가정 — 문서가 충분하면 사람은 바뀌어도 된다

이관 계획은 대개 문서량으로 완성도를 잰다. 매뉴얼, 화면 정의서, 장애 대응 절차서가 갖춰지면 이관이 끝났다고 본다. 이 가정에는 전제가 있다. 시스템에 대한 지식이 전부 문서화 가능하다는 전제다.

오픈 후 현실 — 문서 밖의 지식이 더 크다

실제로 시스템을 지탱하는 지식의 상당 부분은 암묵지다. 왜 이 예외 처리를 넣었는지, 어떤 요구가 왜 반영되지 않았는지, 어느 배치가 특정 요일에 유독 오래 걸리는지. 이런 지식은 매뉴얼의 문장이 아니라 개발자의 경험 안에 있다. AI가 코드 생산을 압축한 시대에는 이 격차가 더 벌어진다. 코드는 빠르게 나왔지만, 그 코드를 왜 그렇게 짰는지에 대한 대화는 생산 속도만큼 기록되지 않는다.

담당자가 바뀌면 조직은 문서만 남고 맥락은 사라진다고 흔히 말한다. 정확히는 반대다. 맥락은 애초에 문서에 담긴 적이 없다. 회의실 대화, 급하게 내린 판단, "일단 이렇게 하고 나중에 고치자"던 합의는 회의록에도, 코드 주석에도 남지 않는다. 이관 시점에 그 담당자가 떠나면, 조직은 처음부터 존재하지 않았던 것처럼 그 맥락을 잃는다. 몇 달 뒤 비슷한 문제가 재발했을 때, 운영팀은 처음 겪는 문제로 착각하고 이미 한 번 풀렸던 고민을 처음부터 다시 시작하게 된다.

그래서 이관은 문서의 이전이 아니라 의사결정 맥락의 이전이어야 한다. 프롬프트 시대의 의사결정을 ADR로 기록해야 한다는 원칙은 3기 5화에서 다뤘다. 개인 채팅창에 머무는 논의가 거버넌스 공백을 만든다는 지적은 1기 8화에서 나왔다. 운영 이관은 이 두 원칙이 실제로 작동하는지 시험받는 첫 순간이다.

이관에 넣을 문구와 절차

지식 이관 체크리스트 6

① ADR·의사결정기록이 운영팀에 접근 가능한 형태로 이관되었는가.

② 프롬프트 로그 중 핵심 로직 생성에 사용된 것이 별도 인덱싱되어 있는가.

③ 개발 인력과 운영 인력이 최소 2주 이상 겹치는 기간을 두었는가.

④ 겹치는 기간 동안 운영팀이 실제 장애 대응을 1회 이상 동행했는가.

⑤ "왜 이렇게 만들었는가" 질의응답 세션을 별도로 진행했는가.

⑥ 이관 후 질의 창구(연락 가능 기간·범위)가 계약에 명시되어 있는가.

지식 이전 완료 확인서 양식 (예시) — "본 확인서는 아래 항목의 이관 완료를 발주기관·수급인 쌍방이 확인함을 증명한다."

① 시스템 문서 이관 완료 여부

② 의사결정기록(ADR) 이관 완료 여부

③ 질의응답 세션 실시 여부 및 잔여 질의 목록

예상 반론과 대응

반론 — "겹치는 기간을 두면 인건비가 이중으로 들어간다. 계약 범위 밖의 비용 아닌가."

대응 — 겹치는 기간의 비용과, 이관 실패 후 첫 장애를 며칠씩 붙잡고 있는 비용을 비교하면 답은 명확하다. 후자가 훨씬 크고, 그 비용은 눈에 보이지 않는 형태(고객 불만, 담당자 야근, 신뢰 손실)로 청구된다. 겹치는 기간은 비용이 아니라 보험이다. 이 보험료를 RFP·계약 단계에서 미리 반영하는 것이 이상적이며, 6기에서 다룬 예산 책정의 연장선이다.

질의응답 세션의 형식도 중요하다. 개발자에게 "질문 있으면 하십시오"라고 열어 두는 방식은 대체로 실패한다. 무엇을 물어야 할지 모르는 사람은 질문하지 않는다. 효과적인 방식은 운영팀이 시스템을 직접 붙잡고 씨름하다 막히는 지점에서 질문이 자연히 튀어나오게 하는 것이다. 그래서 동행 장애 대응이 문서 검토보다 더 확실한 이관 수단이 된다.

체크포인트 — ADR 이관 여부 / 프롬프트 로그 인덱싱 / 인력 중첩 기간 / 동행 장애 대응 / 질의응답 세션 / 완료 확인서 서명

이관을 계약 조건으로 명시하지 않으면, 이 과정 전체가 개발 조직의 선의에 맡겨진다. 선의는 일정이 촉박해지는 순간 가장 먼저 줄어드는 자원이다. 다음 사업 투입이 정해진 개발자에게 이관은 우선순위에서 밀리고, 문서 서른 장을 넘기는 것으로 의무를 다했다고 여기게 된다. 이관의 품질을 개인의 성실함이 아니라 계약과 절차로 보장해야 하는 이유다. 좋은 개발자를 만난 조직은 운이 좋았을 뿐이고, 좋은 절차를 가진 조직은 그 운에 기대지 않는다. 절차는 사람이 바뀌어도 남지만, 선의는 그 사람과 함께 떠난다. 좋은 이관 절차를 갖춘 조직은 담당자가 몇 번을 바뀌어도 같은 품질의 인수인계를 반복할 수 있다. 그 반복 가능성이야말로 조직의 실력이지, 특정 개발자 한 사람의 성실함이 조직의 실력을 대신할 수는 없다.

서른 장의 문서는 무엇을 만들었는지 기록한다. 왜 그렇게 만들었는지는 다른 문서, 다른 노력이 필요하다. 이관이 완성되는 것은 그 두 번째 문서가 실제로 건너갈 때다.

📎 더 읽을거리

소프트웨어 진흥법 시행령 (국가법령정보센터) — 소프트웨어사업의 산출물·문서 관리 관련 규정 원문

HFC의 관점

귀사의 다음 이관, 문서 서른 장 다음에는 무엇이 준비되어 있습니까. HFC컨설팅은 문서 이관을 넘어 의사결정 맥락까지 넘기는 이관 체계를 설계합니다.

changks@hfcconsulting.co.kr

1영업일 이내 답변 · 주식회사 에이치에프씨 컨설팅 · 대표이사 장기석

본 연재의 문구·양식 예시는 법률 자문을 대체하지 않으며, 실제 발주·계약 시 법무 검토를 권장합니다.

---

📚 AI 시대의 운영·유지보수 (전 8화)

◀ 이전 편: 02 SLA: AI 시대에 다시 쓰는 서비스수준협약

다음 편 ▶ 04 하자담보책임의 경계: AI가 만든 버그는 누구 책임인가

연재 전체 보기 →