소프트웨어 설계를 위한 추상적, 구조적 사고│인프콘2023

추상화는 여러 사물·개념에서 공통된 특성을 추출하는 것으로, "공통"과 "추출"이 핵심이다. 지구본·메르카토르 도법·로빈슨 도법은 모두 지구 표면을 표현하지만 무엇을 추출하느냐에 따라 표현이 달라지듯, 추상은 사물을 단순화한 뒤 재해석하는 것이다. 단순화·재해석의 방법으로 데카르트의 요소 환원주의(높은 개념을 더 낮은 요소로 분해)를 소개하고, 피카소의 황소 연작처럼 최종적으로 선만 남기는 것도 같은 맥락이라 한다. 추상화는 현상을 가능한 만큼 분해한 뒤 의도와 목적을 가지고 결합 해 최종 결과를 만드는 것이며, 무의미하게 과한 분해는 의미가 없다. 자기 사진을 색상·구도·선·빛으로 분해한 뒤 일부만 결합해도 여전히 사람임을 알 수 있다는 실습, "피자를 먹고 싶다"는 목표를 만드는 과정으로 나누는 행위의 추상화를 든다. 피자 만들기를 도식화하면 더 추상적이 되고 한 단계 더 압축하면 "피자 주문"이 되는데, 이는 코드에서 긴 프로세스를 하나의 함수로 묶는 것과 같다. 즉 추상화에는 계층 이 있어 해결할 문제에 맞춰 적절한 수준과 관점을 정해야 하며, 공룡 화석처럼 과도한 추상화는 실제를 알 수 없게 만든다(개발에서는 실제 로직을 가린다)는 점도 짚는다.

구조적 사고는 내용을 겹치지 않고 빈틈없이 정리하는 것이다. "좋은 코드 나쁜 코드" 책의, 브라우니 만드는 법을 정신없이 늘어놓은 문서를 예로, 문제를 해결해 주긴 해도 알기 어려운 글은 적절히 구조화해야 한다고 말한다. 그 문서를 목적·묶음·순서 세 관점으로 정리하면 마크다운처럼 보기 쉬워지는데, 이는 누락 없이 중복되지 않게 만드는 MECE 프레임워크와 맞닿는다. 중요한 것은 무조건 안 겹치게 하는 게 아니라 어떻게 나누고 채울지다(성능을 위해 의도적으로 반정규화한 통계 도메인도 모듈을 분리하면 구조적으로 문제없다 — 구조화에도 단계가 있다). 실천 방법으로 큰 문제를 분해하는 탑다운(작은 문제가 미지수일 때)과 세부부터 해결하는 바텀업(작은 문제를 잘 알 때)을 상호보완적 방법론으로 소개한다. 이어 모델링에는 분류(비슷한 단위 그루핑)·추상화(필요한 요소 프로젝션, 계층 레이어링)·일반화(공통점을 묶어 패턴·재사용 함수)의 세 방법이 쓰이며, 모델링에서 추상화와 구조화는 동시에 발생해 떼어 놓을 수 없다 고 정리한다. 같은 문제도 어떤 틀(프레임워크)을 쓰느냐에 따라 접근이 달라지며, 비즈니스 모델 캔버스 같은 기성 틀은 물론 사내 문서 템플릿처럼 직접 만들 수도 있다.

후반부는 소프트웨어 설계를 세 단계로 나눠 다룬다. 도메인 모델링 은 비즈니스 지식을 추상화·구조화해 개발 언어로 바꾸는 것으로, 과외 매칭 서비스를 예로 가장 추상화된 모델에서 학생·선생님·구인·지원·결제 도메인으로 단계적으로 구체화하며 요구사항 변경에 따라 모델이 계속 변함을 보여준다. 아키텍처 는 "개발자가 일하는 방법"으로 무엇을 어떻게 만들고 나눌지를 다루며 요구사항과 조직 상황에 큰 영향을 받는다(조직이 바뀌면 아키텍처도 바뀔 수 있다). 코드 작성 에서는 프로그래밍 패러다임이 소프트웨어를 무엇으로 구성된 것으로 보느냐를 결정하며, 패러다임은 컴퓨터가 아니라 사람을 위한 것이고 순차·분기·반복·참조를 어떻게 보느냐로 갈린다(객체지향은 객체, 함수형은 함수 기준). 문법 설탕은 세부를 숨기는 추상화지만 합의되지 않으면 독이 되므로 추상화 수준을 항상 협의해야 한다. 리팩토링은 기능을 바꾸지 않고 패러다임·크기·소유권·중복·수정 가능성·의존 등 여섯 관점에서 추상화·구조화·일반화 수준을 정하는 일이다(수정 가능성이 높은 코드는 의도적으로 분리하거나 중복을 두는 것도 나쁘지 않다). 마무리에서 추상적·구조적 사고를 기르는 데 지름길은 없으며 여러 관점에서 보는 훈련·다양한 경험·도식화가 도움이 된다고 한다. 다만 구조적 사고는 창의력을 제약하고 추상적인 것은 실체 파악을 힘들게 하니 구체적인 CS 공부도 함께 해야 하며, 직관·관성으로 해 오던 것을 단계별 방법론으로 접근하는 습관을 기르는 것이 중요하다는 말로 맺는다.