기능은 늘었는데, "왜 우리 제품인가"는 더 어려워졌다

CollabOps를 만들면서 제품을 설명하는 문장이 점점 길어졌다. 이슈를 관리하고, 저장소를 제공하고, 코드를 리뷰하고, CI/CD를 실행하고, 문서를 연결하고, AI를 붙인다. 각각 필요한 기능이고, 각각 만든 이유가 있었다.

근데 기능을 하나 추가할 때마다 제품의 가치가 그만큼 선명해지는 건 아니었다. 설명할 수 있는 것은 많아졌다. 고객이 지금 이 제품을 선택해야 하는 이유는 그것과 별개로 답해야 하는 질문이었다.

기능이 많아지면 제품 설명이 쉬워질까?

쉬워지지 않는다. 기능 목록은 만든 사람에게 가장 설득력 있는 결과물이지, 사는 사람에게는 아니다. 엔지니어에게 기능 목록은 꽤 설득력 있다. 그 안에 들어간 설계와 구현, 예외 처리와 운영의 어려움을 알기 때문이다. 나도 무엇을 구현했는지 설명할 때 제일 자신 있었다.

하지만 구매를 검토하는 고객은 그 개발 과정을 함께 겪지 않았다. 고객에게는 이미 돌아가는 업무가 있고, 그 업무에서 해결해야 하는 문제가 있다. 기능 하나가 그 문제의 어디에 닿는지 설명되지 않으면 목록은 그냥 길어질 뿐이다.

고객은 왜 같은 기능이 있어도 도구를 바꾸지 않나?

전환에는 기능과 무관한 비용이 들기 때문이다. Jira로 일을 관리하고 GitLab으로 코드를 검토하며 Jenkins로 배포하는 조직을 생각해 보자. 새 플랫폼이 같은 기능을 제공한다고 해도 그것만으로 옮겨야 할 이유가 되지는 않는다. 이전해야 할 데이터와 권한이 있고, 다시 익혀야 할 사용법이 있고, 새 운영 체계를 책임질 사람이 필요하다.

우리가 제품의 완성도를 설명하는 동안 고객은 전환에 필요한 일을 계산하고 있다. 그 계산은 정당하다. 연동과 마이그레이션 중 무엇이 맞는지는 커넥터를 다 만들어 놓고 왜 마이그레이션을 권하는가에서 따로 다뤘는데, 어느 쪽이든 출발점은 같다. 고객이 지금 무엇을 끝내지 못하고 있는가.

이 차이를 생각하면서 질문을 바꿨다. "우리에게 어떤 기능이 있는가"에 더해, "고객이 지금 내리지 못하는 결정은 무엇인가"를 묻기 시작했다.

고객이 지금 내리지 못하는 결정은 무엇인가?

우리가 집중하기로 한 결정은 하나다. 이 소프트웨어 변경을 운영 환경에 내보내도 되는가. 이번 배포에 어떤 변경이 포함되는지, 어느 코드로 만든 결과물인지, 검증은 그 결과물에 대해 수행됐는지, 승인 이후 달라진 것은 없는지. 도구별로는 기록이 다 있다. 근데 이 질문에 답하려면 여러 화면과 여러 사람을 거쳐야 하는 조직이 많다.

예시를 하나 들어보자. 한 기능이 프런트엔드와 백엔드 두 저장소에 걸쳐 있다. 이슈는 하나지만 변경 요청은 둘이고, 빌드 결과도 각각 생긴다. 백엔드를 다시 빌드했다면 이전 테스트와 승인을 어디까지 그대로 사용할 수 있을까. "둘 다 초록색"이라는 화면만으로는 어떤 조합을 검증했는지 알기 어렵다. 설명을 위한 가정이지만, 추적성에서 우리가 중요하게 보는 질문이 정확히 이것이다.

Change는 무엇을 하나로 모으나?

Change는 위의 판단을 한 단위로 모은다. 바꾸려는 의도, 정확한 코드 버전, 결과물, 검증 근거, 승인, 배포 이력. 이것들을 따로따로 찾는 대신 하나의 변경을 기준으로 함께 읽을 수 있게 만드는 것이다.

이 관점에서 보면 저장소와 파이프라인의 역할도 더 분명해진다. 각각의 기능은 독립된 제품이 아니라 하나의 변경을 설명하는 근거다. 저장소는 어느 코드였는지를, 파이프라인은 그 코드로 무엇을 만들고 무엇을 검사했는지를, 승인은 누가 어떤 근거를 보고 결정했는지를 남긴다. 저장소에서 배포까지 한 평면에 놓는 구조는 SCM에서 배포까지에 더 자세히 적었다.

추적성이 있으면 배포는 자동으로 안전해지나?

아니다. 관계를 연결했다고 배포의 안전성이 증명되지는 않는다. 테스트가 놓친 문제가 있을 수 있고, 운영 환경의 조건이 달라질 수도 있다. 추적성이 해야 할 일은 판단에 사용한 근거와 그 근거가 미치는 범위를 확인할 수 있게 하는 것이다. 모르는 부분까지 안전하다고 표시하면 오히려 잘못된 확신을 준다. 그래서 우리는 확인하지 못한 항목을 확인한 것처럼 보여주지 않는 쪽을 택했다.

이 방향이 실제로 효과를 내는지는 고객 환경에서 세 가지로 본다. 배포 근거를 찾는 시간이 줄었는가. 서로 다른 버전의 검증 결과를 혼동하는 일이 줄었는가. 문제가 생겼을 때 변경의 맥락을 더 빨리 복원할 수 있는가. 제품의 효과는 기능 개수가 아니라 이런 변화에서 확인해야 한다.

기능을 많이 만든 경험은 여전히 자산이다. 다만 그 자산을 어느 고객 문제에 집중할지 결정하는 일은 별도로 해야 했다. 그건 기능 목록을 정리하는 것보다 어렵고, 대표가 더 오래 붙들어야 하는 질문이었다.

요즘은 새 기능을 논의할 때마다 묻는다. 이 기능이 생기면 고객은 어떤 일을 끝낼 수 있는가. 어떤 결정을 더 확실하게 내릴 수 있는가. 그 답을 함께 설명할 수 있을 때 제품을 소개하는 문장도 조금씩 짧아진다.