Ch02 아키텍처적 사고

한 줄 정의

아키텍처적 사고란 설계자의 눈으로 시스템을 바라보는 것이며, 그 핵심은 기술적 너비를 넓히고, 모든 선택에서 트레이드오프를 분석하는 능력입니다.

쉽게 말하면

개발자가 “이 기능을 어떻게 구현하지?”를 고민한다면, 아키텍트는 “이 결정이 시스템 전체에 어떤 영향을 미치지?”를 고민합니다.

개발자는 한 분야를 깊이 파는 전문가라면, 아키텍트는 여러 분야를 넓게 아는 제너럴리스트에 가깝습니다. 그리고 아키텍트의 모든 판단은 “이게 좋다/나쁘다”가 아니라 “어떤 트레이드오프가 있는가?” 에서 시작합니다.

왜 중요한가?

개발자에서 아키텍트로 전환할 때 가장 어려운 부분이 바로 사고방식의 전환 입니다.

기술적 깊이만 추구하던 습관을 너비로 확장해야 하고, “정답 찾기”에서 “트레이드오프 분석”으로 관점을 바꿔야 합니다. 이 전환이 이루어지지 않으면, 아키텍트라는 직함을 가지고 있어도 실제로는 시니어 개발자 수준에 머무르게 됩니다.

핵심 내용

아키텍처와 설계의 차이

소프트웨어에서 아키텍처는 시스템의 구조 에 초점을 둡니다. 마이크로서비스를 선택할지, 계층형으로 갈지 같은 결정이 여기에 해당합니다.

반면 설계는 시스템의 겉모양 에 관련됩니다. UI 화면의 구조와 형태, 사용자 인터페이스의 설계 같은 것들입니다.

하지만 대부분의 결정은 아키텍처와 설계의 스펙트럼 어딘가에 위치합니다. 명확히 구분하기 어려울 때는 다음 기준으로 판단할 수 있습니다.

전략적 결정과 전술적 결정

결정이 전략(strategy) 적일수록 아키텍처에 가깝고, 전술(tactics) 적일수록 설계에 가깝습니다.

판단에 도움이 되는 질문들이 있습니다.

결정에 얼마나 많은 사고와 계획이 필요한가? — 몇 분이면 내릴 수 있는 결정은 전술적(설계), 몇 주 동의와 계획이 필요하면 전략적(아키텍처)입니다.
결정에 몇 명이 관여하는가? — 혼자서 내리는 결정은 설계, 다수의 이해관계자와 협의해야 하면 아키텍처입니다.
결정이 장기적인 비전인가, 단기적인 행동인가? — 곧 변경될 가능성이 큰 결정은 설계, 오랜 기간 지속될 결정은 아키텍처입니다.

노력의 정도

마틴 파울러(Martin Fowler)는 아키텍처를 “변경하기 어려운 것들” 이라고 표현했습니다.

변경이 어려울수록 더 많은 노력이 필요하므로, 그런 결정이나 활동은 스펙트럼에서 아키텍처에 더 가깝습니다. 반면 구현이나 변경에 노력이 거의 들지 않는 사안은 설계 쪽에 놓입니다.

정리의 중요성

중요한 트레이드오프 일수록 해당 결정은 아키텍처에 더 가까워집니다.

예를 들어, 마이크로서비스 아키텍처 스타일을 선택하면 확장성, 민첩성, 탄력성, 내결함성이 좋아집니다. 하지만 시스템이 매우 복잡해지고 비용이 많이 들며, 데이터 일관성이 낮아지고 서비스 사이의 성능도 좋지 않습니다. 이처럼 중대한 트레이드오프가 수반되므로 아키텍처 쪽에 해당합니다.

반면 클래스 파일을 여러 조각으로 쪼개면 유지보수성과 가독성이 좋아지지만, 관리할 클래스가 늘어난다는 정도의 트레이드오프는 상대적으로 덜 중요합니다. 따라서 설계 쪽에 더 가깝습니다.

기술적 너비

개발자에게 기술적 깊이(technical depth) 가 중요하다면, 아키텍트에게는 기술적 너비(technical breadth) 가 더 중요합니다.

이 차이를 이해하는 데 지식 피라미드 가 도움이 됩니다.

graph TB
    A["알고 있는 것<br/>(기술적 깊이)"]
    B["모른다는 것을 아는 것<br/>(기술적 너비)"]
    C["모르는 줄도 모르는 것"]

    A --- B --- C

    style A fill:#4a90d9,color:#fff
    style B fill:#7ab8e0,color:#fff
    style C fill:#b0d4f1,color:#333

