개발사 교체, 한 브랜드의 인수인계 기록

시스템은 돌아가고 있었다. 하지만 왜 돌아가는지 아는 사람이 아무도 없었다.

매장 15개, SKU 약 1,800개를 운영하는 한 패션 브랜드의 운영팀장이 루브릭랩스에 처음 연락해온 건 5월 초였다. 용건은 간단했다. "기존 개발사가 사실상 연락이 끊겼고, 이번 시즌 재고 배분 로직에 오류가 생긴 것 같은데 고칠 수가 없다." 시스템은 멈추지 않았다. 하지만 믿을 수 없는 숫자를 뱉어내고 있었고, 그 숫자를 기반으로 발주와 배분이 이루어지고 있었다.

개발사 교체, 가장 먼저 마주치는 현실

개발사를 바꾸겠다는 결정은 보통 오래 묵혀두다 터진다. 불만은 쌓여 있었지만 교체 비용과 리스크가 두려워 미뤄온 것이다. 그러다 결정적인 사건 하나가 터진다. 이 브랜드의 경우, SS 시즌 배분 오류가 그 계기였다.

문제는 교체를 결심한 이후부터였다. 새 개발사를 찾는 것보다 기존 시스템을 이해하는 것이 먼저였다. 인수인계 문서는 없었다. 소스코드는 있었지만 주석도, 구조 설명도 없었다. 담당 개발자는 이미 퇴사했고, 회사 대표는 연락을 받지 않았다. 남은 건 서버 접속 정보 하나와 3년 치 운영 데이터뿐이었다.

이런 상황은 생각보다 흔하다. 중소 패션·유통 브랜드의 상당수가 외주 개발사와 구두 계약에 가까운 방식으로 시스템을 운영한다. 계약서에 소스코드 소유권이 명시되어 있지 않거나, 문서화 의무가 없거나, 유지보수 범위가 모호하게 적혀 있다. 개발사가 성실하게 운영할 때는 문제가 없다. 관계가 틀어지거나, 개발사가 망하거나, 담당자가 바뀌는 순간 브랜드는 블랙박스 위에 올라타 있다는 사실을 깨닫는다.

루브릭랩스가 실제로 진행한 인수인계 과정

1단계: 시스템 현황 파악 (2주)

코드를 보기 전에 비즈니스 로직부터 물었다. 재고 배분은 어떤 기준으로 이루어지는가. 발주 승인 흐름은 누가 어느 단계에서 결정하는가. 반품은 어떻게 처리되는가. 이 질문들에 운영팀이 답하면서, 시스템이 실제로 하는 일과 운영팀이 기대하는 일 사이의 간극이 드러나기 시작했다.

그 다음에 코드를 열었다. 약 4만 줄 분량의 레거시 코드였다. 주석은 거의 없었고, 변수명은 한글 초성 약어로 가득했다. 데이터베이스 테이블은 140개였는데, 실제로 사용 중인 건 87개였다. 나머지 53개는 언제 만들어졌는지도 불분명한 채 방치되어 있었다.

배분 오류의 원인은 2주 만에 찾았다. 전 시즌 재고 이월 처리 로직에서 특정 카테고리의 SKU가 두 번 집계되는 버그였다. 단순한 오류였지만, 코드 구조를 모르는 상태에서는 어디를 봐야 할지조차 알 수 없었다. 이 버그 하나가 봄 시즌 배분에서 약 2,300만 원 규모의 과잉 발주를 유발하고 있었다.

2단계: 우선순위 분류와 운영 안정화 (3주)

시스템 전체를 한 번에 재구축하는 것은 현실적이지 않다. 시즌이 돌아가고 있고, 매장은 열려 있고, 발주는 계속 나가야 한다. 루브릭랩스는 기능을 세 그룹으로 분류했다.

