# 소프트웨어 아키텍처 배우기 > Clean Markdown view of GeekNews topic #29452. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29452](https://news.hada.io/topic?id=29452) - GeekNews Markdown: [https://news.hada.io/topic/29452.md](https://news.hada.io/topic/29452.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-13T10:06:34+09:00 - Updated: 2026-05-13T10:06:34+09:00 - Original source: [matklad.github.io](https://matklad.github.io/2026/05/12/software-architecture.html) - Points: 10 - Comments: 1 ## Topic Body - **소프트웨어 설계**는 강의보다 실제 프로젝트에서 책임을 맡고 문제가 자기 일이 될 때 더 깊게 배워짐 - **Conway’s Law**는 소프트웨어가 조직의 사회적 구조를 반복한다는 관점이며, 과학 코드와 산업 코드의 차이도 인센티브에서 생길 수 있음 - rust-analyzer는 빠른 빌드, stable 지원, C 의존성 제거, 몇 초짜리 테스트로 **고효율 기여자**가 집중하기 쉽게 만듦 - rust-analyzer는 독립 기능을 `catch_unwind`로 보호하고 PR 기준을 낮췄지만, 핵심 **spine**에는 훨씬 엄격한 품질 기준을 적용함 - 실험적 구조는 장기 현실이 될 수 있으며, rust-analyzer도 LSP 아키텍처 **프로토타입**에서 또 하나의 컴파일러 유지로 이어짐 --- ### 소프트웨어 설계는 실전에서 가장 잘 배움 - **소프트웨어 설계**는 공식 강의보다 실제 프로젝트에서 책임을 맡고 문제를 직접 해결할 때 더 잘 배워짐 - 대학 설계 수업과 코스 프로젝트에서 “아키텍트” 역할을 맡았을 때보다, 두 번째 실전 프로젝트였던 [IntelliJ Rust](https://github.com/intellij-rust/intellij-rust)에서 설계 문제가 자기 일이 되면서 학습이 본격화됨 - IntelliJ Rust에서는 몇 가지 실수가 있었지만 치명적이지 않았고, 그 과정에서 많은 것을 배울 수 있었음 - **소프트웨어 엔지니어링**은 호기심 있는 사람이 원리부터 생각하고 여러 글을 읽으며 익힐 수 있을 만큼 단순한 면도 있음 ### 인센티브 구조와 Conway’s Law - **[Conway’s Law](https://en.wikipedia.org/wiki/Conway%27s_law)** 는 소프트웨어가 그것을 만드는 조직의 사회적 구조를 반복한다는 관점임 - 산업용 소프트웨어와 과학 코드의 차이는 소프트웨어 구축 지식 자체보다, 사람들에게 소프트웨어를 만들게 하는 **인센티브 구조**에서 비롯될 수 있음 - “3개월 안에 논문을 내야 하는 PhD” 같은 상황은 과학 코드의 형태를 좌우하는 중요한 요인이 될 수 있음 - 인센티브 구조에는 크게 두 가지 방식으로 대응 가능함 - ## 프로젝트의 인센티브를 설계하거나 움직이기 - 프로젝트의 **인센티브 구조**를 설계하거나 조정할 기회는 드물지만, 그런 기회가 생기면 영향이 커짐 - [TIGER_STYLE](https://github.com/tigerbeetle/tigerbeetle/blob/0.17.4/docs/TIGER_STYLE.md)의 핵심은 규칙 목록 자체가 아니라, 그 규칙들이 좋은 선택이 되도록 만드는 **사회적 맥락**에 있음 - ## 바꿀 수 없다면 제약에 적응하기 - 인센티브 구조는 원하는 대로 주어지는 경우가 거의 없으며, 바꿀 수 없다면 그 구조에 맞춰 적응해야 함 - 산업 소프트웨어 프로젝트에서도 “제대로 할 시간”은 거의 없고, 주어진 제약 안에서 가능한 최선을 해야 함 ### rust-analyzer에서 구조와 참여자를 맞춘 방식 - [rust-analyzer](https://github.com/rust-lang/rust-analyzer)는 깊이와 폭을 모두 가진 프로젝트임 - **깊은 측면**에서는 컴파일러라는 성격 덕분에 뛰어나고 헌신적인 기여자를 끌어들일 수 있음 - **넓은 측면**에서는 고전적인 IDE가 목적별 특수 기능을 많이 갖고 있어, Rust를 배우는 사람이나 꾸준히 참여하기 어려운 주말 기여자가 자신의 불편을 해결하려고 한두 시간을 쓰기에 적합함 - rust-analyzer가 `rustc` 빌드를 요구하지 않고, stable에서 빌드되며, C 의존성이 없고, 전체 테스트 스위트가 몇 초 안에 끝나도록 고집한 이유는 **고효율 기여자**를 끌어들이기 위해서였음 - 빌드 시스템을 다듬어 사람들이 다른 것을 신경 쓰지 않고 borrow checker 작업에 집중할 수 있게 하려 했음 - 주말 기여자를 끌어들이기 위해 rust-analyzer 내부는 여러 **독립 기능**으로 나뉘었고, 각 기능은 런타임에서 `catch_unwind`로 보호됨 - 기능 PR의 기준은 “해피 패스가 동작하고 테스트가 있음”으로 낮췄고, 해당 코드가 크래시하더라도 받아들일 수 있다고 봄 - 다만 두 조건이 필요했음 - 품질 문제가 **개별 기능** 안에 격리되고 다른 부분으로 번지지 않아야 함 - 런타임 크래시는 사용자에게 보이지 않아야 하며, 이를 위해 rust-analyzer 기능은 **불변 스냅샷**으로 동작하고 데이터를 오염시키지 못해야 함 - 반대로 기능을 떠받치는 핵심 **spine**에는 훨씬 엄격한 품질 기준을 적용함 ### 실험적 구조가 장기 현실이 되는 위험 - 인센티브 구조를 고치기보다 적응할 때는 미래가 불확실하고, 대개 가장 불편한 방식으로 현실화될 수 있음을 조심해야 함 - rust-analyzer의 원래 동기는 IntelliJ Rust 안에 병렬 컴파일러를 하나 더 작성하는 일을 피하고, LSP를 위한 더 나은 아키텍처를 **프로토타입**으로 검증해 그 배움을 `rustc`로 되돌리는 것이었음 - 그래서 핵심부까지 포함해 코드가 매우 **실험적**이었음 - 결과적으로 또 하나의 컴파일러를 유지하게 됨 - 비슷하게 uutils 프로젝트도 Rust를 배우는 사람들의 주요 목적지로 시작해 Ubuntu의 coreutils 구현체가 됨 ### 참고할 만한 자료와 책 - **정답이 담긴 단일 책**은 없으며, 실전이 필수 요소로 보임 - [Boundaries](https://www.destroyallsoftware.com/talks/boundaries) by Gary Bernhardt - 구체적인 조언이 탄탄하고, 더 상위 수준의 탐구를 촉발한 자료임 - [How to Test](https://matklad.github.io/2021/05/31/how-to-test.html) - 테스트의 중요성은 바로 이해했지만, 널리 인용되는 많은 테스트 조언이 실질적이지 않다는 점을 인정하고 실제로 작동하는 방식을 개념화하기까지 오래 걸렸음 - [∅MQ guide](https://zguide.zeromq.org/docs/chapter6/)와 [Pieter Hintjens의 글](http://hintjens.com) - Conway’s Law식 사고를 접하게 해준 자료임 - rust-analyzer의 기능 개발 아키텍처는 [optimistic merging](http://hintjens.com/blog:106)을 적용한 형태임 - [Reflections on a decade of coding](https://www.scattered-thoughts.net/writing/reflections-on-a-decade-of-coding/) by Jamii - 매우 메타적인 내용을 다루며, [링크 모음](https://matklad.github.io/links.html)의 첫 번째 항목으로 둘 만큼 훌륭함 - [Ted Kaminski](https://www.tedinski.com/archive/) 블로그 - 존재하지 않는 책을 위한 노트라는 형식으로, 소프트웨어 개발에 대한 일관된 이론에 가장 가까움 - [Software Engineering at Google](https://abseil.io/resources/swe-book)과 Ousterhout의 *The Philosophy of Software Design* - 자주 추천되는 좋은 책들이며, 특히 Software Engineering at Google은 [unit test와 integration test에 관한 중요한 이름들](https://matklad.github.io/2022/07/04/unit-and-integration-tests.html)을 정리하는 데 도움이 됐음 - 다만 개인적으로는 획기적인 책은 아니었음 ## Comments ### Comment 57366 - Author: neo - Created: 2026-05-13T10:06:35+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48106024) - 치트시트로 요약하면, 좋은 설계는 하나의 아이디어가 전체에 스며들어 있고 **놀라움을 최소화**하는 방향이어야 함 시스템이 허용하면 사람들은 결국 그렇게 쓰고, “모두가 그냥 X만 해주면”으로 시작하는 해법은 해법이 아님 데이터를 변환하는 부분과 사용하는 부분을 분리하고, 데이터 모델은 코드보다 오래가며, 결합도는 많은 문제의 뿌리임 버전 관리는 피할 수 없고, 상태는 명시적으로 드러내야 하며, 정보마다 단일 진실 공급원이 있어야 함 이름 짓기에 더 많은 시간을 쓰고, 테스트가 어렵다면 설계가 잘못된 것이며, 문서화하지 않은 결정은 후회하게 됨 커뮤니케이션은 비용이므로 지불하기 전에 정당화해야 하고, 엔지니어의 일은 불완전한 정보 속에서 경험칙으로 문제를 푸는 것임 - 이 내용 대부분은 실제로 **소프트웨어 아키텍처**와는 크게 관련 없어 보이고, “시스템의 일부를 격리하라” 정도만 해당될 수 있음 글 자체도 소프트웨어 아키텍처 관점에서는 그리 일관적이지 않았음 4+1 아키텍처 뷰는 UML을 빼면 큰 그림을 생각하는 좋은 개념적 틀이고, Pattern-Oriented Software Architecture 시리즈도 사람들이 도달하는 여러 아키텍처를 잘 정리함 Grady Booch가 소프트웨어 아키텍처 핸드북을 만들던 적도 있는데 지금은 거의 멈춘 듯하고, 당시 메일링 리스트에서 회사나 대형 오픈소스 프로젝트의 큰 시스템 아키텍처를 기록하곤 했음 이런 자료들을 파고들면 규모, 안전성, 성능, 상호운용성, 페일세이프 같은 서로 다른 초점에 맞춰 아키텍처가 만들어지고, 각 목표에는 현실적인 트레이드오프가 있다는 걸 볼 수 있음 - 전부 동의하진 않지만 몇 가지를 더하자면, 소프트웨어의 1차 목표는 **눈앞의 문제 해결**이고 2차 목표는 가능성 높은 미래 문제를 최소 노력으로 해결하는 것임 이 기준에서 더 낫다면 나쁜 설계처럼 보여도 실제로는 좋은 설계임 인터페이스는 올바르게 쓰기 쉽고 잘못 쓰기 어렵게 만들고, 프로젝트를 모르는 사람이 어떻게 사용할지 생각해야 함 올바른 코드는 쓰기 쉬워야 하고 수상한 코드는 눈에 띄어야 하며, 버그는 가능한 한 왼쪽으로 옮겨야 함 하나의 버그를 고치는 것보다 **버그 부류**를 없애는 편이 낫고, 인터페이스는 구현보다 바꾸기 어려우므로 올바른 인터페이스라면 못생긴 구현도 괜찮음 주석과 문서는 코드가 왜 그런 형태인지 설명해야 하고, 겉보기엔 더 단순한 방법이 있어도 어떤 제약 때문에 안 된다면 그것을 남겨야 함 데이터 관점에서는 반복하지 말아야 하며, 같은 사실을 여러 곳에 저장하면 결국 어긋나고 버그가 생김 잘 닦인 길에서 벗어나는 데는 비용이 있고, 정말 가치 있을 때는 그래도 되지만 그 비용을 과소평가하면 안 됨 더 나쁜 듯 보이는 지루한 기술이 더 나은 기술일 때가 많고, “할 가치가 있나?”가 아니라 “다른 일을 하는 것과 비교해 할 가치가 있나?”로 기대값을 따져야 함 자신이 남들보다 똑똑하다고 생각해도 지능만으로 충분하지 않은 문제가 있으며, 어떤 문제는 실제로 터지기 전까지 발견할 수 없으니 남들의 실수에서 배워야 함 마찰은 조용한 살인자임 - **데이터 마이그레이션**은 필연적이므로 미리 계획해야 하고, 이는 버전 관리의 귀결임 계획은 좋지만 때로는 직접 시도해봐야 하며, 모든 것은 돈이 듦 비용을 고려하지 않고 설계하면 나중에 어려운 선택을 강요받게 됨 - 1년 넘게 비디오 게임을 만들면서, 지속 가능한 엔진과 분리된 **데이터 파이프라인**, 완전히 분리된 리소스 렌더링/관리 계층, 명시적인 상태 변환 방식을 구축하고 있는데 이 목록 대부분이 그대로 적용됨 혼자 만드는 프로젝트라도 엔진의 제약이 “테스트 중 튀어나온 이상한 새 기능을 이런 방식으로 추가하라”는 길잡이가 되어 줌 “특정 상태 변환에서 여러 번 실행되는 새 사운드 효과를 만들려면 이렇게 하라” 같은 방대한 문서를 매번 들고 있을 필요가 없어짐 - 이 분야에서 일하고 있고, 우리 쪽은 의료 산업을 모델링하기 때문에 다른 분야보다 덜 추상적임 시스템 설계자는 산업을 이해해야 하며, 그들의 용어와 모델링 습관을 완전히 받아들일 필요는 없지만 데이터셋을 바라보는 이유와 관점은 알아야 함 의료 시장의 복잡성을 의도적으로 단순화해 불필요한 과잉 정의를 없애고 더 통합된 모델을 제공한 부분도 있지만, 그런 변경은 문제 영역을 충분히 이해했기 때문에 자신 있게 할 수 있었음 특히 **이름은 거의 죽지 않음** 가끔 죽기도 하지만 이름을 바꾸려면 극단적인 노력이 필요하므로, 도메인 전문가들이 명명안을 오래 검토하게 해서 빠진 부분이 없는지 확인하는 데 큰 시간을 쓰는 것이 정말 가치 있음 몇몇 개념은 밀어붙일 수 있어도 영업·마케팅 같은 비즈니스 쪽은 계속 업계 용어를 요구하며 모델을 현재 산업 관점에 맞추라고 압박함 그 흐름을 깨기로 했다면 그 단절은 의도와 목적이 분명해야 함 소프트웨어에서 가장 강조해야 할 속성은 **유지보수성**임 만드는 데 얼마가 드느냐도 질문이지만, 운영하는 데 드는 비용은 인프라뿐 아니라 누적되는 기능 요청, 코드 리팩터링, 서드파티 소프트웨어 버전 유지까지 포함하므로 훨씬 더 큰 영향을 줌 - 추천 목록은 Ousterhout의 A Philosophy of Software Design처럼 좋은 경우가 많지만, 대체로 소프트웨어 아키텍처 자체보다는 **소프트웨어 개발 일반론**에 가까움 아키텍처를 보려면 Shaw/Garlan의 Software Architecture: Perspectives on an Emerging Discipline 같은 고전과 Mary Shaw의 글을 권함 소프트웨어 아키텍처 분야가 왜 예상대로 흘러가지 않았는지 탐구한 Myths and Mythconceptions: What Does It Mean to Be a Programming Language, Anyhow?나 Revisiting Abstractions for Software Architecture and Tools to Support Them 같은 최근 논문도 좋음 실용적으로는 Unix 파이프와 필터, REST가 왜 성공했고 어디서 왜 무너지는지 보면 좋고, **헥사고날 아키텍처**도 핵심임 개인적으로는 소프트웨어 아키텍처와 메타객체 프로토콜을 연결해 프로그래밍 언어와 프로그래밍의 새 기반으로 보려는 Beyond Procedure Calls as Component Glue: Connectors Deserve Metaclass Status도 있음 Mary Shaw의 Procedure Calls Are the Assembly Language of Software Interconnection: Connectors Deserve First-Class Status에 대한 답으로, 절차 호출이 어셈블리어라면 고수준 언어는 어떤 모습일지를 묻는 작업임 어쩌면 소프트웨어 아키텍처에는 더 밝고 실용적인 미래가 있을지도 모름 - **헥사고날 아키텍처**가 뭔가? - “절차 호출이 어셈블리어라면 고수준 언어는 어떤 모습일까?”라는 질문은 프로그래밍 언어 이론과 소프트웨어 공학 도구에 밝지는 않지만, 람다 대수, LISP, APL, Clojure, TCL 같은 것들의 기본 개념 아닌가 싶음 몇 가지 자료구조와 타입, 작은 기본 함수 모음만 있으면 그것들을 조합하면 됨 Lisp에서 좋아하는 점 하나는 더 복잡한 타입, 특히 FFI에서 온 타입이 항상 불투명하다는 것임 C 비슷한 언어에서 구조체를 정의하면 표준 함수 모음을 얻게 되는 **CLOS 구현**을 보고 싶음 - 아키텍처를 배우는 가장 좋은 방법은 충분히 큰 프로젝트를 만드는 것이 아니라 **유지보수**하는 것임 그것도 적어도 두세 개 프로젝트에서 해야 함 프로젝트가 너무 작으면 어떤 아키텍처도 잘 동작하고, “큰” 프로젝트는 코드 줄 수보다 그동안 작업한 사람 수, 더 좋게는 팀 수로 판단하는 편이 나음 서로 다른 프로젝트가 적어도 두 개는 있어야 비교가 가능하고, 한 프로젝트에 수십 년 갇혀 현대적인 문제 해결 방식을 모르는 사람들도 봤음 하지만 실제로는 프로젝트를 만든 사람이 승진해 아키텍트가 되는 경우가 많고, 유지보수한 사람이 되는 경우는 드묾 Google에서는 특히 새로 출시해야 승진하고, 유지보수로는 승진하지 않으며 가능하면 출시 직후 빠져나가는 편이 유리해서 더 뚜렷함 역설적으로 아키텍트가 되기에 가장 좋은 위치에 있는 사람은 회사 내부에서 아무도 맡기 싫어하는 기존 프로젝트 유지보수에 투입되는 외부 계약자일 수 있음 이들은 아키텍처를 유지해야 하고 여러 프로젝트를 거치므로 비교할 수 있음 다만 시간 단위로 청구한다면 더 많은 시간을 청구하려고 아키텍처를 과도하게 복잡하게 만들 위험이 있음 - 이런 맥락에서는 **Architecture of Open Source Applications**를 정말 추천함 각 장을 해당 프로젝트의 유지보수자가 쓴 책 시리즈라서, 예제로 아키텍처를 배울 수 있음 아키텍처가 무엇인지뿐 아니라 그것을 만든 제약, 보통은 역사와 바뀌는 프로젝트 비전까지 알 수 있음 여러 저자가 쓴 책의 한계 때문에 모든 장이 똑같이 좋거나 흥미롭지는 않고 모두 오래되었지만, 그래도 읽을 가치가 있음 [http://aosabook.org/]() - 작업하는 프로젝트의 **정신 모델**을 더 잘 얻는 데 시간을 쓰고 싶지만, 프로그래밍 언어나 특정 아키텍처 선택, 시간 쓸 가치가 없어 보일 만큼 복잡해진 부분이 싫어지기 시작하면 의욕이 크게 떨어짐 프로젝트에 따라 다르지만 “풀스택 개발자”로 일하는 건 프로그래밍의 재미를 없애는 느낌임 이미 일주일에 40시간을 상상 가능한 가장 따분한 프로젝트를 보며 보내고 있음 - 그냥 내려놓는 게 좋음 흠 없는 프로젝트는 단 하나도 없음 그리고 프로그래밍 언어가 그렇게 큰 문제라면 배를 갈아타는 편이 낫다 모두가 여러 언어를 다룰 수 있어야 한다고 보지만, 결국 선택은 본인 몫임 - **분석 마비**는 항상 위험하니 완벽함이 아니라 유연함을 목표로 해야 함 가장 많은 시간을 쓰는 결정이 가장 중요한 결정인지 확인해야 함 잘 설계된 자료구조는 프레임워크, 언어, 플랫폼보다 성능과 유지보수성에 훨씬 더 큰 영향을 줌 개인적으로는 매일 ADHD와 함께 일하기 때문에 진전이 일어나도록 계속 밀어붙여야 하고, 이는 중요하지 않은 결정을 골라 끝내면서 신중한 사고가 필요한 남은 문제 공간에 집중한다는 뜻임 - 감정 조절을 더 잘해야 하는 상황처럼 들림 - “클린 코드”나 “아름다운 코드” 같은 말은 주니어가 소프트웨어 아키텍처 모범 사례를 배우는 데 별로 도움이 안 됨 주니어가 왜 ORM을 쓰냐고 물었을 때 시니어가 “더 깔끔해서”라고 답하면 남는 건 물음표뿐임 차라리 명확한 목표 목록을 정의하는 편이 좋음 유지보수 가능성, 성능과 확장성, 효율성, 회복탄력성, 관측 가능성, 테스트 가능성과 테스트됨, 보안성, 새 개발자가 읽기 쉬움 같은 기준이 서로 균형을 이룸 기준을 더할수록 망설일 때 더 나은 선택을 하기 쉽고, 개발팀 바깥 사람에게도 의미가 있어 고객과 무엇에 돈을 내는지 합의할 수 있음 프로젝트는 생애 대부분을 유지보수 모드로 보내고, 이는 프로젝트가 성공했다는 좋은 뜻이므로 **유지보수 가능성**도 정의할 수 있음 새 기능을 아키텍처를 깨지 않고, 더 나아가 단일 메서드 시그니처도 깨지 않고 넣을 수 있는 능력이 좋은 출발점임 추상화에는 매우 조심해야 함 “추상화는 원하는 것이 얼마나 단순한지 숨기는 경우가 많다”는 말이 맞고, ORM이 딱 그런 대상임 대부분의 경우 데이터는 1급 시민으로 다뤄야 하며, DBA와의 협업도 좋아짐 성급한 최적화에 빠지지 않으면서 행복 경로 밖을 생각하는 것도 도전이고, 장단점을 보지 않은 채 좋은 아이디어 구현에 돌진하는 일을 막아줌 내 코드를 다룰 사람이 아주 나쁜 하루를 보냈다고 상상하면, 읽기 즐겁게 만드는 데 도움이 됨 곳곳의 주석, 생략 가능해도 두는 지역 변수, 변수 이름 같은 것들이 여기에 해당함 프레임워크는 신중히 골라야 하며, 좋은 하인이지만 나쁜 주인임 “프레임워커가 아니라 엔지니어가 되라”는 글의 표현이 맞음 - “강하게 의견을 내는 프레임워크”와 비교하면 **모듈형 프레임워크**는 금값을 함 강한 의견 자체가 싫지는 않고, 라이브러리나 도구에는 오히려 훌륭한 특성일 수 있음 해당 라이브러리나 도구는 자기 영역에 대한 많은 도메인 전문성을 갖고 있을 가능성이 큼 하지만 프레임워크에서는 강한 의견이 “망치를 들었으니 모든 게 못으로 보인다”로 변질되기 쉬움 항상 그러거나 항상 문제가 되는 건 아니지만, 한 도메인의 정통 교리를 넓게 적용하면 그 정당화가 도메인 특화였는데 더 넓은 맥락에서는 깨질 위험이 있음 그래서 프레임워크는 다른 ORM이나 영속성 통합 계층을 꽂을 수 있고, 라우터·검증기·문제에 맞지 않는 다른 구성요소를 교체할 수 있는 모듈성을 선호함 프레임워크 생태계 안에 여러 패러다임의 대안이 있으면 특히 가치가 큼 거의 맞는 기성 도구를 찾고, 단점이 분명하며 필요할 때 보완 가능한 선택지를 고를 수 있기 때문임 유지보수성을 위해서는 NIH 증후군과 싸우는 것이 매우 중요함 이것은 자원을 놀라운 속도로 빨아들이는 지속적인 위험임 동시에 일부 구성요소는 직접 조정하거나 완전히 소유할 때 큰 이익을 얻을 수도 있으며, 어려운 부분은 무엇이 어느 쪽인지 판단하는 일임 유지보수성을 목록 맨 앞에 둔 점에 깊이 공감함 - 시스템 공학 관점에서 소프트웨어 아키텍처는 **배관 설계**와 비슷함 매우 중요하지만 사람은 배관 안에 사는 게 아니라 배관이 있는 집에 살고 있음 배관이 집의 나머지 부분을 고려하지 않으면 고치는 데 비용이 엄청나게 들 수 있음 - 좋은 글임 “소프트웨어 아키텍처를 배운다”는 것은 단 하나의 정답이 없다는 걸 이해하는 일임 이것은 예술이자 과학임 읽을거리로는 Simplify IT - The art and science towards simpler IT solution을 추천함 [https://nocomplexity.com/documents/reports/SimplifyIT.pdf]() - **Gary Bernhardt 강연**은 정말 특별함 다른 흥미로운 곳으로 이어질 개념이 많이 담겨 있음