알고 있는 것 — 일상 업무에서 사용하는 기술, 프레임워크, 언어, 도구. 기술적 깊이 를 대표합니다.
모른다는 것을 아는 것 — 들어는 봤고 원리는 대충 알지만, 실제 경험이나 전문성이 거의 없는 영역. 기술적 너비 를 대표합니다.
모르는 줄도 모르는 것 — 주어진 문제의 완벽한 해법이 될 수 있는 기술인데, 존재 자체를 모르는 것. 피라미드에서 가장 큰 부분을 차지합니다.

개발자와 아키텍트의 지식 구조 차이

개발자는 커리어 내내 피라미드의 상단(깊이) 을 키우는 데 집중합니다. 한 분야를 선택해서 전문성을 쌓는 것이 핵심이기 때문입니다.

아키텍트는 반대로 피라미드의 중간 부분(너비) 을 넓히는 것이 더 중요합니다. 아키텍트가 결정을 내릴 때는 여러 가지 기술적 제약과 팀의 역량을 고려해야 하므로, 다양한 솔루션을 폭넓게 이해하는 것이 매우 가치 있습니다.

현명한 아키텍트는 힘들게 쌓은 일부 전문성을 포기하고 그 시간만큼 자기 기술 포트폴리오의 폭을 넓혀야 합니다.

이 변화를 어렵게 느끼는 사람이 많습니다. 흔히 두 가지 문제로 나타납니다. 첫째, 아키텍트가 많은 영역의 전문성을 유지하려 하다가 어느 것 하나 성공하지 못합니다. 둘째, 자신의 오래된 지식이 여전히 최신이라고 착각하는 케케묵은 전문 지식(stale expertise) 현상이 나타납니다.

꽁꽁 언 원시인 안티패턴

아키텍트가 자신이 집착하는 비합리적인 관심사로 모든 아키텍처를 판단하는 행동적 안티패턴을 ‘꽁꽁 언 원시인(Frozen Caveman)’ 안티패턴이라고 합니다.

과거의 잘못된 결정이나 뜻밖의 사건에 대한 경험이 있는 아키텍트가 관련 모든 것에 과도하게 신중해지는 형태로 나타납니다. 실질적인 기술 위험과 ‘느낌상의 위험’을 구분하는 능력을 계속 배우고 익혀야 합니다.

20분 규칙

매일 최소 20분 을 새로운 내용을 학습하거나 특정 주제에 대해 더 깊이 파고드는 데 사용합니다.

핵심은 바쁘더라도 기술적 너비를 넓히는 데 집중할 시간을 의도적으로 확보 하는 것입니다. 특히 이메일을 확인하기 전에 20분을 투자하라고 강력히 권합니다. 아침의 집중력은 이메일을 확인하는 순간부터 사라지기 시작하기 때문입니다.

좋은 학습 소스로는 InfoQ, DZone Refcardz, 소트웍스 기술 레이더 등이 있습니다.

개인 레이더 개발

소트웍스(ThoughtWorks)의 기술 레이더 는 신생 기술의 위험과 보상을 평가할 수 있게 돕는 ‘살아 있는’ 문서입니다.

기술 레이더는 네 개의 사분면과 네 개의 동심원으로 구성됩니다.

사분면 (분류)

사분면	내용
Tools(도구)	IDE, 개발 도구부터 엔터프라이즈급 통합 도구까지
Languages and Frameworks	컴퓨터 언어, 라이브러리, 프레임워크
Techniques(기법)	프로세스, 엔지니어링 관행, 실천법
Platforms(플랫폼)	데이터베이스, 클라우드, 운영체제 등 기술 플랫폼

동심원 (성숙도)

동심원	의미
Hold(보류)	재고해야 할 기술. 새 프로젝트에서는 시작하지 말 것
Assess(평가)	탐색해 볼 만한 기술. 연구나 스파이크 수준
Trial(시도)	적극적으로 추구할 만한 기술. 저위험 프로젝트에서 시작
Adopt(채택)	업계가 반드시 채택해야 할 기술

개인 레이더를 만드는 과정 자체가 핵심입니다. 바쁜 일정 중에서 그런 기술들을 생각해 볼 시간을 확보한 구실이 되고, 그 과정에서 생기는 대화와 사고가 가장 중요합니다.

