🏗️ 아키텍처 결정을 잘하는 시니어의 6가지 실전 프레임워크

How I Make Better Architectural Decisions as a Senior Developer

소프트웨어 시스템의 성패는 아키텍처 결정에 달려 있다고 해도 과언이 아닙니다.

개발을 하다 보면 기술적인 역량만으로는 부족하다는 걸 느끼게 됩니다.

올바른 결정을 내리려면 트레이드오프를 저울질하고, 장기적인 영향을 고려하며, 다양한 이해관계자들과 소통하는 능력이 필요하죠.

이 글에서는 제가 어떻게 소프트웨어 아키텍처를 설계하고, 어려운 결정을 내리는지 공유하려고 합니다.

스포일러 > 완벽한 정답은 거의 없습니다. 현재 상황에서 최선의 선택을 하는 것이 중요합니다.

---

🧱 아키텍처는 ‘명확한 문제 정의’에서 시작한다

화이트보드를 꺼내기 전에, 저는 항상 문제를 정말 명확하게 이해하려고 노력합니다.

문제를 잘 정의하는 것만으로도 좋은 설계를 절반은 한 셈이죠.

다음은 제가 주로 사용하는 방식입니다:

1. “왜?”를 반복해서 묻는다

“마이크로서비스로 가야 해요.”라는 말이 들리면, 그냥 동의하지 않습니다.

그 결정의 배경을 이해할 때까지 계속 “왜?”라고 묻습니다.

스케일 문제인지, 팀 구성 때문인지, 아니면 빠른 배포 때문인지 분명히 해야 하죠.

2. 제약 조건을 정의한다

성능, 확장성, 팀 역량, 예산 등 다양한 현실적 제약이 아키텍처에 영향을 줍니다.

3. 이해관계자들과 대화한다

제품팀, 비즈니스팀, 운영팀 등 다양한 팀과 이야기하다 보면

숨겨진 요구사항(예: 규제 준수, 비용 이슈, 고충사항 등)을 알게 됩니다.

4. 핵심 유스케이스를 명확히 한다

엣지 케이스에 집착하기보단, 핵심 기능이 얼마나 잘 작동하는지에 집중합니다.

5. 한 페이지 요약을 작성한다

뻔한 말 같지만 정말 효과적입니다.

문제와 제약 조건을 A4 한 장 분량으로 명확히 설명하지 못하면, 아직 이해가 부족한 것입니다.

종이에 흐릿하게 보이면, 실제 서비스에선 더 엉망이 될 가능성이 높습니다.

---

이제 실제 상황에서 어떤 선택을 어떻게 했는지 6가지 사례를 통해 살펴보겠습니다.

1. 단순함 vs 유연성: REST vs 이벤트 기반

시나리오: 온라인 쇼핑몰에서 결제 후 두 가지 작업이 필요합니다: 주문 처리와 재고 차감.

플래시 세일 같은 트래픽 폭주 상황도 고려해야 합니다.

선택지

• A) REST API를 통한 동기 방식: 간단하지만 서비스 간 강결합
• B) Kafka 등 이벤트 기반 비동기 방식: 느슨한 결합, 확장성 높음, 하지만 복잡도 증가

나의 선택과 이유

작은 시스템이라면 REST가 직관적이고 좋습니다.

하지만 이처럼 동시에 처리해야 할 작업이 많고, 트래픽 부하가 큰 상황이라면 이벤트 기반이 적합합니다.

이벤트 기반의 장점:

• 느슨한 결합: Payment 서비스는 소비자가 누군지 몰라도 됨
• 독립 확장성: 주문 서비스만 터지면 그것만 스케일 아웃
• 장애 격리: 한 서비스가 죽어도 다른 서비스는 동작
• 확장 용이: 이벤트에 새 서비스만 구독시키면 됨 (예: 이메일 발송, 분석 등)

물론 Kafka 모니터링, 메시지 중복, 재시도 같은 부가 작업은 필요하지만,

확장성과 복원력을 위해선 그만한 가치가 있습니다.

---

2. 직접 구축할까? 사올까? (Build vs Buy)

시나리오: 기업용 모바일 앱을 위한 로그인 기능. MFA, 생체 인증, SSO 등 고급 기능 요구 + GDPR 등 컴플라이언스 준수 필요.

선택지

• A) 직접 인증 시스템 구축
• B) Auth0, AWS Cognito 같은 외부 인증 서비스 사용

나의 선택과 이유

보안은 제대로 만들기 어렵습니다.

그리고 규제까지 얽히면 인증은 절대 가볍게 보면 안 됩니다.

전 이럴 땐 외부 솔루션을 도입합니다.

• 검증된 보안
• 자동 컴플라이언스 대응
• 지속적인 업데이트
• 핵심 제품에 집중 가능

