복잡성을 다루는 법 – 진짜 소프트웨어 설계란 무엇인가

이 글은 Pragmatic Engineer 뉴스레터에서 발행된
『The Philosophy of Software Design – with John Ousterhout』 인터뷰 내용을 기반으로,
제가 실무에서 느낀 복잡성과 설계에 대한 고민을 함께 정리한 두 번째 이야기입니다.

복잡성과의 싸움, 설계는 무엇을 위한 것인가?

Ousterhout 교수는 말합니다.

“소프트웨어 설계란 곧 복잡성을 다루는 기술이다.”

복잡성을 다루는 방법은 두 가지입니다.

복잡성을 제거하기 – 아예 문제 상황이 생기지 않도록 설계

복잡성을 감추기 – 복잡한 로직은 내부로 숨기고, 외부에는 단순한 인터페이스만 제공

그는 특히 후자를 강조하며, 이를 Deep Module이라는 개념으로 설명합니다.

✅ Deep Module: 내부적으로 복잡하지만 외부에는 단순한 인터페이스
❌ Shallow Module: 복잡한 인터페이스지만 실제로 하는 일은 단순

“처음 떠오른 아이디어가 최선일까?”

그는 또 하나의 설계 팁을 소개합니다.

“진짜 실력자는 설계안을 최소 두 번 이상 고민한다.”

처음 생각한 구조가 가장 좋은 선택이 아닐 가능성이 높기 때문입니다.
그는 실제로 자신이 만든 Tk 툴킷의 API를 처음 설계했다가,
전혀 다른 두 번째 설계안으로 갈아탔고,
그 선택이 지금까지도 사랑받는 구조가 되었다고 말합니다.

저 역시 실무에서 이를 뼈저리게 느낀 적이 있습니다.
처음 요구사항을 들었을 때, 워터폴 방식으로 빠르게 구현했지만
고객 피드백, 실환경에서의 문제, 성능 이슈 등으로
기능 자체를 다시 설계해야 했던 경험이 많았습니다.

그래서 지금은 어떤 설계가 떠올라도
“이게 정말 최선인가?”라는 질문을 습관처럼 던집니다.
정답이 없는 문제이기에, 더더욱 당연함을 의심할 필요가 있는 것이죠.

AI 시대, 더 중요한 건 기본기

지금 저는 AI 기반 개발 도구를 자주 사용합니다.
하지만 그만큼 전체 흐름을 이해하지 못하고 복사/붙여 넣기만 하는 위험성도 함께 커졌습니다.

AI가 제안하는 해결책이 항상 최적의 답은 아니며,
문제의 본질을 이해하지 못한 상태에서 나온 결과일 수 있기 때문입니다.

그래서 오히려 지금 시대에는 이런 능력이 더 중요해졌습니다.

전체 구조와 흐름을 설계하는 능력

모듈화와 추상화에 대한 감각

CS 기반 지식과 기본기

앞으로는 이런 기초가 튼튼한 개발자가
AI 도구를 가장 잘 다루는 사람이 될 것입니다.

좋은 설계자란?

오스터하우트 교수는 마지막으로 이렇게 말합니다.

“좋은 설계자는 공감 능력이 있는 사람이다.
사용자의 입장에서, 동료 개발자의 입장에서
더 나은 구조를 고민할 수 있는 사람.”

이 말은 제가 지금도 자주 떠올리는 문장이기도 합니다.
내가 만든 이 코드와 구조는 과연 협업하는 동료에게 쉬울까?
혹은 내가 만든 API는 다른 사람이 보고 이해할 수 있을까?

'한 번 더 설계하기'는 더 나은 코드의 시작이다

AI 도구 덕분에 더 빨리 개발할 수 있는 시대.
하지만 진짜 좋은 개발자는 결국, 더 나은 설계를 할 줄 아는 사람일 것입니다.

‘한 번 더 설계하기’, ‘하나 더 아이디어를 떠올려 보기’,
이 작은 습관이 여러분의 다음 프로젝트를 더 단단하게 만들 수 있기를 바랍니다.