[Review] 소프트웨어 아키텍처 3주차 후기

1. 마이크로커널 아키텍처 (Microkernel Architecture)

• - Open Code (오픈 코드): Node.js 기반의 터미널 에이전트 앱으로, 코어 커널 컴포넌트 위에 인증용 플러그인이나 커스텀 툴, MCP 서버 등을 붙여 확장하는 형태를 가집니다. 
• 
  
• - Grafana (그라파나): Go 언어로 작성된 메인 코어 서버에 몽고DB, MySQL 등 다양한 데이터 소스를 플러그인 형태로 붙여 관찰성(Observability)을 확보하는 대표적인 사례입니다. 

• 
  
• - 초기에는 호스트 프로그램에 설치하는 플러그인 방식이었을지 몰라도, 지금은 웹훅(Webhook)이나 별도 서버(Lambda 등)를 통해 이벤트를 주고받는 형태로 발전했기 때문입니다. 
• 
  
• - 결국 "플러그인끼리 서로 참조하는 순간, 그것은 더 이상 플러그인이 아니라 플랫폼이 된다"는 통찰이 인상적이었습니다. 

2. 서비스 기반 아키텍처와 도메인 이야기

• - Layered Monolith: 가장 익숙하고 시작하기 좋은 구조이지만, 팀과 기능이 커지면 계층 간 점프나 스파게티 코드가 발생하기 쉽습니다. 
• 
  
• - Modular Monolith: 패키지 단위로 도메인을 나누어 결합도를 낮추는 시도입니다. 
• 
  
• - Service-Based Architecture: 모놀리스와 마이크로서비스의 중간 단계로, 도메인별로 서비스를 나누지만 DB를 공유하거나 트랜잭션을 묶는 등 현실적인 타협점을 찾기도 합니다. 
  
  

• - 문제: 신약 개발이나 바이오 연구에서 세포를 배양하는 과정은 24시간 관리가 필요하고, 사람의 실수가 치명적일 수 있습니다. 
• 
  
• - 해결: 로봇을 이용해 이 과정을 자동화합니다. 로봇 팔이 피펫팅을 하고, 인큐베이터에 넣고, 원심분리기를 돌리는 과정을 소프트웨어로 제어합니다. 

• - 아키텍처적 난제: 고객사마다 원하는 실험 레시피가 다르고, 장비 구성이 제각각입니다.
• 
  
  • - 이 지점에서 마이크로커널 아키텍처가 이상적인 해법으로 떠오릅니다. 
  • 
    
  • - 코어(Core): 로봇 제어, 스케줄링 등 공통 로직. 
  • 
    - 플러그인(Plugin): 각 고객사의 커스텀 실험 레시피 및 장비 모듈. 

3. 자유 토론 및 잡담

• - 서킷 브레이커(Circuit Breaker): AWS나 Cloudflare 장애 이야기를 하며, 외부 장애가 우리 서비스로 전파되는 것을 막는 서킷 브레이커 패턴의 중요성을 다시금 실감했습니다. "지라가 안 돼서 공부를 접고 PC방에 갔는데 롤도 안 되더라"는 웃픈 에피소드도 있었죠. 
• 
  
• - 클린 코드 vs 클린 아키텍처: 로버트 C. 마틴(Uncle Bob)과 마틴 파울러(Martin Fowler)의 책들을 혼동했던 에피소드로 웃음꽃을 피웠습니다. 
• 
  
• - 팀 토폴로지(Team Topologies): 아키텍처는 결국 조직 구조와 뗄 수 없습니다. 콘웨이의 법칙처럼, 팀이 일하는 방식이 소프트웨어 구조에 그대로 반영된다는 점에 다들 깊이 공감했습니다. 
  
  
  

마무리

이번 스터디는 단순히 책의 내용을 요약하는 것을 넘어, "우리 회사의 구조는 어떤가?", "이 이론을 내 도메인에 어떻게 적용할 것인가?"를 고민해볼 수 있는 시간이었습니다.

특히 "아키텍처는 미술 사조와 같아서 유행이 있다"는 말처럼, 정답을 찾기보다 현재 우리 상황에 맞는 최선의 트레이드오프를 찾아가는 과정이 중요함을 깨달았습니다.

다음 주에도 이어질 아키텍처 탐험을 기대하며, 이번 주 회고를 마칩니다!