Architecture - 전략적 학습을 위한 도구
in DEV on Architecture
이 포스트에서는 빈약한 의사소통을 개선하고, 기업 문화의 기준을 더 높이는 데 도움이 되는 전략적 학습 도구에 대해 알아본다.
이 도구들을 통해 실험을 기반으로 정보에 입각한 결정을 내리는 방법과 소프트웨어와 아키텍처에 적용하는 방법을 학습한다.
- 소프트웨어 아키텍처와 기술 플랫폼보다 비즈니스 이니셔티브를 우선시 할 것
- 사용자들은 마이크로서비스나 클라우드 같은 기술 자체에 관심이 있는 것이 아니라 그 기술이 제공하는 결과에 관심이 있음
- 사용자에게 최상의 결과를 제공하는 가장 빠른 방법은 점진적 개선을 일관성있게 추진하는 것임
- 최고의 서비스 수준의 아키텍처와 배포 방법 옵션들을 놓고 필요와 목적을 충분히 이해한 상태에서 선택할 것
- 실패 문화를 수용하되, 실패를 비난하는 문화로 오해하지 않아야 함
- 통제된 실패가 성공으로 이어질 수 있으며, 이때 실패는 황금 항아리로 가는 레드 카펫이 될 수 있음
- 빠른 실패는 빠른 학습으로 이어짐
- 기업의 비즈니스 역량을 정확히 인식하는 것은 전략적 소프트웨어 이니셔티브 중에서 가장 큰 투자가 필요한 부분을 파악하는데 매우 유용함
- 무료로 구입하거나 다운로드할 수 있는 것을 직접 구축하지 말 것
비즈니스 이니셔티브
비즈니스 이니셔티브는 비즈니스 성과(매출 성장, 고객 확보, 제품 개선 등)을 만들기 위해 시작하는 구체적이고 실행 가능한 프로젝트나 활동임
주로 “당장의 비즈니스 목표”를 달성하기 위해 움직임
예) 신규 가입자 30% 늘리기, 연내 새로운 구독 상품 출시, 구매 전환율 10% 높이기
즉, 이렇게 당장의 비즈니스 성과를 만들기 위한 활동을 말함 (실행 중심)전략적 이니셔티브는 장기적인 방향성이나 회사의 큰 그림을 이루기 위해 시작하는 더 고차원적인 프로젝트를 말함
단기 목표보다 회사의 전략적 포지셔닝, 경쟁력 강화, 장기 생존 같은 것을 목표로 함
예) 5년 내 글로벌 시장 점유율 1위 달성, AI 기반 서비스를 전 사업군에 도입
즉, 회사의 전략적 미래를 위해 움직이는 대규모 방향성을 말함 (방향 설정 중심)
전략 수립 과정에서는 비즈니스 가치를 명확히 식별하고, 차별화된 전략을 발굴해야 한다.
이 과정 자체에도 지속적인 혁신이 필요하다.
비즈니스는 자신의 사업을 누구보다 깊이 이해하는 능력을 갖춰야 한다.
이 능력을 성공을 위한 절대적인 조건이며, 단발적인 이해에 그치지 않고 끊임없이 탐구하고 학습하며, 새로운 통찰을 발견하는 과정이 꾸준히 이어져야 한다.
목차
- 1. 이른 결정, 늦은 결정, 맞는 결정, 틀린 결정
- 2. 문화와 팀
- 3. 대규모 시스템은 왜 분해되는가: 인지 한계와 모듈 설계의 원리
- 4. 최종 책임 순간까지 결정 미루기: 모놀리스와 마이크로서비스 배포 전략
- 5. 모듈과 배포, 그 사이
- 6. 전략적 아키텍처와 아키텍처 결정 기록(ADR, Architecture Decision Records) 의 중요성
- 정리하며..
- 참고 사이트 & 함께 보면 좋은 사이트
1. 이른 결정, 늦은 결정, 맞는 결정, 틀린 결정
요약
- 결정은 빨라도, 늦어도, 반드시 책임있게
- 잘못된 결정도 학습의 자산임
- 비판적 사고로 인지 오류를 극복하자
- 의사결정 기록을 남기고, 필요한 경우 구조적으로 결정을 유예하자
전략 수립과 개발 과정에서 어떤 결정은 가능한 한 빨리 내리는 것이 최선이고, 어떤 결정은 가능한 한 늦게 내리는 것이 최선이다.
애자일 원칙에서는 모든 결정이 “최종 책임 순간”에 이루어져야 한다고 강조한다.
그렇다면, 어떻게 그 순간을 알 수 있을까?
메리와 톰 포펜디크는 다음과 같이 조언한다.
되돌리기 어렵고 중요한 결정은 최대한 늦게 내려야 한다.
결정하지 않는 비용이 결정하는 비용보다 커지기 직전까지 기다린다면, 더 많은 정보를 수집할 수 있어서 실패 위험을 줄일 수 있다.
무책임한 결정은 언제나 문제를 만들기 때문에 결정은 책임감있게 내려야 한다.
무책임한 결정은 상황을 충분히 이해하지 못했을 때 발생하며, 대부분 너무 이른 결정에 다다르게 된다.
충분한 정보가 있어도 검토없이 성급히 결정하면 실패는 명확해진다.
시간이 흐를수록, 결정을 미루는 것은 잘못된 결정을 내리는 것보다 더 큰 문제가 된다.
스스로 동기부여된 사람들은 가만히 앉아서 기다리지 않는다.
개발 초기에는 종종 아래와 같은 문제가 발생한다.
- 잘못된 결정으로 인한 불완전한 코드
- 지나치게 범용적인 추상화 계층을 정의
- 일부 개발자가 팀 방향과 다르게 독자적으로 움직이는 현상
이런 임의적인 행동들은 행동한 본인 입장에서는 헌신적인 기여처럼 보일 수 있지만, 이러한 행동은 팀의 공식적인 의사결정 과정을 무시하고 개인 플레이를 강화함으로써 결과적으로 팀워크를 약화시킨다.
결국 초기에 발생한 이러한 독자적인 행동 패턴은 애플리케이션 또는 아키텍처 구조 자체에 고착되어 소프트웨어 생명주기 전체에 걸쳐 지속적인 부정적 영향을 끼치게 된다.
잘못된 결정을 했을 때는 숨지기 말고 솔직하게 인정해야 최대한 빨리 상황을 바로잡을 수 있다.
초기에 잘못된 구조를 바로잡는 것은 큰 비용이 들지 않지만, 시간이 지나면 수정 비용은 급격히 증가한다.
즉, 빠르게 인정하고 빠르게 수정하는 것이 좋다.
잘못된 결정을 내리기 전에 애플리케이션 구조화를 시작하는데 오랜 시간을 기다리기만 했다면, 얻을 수 있는 것은 거의 없다.
- 결정을 빨리 내리고, 실패를 경험하며, 그때그때 개선해온 경우
- 결정을 늦게 내리고, 아무런 경험 없이 최종 선택만 하는 경우
이 둘은 비교하면 전자가 훨씬 더 나은 결과를 만든다.
결정을 하고, 실패하고, 개선하는 과정을 통해 더 깊은 학습을 하고, 문제를 더 근본적으로 이해하게 된다.
이것은 마치 부채를 기록하고 최대한 빨리 갚아나가는 것과 같은 이치이다.
빚을 숨긴 채 시간이 흐를수록 이자는 불어나고, 결국 훨씬 더 큰 대가를 치르게 되듯이 결정도 빠르게 내리고 빠르게 수정하는 것이 최선이다.
이것이 바로 최종 책임 순간에 내리는 성숙한 의사 결정이다.
즉, 성숙한 의사 결정은 경험을 거치는 쪽이다.
의사결정을 하지 못한 채 고민하고 있거나, 이미 내려진 잘못된 결정으로 인해 주눅 들 필요는 없다.
일부 성공적인 실험은 우리의 가정이 옳았음을 확인하는 과정일 뿐이다.
또 다른 실험들은 우리의 생각이 실제로 유효한지를 검증하기 위해 존재한다.
결국 모든 실험을 학습의 일부이다.
잘못된 결과가 나오더라도 그것은 중요한 경험이 된다.
하지만 과도하게 이른 결정은 무책임한 행동이다.
특히 충분한 정보도 없이 “MSA 를 도입하자” 며 미리 아키텍처를 설계하는 것은 심각한 실수이다.
이러한 중요한 결정은 선택의 필요성과 정당성이 명확해질 때까지 미뤄야한다.
전문가와 아마추어를 가르는 기준은 타이밍이다.
전문가는 중요한 결정을 언제까지 미뤄야 하는지를 알고 있으며, 오류를 최대한 이른 시점에 포착하여 큰 문제가 되기 전에 개선하는 방법을 알고 있다.
반면 아마추어는 처음부터 모든 것을 완벽하게 하려하고, 문제가 자신의 해결 능력을 넘어설 때 결국 잘못된 결정을 조급하게 내려버리는 경향이 있다.
결국 의사결정의 핵심은 타이밍이다.
의사결정은 학습을 이끈다.
모든 결정은 행동을 이끌고, 행동은 새로운 요구사항과 지식을 만들어낸다.
결정은 학습과 지식 습득으로 이어지는 과정이므로, 결정하는 것을 두려워하거나 소홀히해서는 안된다.
아래는 무책임한 MSA 선택을 부르는 오류들이다.
- 권위에 대한 호소
- 전문가처럼 보이는 사람이 MSA 를 추천했다는 이유만으로 도입하는 것
- 참신함에 대한 호소
- 새로운 트렌드라는 이유만으로 도입하는 것
- 군중에 대한 호소
- 다른 회사가 도입했으니 우리도 해야 한다는 식의 포모 심리
이러한 오류를 피하기 위해 비판적 사고가 필요하다.
비판적 사고란
- 자신의 신념과 행동을 돌아보고,
- 논리적으로 추론하며,
- 복잡한 문제를 다각도로 바라보는 사고 패턴이다.
비판적 사고를 통해 문제 상황의 다양한 측면을 볼 수 있기 때문에 우리는 더 신중하고 견고한 결론에 도달할 수 있다.
의사결정 과정을 기록하는 것도 중요하다.
예를 들어 아키텍처 결정 기록(ADR, Architecture Decision Record) 와 같은 도구를 통해 팀의 의사결정 과정을 추적하고 관리할 수 있다.
결정을 유예하고 싶다면 구조를 지혜롭게 설계하면 된다.
때로는 지금 당장 결정할 수 없는 장기적 문제들이 있다.
이럴 때 사용할 수 있는 개발 기법 중 하나는 포트 및 어댑터 아키텍처이다.
포트 및 어댑터 아키텍처는 핵심 비즈니스 로직과 외부 시스템을 분리하여 의존성을 최소화하고 유연성을 확보한다.
또한 시네핀 프레임워크와 같은 인지 모델을 사용하여 복잡한 상황에서도 적절한 의사결정을 내릴 수 있다.
포트 및 어댑터 아키텍처에 대한 상세한 내용은 추후 다룰 예정입니다. (p. 97)
2. 문화와 팀
실험과 학습을 장려하는 문화를 만드는 것은 중요하다.
애자일 문화를 제대로 정착시키기 위해서는 잘못된 시도조차 보상하는 구조가 필요하다.
실패한 시도라도, 그 실패가 결국 더 나은 결과로 이어질 수 있다면 그 자체로 가치 있는 경험이기 때문이다.
엔지니어링 모델 vs 계약 모델
소프트웨어 개발 접근 방식에는 엔지니어링 모델과 계약 모델이라는 두 가지 개념이 있음
계약 모델
- 개발자에게 명확한 작업 지시를 내림
- 실패는 허용되지 않음
- 목표는 “지시된 대로 정확히 수행”하는 것
엔지니어링 모델
- 가설을 기반으로 실험적 개발을 수행
- 과정 속에서 학습하고 개선하는 것을 장려함
- 실패는 더 나은 결과를 위한 필수 과정으로 받아들임
엔지니어링 모델의 대표적인 사례로는 스페이스엑스와 테슬라가 있음.
이들은 반복적인 실험과 실패를 통해 비약적인 기술적 성과를 이뤄내었음
문화가 결국 팀과 조직을 결정짓는다.
기업 문화는 단순한 분위기나 규칙 이상의 의미를 가진다.
문화는 아래와 같은 모든 것에 영향을 미친다.
- 팀의 상호작용 방식
- 가치있는 지식의 생성과 공유
- 변화에 대한 수용 또는 저항
- 지식의 격리 또는 개방성
건강한 조직 문화를 갖춘 팀은
- 목표를 향해 빠르게 합의할 수 있고
- 팀 응집력이 높아지며,
- 개인 구성원들도 더 강한 동기를 느낀다.
- 결과적으로 업무 효율성 역시 극대화된다.
새로운 조직이나 팀을 만들 때, 혹은 기존 문화를 바꾸려 할 때 무엇보다 가장 먼저 신경써야 할 것은 건강한 문화 구축이다.
도구나 프로세스, 시스템을 아무리 잘 정비해도 문화가 병들어 있다면 어떤 구조든 쉽게 무너질 수 있다.
2.1. 실패는 치명적이지 않다
실패에 대한 두려움은 의사결정 방식에 직접적인 영향을 미친다.
실패로 이어질까봐 두려워서 결정을 계속 미루거나 아예 결정을 내리지 못하는 경우가 생긴다.
두려움은 빠르고 책임 있는 의사결정을 가로막고, 결국 팀과 조직의 성장을 방해하게 된다.
엔지니어링 모델은 실패로부터 조직의 학습을 유도하기 때문에 계약 모델보다 월등하다.
- 엔지니어링 모델은 가설을 세우고 실험을 수행한다.
- 모든 실험적 실패는 목적을 위한 수단이다.
- 실패는 ‘무엇이 어떻게 동작하는지’ 를 배우기 위한 과정이다.
반면, 팀이 전혀 실패하지 앟는다면 그것은 학습을 통해 새로운 길을 찾지 않고, 이미 알고 있는 안전한 공간 안에서만 결정을 내린다는 신호일 수 있다.
즉, 우물 안 개구리처럼 기존의 지식에 안주하고 있다는 뜻이다.
애자일 문화와 실패를 용납하는 건강한 조직 문화는 팀이 기꺼이 실험을 수행하고, 실패를 두려워하지 않도록 만든다.
실패해도 괜찮다는 심리적 안정감을 제공하고, 새로운 가능성을 실험하고 탐색하는 모험 정신을 장려한다.
그러나 여기에도 균형이 필요하다.
실패를 용납하는 문화가 있다고 해서 무능함이나 현실 안주까지 용납해서는 안된다.
실패를 인정하되, 항상 학습과 개선을 전제로 해야 한다.
실패는 흥미로운 학습 기회를 제공한다.
열악한 모델 설계, 취약한 코드, 부족한 아키텍처, 불완전한 분석, 기술 역량 부족.. 이러한 실수들은 모두 중요한 교훈을 얻을 수 있는 기회다.
실패에도 2가지 종류가 있다.
| 구분 | 긍정적인 실패 | 부정적인 실패 |
|---|---|---|
| 정의 | 정보와 지식을 생산하는 실패 | 비용만 낭비하고 비즈니스에 해를 끼치는 실패 |
| 결과 | 학습 기회를 제공하고, 성장과 성공으로 이어짐 | 큰 비용만 소모하고, 조직에 실질적 해를 끼침, 신뢰 하락 |
실패를 통해 구체적 성과와 지식을 얻었을 때, 조직은 반드시 보상을 제공해야 한다.
실패 자체를 보상하는 것이 아니라 실패를 통한 학습과 개선 노력을 보상하는 것이다.
이러한 보상 구조가 있어야만 팀이 더 많은 실험을 두려움 없이 시도할 수 있고, 조직은 지속적인 성장을 이어갈 수 있다.
2.2. 비난 문화가 혁신을 막는 방식
비난 문화는 실패를 용납하지 않는다.
실패를 통한 학습을 축하하거나 인정하지 않고, 실패 속에 담긴 성과조차 그냥 버려진다.
비난이 지배하는 환경에서는 문제 해결을 위한 실험조차 계획할 수 없다.
결국 모든 일은 동일하고, 일률적이며, 평범한 방식으로만 진행된다.
누구나 비난받기를 싫어하기 때문에 실패할 수도 있는 새로운 시도를 꺼리게 되고, 아무도 위험을 감수하려 하지 않는다.
이런 환경에서는 창의성과 혁신히 완전히 사라진다.
비난 문화에 빠진 기업은 혁신 대신 운영 효율성을 통해 수익을 올리려 한다.
가장 흔한 방법은 인수합병과 같은 외부 성장 전략이다. 주주에게 보기 좋은 연간 보고서를 만들어내는 것에 집중하고, 비즈니스 혁신보다는 현재 모델을 최대한 효율적으로 굴리는 데 몰두한다.
이 전략은 단기적으로는 효과가 있지만 장기적으로는 지속적인 성장을 보장하지 못한다.
COVID-19 팬데믹의 예를 보자.
COVID-19 대유행 당시 미국 정부는 수많은 백신 연구 개발 프로젝트에 자금을 지원했다.
일부 프로젝트를 실패했고, 일부 프로젝트는 성공했다.
정부는 처음부터 일부는 실패할 것은 알고 있었지만, 성공할 가능성도 충분하다는 기대를 안고 위험을 감수했다.
여러가지 방안을 병렬로 탐색하는 것은 문제 해결을 위한 가장 빠르고 효율적인 방법이 될 수 있다.
비난 문화에서는 수동적 공격으로 팀을 관리하고, 과도한 통제, 업무 시간 과다 측정, 마감일을 맞추기 위한 야근 강요 등의 내부적 문제 행동이 나타난다.
비난은 다른 사람의 실수를 집요하게 들춰내고, 심지어 잘된 결과조차 잘못된 것처럼 몰아간다.
수동적 공격은 겉으로는 순응하는 척하지만, 속으로는 저항하는 행동을 말한다.
예를 들어 “너 오늘은 괜찮아 보이네.” 처럼 말하는 경우 표면적으로는 칭찬같지만 실제로는 빈정대는 의미를 담고 있다.
수동적 공격은 직접적인 대립을 피하면서도 상대방을 깎아내리는 방법이다.
2.3. 시스템 아키텍처를 완성하는 팀 전략: 팀 토폴로지와 역 콘웨이 패턴
팀 토폴로지에서 강조하듯 추구하는 시스템 구조가 조직 구조와 맞지 않는다면, 시스템 혹은 조직 중 하나는 반드시 변경되어야 한다.
조직의 재구성은 반드시 기술적인 아키텍처만을 위한 것이 아니다.
기술 아키텍처는 비즈니스 전략 아키텍처를 지원하기 위해 존재한다.
개별 팀은 비즈니스 전문가와 소프트웨어 개발자 간의 필수적인 대화를 촉진할 수 있어야 한다.
“도메인 전문가의 참여는 최종 참여자의 참여를 뜻하며, 최종 사용자의 요구사항에 따라 기능을 개발하는 것과 같다.”
최종 사용자와 도메인 전문가는 린(Lean) 과 애자일 프로젝트에서 가장 중요한 접점임을 이해해야 한다.
최종 사용자(User) 는 제품이나 서비스를 실제로 사용하는 사람을 의미한다.
도메인 전문가는 금융 서비스를 개발할 때의 금융 전문가나 의료 서비스를 개발할 때의 의사처럼 특정 비즈니스 영역(도메인)에 깊은 지식과 경험을 가진 사람을 의미한다.
린(Lean) 과 애자일의 핵심은 “낭비를 줄이고 빠르게 가치있는 제품을 만드는 것”인데 이 목표를 달성하려면 누구를 위해 어떤 가치를 만들어야 하는지를 정확히 알아야 한다.
최종 사용자와 도메인 전문가의 접점이 중요한 이유는 최종 사용자는 “어떤 문제를 해결해야 하는지”를 알고 있고, 도메인 전문가는 “그 문제를 비즈니스 관점에서 어떻게 풀어야 하는지”를 알고 있기 때문이다.
따라서 이 두 집단이 제대로 연결되어야 진짜 의미있는 요구사항을 뽑아낼 수 있고, 그 요구사항을 제대로 해결하는 소프트웨어를 만들 수 있다.
린이나 애자일 방식에서는 최종 사용자와 도메인 전문가가 지속적으로 대화하고, 짧은 주기로 피드백을 받으며, 빠르게 방향을 조정한다.
린(Lean)
린은 낭비를 최소화하고 고객에게 가치를 빠르게 전달하는 방법론임
고객이 진짜 원하는 것에만 집중해서 빠르고 효율적으로 가치를 만드는 것고객이 원하지 않은 기능은 없애서 낭비를 제거하고, 작은 단위로 빠르게 만들고 검증해서 빠른 피드백을 받음
소프트웨어 개발에서의 린
- 작은 기능 단위로 빠르게 출시하고, 고객 피드백을 받아 개선함
- 불필요한 문서, 미팅, 승인 절차 최소화
- WIP(Work In Process) 를 줄여서 동시에 많은 걸 하려 하지 않음
린(Lean) vs 애자일
린
- 목표: 낭비를 줄이고 가치 흐름을 최적화
- 핵심: 효율성
- 접근 방법: 프로세스 최적화
애자일
- 목표: 고객 요구에 빠르고 유연하게 대응
- 핵심: 적응성
- 접근 방법: 팀 협력과 반복적 개발
공통점은 둘 다 “빠르게 고객 가치를 제공”하려 한다는 것임
즉, 린은 효율성과 가치 흐름을 강조하고, 애자일은 유연성과 적응을 강조하지만 결국 둘 다 비슷한 목표를 가짐
역 콘웨이 법칙은 마이크로서비스가 대중화되면서 주목받기 시작했다.
이 패턴은 원하는 시스템을 먼저 설계한 후 그에 맞게 팀 구조를 다시 만들라고 조언한다.
팀 간 소통을 최적화하여 재구성하면 목표하는 시스템 아키텍처를 실제로 실현할 가능성이 높아진다.
<팀 간 소통을 개선하는 효과적인 팀 구성 방법>
- 팀을 먼저 구성하고 교류를 촉진하라
- 업무를 수행하기 전에 팀을 구성하고 규범을 세운다.
- 교류룰 통해 암묵적 지식을 공유하는 시간이 필요하다.
- 프로젝트 구축 팀이 해산되면 그 프로젝트는 유지보수 팀으로 넘어가는 경우가 있는데 이 때 프로젝트 구축 팀에서 쌓인 암묵적 지식이 사라지기 쉬우므로 지속 가능한 팀 구조가 중요하다.
- 팀 크기를 제한하라
- 소프트웨어 도메인 문제를 풀 수 있는 최소 규모의 팀을 구성한다.
- 팀이 커질수록 내부 조정과 소통 비용이 급격히 증가한다.
- 독립적인 팀을 구성하라
- 코드 의존성을 최소화하고, 릴리스 과정에서 자율성을 확보해야 한다.
- 비즈니스 역량을 중심으로 조직하라
- 팀 내 다양한 기술 스킬(아키텍트, 개발자, QA 등) 을 통합한다.
- 모든 역할이 평등한 관계에서 업무를 수행해야 한다.
- 콘웨이의 법칙에 따르면 기술 스킬을 기반으로 만들어진 사일로(Silo) 조직보다 비즈니스 중심 교차 기능팀이 훨씬 효과적이다.
- 팀 간 소통 게이트웨이를 명확히 정의하라
- 팀 간 소통은 명확한 프로토콜과 게이트웨이를 거쳐야 한다.
- 이는 팀의 목표와 방향성을 보호하고, 허가받지 않은 의견 교환이 이뤄지지 않게 한다.
- 팀은 단일 책임을 갖는다
- 한 팀에 과도한 작업과 여러 컨텍스트를 요구하면 안된다.
- 단일 책임은 “단 한가지 컨텍스트만을 다뤄야 한다”는 것이 아니라 “한 가지 문제를 해결할 때 필요한 다양한 컨텍스트를 다룰 수 있음”을 의미한다.
- 팀에서 멀티태스킹을 제거하라
- 인간의 뇌를 멀티태스킹에 적합하지 않다.
- 멀티태스킹은 컨텍스트 스위칭 비용을 초래하여 생산성을 심각하게 저하시킨다.
사일로 조직(Silo)
사일로 조직은 팀끼리 벽을 세우고, 서로 소통하거나 협력하지 않는 조직 형태임 (= 서로 벽을 쌓고 각자 따로 움직이는 조직 구조)
사일로는 원래 농장에서 곡식을 저장하는 거대한 독립 저장탑을 뜻하는데, 조직에서는 부서별로 따로따로 고립되어 있는 모습을 비유함사일로 조직의 특징
- 소통 단절: 부서끼리 정보를 공유하지 않음
- 협업 부족: 다른 팀과 협력하지 않고, 자기 부서일만 함
- 전체 최적화 실패: 부서 최적화만 신경쓰다 보니 회사 전체 목표는 소외됨
- 변화 대응 느림: 부서 간 조율이 어려워 반응이 늦음
사일로 조직의 단점
- 개발팀, QA 팀, 운영팀이 따로따로 일함
- 개발팀은 “개발만 끝내면 나의 일은 끝” 같은 식으로 동작함
- 문제가 생겨도 팀 간 조율이 어렵고, 책임 소재만 따짐
- 결과적으로 고객 가치 전달이 느려지고, 품질도 떨어짐
기술 기반 사일로 조직에서 중간에 위치한 팀은 여러 팀과 소통 및 조정을 해야하기 때문에 과도한 부담을 지게 된다.
이는 팀 간 소통 비용 증가 → 납기 지연 → 품질 저하로 이어진다.
이제 교차 기능팀의 선순환에 대해 알아보자.
비즈니스 역량을 중심으로 구성된 교차 기능팀은 담당하는 서브시스템 아키텍처의 전체 생명주기를 책임진다.
개발한 소프트웨어가 운영 단계에서 어떻게 동작할지까지 고려하며, 운영에 필요한 통찰을 갖고 적극적으로 지원하게 된다. 고객과 사용자로부터 얻는 통찰력은 팀의 비즈니스 역량을 높이는 데 기여한다.
즉, 비즈니스와 개발이 선순환을 이루는 구조를 만든다.
2.4. 안전한 실험 환경
안전한 실험 환경이 각 팀이 마음대로 아키텍처를 선정하거나 기술을 도입해도 된다는 것을 의미하는 것은 아니다.
새로운 것을 맹목적으로 시도하면서 그것을 실험이라고 포장하는 것은 오히려 조직에 큰 위험을 초래할 수 있다.
신중하게 선택된 실험만이 안전한다. 안전한 실험은 아래를 전제로 한다.
- 잠재적으로 큰 학습 결과와 지식을 얻을 수 있는 아이디어를 신중하게 선택한다.
- 예상치 못한 사건이 발생할 수도 있다는 것을 사전에 인지한다.
- 원하지 않은 결과가 나오더라도 팀을 보호할 준비가 되어 있다. 즉, 통제된 위험 속에서 가치있는 학습을 추구하는 것이 바로 안전한 실험이다.
안전한 실험의 진행 방식은 아래와 같다.
- 학습 목적 명확화
- 무엇을 배우고 싶은지 실험의 목적을 명확히 설정
- 사전 리스크 인식
- 실험이 실패할 경우 발생할 수 있는 리스크 미리 분석
- 팀 보호 장치 마련
- 실험 실패로 인한 책임을 개인에게 전가하지 않고 조직 차원에서 학습 기회로 받아들임
- 평가와 검사 진행
- 실험이 진행되는 동안 중간 점검을 수행
- 수집된 정보를 분석하여 실험을 계속할지, 수정할지, 중단할지 결정함
3. 대규모 시스템은 왜 분해되는가: 인지 한계와 모듈 설계의 원리
대규모 시스템이 분해되는 과정은 보통 3가지 단계로 이루어진다.
- 거대한 시스템이 필요하다는 인식
- 초기 설계자들의 인식과 조직 내부 압력으로 대규모 시스템이 요구됨
- 조직 내 소통 구조의 분리
- 경영진은 큰 설계 조직에 특정 요구를 전달하고,
- 이 과정에서 조직 내 의사소통 구조가 자연스럽게 분리됨
- 시스템이 조직 구조를 반영하게 됨
- 동형성의 원칙에 따라 시스템 구조는 설계 조직에서 발생한 의사소통 구조의 분리를 그대로 반영하게 됨
동형성(Homomorphism)의 원칙
동형성은 서로 다른 2개의 구조(시스템과 조직)가 같은 형태를 띄게 되는 현상임
조직이 나뉘어져 있다면, 시스템 구조도 자연스럽게 그 조직의 분리 형태를 반영하게 됨
이는 콘웨이의 법칙의 핵심 메커니즘과 맞닿아 있음
인간은 본능적으로 큰 문제를 작은 문제 집합으로 나누어 다루려고 한다.
작은 문제는 추론하기 쉽고 해결책을 찾기도 쉽다. 여러 개의 작은 문제 해결책이 모여 결국 큰 문제를 해결하게 된다.
이런 본능은 대규모 시스템을 자연스럽게 모듈화하도록 이끈다.
밀러의 법칙에 따르면 사람은 한 번에 약 5~9개 정도의 정보 단위만 기억할 수 있다.
이렇게 사람의 단기 기억에는 한계가 있으므로 복잡한 정보를 다루려면 기억해야 할 항목수를 줄이거나 구조적으로 묶어서 기억해야 한다.
이러한 한계 때문에 우리는 정보를 계층적으로 분해하고 작은 모듈로 나누게 된다.
이 분해 과정은 “적당한 크기”의 덩어리가 될 때까지 계속되는데 적당한 크기란 인지 부하가 심하지 않고, 새로운 정보를 학습할 수 있을만큼 복잡하지 않은 정도를 말한다.
즉, 시스템을 적절히 분해하는 것은 인지 부하를 줄이고, 학습 가능성과 이해도를 높이는 전략이다.
인지 부하(Cognitive Load)
인지 부하는 학습할 때 우리 뇌가 처리해야 하는 정보량을 말함
어떤 정보가 학습되기 위해 들어오는 정보를 처리해야 하는데, 처리할 수 있는 정보의 양보다 학습을 통해 들어오는 정보의 양이 많을 때 문제가 발생하며 이를 인지 부하가 큰 상태라고 말함
모듈은 시스템 설계에서 개념적 경계와 물리적 구획, 두 가지 역할을 한다.
- 개념적 경계
- 문제를 명확하게 나누어 이해하기 쉽게 만듦
- 물리적 구획
- 실제로 소프트웨어 구조에도 경계를 설정함
보험 시스템을 통해 모듈 분해의 예시를 보자.
예를 들어 보험 시스템에서 “보험 계약” 모듈을 개발하는 팀을 생각해보자.
이 팀의 주요 컨텍스트는 보험 계약이지만 계약 모듈을 제대로 설계하려면 상품, 청구, 다른 비즈니스 역량까지도 고려해야 한다.
이 때 팀원은 다음을 명확히 인지해야 한다.
- 자신의 컨텍스트에서 종료되는 지점
- 다른 컨텍스트로 입장하는 지점
- 다시 자신의 컨텍스트로 복귀하는 지점
보험 계약 모듈 안에서도 인수, 처리, 증서와 같은 하위 모듈을 만들 수 있다.
체계적인 분해를 통해 복잡한 문제를 다루기 쉽게 만든다.
작은 모듈을 격상시키는 시점은 언제일까?
인수, 처리, 증서와 같은 하위 모듈을 계약 모듈과 같은 레벨로 격상시켜야 할까?
이 결정은 “아직 충분한 정보가 없다”는 인식이 있을 때는 보류해야 한다.
지금 당장 무리하게 결정하면 무책임한 아키텍처 설계가 되어버릴 수 있다.
시간이 지나면서 소프트웨어 모델의 질서는 자연스럽게 악화된다.
따라서 팀은 대화를 통해 얻는 관찰과 설계를 소프트웨어 모델에 계속 반영해야 한다. 이 때 자연스럽게 모듈의 물리적 구획을 발견하고 정리할 수 있다.
4. 최종 책임 순간까지 결정 미루기: 모놀리스와 마이크로서비스 배포 전략
마이크로서비스를 섣불리 선택하는 것도, 모놀리스를 무조건 장기적으로 고집하는 것도 위험하다.
애자일 기본 정신처럼 배포 방법에 관한 결정도 최종 책임 순간에 이루어져야 한다.
애자일 선언문에는 배포에 관해 2가지 원칙이 있다.
- 가장 높은 우선순위는 가치 있는 소프트웨어의 지속적 전달(CD, Continuous Delivery)을 통해 고객을 만족시키는 것
- 주 단위 또는 월 단위로, 짧은 시간 간격을 두고 소프트웨어를 자주 배포할 것 즉, 빠르고 지속적인 가치 제공이 배포 전략의 핵심이다.
이런 상황에서 어떻게 배포에 대한 결정을 최대한 늦출 수 있을까?
배포에 관련된 의사결정은 ‘결정의 시작 시점이나 빈도’보다는 ‘결정의 유형’을 중심으로 접근해야 한다.
배포 유형(모놀리스, 마이크로서비스)은 선택 사항이지만, 지속적인 전달과 빈번한 배포는 필수 사항이다.
서비스형 기능(FaaS, Function as a Service) 를 포함한 서버리스 아키텍처 배포 유형을 선택했을 때 무엇이 달라질 수 있는지는 추후 다룰 예정입니다. (p. 113)
즉, 무엇을 선택하든 빠르게 전달하고 자주 배포하는 것은 기본 전제이다.
초기에는 빠른 실험과 전달을 지원하는 배포 방식을 선택하는 것이 좋다.
초기에 빠른 실험과 구현이 가능해야 하고, 비즈니스 문제를 깊이 이해하기 전에 분산 컴퓨팅 문제(네트워크 장애, 데이터 일관성 등)를 해결하려 들 필요가 없다.
그래서 초기 아키텍처는 모놀리스가 적합하다.
분산 컴퓨팅의 복잡성을 불필요하게 일찍 맞닥뜨리는 것은 빠른 전달을 방해하고 초기 성공을 지연시킨다.
전달(Delivery) vs 배포(Deploy)
전달은 사용할 준비가 완료된 상태를 의미하고, 배포는 사용할 수 있게 실제 환경에 반영된 상태를 의미함
전달
- 의미: 사용자가 사용할 수 있도록 소프트웨어를 준비 완료한 상태
- 목표: 기능/제품이 출시될 준비가 완료되었음을 보장
- 위치: 개발자/QA/릴리즈 매니저의 관점
- 발생 시점: 코드가 테스트를 통과하고, 제품이 ‘출시할 준비’가 된 시점
- 예시: 앱 스토어에 앱을 제출할 준비가 된 상태
배포
- 의미: 소프트웨어를 운영 환경에 실제로 반영하는 것
- 목표: 기능/제품을 실제 사용자에게 제공
- 위치: 운영팀/DevOps 관점
- 발생 시점: 그 제품이 운영 환경에 실제로 반영되는 시점
- 예시: 앱이 실제로 앱 스토어에 올라가 다운로드 가능해진 순간
전달까지는 완료되었어도, 배포는 전략적으로 따로 관리할 수 있음
예를 들어 새로운 기능을 코드로는 완료했지만, 플래그를 통해 실제로는 배포하지 않을 수도 있음
혹은 특정 국자나 사용자 그룹에만 점진적으로 배포할 수도 있음전달과 배포 시점을 구분하면 ‘출시 시점’을 유연하게 관리할 수 있음
CD(Continuous Delivery) vs Continuous Deployment
CD 는 코드가 항상 프로덕션에 배포할 준비가 도어 있는 상태를 유지하는 것이고, Continuous Deployment 는 코드가 준비되지마자 자동으로 프로덕션에 배포하는 것을 의미함
비즈니스 고객을 만족시키기 위해 소프트웨어를 클라우드로 이전하는 것은 이제 많은 조직에서 필수적인 선택이 되었다.
하지만 단순히 클라우드 시스템으로 옮긴다고 해서 그것이 디지털 트랜스포메이션을 달성하는 것은 아니다.
디지털 트랜스포메이션은 단순한 인프라 전환을 넘어, 비즈니스 모델, 운영 방식, 고객 경험 전반을 디지털 중심으로 재설계하여 경쟁력을 강화하는 것이다.
클라우드로 이전하는 과정에서도 중요한 원칙은 변하지 않는다.
복잡성은 가능한 한 낮게 유지하고, 비즈니스 가치 흐름을 최적화하는 방향으로 설계해야 한다.
즉, 단순한 인프라 이관에서 끝나면 안되고 비즈니스 관점에서 가치를 최적화하고, 동시에 분산 컴퓨팅의 복잡성은 최소화해야 한다.
비즈니스 상황에 맞는 아키텍처를 결정하는 것이 중요하다.
초기에는 규모와 성능 문제가 드물기 때문에 굳이 분산 시스템의 어려움을 감수할 필요가 없다.
나중에 실제로 성능 병목이나 확장성 문제 지표가 나타날 때 그때 가서 모놀리스에서 마이크로서비스로 추출하는 것이 합리적이다.
필요할 때까지 아키텍처 복잡성을 키우지 않는 것이 좋다.
처음부터 모듈을 잘 나누고(개념적 경계 설정), 가장 간단한 배포 방법(보통 모놀리스)을 사용하여 빠르게 전달하고, 이후 성능 지표와 운영 경험을 통해 필요한 시점에 서비스를 분리하고 확장하는 것이 올바른 접근법이다.
최종 책임 순간에 경험 기반으로 결정을 내려야 한다.
아키텍처 결정은 ‘예측’이 아니라 ‘경험’을 기반으로 해야 한다. 빠른 전달과 지속적 배포를 통해 경험을 쌓고, 그 경험을 바탕으로 필요한 순간에 아키텍처를 변경한다.
즉, 빠르게 배포하고, 경험을 쌓고, 필요할 때 시스템을 분해해라.
5. 모듈과 배포, 그 사이
모듈에 대해 고민한 후 배포 방법에 관한 결정을 하기 전에 아래와 같은 작업을 해야 한다.
- 어떤 비즈니스 역량을 시스템의 어떤 부분에 호스팅할 지 파악
- 영향력있는 전략적 기능 파악
- 소프트웨어 개발의 복잡성과 위험성 이해
- 전체 비즈니스 프로세스 이해를 위한 협업
- 모든 것이 정상 동작한다는 것을 증명하기 위한 내용 추론
여기서는 앞의 3개에 대해 다룬다.
뒤의 2개는 추후 다룰 예정입니다. (p. 115)
5.1. 비즈니스 역량(구조)과 비즈니스 프로세스(흐름), 그리고 전략적 목표
비즈니스 역량은 수익 창출을 위해 존재하는 비즈니스 기능을 뜻한다.
비즈니스 역량은 다음 3가지 유형으로 나뉜다.
- 핵심 비즈니스 역량
- 비즈니스 내에서 반드시 뛰어나야 하며, 차별화되어야 하는 역량
- 비즈니스는 이 핵심 역량을 중심으로 혁신해야 함
- 지원 비즈니스 역량
- 혁신 대상은 어니지만 반드시 존재해야 하는 역량
- 별도 솔루션으로 대체할 수 없을 경우에는 자체 구축이 필요함
- 일반 비즈니스 역량
- 핵심 역량과 직접적으로 연결되지 않는 기본 기능
- 가능하다면 외부 솔루션(구매/구독)으로 대체하는 것이 좋음
비즈니스 역량은 “비즈니스가 무엇을 하는가”를 나타낸다. “어떻게 수행하는가”에 대해서는 말하지 않는다.
예를 들어 한 보험 회사에서 “보험 계약 심사”는 비즈니스 역량이다. 이 심사는 우편, 전화, 웹 등의 다양한 방법으로 수행할 수 있다.
- 무엇: 보험 계약 심사
- 어떻게: 우편, 전화, 웹 등 (변경 가능) “무엇”은 시간이 지나도 본질적으로 변하지 않지만, “어떻게”는 기술이나 환경에 따라 변화한다.
비즈니스 프로세스는 비즈니스 역량을 정의하고 연결하는 일련의 활동을 말한다.
비즈니스 프로세스는 “비즈니스가 일을 어떻게 처리하는지”에 관심을 가지며, 프로세스 모델은 작업 순서와 흐름을 명확하게 보여준다.
예를 들어 “청구 비즈니스 영역”은 “청구 요청 확인”과 “청구 요청 처리” 와 같은 프로세스를 포함할 수 있다.
<비즈니스 역량과 비즈니스 프로세스 차이>
| 구분 | 비즈니스 역량 | 비즈니스 프로세스 |
|---|---|---|
| 의미 | 비즈니스가 무엇을 하는지 | 비즈니스가 일을 어떻게 처리하는지 |
| 명명규칙 | 보통 명사-동사 순 예) 구독 계산, 청구 처리 | 보통 동사-명사 순 예) 청구 요청 확인 |
| 초점 | 구조(Structure) | 흐름(Flow) |
| 변화 빈도 | 상대적으로 변하지 않음 | 기술 변화, 규제 변화 등으로 자주 변경됨 |
비즈니스 역량과 비즈니스 프로세스의 구분이 왜 중요할까?
비즈니스 담당자들은 보통 프로세스 중심으로 생각하고 이야기한다. 그러나 소프트웨어 모델링이나 아키텍처 설계예서는 비즈니스 역량을 중심으로 경계를 나눠야 한다. 만약 프로세스 기반으로만 시스템을 설계하면 잘못된 모델 경계를 만들 위험이 있다.
비즈니스 프로세스는 비즈니스 역량을 뒷받침하고, 비즈니스 역량은 전략을 뒷받침한다.
구조(무엇)와 흐름(어떻게)을 명확히 구분하는 것이 견고하고 장기적으로 유지 가능한 시스템을 설계하는 핵심이다.
5.2. 잘못된 기능 개발을 피하는 방법: 임팩트 매핑과 전략적 목표 정렬
소프트웨어 개발에서 흔히 발생하는 문제 중 하나는 비즈니스에 거의 기여하지 않는 기능을 개발하는 것이다.
이 문제는 종종 YAGNI(You Aren’t Gonna Need It) 원칙을 주장하는 주요 이유가 된다.
YAGNI 는 당장 필요하지 않은 기능을 개발하지 말라는 원칙을 말한다.
그렇다면 왜 가치없는 기능을 개발하게 될까?
- 잘못된 소통의 문제
- 소프트웨어 개발자와 비즈니스 관계자 간 협업과 커뮤니케이션 채널이 제대로 구축되지 않은 경우
- 강요된 결정
- 명확한 비즈니스 목표 없이, 개인의 주장이나 집착에 의해 의사결정이 강요된 경우
잘못된 결정을 추적하려 할 때 의사결정 일지가 없으면 당시 관계자만 알고 있는 암묵적 지식의 의존해야 하며, 이유도 모른 채 기존 결정을 그대로 받아들여야 할 수도 있다.
또한 의사결정 일지가 있더라도 잘못된 기능을 시스템에서 효율적으로 제거하는 데는 직접적인 도움이 되지 않는다.
결국 문제를 근본적으로 예방하려면 결정의 동기와 목적을 명확히 하고, 올바른 방향으로 정렬해야 한다.
이러한 문제를 해결하고자 임팩트 매핑(Impact Mapping) 이라는 도구가 등장했다.
임팩트 매핑은 전략적 목표에 정렬된 기능 개발을 돕는 도구로써, 잘못된 기능을 막아준다.
즉, 개발하는 기능이 전략적 목표 달성에 어떤 영향을 미치는지 명확히 검증하는 방법이다.
<임팩트 매핑 4단계 질문>
- 왜(목표)
- 우리가 달성하려는 비즈니스 목표는 무엇인가?
- 누가(행위자)
- 이 목표를 달성하기 위해 행동을 바꿔야 하는 행위자는 누구인가?
- 어떻게(영향)
- 목표를 달성하려면 행위자에게 어떤 영향(impact)을 주어야 하는가?
- 무엇을(결과물)
- 그 영향을 실현하기 위해 필요한 결과물은 무엇인가?
마인드맵은 임팩트 매핑을 실행하기에 좋은 방법이다.
임팩트 매핑의 예시로 보험 시스템을 보자. 
- 왜: 보험 중개사의 신규 가입 증가
- 누가: 보험 중개사
- 어떻게: 더 쉽게 신청서를 제출할 수 있도록 원클릭 신청서 제출 개발
- 무엇을: 원클릭 신청서 제출의 영향으로 산출되는 중개사 고객 계정 조회, 위험 담당자, 보험금 계산
이 과정을 통해 단순한 아이디어인지, 아니면 실제 전략적 목표에 기여하는 기능인지를 구별할 수 있다.
임팩트 매핑을 통해 도출된 영향들은 전략적 영향과 지원적 영향으로 구분할 수 있다.
| 구분 | 설명 | 예시 |
|---|---|---|
| 전략적 영향 | 비즈니스 목표 달성에 직접 연결되는 핵심 영향 | 원클릭 신처어서 제출 |
| 지원적 영향 | 전략적 영향 지원은 하지만 직접 목표에 연결되지는 않는 영향 | 중개사 등록 |
5.3. 의사결정을 위한 시네핀(Cynefin) 프레임워크
시네핀 프레임워크는 의사결정권자가 상황을 인지하고, 자신의 행동과 다른 사람들의 행동을 어떻게 이해할지 돕는 도구이다.
복잡하고 불확실한 환경에서 “지금 내가 처한 상황은 어떤 종류의 문제인가?”, “이 상황에서 어떤 식으로 행동해야 할까?” 를 판단하는데 도움을 준다.
<시네핀 프레임워크의 5가지 영역>
| 영역 | 설명 | 접근법 |
|---|---|---|
| 확실(Clear) | - 원인과 결과가 명확히 연결되어 있는 단순한 문제 - 무엇인지 알고 이해하고 있는 지식 - 누구나 쉽게 인지할 수 있고 예측 가능함 | 감지 → 분류 → 반응 (문제를 감지 → 분류 → 매뉴얼대로 대응) |
| 난해(Complicated) | - 분석이 필요하지만 원인과 결과가 존재하는 문제 - 무엇인지는 알지만 이해하지는 못하고 있는 지식 - 전문가의 조언이나 분석이 필요함 | 감지 → 분석 → 반응 (문제를 감지 → 전문가 분석 → 대응) |
| 복잡(Complex) | - 원인과 결과가 사후에야 명확해지는 문제 - 이해하고는 있지만 존재 자체는 인지하지 못하는 지식 - 실험과 관찰을 통해 점진적으로 이해해야 함 | 탐구 → 감지 → 반응 (실험 → 결과 관찰 → 대응) |
| 혼란(Chaotic) | - 원인과 결과가 존재하지 않는 문제 - 인지하지도 못하고 이해하지도 못하는 완전 미지의 영역 - 즉각적인 대응과 안정화가 필요함 | 행동 → 감지 → 반응 (즉시 행동 → 결과 감지 → 대응) |
| 무질서(Disorder) | - 상황이 어느 영역에 속하는지도 모르는 상태 - 가장 위험하며 빠르게 탈출해야 함 | (상황을 분류해 4개 영역 중 하나로 이동) |
- 확실(Clear)
- 문제화 해결 방법이 모두 명확
- 표준 절차나 매뉴얼을 따라 해결
- 예) 서버 재시작, 장애 시 매뉴얼대로 조치
- 난해(Complicated)
- 분석이 필요하지만 전문가가 답을 찾을 수 있음
- 하나 이상의 올바른 답이 있을 수 있음
- 예) 시스템 성능 저하 분석, 대규모 아키텍처 설계
- 복잡(Complex)
- 사전 예측 불가
- 안전한 실험을 통해 다양한 시도를 하고
- 실패와 성공을 관찰하여 점진적으로 올바른 방향을 찾아야 함
- 예) 새로운 제품 기능 도입, 사용자 반응 분석
- 복잡 영역에서는 예측이 아니라 관찰을 통해 의사결정을 해야함
- 혼란(Chaotic)
- 즉각 조치 없이는 상황이 더 악화됨
- 어떤 행동이든 즉시 시도하고 안정화 필요
- 예) 대규모 시스템 장애, 보안 사고 발생 직후
- 무질서(Disorder)
- 현재 문제가 어떤 유형인지 파악조차 불가능
- 빠르게 분류하고 안정된 영역으로 이동해야 함
- 무질서는 프레임워크의 중심에 존재함
스노든에 따르면 애자일 방식은 복잡 영역에 적합하다. 큰 문제를 작은 문제로 쪼개면서 복잡도를 낮추어서 복잡 영역에서 난해 영역으로 전환시킨다.
즉, 큰 문제를 쪼개면 문제를 더 쉽게 분석하고 대응할 수 있게 된다.
6. 전략적 아키텍처와 아키텍처 결정 기록(ADR, Architecture Decision Records) 의 중요성
소프트웨어 아키텍트는 적절한 시기에 내려지는 의사결정을 문제없이 지원할 수 있도록, 전략적 변화룰 쉽게 반영할 수 있는 유연한 아키텍트를 설계할 수 있어야 한다.
시간이 지나면서 비즈니스 환경과 기술 요구사항은 계속 변하기 마련이다.
따라서 소프트웨어 아키텍트는 “당장의 완벽”이 아니라 “시간을 견디며 유연하게 개선될 수 있는 구조”를 목표로 해야한다.
소프트웨어 아키텍처가 실패하는 가장 심각한 원인은 아래와 같다.
- 상아탑 아키텍처
- 아키텍트가 현실 세계의 제약 사항을 고려하지 않고 개발팀과 동떨어진 상태에서 이론만으로 아키텍처를 설계하는 경우
- 비일관적 의사결정
- 소통없이 그때그때 즉흥적으로 구조를 결정하는 경우
- 일반적 관행 무시
- 검증된 성공 사례와 일반적인 좋은 관행을 무시하고 독단적인 결정을 내리는 경우
소프트웨어 아키텍트는 적절한 시기에 내려지는 의사결정을 문제없이 지원하고자 전략적 변화를 손쉽게 반영할 수 있는 유연한 아키텍처를 설계할 수 있어야 한다.
소프트웨어 아키텍처의 최악의 실패는 아키텍트가 성공 사례로 입증된 일반적 관행에서 벗어나는 아키텍처 결정을 내리고, 현실 세계의 제약 사항에 대한 이해가 없으며(상아탑 아키텍처), 소통 방식을 고려하지 않고 그때그때 구조에 대한 결정을 내리는 것이다.
상아탑(Tower of Ivory)
현실과 단절된 이상적인 공간을 말함
소프트웨어에서는 “현장을 모른 채 책상 앞에서만 만들어낸 비현실적 아키텍처”를 뜻함
전략적 소프트웨어 아키텍처의 핵심 관점은 시간에 따른 개선이다.
- 이 아키텍처가 시간이 지나면서 어떻게 개선되었는가?
- 왜, 어떤 이유로 그렇게 개선되었는가?
아키텍처는 완벽하게 짜는 것이 아니라, 변화 속에서 살아남을 수 있게 기록하고 개선하는 것이다.
새로 합류한 팀원도 과거의 의사결정 이유를 이해할 수 있어야 하고, 과거 결정을 뒷받침하는 컨텍스트(맥락)를 명확히 알 수 있어야 한다.
이를 위해 반드시 필요한 것이 바로 아키텍처 결정 기록(ADR, Architecture Decision Records) 이다.
아키텍처 결정 기록은 각 아키텍처 결정과 그 당시의 컨텍스트 및 결과를 기록하는 문서를 말한다.
아키텍처 결정 기록은 아래와 같은 역할을 한다.
- 아키텍처 결정의 이력과 맥락을 기록
- 팀 내부 커뮤니케이션을 강화
- 신규 팀원이 빠르게 아키텍처를 이해하도록 지원
- 향후 변경 시 과거 결정을 참고하여 더 나은 선택을 가능하게 함
아키텍처 결정 기록은 코드와 함께 저장되며, 모든 팀원이 접근 가능해야 한다.
애자일이라서 문서화는 필요없다는 오해가 종종 있는데 애자일의 본래 취지는 불필요한 문서화는 줄이고, 의미있는 정보를 남기라는 것이다.
기술팀과 비즈니스 이해관계자가 현재 컨텍스트를 올바르게 이해할 수 있도록 돕는 문서는 적극적으로 권장된다.
아키텍처 결정 기록은 그런 의미에서 필수적인 문서화 대상이다.
<아키텍처 결정 기록 양식 예시>
- 제목
- 따로 설명할 필요없이 자명한 결정의 제목
- 상태
- 제안(Proposed), 수락(Accepted), 거부(Rejected), 중단(Deprecated), 대체(Superseded) 등 결정 상태
- 컨텍스트
- 이 결정을 고려하게 된 동기, 배경, 문제 상황 설명
- 결정
- 선택한 해결책과 이유
- 결과
- 이 결정으로 인해 무엇이 쉬워졌고, 무엇이 어려워졌는지 설명
정리하며..
- 의사결정을 내리기에 가장 적절한 시기를 이해해야함
- 안전한 실험과 통제된 실패를 의사결정 도구로 사용
- 비즈니스 역량을 인지하고 모듈화해야 함
- 시네핀과 아키텍처 결정 기록(ADR)과 같은 도구를 사용해서 의사결정에 도움을 주고, 장기적인 추적이 가능하게 해야 함
참고 사이트 & 함께 보면 좋은 사이트
본 포스트는 반 버논, 토마스 야스쿨라 저자의 전략적 모놀리스와 마이크로서비스를 기반으로 스터디하며 정리한 내용들입니다.
