1장이 “좋은 아키텍처는 나중이 아니라 지금 신경 써야 한다”고 못박았다면, 2장은 그 말이 왜 그토록 지키기 어려운지를 해부한다. 마틴의 진단은 냉정하다 — 아키텍처가 밀리는 것은 게을러서가 아니라, 우리가 매일 마주하는 두 가지 가치가 서로 다른 목소리로 우리를 부르기 때문이다. 하나는 다급하게 소리치고, 다른 하나는 조용히 중요하다. 그리고 인간은 소리치는 쪽에 먼저 손이 간다.
모든 소프트웨어 시스템은 이해관계자에게 두 종류의 가치를 제공한다. **행위(behavior)와 구조(structure)**다. 이 장의 전부는, 대부분의 조직이 둘 중 값이 덜 나가는 쪽에 목숨을 걸고 값이 더 나가는 쪽을 방치한다는 역설을 드러내는 데 있다.
행위 — 눈에 보이고, 급하게 우는 가치
행위는 알기 쉬운 가치다. 프로그래머를 고용하는 이유가 바로 이것이다. 이해관계자가 기능 명세나 요구사항을 내밀면, 우리는 기계가 그 명세대로 동작하도록 코드를 짠다. 매출을 계산하고, 재고를 차감하고, 주문을 접수한다. 기계가 요구대로 굴러가 이해관계자에게 돈을 벌어 주거나 비용을 아껴 주면, 소프트웨어는 제 값을 한다.
많은 프로그래머가 자기 일이 여기서 끝난다고 믿는다. 명세대로 동작하게 만들고, 버그가 나면 고친다. 이것이 소프트웨어의 전부라고 여긴다. 마틴은 여기에 대고 단호하게 틀렸다고 말한다. 행위는 두 가치 중 하나일 뿐이며, 더 값나가는 쪽도 아니다.
판단 기준: “요구대로 동작하는가”는 소프트웨어가 통과해야 할 첫 관문이지 마지막 관문이 아니다 — 여기서 멈추면 가치의 절반만 배달한 것이다. 함정: 행위는 데모로 보여줄 수 있고 티켓으로 셀 수 있어서 성과처럼 느껴진다. 그 가시성 때문에 조직 전체가 행위만 성과로 계산하고, 보이지 않는 구조는 성과 장부에서 통째로 누락된다.
구조 — “소프트”라는 이름에 담긴 약속
두 번째 가치는 소프트웨어라는 단어 자체에 숨어 있다. **소프트(soft)**웨어는 부드러운 제품이라는 뜻이다. 무엇이 부드러워야 하나. 기계의 행위가 아니라, 그 행위를 바꾸기가 쉬워야 한다는 것이다. 소프트웨어를 발명한 이유가 바로 여기 있다. 하드웨어처럼 굳어 버린 기계 대신, 요구가 바뀔 때마다 값싸게 행위를 갈아 끼울 수 있는 기계를 갖고 싶었기 때문이다. 그것이 하드웨어와 소프트웨어를 가르는 본질이다.
그렇다면 변경 비용은 어떤 모습이어야 하는가. 마틴은 이상적인 상태를 한 문장으로 못박는다 — 변경의 어려움은 변경의 범위(scope)에 비례해야 하고, 변경의 형태(shape)에 비례해서는 안 된다. 이 한 문장이 2장의 심장이다.
풀어 보자. 이해관계자가 비슷한 크기의 변경 요청 둘을 가져온다. 둘 다 손대는 코드의 양은 얼추 같다. 그런데 하나는 사흘이면 끝나고, 다른 하나는 손댈 곳이 시스템 전역으로 흩어져 몇 주가 걸린다. 이해관계자의 눈에는 둘의 규모가 같아 보이는데 비용이 몇 배로 벌어진다. 왜 이게 저것보다 이렇게 비싸냐고 물으면, 개발팀은 새 기능이 기존 구조의 형태에 맞지 않아 여기저기를 뜯어야 한다고 답할 수밖에 없다. 변경 비용이 요청의 범위가 아니라 시스템의 형태에 붙잡힌 것이다. 이것이 나쁜 아키텍처의 증상이다.
판단 기준: 비슷한 규모의 요청들이 저마다 다른 비용을 요구하고, 그 편차가 “요청의 크기”가 아니라 “코드가 놓인 모양”에서 온다면 구조가 병들어 있다는 신호다. 함정: 개별 변경 하나하나는 늘 그럭저럭 해낼 수 있어서 위기가 감지되지 않는다. 형태에 비례하는 비용은 릴리스를 거듭할수록 조용히 누적되다가, 1장의 그래프처럼 생산성이 0으로 수렴하는 지점에서야 청구서로 도착한다.
어느 가치가 더 큰가 — 두 개의 사고 실험
행위와 구조 중 무엇이 더 값나가는가. 마틴은 답을 강요하지 않고, 두 개의 극단적인 프로그램을 나란히 세워 우리가 스스로 고르게 한다.
첫째, 완벽하게 동작하지만 도저히 변경할 수 없는 프로그램. 요구가 바뀌는 순간 아무도 손댈 수 없으니, 요구는 반드시 바뀌므로, 이 프로그램은 곧 쓸모를 잃는다. 완벽한 행위는 굳어 버리는 순간 죽은 자산이 된다.
둘째, 동작은 하지 않지만 변경이 지극히 쉬운 프로그램. 지금은 요구를 만족시키지 못하지만, 요구가 바뀔 때마다 값싸게 고쳐 나갈 수 있다. 따라서 이 프로그램은 계속 살아 움직이며 언젠가 요구를 만족시킨다.
물론 두 프로그램 다 극단이라 현실에는 없다. 하지만 사고 실험의 결론은 명확하다 — 동작하지만 못 고치는 프로그램보다, 못 동작해도 고칠 수 있는 프로그램이 더 값지다. 그러니 논리적으로 구조가 행위보다 더 큰 가치를 지닌다. 이 결론은 직관을 배반한다. 우리 눈에 급하게 우는 것은 언제나 “동작하느냐”이기 때문이다.
판단 기준: 두 개선안 중 어디에 시간을 쓸지 저울질할 때, “이 시스템이 앞으로도 요구 변경을 값싸게 흡수할 수 있는가”를 “지금 이 기능이 도는가”보다 위에 둔다. 함정: 구조가 더 값지다는 명제를 “행위는 대충 해도 된다”로 오독하지 말 것 — 마틴의 요점은 우선순위의 역전이지 행위의 포기가 아니다. 동작하지 않는 소프트웨어는 여전히 소프트웨어가 아니다.
아이젠하워의 격자 — 긴급과 중요는 같지 않다
이 역설을 마틴은 아이젠하워 대통령의 오래된 격언 하나로 압축한다. “나에게는 두 종류의 문제가 있다. 긴급한 것과 중요한 것. 그런데 긴급한 것은 좀처럼 중요하지 않고, 중요한 것은 좀처럼 긴급하지 않다.” 이 문장을 두 축의 격자로 펼치면, 소프트웨어의 두 가치가 정확히 그 위에 자리를 잡는다.
가로축은 긴급함, 세로축은 중요함이다. 이 격자에는 네 칸이 생긴다. 긴급하고 중요한 것, 긴급하지만 안 중요한 것, 안 긴급하지만 중요한 것, 안 긴급하고 안 중요한 것. 마틴은 소프트웨어의 두 가치를 이 격자 위에 이렇게 배치한다.
행위의 긴급함은 지금 당장이지만, 그 중요함이 늘 높지는 않다. 오늘 반드시 처리해야 할 기능 요청이 마감을 달고 날아오지만, 그중 상당수는 시스템의 운명을 좌우할 만큼 중요하지는 않다. 반대로 아키텍처(구조)는 대단히 중요하지만, 지금 당장 급하지는 않다. 오늘 손보지 않아도 시스템은 오늘 멈추지 않는다. 그래서 아키텍처는 언제나 “나중에”로 미룰 수 있는 얼굴을 하고 있다.
여기서 사람들이 저지르는 치명적 실수가 나온다. 첫 번째 칸(긴급하고 중요)과 두 번째 칸(긴급하지만 안 중요)을 뭉뚱그려 버리는 것이다. 긴급하다는 이유 하나로, 정작 중요하지 않은 기능 요청을 정말로 중요한 아키텍처 작업보다 앞에 세운다. 급한 불을 끄느라 집의 골조가 썩는 걸 방치하는 셈이다. 개발팀이 매일 저지르는 실수가 바로 이 뒤섞음이다 — 긴급함을 중요함으로 착각하는 것.
판단 기준: 어떤 작업을 먼저 할지 다툴 때, “급한가”와 “중요한가”를 반드시 두 개의 독립된 질문으로 나눠 묻는다. 급한 기능 요청 대부분은 첫 번째 칸이 아니라 두 번째 칸(긴급하지만 안 중요)에 속하며, 그 자리에서는 세 번째 칸의 아키텍처에 우선순위를 내줘야 한다. 함정: 긴급함은 목소리가 크고 중요함은 목소리가 작아서, 두 축을 나눠 묻지 않으면 격자가 저절로 한 줄로 뭉개진다 — 그 순간 안 긴급하지만 중요한 아키텍처는 영원히 순번을 얻지 못한다.
우선순위를 업무 부서에 맡기면 벌어지는 일
여기서 마틴은 조직의 역학을 냉정하게 짚는다. 아키텍처가 늘 밀리는 이유는 개인의 게으름이 아니라 누가 우선순위를 쥐고 있느냐의 문제다.
업무 관리자(business managers)는 아키텍처의 중요성을 평가할 위치에 있지 않다. 그것을 판단하라고 프로그래머를 고용한 것이다. 그런데 현실에서는 우선순위 결정권이 업무 부서로 넘어간다. 업무 부서가 볼 수 있는 것은 오직 긴급하게 우는 행위뿐이다. 그들의 눈에 아키텍처는 지금 당장 매출을 만들지 않는, 미룰 수 있는 무엇이다. 그래서 우선순위 목록의 아래로, 아래로 계속 밀려난다. 결국 시스템은 골조 없이 기능만 쌓아 올린 위태로운 건물이 되고, 어느 릴리스에선가 무너진다.
마틴의 처방은 그래서 정치적이다. 개발팀은 아키텍처의 중요성을 위해 싸워야 한다. 아키텍처의 가치를 아는 유일한 집단이 개발팀이므로, 그 가치를 옹호할 책임도 개발팀에 있다. 이것은 코드를 잘 짜는 기술의 문제가 아니라, 조직 안에서 보이지 않는 가치를 대변하는 투쟁의 문제다. 개발팀이 이 싸움을 회피하고 업무 부서가 정한 순서를 고분고분 따르기만 하면, 자신들이 지키기로 되어 있던 바로 그 가치를 스스로 파괴하게 된다.
판단 기준: 아키텍처 작업이 스프린트마다 뒤로 밀린다면, 그건 시간이 없어서가 아니라 우선순위 결정권이 그 가치를 볼 수 없는 사람 손에 있다는 구조적 신호다 — 결정권의 위치부터 바로잡아야 한다. 함정: “업무가 원하는 걸 만들어 주는 게 우리 일”이라는 협조적 태도는 얼핏 프로다워 보이지만, 아키텍처를 대변할 유일한 집단이 침묵을 택하는 순간 그 프로다움은 시스템을 무너뜨리는 방조가 된다.
소프트웨어 개발자도 이해관계자다
마틴은 개발팀에게 이 싸움을 떠넘기며 한 가지 인식의 전환을 요구한다. 개발팀은 자신을 단순한 하청 노동자로 여기지 말고, 시스템을 지킬 책임을 진 이해관계자 집단으로 여겨야 한다는 것이다. 다른 이해관계자들이 행위를 지키듯, 개발팀은 구조를 지킨다. 이것은 역할 분담의 문제다. 아무도 구조를 대변하지 않으면 구조는 소리 없이 팔려 나간다.
그래서 아키텍처를 지키는 일은 겸손한 순응이 아니라 책임 있는 주장이다. 매번 새 기능 요청 앞에서, 그것이 정말 지금 골조를 희생할 만큼 긴급하고 중요한지 되물어야 한다. 대개는 아니다. 대개 그것은 두 번째 칸 — 급하지만 그다지 중요하지 않은 요청 — 이며, 그렇다면 세 번째 칸의 구조 작업에 순번을 양보해야 한다.
- 소프트웨어의 두 가치는 **행위(기능)와 구조(변경 가능성)**다. 급하게 우는 쪽은 늘 행위지만, 논리적으로 더 값나가는 쪽은 구조다.
- “소프트”란 변경이 쉬워야 한다는 약속이며, 그 이상은 변경 비용이 요청의 범위에 비례하고 코드의 형태에 비례하지 않는 상태다.
- 아이젠하워 격자: 행위는 긴급하나 늘 중요친 않고, 아키텍처는 중요하나 급하지 않다 — 긴급함과 중요함을 뭉개는 순간 아키텍처는 영원히 밀린다.
- 우선순위를 업무 부서에 맡기면 그들이 볼 수 있는 긴급한 행위만 이긴다. 구조의 가치를 아는 개발팀이 그것을 위해 싸워야 한다.
동작하는 소프트웨어는 오늘의 값을 내고, 부드러운 소프트웨어는 내일의 값까지 낸다. 2장은 그 두 값이 매일 우리 앞에서 벌이는 우선순위 다툼의 이름을 붙여 주었다. 다음 장부터 이 책은 “부드러움”을 감정이 아니라 기술로 다루기 시작한다 — 무엇이 코드를 부드럽게 만드는가라는 질문에 답하기 위해, 프로그래밍 패러다임이라는 벽돌부터 다시 쌓아 올린다.
다음장으로 3장