더 스마트한 소프트웨어 아키텍처는 더 스마트한 팀을 만든다

Source: Dev.to

1. 절차적 개발: 편안한 고립의 길

절차적 작업은 간단합니다:

입력 → 로직 → 출력.

로직을 서비스에 넣으세요. OrderService 혹은 FooManager 같은 이름을 짓고.
테스트를 작성하고, 초록색이 되게 하세요. 끝.

이 세계에서는:

• 혼자서 작업할 수 있다.
• 토론은 선택 사항이다.
• 공유된 이해는 불필요하다.
• 기능은 티켓이며, 생각이 아니다.
• 아키텍처는 폴더 구조이다.
• 진행 상황은 체크표시로 측정한다.

팀은 의미 주위에 모이지 않는다; 의미가 없고, 단지 작업만 있다. 절차적 코드베이스는 평평한 풍경이다: 모든 것이 동등하게 중요하고 동시에 동등하게 중요하지 않으며, 중력 중심이나 개념적 위계가 없다.

팀에 미치는 결과

• 모두가 혼자 일한다.
• 모두가 자신의 작은 세계를 만든다.
• 모든 것이 동등하게 단절된다.
• 소유권은 파편화된다, 시스템이 파편화되었기 때문이다.

절차적 팀은 교체 가능한 작업자들이 교체 가능한 로직을 전달하는 집단이 된다. 이것은 팀의 잘못이 아니라 아키텍처의 잘못이다. 이 접근 방식은 한 차원, 즉 인력만 확장된다.

2. 풍부한 도메인 모델: 협업을 자연스럽게 끌어당기는 자석

풍부한 도메인 모델은 구조와 의미를 가지고 제품의 본질을 나타낸다. 시스템이 실제 세계를 반영할 때—개념, 불변식, 경계, 협업을 포함하면—더 이상 고립해서 작업할 수 없다. 모든 새로운 기능이 이미 존재하는 무언가에 연결되기 때문에 대화하고, 이해하고, 정렬해야 한다.

전형적인 질문은 순수 기술적이라기보다 제품 지향적이 된다:

• 이 개념은 다른 것들과 어떻게 상호작용하는가?
• 이 행동의 소유자는 누구인가?
• 이미 이 관점을 포착한 모델이 있는가?
• 이 책임은 여기 있나, 아니면 다른 곳에 있는가?

이러한 대화는 디자이너, 비즈니스 전문가, 분석가, 제품 소유자를 끌어들인다.

모델링 팀에서

• 도메인 모델은 공유된 정신 지도다.
• 모두가 같은 개념 객체를 가리킨다.
• 토론이 더 쉽고, 빠르고, 풍부해진다.
• 제품 전체가 더 많은 사람에게 이해된다.
• 소유권은 티켓 소유가 아니라 공유된 책임이 된다.

도메인 모델은 팀을 팀으로 만들도록 강제한다—모두가 모이는 모닥불이다.

3. 직관에 반하는 현실: 풍부한 모델이 더 빠르다

“코딩을 바로 시작할 수 있기 때문에 절차적 개발이 더 빠르다”는 신화가 있다. 실제로 두 접근 방식은 같은 속도로 시작하지만, 시간이 지나면서 하나만 가속한다.

풍부한 모델을 사용할 때

• 구조가 새로운 기능을 안내한다.
• 복잡한 행동은 기존 행동의 조합이 된다.
• 규칙, 제약, 불변식이 이미 내재되어 있다.
• 많은 결정이 모델에 의해 이미 내려졌다.
• 코드를 덜 쓰고 실수를 적게 만든다.

절차적 코드는 복합되지 않으며, 도메인 모델링은 복합한다. 절차적 코드베이스는 가속되지 않고 무게만 쌓인다.

절차적 시스템에서

• 모든 새로운 기능은 작은 재발명이다.
• 모든 서비스는 새로운 로직 조각이다.
• 모든 변경은 여러 곳을 건드린다.
• 모든 새로운 요구는 이전에 만든 지름길을 드러낸다.

레버리지가 없고, 단지 노동만 있다.

4. 그렇다면 왜 절차적 개발이 지배적인가? (그 비용이 보이지 않기 때문에)

도메인 모델링이 더 나은 팀, 더 빠른 개발, 높은 품질을 가져온다면 왜 절차적 개발이 산업을 장악하고 있을까? 조직은 교체 가능성을 최적화하고, 효율성을 최적화하지 않기 때문이다.

절차적 코드는:

• 채용하기 쉽다
• 외주 주기 쉽다
• 추정하기 쉽다 (“그냥 서비스 하나 만들면 된다”)
• 내부 인력을 교체하기 쉽다
• 관리자에게 설명하기 쉽다
• 스프레드시트에서 정당화하기 쉽다

하지만 저렴한 것이 아니라 보이지 않게 비싼 것이다. 장기 비용—느린 개발, 버그, 재작성, 마이크로서비스 과잉, 협업 오버헤드, 인지 부하—가 조용히 누적된다. 소프트웨어는 폭발하지 않고 조용히 부패한다.

이 현상에 대한 심층 분석은 여기서 확인할 수 있다:
Why IT Is an Expensive Mess — And Why Nobody Inside IT Notices

5. 교체 가능성을 원한다면 작업을 단순화하지 말고 — 개발자를 더 똑똑하게 만들라

현재 기업 논리는 다음과 같다:

“우리는 교체 가능한 개발자를 원한다. 그래서 작업을 최저 공통 분모로 단순화해야 한다.”

이 논리는 곧:

• 절차적 코드
• 서비스 스프
• 끝없는 마이크로서비스
• 설계 대신 티켓
• “그냥 서비스를 추가하라”는 사고
• 사람을 늘리는 것으로만 확장되는 취약한 시스템

반대가 필요하다. 개발자를 적응력 있고, 교체 가능하며, 효과적으로 만들고 싶다면:

• 작업을 단순화하지 말고, 기술을 부여하라.
• 서비스 폴더가 아니라 이해할 수 있는 모델을 제공하라.
• 분열이 아니라 명확성을 제공하라.

강력한 모델은 혼돈 없이 유연성을 만든다. 절차적 혼란은 유연성으로 가장한 혼돈을 만든다.

6. 팀 행동은 기술 구조를 따른다

핵심 논제: 당신의 아키텍처가 팀 역학을 결정하고, 팀 역학이 제품을 결정한다.

약한 구조 위에 강한 팀을 만들 수 없으며, 절차적 파편 위에 제품 소유권을 세울 수 없다. 진정한 팀워크는 모일 가치가 필요하다: 제품의 의미를 포착하는 모델.

7. 마무리 생각

팀은 스탠드‑업, 회고, 보드 게임을 해서 팀이 되는 것이 아니다. 팀은 함께 생각해야 할 때 팀이 되고, 함께 생각한다는 것은 생각할 대상이 있을 때만 가능하다:

• 공유된 언어
• 공유된 개념
• 공유된 구조
• 공유된 의미
• 공유된 책임

절차적 개발은 공유된 사고의 필요성을 없애고, 도메인 모델링은 그것을 만든다. 한 길은 고립된 작업자와 비싼 시스템을, 다른 길은 진정한 팀과 진정한 제품을 만든다. 제품—그리고 팀을 구축하는 길을 선택하라.