보안 포탈 설계 (3) 복사해서 따로 만들고 다시 합쳤습니다

기존 제품을 갈아엎는 과정에서 팀이 둘로 갈린 이야기입니다. 시리즈의 다른 글 보기

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

1편과 2편에서 무엇을 만들었는지 썼습니다. 이번 편은 어떻게 만들었는지입니다. 기술보다는 진행 방식에 대한 이야기입니다.

고쳐 쓸 수 있을 줄 알았습니다

처음 계획은 점진 개선이었습니다.

기존 제품이 이미 고객사에서 돌아가고 있었고, 화면과 업무 흐름도 자리를 잡은 상태였습니다. 여기에 필요한 것을 하나씩 얹으면 될 거라고 봤습니다. 교과서에 나오는 방식이기도 합니다. 큰 재작성은 위험하니 조금씩 바꾸라는 것.

몇 주 해보고 이 계획이 틀렸다는 걸 알았습니다.

한 줄 고치는 데 이틀이 걸렸습니다

문제는 기능이 아니라 바닥에 있었습니다.

기반 프레임워크가 오래된 버전에 묶여 있었습니다. 그래서 새 라이브러리를 쓰려면 기반을 올려야 하고, 기반을 올리면 그 위에 있는 것들이 전부 흔들립니다. 하나를 고치려고 열을 건드려야 하는 상태였습니다.

이런 일이 반복됐습니다.

기능 A 추가
  → 라이브러리 B 필요
  → B는 프레임워크 상위 버전 요구
  → 올리면 C, D, E가 깨짐
  → 일단 B 없이 A를 직접 구현
  → 비슷한 코드가 또 하나 생김

우회할수록 코드가 늘고, 늘어난 코드가 다음 작업을 더 느리게 만들었습니다. 개선하는 속도보다 부채가 쌓이는 속도가 빨랐습니다.

복사해서 따로 만들기로 했습니다

그래서 방향을 바꿨습니다. 저장소를 하나 더 만들고 코드를 복사한 뒤, 거기서는 기반부터 새로 깔기로 했습니다.

이 결정에는 조건이 하나 붙었습니다. 기존 제품 개발을 멈출 수 없다는 것입니다.

고객사에 납품된 제품이 있었고 요청이 계속 들어오고 있었습니다. 새로 만드는 동안 기존 쪽이 멈추면 그 몇 달치 요청이 전부 밀립니다. 그래서 이렇게 나눴습니다.

새 갈래를 혼자 맡은 건 인력이 없어서이기도 했지만, 초기에는 여러 명이 붙는 게 오히려 느리기 때문이기도 했습니다. 구조가 계속 바뀌는 동안에는 합의할 게 너무 많습니다.

합칠 때가 진짜였습니다

두 달쯤 뒤 새 갈래가 돌아가는 모양이 됐습니다. 그때 기존 팀원들이 넘어왔고, 그동안 기존 갈래에 쌓인 작업을 새 갈래로 옮겨야 했습니다.

여기서 알게 된 게 있습니다. 떨어져 있던 기간만큼 옮기는 비용이 붙습니다.

기존 갈래에 들어간 기능들은 옛 구조를 전제로 쓰여 있었습니다. 새 갈래는 폴더 구조도 데이터 접근 방식도 바뀐 상태입니다. 그래서 파일을 그대로 가져올 수가 없었습니다. 무엇을 하려던 코드인지 읽고, 새 구조에 맞게 다시 쓰는 일에 가까웠습니다. 파악하는 시간이 다시 쓰는 시간보다 길었습니다.

옮기는 비용은 기능의 크기보다 그 기능이 옛 구조에 얼마나 기대고 있었는지에 비례했습니다. 화면 한 장짜리라도 데이터 접근 방식이 바뀐 자리를 지나가면 오래 걸렸고, 덩치가 커도 독립적으로 쓰인 코드는 금방 넘어왔습니다.

얻은 것과 포기한 것

얻은 것 — 바닥을 갈아엎을 수 있었습니다. 점진 개선으로는 몇 년이 걸렸거나 못 했을 일입니다. 그리고 기존 고객 대응이 한 번도 멈추지 않았습니다. 이게 실무에서는 가장 컸습니다.

포기한 것 — 옮기면서 다시 쓴 분량이 적지 않았습니다. 그리고 그 기간 동안 두 갈래의 동작이 달랐습니다. 어느 쪽이 맞는지 물어볼 때마다 "어느 저장소요?"를 먼저 물어야 했습니다.

이걸 감수한 이유는 단순합니다. 점진 개선을 몇 주 해보고 끝이 안 보인다는 걸 확인했기 때문입니다. 해보지 않고 골랐다면 잘못된 결정이었을 것 같습니다.

갈라놓는 기간은 짧을수록 좋았습니다

지금 정리된 건 이 정도입니다.

복사해서 따로 만드는 방식 자체가 나쁘지는 않았습니다. 다만 비용이 떨어져 있는 기간에 비례해서 붙습니다. 두 달이 넘어가면서부터 옮길 게 눈에 띄게 늘었습니다.

그래서 다음에 비슷한 상황이 오면 더 빨리 합치는 쪽으로 하려 합니다. 완성한 다음에 한 번에 합치는 대신, 새 갈래가 돌아가는 최소한의 모양이 되면 그때 팀을 옮기고 나머지는 같이 만드는 식입니다. 기반만 바뀌면 그 위는 여럿이 붙어도 충돌이 적으니까요.

기존 갈래를 어느 시점에 닫을지는 아직 기준이 없습니다. 고객사 버전이 남아 있는 한 완전히 닫을 수가 없고, 그렇다고 두 벌을 계속 들고 가면 같은 문제가 반복됩니다. 지금은 고객사 이관 일정에 맞춰 건건이 판단하고 있는데, 이 부분은 다음 전환 때 다시 볼 생각입니다.

이 글에서는 진행 방식만 다뤘습니다. 기반을 실제로 무엇으로 바꿨는지는 다음 시리즈로 이어집니다.

다음 편에서는 그 기반을 무엇으로 바꿨는지 다룹니다. — 레거시를 옮기며

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