폭포수와 거버넌스의 세계에 통합 플랫폼이 필요한가, 어느 SI 현장에서 받은 질문에 대한 긴 답변

얼마 전에 국내에서 다섯 손가락 안에 드는 규모의 시스템을 25년 만에 차세대로 전환하는 프로젝트 팀 앞에서 데모를 했다. DevOps 가 뭔지 설명할 필요가 없는 자리였다. 시작하자마자 이런 말을 들었으니까.

"저희는 CI/CD 가 구조화되어 있고, 딜리버리까지 툴체인으로 자동화되어 있습니다. 도구도 지식도 이미 있어요. 개념 말고, 그 위에 뭐가 더해지는지를 말씀해 주시죠."

그리고 미팅 막바지에 프로젝트를 총괄하는 PM 이 이렇게 정리했다.

"저희는 SI 에서 애자일로 안 합니다. 요구사항 분석, 설계, 구현. 전통적인 폭포수예요. 기획에만 1년을 쓰고 거버넌스는 아주 엄격하게 갑니다. 이렇게 관리한 걸 개발/운영 조직에 이관하는 게 저희 고민이고요."

돌아오는 길 내내 이 질문을 생각했다. 도전적이긴 한데 정당한 질문이고, 정당한 질문에는 그 자리에서 한 답보다 긴 답을 빚졌다고 생각한다. 그래서 이 글을 쓴다.

질문을 분해하면

"우리한테 굳이 필요한가?"라는 질문은 사실 세 개의 전제 위에 서 있다.

1. 우리는 애자일이 아니라 폭포수다. 그런데 이런 플랫폼은 애자일 도구 아닌가.
2. 우리는 도구를 이미 다 갖췄다. 더 살 게 없지 않나.
3. 우리는 거버넌스가 충분히 엄격하다. 관리는 이미 잘 되고 있지 않나.

세 전제가 모두 참이면 결론도 참이다. 필요 없다. 그러니 하나씩 보자. 미리 말해두면 나는 셋 다 문제가 있다고 생각하는데, 재미있는 건 가장 중요한 실마리가 그들이 마지막에 스스로 꺼낸 단어에 있다는 점이다. 이관.

전제 1. "이건 애자일 도구다"

이 전제는 범주를 혼동하고 있다. 애자일은 방법론이고 DevOps 는 인프라다.

CI 파이프라인, 형상관리, 자동화 배포, 변경 추적. 이 중 어느 것도 2주 이터레이션을 전제하지 않는다. 커밋이 발생하고 빌드가 돌고 산출물이 나가는 흐름은 그 작업이 백로그에서 왔는지 WBS 에서 왔는지 묻지 않는다. 스프린트 보드가 안 맞으면 안 쓰면 된다. 실제로 우리 고객 중에 스프린트 기능을 한 번도 안 켠 곳이 있다.

여기까지는 오해를 푸는 이야기다. 더 중요한 관찰은 따로 있다. 이 인프라가 없을 때 가장 비싸게 터지는 방법론이 다름 아닌 폭포수다.

폭포수는 통합 리스크를 구조적으로 뒤로 미룬다. 200~300명이 1년 넘게 각자의 모듈을 만들고, 테스트 단계에 와서야 전체가 처음으로 합쳐진다. 애자일 조직이 2주마다 할부로 내는 통합 비용을 폭포수 조직은 프로젝트에서 가장 압축적인 구간에 일시불로 낸다. 그 구간에 일일 빌드와 자동화된 통합 파이프라인이 없으면 계획서의 "테스트 기간"은 실제로는 "통합 문제를 처음 발견하는 기간"이 된다. 이 업계에서 오래 일한 사람치고 그 광경을 못 본 사람은 없을 것이다.

그러니까 인과가 통념과 반대다. 애자일이라서 CI/CD 를 하는 게 아니라, CI/CD 없는 폭포수가 가장 위험한 조합이다.

물론 이 조직은 CI/CD 를 갖췄다. 그러니 전제 1을 걷어내도 그들의 질문은 그대로 남는다. 진짜 논점은 다음이다.

전제 2. "도구는 이미 다 있다"

맞는 말이다. 이슈 트래커 있고, 저장소 있고, CI 서버 있고, 배포 자동화도 있다. 기능 목록을 놓고 비교하면 우리가 더 채울 칸이 별로 없다.

그런데 이 전제에는 숨은 가정이 하나 있다. 도구의 합이 곧 플랫폼이라는 가정. 나는 이게 틀렸다고 본다.