즉시 수정이 필요한 버그, 단기적으로 수동 운영으로 대체 가능한 기능, 중장기 재설계가 필요한 구조적 문제. 이 분류 작업 자체가 운영팀에게 처음으로 "우리 시스템의 지도"를 제공하는 과정이었다. 이전까지 운영팀은 시스템이 어디까지 자동으로 처리하고 어디서부터 사람이 개입해야 하는지를 정확히 몰랐다.

버그 수정 이후 3주 동안은 신규 기능 개발 없이 운영 안정화에만 집중했다. 모니터링 로그를 새로 심고, 이상값이 발생하면 운영팀 슬랙으로 알림이 오도록 했다. 작은 변화였지만, 운영팀장의 표현을 빌리자면 "처음으로 시스템을 믿고 퇴근할 수 있게 됐다"는 변화였다.

3단계: 문서화와 지식 이전 (병행)

인수인계에서 가장 많이 생략되는 단계가 문서화다. 새 개발사도 바쁘고, 브랜드 담당자도 바쁘다. 하지만 이 단계를 건너뛰면 3년 후 똑같은 상황이 반복된다. 다음 개발사도, 그다음 개발사도 같은 블랙박스 앞에 서게 된다.

루브릭랩스는 코드 문서화와 별개로 운영팀이 읽을 수 있는 시스템 운영 가이드를 작성했다. 개발 언어나 기술 스택이 아니라, "이 버튼을 누르면 무슨 일이 일어나는가", "이 숫자가 이상하면 어디를 확인해야 하는가" 같은 실무 중심의 문서다. 분량은 A4 기준 28페이지. 지금 이 브랜드의 운영팀은 이 문서를 신규 입사자 온보딩 자료로 활용하고 있다.

개발사 교체 전에 반드시 확인해야 할 것들

이 과정을 통해 루브릭랩스가 정리한 체크리스트는 세 가지다.

첫째, 소스코드 소유권. 계약서에 명시되어 있는가. 개발사가 폐업하거나 연락이 끊겼을 때 코드에 접근할 수 있는가. 많은 브랜드가 이 항목을 계약 당시 확인하지 않는다.

둘째, 서버와 도메인 관리 주체. 서버 접속 계정, 도메인 등록 정보, SSL 인증서 갱신 주기가 브랜드 측에 문서화되어 있는가. 이것이 없으면 개발사 교체 시 서비스가 일시 중단될 수 있다.

셋째, 데이터 백업과 이관 가능 여부. 3년 치 판매 데이터, 재고 이력, 고객 데이터를 새 시스템으로 이관할 수 있는 형태로 보관하고 있는가. 데이터가 개발사 서버에만 있고 내보내기 기능이 없다면, 교체 시 데이터를 잃을 수 있다.

이 세 가지를 지금 당장 확인할 수 없다면, 개발사 교체를 고려하기 전에 먼저 이 항목들을 현재 개발사에 요청해야 한다.

교체 이후: 브랜드가 얻은 것

이 브랜드는 인수인계 완료 후 약 두 달 만에 신규 기능 개발을 시작할 수 있었다. 재고 배분 로직 개선, 매장별 sell-through 자동 리포트, 시즌 말 재고 소진 시뮬레이션이 순서대로 추가됐다. 이전 개발사와 함께했던 마지막 1년 동안 단 하나의 신규 기능도 배포되지 않았던 것과 대비된다.

운영팀장은 이렇게 말했다. "개발사를 바꾸는 게 무서웠던 건, 지금보다 더 나빠질까 봐였어요. 그런데 막상 해보니까, 이미 충분히 나쁜 상태였더라고요."

개발사 교체의 진짜 비용은 새 개발사에 지불하는 금액이 아니다. 교체를 미루는 동안 쌓이는 기회비용, 오류가 있는 숫자를 믿고 내리는 발주 결정, 시스템을 이해하는 사람 없이 시즌을 넘기는 리스크가 진짜 비용이다.

인수인계는 단순히 코드를 넘겨받는 일이 아니다. 브랜드가 자기 시스템을 처음으로 이해하게 되는 과정이다. → 문의하기