7장 요약

• 기능 설계 : 사용자의 목표를 만족시키기 위해 시스템이 제공해야 할 행위를 설계하는 것. 자주 변경되는 불안정한 요소를 다룬다.

• 구조 설계 : 기능의 변경을 안정적으로 수용할 수 있는 시스템의 뼈대를 설계하는 것. 잘 변하지 않는 안정적인 요소를 다룬다.

• 도메인 모델 : 구조 설계의 기반이 되는, 문제 해결 대상 영역의 핵심 개념과 관계를 표현한 것이다.

• 개념 관점 : 작성된 코드가 도메인 모델의 개념들을 얼마나 잘 반영하는지를 바라보는 관점이다.

• 명세 관점 : 객체의 외부 인터페이스, 즉 메시지를 통해 드러나는 객체의 책임과 약속을 바라보는 관점이다.

• 구현 관점 : 인터페이스 뒤에 숨겨진 객체의 내부 데이터와 메서드 로직, 즉 책임을 '어떻게' 수행하는지를 바라보는 관점이다.

안정적인 구조설계(도메인)를 바탕으로 기능설계의 요구사항을 메시지 기반 협력으로 구현하여, 최종적으로 개념, 명세, 구현 관점이 명확하게 분리된 유연한 코드를 만드는 구체적인 과정

느낀점

팀 프로젝트와 도메인 이해의 중요성

팀 프로젝트를 진행하다 보면 팀원 간에 도메인과 프로젝트에 대한 이해가 달라 기능이나 코드가 의도와 다르게 작성되는 경험을 종종 한다. 7장에서 말하는 안정적인 '지도'를 보고 코드를 작성하려면, 먼저 팀원 모두가 같은 지도를 공유해야 한다는 생각이 들었다.

안정적인 프로그램을 만들려면 프로젝트 시작 단계에서 와이어프레임, 핵심 기능, MVP를 명확하게 정하고 모두가 동일하게 이해해야 한다. 코드와 기술적인 이야기 전에, 아이디어 단계부터 생각을 맞춰나가야 비로소 올바른 지도가 그려지고, 책에서 말하는 객체지향 설계를 제대로 수행할 수 있을 것 같다.

아직 회사에 가보지는 않았지만
회사에 존재하는 여러 시스템과 프로세스도 이러한 목적도 있는게 아닐까 한다.

프레임워크와 객체지향

프레임워크를 배울 때 흔히 "제어의 흐름이 정해져 있어 편리하다"고 배운다.
하지만 이 점이 오히려 문제가 될 수도 있겠다 생각이 들었다.

객체지향을 공부하고 프레임워크를 다시 보니, 이미 짜여있는'틀'로 보인다. 프레임워크는 작업 흐름과 그 안에서 필요한 역할들을 이미 정의해 놓았기 때문에, 개발자의 핵심 임무는 그 틀에 맞는 객체를 구현하는 것이다.

하지만 객체지향에 대한 깊은 이해가 없다면 프레임워크를 단순히 '사용'하는 데 그칠 수 있다.
역할, 책임, 협력의 관점을 이해하고 프레임워크의 안정적인 구조 위에서 확장성 높은 코드를 고민할 때, 프레임워크를 제대로 활용 할 수 있을 것 같다.

AI 시대, 개발자

요즘 AI는 코딩을 점점 잘한다.
개발자의 역할이 대체될 수 있다는 불안감이 생긴다.
이 고민에 객체지향의 관점을 적용해 보았다.

AI가 잘하는 부분은 구현 관점인 것 같다.
특정 함수를 만들거나 정해진 기능을 구현하는 작업은 매우 잘한다.
하지만 비즈니스 로직과 전체 맥락을 이해하여 시스템의 큰 그림을 그리는 개념 관점과 명세 관점은 AI가 부족한 영역인 것 같다.

어떤 객체들이 메시지를 주고받으며 협력해야 하는지, 시스템 전체의 '지도'를 그리고 유연한 구조를 설계하는 과정은 앞으로 개발자의 경쟁력이 될 수 있지 않을까? 우리가 지도를 올바르게 설계하고 구체적인 구현을 AI에게 맡긴다면, 훨씬 빠르게 성장할 수 있을 것 같다. 결국 우리는 단순히 코드를 작성하는 사람이 아니라, 시스템의 설계와 흐름, 그리고 지도를 이해하고 만드는 사람이 되어야 할 것 같다.

하지만 Cursor나 새로 나오는 AI를 보면 점점 지도를 그리기 시작하는 것 같기도 하다. 하드웨어 성능과 처리 속도가 올라가면 금방 할 수 있을 것 같기도....