Seongwon

[인물] 진화적 아키텍처의 두 사람 — Neal Ford & Rebecca Parsons, 그리고 ‘수치로 판단하기’의 시작

정성원

아키텍처 공부를 하다 보면 결국 같은 두 이름을 계속 마주치게 된다. Neal Ford와 Rebecca Parsons. 두 사람은 “아키텍처는 한 번 정하고 끝나는 게 아니라, 측정 가능한 지표로 끊임없이 검증하며 진화시키는 것”이라는 생각을 정리해 준 사람들이다. 이 글은 두 사람이 누구인지 간단히 소개하고, 그들의 핵심 메시지를 ‘지금 내 수준에서 실제로 써먹을 수 있는 숫자’로 바꿔 정리한 기록이다.

Neal Ford

  • 소속/직함: Thoughtworks의 Director, Software Architect, and Meme Wrangler. (“Meme Wrangler”라는 별난 직함이 공식 프로필에 실제로 적혀 있다.)
  • 무엇으로 유명한가: 진화적 아키텍처(Evolutionary Architecture)와 아키텍처 적합도 함수(fitness functions) 개념을 대중화한 사람. 소프트웨어 아키텍처 교육 분야의 대표적인 저자이자 강연자다.
  • 대표 저서: 『Building Evolutionary Architectures』(공저), 『Fundamentals of Software Architecture』(Mark Richards 공저, O’Reilly, 2020), 『Software Architecture: The Hard Parts』(2021), 『The Productive Programmer』(2008) 등.
  • 영향력: 전 세계 700여 개 개발 콘퍼런스에서 3,000회 넘게 발표한 국제적 스피커.

Rebecca Parsons

  • 소속/직함: Thoughtworks의 최고기술책임자(CTO)를 오래 역임했고, 현재는 CTO Emerita(명예 CTO). 1999년 Thoughtworks에 합류했다.
  • 배경: Rice University에서 컴퓨터과학 박사(1992). 컴파일러·프로그램 최적화·분산 컴퓨팅·프로그래밍 언어 이론·머신러닝·계산생물학까지 폭넓은 연구 경력을 가진 학자 출신 기술 리더.
  • 무엇으로 유명한가: Neal Ford·Patrick Kua와 함께 『Building Evolutionary Architectures』를 공저하며 ‘진화적 아키텍처’ 사상을 함께 정립. fitness functions와 자동화된 거버넌스(automated software governance)의 핵심 주창자.
  • 그 외: 여성 개발자·STEM 다양성 옹호 활동으로도 잘 알려져 있으며, 2018년 AnitaB.org의 Technical Leadership ABIE Award를 수상했다.

두 사람을 묶어주는 책: 『Building Evolutionary Architectures』

두 사람이 Patrick Kua와 함께 쓴 책이 바로 『Building Evolutionary Architectures』다(1판: O’Reilly, 2017 — 부제 Support Constant Change). 2022년 2판에서는 Pramod Sadalage가 합류해 4인 공저가 되었고, 부제가 Automated Software Governance로 바뀌었다.

이 책의 핵심 개념이 fitness function(적합도 함수)이다. 한마디로 “이 아키텍처가 우리가 원하는 특성(성능·확장성·신뢰성 등)에 얼마나 가까운지를 객관적인 수치로 측정하는 장치”다. ‘느낌상 빨라진 것 같다’가 아니라 ‘p95 응답이 300ms 이하인가’처럼, 판단의 기준을 숫자로 못 박는 것이 핵심이다.

나의 생각 — 왜 이 두 사람이 중요하다고 느꼈나

개발을 하다 보면 “이쯤이면 캐시 하나 넣어야 하지 않나”, “커넥션을 좀 늘려야 할 것 같은데” 같은 막연한 감으로 결정을 내리게 되는 순간이 많다. Neal Ford와 Rebecca Parsons가 내게 준 가장 큰 메시지는 이거다 — “감으로 하지 말고, 측정해서 숫자로 결정하라.”

두 사람이 말하는 fitness function은 거창한 도구가 아니라, ‘어떤 숫자가 어떤 선을 넘으면 이렇게 한다’는 나만의 판단 규칙을 미리 정해두는 습관에 가깝다고 이해했다. 그래서 나는 이 두 사람을 단순한 ‘유명 아키텍트’가 아니라, 주니어가 의사결정을 ‘감’에서 ‘지표’로 옮기게 만들어주는 사람들이라고 생각한다. 아래는 그 생각을 내 현재 수준에서 실제로 쓸 수 있게 정리한, 일종의 ‘작은 fitness function 모음’이다. (절대적인 법칙이 아니라 출발점이고, 진화적 아키텍처의 정신대로 측정하면서 계속 고쳐갈 기준이다.)

