멀티사이트 결제 PG 라우팅 구조를 완성한 달

1월에 167개 커밋이 쌓였다. 달력 기준으로 지금까지 제일 많은 달. 숫자만 보면 그냥 바빴구나 싶겠지만, 상황이 좀 특이했다. 퇴사 결심이 이미 서 있었다. 회사는 인수인계 모드, 사이드 프로젝트는 전속력. 이게 실제로 충돌하지 않았다는 게 흥미로웠다. 각각 쓰는 뇌의 부위가 달랐다고나 할까. 낮에는 기존 코드를 설명하는 사람, 밤에는 새 코드를 짜는 사람. 같은 사람이 두 가지를 동시에 하는 건 에너지가 두 배로 드는 게 아니라, 종류가 다른 에너지를 교대로 쓰는 것에 가깝다. 체력적으로는 빡셌지만, 동기가 명확하면 버텨진다는 걸 이달이 보여줬다.

PG 라우팅 구조를 DB로 빼는 이유

이달 가장 큰 덩어리는 PG 설정 관리 페이지와 시스템 ID 기반 라우팅 구조였다. slecs는 멀티 사이트를 다루는 시스템이다. 사이트마다 계약한 PG가 다를 수 있고, 같은 PG라도 MID(Merchant ID)나 키가 다르다. 이걸 코드 안에 하드코딩해두면 사이트 하나 추가될 때마다 배포가 필요하고, 잘못 건드리면 다른 사이트 결제에 영향이 간다.

구조를 잡을 때 선택지는 크게 두 가지였다.

• 코드 레벨 분기: if site_id == 'A' then use PG_X 형태로 코드 안에 때려박는 방식
• DB 기반 라우팅: 사이트-PG 매핑을 테이블로 관리, 런타임에 조회

전자는 빠르게 시작할 수 있지만, 사이트가 늘어날수록 분기가 폭발한다. 결제 도메인에서 하드코딩된 PG 설정이 살아있으면 운영할 때 사단이 난다. 그래서 어드민에서 시스템 ID를 기준으로 PG를 골라 설정하고, 결제 흐름에서는 그 설정을 읽어 동적으로 라우팅하는 방향으로 갔다.

대략 이런 흐름이다:

def resolve_pg_config(site_id: str) -> PGConfig:
    config = PGSettingRepository.get_by_site(site_id)
    if config is None:
        raise PGConfigNotFoundError(site_id)
    return PGConfig(
        provider=config.provider,
        merchant_id=config.merchant_id,
        secret_key=decrypt(config.secret_key),
    )

어드민 설정 페이지는 이 테이블을 CRUD하는 UI다. 시스템 ID를 선택하고, 어떤 PG를 쓸지, 키 값은 무엇인지를 저장한다. 배포 없이 PG를 바꿀 수 있게 된다. 멀티 사이트 시스템에서 이 구조가 없으면 운영이 점점 고통스러워진다.

트레이드오프도 있다. DB 조회가 결제 흐름에 하나 더 끼어든다. 캐싱을 안 하면 성능에 영향을 줄 수 있고, 캐시를 하면 설정 변경이 즉시 반영 안 될 수 있다. 지금 단계에서는 짧은 TTL 캐시로 타협했다. 사이트 수가 많지 않은 시점에서 DB 부하보다 운영 편의를 먼저 챙긴 결정이다.

DDL 동기화와 코드-스키마 드리프트

이달에 데이터베이스 DDL도 전면 정비했다. 개발하다 보면 코드는 앞서가고 DDL 파일이 뒤처지는 일이 생긴다. 마이그레이션 툴을 쓰면 자동으로 맞춰지지만, 그게 없으면 실제 DB 상태와 레포 안의 DDL 파일이 조용히 달라진다. 새 환경을 셋업하거나 팀원이 합류할 때 터진다. 이걸 이달에 맞춰줬다.

DDL 정비가 지루해 보이지만 사실 이게 기술 부채의 전형적인 생김새다. 당장 기능에 영향을 안 주니까 미뤄지고, 쌓이면 나중에 한꺼번에 정리하는 데 배로 든다. 이달에 한 번 맞춰놓으면 다음부터는 DDL을 코드와 같이 커밋하는 습관만 유지하면 된다.

아이콘 클래스 이름 일괄 변경도 이달에 했다. 이런 류의 작업은 타이밍이 중요하다. 사이트가 커지고 나서 하면 놓치는 곳이 생기고, 시각적 버그로 이어진다. 커밋 수는 작아도 나중에 찾기 귀찮아지는 부채를 미리 청산한 작업이다.

id 로직 개선과 하드코딩 제거도 같은 맥락이다. 코드 어딘가에 특정 사이트나 설정 값이 리터럴로 박혀 있으면 멀티 사이트 구조와 충돌한다. PG 라우팅을 DB로 빼는 작업과 같은 방향성이다. 하드코딩은 결국 다 걷어내야 하고, 일찍 할수록 나중에 덜 고생한다.

167커밋이 다음 달 278의 전조였다고 지금은 알지만, 그때는 그냥 하루하루 할 일을 했을 뿐이다. 퇴사 전 마지막 두 달을 어떻게 보내느냐가 개인 프로젝트의 궤도를 결정했다. 인수인계를 제대로 하면서 개인 작업도 가속하는 게 양립 불가능하지 않다는 걸, 이달 커밋 로그가 증명해줬다.