여러 시스템에 흩어진 같은 문제를 빠짐없이 닫는 법

문제 제기: '고쳤다'는 완료가 아니다

여러 시스템이 같은 뼈대를 공유하면, 하나에서 발견한 문제는 대개 다른 곳에도 있다. 실제 개발 기록에서는 KR·US·코인 세 시장의 자동매매 시스템에서 같은 종류의 운영 위험이 여러 레포에 공통으로 흩어져 있었다. 원장 불일치, 시세 조회 실패 처리, 계정 동기화, 승인 인가 같은 문제들이 시장별로 다른 레포에 나뉘어 있었다.
이때 흔한 착각은 "코드를 고쳤으니 끝났다"는 것이다. 하지만 멀티레포 환경에서 안전 수정은 발견 → 수정 → 배포 → 관찰이라는 사슬 전체가 이어져야 실제로 닫힌다. 커밋 하나가 머지됐다는 사실은 그 사슬의 두 번째 고리일 뿐이다. 세 번째, 네 번째 고리가 빠지면 문제는 조용히 남아 있다.

---

왜 위험한가: 빠지는 시장이 생길 수 있다

레포가 하나면 고친 것과 배포한 것이 거의 붙어 있다. 그러나 시장별로 레포가 나뉘면 상황이 달라진다. KR 레포는 수정하고 배포까지 했는데, 같은 문제의 US 버전은 커밋만 하고 배포는 미뤘거나, 코인 레포에는 아예 수정이 들어가지 않는 식의 누락이 생길 수 있다.
더 위험한 것은 이 누락이 겉으로 드러나지 않을 수 있다는 점이다. 각 레포의 이슈는 "수정 완료"로 닫혀 있고, 담당자는 자기 레포만 보면 문제가 없어 보인다. 그러나 전체를 조망하는 주체가 없으면, 배포되지 않은 안전 수정은 운영 중인 시스템에서 여전히 낡은 코드로 돌아간다. 안전 문제일수록 이 간극은 그대로 사고 위험이 된다.
개발 기록의 결론은 명확했다. 각 코드가 고쳐졌다는 사실만으로는 끝나지 않는다. 어딘가 하나는 발견→수정→배포→관찰의 연결 상태를 소유해야, 빠진 시장 없이 문제를 닫을 수 있다.

---

확인 절차: 허브가 연결 상태를 소유한다

실제로 적용한 방식은 "허브"를 하나 두는 것이었다. 허브는 흩어진 문제의 연결 상태를 추적·관리하는 곳이다. 실제 기록에서는 허브에서 P1/MED 후속 작업을 묶어 관리하고, 각 구현 레포의 수정 커밋과 운영 맥 배포 여부를 인수인계 보드 및 월간 문제 문서에 연결했다. 절차는 다음과 같다.

1. 공통 문제를 우선순위로 묶는다. 허브에서 P1/MED 같은 등급으로 후속 작업을 분류했다. 등급 판정 기준은 조직마다 다를 수 있으므로(예: 운영 사고로 이어지는지 여부 등) 팀 상황에 맞게 정한다.
2. 영향받는 시장을 모두 나열한다. 문제 하나에 대해 KR·US·코인 중 어디가 해당되는지 표로 적는다. 여기서 빠진 시장이 곧 누락 후보다.
3. 각 레포의 수정 커밋을 링크한다. 문제 항목마다 실제 수정 커밋을 연결한다. 커밋이 없으면 그 시장은 아직 '수정' 단계에도 못 들어간 것이다.
4. 운영 배포 여부를 별도로 표시한다. 커밋과 배포는 다른 칸이다. 개발 기록에서는 운영 맥에 배포됐는지를 인수인계 보드와 월간 문제 문서에 따로 연결했다.
5. 관찰 결과를 남긴다. 배포 후 실제로 그 위험이 재현되지 않는지 확인한 기록을 남겨야 사슬이 완성된다.

---

체크리스트: 사슬의 어느 고리가 빠졌는가

아래 표는 하나의 공통 문제에 대해 시장별로 어느 단계까지 왔는지 점검하는 가상의 예시다. 실제 기록의 결과가 아니라, 표를 채우면 어디가 비었는지 어떻게 드러나는지 보여주기 위한 것이다. 한 줄이라도 빈 칸이 있으면 그 문제는 아직 닫힌 것이 아니다.

KR	O	커밋 링크	배포 확인	재현 없음
US	O	커밋 링크	미배포?	-
코인	O	커밋 없음?	-	-

이 가상 예시에서는 US가 고쳤지만 배포 칸이 비어 있고, 코인은 수정 커밋 칸이 비어 있다. 이렇게 칸을 나눠 두면 어느 시장이 어느 단계에서 멈췄는지 한눈에 드러난다. 실무 체크리스트로 옮기면 다음과 같다.

• 이 문제가 어떤 시장에 공통으로 존재하는지 모두 나열했는가?
• 각 시장마다 수정 커밋이 실제로 존재하는가?
• 커밋과 배포를 다른 칸으로 구분했는가?
• 운영에 배포된 뒤 위험이 재현되지 않는지 관찰했는가?
• 누락된 시장을 발견했을 때 되돌리거나 후속 처리할 담당과 마감이 정해졌는가?

---

적용 예시: 자동매매가 아니어도 통한다

이 구조는 자동매매에만 쓰이는 것이 아니다. 같은 컴포넌트를 여러 서비스가 복사해 쓰는 상황이면 어디든 적용된다.

1. 사내 마이크로서비스: 인증 라이브러리의 취약점을 발견했다면, 그 라이브러리를 쓰는 모든 서비스 목록을 만들고 각각 패치 버전 반영 → 배포 → 로그 확인까지 표로 추적한다.
2. 여러 리전 배포: 한 리전에서 고친 설정 오류가 다른 리전에도 있는지 확인하고, 리전별 배포 완료 시각을 기록한다.
3. 모노레포 속 여러 패키지: 레포가 하나여도 패키지별 배포 파이프라인이 다르면 같은 누락이 생길 수 있다. 패키지 단위로 배포 여부를 나눠 본다.

핵심은 "누가 전체를 소유하는가"다. 전체 연결 상태를 관리하는 주체가 없으면 사각지대가 생길 수 있다. 허브 문서 하나가 전 범위의 연결 상태를 들고 있어야 한다.

---

한계와 주의사항

이 방법에도 한계가 있다. 첫째, 허브 문서가 수작업으로 갱신되면 그 자체가 또 다른 누락 지점이 된다. 가능하면 배포 여부는 CI/CD 상태나 태그에서 자동으로 끌어오는 편이 안전하다. 둘째, 표에 시장을 나열하는 단계에서 애초에 빠뜨리면 이후 절차가 모두 무의미하다. 영향 범위 나열은 여러 사람이 교차 검토하는 것이 좋다.
셋째, "관찰" 단계는 짧게 끝내면 안 된다. 배포 직후엔 재현되지 않다가 특정 조건에서 뒤늦게 나타나는 문제도 있다. 관찰 기간과 무엇을 봤는지를 함께 기록해야 한다. 여기 적은 절차는 실제 멀티레포 자동매매 시스템의 안전 수정 추적 경험을 일반화한 것으로, 조직 규모나 도구에 따라 등급 기준과 문서 위치는 조정이 필요하다. 어떤 절차도 "100% 누락 없음"을 보장하지는 못한다는 점을 전제로 두고, 사슬의 빈 칸을 줄이는 도구로 쓰는 것이 현실적이다.