그 인터페이스는 누구의 과업도 아니었다

PMO 실전 노트 · Note 30

장애는 경계에서 났다.
경계는 누구의 것도 아니었다.

그 인터페이스는 누구의 과업도 아니었다 · HFC Consulting

---

여러 회사가 함께 들어오는 사업에서 가장 위험한 곳은 각 사의 안이 아니다. 사이다. 이 노트는 그 사이에서 멈춘 사업의 이야기다.

장면

한 공공기관의 시스템 구축 사업이었다. 주사업자가 업무 시스템을, 참여사가 AI 기반 분석 솔루션을 맡았다. 통합테스트 둘째 주, 업무 시스템에서 넘긴 데이터가 솔루션에서 절반만 조회됐다.

회의가 열렸다. 주사업자가 말했다. "저희는 연계 규격대로 보냈습니다. 수신 처리는 솔루션 쪽입니다." 참여사가 답했다. "저희 솔루션은 표준 입력만 받습니다. 변환 모듈은 저희 과업이 아닙니다." 양쪽 다 계약서를 펼쳤다. 양쪽 다 옳았다. 데이터를 보내는 과업과 받는 과업은 있었다. 그 사이를 잇는 변환은, 어느 쪽의 과업 목록에도 없었다. 발주 담당자가 물었다. "그럼 이건 누가 합니까." 회의실이 조용해졌다. 테스트 일정은 그 침묵 속에서 하루씩 밀리고 있었다.

그때의 선택

갈림길은 분명했다. 하나는 책임 공방을 끝까지 가는 것. 공문이 오가고, 감정이 상하고, 결론은 몇 주 뒤에나 난다. 테스트 일정은 그동안 서 있다. 다른 하나는 판정을 뒤로 미루고 일부터 움직이는 것이었다.

PMO는 회의의 안건을 바꿨다. "누구 책임인가"를 내리고 "누가 하면 가장 빠른가"를 올렸다. 변환 모듈은 솔루션 구조를 아는 참여사가 만들되, 그 공수는 경계 과업으로 별도 기록하고 정산 협의는 오픈 뒤로 미룬다는 합의서 한 장을 그 자리에서 썼다. 그리고 남은 통합테스트 기간에 할 일을 하나 추가했다. 인터페이스 정의서의 모든 항목에 송신 책임과 수신 책임, 그리고 변환 책임의 세 칸을 만들어 회사 이름을 적어 넣는 일이었다. 빈칸이 여덟 개 나왔다. 장애가 나기 전에 발견된 여덟 개였다.

복기

경계의 과업은 이름이 붙기 전까지 존재하지 않는다. 그리고 존재하지 않는 과업은 견적에도, 일정에도, 투입 계획에도 없다. 문제는 그것이 통합테스트라는 가장 늦고 가장 비싼 시점에 모습을 드러낸다는 것이다. 이때의 판정 회의는 필연적으로 책임 공방이 된다. 각 사의 계약서는 각 사를 지키기 위해 쓰였고, 그 사이의 빈칸을 지키는 문서는 처음부터 없었기 때문이다.

지금 다시 본다면, 이 여덟 개의 빈칸은 착수 단계에 찾을 수 있었다. 과업범위를 확정할 때 세 문서를 대사하며 경계 과업 목록을 따로 뽑는 절차(9기 2화, 과업범위 확정)가 있었다면, 그리고 기술협상 단계에서 연계 책임의 칸을 계약 문장으로 만들어 두었다면(8기 7화, 기술협상) 회의실의 두 계약서는 서로를 겨누지 않았을 것이다.

AI 솔루션이 들어오는 사업일수록 이 빈칸은 늘어난다. 모델은 표준 입력을 요구하고, 현장의 데이터는 표준이 아니기 때문이다. 그 간극을 메우는 변환과 정비가 누구의 과업인지, 계약서가 침묵하면 통합테스트가 대신 말하게 된다.

원칙 한 줄

경계의 과업은 이름을 붙이기 전까지 아무의 것도 아니다 — 인터페이스마다 송신·수신·변환의 세 칸을 만들고, 착수 단계에 회사 이름을 적게 하라.

본 사례는 실제 경험을 바탕으로 재구성·익명화되었습니다. 특정 기관·기업·사업과 무관합니다.

본 글은 일반적인 정보 제공을 목적으로 하며, 법률 자문이 아닙니다. 개별 사안은 법률 전문가와 상의하시기 바랍니다.

여러 회사가 함께하는 사업을 관리하고 계십니까?

HFC컨설팅은 컨소시엄 사업의 과업 경계 정의, 인터페이스 책임 매트릭스 수립, 다자 협의체 운영을 지원합니다. 빈칸은 장애가 나기 전에 찾아야 합니다.

changks@hfcconsulting.co.kr

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

---

📚 PMO 실전 노트 — 현장의 갈림길을 기록합니다

◀ 이전 노트 (Note 28): 리허설은 두 번 실패했다

코너 전체 보기 →