팀과 기술의 리빌드 — 다시 일하는 법을 정비하다

1. 리빌드의 시작 — 사람부터 바꿨다

2025년 4월 초, REINDEERS는 중대한 결정을 내렸다. 시스템을 새로 만드는 일보다 먼저, 사람을 바꾸기로 한 것이다. 플랫폼은 기술로 움직이지만, 운영의 일관성을 무너뜨리는 것은 언제나 사람이다.

결국 기존 직원들은 모두 퇴사했다. 이전 팀은 실험적이었지만, 운영 가능한 구조를 만들기엔 역부족이었다. 남은 것은 코드 일부와 배포 스크립트뿐이었다. 우리는 그 위에 새로운 문화를 세우기보다, 완전히 새 팀을 만드는 길을 선택했다. 이것이 네 번째 팀 교체였다. 2015년 IMARKET Thailand 창업 이후 10년 동안 팀이 네 번 바뀌었다는 사실은 글로벌 스타트업이 겪는 현실을 그대로 보여준다.

2. 새 팀의 탄생 — 기술 커트라인부터 통과해야 했다

신규 채용의 기준은 단순했다. "운영 가능한 기술을 이해하는가." 단순히 코드를 작성할 줄 아는 개발자가 아니라, 시스템이 어떻게 동작하고 복제되며, 장애를 어떻게 복구해야 하는지를 아는 엔지니어만이 합류할 수 있었다.

기술 커트라인 (필수 항목)

Nuxt 3 / Vue3 + SSR 구조 이해
API 서버 설계 경험
CI/CD 파이프라인 구축 및 유지 경험
COS/CDN 배포 자동화 경험
Redis TTL 관리, MQ(AMQP) 이벤트 설계 경험
Git 브랜치 전략 및 Pull Request 프로세스 숙지
테스트 주도 개발(TDD) 환경 설정 경험

신규 구성원들은 모두 위 기준을 통과해야 했으며, 각자 DevOps, Front, API, Data, AI 셀로 배치되었다. 시스템 설계보다 먼저, 운영 가능한 인력을 확보하는 것이 첫 번째 과제였다. 현재 팀은 NHN 에이컴메이트 출신을 중심으로 구성되었다. 대규모 이커머스 플랫폼 운영 경험이 있는 엔지니어들이었기 때문에, "코드를 짤 수 있는가"보다 "운영 장애를 수습한 경험이 있는가"를 더 중요하게 봤다.

3. 코드 리뷰 프로세스 — AI + 사람의 이중 검증

새 팀이 가장 먼저 정립한 것은 코드 리뷰 체계였다. 모든 코드 변경은 반드시 PR(Pull Request)을 거쳐야 하며, 리뷰는 두 단계로 진행된다.

1차는 AI 리뷰다. PR이 생성되면 CI 파이프라인에서 자동으로 정적 분석이 실행된다. 구조적 오류, 보안 취약점, 성능 병목 가능성을 탐지하고 PR에 코멘트로 남긴다. 2차는 셀(Cell) 동료에 의한 사람 리뷰다. AI가 놓치기 쉬운 비즈니스 로직의 정합성, 도메인 규칙 준수 여부를 확인한다. 예를 들어 "태국의 VAT 계산이 맞는가", "말레이시아의 수출 규정에 부합하는가" 같은 검증은 도메인 지식이 필요하기 때문에 사람이 담당한다.

두 단계 모두 통과해야 Merge가 가능하다. AI 리뷰에서 CRITICAL 등급 이슈가 발견되면 사람 리뷰 자체가 차단된다. 이 구조는 리뷰 품질을 보장하면서도 리뷰 속도를 유지하는 데 효과적이었다.

4. 셀(Cell) 구조 — 기술 중심의 운영 단위

새 팀은 기능 중심이 아니라, 기술 중심으로 구성되었다. 각 셀은 자체 파이프라인을 가지고 있고, 코드 품질과 배포 성공률에 대한 책임을 스스로 진다.

엔지니어링 셀 구조

[CELL-A] Front-End (Nuxt + Vue3)
 - i18n, SEO, CDN 최적화
[CELL-B] Back-End (API Services)
 - API Gateway, MQ, Redis
[CELL-C] DevOps (CI/CD, DNS, Security)
 - 배포 자동화, 보안, 인프라
[CELL-D] Data/AI
 - AI 코드 리뷰, 로그 분석, 자동화 모듈

셀 간 통신은 MQ를 통해 이루어진다. 공통 이벤트는 reindeers.global 익스체인지에서 주제별로 분리된다. 셀 구조를 선택한 이유는 4개국에 걸친 협업 때문이다. 태국, 한국, 중국, 말레이시아에 분산된 팀원들이 하나의 기능을 함께 개발하는 것은 시간대 차이만으로도 병목이 된다. 대신 기술 계층별로 셀을 나누면, 각 셀이 자신의 영역에서 독립적으로 작업하고 MQ 이벤트 인터페이스만 합의하면 통합이 가능하다.

5. CI/CD 파이프라인 — 환경 격리와 자동화

새 팀은 Drone을 단순한 빌드 도구가 아닌 운영 자동화 엔진으로 사용한다. 각 환경(dev/stg/prod)은 격리되어 있으며, 환경 변수는 KMS로 암호화된다.

Drone 파이프라인 예시

kind: pipeline
type: docker
name: reindeers-deploy

trigger:
  branch: [ main, develop ]