도구가 N 개면 그 사이의 연동 지점은 최대 N×(N−1)/2 개다. 다섯 개면 열 개. 각 지점은 API 토큰과 웹훅과 스키마 매핑을 요구하고, 무엇보다 그걸 유지보수할 담당자를 요구한다. 3년짜리 프로젝트라면 그 열 개의 접점이 3년 내내 깨질 기회를 갖는다. 도구 하나가 버전업을 하면 주변 연동이 따라서 흔들린다. 이 연동을 잇고 고치는 노동이 어느 조직에나 있는데, 어느 조직의 조직도에도 없다.

이슈 트래커는 자기가 주인인 영역만 안다. CI 는 배포 도구의 상태를 모르고, 배포 도구는 어떤 요구사항이 함께 나갔는지 모른다. 각 도구가 알아서 잘 돌아가는 것과 그 사이의 맥락이 연결되어 있는 것은 완전히 다른 문제다. 전자는 도구를 사면 되지만 후자는 살 수가 없다.

이 지점에서 같은 자리에 있던 다른 분이 좋은 반론을 냈다. "묶은 건 알겠는데, 어떤 팀은 이슈 관리만 필요해요. 그런 팀한테는 과잉 아닌가요?"

내 답은 이거였다. 도입은 부분적이어도 된다. 통합은 부분적일 수 없다.

이슈만 쓰는 팀은 이슈만 쓰면 된다. 안 쓰는 기능은 화면에서 안 보일 뿐이다. 하지만 "이슈 트래커"와 "공유 그래프 위의 이슈 트래커"의 차이는 다른 팀의 파이프라인이 그 팀의 이슈를 참조해야 하는 날 드러난다. 배포 실패가 이슈에 자동으로 걸리고 변경요청 승인이 파이프라인 게이트가 되는 건 두 기능이 같은 평면에 있을 때만 성립하는 이야기고, 나중에 연동으로 소급해서 만들 수 없다. 기능은 나중에 추가할 수 있다. 속성은 처음부터 있거나 영원히 없다.

그래서 안 쓰는 기능은 비용이 아니라 옵션이다. 조직이 바뀌고 방법론이 바뀌어도, 차세대가 끝나고 운영 단계에서 애자일 요소가 섞여 들어오더라도, 도구와 데이터를 갈아엎지 않아도 된다는 옵션.

전제 3. "거버넌스는 이미 엄격하다"

이 전제가 제일 흥미롭다. 틀린 말이 아니기 때문이다. 이 전제는 맞고, 맞다는 사실이 오히려 계산을 뒤집는다.

엄격한 거버넌스란 결국 증적의 체계다. 어떤 요구사항이 언제 왜 바뀌었고 누가 승인했는지. 이 변경이 어떤 검수 게이트를 통과했는지. 지금 운영에 나가 있는 버전이 어떤 결재를 거쳐 나갔는지. 감사가 들어오면 이 질문들에 답해야 하고, 이 조직은 실제로 답한다. 문제는 어떻게 답하느냐다.

도구가 파편화된 환경에서 그 답이 만들어지는 과정을 나는 여러 현장에서 봤다. 이슈 트래커 화면을 캡처하고, 저장소에서 커밋 로그를 뽑고, CI 서버에서 빌드 이력을 내리고, 결재 시스템에서 승인 문서를 찾아서, 누군가 엑셀에 손으로 이어 붙인다. 도구와 도구 사이의 경계마다 증적이 한 번씩 끊어지고, 끊어진 자리를 잇는 건 언제나 사람의 야근이다.

여기서 나오는 결론이 아마 이 글에서 제일 중요한 문장일 것이다. 파편화된 툴체인 위에서 거버넌스는 엄격해지는 만큼 정확히 비례해서 비싸진다. 거버넌스가 엄격하다는 건 통합 플랫폼이 필요 없다는 근거가 아니라, 그만큼 파편화의 세금을 많이 내고 있다는 뜻이다.

요구사항, 변경요청, 승인, 커밋, 빌드, 배포가 처음부터 한 그래프 위의 연결된 사건이라면 증적은 만들어내는 산출물이 아니라 일하는 행위의 부산물이다. 감사 대응이 문서 작성 프로젝트에서 조회로 바뀐다. 거버넌스를 완화하자는 얘기가 아니다. 같은 엄격함을 사람의 규율이 아니라 시스템의 속성으로 만들자는 얘기다.