정리 분석

아키텍처적 사고의 핵심 역할 입니다. 모든 해법에서 트레이드오프(절충점)를 찾아내고, 그 장단점을 분석해서 최선의 해법을 도출하는 것입니다.

아키텍처적인 구글이나 LLM에 풀어볼 수 없는 것들이다. — 마크 리처즈

아키텍처에는 정답도 오답도 없다. 트레이드오프가 있을 뿐이다. — 닐 포드

정답은 항상 “상황에 따라 다르다(It depends)” 입니다. 배포할 환경, 비즈니스 목표, 조직 문화, 예산, 일정, 개발자 역량 등 수많은 요소에 따라 달라지기 때문입니다.

예시: 경매 시스템의 토픽 vs 대기열

온라인 경매에서 Bid Producer 서비스가 입찰 항목을 Bid Capture, Bid Tracking, Bid Analytics 세 서비스로 전송해야 한다고 가정합니다.

토픽(발행-구독) 방식

Bid Producer는 토픽 하나에만 연결하면 됩니다. 새 서비스(Bid History)를 추가할 때도 토픽을 구독하기만 하면 됩니다.

flowchart LR
    BP[Bid Producer] --> T((Topic))
    T --> BC[Bid Capture]
    T --> BT[Bid Tracking]
    T --> BA[Bid Analytics]
    T -.-> BH[Bid History]

    style T fill:#f9a825,stroke:#f57f17,color:#000
    style BH stroke-dasharray: 5 5

대기열(점대점) 방식

Bid Producer가 세 개의 대기열에 각각 연결되어야 합니다. 새 서비스를 추가하면 새 대기열과 Bid Producer의 로직 수정이 필요합니다.

flowchart LR
    BP[Bid Producer] --> Q1[/Queue/]
    BP --> Q2[/Queue/]
    BP --> Q3[/Queue/]
    BP -.-> Q4[/Queue/]
    Q1 --> BC[Bid Capture]
    Q2 --> BT[Bid Tracking]
    Q3 --> BA[Bid Analytics]
    Q4 -.-> BH[Bid History]

    style Q1 fill:#42a5f5,stroke:#1565c0,color:#fff
    style Q2 fill:#42a5f5,stroke:#1565c0,color:#fff
    style Q3 fill:#42a5f5,stroke:#1565c0,color:#fff
    style Q4 fill:#42a5f5,stroke:#1565c0,color:#fff
    style BH stroke-dasharray: 5 5
    style Q4 stroke-dasharray: 5 5

기준	토픽(발행-구독)	대기열(점대점)
아키텍처 확장 능력	우수 (새 구독자 추가 용이)	부족 (새 대기열 + 로직 수정 필요)
서비스 결합도	낮음	높음 (Bid Producer가 소비자를 알아야 함)
데이터 접근 보안	취약 (누구나 토픽 접근 가능)	강함 (특정 소비자만 수신)
소비자별 메시지 포맷	동질적 계약만 가능	소비자별 자체 계약 가능
모니터링/확장성	개별 모니터링 미지원, 자동 확장 미지원	개별 모니터링, 부하 분산, 자동 확장 가능

겉보기에 토픽이 압도적으로 좋아 보이지만, 아키텍트라면 부정적인 측면도 들여다봐야 합니다. 이처럼 트레이드오프를 폭넓게 따져 본 후, “확장 능력이 더 중요한가, 아니면 보안이 더 중요한가?” 같은 질문을 해야 합니다.

비즈니스 동인의 이해

아키텍처적 사고는 시스템 자체를 이해하는 것을 넘어서 시스템의 성공에 필요한 비즈니스 동인(business driver) 을 이해하는 것입니다.

확장성, 성능, 가용성 같은 아키텍처 특성을 도출하려면, 비즈니스가 무엇을 필요로 하는지 알아야 합니다. 비즈니스 도메인 지식이 필요한 이유이기도 하고, 주요 비즈니스 이해관계자들과 원만하고 협력적인 관계를 뺏어야 하기 때문입니다.

아키텍처와 코딩 실무의 균형

아키텍트가 직면하는 난제 중 하나는 코딩 실무와 아키텍처 작업의 균형 을 맞추는 일입니다. 아키텍트는 반드시 코딩을 해야 하며, 일정 수준 이상의 기술적 깊이를 유지해야 합니다.

병목 함정(Bottleneck Trap)

