소프트웨어 아키텍처는 책보다 인센티브와 제약에서 배운다는 이야기

• matklad의 첫 결론은 꽤 현실적임. 소프트웨어 아키텍처는 책으로만 배우기 어렵고, 결국 직접 책임지고 만들어봐야 는다

  • 대학의 설계 수업도 들었지만 실제로는 “소방관 놀이하는 유치원생”에 가까웠다고 표현함
  • 본인을 진짜로 성장시킨 건 IntelliJ Rust에서 소프트웨어 리더십을 맡게 된 커리어상의 우연이었다고 함
  • 좋은 소식은, 호기심 있는 사람이라면 1원칙과 블로그 글들만으로도 꽤 멀리 갈 수 있다는 것

• 나쁜 소식은 Conway의 법칙임. 코드는 조직 구조와 인센티브를 꽤 정직하게 닮음

  • 글에서 인용한 문장은 “우리는 프로그래밍을 코드 작성처럼 말하지만, 코드는 아키텍처보다 덜 중요하고, 아키텍처는 사회적 문제보다 덜 중요하다”는 쪽에 가까움
  • 과학 코드가 산업 코드와 다른 이유도 단순히 개발 지식 부족 때문만은 아니라고 봄
  • “3개월 안에 논문을 내야 하는 박사과정” 같은 인센티브가 코드 품질을 크게 설명할 수 있다는 얘기임

• 그래서 설계자는 코드 구조만 볼 게 아니라 인센티브 구조도 봐야 함

  • 가끔은 프로젝트의 인센티브를 설계하거나 살짝 밀어볼 기회가 생기는데, 그때의 영향력이 엄청 크다고 함
  • TIGER_STYLE도 규칙 목록 자체보다, 그 규칙이 말이 되는 사회적 맥락이 핵심이라고 해석함
  • 하지만 대부분의 프로젝트에서는 인센티브가 마음에 들지 않더라도 바꾸기 어렵고, 결국 제약 안에서 최선을 찾아야 함

• rust-analyzer 사례가 이 글의 진짜 본론에 가까움

  • 프로젝트의 물리적 현실은 “깊고 넓다”였음
  • 깊다는 건 컴파일러라는 뜻이고, 넓다는 건 전통적인 IDE처럼 목적별 기능이 엄청 많다는 뜻임
  • 깊은 컴파일러 코어는 소수의 뛰어난 장기 기여자를 끌어들일 수 있음
  • 반면 자잘한 IDE 기능은 Rust를 배우는 사람들이 주말에 한두 시간 들여 자기 불편을 고치는 기여와 잘 맞음

• matklad가 rust-analyzer의 빌드 환경에 집착한 이유도 여기서 나옴

  • rustc를 빌드하지 않아도 되고, stable Rust에서 빌드되고, C 의존성이 없고, 전체 테스트가 몇 초 만에 끝나야 한다고 봄
  • 이건 단순한 개발자 경험 개선이 아니라 고임팩트 기여자를 끌어오기 위한 아키텍처적 선택이었음
  • 누군가 borrow checker 쪽을 고치려는데 빌드 시스템부터 씨름하게 만들면, 좋은 기여가 시작되기도 전에 꺾일 수 있다는 판단임

• rust-analyzer는 기능 영역과 코어 영역의 품질 기준도 다르게 잡음

  • 많은 독립 기능은 런타임에서 catch_unwind로 감싸서 기능별 실패가 전체 시스템으로 번지지 않게 함
  • 이런 기능 PR의 기준은 “happy path가 동작하고 테스트가 있다” 정도로 낮게 잡았다고 함
  • 대신 품질 문제는 기능 안에 격리되어야 하고, 사용자가 보는 런타임에서는 크래시가 보이지 않아야 함
  • 반대로 여러 기능을 떠받치는 core spine에서는 훨씬 더 깐깐하게 품질을 봤음

• 흥미로운 경고도 있음. 인센티브에 적응해서 만든 구조가 나중에 다른 미래를 맞을 수 있다는 것

  • rust-analyzer의 원래 동기 중 하나는 IntelliJ Rust 안에 별도 컴파일러를 또 쓰지 않기 위한 실험이었음
  • 더 나은 LSP 아키텍처를 프로토타입하고, 배운 내용을 rustc로 되돌리는 목표도 있었다고 함
  • 그런데 결과적으로는 “컴파일러가 하나 더 생긴 셈”이 됐다고 농담함
  • uutils도 Rust 학습자들의 목적지로 시작했다가 Ubuntu coreutils 구현체가 된 비슷한 사례로 언급됨

• 추천 자료 쪽에서도 “정답 책 하나”는 없다고 선을 그음

  • Gary Bernhardt의 Boundaries talk는 객체 수준 조언도 좋고, 메타 질문을 촉발한 자료라고 함
  • How to Test는 널리 인용되는 테스트 조언 중 상당수가 주술에 가깝다는 걸 인정하게 해준 자료로 언급함
  • Pieter Hintjens와 ZeroMQ 가이드는 Conway의 법칙식 사고를 배우는 데 도움이 됐다고 함
  • Software Engineering at Google과 Ousterhout의 The Philosophy of Software Design은 좋지만, 본인에게 완전히 판을 바꾼 책은 아니었다고 평가함

• 이 글이 특히 연구 코드나 사내 툴을 만지는 개발자에게 찔리는 이유는 명확함

  • “제대로 만들 시간이 없었다”는 말은 거의 모든 산업 프로젝트에도 해당함
  • 중요한 건 이상적인 아키텍처를 상상하는 게 아니라, 지금 프로젝트의 시간·기여자·빌드 비용·테스트 비용 안에서 무엇을 격리하고 무엇을 엄격히 볼지 정하는 것임
  • 결국 좋은 설계는 멋진 다이어그램보다 실패가 번지는 경로를 줄이고, 좋은 기여가 들어오는 경로를 짧게 만드는 쪽에 가까움

---

기술 맥락

• rust-analyzer 설계에서 중요한 건 모든 코드에 같은 기준을 적용하지 않았다는 점이에요. 컴파일러 코어처럼 여러 기능이 의존하는 부분은 엄격하게 보고, 독립 IDE 기능은 기여 장벽을 낮췄어요. 프로젝트의 깊이와 넓이가 다르니 품질 정책도 달라야 했던 거예요.

• 빌드가 빠르고 의존성이 적어야 한다는 조건은 단순 편의가 아니에요. 오픈소스에서는 기여자가 관심을 가진 순간에 바로 고칠 수 있어야 하거든요. rustc 빌드나 C 의존성 때문에 첫 실행부터 막히면, 잠재적인 좋은 기여가 사라져요.

• catch_unwind로 기능 실패를 격리한 것도 인센티브 설계예요. 작은 기능은 많은 사람이 쉽게 넣게 하되, 그 기능이 터져도 전체 언어 서버 상태를 망치지 않게 만든 거죠. 낮은 품질 기준을 허용하려면 그만큼 격리 경계가 선명해야 해요.

• 이 관점은 회사 코드에도 그대로 적용돼요. 모든 모듈을 최고 품질로 만들 수 없다면, 어디가 시스템의 척추이고 어디가 실험 가능한 잎사귀인지 먼저 나눠야 해요. 그 구분 없이 “클린하게 합시다”만 외치면 실제 제약을 못 이겨요.