설계와 가치

소프트웨어 아키텍처라는 말, 좀 거창하게 들리잖아. 설계랑 아키텍처가 뭐가 다른 건지부터 따져보고, 왜 우리가 아키텍처에 목숨을 걸어야 하는지를 이야기해볼 거야.

설계(Design)와 아키텍처(Architecture) 는 사실 같은 거야. 아무 차이 없어. 흔히 아키텍처는 고수준 구조, 설계는 저수준 세부사항이라고 구분하는데, 밥 아저씨는 이 구분이 무의미하다고 봐. 저수준의 세부사항과 고수준의 구조는 하나의 연속체를 이루고 있거든. 건물로 치면 아키텍처가 건물의 형태, 공간 배치 같은 거고 설계가 콘센트 위치, 보일러 배관 같은 건데, 실제로 건물을 지을 때 이걸 분리해서 생각하는 게 불가능하지. 소프트웨어도 마찬가지야.

그럼 좋은 설계의 목표가 뭐냐. 답은 명쾌해 -- 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 거야. 설계 품질의 척도는 단순하지. 고객의 요구를 만족시키는 데 드는 비용이 얼마냐는 것. 비용이 낮고 시스템의 수명 내내 낮게 유지되면 좋은 설계, 릴리스할 때마다 비용이 올라가면 나쁜 설계야.

저자가 실제 사례를 보여주는데, 릴리스마다 엔지니어 수는 계속 늘어나는데 코드 한 줄당 비용이 폭등하는 그래프가 나와. 초기에는 적은 인력으로 빠르게 만들었는데, 시간이 갈수록 같은 기능을 추가하는 데 더 많은 사람이 필요해지는 상황. 이게 엉망진창이 되어가는 신호야. 개발자들이 "빨리 가려고" 엉성한 코드를 짜는데, 실제로는 그게 느려지는 원인이 되거든. 토끼와 거북이 우화처럼 -- 빠르고 지저분하게 가면 결국 느려지고, 느리더라도 꾸준하고 깨끗하게 가는 쪽이 이기지.

이제 소프트웨어 시스템이 이해관계자에게 제공하는 두 가지 가치를 봐야 해. 행위(Behavior)와 구조(Structure). 개발자는 둘 다 책임져야 하는데, 대부분 하나에만 집중하다가 망해.

행위 가치는 소프트웨어가 요구사항대로 동작하는 거야. 이해관계자가 "이렇게 동작해야 해"라고 말하면 개발자가 코드를 짜서 그렇게 돌아가게 만드는 거지. 많은 개발자가 자기 일이 여기서 끝난다고 생각해. 요구사항을 코드로 옮기고, 버그 나오면 고치고. 하지만 이건 반쪽짜리 일이야.

아키텍처 가치는 소프트웨어가 "부드러운(soft)" 상태를 유지하는 거야. 소프트웨어(Software)라는 단어 자체가 "부드러운 제품"이라는 뜻이잖아. 하드웨어와 대비되는 개념 -- 쉽게 변경할 수 있어야 하니까 "소프트"인 거지. 변경하기 어려운 소프트웨어는 소프트웨어라는 이름이 무색해. 변경 비용은 변경의 범위(scope)에 비례해야지, 변경의 형태(shape)에 비례하면 안 돼.

행위 vs 아키텍처, 뭐가 더 중요하냐고 물으면 저자는 아키텍처가 더 중요하다고 주장해. 완벽하게 동작하지만 변경이 불가능한 프로그램은 요구사항이 바뀌면 쓸모없어지고, 동작하지 않지만 변경이 쉬운 프로그램은 동작하게 고치면 되거든. 아이젠하워 매트릭스를 빌려오면, 행위는 긴급하지만 항상 중요한 건 아니고, 아키텍처는 중요하지만 결코 긴급하지 않아. 문제는 경영진이 긴급한 것만 밀어붙이면서 중요한 걸 계속 미루게 된다는 거야.

결론은 단호해 -- 아키텍처의 중요성을 위해 싸우는 건 개발팀의 책임이야. 마케팅팀은 마케팅을 위해 싸우고, 운영팀은 운영을 위해 싸우잖아. 아키텍처를 위해 싸울 사람은 개발팀뿐이야. 자신을 과신하지 마. 소프트웨어 아키텍처를 심각하게 고민해야 해.

---

정리

1장 읽고 기억할 거 세 가지:

1. 설계와 아키텍처는 같은 거야. 고수준/저수준 구분은 무의미하고, 좋은 아키텍처의 목표는 시스템을 만들고 유지보수하는 데 드는 인력을 최소화하는 거지.
2. 아키텍처 가치가 행위 가치보다 중요해. 지금 동작하는 것보다 나중에 변경할 수 있는 게 장기적으로 더 큰 가치야. 변경 가능성을 잃으면 소프트웨어는 죽어.
3. 아키텍처를 위해 싸우는 건 개발자의 일이야. 아무도 대신 싸워주지 않아. "나중에 정리하지"라는 말은 거짓말이고, 그 "나중"은 절대 안 와.