1주차 클린 아키텍처 스터디 리뷰: 프로그래밍 패러다임과 AI 시대의 설계
안녕하세요, 이번 <클린 아키텍처 스터디> 리딩을 맡게 된 조영록이라고 합니다.
이번 K-DEVCON 소프트웨어 아키텍처 스터디에서는 로버트 C. 마틴의 『클린 아키텍처』 1장부터 6장까지의 내용을 다루었습니다.
이번 주차는 단순히 아키텍처의 구조론을 넘어서, 소프트웨어의 근간을 이루는 세 가지 프로그래밍 패러다임의 본질을 짚어보고, 이를 급변하는 AI 개발 환경과 현업의 실무에 어떻게 접목할 것인지 논의하는 시간이었습니다.
1. AI 시대, 설계와 테스트 명세의 재발견
가장 먼저 화두로 떠오른 것은 AI의 도입으로 인한 개발 환경의 변화였습니다. AI 도구들의 발전으로 코드 생산 속도가 기하급수적으로 빨라지면서, 개발자가 맞닥뜨린 새로운 딜레마는 '검증'입니다.
- 검증의 주체 변화: AI가 대량으로 생성해 내는 코드를 사람이 일일이 리뷰하고 검증하는 것은 이제 현실적으로 불가능에 가깝습니다. 생산성이 폭발적으로 증가한 만큼, 결과물에 대한 검증 체계는 더욱 정교해져야 합니다.
- TDD와 명세의 중요성: 코드를 빠르게 짜는 것보다 선행되어야 할 것은 '기획 명세의 구체화'입니다. 기획 단계에서부터 요구사항을 명확히 정의하고, 이를 바탕으로 테스트 코드를 먼저 촘촘하게 작성해야 합니다. 즉, AI가 작성한 코드를 사람이 직접 검증하는 것이 아니라, 우리가 견고하게 짜둔 '테스트 명세'가 AI의 결과물을 통제하고 검증하도록 제어권을 유지해야 시스템의 신뢰성을 확보할 수 있습니다.
- 아이젠하워 매트릭스 (Eisenhower Matrix)의 적용 : 업무를 중요도와 긴급도를 기준으로 나누는 방식을 개발에 대입해 보았습니다. 당장 눈앞의 버그를 고치는 1사분면(긴급하고 중요한 일)에만 끌려다니기보다는, 아키텍처를 개선하고 테스트 명세를 고도화하는 2사분면(긴급하지 않지만 중요한 일)에 리소스를 투자하는 것이 장기적인 소프트웨어 품질과 유지보수 비용 절감에 핵심적이라는 공감대가 형성되었습니다.
2. 프로그래밍 패러다임의 본질: 무엇을 제한하는가?
『클린 아키텍처』에서는 1~6장에 걸쳐 구조적, 객체지향, 함수형 프로그래밍을 소개합니다. 아키텍처 관점에서 각 패러다임의 진정한 가치는 '어떤 새로운 기능을 제공하는가'가 아니라 '무엇을 제한하고 통제하는가'에 있습니다.
- 구조적 프로그래밍 (Structured Programming)
- 제한: 제어 흐름의 직접적인 전환(goto 문)을 제한합니다.
- 본질: 프로그램 카운터(PC)의 임의 점프를 if/else, while 등의 블록으로 제한함으로써, 사람이 코드를 위에서 아래로 순차적으로 읽고 추적할 수 있도록 예측 가능성을 부여했습니다.
- 객체지향 프로그래밍 (Object-Oriented Programming, OOP)
- 제한: 제어 흐름의 간접적인 전환(함수 포인터의 직접 호출)을 제한합니다.
- 본질: OOP의 핵심은 캡슐화나 상속보다 다형성(Polymorphism)에 있습니다. 다형성을 통해 의존성 역전 원칙(DIP)을 구현하여, 인터페이스라는 계약을 매개로 변경 가능성이 높은 구체적인 모듈과 변경 가능성이 낮은 추상적인 모듈의 경계를 명확히 분리합니다. 이를 통해 시스템의 결합도를 낮추고 언제든 부품을 갈아끼울 수 있는 유연성을 확보합니다.
- 함수형 프로그래밍 (Functional Programming)
- 제한: 변수 할당(가변 상태)을 제한합니다.
- 본질: 동시성 문제와 레이스 컨디션(Race Condition)의 근본적인 원인은 가변 상태에 있습니다. 데이터의 상태를 변경하지 않고 입력과 출력을 통제하는 순수 함수를 지향함으로써, 복잡도를 낮추고 테스트를 용이하게 만듭니다.
3. 현업의 고민과 스터디 인사이트
패러다임과 아키텍처 이론을 바탕으로, 각자의 실무 환경에서 겪고 있는 생생한 고민들이 쏟아졌습니다.
- 상태 관리와 생태계의 패러다임: 프론트엔드 진영(React 등)에서는 동시성 문제와 복잡한 상태 관리를 통제하기 위해 함수형 프로그래밍과 불변성의 개념이 필수불가결한 요소로 자리 잡고 있습니다. 반면 백엔드(Spring, Node.js 등)에서는 도메인 로직의 보호와 거대한 시스템의 확장을 위해 객체지향의 인터페이스 분리와 다형성이 여전히 강력한 도구로 활용되고 있음을 비교해 볼 수 있었습니다.
- AI 도입의 빛과 그림자 (Cost vs. ROI): 사내에서 특정 시니어 개발자의 코드 스타일을 AI에 페르소나로 학습시켜 자동 리팩토링 PR을 올리게 하는 흥미로운 사례가 공유되었습니다. 시스템적 효율과 생산성은 압도적이지만, 추론에 소모되는 엄청난 토큰 비용(API Cost)과 인건비 절감 사이에서 최적의 타협점을 찾는 것이 앞으로 모든 기업의 과제가 될 것입니다.
- 도메인 분리와 복잡도의 역설: WMS(창고 관리)와 OMS(주문 관리)처럼 밀접하게 얽힌 도메인을 마이크로서비스로 분리했을 때 발생하는 트랜잭션 처리와 보상 로직의 복잡성에 대한 고충이 있었습니다. 서비스가 무조건 분리되어 있다고 좋은 것이 아니며, 통합된 모놀리식 구조가 오히려 인지적 과부하와 아키텍처 유지보수 비용을 줄이는 데 더 합리적인 선택이 될 수 있다는 점을 상기하게 되었습니다.
맺음말
소프트웨어(Software)라는 단어의 본질은 기계(Hardware)의 행위를 상황에 맞게 '유연하게(Soft) 변경'할 수 있다는 데 있습니다. 코드가 단순히 동작하게 만드는 것을 넘어, 타인과 미래의 나에게 신뢰를 줄 수 있는 견고한 구조를 고민하는 것이 엔지니어이자 아키텍트의 숙명일 것입니다.
다음 스터디에서도 현업의 치열한 경험과 아키텍처 이론이 교차하는 흥미로운 논의가 이어지기를 기대합니다.