두 번째 사례가 나왔는데, 공통부로 올리지 않았습니다

안녕하세요. 오픈소프트랩 개발팀입니다.

뼈대는 같고 도메인만 달랐다는 글을 이렇게 맺었습니다.

한 제품에서만 쓰는 걸 공통부에 올렸다가 조건 분기가 늘어나는 상황을 앞에서 겪었기 때문입니다. 같은 실수를 반복하지 않으려면 두 번째 사례가 나올 때까지 기다리는 편이 낫다고 봤습니다.

그 두 번째가 왔습니다. 그리고 저희는 공통부로 올리지 않았습니다.

알림이 제품마다 따로 있었습니다

문제가 된 건 알림이었습니다.

보안 운영 쪽에는 알림이 오래전부터 있었습니다. 소명을 요청하면 대상자에게 메일이 나가고, 결재가 올라오면 결재자에게 화면 알림이 뜹니다. 만든 지 몇 년 됐고 잘 돌아갑니다.

AI 통제 쪽에도 자체 알림이 있습니다. 차단이 확정된 건이 생기면 알림과 메일이 나갑니다.

그리고 MCP 게이트웨이에는 알림이 없었습니다. 도구 승인 절차를 만들면서 필요해졌습니다. 신청이 올라왔는데 결재자가 모르면 절차가 멈춥니다.

여기가 두 번째 사례였습니다. 같은 성격의 기능이 세 번째 제품에서 필요해진 것입니다.

올리려고 열어봤습니다

기준대로 하면 공통부에 올릴 차례입니다. 그래서 보안 운영 쪽 알림이 새 제품에 그대로 맞는지 봤습니다.

겉으로는 같은 일을 합니다. 어떤 일이 생기면 누군가에게 알린다. 그런데 받는 사람이 달랐습니다.

특히 조직 밖으로 나가는 경우가 컸습니다. 보안 운영 쪽은 계정이 없는 사람에게도 보내야 하고, 그래서 메일과 토큰 링크가 얽혀 있습니다. MCP 게이트웨이 쪽에는 그런 게 없습니다.

공통부에 올리려면 이 차이를 전부 다룰 수 있어야 합니다. 그러면 결국 조건 분기가 들어갑니다. 앞 글에서 실패했던 그 방식으로 돌아가는 것입니다.

옮기는 것이 비용이 더 저렴했습니다

계산해 보니 이랬습니다.

공통부로 올리기
  제품별 코드를 하나로 합친다
  차이를 설정이나 분기로 흡수한다
  기존 제품을 다시 그 위에 올린다
  새 제품을 붙인다
  → 이미 돌아가는 제품을 건드려야 한다

복사해서 옮기기
  한쪽 코드를 가져와 새 제품에 맞춘다
  → 돌아가는 제품은 그대로 둔다

결정적인 건 이미 고객사에서 돌아가고 있다는 점이었습니다. 공통부로 올리면 이미 돌아가는 제품까지 회귀 위험을 집니다. 얻는 건 코드 한 벌이 줄어드는 것인데, 잃을 수 있는 건 운영 중인 제품입니다.

그래서 보안 운영 쪽 알림을 가져와서 새 제품에 맞췄습니다. 메일 발송과 화면 알림, 결재 알림 연결까지 옮겼습니다.

대신 이어 붙이는 자리는 공통으로 뒀습니다

전부를 복사한 건 아닙니다. 하나를 공통으로 남겼습니다.

업무 로직이 알림을 직접 부르지 않게 했습니다. "승인 요청이 생겼다"까지만 알리고, 그걸 받아서 누구에게 어떻게 보낼지는 알림 쪽이 정합니다. 업무 로직은 알림이 메일로 가는지 화면 알림으로 가는지 모릅니다.

이렇게 하니 옮길 때 업무 로직은 손대지 않아도 됐습니다. 알림 구현만 바꿔 끼우면 됩니다. 나중에 정말 합치기로 해도 마찬가지입니다. 이어 붙이는 자리가 같으면 그 아래를 바꾸는 일이 됩니다.

정리하면 이렇습니다.

구현은 복사하고, 이어 붙이는 자리만 공통으로 둔다.

얻은 것과 포기한 것

얻은 것 — 이미 돌아가는 제품을 건드리지 않았습니다. 그리고 새 제품에 붙이는 일이 빨랐습니다. 이미 검증된 코드를 가져왔으니 처음부터 만드는 것보다 훨씬 적게 걸렸습니다.

포기한 것 — 알림 코드가 세 벌이 됐습니다. 메일 발송처럼 정말 같은 부분까지 세 곳에 있습니다. 한 곳에서 문제가 발견되면 나머지 두 곳도 봐야 합니다. 쿼리를 두 벌로 나눴을 때와 같은 종류의 부담입니다.

그리고 저희가 세운 기준을 저희가 어겼습니다. 두 번째 사례가 나오면 올린다고 써놓고 안 올렸습니다.

기준이 틀렸던 건 아니었습니다

돌아보니 기준 자체가 틀린 건 아니었습니다. 빠진 조건이 있었습니다.

"두 번째 사례가 나오면 올린다"는 두 번째가 나오기 전에 올리지 마라는 뜻이었습니다. 너무 일찍 공통화하지 말자는 규칙이었지, 두 번째가 나오면 무조건 올리라는 규칙이 아니었습니다. 그런데 문장이 짧다 보니 뒤쪽으로 읽히게 써뒀습니다.

지금은 이렇게 고쳐 씁니다.

두 번째 사례가 나오기 전에는 공통부로 올리지 않는다.
두 번째가 나오면 올릴지 복사할지를 그때 판단한다.
이미 운영 중인 제품을 건드려야 한다면 복사가 기본이다.

세 번째가 오면

지금 붙어 있는 문제입니다.

네 번째 제품에 알림이 필요해지면 그때는 네 벌이 됩니다. 어느 시점부터는 합치는 편이 비용이 더 저렴해질 텐데, 그 시점을 숫자로 잡기가 어렵습니다.

판단 기준으로는 같은 부분이 얼마나 자주 같이 고쳐지는지를 생각하고 있습니다. 세 곳을 한 달에 몇 번씩 같이 고치고 있다면 합칠 때가 된 것이고, 각자 다른 방향으로 갈라지고 있다면 애초에 같은 기능이 아니었던 것입니다. 이 지표를 볼 생각입니다.

메일 발송처럼 차이가 없는 부분만 먼저 떼어내는 방법도 함께 검토할 생각입니다. 전부 합치는 것보다 위험이 작고, 세 벌에서 가장 많이 겹치는 부분이기도 합니다.

오픈소프트랩 개발팀이 작성합니다. 보안 운영 포탈과 생성형 AI 사용 통제를 만들고 있습니다.