소프트웨어 아키텍처는 어떻게 배워야 할까? - 코드 너머의 설계 감각 기르기

들어가며: '아키텍처'라는 모호한 단어

개발 좀 하다 보면 누군가 "이 시스템 아키텍처가 별로네"라는 말을 합니다. 그런데 막상 "아키텍처가 뭔데요?"라고 물어보면 명확하게 답하기가 쉽지 않거든요. 클래스 다이어그램? 마이크로서비스? 폴더 구조? 다 맞기도 하고 다 틀리기도 합니다. rust-analyzer 같은 대형 오픈소스 프로젝트를 이끌었던 matklad(Aleksey Kladov)가 최근 "소프트웨어 아키텍처를 어떻게 배웠는가"를 정리한 글을 공개했는데요, 코드 잘 짜는 것과 아키텍처를 잘 설계하는 건 다른 근육이라는 점을 짚고 있어서 한 번 깊게 풀어볼 만한 주제예요.

주니어 시절에는 "이 함수가 잘 동작하느냐"가 관심사라면, 시니어로 갈수록 "이 모듈이 다음에 바뀔 때 얼마나 잘 바뀔 수 있느냐", "이 의존성 방향이 5년 뒤에 우리를 괴롭히지 않을까" 같은 질문으로 시야가 옮겨갑니다. 그게 바로 아키텍처를 보는 눈인데, 이건 책을 한 권 읽어서 갑자기 생기는 게 아니라 시간을 들여 길러야 하는 감각에 가까워요.

핵심 내용: 코드를 쓰는 것과 시스템을 설계하는 건 다른 일

matklad가 강조하는 첫 번째 포인트는 아키텍처는 "코드의 모양"이 아니라 "코드가 변화에 어떻게 반응하는가" 라는 점이에요. 다시 말해, UML 다이어그램이 예쁘게 그려진다고 좋은 아키텍처가 아니라, 새 기능을 추가했을 때 한 군데만 고치면 끝나는지, 아니면 열 군데를 고치고도 버그가 터지는지가 진짜 척도라는 거죠. 이게 뭐냐면, 마치 집을 지을 때 "방을 더 늘리려면 벽 한 개만 허물면 되는가"와 비슷한 질문입니다.

그래서 그는 아키텍처를 배우는 방법으로 몇 가지를 제시해요. 첫째, 큰 오픈소스 프로젝트의 역사를 읽어보라는 거예요. 단순히 현재 코드만 보지 말고, git log를 거꾸로 따라가면서 "이 모듈은 왜 이렇게 쪼개졌나", "이 추상화는 어떤 문제를 풀려고 만들어졌나"를 추적하라는 겁니다. rust-analyzer, SQLite, Linux 커널 같은 프로젝트들이 좋은 예고, 특히 큰 리팩토링 커밋의 메시지를 읽으면 설계자의 사고 흐름이 그대로 보이거든요.

둘째, 직접 큰 시스템을 만들어보라고 합니다. 작은 토이 프로젝트는 아키텍처가 필요 없어요. 그냥 main 함수에 다 넣어도 동작하니까요. 하지만 코드가 1만 줄, 10만 줄로 커지면 그때부터 "이 부분이 저 부분을 알아야 하나?", "이 변경은 왜 이렇게 파급이 큰가?" 같은 고민이 자연스럽게 생깁니다. 그 고민을 직접 겪어야 아키텍처가 왜 필요한지 몸으로 알게 된다는 거예요.

셋째, 흥미로운 이야기인데 "아키텍처는 글로 써봐야 는다" 는 점이에요. 코드를 짜는 것과 그 코드의 설계 의도를 글로 설명하는 건 다른 일입니다. 글로 쓰려고 하면 자기가 명확하게 이해하지 못한 부분이 드러나거든요. ADR(Architecture Decision Record)이나 디자인 문서를 쓰는 습관이 그래서 중요합니다.

업계 맥락: 왜 지금 다시 아키텍처 이야기일까

사실 "클린 아키텍처", "DDD", "육각형 아키텍처" 같은 책과 개념들은 이미 많이 있어요. 그런데 matklad의 접근은 좀 달라요. 기존 책들이 "이런 규칙을 따르세요"라는 처방전 형태라면, 그는 "어떻게 배워나가는가"라는 학습 과정에 집중합니다. 이게 중요한 이유는, 규칙만 외워서는 새로운 상황에서 응용이 안 되거든요.

비슷한 흐름으로 최근 몇 년간 John Ousterhout의 "A Philosophy of Software Design"이나 Donella Meadows의 시스템 사고 책들이 다시 주목받고 있어요. 공통점은 "규칙"보다 "감각"을 강조한다는 점입니다. 또한 LLM이 코드를 대량으로 생성하는 시대가 되면서, 인간 개발자가 가져야 할 차별화된 역량으로 "전체 시스템을 설계하는 능력"이 더 중요해졌다는 인식도 깔려 있어요. AI가 함수 단위 코드는 잘 짜지만, 모듈 간의 경계와 책임을 정하는 건 아직 사람의 영역이거든요.

한국 개발자에게 주는 시사점

한국 IT 업계에서는 주니어가 시니어로 성장하는 길에서 자주 막히는 지점이 바로 여기예요. 코드는 잘 짜는데 시스템 설계 회의에 들어가면 할 말이 없는 경우가 많거든요. matklad의 조언을 실무에 적용한다면, 첫째로 사내 레거시 코드의 git history를 거꾸로 따라가 보는 연습을 추천하고 싶어요. 회사에 있는 5년, 10년 된 모듈은 그 자체로 살아있는 아키텍처 교재거든요. "왜 이 클래스가 이렇게 나뉘었지?"라고 의문이 들 때, 그냥 욕하지 말고 커밋 로그를 읽어보면 당시 어떤 제약과 트레이드오프가 있었는지가 보입니다.

둘째로, 자기 프로젝트에서 ADR을 써보세요. 거창할 필요 없이 "왜 이번에 Redis 대신 Postgres를 캐시로 썼는가"를 노션에 한 페이지로 정리해보는 것만으로도 사고가 정리됩니다. 이게 쌓이면 본인만의 설계 라이브러리가 되거든요.

셋째로, 오픈소스 기여를 할 때 한 줄 fix보다는 작은 리팩토링 PR을 추천해요. "이 함수를 별도 모듈로 빼면 어떨까요?" 같은 제안을 만들어보면 메인테이너가 "왜 그게 더 나은지" 토론을 걸어옵니다. 그 대화에서 진짜 아키텍처 감각이 자라요.