직접 만들면 커스터마이징은 가능하겠지만, 팀의 리소스를 너무 많이 소모합니다.

이건 ‘휠을 다시 만들 필요는 없다’는 고전적인 사례입니다.

---

3. 모놀리스 vs 마이크로서비스

시나리오: SaaS 스타트업, 제품-시장 적합성(PMF)을 찾는 단계, 빠른 개발이 중요하지만 확장성도 고려해야 함.

선택지

• A) 모듈형 모놀리스로 시작, 이후 마이크로서비스로 전환 가능하게 설계
• B) 처음부터 마이크로서비스로 분리하여 독립 배포, 확장 가능

나의 선택과 이유

초기에는 속도가 생명입니다.

모놀리스는 빠르게 개발하고 디버깅하기 좋습니다.

PMF도 안 나왔는데 마이크로서비스부터 도입하면:

• 분산 트랜잭션
• 서비스 간 통신
• 배포 복잡도 증가

이런 문제가 생기죠. 페이스북, 인스타그램, 아마존도 처음엔 모놀리스였습니다.

🔍 PMF란?

• Product-Market Fit(제품-시장 적합성) 의 약자입니다.
• “내가 만든 제품이, 특정 시장의 실제 고객들에게 명확한 가치를 제공하고 있으며, 그 고객들이 기꺼이 돈을 내고 사용하려는 상태”

---

4. SQL vs NoSQL

시나리오: 사용자 정의 필드를 지원하는 CRM 시스템.

일부 고객은 고정된 데이터 구조를, 일부는 유연한 구조를 원함.

선택지

• A) PostgreSQL/MySQL + JSON 컬럼
• B) MongoDB/DynamoDB 같은 NoSQL

나의 선택과 이유

기본적으로 저는 SQL을 선호합니다.

하지만 다양한 구조의 필드가 자주 바뀌고, 확장성이 중요하다면 NoSQL이 낫습니다.

복잡한 쿼리나 리포팅이 필요한 경우, SQL + NoSQL 혼용도 고려할 수 있습니다.

---

5. 캐싱할까 말까 (To Cache or Not to Cache)

시나리오: 추천 시스템의 부하가 높아 성능 문제 발생.

지연 시간이 사용자에게 바로 체감됨. 빠르게 해결이 필요함.

선택지

• A) Redis를 활용한 캐싱
• B) 추천 결과를 미리 계산해서 저장 (precompute)

나의 선택과 이유

Redis 캐싱이 단기적으로는 가장 빠른 해결책입니다.

• 2초 걸리던 쿼리를 100ms 미만으로
• 구조 변경 없이 적용 가능
• 추후 precompute 방식으로 확장 가능

Redis의 단점은 데이터 동기화나 캐시 무효화 등의 처리 필요성입니다.

하지만 지금처럼 급한 상황에서는 빠른 캐시 적용이 효과적입니다.

기준은 간단합니다.

빠른 개선이 필요할 땐 캐시, 예측 가능한 부하라면 precompute.

---

6. 레거시 시스템 다루기 (Taming the Legacy Beast)

시나리오: 20년 된 핵심 모놀리스 시스템.

변경이 어렵고 버그가 자주 발생함. 개발자들은 손대기를 꺼려함.

선택지

• A) 새로 처음부터 다시 구축
• B) 점진적으로 리팩토링 및 현대화

나의 선택과 이유

다시 만드는 건 매력적이지만 실제로는 실패 확률이 높습니다.

• 새 버그 발생
• 과한 일정 지연
• 기존 기능 누락 위험

그래서 저는 점진적 리팩토링을 선택합니다.

• 불안정하거나 자주 고장 나는 모듈을 우선 개선
• 래퍼/인터페이스로 경계를 만들고 안전하게 교체
• 테스트와 CI/CD 강화로 안정성 확보
• 변경 가능한 부분부터 구조 개선

이 방식이 덜 화려해 보여도 현실적으로 가장 안전하고 신뢰할 수 있습니다.

---

✅ 아키텍처 결정에서 배운 교훈

아키텍처 결정은 장기적인 영향을 끼칩니다.

좋은 선택을 하려면 경험이 필요하지만, 학습 속도를 높일 방법도 있습니다:

• 과거를 돌아보기: 이전 프로젝트의 ADR이나 회고 분석
• 유행 따라가지 않기: 트렌드보다 우리 상황에 적합한 기술 선택
• 변화에 유연한 설계: 모듈화, 느슨한 결합을 우선시
• 작게 시도하고 검증: 작게 실험해보고 실제 성능 확인
• 되돌릴 수 있는 선택하기: 회복 가능한 구조 고려
• 실패에서 배우기: 틀릴 수도 있다는 전제하에 유연하게 대응
• 단기와 장기 균형 맞추기: 급한 땐 빠르게, 장기적으론 구조적으로
• 기술 선호 내려놓기: 감정이 아닌 ‘문제에 맞는 기술’을 선택