아키텍트가 시스템의 핵심 경로(critical path)에 위치한 코드의 기반이 되는 바탕 코드를 소유하게 되면, 아키텍트가 팀 전체의 병목 이 됩니다.

이를 피하려면 시스템의 핵심 부분을 개발 팀 내 다른 이들에게 위임하고, 대신 아키텍트는 향후 1~3번의 반복(iteration) 이후에 필요할 소규모 비즈니스 기능성(예: 서비스나 UI 화면)에 초점을 둔 코딩 실무를 맡는 것이 좋습니다.

이렇게 하면 세 가지 긍정적인 효과가 생깁니다.

아키텍트는 실제 프로덕션 코드를 작성하면서도 팀의 병목이 되지 않습니다.
시스템의 핵심 경로와 프레임워크 코드를 개발 팀에 분산시킴으로써, 개발자들이 시스템의 더 어려운 부분에 대해 소유권을 가지고 시스템을 더 깊이 이해하게 만들 수 있습니다.
아키텍트가 개발 팀과 동일한 비즈니스 관련 소스 코드를 작성하게 됩니다. 이는 개발 과정, 프로세스, 개발 환경에서 팀이 겪는 고충을 아키텍트가 더 잘 이해하는 데 도움이 됩니다.

기술적 깊이를 유지하는 방법들

PoC를 자주 진행한다 — 개념 증명(Proof of Concept) 작업을 자주 진행하면 아키텍처적 결정을 실제 구현 관점에서 검증할 수 있습니다. 가능한 한 프로덕션급 품질의 코드를 작성해야 합니다.
기술 부채를 해결한다 — 개발 팀이 중요한 기능적 사용자 스토리 작업에 집중할 수 있도록, 우선순위가 낮은 기술 부채를 아키텍트가 처리합니다.
버그를 잡는다 — 반복 동안 버그를 고치면서 실무 감각을 유지하고, 코드베이스와 아키텍처의 문제점이나 약점을 발견하는 기회가 됩니다.
자동화를 한다 — 명령줄 도구나 분석기를 만들어서 개발 팀의 일상 업무를 자동화하면, 코딩 실무 역량을 유지하면서 팀의 생산성도 높일 수 있습니다.
코드 검토를 한다 — 직접 코드를 작성하지 않더라도 소스 코드에 관여하게 되며, 아키텍처 준수 여부를 점검하고 멘토링 기회도 포착할 수 있습니다.

정리

개발자 vs 아키텍트의 지식 전략

기준	개발자	아키텍트
지식 전략	기술적 깊이(depth) 중심	기술적 너비(breadth) 중심
목표	한 분야의 전문가	다양한 분야의 트레이드오프 파악
지식 피라미드 초점	상단(알고 있는 것) 키우기	중간(모른다는 것을 아는 것) 넓히기
위험	시야가 좁아짐	케케묵은 전문 지식(stale expertise)

아키텍처 vs 설계 판별 기준

기준	아키텍처에 가까움	설계에 가까움
결정의 성격	전략적 (장기적, 다수 관여)	전술적 (단기적, 혼자 결정)
변경 노력	높음 (변경하기 어려움)	낮음 (쉽게 변경 가능)
트레이드오프	중대한 트레이드오프 수반	경미한 트레이드오프

내 생각

20분 규칙 은 당장 실천할 수 있는 가장 구체적인 조언입니다. 매일 아침 이메일 열기 전에 InfoQ나 기술 블로그를 20분 읽는 습관은 1년이면 상당한 기술적 너비를 만들어 줍니다.
케케묵은 전문 지식(stale expertise) 은 경력이 쌓일수록 경계해야 할 함정입니다. “내가 아는 방식이 최선”이라는 확신이 강해질수록, 실은 그 지식이 이미 낡았을 가능성이 높습니다.
병목 함정 은 실무에서 자주 보는 패턴입니다. “내가 제일 잘 아니까 내가 하겠다”는 선의가 오히려 팀 전체의 속도를 떨어뜨립니다. 아키텍트의 코딩은 핵심 경로가 아닌 곳에서 해야 합니다.
토픽 vs 대기열 예시는 아키텍처적 사고의 핵심을 잘 보여줍니다. 실무에서도 “이 기술이 좋다”가 아니라 “이 상황에서 어떤 트레이드오프를 감수할 것인가”로 접근해야 합니다.

출처

소프트웨어 아키텍처 The Basics, Ch02 아키텍처적 사고

Dev Wiki

탐색기