프로젝트 두 개 합치기를 접었다 — 재사용 가능한 건 100줄

프로젝트가 늘 때마다 계정을 새로 만들고 있었다. 쓰는 관리형 데이터베이스 무료 등급이 계정당 프로젝트 두 개까지라서다. 그래서 진행 중인 두 프로젝트를 하나로 합치려고 했다. 둘 다 같은 회사 일이고, 같은 분야고, 대상도 비슷했다. 새로 시작하는 쪽은 아직 화면 세 개뿐이었고, 먼저 있던 쪽은 파일 66개짜리 서비스였다. 먼저 있던 쪽에 얹으면 코드를 많이 아낄 것 같았다.

겹친다고 꼽은 네 개 중 셋이 틀렸다

합칠 근거로 기능 네 가지를 꼽았다. 자료실, 대회 데이터, 출석체크, 학생 관리. 이 중 셋이 양쪽에서 다 쓰인다고 봤다. 세어 봤더니 이랬다.

• 자료실 — 있다. 그런데 테이블이 컬럼 세 개다. 게다가 행사에 안 묶여 있어서 두 쪽 자료가 한 곳에 섞인다
• 대회 데이터 — 한쪽 전용이 맞다
• 출석체크 — 없다. 검색에 걸린 한 건은 「명단 제출」이었고 출석이 아니었다
• 학생 관리 — 있는데 성격이 정반대였다. 그쪽은 실명을 익명 번호로 바꾸는 장치고, 새로 만드는 쪽은 출결부라 실명이 있어야 성립한다

재사용할 수 있는 걸 실제로 세니 자료실 테이블 세 컬럼과 비밀번호 게이트 30줄, 합쳐서 100줄 남짓이었다.

스택이 가깝다는 건 합칠 이유가 아니다

그런데도 처음엔 "그래도 스택이 가까우니 합치는 게 낫지 않나"로 기울었다. 두 프로젝트 프레임워크 버전이 한 세대 차이였고, 이전에 포기했던 다른 합치기 후보는 두 세대 차이였다. 그것보다는 가까워 보였다.

그 비교가 틀렸다. 가깝다는 건 합치기 쉽다는 뜻이지 합칠 이유가 아니다. 쉬움과 이유를 섞어서 보고 있었다.

unique index 한 줄에서 방향이 뒤집혔다

진짜로 갈린 곳은 따로 있었다. 먼저 있던 서비스 데이터베이스에 이런 줄이 박혀 있었다.

-- 활성 행사 단일 보장: is_active=true 인 행은 1개만 존재 가능
create unique index events_single_active_idx on events (is_active) where is_active;

행사를 하나만 돌리는 전제로 만든 것이다. 새로 붙일 쪽은 여러 곳에서 동시에 돌아간다. 합치는 순간 이 제약이 깨지고, "지금 무슨 행사냐"를 판정하는 코드를 전부 고쳐야 한다.

아끼는 게 100줄인데 고쳐야 하는 게 그보다 크다. 여기서 방향이 뒤집혔다.

앱은 따로, 데이터베이스는 하나

합치는 목적을 다시 물었다. 원래 이유는 비용이었다. 계정을 새로 만들지 않으려는 것.

그 문제와 코드를 합치는 것은 아무 상관이 없었다. 계정을 아끼려면 데이터베이스만 같이 쓰면 되고, 앱은 따로 둬도 된다. 그래서 이렇게 갈랐다.

• 앱·저장소는 따로 — 재사용할 게 100줄이라 합칠 값이 없다
• 데이터베이스는 하나에 전용 스키마로 — 계정을 안 늘려도 된다
• 접근은 그 서비스 라이브러리 대신 데이터베이스에 직접 연결 — 나중에 다른 곳으로 옮길 때 연결 문자열 한 줄만 바꾸면 된다

"합치면 아낀다"는 느낌은 아끼는 양을 세기 전에 먼저 왔다. 그 느낌이 온 뒤에 근거를 찾으니 겹쳐 보이는 항목 네 개가 금방 나왔고, 그중 셋이 틀렸다.

세는 데 걸린 시간은 20분이었다. 이름을 대조하고, 없는 기능을 검색으로 확인하고, 재사용할 줄 수를 실제로 셌다. 물어본 건 한 줄이었다 — 합치면 아끼는 게 몇 줄인가.