📘 ADR란?

Architecture Decision Record는 “특정 시점에 왜 그 기술적 결정을 내렸는지 기록으로 남기는 문서”입니다. 소프트웨어 설계 과정에서 “왜 이걸 선택했는가?“에 대한 맥락과 트레이드오프를 명확히 하기 위해 사용됩니다.

---

좋은 아키텍처는 처음부터 완벽할 필요가 없습니다.

지속적으로 배우고, 개선하고, 유연하게 변화에 대응하는 것이 핵심입니다.

📋 블로그 내용 요약 표 (시니어 개발자의 아키텍처 결정 6가지 사례)

번호	주제	상황 요약	선택지 A	선택지 B	최종 결정 & 이유 요약
1	단순함 vs 유연성	결제 후 주문 처리 + 재고 차감 필요, 트래픽 급증 대비	REST API: 단순하고 직관적이지만 강결합	이벤트 기반(Kafka): 느슨한 결합, 확장성 ↑, 복잡도 ↑	이벤트 기반 선택: 확장성과 장애 격리에 유리
2	Build vs Buy	보안이 중요한 모바일 앱(MFA, SSO, GDPR 등)	직접 인증 시스템 구축: 완전한 제어 가능	Auth0/Cognito 등 외부 솔루션: 빠른 출시, 규제 대응, 보안 검증 완료	Buy(외부 솔루션): 리스크 낮추고 본질에 집중
3	모놀리스 vs 마이크로서비스	스타트업 초기 단계, 빠른 개발이 중요, PMF 전	마이크로서비스: 독립 배포, 확장성 있으나 초기 복잡도 ↑	모듈형 모놀리스: 빠른 개발, 전환 용이	모놀리스 선택: 초기엔 속도가 중요
4	SQL vs NoSQL	유연한 커스텀 필드를 가진 CRM, 일부 고객은 정형, 일부는 비정형 데이터 선호	SQL(JSON 컬럼): 정형 쿼리, 안정성 ↑	NoSQL: 유연한 스키마, 스케일 쉬움	혼용 or NoSQL: 유연성과 확장성 고려
5	Cache or Precompute	추천 시스템이 부하를 일으킴, 빠른 개선 필요	Redis Cache: 즉각 성능 향상, 적용 쉬움	Precompute: 더 빠르지만 초기 구축 복잡도 ↑	Cache 우선: 빠른 효과, 이후 Precompute로 개선
6	레거시 개선 vs 전면 재구축	20년 된 핵심 시스템, 변경 어려움, 버그 잦음	재구축: 깔끔하지만 위험 부담 크고 완료까지 오래 걸림	점진적 리팩토링: 안정성 유지, 개선 지속 가능	점진적 리팩토링: 현실적인 선택, 리스크 ↓

📌 기타 정리: 아키텍처 결정 시 고려할 원칙

항목	설명
과거 사례 분석	ADR, 포스트모템 문서 등을 통해 학습
트렌드 맹신 금지	유행보단 상황에 맞는 기술 선택
변화에 강한 구조	느슨한 결합, 모듈화 중심 설계
프로토타이핑	실험과 측정으로 검증 후 적용
되돌릴 수 있는 결정	되돌릴 수 없는 결정은 신중하게
실수 수용	빠르게 개선 가능한 문화 유지
단기 vs 장기 균형	장기적 품질을 고려하되, 때론 빠른 해결도 필요
감정 배제	기술적 흥미보다 문제 해결 중심으로 판단

✅ 추가로 논의할 만한 주제 3가지

1. 프로토타이핑 vs 사전 설계: 어디까지 고민하고 시작할 것인가?

   👉 초기에 완벽한 설계를 할 수는 없습니다.

   빠르게 작동하는 프로토타입으로 검증하고, 피드백을 반영해 진화시키는 전략이 효과적입니다.

   문제 정의가 명확할수록 설계가 쉬워지고, 프로토타이핑은 설계를 구체화시키는 도구입니다.

---

1. 기술 스택 선택 시 팀의 역량을 어떻게 고려해야 하는가?

   👉 “이 기술이 좋은가?”보다 중요한 건 “우리 팀이 이 기술을 잘 다룰 수 있는가?”입니다.

   새로운 기술 도입 시 러닝 커브, 인력 수급, 유지보수까지 고려한 현실적 기술 선택이 필요합니다.

---

1. 성능 최적화를 언제부터 고려해야 할까?

   👉 너무 이른 최적화는 낭비지만, 무시하면 나중에 큰 기술 부채로 돌아옵니다.

   핵심 경로(핫패스)에 대해서는 기획/설계 단계부터 성능을 고려하고,

   나머지는 실제 부하가 관측된 후 튜닝하는 방식이 실용적입니다.