커넥터를 다 만들어 놓고 왜 마이그레이션을 권하는가

도입 미팅마다 빠지지 않는 질문이 있다. "저희는 깃랩이랑 SVN 이랑 젠킨스를 쓰고 있는데, 콜랩옵스에서 통합이 되나요?"

답은 두 갈래다. 연동(integration)도 되고, 마이그레이션도 된다. Jira 같은 도구들과 이어 주는 커넥터를 우리가 직접 만들어서 제공한다. 그런데 그 커넥터를 만든 당사자로서, 우리는 대부분의 경우 마이그레이션을 권한다. 자기가 만든 기능을 쓰지 말라고 권하는 셈이라 이상하게 들릴 수 있는데, 이 글에서 그 이유를 설명해 보려고 한다.

연동이 옮기는 것과 옮기지 못하는 것

연동이 옮기는 것은 데이터다. 이슈 제목, 커밋 메시지, 빌드 상태. 웹훅과 API 로 이쪽 화면에 저쪽 데이터를 보여 주는 것까지는 어렵지 않다.

연동이 옮기지 못하는 것은 세 가지다.

첫째, 참조 관계. 저쪽 시스템의 이슈 #1234 와 이쪽 커밋이 관련 있다는 사실은 어느 쪽 데이터에도 원래 없다. 연동 코드가 커밋 메시지의 문자열을 파싱해서 추측할 뿐이다. 문자열 규칙이 어긋나는 순간 관계는 끊어지고, 아무도 끊어진 걸 모른다.

둘째, 권한. 두 시스템의 권한 모델은 서로 호환되지 않는다. 저쪽에서 비공개인 이슈가 연동을 타고 이쪽에 노출되는 사고는, 연동을 오래 운영해 본 조직이라면 한 번쯤 겪었을 것이다. 그래서 연동 계정에는 보수적으로 넓은 권한을 주게 되고, 그 계정의 API 토큰이 곧 보안 감사의 단골 지적 사항이 된다.

셋째, 실행. 이쪽에서 보는 것과 이쪽에서 실행하는 것은 다르다. 연동 환경에서 의사결정은 결국 원래 도구로 돌아가서 실행된다. 대시보드에서 확인하고, 젠킨스에 가서 재빌드하고, 깃랩에 가서 머지하고, Jira 에 돌아와서 상태를 바꾼다. 화면은 하나가 됐는데 일은 여전히 네 군데서 한다.

정리하면 이렇다. 연동은 데이터를 옮기고, 마이그레이션은 맥락을 옮긴다. 우리 제품의 가치가 통합된 맥락, 그러니까 이슈에서 커밋, 빌드, 배포까지 이어지는 하나의 그래프에서 나오는 이상, 연동만으로는 그 가치의 절반도 전달되지 않는다.

AI 를 붙이는 순간 차이가 벌어진다

이 차이는 예전에는 "불편함" 수준이었다. AI 에이전트를 붙이는 순간 "결정적" 이 된다.

에이전트가 일을 잘하려면 맥락을 따라가야 한다. 이 이슈에 얽힌 커밋, 그 커밋이 깨뜨린 빌드, 비슷한 과거 장애. 통합된 그래프 위에서 이건 관계를 따라가는 조회다. 연동된 환경에서 이건 API 토큰 네 개와 서로 다른 응답 스키마 네 개를 상대하는 왕복 여행이고, 그렇게 모아 온 조각들 사이의 관계는 다시 추측이다. 우리가 깃허브나 깃랩 연동을 실제로 다 지원하면서도 고객에게 솔직하게 말하는 지점이 여기다. 되긴 되는데, 토큰 기반 연동 위에서 에이전트를 돌리는 건 생각보다 많이 힘들다.

그래서, 어떻게 넘어오는가

"마이그레이션" 이라는 단어가 빅뱅 전환을 떠올리게 하는데, 우리가 권하는 건 그게 아니다. 실제로 잘되는 경로는 대체로 이렇다.

한 팀, 한 저장소부터 옮긴다. 보통 신규 프로젝트나 가장 적극적인 팀이 먼저 들어온다. 이 기간에는 기존 도구와 커넥터로 이어 둔다. 사실 커넥터의 진짜 용도가 이거다. 영구적인 다리가 아니라 이사 기간의 임시 다리. 기존 도구의 이력은 이슈·커밋 이력까지 포함해서 가져온다. 25년 치 히스토리를 버리고 오라는 얘기가 아니다. 그리고 옮긴 팀에서 효과가 검증되면 다음 팀이 넘어온다. 우리 경험상 이 순서를 건너뛰고 전사를 한 번에 옮기려는 시도보다, 이렇게 번지는 쪽이 결과가 좋았다.

SVN 처럼 오래된 형상관리를 쓰는 조직도 마찬가지다. SVN 을 아직 쓰는 이유가 게을러서가 아니라는 걸 우리는 안다. 안정적이니까 쓰는 것이다. 그래서 전환은 안정성이 검증되는 속도만큼만 진행하면 된다.

연동이 정답인 경우도 있다

이 글의 균형을 위해 반대 방향도 분명히 해 두고 싶다. 모든 것을 옮기는 게 답은 아니다.

ITSM 이 대표적이다. 우리는 ITSM 을 만들지 않는다. 우리 스코프 밖이라고 판단했고, 앞으로도 연동으로 지원할 계획이다. 조직 전체가 이미 깊게 의존하는 전사 시스템, 규제상 특정 도구가 지정된 영역, 수명이 얼마 안 남은 레거시. 이런 것들은 옮기는 비용이 옮겨서 얻는 맥락보다 크다. 그런 영역은 연동으로 두는 게 맞다.

기준은 단순하다. 개발의 일상 루프 안에 있는 것은 안으로, 루프 밖에 있는 것은 연동으로. 이슈, 코드, 파이프라인, 배포는 하루에도 수십 번 서로를 참조하니까 한 평면에 있어야 한다. 반면 분기에 한 번 데이터를 주고받는 시스템까지 끌어안을 이유는 없다.

커넥터를 다 만들어 놓고 마이그레이션을 권하는 이유를 한 문장으로 줄이면 이렇다. 연동은 도구를 잇지만, 우리가 팔고 싶은 것은 도구가 아니라 이어진 맥락이기 때문이다.