우리는 왜 고객이 쓰는 도구부터 바꾸려 했을까

이전에 커넥터를 다 만들어 놓고 왜 마이그레이션을 권하는가를 썼다. 이슈부터 코드, 빌드, 배포까지 같은 구조에서 관리하면 관계와 권한, 실행을 더 일관되게 다룰 수 있다는 생각이었다. 지금도 그 장점은 그대로다. 다만 그 글에서 도입 경로를 판단한 기준에 하나를 더 보태고 싶다. 어디서 출발할 것인가.

연동은 정말 관계와 권한을 옮기지 못하나?

옮길 수 있는 부분이 있다. 이전 글에서는 연동으로 참조 관계나 권한을 가져오는 데 생기는 한계를 강하게 설명했다. 근데 연동이 원칙적으로 그런 관계를 다룰 수 없다는 식으로 읽힌다면 너무 넓은 주장이다. 외부 식별자를 보존하고, 명시적인 연결 관계를 관리하고, 권한을 확인하며, 실행 API를 사용하는 방식으로 풀 수 있는 부분이 있다. 진짜 문제는 어떤 조건에서 얼마나 정확하게 유지할 수 있느냐다.

이 차이는 고객의 도입 결정을 생각할 때 중요하다. 공급자가 보기에는 하나의 플랫폼 안에서 모델을 통일하는 것이 자연스럽다. 고객에게는 이미 운영하는 도구가 있고, 그 도구를 중심으로 쌓인 프로세스와 책임이 있다. 통일된 구조가 주는 이익과 그 구조로 옮기는 비용은 함께 계산해야 한다.

고객은 왜 도구 교체를 출발점으로 삼지 않나?

풀고 싶은 문제가 도구 교체보다 작은 경우가 많기 때문이다. Jira와 GitLab, Jenkins를 이미 운영하는 조직을 생각해 보자. 고객이 어려워하는 일이 배포 직전 변경 범위와 검증 결과를 맞추는 것이라면, 그 문제를 해결하기 위해 이슈 관리와 저장소를 모두 교체해야 하는지 먼저 물어야 한다. 기존 환경에 필요한 관계를 연결해 개선할 수 있다면 그 경로도 검토할 가치가 있고, 우리는 그 경로를 지원한다.

반대로 새로운 개발 환경을 구축하거나 기존 도구의 운영 부담 때문에 교체를 원하는 조직이라면, 플랫폼의 기본 기능을 함께 도입하는 방식이 적합하다. 내부망에 설치해야 한다는 조건과 저장소까지 이전해야 한다는 조건도 별개다. 설치 위치만으로 도구 교체 범위가 정해지지는 않는다.

도입 범위는 무엇을 기준으로 정해야 하나?

고객이 얻고 싶은 결과와, 그 결과에 필요한 최소한의 변화다. 배포에 대한 근거를 모으는 것이 목표라면 어떤 시스템에서 무엇을 읽어와야 하는가. 실제 실행도 연결하려면 어느 권한이 필요한가. 현재 환경에서 얻을 수 없는 근거는 무엇인가. 이 세 질문이 "어떤 도구를 바꿀 것인가"보다 도입 범위를 정하는 데 훨씬 도움이 된다.

연동을 택하면 어떤 엔지니어링을 해야 하나?

성공한 시연 이후의 일들이다. 이벤트가 늦게 도착하거나 누락될 수 있고, 토큰의 권한이 바뀔 수 있고, 원본 데이터가 삭제될 수 있다. 중복 처리와 재수집, 상태 확인, 권한 변경 반영까지 다뤄야 운영 가능한 연동이다. 우리가 커넥터를 만들면서 배운 것도 대부분 여기에 있다.

정확한 대상을 연결하는 일도 필요하다. 같은 브랜치 이름이나 이슈 번호가 보인다고 같은 변경의 근거라고 단정할 수 없다. 어느 저장소의 어떤 리비전인지, 어떤 빌드가 만든 결과물인지, 그 결과물에 대해 무엇을 검증했는지가 연결돼야 한다. 원본 시스템이 제공하는 식별자와 근거를 보존하는 것이 이때 설계 기준이다.

데이터가 없다는 사실은 어떻게 보여줘야 하나?

없다고 보여줘야 한다. 외부 시스템에 접근할 수 없어 검사 결과를 읽지 못했다면, 그건 검사를 통과했다는 뜻이 아니다. 최신 상태를 확인하지 못했다면 마지막으로 확인한 시점과 함께 보여준다. 추적성은 연결선을 많이 그리는 것으로 완성되지 않는다. 확인한 것과 확인하지 못한 것을 구분해 보여줄 때 완성된다.

CollabOps의 중심에 Change를 놓는 방향도 이 질문에서 나온다. 변경의 근거가 우리 기본 기능에서 생겼는지 기존 고객 도구에서 생겼는지와 무관하게, 그 근거가 어떤 판단을 뒷받침하는지 한 화면에서 이해할 수 있어야 한다. 근거의 출처가 어디든 Change가 그것을 묶는 단위다.

이 생각이 모든 고객에게 연동만 권하겠다는 뜻은 아니다. 마이그레이션이 더 나은 조건이 있고, 기존 도구를 유지하는 편이 나은 조건이 있다. 바꾸고 싶은 건 하나다. 공급자에게 익숙한 구조를 고객의 출발점으로 삼는 습관.

그래서 도입을 이야기할 때는 먼저 묻는다. 지금 가장 어려운 판단은 무엇인가. 그 판단을 바꾸기 위해 반드시 바꿔야 할 것은 무엇인가. 고객이 이미 가진 환경에서 시작해 그 질문에 답할 수 있어야 통합이라는 말도 실제 가치가 된다.