내 수준에서 받아들일 만한 ‘비율과 격차’ 기준

핵심은 두 가지를 같이 본다는 것이다. 비율(ratio) = 지금 상태가 한계 대비 어디쯤인가, 격차(gap) = 정상값과 현재값이 얼마나 벌어졌는가. 비율이 높고 격차가 벌어지기 시작하는 ‘교차점’이 행동해야 할 신호다.

1) Redis 같은 캐시를 도입해야 할 때

  • 읽기:쓰기 비율 ≥ 10:1 (읽기가 전체의 90% 이상) → 캐시 효과가 큰 강력한 후보. 반대로 쓰기가 잦은 데이터는 무효화 비용이 이득을 깎아먹으니 신중.
  • 같은 데이터의 반복 조회가 많아야 한다. 도입 후 목표 캐시 적중률(hit rate) ≥ 80~90%. 적중률이 70%를 밑돌면 “캐시 대상/키 설계가 잘못됐다”는 신호로 보고 재검토.
  • 신선도 허용치(staleness): 데이터가 수 초~수 분 정도 옛것이어도 괜찮은가? 실시간 정합성이 필수라면 캐시보다 다른 해법을 먼저.
  • 행동 트리거(격차): 동일 조회 쿼리가 DB 부하 상위를 차지하고, 단순 조회의 p95 지연이 평소의 2~3배로 튀기 시작하면 도입 시점.

감 잡기 한 줄: 읽기 90%+ · 같은 키 반복 · 적중률 80%+ 가 그려지면 캐시. 적중률 50% 이하면 비용만 늘리는 셈.

2) DB 커넥션 수를 늘려야 할 때

  • 먼저 적정 크기 공식부터: HikariCP 권장값은 커넥션 수 ≈ (CPU 코어 수 × 2) + 디스크 수. 보통 한 자릿수~수십 개다. 수백 개 커넥션은 거의 항상 안티패턴(컨텍스트 스위칭·락 경합으로 오히려 느려짐).
  • 늘려야 할 신호(비율+격차): 풀 사용률(active/max)이 지속적으로 85% 이상이면서 동시에 커넥션 획득 대기(wait) 시간이 발생(이상적으로는 0, 수십 ms 이상 잡히면 부족).
  • 늘리면 안 되는 신호: 풀 사용률이 50% 미만인데 느리다 → 커넥션 문제가 아니라 쿼리/인덱스/N+1 문제. 또한 DB CPU가 85% 이상이면 커넥션을 늘려도 악화 → 커넥션 증설 전에 쿼리 최적화·읽기 복제본 분산이 먼저.

감 잡기 한 줄: 사용률 85%+ & 대기 발생 → 부족(증설). 사용률 낮은데 느림 → 커넥션 아닌 쿼리 문제. DB CPU부터 확인.

3) RabbitMQ 같은 메시지 큐를 추가해야 할 때

  • 비동기로 떼어낼 일이 있는가: 사용자가 결과를 기다릴 필요 없는 작업(메일/알림 발송, 이미지·영상 처리, 외부 API 연동)이 응답 시간의 30% 이상을 차지하거나 처리에 수백 ms~초가 걸리면 큐로 분리 후보.
  • 트래픽 변동성(비율): 피크:평균 ≥ 5:1 같은 스파이크성 트래픽이면, 큐가 버퍼 역할을 해 부하를 평탄화한다.
  • 강결합 끊기: 외부 호출 실패가 사용자 요청 전체 실패로 전파된다면, 큐로 비동기 격리해 장애 전파를 막는다.
  • 건강 지표(격차): 운영 중 큐 깊이(backlog)가 0 근처에서 안정이면 건강. 큐가 계속 우상향이면 ‘생산 속도 > 소비 속도’라는 뜻 → 컨슈머를 늘리거나 처리 최적화. 목표는 소비률이 생산률보다 약 1.2배 이상 여유(버스트 흡수).

감 잡기 한 줄: ‘기다릴 필요 없는 무거운 일’ + ‘들쭉날쭉한 트래픽’ + ‘장애 전파’ 중 두 개 이상이면 큐. 큐 깊이가 계속 쌓이면 컨슈머 부족.

마무리

Neal Ford와 Rebecca Parsons에게 배운 한 줄은 결국 이것이다 — “아키텍처 결정은 감이 아니라 측정으로.” 위 숫자들은 정답이 아니라 출발점이다. 진화적 아키텍처의 정신대로, 내 서비스에서 직접 지표를 재면서 이 기준선들을 계속 보정해 나가는 것 — 그게 fitness function을 ‘내 것’으로 만드는 과정이라고 생각한다.

참고문헌

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다