설계의 함정 - 소프트웨어 설계의 정석을 읽고

소프트웨어 설계의 정석 책 표지

소프트웨어 설계란 무엇일까? 개발자는 개발에 앞서 설계라는 과정을 충분히 수행하고 있을까?

소프트웨어 설계의 목적은 무엇일까?

‘설계’란 공학 분야에서 제품을 어떻게 만들지에 대한 계획을 세우는 일이다.
그렇다면 소프트웨어 설계란 코드를 작성하기 전, 미리 계획하고 준비하는 일련의 과정이라 할 수 있다.
그렇다면 우리는 이 과정을 잘하고 있을까?

 여러 회사를 경험하거나 이야기를 듣다 보면, 이 질문에 확신 있게 ‘그렇다’고 답할 수 있는 경우는 그리 많지 않다. 그렇기에 우리는 소프트웨어 설계에 대해 더 깊이 고민하고, 비평해볼 필요가 있다.

이 책에서 말하는 ‘소프트웨어 설계를 잘하기 위해 필요한 요소’는 세 가지다.

1. 설계의 목적을 명확히 파악할 것
2. 설계에 필요한 최소한의 테크닉을 습득할 것
3. 그리고 주변 사람들과 제대로 된 의사소통을 할 것 - 설계는 곧 커뮤니케이션이다

이 중에서도 개인적으로 가장 공감되는 부분은 1번과 3번이다.
설계란 단순히 멋진 코드를 짜서 동작하는 서비스를 만드는 것이 아니다.
나와 함께 일하는 사람들이 같은 목표를 향해 나아가기 위해 반드시 필요한 작업이다.
‘사람들과 함께 나아가기 위한 설계’란 구체적으로 어떤 의미일까?

 복잡한 요구사항이 존재하는 조직에서는 결코 혼자서 서비스를 완성할 수 없다. 디자이너, 기획자, 개발자가 함께 협업하는 구조를 가진다.
각자의 역할은 단순히 개인의 업무만 수행하는 것에 그치지 않는다.

 

예를 들어보자.
기획자가 기획서를 완성한 후 개발자에게 넘긴다고 해서 역할이 끝난 것일까?
만약 디자이너나 개발자가 완성된 기획서에 다양한 의견을 제시한다면 어떨까?
기획자는 불편함을 느낄 수도 있다.
그렇다면 디자이너와 개발자의 의견을 반영하여 기획서를 수정했다면 협업이 잘 이루어졌다고 볼 수 있을까?

 

나는 이 상황에서 ‘기획서의 함정’ 이 있다고 생각한다.
완성된 기획서에 다른 팀원의 의견을 반영했다고 해서 모든 문제가 해결된 것은 아니다.
실제 구현 및 디자인 작업을 시작하면 예기치 못한 정책 이슈나 엣지 케이스가 자주 발견된다.
결국 추가적인 일을 해야 하는 상황이 반복된다.
기획 단계에서는 몰랐던 문제들이 개발 및 디자인 단계에서 비로소 드러나는 것이다.

그래서 내가 생각하는 협업의 핵심은 ‘완성된 기획서를 넘기는 방식’ 이 아니다.
기획서가 완성되기 전, 즉 기획 과정 중에도 디자이너와 개발자에게 수시로 공유하고, 피드백을 주고받는 것이다.
함께 같은 방향을 바라보며 기획서를 다듬어 가는 과정 속에서 진정한 협업이 이루어진다고 생각한다.
전체적인 맥락을 함께 이해하는 것, 이것이 협업 메커니즘의 핵심이다.

그렇다면 소프트웨어 설계는 어떤 역할을 할까?

기획자와의 협업처럼 소프트웨어 설계 역시 이해관계자들과 중간중간 공유하며 소통하는 커뮤니케이션 도구가 되어야 한다.
용어집, 개념 모델을 통해 팀원들과 같은 언어로 대화하고,
요구사항이 변경되더라도 설계를 기반으로 논의가 가능해야 한다.

결국, 이것이 바로 이 책에서 말하는 ‘제대로 된 의사소통’ 이라고 생각한다.

이러한 이유로 우리는 유스케이스를 그리고, 개념 모델링을 작성하며, 데이터베이스나 아키텍처를 설계하는 것이다.

---

소프트웨어 설계, 어떻게 해야 할까?

결론부터 말하면 소프트웨어 설계에 정답은 없다.
하지만 이 책에서는 이를 크게 두 가지로 나누어 설명한다. 바로 외부 설계와 내부 설계다.

• 외부 설계는 시스템이 외부에 제공해야 하는 기능을 구체화하는 작업이다.
시스템 사용자나 외부 시스템과의 인터페이스, 제공 기능 등을 설계한다.
외부 설계에서는 주로 입력과 출력이 정의된다.

• 내부 설계는 이러한 입력과 출력 사이에서 수행되는 내부 로직과 처리를 설계하는 작업이다. 이를 위해 우리는 먼저 요구사항을 정의하고, 유스케이스 분석, 개념 모델링, 비기능 요건 정의 등을 수행한다.
그 다음으로는 외부 설계를 위해 화면 설계, 외부 시스템 I/F 설계, 배치 설계, 장표 설계, 데이터베이스 논리 설계 등을 한다.
내부 설계로는 화면 프로그램 설계, 비즈니스 로직 프로그램 설계(예: 클래스 다이어그램), 데이터베이스 프로그램 설계 등이 있다.

이처럼 설계 과정은 결코 가볍지 않다.
그렇다면 우리는 여기서 질문해 볼 필요가 있다.
“이렇게 많은 작업을 꼭 해야만 하는 걸까?”

만약 내가 과거에 이러한 설계를 해본 경험이 없었다면 책만 읽고 넘어갔을지도 모른다. 하지만 실제로 현업에서 이러한 작업들을 반복하며 경험했기에 나는 자신 있게 말할 수 있다.

“이 모든 작업은 반드시 필요하며, 정말 중요하다.”

---

내가 생각하는 설계의 핵심

개인적으로 나는 외부 설계와 내부 설계를 구분해서 그리는 것보다 ‘내가 만들어야 할 가치가 무엇인지’ 에 더 집중하며 설계를 수행해왔다.
그 과정에서 가장 핵심이 되는 작업은 단연코 개념 모델링(도메인 모델링) 이었다.

 우리는 객체지향 프로그래밍을 한다.
객체지향의 핵심인 협력, 역할, 책임을 기반으로 도메인을 정의하고, 이를 통해 우리가 만들어야 할 가치를 구체화해야 한다.
그 외 다양한 설계 산출물들은 이러한 개념 모델링을 보조하여 우리가 목표로 하는 가치를 더욱 선명하게 만들어 준다.

 

---

마무리하며

이 책은 설계의 본질과 목적, 그리고 실무에서 반드시 고려해야 할 설계 프로세스에 대해 깊이 있게 다루고 있다. 특히 ‘설계는 커뮤니케이션이다’ 라는 핵심 메시지는 지금까지 내가 해온 고민과도 맞닿아 있었다.

여러분은 설계를 어떻게 하고 계신가요?