무사시 vs 코지로: Software Architecture가 기본으로부터 배울 수 있는 것

Source: Dev.to

일본 역사에서, 한 결투는 화려함 때문에가 아니라 절제 때문에 기억됩니다.

Sasaki Kojiro는 명예를 위해 차려입고 도착했습니다: 긴 검, 완벽한 자세, 의식, 명성, 형식.
Miyamoto Musashi는 늦게 도착했으며, 갑옷도 없고 장식도 없으며, 노를 깎아 만든 나무 검을 휘두렀습니다.

결투는 빠르게 끝났습니다—Kojiro가 약해서가 아니라, Musashi가 더 깊은 것을 이해했기 때문입니다: 상황이 불확실할 때 근본이 화려함을 이긴다는 것을.

현대 소프트웨어 아키텍처는 매일 이 결투를 반복합니다.

The Modern Kojiro: “We’ll Need Microservices to Scale”

모든 스타트업은 결국 이 문장을 듣게 됩니다:

“We’ll need microservices to scale.”

때때로는 맞을 수도 있지만, 대부분은 규모가 커지기 전, 제품‑시장 적합성을 찾기 전, 팀조차 무엇을 확장하려는지 모르는 시점에 너무 일찍 말해지는 경우가 많습니다.

전형적인 초기 단계 스타트업 프로필

• 1–3명의 엔지니어
• 불안정한 요구사항
• 실질적인 트래픽 압박이 없음
• 제한된 예산
• 빠른 반복 사이클

그럼에도 불구하고 그들은 다음을 사용하려 합니다:

• Kubernetes
• Service meshes
• Distributed deployments
• Multi‑database strategies
• Cloud abstractions layered on abstractions

이는 마치 코지로가 의식용 갑옷을 입고 필요 없는 전투에 나서는 것과 같습니다. 마이크로서비스는 조직 규모의 문제를 해결하지만, 초기 단계의 혼란을 해결해 주지는 못합니다.

이 단계에서 하나의 어려운 문제(코드 구조)를 다섯 개의 더 어려운 문제와 교환하게 됩니다:

• 네트워크 경계
• 배포 복잡성
• 가시성 오버헤드
• 보안 표면
• 분산 실패 모드

칼날은 인상적이지만, 전장은 잘못되었습니다.

무사시의 선택: 모듈형 모놀리식

무사시는 검을 거부한 것이 아니라 불필요한 의식을 거부했습니다. 건축적 대응은 모듈형 모놀리식입니다.

모듈형 모놀리식은:

• 하나의 배포 가능한 애플리케이션
• 강력한 내부 경계와 규율을 갖춤

핵심 특성

• 단일 코드베이스
• 단일 배포
• 명확한 모듈 소유권
• 모듈 간 누수 없음
• 도메인 간 명시적 계약

예시 구조

/users
  /domain
  /service
  /controller

/billing
  /domain
  /service
  /controller

/analytics
  /domain
  /service
  /controller

각 모듈:

• 자신의 데이터를 소유함
• 인터페이스를 공개함
• 구현 세부 사항을 숨김

이는 “그냥 폴더”가 아니라 의도된 분리입니다—무사시의 목검처럼 단순하고, 집중적이며, 치명적입니다.

왜 이것이 초기 대결에서 승리하는가

운영 비용이 저렴함

• 한 번 배포하고, 한 번 모니터링하고, 한 번 디버그합니다.
• 인프라 비용이 변동 없이 일정하게 유지됩니다—그 자체가 하나의 기능이죠.
• 관리할 클러스터가 없고, 배포 전 이해해야 할 서비스 메시도 없습니다.

빠른 적응력

• 초기 단계 요구사항이 매일 바뀝니다.
• 모듈형 모놀리식은 자신 있게 리팩터링하고, 내부를 변경해도 파급 효과가 없으며, 두려움 없이 빠르게 움직일 수 있게 합니다.

보안이 쉬워짐

• 하나의 애플리케이션은 노출 표면이 적고, 인증 흐름이 단순하며, 데이터 경계가 명확합니다.
• 분산된 보안은 더 어렵습니다.

팀 명확성

• 두 명의 개발자라도: 한 명은 인증을, 다른 한 명은 분석을 담당합니다.
• 책임이 명확하고, 소유권이 드러나며, “누가 프로덕션을 망쳤나요?” 같은 미스터리가 없습니다.

그것을 만들거나 깨뜨리는 규율

무사시는 여전히 끊임없이 훈련했다. 모듈식 모놀리쓰는 규율 없이는 실패한다.

중요한 규칙들

• 모듈 간 직접 DB 접근 금지.
• 다른 모듈의 내부 서비스를 임포트 금지.
• 정의된 인터페이스를 통한 통신만 허용.
• 공유 코드는 명시적인 공유 레이어에 위치.

이 규칙을 어기면 얽힌 모놀리쓰가 되고, 모듈식이 아니다—​그것은 코스프레이며, 무사시가 아니다.

스케일링 순간 (코지로가 지는 순간)

When scale actually arrives:

• 트래픽이 증가한다.
• 특정 도메인이 뜨거워진다.
• 팀 규모가 커진다.

At that point:

• 각 모듈이 이미 서비스처럼 동작한다.
• 경계가 이미 적용된다.
• 추출이 감정이 아닌 기계적으로 이루어진다.

You can:

• 단일 모듈을 컨테이너화한다.
• 독립적으로 배포한다.
• 나머지는 그대로 두고 Cloud Run, ECS, Railway 등으로 옮긴다.

재작성도, 패닉도, “재구축에 3개월”도 없다. 시스템은 진화할 뿐, 초기화되지 않는다. 이것은 전투 중에 적응하는 무사시이며, 형태에 갇힌 코지로가 아니다.

초기 창업자에게 이것을 추천하는 이유

• 학습
• 비용
• 속도
• 명확성
• 미래 선택 가능성

당신은 마이크로서비스를 거부하는 것이 아니라, 그것을 얻고 있습니다. 마이크로서비스는 코지로의 검과 같은 도구일 뿐이며, 진지함의 배지가 아닙니다.

문제를 이해하기 전에 구축하는 아키텍처가 가장 비용이 많이 듭니다.