[맺는 글-제이슨 고먼]
1990년대로, Big Architecture(모든 것을 완벽하게 분석하고 설계한 후 구현하고 테스트하며, 이후 빅뱅 통합 과정을 거치는 아키텍처)라는 공룡이 세계를 지배하던 시기였다. 출세하려면 객체나 컴포넌트, 디자인 패턴, UML을 배워야만 했다. 설계 단계에는 '선임' 프로그래머가 시스템에 대한 상세한 청사진을 펼치고, 대다수의 '후배' 프로그래머가 따르도록 만들었다. 물론 지켜지지는 않았다. 단 한 번도.
다행히도 이후에 애자일 소프트웨어 개발이라는 혁명이 발발했고, 나와 같은 아키텍트를 이 불행으로부터 벗어나게 해 주었다. 나는 프로그래머다. 나는 프로그래밍을 좋아한다. 그리고 코드에 긍정적인 영향을 줄 수 있는 방법 중 내가 발견한 최고는 코드를 작성하는 일이다.
Big 아키텍처라는 공룡은 익스트림 프로그래밍이라는 소행성으로 인해 완전하게 멸종해버렸다. 그리고 그렇게 우리는 살아남았다. 개발팀은 자유의 몸이 되어 중요한 일에 집중하고, 가치를 더하는 것에 노력을 기울일 수 있었다.
Big 아키텍처라는 공룡은 완전히 사라졌고, 작고 날렵하며 충분한 만큼만 설계를 선행한 다음 수없이 리팩터링을 진행하는 영장류가 세상을 대체했다. 소프트웨어 아키텍처는 이제 즉각적으로 반응하게 되었다.
아키텍처를 프로그래머에게 맡기면 프로그래머가 반드시 아키텍트처럼 생각할 수 있어야 한다는 문제가 생겼다. 설계와 관련된 모든 결정은 미래에 발생할 변경에 문을 열어 둘 수 있어야 한다. 미래에 덧붙여질 코드를 방해하지 않으면서도 코드가 동작할 수 있게 작성하는 데는 심상치 않은 능력이 요구된다. 그리하여 Big 아키텍처의 시대가 물러나고 새로운 Fragile 아키텍처의 시대가 찾아왔다. 설계는 빠르게 성장하면서 가치를 더 일찍 전달할 수 있께 되었으나, 이러한 혁신 속도를 그대로 유지하기는 상당히 어려워졌다.
오늘의 가치를 제공하기 위해 코드를 작성하면서 내일의 가치를 방해하지 안헥 만드는 일이 어떻게 가능한지 당신도 이제 알게 되었을 것이다. 이를 실천에 옮겨서 당신의 코드에 그 원칙들을 적용하는 책임은 당신에게 있다. 코드를 분석하고, 밥이 강조한 유형의 문제를 찾아낸 후, 그 문제를 고치기 위해 리팩터링하라. 그래서 새 코드가 골칫거리가 될 가능성을 낮추어라. 예를 들어 TDD를 하는 중이라면, 각 테스트를 통과한 다음 가벼운 설계 리뷰를 반드시 거치고, 이를 통해 중간중간 정리하도록 하라. 코드를 커밋하기 전이라면, 동료에게 함께 리뷰해줄 것을 요청하라. 코드의 품질 게이트를 빌드 파이프라인에 추가할 수 있는지, 그 가능성을 검토하라. 그래서 클린 아키텍처를 위반하는 사태에 대한 최종 방어선을 구축하라.
팀과 함께 클린 아키텍처에 대해 이야기하라. 품질은 공동의 책임이며, 좋은 아키텍처와 나쁜 아키텍처 사이의 간극에 대해 합의를 이루는 일은 중요하다. 25년 전의 내가 그랬던 것처럼, 대다수의 소프트웨어 개발자는 아키텍처에 대해 잘 알지 못한다는 사실에 유의하라.
댓글