1년짜리 기획도 같은 구조다. 그 1년간 생산되는 요구사항 정의와 설계 결정은 문서 서버에 스냅샷으로 얼어붙는 순간부터 낡기 시작한다. 구현 중에 요구사항은 바뀐다. 반드시 바뀐다. 그때마다 문서와 코드의 거리가 벌어지고 그 거리를 아는 사람은 줄어든다. 기획 산출물이 실행 그래프에 연결되어 있다는 건 3년 뒤에도 "이 코드가 왜 이렇게 생겼지?"의 답이 클릭 몇 번 거리에 있다는 뜻이다.

그리고 그들이 스스로 꺼낸 단어, 이관

여기까지가 질문에 대한 답이라면 지금부터는 질문에 없던 답이다. PM 이 마지막에 고민이라고 말한 그것.

폭포수 SI 의 마지막 단계는 배포가 아니다. 조직 간 컨텍스트 이전이다. 300명이 3년 동안 만든 시스템이 운영 조직으로 넘어가는 순간 만든 조직은 해산한다. 다음 10년 동안 이 시스템을 고칠 사람들은 아까 그 감사 질문들과 똑같은 질문에 답해야 한다. 이 화면은 어떤 요구사항에서 왔는가. 이 모듈의 마지막 수정은 어떤 장애 때문이었는가. 단, 이번에는 답을 아는 사람이 회사에 없다.

파편화된 환경에서 그 답은 인수인계 문서 어딘가에 스냅샷으로 존재한다. 문서는 이관 시점에 이미 낡아 있고 쓴 사람들은 다음 프로젝트로 떠났다. 운영 조직은 시스템과 함께, 그 답을 처음부터 다시 찾아내야 하는 숙제를 물려받는다.

컨텍스트가 하나의 그래프에 있으면 이관의 성격 자체가 바뀐다. 산출물을 전달하는 행사가 아니라 살아 있는 컨텍스트에 대한 접근 권한을 전환하는 절차가 된다. 25년 만의 차세대라면 이 차이의 무게는 배가 된다. 이번 프로젝트에서 쌓이는 컨텍스트가 다음 25년의 유지보수 자산이기 때문이다. 그 자산을 문서와 스프레드시트의 스냅샷으로 남길 것인가, 이슈에서 커밋과 빌드 로그까지 내려가지는 그래프로 남길 것인가.

전제 1, 2, 3에 다 동의하지 않는 조직이라도 이관 앞에서는 계산이 달라진다고 생각한다. 통합 평면은 개별 도구의 어떤 조합으로도 복제할 수 없는 걸 딱 하나 갖고 있는데, 통째로 넘겨줄 수 있다는 것이다.

우리가 못 하는 것

이 논증이 신뢰를 얻으려면 한계도 같은 정확도로 말해야 한다. 그 미팅에서 우리가 인정한 것들이다.

프로덕션에 실제로 어떤 형상이 떠 있는지, 플랫폼은 스스로 검증하지 못한다. 파이프라인이 뭘 내보냈는지는 알지만 런타임의 실제 상태를 관측하는 건 구조적으로 다른 문제다. 우리 한계이고, 모든 CI/CD 플랫폼의 한계다.

방법론도 대체하지 않는다. 단계를 어떻게 자르고 게이트를 어디에 둘지는 여전히 조직의 판단이다. 플랫폼의 일은 그 판단이 내려진 다음부터다.

그리고 200명이 압축적으로 일하는 구간에서 얼마나 좋아지는가. 이건 실측의 영역이다. 우리가 우리 제품을 쓰면서 체감한 수치는 있지만 그 규모의 SI 현장에서 나온 수치는 아직 없다. 미팅에서 주장할 게 아니라 파일럿에서 측정할 일이다.

세 전제가 수렴하는 곳

세 전제로 돌아가자. "애자일 도구 아닌가"는 범주 오류였고, 오히려 폭포수가 이 인프라를 가장 절실하게 필요로 한다. "도구는 다 있다"는 도구의 합과 평면을 혼동한 것이고, 그 차이는 연동 매트릭스와 함께 3년 내내 청구된다. "거버넌스는 엄격하다"는 사실인데, 파편화된 환경에서 그 엄격함은 엄격해지는 만큼 비싸진다. 그리고 이 모든 논증이 수렴하는 지점이 이관이다. 만든 조직이 해산하는 산업에서, 넘겨줄 수 있는 형태로 컨텍스트를 쌓는 것보다 중요한 인프라 결정은 별로 없다.

방법론은 바꾸지 않아도 된다. 바꿔야 하는 건 컨텍스트가 사람의 기억과 문서의 스냅샷에만 사는 상태다.