비개발자도 이해하는 객체지향 마스터 클래스 | 『객체지향의 사실과 오해』 2시간 완독

한 줄 핵심

객체지향은 AI가 만든 설계를 지시·검증하고, 책임과 협력을 기준으로 코드 스멜을 잡아내는 실전적인 설계 안목이다.

시간별 요약

1. 0:00
   시작 대기 라이브 시작을 알리고 질문 채널 사용법을 안내한 뒤, 오늘 다룰 주제인 객체지향 마스터 클래스를 예고한다.
2. 1:51
   왜 지금 객체지향인가 AI에게 코딩과 업무를 맡기는 시대일수록 결과를 잘 지시하고 잘 검증하는 능력이 중요하며, 그 바탕이 되는 개념으로 객체지향을 제시한다.
3. 5:53
   이 강의의 목표: AI 설계에서 코드 스멜 맡기 객체지향을 설명할 수 있는 수준을 넘어서, AI가 만든 설계에서 이상한 냄새를 맡고 어떤 부분을 고쳐야 하는지 짚어내는 감각을 목표로 삼는다.
4. 10:44
   오늘의 진행 순서 개념 설명에서 시작해 설계 기법을 익히고, 마지막에는 그 설계를 바이브 코딩에 적용하는 순서로 진행하며, 평가 역량에 초점을 둔다.
5. 13:29
   절차지향과 객체지향의 비교 주문 프로세스를 예로 들어 절차를 순서대로 적는 방식과 객체들을 먼저 설계해 협력시키는 방식의 차이를 설명한다.
6. 20:02
   카페 예시로 배우는 역할, 책임, 협력 손님, 캐셔, 바리스타의 상호작용을 통해 역할은 자리, 책임은 수행해야 할 응답, 협력은 그 책임들이 엮인 구조라는 점을 이해시킨다.
7. 24:13
   자율성은 책임 수행 방식을 스스로 정하는 것 책임을 어떻게 수행할지는 외부가 정하는 것이 아니라 객체가 스스로 결정해야 하며, 이 자율성이 높을수록 재사용성이 높아진다.
8. 29:12
   협력성은 God Object를 피하는 것 한 객체가 모든 일을 떠안는 God Object는 대체와 유지보수가 어려우므로, 책임을 나누고 서로 협력하도록 설계해야 한다.
9. 35:45
   추상화, 캡슐화, 다형성 추상화는 협력에 필요한 정보만 남겨 단순화하는 것이고, 캡슐화는 내부 처리 방식을 숨기는 것이며, 다형성은 같은 책임을 수행할 수 있으면 다른 객체가 와도 괜찮다는 성질이다.
10. 44:21
    자율성과 협력성이 낮을 때 생기는 문제 협력성이 낮으면 한 객체에 책임이 몰려 비대해지고, 자율성이 낮으면 외부 지시에 의존하게 되어 재사용성과 유연성이 떨어진다.
11. 46:20
    협력성에는 정답이 없다 파일을 잘게 나누는 것이 항상 좋은 것은 아니며, 협력성이 높은 구조는 이해가 어렵고 낮은 구조는 비대해질 수 있으므로 상황에 맞는 균형이 필요하다.
12. 54:28
    질문 답변 포장마차처럼 작은 상황에서는 적은 인원이 더 낫고, 책임을 나눈 뒤 상위 개념이 생기면 그때 묶으면 되며, 설계는 상황에 따라 유연하게 바뀌어야 한다.
13. 57:16
    객체지향 한 줄 정의 객체지향은 기능을 객체들의 협력으로 설계하는 기법이며, 그 핵심 성질은 자율성, 협력성, 추상화, 캡슐화, 다형성으로 정리된다.
14. 1:02:48
    쉬는 시간 질문 답변 SOLID는 객체지향의 상위 개념이 아니라 좋은 설계 원칙들을 정리한 것이며, 자율성과 협력성은 요청하는 쪽과 처리하는 쪽의 관계를 분리해 이해해야 한다.
15. 1:18:43
    1교시 복습 절차지향과의 차이, 역할·책임·협력, 자율성과 협력성, 추상화·캡슐화·다형성의 핵심을 다시 묶어 정리하고, 협력성의 균형 감각을 복습한다.
16. 1:23:04
    설계는 어떻게 하는가까지 『객체지향의 사실과 오해』는 개념과 철학을 이해하는 책이며, 실제 설계 방법은 『오브젝트』나 DDD 같은 다음 단계의 책에서 더 깊게 다뤄야 한다.
17. 1:26:25
    객체 지도 3단계 먼저 안정적인 도메인 관계를 객체 지도로 그린 뒤, 기능별로 관련 객체만 떼어 협력 구조로 옮기는 방식이 설계의 기본 흐름이다.
18. 1:35:06
    객체지향과 테스트 주도 개발 객체지향은 역할과 책임 중심이어서 테스트가 검증하기 쉬우며, TDD는 먼저 책임과 테스트를 정하고 구현을 맞춰 가는 방식으로 잘 맞물린다.
19. 1:41:10
    질문 답변 처음 정한 책임은 필요에 따라 바뀔 수 있으며, 리서치 기능처럼 비대해질 부분은 MCP로 분리하는 식으로 협력 구조를 조정하는 것이 자연스럽다.
20. 1:46:25
    바이브 코딩 적용: 인스타 할인 기획전 수집기 설계 인스타그램 게시물을 수집해 할인 기획전만 걸러 웹에 모으는 기능을 예시로, AI에게 객체 지도를 그리게 하며 설계 관점을 적용한다.
21. 1:55:31
    AI가 그린 객체 지도에서 책임이 몰린 객체 찾기 데일리 스캔잡처럼 연결이 과도한 객체를 찾아내고, 판단 기준까지 직접 쥔 부분을 분리해야 자율성과 캡슐화가 살아난다.
22. 2:06:54
    두 번째 시연 마케팅 에이전시 ERP의 리드 칸반 설계를 예로 들며, 객체 지도 기준으로 서비스가 판단까지 떠안는지, 레이어를 건너뛰는지 점검한다.
23. 2:15:37
    범위를 프론트엔드로 좁혀 다시 점검하기 범위를 프론트엔드로 좁혀 다시 보면, 커스텀 훅이 도메인 로직과 UI 결정까지 떠안는 문제가 드러나고, 토스트나 부수 책임을 분리하는 방향이 더 적절해진다.
24. 2:27:11
    질문 답변 『객체지향의 사실과 오해』 이후에는 『오브젝트』를 이어 읽는 것이 좋고, 자율성은 모든 일을 직접 하는 것이 아니라 책임 수행 방식을 스스로 정하는 것이라는 점을 다시 강조한다.
25. 2:37:59
    마무리 이번 라이브는 객체지향의 핵심 개념을 AI 설계 검증과 바이브 코딩에 연결해 본 첫 시도였으며, 앞으로 더 다듬어 계속 이어가겠다고 정리한다.

실무 인사이트

• AI에게 설계를 맡길수록 중요한 역량은 구현 능력보다 설계의 이상 징후를 가려내는 평가 능력이다.
• 객체지향을 실전에서 쓰려면 정답 설계를 찾기보다 책임이 몰렸는지, 외부 지시에 의존하는지 먼저 점검하는 습관이 유용하다.
• 바이브 코딩에서도 객체 지도와 책임 분리를 기준으로 프롬프트를 쓰면, 결과물의 유지보수성과 확장성을 크게 높일 수 있다.