- 활동 내용 : GDSC Core Member Session 1
- 진행 일자 : 2022년 11월 14일 월요일
이번주 월요일에 GDSC 코어 멤버 세션으로 Spring과 OOP에 대해서 발표했습니다. 발표 영상을 첨부하고 싶었으나 녹화를 깜빡한 관계로 슬라이드와 대본을 함께 올립니다.
주제 선정 동기
스프링 입문과 심화 스터디를 진행하면서, 스프링은 객체지향 프레임워크이니 OOP가 무엇인지 알고 계셔야 한다고 언급하며 읽어보면 좋은 링크를 드렸었습니다. 그래도 이왕이면 한번 날을 잡고 OOP 이야기를 하고 싶었고, 저 스스로도 정리가 필요하다고 생각했기 때문에 OOP를 주제로 정했습니다.
목표 설정
이 발표의 목표는 다음과 같습니다.
1. 객체지향이 패러다임이라는 것을 인지하기. 객체지향의 핵심 개념(다형성, 캡슐화 등)이 왜 등장했는지, 객체지향 프로그래밍 언어의 문법이 존재하는지 생각해보도록 유도하기
2. 스프링이 어떻게 객체지향을 적용했는지 알아보기
3. (본인이) 스프링을 왜 시작했는지, 어떻게 공부했는지 궁금해하시는 분들이 계셔서 나의 경험 공부하기, 일종의 가이드라인 제공하기
내용 구상
발표 내용은 다음과 같이 구상했습니다.
1. 객체지향 패러다임 설명 : 객체는 협력하기 위해 존재하며, 메시지로 협력한다.
2. 스프링에 객체지향이 어떻게 적용됐는지 살펴보기 : DI, IOC, AOP가 어떻게 객체지향을 지키는지
3. 스프링 공부 썰~ 공부하면서 느꼈던 어려움, 더 공부해야 하는 토픽 제공
구체화
발표 내용을 구체화할 때 다음 자료를 참고했습니다. 특히 <객.사.오>를 많이 활용했습니다. 또 제이 님의 aop 설명은 코드를 그대로(...) 가져왔습니다. 좋은 설명 남겨주신 분들께 정말 감사드립니다!
- 객체지향 패러다임 - 조영호 님의 <객체지향의 사실과 오해> 1장, 2장
- 스프링에 객체지향이 어떻게 적용됐는지 - 유튜브 우테코 영상들
- 스프링 공부 썰 By Me..
반응
멤버분들이 만족도 폼으로 많은 반응을 주셨습니다. 감사해요💕
멘트를 직접 오픈할 수는 없어서 다음과 같이 요약했습니다.
- 객체 지향의 주요한 개념이 어떤 맥락에서 나왔는지 알 수 있었습니다
- 단순한 사용법보다 그것이 왜 존재하는지 알 수 있어서 좋았습니다
- 경험을 들을 수 있어서 좋았습니다. 스터디 진행해주세요 / 웹 공부 커리 알려주세요
재밌는게 익명이었는데도 말투가 지문인 분들이 있어서 넘 웃겼습니다 ㅋㅋㅋㅋ
슬라이드와 발표 대본
안녕하세요, 스프링과 OOP라는 주제로 발표할 코어 멤버 민휘입니다. 스프링 스터디를 운영하면서 객체지향에 대해 여러 번 언급을 했는데, 이번 기회에 설명을 해보겠습니다. 저기 부제 스프링 공부의 어려움을 적어놓은 게 보이시나요? 객체지향 설명도 할거지만 저의 스프링 공부 썰도 같이 풀어볼 예정입니다.
이번 발표에서는 이런 얘기를 할겁니다. 객체 지향의 핵심을 짚어볼거구요, 스프링에서 객체 지향이 어떻게 사용되었는지 살펴볼거구요, 웹 개발에 입문하시는 분들을 위해 어떤 공부를 해야하는지도 함께 얘기해보겠습니다.
여러분. 요즘에 스프링 인기가 상당합니다. 스프링 공부하는 분들 엄청 늘었어요. 제가 처음에 스프링에 관심을 가지게 된 계기는 소위 네카라쿠배라고 하는 IT 대기업에서 스프링 개발자를 적극적으로 뽑는다는 소식을 듣고 이거 해볼까 관심을 가졌습니다. 실제로 스프링을 사용하는 기업을 보면 규모가 엄청 큰 프로젝트를 개발하는 IT 대기업, 혹은 규모가 점점 커져서 스프링으로 전환하려는 스타트업 기업들이 있습니다. 그런데요, 사실 우리가 단순한 서버 API를 개발할 것이라면 굳이 스프링을 사용할 이유가 없어요. 왜냐하면 동적 언어, js나 파이썬을 사용하는 프레임워크를 써보면 스프링보다 훨씬 효율적이고 빠르게 개발할 수 있습니다. 근데 왜 규모가 커질수록 스프링을 도입하려고 하는걸까요?
그 이유는 오늘의 주제이기도 한 OOP와 관련이 있습니다. 스프링은요 개발자가 OOP를 지키면서 개발할 수 밖에 없도록 강제를 합니다. 이미 스프링이 웹 개발에 필요한 공통적인 기능들을 다 추상화해놓고 서비스 로직만 개발자가 작성하도록 인터페이스를 제공해요. 우리가 OOP를 지켰을 때 얻을 수 있는 장점은 서비스 로직에 집중할 수 있다는 것입니다. 요구사항 변경에 유연하게 대처를 할 수 있게 되구요. 이러한 장점들이 프로젝트 규모가 커질수록 엄청난 힘을 발휘합니다. 개발자가 로직에만 집중할 수 있게 되니까 성능과 안정성에 신경을 쓸 수 있고요, 복잡도가 증가하는 코드를 효율적으로 관리할 수 있습니다. 결국에는 코드를 깨끗하게 유지하는데 도움이 됩니다.
제가 한번 오프라인이니까 질문을 드리고 싶은데요. 여러분은 객체 지향하면 어떤게 떠오르시나요. 막 던져주세요. (자바, 상속, 김영한(!!!!) 등의 답변이 나왔습니다)
좋습니다. 주로 많은 분들이 떠올리시는 것들이 이런 객체 지향의 핵심 개념. 그런데 여러분. 과연 이런 것들이 객체 지향을 대표할 수 있다고 생각하시나요? 다들 뭔가 조금씩 모자라지 않나요? 맞습니다. 그래서 저와 함께 객체지향이라는 패러다임을 한번 살펴보도록 하겠습니다.
조영호 님의 객체지향의 사실과 오해 라는 책에서 발췌한 문장을 읽어볼게요. ‘객체 지향 패러다임은 인간이 인지할 수 있는 다양한 객체들이 모여 현실 세계를 이루는 것처럼 소프트웨어의 세계 역시 인간이 인지할 수 있는 다양한 소프트웨어 객체들이 모여 이뤄져 있다는 믿음에서 출발한다.’ 객체 지향이 현실 세계의 시뮬레이션을 하기 위해 탄생했다는 설명은 익숙하실 것 같아요. 정말일까요? 정말 소프트웨어 객체가 현실 객체의 모방일까요? 제가 바로 다음 문장을 읽어드릴게요.
‘그러나 현실 세계와 소프트웨어 세계 사이의 유사성은 여기까지일 뿐이다. 객체지향 패러다임의 목적은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것이다. 따라서 소프트웨어 세계에서 살아가는 객체는 현실 세계에 존재하는 객체와는 전혀 다른 모습을 보이는 것이 일반적이다.’ 예를 들어 현실 세계의 전등은 사람의 손길 없이는 스스로 불을 밝힐 수 없지만 SW 세계의 전등은 스스로 전원을 키고 끌 수 있습니다. 전등이 켜져있는지 유무를 나타내는 상태 변수를 두고 메소드로 조작할 수 있겠죠. 그리고 메소드를 자신만 사용할 수 있도록 숨겨서 스스로 전원을 켤 수 있습니다.
자 그러면 주인공인 객체가 객체 지향 세계에서 어떤 의미를 가지는지 알아볼게요. 현실의 객체는 여러 개가 모이고 협력해서 공동의 목표를 이룹니다. 예를 들어 커피를 주문하는 상황에서, 손님은 커피를 주문하고, 캐셔는 주문을 받아서 주문표를 작성하고, 바리스타는 커피를 만듭니다. 커피 주문이라는 공동의 목표를 위해 여러 객체는 스스로의 책임을 다합니다. 소프트웨어의 객체는요 애플리케이션의 기능을 구현하기 위해 존재합니다. 이 기능은 엄청 크기 때문에 자신의 책임을 다하는 여러 객체들이 서로 상호작용해서 기능을 하게 됩니다. 커피 주문을 소프트웨어로 구현하면 이런 모습의 객체들이 협력하게 될 것입니다.
객체는 어떻게 협력하는지 알아보겠습니다.
현실 세계에서는 의사소통을 합니다. 객체가 사람이 아니라면, 버튼을 누르는 등 어떤 이벤트를 발생시켜 상호작용을 합니다. SW 세계에서의 객체는 메시지를 통해 협력에 참여합니다. 어떤 객체는 메시지를 전송해서 다른 객체에게 책임을 수행할 것을 요청합니다. 메시지는 객체가 무엇을 수행할 지 알려주는데요, 메시지를 처리하기 위해 객체 내부에서는 메소드를 사용합니다.
객체들이 이렇게 메시지를 통해 협력에 참여하려면 갖춰야하는 조건이 있습니다. 객체는 충분히 협력적이어야 합니다. 다른 객체의 요청을 듣거나 다른 객체에게 도움을 요청할 수 있어야 합니다. 또 객체는 충분히 자율적이어야 합니다. 자신의 행동을 스스로 결정하고 책임진다는 말입니다. 여기서 생각나는 개념이 있지 않으신가요? 바로 캡슐화인데요. 객체가 자율적이기 위해서 스스로의 책임을 메소드로 구현해서 외부에 오픈하고, 이 메소드는 객체 내부에서만 접근할 수 있는 상태를 관리합니다. 캡슐화가 이러한 자율적인 책임이라는 맥락에서 등장을 합니다.
앞에서 봤던 자율적인 책임은 굉장히 중요합니다. 왜냐하면 자율적인 책임이 결국은 협력의 품질을 결정하기 때문입니다. 자율적인 책임을 가지는 객체는 존재 이유가 명확해져요. 이 예제에서 붕어빵 장수는 반죽부터 붓든 팥부터 꺼내든 붕어빵만 만들면 돼요. 또 붕어빵 장수가 저여도 되고 여러분도 되고 교수님이 되도 상관 없어요. 붕어빵을 만드는 역할 하나만 하면 됩니다. 손님은 붕어빵 장수가 어떻게 빵을 만드는지는 상관 없고 빵만 받으면 돼요. 객체 입장에서는 자기가 약속된 책임만 완수할 수 있으면 내부에서 이걸 어떻게 구현하는지는 상관이 없어요. 이걸 우리는 다형성이라고 불러요. 주로 상속이나 인터페이스 같은걸 쓰는데, 다형성을 활용하면 협력하는 그림에서 특정 책임을 가진 객체를 얼마든지 갈아낄 수 있어요. 그렇게 되면 협력이 유연해지고 객체를 재활용할 수 있다는 장점이 생깁니다.
제가 마지막으로 강조하고 싶은건 객체 지향은 사상이에요. 사고 방식이에요. 이 사고 방식을 프로그래밍에 적용한게 OOP구요. 여기서는 코드를 정리하는 방식으로 사용이 된거에요. 그러니까 너무 문법만 냅다 공부하지 마시고 이 문법이 존재하는 목적에 대해서 한번 고민해보시면 좋겠습니다.
그러면 이제 스프링 이야기로 넘어가보겠습니다. 스프링은요 객체 지향 패러다임 위에 세워진 프레임워크에요. 무슨 말이냐면 개발자들이 객체 지향을 지키면서 프로그래밍할 수 있도록 돕는다는 뜻이에요. 스프링을 공부하다보면 크게 두 영역에서 OOP를 발견할 수 있는데요. 하나는 스프링의 핵심 원리나 MVC 패턴 등 스프링 프레임워크 자체에 대한 공부를 할 때고요, 다른 하나는 우리가 애플리케이션 코드를 짤 때 객체 지향 원칙을 지키면서 클린한 코드를 짜는 부분입니다. 이런거는 SOLID 규칙 같은거 보면서 연습해보면 되는거구요.
스프링의 핵심 원리인 AOP, DI, IOC에 대해서 훑어볼건데요. 설명이 추상적이어도 그냥 스프링에서 이 개념을 적용한 목적이 객체 지향 때문이라는걸 인지해주시면 좋을 것 같아요.
스프링을 사용하면 내가 직접 객체를 생성하거나, 객체 사이의 관계, 앞에서 살펴본 메시징을 주고 받는 그런 관계를 코드로 만들지 않아도 됩니다. 이렇게 어노테이션만 붙이면 스프링이 어딘가에서 객체를 꺼내서 주입해줍니다. 이걸 우리는 Dependency Injection이라고 합니다. 그래서 스프링을 쓰면 개발자는 객체의 책임과 관계를 결정할 수 밖에 없어요. 객체지향적인 프로그래밍을 강제하고 있다고 봐도 되겠죠.
그리고 DI가 가능한 이유는 바로 스프링이 객체를 직접 관리하기 떄문이에요. 빈(객체)을 생성하고, 의존성을 주입하고 생명주기를 관리해주는 역할을 스프링에서 컨테이너가 해주는데요. 여기서 개발자 대신 스프링 프레임워크가 객체의 제어 권한을 가지고 관리한다고 해서 제어의 역전, IOC 컨테이너라고 부릅니다. 그럼 개발자는 객체 관리에 신경 쓸 필요 없이 서비스 로직에 집중할 수 있게 됩니다.
마지막으로 AOP 보겠습니다. AOP도 객체 지향처럼 프로그래밍 패러다임인데요. 로직의 핵심 관점과 부가적인 관점을 나누고 관점을 기준으로 모듈화하겠다는 의미입니다. 무슨 소린가 싶죠? 우리가 작성한 애플리케이션 로직이 이미지처럼 생긴게 오백개 정도 있다고 가정할게요. 그리고 성능 분석을 위해 모든 서비스에 실행 시간 측정 기능을 추가하는 상황을 가정해보겠습니다. 모든 메소드에 이렇게 기능을 추가하는 게 가능할까요? 나중에 시간 측정 기능이 아니라 사용자 로그를 찍는 기능이 들어오면, 그때도 메인 로직에 하나씩 기능을 추가해야 할까요? 여기서 AOP를 적용하면, 이런 메인 서비스 로직을 제외한 기능은 부가 기능이 됩니다. 그리고 이 기능은 메인 로직과 구분합니다. 부가 로직을 수행하는 기능을 분리해두고 이 로직을 적용할 메인 로직만 지정하면 쉽게 코드를 리팩터링할 수 있어요. 이것도 역시 객체지향과 깊은 연관이 있는데요 SOLID 원칙 중에 객체는 하나의 책임만을 수행한다는 내용이 있어요. 요 원칙을 잘 지키도록 하는 것이 AOP입니다.
슬슬 저의 스프링 공부 썰을 얘기해보려고 하는데요. 저는 처음에 스프링을 지금 입문 스터디에서 쓰는 교재로 시작했어요. 그때 당시에는 그렇게 어렵다고 느끼지 않았어요. 왜냐하면 정말 사용법 위주로 공부를 했기 때문에, 스프링이 다 추상화해놓은거 착실하게 갖다 쓴 거기 때문에. 스프링이 왜 어렵다는 거야? 너무 편한데? 라는 생각을 했어요. 미친거죠.
스프링 프레임워크가 어떻게 설계됐는지 공부를 하는데 진짜 너무 너무 어려운거에요.(DI, AOP, DispatcherServlet 등) 내가 뭐가 부족해서 지금 이걸 소화 못하는지 궁금했어요. 커뮤니티 들어가서 보니까, 스프링은 지금까지 자바 웹 개발 역사에서 사용된 기술들을 객체 지향적으로 사용할 수 있도록 추상화해놓은 프레임워크다라는 거에요. 그럼 나는 지금까지 스프링이 무엇을 추상화했는지 전혀 모르는 상태에서 껍데기만 보고 있었구나. 그러니까 이렇게 어렵지. 생각을 했고 그때부터 서블릿, 자바 빈, 하이버네이트 이런 기술들을 개념적으로라도 공부를 하려고 했습니다.
제가 지금까지 스프링 프레임워크에 대해서 막 얘기를 했지만 사실 여러분 무슨 프레임워크를 사용하는지는 크게 상관이 있진 않습니다. 특히 저희 같은 주니어 준비생들은요. 중요한거는 내가 개발하는 프로그램이 어떤 프로세스를 가지고 실행되는지 알고 있는 거에요.
백엔드를 한다고 하면, 쨌든 웹에서 동작하니까 네트워크 알아야하고, 데이터 관리해야하니 DB 알아야 하고, 애플리케이션 코드 쓰려면 언어 알아야 되고요. 내가 작성한 코드의 품질을 관리하고 싶으면 테스트 코드 써야하고, 좀더 객체지향적으로 애플리케이션을 관리하고 싶으면 디자인 패턴이나 도메인 알아야 합니다. 또 프레임워크 쓴다고 하면 그것도 공부를 해야할겁니다. 스프링 쓴다고하면 자바 웹개발 기술부터 훑어야겠죠. 공부할게 어마어마하게 많습니다. 하나만 알기에도 벅찬데요. 이래서 개발자는 끝도없이 공부한다고 하나봐요. 겁이 나네요.
자 발표 내용을 세 줄로 정리해보겠습니다.
첫째. OOP는 패러다임이다. 둘째. 스프링 공부는 방대하다. 셋째. 그러니 여러분 우리 같이 열심히 공부합시다.
마지막에 홍보를 좀 하자면. 저도 바빠서 스프링 심화 스터디 참여를 거의 못하고 있어요. 너무 아쉬워서, 입문 스터디 참여하신 분들 대상으로 토비 스프링 방학 때 진행해볼까 생각중이구요. 또 요즘에 이펙티브 자바나 DDD 혹은 디자인 패턴에 관심 많은데 저와 함께 공부하고 싶으신 분들 대환영입니다. 연락 주세요. 네 이상으로 발표 마치겠습니다. 감사합니다.