steps:
  - name: build
    image: node:20
    commands:
      - npm ci
      - npm run lint
      - npm run test
      - npm run build

  - name: upload
    environment:
      COS_BUCKET: reindeers-fe
      COS_REGION: ap-hongkong
    commands:
      - upload built assets to COS

  - name: purge-cdn
    commands:
      - invalidate CDN cache

  - name: notify
    commands:
      - send deploy result notification

배포 성공률은 99.3% 이상을 유지하며, 모든 로그는 COS에 보존되어 트레이서빌리티가 확보된다. 롤백 기능도 파이프라인에 내장되어 있어, 배포 후 헬스체크가 실패하면 이전 버전으로 자동 복구된다.

6. Git 정책 — 일관성과 승인 절차의 표준화

모든 코드 변경은 Git Flow를 기반으로 하며, PR(Pull Request) 단위로 검토된다. 커밋 메시지는 Conventional Commits 형식을 따라야 하며, 서명된 커밋만 Merge 가능하다.

main        → 프로덕션 (자동 배포)
develop     → 통합 테스트 환경
feature/*   → 기능 단위 브랜치
release/*   → 사전 배포
hotfix/*    → 긴급 수정

브랜치 전략에서 가장 중요한 규칙은 main 브랜치에 대한 직접 커밋 금지다. 모든 변경은 feature 또는 hotfix 브랜치에서 작업한 후 PR을 통해서만 main에 합류한다. 이 규칙은 예외 없이 적용된다. 긴급 장애 대응 상황에서도 hotfix 브랜치를 생성하고 최소한의 리뷰를 거친다. "급하니까 바로 푸시하자"는 과거에 너무 많은 문제를 만들어냈기 때문이다.

7. 크로스 타임존 협업 — 4개국 동시 개발의 현실

태국(GMT+7), 한국(GMT+9), 중국(GMT+8), 말레이시아(GMT+8). 시간대 차이는 최대 2시간이지만, 실질적인 협업 가능 시간은 더 좁다. 각국의 업무 시작/종료 시간, 점심 시간, 공휴일이 모두 다르기 때문이다.

이 문제를 해결하기 위해 "비동기 우선(async-first)" 원칙을 채택했다. 실시간 회의는 최소화하고, 모든 의사결정은 문서와 PR 코멘트를 통해 이루어진다. 각 셀이 독립적으로 작업할 수 있도록 인터페이스(MQ 이벤트 스키마, API 명세)를 먼저 합의하고, 구현은 각자의 시간대에서 진행한다. 코드 리뷰도 비동기적으로 진행된다. 한국 팀이 올린 PR을 태국 팀이 다음 날 아침에 리뷰하고, 그 피드백을 한국 팀이 다시 자신의 업무 시간에 반영하는 흐름이다.

실시간 소통이 필요한 경우는 주 1회 전체 동기화 미팅으로 한정한다. 이 미팅은 4개국 모두가 업무 시간인 오전 10시(한국 기준)에 진행되며, 30분 이내로 끝내는 것을 원칙으로 한다. 나머지는 모두 비동기 채널에서 처리된다.

8. 문서화 표준 — 코드가 곧 문서

별도의 문서 저장소를 운영하지 않는다. 코드 저장소 안에 모든 문서가 함께 버전 관리된다. API 명세는 코드에서 자동 생성되고, 데이터 모델 문서는 DBML로 관리되어 코드와 동기화된다.

이 접근 방식의 장점은 "문서가 코드와 괴리되는 문제"를 원천적으로 방지한다는 것이다. 별도의 위키나 노션에 문서를 관리하면, 코드가 변경될 때 문서 업데이트가 누락되기 쉽다. 코드 저장소 안에 문서가 있으면 PR 리뷰 시 코드 변경과 문서 변경을 함께 확인할 수 있다. 문서 없는 코드 변경은 리뷰에서 거부된다.

9. 코드 품질과 테스트 자동화

모든 코드 빌드 전에 린트, 포맷팅, 테스트가 자동 실행된다. 한 단계라도 실패하면 빌드가 중단된다.

테스트 설정 예시

"scripts": {
  "lint": "eslint --ext .ts,.vue src",
  "format": "prettier --write src",
  "test": "vitest run",
  "build": "npm run lint && npm run test && nuxt build"
}

테스트 결과는 대시보드에서 시각화되며, DevOps 셀에서 실시간으로 모니터링된다. 테스트 커버리지가 기준 이하로 떨어지면 PR 승인이 차단된다. 이 자동화된 품질 게이트가 있기 때문에 4개국에 분산된 팀이 동일한 품질 기준을 유지할 수 있다.

10. 결론 — 팀이 바뀌자, 시스템이 바뀌었다

기존의 개발 방식은 실험적이었지만 지속 불가능했다. 인적 구조를 먼저 정리하고, 그 위에 새로운 시스템을 세웠기에 지금의 안정성이 가능했다.

REINDEERS는 이제 사람에 의존하지 않는 구조를 갖췄다. 팀이 시스템을 만들던 시대에서, 이제 시스템이 팀을 규정하는 시대로 전환되었다. CI/CD 파이프라인, AI 코드 리뷰, 자동화된 테스트, MQ 기반 셀 간 통신. 이 모든 것이 "특정 개발자가 없으면 안 되는" 구조를 제거하기 위한 장치다. 누군가가 빠져도 시스템은 동일하게 동작하고, 새로운 사람이 합류해도 동일한 프로세스 안에서 즉시 기여할 수 있다. 그것이 팀을 네 번 교체하면서 배운 가장 비싼 교훈이었다.

Blog

Search This Blog