웹서버 개발자(?)의 OOP 제대로 공부하기

난 부트캠프를 통해 개발 시작 3개월만에 웹 프론트 개발자로 취업을 했는데 그 당시의 난 컴퓨터의 깊은 속 사정까지 알지 못하였고 그저 요령으로만 개발을 했었다. 그러다보니 내 성향상 이게 원하던 개발이 아니란 생각이 강하게 들었고 방법을 찾던 중 포큐 아카데미에 등록할 결심을 하였다. 빠밤. 초반 COMP1500은 그래도 6개월 정도 배웠다고 만만하게 보다가 결국 실습에서 통과하지 못하는 불상사가 발생했다. 이는 뒤 수업까지 영향을 미쳤으며 4번의 수업이 되어서야 비로소 모든 실습, 과제를 제 시간 안에 제출할 수 있게 되었다.. 드디어 조교 지원 자격을 얻었다!

내가 하고있는 일

현재 신발 관련 정보 제공 어플을 만드는 회사에서 데이터 수집과 서버 구현, 유지보수, 배포 등을 맡고 있다. 실력이 좋아서라기보단 할 사람이 나밖에 없어서다. 아직은 크게 기능이 없고 사용자도 많지 않아 node.js 기반의 express 서버로 충분히 견딜 수 있다. 다만 데이터가 많아지고 제휴 맺는 업체가 늘어나 유저가 늘어남에따라 좀 더 안정성 있고 유지보수하기 쉬운 서버를 만들어야할 필요가 있었고 결국 내가 개발해야하는 것이기에 회사의 성장과 동시에 나의 성장도 반드시 필요한 상황이 되었다. 데이터 수집 부분에서 node.js에서 작동하는 puppeteer를 사용하고 있는데 chromium이라는 꽤 무거운 외부 프로그램을 사용하다보니 한 번 구현을 해놓아도 생각보다 여러 문제가 ~~내 속과 함께~~ 팡팡 터졌다. 자동으로 데이터를 수집하게 구현하려면 chromium이란 프로그램이 꺼지지 않아야 하는데 자꾸 꺼져서 데이터가 수집되지 않는 상황이 빈번하게 터졌고 이는 해당 과목을 들으면서 좀 더 멋있게(?) 구현하여 지금은 꽤 안정적으로 돌고 있다.

또 다시 포큐 아카데미

갑자기 다시 일을 하는 바람에 ~~네.. 핑계입니다~~ 저번 알고리듬(COMP3500) 과목을 실패하였고 수업료를 버렸단 생각에 다음 학기에 대한 계획을 세우지 않았고 이는 4개월 간의 자유이자 방황의 시간으로 나를 이끌었다. 시간이 많아질 수록 생각은 많아졌고 생각은 고민으로 고민은 나를 방황케 했다. 그렇다고 시간을 아예 버렸냐고 한다면 그건 아니다. 나의 성향상 특정 기술을 내부 지식 모르고 사용하는 건 스타크래프트의 show me the money 쓰는 것과 비슷하게 느껴졌고 결국 아직 기본이 부족하니 이를 보충하잔 결론을 냈다. 그렇다고 대학을 다시 들어갈 순 없는 노릇이고 ~~일하면서 돈벌어야지!~~ 결국 다시 포큐 아카데미에 등록하게 되었다.

OOP란 단어는 코딩을 몇 달 정도 경험해본 사람이라면 수없이 보았을 단어이다. 나도 해당 수업을 듣기 전까지 OOP란 단어를 개발 문서에서든 특정 채용공고에서든 책에서든.. 수없이 많이 보았고 어느 정도 단어에 익숙해졌을 때 내가 듣고있던 강의에서 OOP에 대해 설명을 해주었고 거기서 OOP의 개념을 처음 배우게 되었다.

"OOP는 캡슐화, 상속, 추상화, 다형성이란 4개 개념이 있고 캡슐화는 데이터 내부 개체를 묶어서 캡슐처럼 만드는 것이며... 블라블라"

? 그래서 뭐 어쩌라고 ?

마음 속에서 나오는 답답함을 꾹꾹 누르며 견뎌! 보았지만 OOP의 개념을 이해하기엔 내 실력과 강의 내용이 너무 부족했다. 물론 프로그래밍 특성 상 개념보단 실제 구현에 초점을 맞추는 것이 맞지만.. ~~아~ 그래도 뭘 알려줘야죠~~~ 너무 추상적이었다. 이것이 나의 OOP에 대한 첫 학습이었다. 뭐 개념을 알긴 아니깐 다른 문서나 자료에서 OOP를 볼 때 크게 신경쓰지 않았었고 이는 디자인 패턴을 만나고서야 다시 OOP에 대한 중요성을 느끼게 되었다. 디자인 패턴이 중요하다! 짱이다! 라는 말을 하게되면 강사님께 여러 소리 들을 거 같다. 그냥 디자인 패턴을 보고 아 이건 OOP가 전제 되어야 이해할 수 있겠구나! 라고 생각한 거다. 혼자 개발해야하다보니 빠르게 하는 것이 무엇보다 중요했다. javascript 언어의 특성 상 여러 프로그래밍 패러다임으로 구현할 수 있었고 OOP 개념을 다 배워 멋있는 코드를 짜려고 한다면 따가운 시선을 견뎌야할 것이 분명하기에 이런저런 생각 없이 C언어 스타일로 한 스크립트에 여러 함수를 호출하는 방식으로 구현하고 고치고 수정하고를 반복했다. 뭐 대단한 프로그래밍이 아니라 충분하긴 했지만. 아무튼 이대로 있으면 내 경력이 똥과 만날 거 같아서 우선 javascript를 이용한 설계 같은 책들을 살펴 보았다. 다 보진 않았지만 여기서 얻은 건 OOP에 대한 전반적인 개념보단 javascript란 언어에 무게가 실려있어 살포시 내 침대 밑 책장에 다시 넣어 뒀다. 그리고 재빨리 포큐 아카데미의 OOP 결제를..

처음엔 강의부터 결제하여 이미 3번의 수업을 들어본 경험으로 실습은 내가 스스로 해보고 강의를 잘 정리 해보자! 란 자만으로 강의만 들었었다. 아.. 그냥 빨리 풀코스 들을 걸.. OOP의 개념은 말 그대로 개념일 뿐이었다. 강의 내에서 분명히 괜찮은 예시 코드가 있지만 그 코드만으로론 부족했고 따로 내가 하고 있는 일에 적용하자니 막막했다. 어영부영 시간을 보내다 다시 풀코스 결제를.. 하게 되었다.

구조적 프로그래밍과 OOP

수능 독서 지문에서도 중요한 내용은 강조하기 위해 비교 대조를 사용한다. 한 가지 견해 혹은 사실을 보는 것보다 더 기억에 남고 이해가 될 것이라 생각해서지 않을까 싶다. 요즘에 난 구글보다 gpt에 먼저 검색한 뒤 해당 키워드가 맞는지 구글링을 해본다. 블로그엔 내가 원하는 질문에 대한 답변이 없기에 gpt가 잘못된 답변이든 정확하든 내 질문에 대한 답은 해주기 때문이다. 구조적 프로그래밍과 객체지향 프로그래밍에 대해 설명해달란 질문을 했더니 다음과 같은 답변을 받았다.

C# 처음 배웠을 당시 static이란 개념을 이해하지 못했다. 강의에선 그냥 C언어처럼 사용하는 키워드라고 설명하며 나중에 이해될 거라고 했다. 이는 OOP를 배우고 나니 명백히 이해가 되었다. 기본적으로 객체지향적으로 프로그래밍 함에 있어선 static은 필요하지 않다. 그렇지만 static 기능과 같은 것이 필요할 때 static 기능을 쓰지 않고 다른 방법을 통해 사용하는 건 효율적이지 못하다고 볼 수 있다. 모든 공학엔 경제학적 개념이 들어간다. 운영체제를 보면 한정된 자원으로 최대 효율을 사용하려는 노력을 볼 수 있다. 다만 효율적이란 것이 오롯이 기계에만 적용되는 건 아니다. 성능을 포기하더라도 사람 사이의 소통을 위한 프로그래밍 패러다임인 OOP는 기계적으로 효율적이진 못하나 더 큰 제품 구현을 여러 사람들과의 협업함에 있어서 효율적이기에 사용한다. 어쨌거나 static의 기능 뿐만 아니라 OOP에서 static이 갖고 있는 의미까지 해당 수업을 통해 이해할 수 있었다.

개체지향 프로그래밍 (OOP)

처음 개념을 배웠던 것과 다르게 포큐 아카데미의 OOP 수업은 내용이 정말 많았다. 일반인은 모르는 수많은 디테일을 알고 있는 사람을 우리는 전문가라고 부른다. 이전에서 볼 수 없었던 수많은 디테일들을 강의에서 볼 수 있었고 4개의 수업 중 가장 강사님의 오랜 고민 흔적을 많이 볼 수 있는 강의였다. 너무 칭찬만 했나..? 근데 진심 경험에서 얻어야하는 부분을 가장 잘 정리하고 설명해주는 강의라고 생각합니다..

제일 좋았던 부분은 여러 수많은 의견들을 정리해주었고 OOP를 어떻게 바라볼 수 있는지 관점을 심어 주었다. 주관적인 것들은 다양한 의견이 붙으며 이는 같은 언어를 사용해도 의미 또한 다를 수 있다. 강사님이 설명해주신 내용을 나만의 언어로 잘 정립하고 나니 여러 문서를 보더라도 흔들리지 않고 이해할 수 있게 되었다. 혼자 공부할 때 캡슐화와 상속 추상화까진 꽤 구체적인 가이드가 있었기에 대략적인 느낌으로 이해는 했다. 캡슐화는 필요하지 않는 상태나 동작을 숨기면 되고 상속은 공통된 부분을 묶어주면 되고.. 추상화는 단어 자체가 추상적이었지만 그래도 외부에 노출한 상태와 동작만으로 추상화를 시켜준다... 등 대충 이해한 거 같다. ~~지금은 처음 이해했을 때와 달라서 처음에 어떻게 이해했는지 기억이 잘 나진 않는다.~~ 하지만 다형성이란 개념은 크게 와닿지 못했다. 이것저것 다형성에 대해 검색해봐도 확 와닿는 부분은 없었다. 시간이 지나 다형성에 대해 배우고 이것저것 검색을 하던 시기가 있었다. typescript에선 OOP에 해당하는 다형성을 어떻게 사용하는지 궁금하여 구글에 "typescript 다형성"이란 키워드로 검색을 해보았더니 여러 블로그 글에서 다형성을 다음과 같이 설명하였다.

만약 내가 이 수업을 듣지 않고 해당 문서를 보았다면 다형성은 제네릭을 구현하기 위해 필요하구나! 하고 휙 넘어가버릴 수도 있었을 것이다. 강의 내용에 위 내용에 대한 언급이 있긴하다. 애드혹 다형성과 매개변수 다형성이란 단어로 소개를 해준다. 다만 이는 OOP에 핵심적인 다형성을 뜻하는 것이 아니다. 그저 typescript의 특성으로써의 기능을 블로그에 소개한 것으로 보인다. 그래서 난 해당 글을 보고 왜 다형성을 저렇게 설명했지 생각하며 아 OOP에 초점을 둔 것이 아닌 그저 typescript의 기능에 초점을 맞춘다면 여러 기능을 소개할 것이고 그 중 매개변수 다형성을 다형성으로 설명했겠구나란 생각을 할 수 있었다. typescript가 OOP만을 위한 프로그래밍 언어 혹은 컴파일러가 아니기에 충분히 다형성을 저렇게 설명할 수 있다고 생각한다. 그저 다형성을 모르는 사람에게 살짝 오해의 여지가 있기에 언급해봤다.

그럼 다형성이란 키워드만을 구글링해보면 어떨까?

수업을 듣기 전에 검색해본 적이 있겠지만 기억이 안난다. 쨌든 수강 전에 OOP의 4개 개념을 따로 검색하여 공부했다면 나는 꽤 오랜시간 다형성에 대해 이해하지 못했을 것이다. 마지막 부분에 애드혹 다형성, 매개변수 다형성, 하위형 다형성의 의미가 중요도 순이 아닌 A -> P -> S 사전적 순서로 병기되어 있었고 여기서 다형성의 의미를 이해하기엔 무리가 있어 보였다. 수업에서 강조하는 건 Subtyping이다.

단순히 정확한 개념을 알려주는 것에 그쳤다면 이렇게까지 후기를 쓰지도 않았을 것이다. ~~후기 이벤트 때문도 있지만..~~ 해당 수업은 단순히 OOP만을 알려주는 과목이 아니고 제목에도 있다시피 설계가 실습과 과제에 포함된다. 여러 OOP 개념을 다향한 방법으로 설계하는 경험을 가질 수 있을 것이고 이는 코드를 한층 더 깊이 이해하는 힘을 주었던 거 같다.

상속에서 시작해 인터페이스 ,좋은 설계까지

강의를 따로 들었을 때는 몰랐었는데 시험을 위해 복습하던 중 강의에서 꽤 큰 흐름을 하나 발견했다. 이는 상속에서 다형성, 다형성에서 추상 클래스, 추상 클래스에서 인터페이스, 인터페이스에서 좋은 설계와 여러 디자인 패턴까지.. 내용 하나하나가 해당 단계에서 궁금하거나 해결책을 바로 뒤에 나오게 강의를 설계하신 거 같아 강사님의 강의 제작 능력에 한 번 더 놀랐다.

위에서 보다시피 다형성은 상속을 전제한다. 다형성의 하나의 타입으로 자식 개체들을 참조하려면 반드시 필요하기 때문이다. 상속을 사용하여 다형성을 구현하게 되면 여러 문제가 생기게 되는데 예를들어 실제 인스턴스화 시키지 않을 클래스를 찍어낼 수 있게 된다. 실제 개체로 만들지 않을 클래스를 찍어낼 수 있는 건 협업을 함에 있어서 하지 않아도 될 행동을 할 수 있게 남겨둠으로써 이상한 짓을 해버릴 수 있는 상황을 만들게 된다. 하지 않는 게 좋다는 뜻이다. 여기서 추상 클래스에 대한 개념을 설명하며 문제를 하나 해결한다. 또 하나의 다른 문제는 추상 클래스 또한 너무 과할 수 있다는 것이다. 간단한 함수만 사용하게 강제하고 싶은데 추상 클래스를 사용하는 것은 좀 과하지 않나 싶은 것이다. 여기서 나온 것이 인터페이스이다. 인터페이스가 해당 목적만을 위해 나온 건 아니라고 설명하지만 순수 추상 클래스로서의 인터페이스를 이런 흐름으로 설명한다.

인터페이스의 뜻을 찾아보면 프로그래밍에 적용하기에 너무 추상적인 내용이다. 저 문장만을 보고 인터페이스를 잘 쓰는 사람은 세상에 없지 않을까? 인터페이스란 용어는 실생활에서도 매우 자주 사용되며 프로그래밍에 있어서도 꽤 다양한 뜻으로 사용된다. 프런트 개발을 하면 UI란 단어를 들어봤을 것이다. 이를 사전적 정의와 함께 생각해본다면 사용자와 신호를 주고받는 경계면으로 풀이할 수 있는데 요즘 많이 보이는 키오스크가 이 의미를 가장 잘 나타내는 것 같다.

출처 : http://www.koit.co.kr/news/userArticlePhoto.html

프로그래밍에서의 인터페이스는 주로 API라고 불리는 Application Programming Interface에서 주로 사용된다.

간단하게 두 프로그램 사이 데이터를 교환할 목적으로 만들어진 경계라고 생각하면 될 것 같다. 예를들어 A란 어플리케이션에서 카카오톡의 지도를 사용한다고 할 때 카카오톡이 설계해놓은 API의 규칙을 지킨다면 A 어플에서 해당 기능을 사용할 수 있다.

다음은 자바 언어에서 제공하는 인터페이스에 대해 설명해놓은 글이다.

출처 : http://www.tcpschool.com/java/java_polymorphism_interface

이처럼 인터페이스는 다양한 의미를 가지며 실제 내가 사용하는 인터페이스가 무엇인지 잘 파악하고 구현해야 할 것이다. 강의에선 인터페이스의 사전적 정의부터 실제 프로그래밍에 어떻게 적용되며 어떻게 받아들여야하는 지까지 매우 자세하게 설명을 해주었다. API가 의미하는 인터페이스와 자바 언어 자체 기능으로서의 인터페이스 그리고 OOP에서 주로 이야기하는 인터페이스까지 프로그래밍에서도 다양한 개념을 잘 정리할 수 있었다. 위에 설명에서도 인터페이스를 통한 다중 상속 구현을 언급하는데 이는 강의에서 보다 자세히 배울 수 있을 것이다. 상속을 설명할 때 다중 상속에 대한 문제점을 다루는데 이는 인터페이스를 통해서 해결할 수 있다고 제시해준다.

또한 여기서 포큐 아카데미의 장점이 나오는데 앞 과목에서 배운 내용을 뒤에서 버리지 않고 연결시켜주는 것이다. 컴퓨터 공학이란 학문이 각각의 과목으로 뚜렷하게 나뉘지 않는 만큼 다른 과목을 알아야 설명할 수 있는 부분이 있을텐데 포큐에선 놓치지 않고 설명해준다. 난 이전 학기에 C 언매니지드 언어를 배웠기에 함수 포인터에 대해 이해하고 있었다. 여기서 자바의 인터페이스와 C언어의 함수 포인터에 대해 비교하며 한 번 더 인터페이스의 쓰임에 대해 이해할 수 있었다. 바인딩에 대한 개념 설명을 시작으로 실제 컴파일, 런타임에 어떻게 프로그램이 동작하는 지 알게되는 계기가 되기도 하였다.

출처 : https://velog.io/@marintelli/%ED%95%A8%EC%88%98%ED%8F%AC%EC%9D%B8%ED%84%B0void%ED%8F%AC%EC%9D%B8%ED%84%B0

함수 포인터란 함수의 선언(함수명, 반환형, 매개변수 형 목록)만으로 해당 함수를 호출할 수 있고 이는 실제 어떤 함수인지 몰라도 컴파일이 되어 실행파일까지 나온다는 뜻이며 실제 어떤 함수인지는 런타임 시점에 알 수 있다.

출처 : https://www.geeksforgeeks.org/dynamic-binding-in-cpp/

바인딩은 함수 호출과 함수 정의를 연결하는 것으로 컴파일 시점에 연결되는 것을 이른 바인딩, 런타임 시점에 연결되는 것을 늦은 바인딩이라고 하며 C언어의 함수 포인터나 자바의 인터페이스는 늦은 바인딩에 해당된다고 할 수 있다.

여기까지 배우고 나면 인터페이스의 쓰임이 궁금해진다.

그래그래 인터페이스 알겠는데 어디에 쓰는데??

이런 궁금증이 생길 시점에 강의는 좋은 설계에 대해 설명한다. 인터페이스를 사용하거나 추상 클래스 혹은 더 높은 단계의 부모 클래스에 의존하여 설계를 하면 코드는 유연해지는 것은 맞다. 다만 극단적으로 가지 말라며 조언하며 여러 근거들을 들어 합리적인 판단을 유도한다. 자세한 내용은 강의에서 다루지만 결국 강의가 하는 말은 밸런스를 잘 갖추는 것이 중요하다고 한다. 유연한 설계의 극단은 모든 클래스에 인터페이스를 설계하는 것이고 유연하진 않지만 최적화된 설계의 극단은 모든 내용을 하나의 클래스에 구겨 넣는 것이다. 우리는 이 중간 지점을 잘 찾아 설계해야 하며 중간 지점은 많은 경험을 통해 찾을 수 있다고 한다. 기본기는 결국 많이 만들어 보고 피드백하며 쌓아지는 것이다.

이 다음으론 디자인 패턴에 대해 설명한다.

출처 : https://refactoring.guru/ko/design-patterns/catalog

보통 디자인 패턴 강의는 여러 디자인 패턴을 소개하며 어디에 적용되는지 실습으로 마무리 한다. 포큐 아카데미는 디자인 패턴을 절대 사용하지 말라고 한다.

디자인 패턴을 먼저 배우고 해당 패턴을 적용하는 방식의 공부법은 이미 디자인 패턴이 나온지 오랜 시간이 지났음에도 실효성이 크게 없었고 오히려 잘못된 패턴 사용으로 인해 더 큰 문제를 일으켰다고 한다. 프로그래밍 업계에서 사람을 뽑을 때 뽑고싶은 개발자보다 뽑으면 안되는 개발자를 걸러내는 것이 훨씬 중요하다고 하는데 이런 예시가 있어서인건가?

그렇다고 디자인 패턴은 절대 사용하면 안된다가 아니라 여기서 또 기본기를 강조하여 디자인 패턴을 봤을 때 이미 해당 방법으로 구현을 해보았을 때 사용하라는 이야기를 해준다. 즉, 패턴을 배워서 사용하기보다 개발에 어떤 문제에 봉착했을 때 해당 문제에 적합한 해결책을 찾다보면 자연스럽게 디자인 패턴을 알게 될 것이고 이것이 더 기억에 남을 것이며 잘못된 디자인 패턴의 사용 또한 예방할 수 있을 것이다. ~~그렇다고 시험에서 출제하지 않진 않아요..~~ 내가 실제 일하면서 써본 패턴은 구독 발행 패턴이다. 옵저버 패턴보다 한 차원 위의 개념이며 이는 요즘 대세인 Micro Service Application (MSA)에서 자주 사용한다. 구독 발행 패턴이란 특정 사건(상태 변화 혹은 동작)이 발생했을 때 구독자들에게 알려주는 설계로 알림 기능에서 주로 사용한다.

출처 : https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber

현재 회사 어플도 알림 기능이 있으며 특정 게시글이 업로드되면 알림을 켜놓은 모든 유저들에게 전체 알림을 보내야하는 구조이다. 따로 구독자들을 모아놓은 데이터베이스가 존재하진 않지만 게시글이 업로드 되면 생성된 producer 인스턴스를 통해 send를 하여

consumer 인스턴스에서 콜백함수 핸들러를 통해 이벤트를 처리하는 구조이다.

여기서 핸들러에 구독자들에게 특정 알림을 보내게끔 설계를 하였고 이는 메인 서버의 부하를 분산하고 알림 서버와 메인 서버의 결합도를 낮추어 특정 서버에 장애가 나더라도 다른 서버에 지장을 주지 않는 효과를 얻는다. 알림 서버 구현이란 과제를 맡았고 어떻게 구현할까 여러 자료를 찾아보다 보니 결국 구독 발행 패턴과 유사한 설계로 이어졌다. 이 경험으로 인해 강사님의 말에 좀 더 설득 되었던 거 같다.

마지막으로 SOLID 설계 정신을 소개로 OOP에 대한 개념은 마무리가 된다. SOLID 또한 앞에서 말했던 개념에서 벗어나지 않은 관점으로 천천히 설명해주고 어떻게 해당 정신을 받아들일지 또한 생각하게 되었다.

타입스크립트와 Nest.js에서의 OOP

OOP 수업을 들으며 따로 공부했던 typescript를 간략히 소개하면 javascript로 바꿔주는 컴파일러와 동시에 문법을 갖고있는 프로그래밍 언어이다. 모든 브라우저의 동적 움직임은 javascript 문법을 통해서만 실행된다. javascript 언어 자체는 타입이 없어 혼자 개발한다면 모를까 여러 사람과 협업하기에 좋은 언어는 아니지만 이미 커버린 javascript 생태계와 생태계가 커짐에 따라 javascript를 사용하는 소프트웨어 규모도 커졌기에 프로그래밍 언어에서 지원하는 타입이 필요하는 상황이 되었다. 그렇게 탄생한 Typescript는 웹 프런트 개발자 뿐만 아니라 Node.js를 사용하는 웹 서버 개발자들도 많이 사용하는 언어가 되었으며 회사 지원 자격으로 필수로 언급되고 있다.

Java의 스프링을 사용하여 웹서버를 구현하는 것이 진리였지만 에자일 개발과 소규모 스타트업의 성공 사례(?)들이 늘어남에 따라 빠르게 개발하고 고객의 반응을 보는 것이 대세가 된 거 같다. 개인적인 생각이고 통계를 낸 것은 아니다. 이런 대세에 가장 잘 부합하는 Node.js가 적절한 시기에 떠올랐고 javascript만을 사용하여 프런트와 서버 둘 다 개발할 수 있다는 건 개발자들에게 아주 큰 매력으로 다가왔다고 한다. Node.js는 js의 런타임 환경이며 웹브라우저와 거의 비슷한 api를 가지고 있고 아주 빠르게 서버를 구현하여 배포할 수 있다. 거기에 express란 패키지를 사용한다면 5분도 안되어서 로컬 환경에서 접속 가능한 서버를 구현할 수 있을 것이다. 하지만 규모가 좀 있는 프로젝트에 있어서 js 언어는 너무 자유롭고 설계도 사람마다 회사마다 너무 달랐다. 괜찮은 웹서버를 구현하는 데에 있어서 설계 패턴을 미리 잡아주는 것은 꽤 좋은 방법이었고 거기서 탄생한 것이 Nest.js 인 거 같다. 어쨌거나 Nest.js는 여러 디자인 패턴과 OOP를 사용하게끔 디자인 된 프레임워크였기에 해당 수업과 병행하기에 괜찮았다. 다만 Nest.js를 OOP를 모르고 공부하기엔 설계 자체가 패턴으로 덕지덕지 쌓여있는 프레임워크이기에 좀 어려울 수 있다.

Nest.js의 철학을 보면 해당 강의에서 언급한 OOP의 장점을 아주 잘 사용하고 있는 거 같다. 테스트에 용이하며 확장성 있고 결합도를 낮추며 유지보수가 쉬운 설계를 유도한다. 대부분의 서버가 요청을 보내고 그에 대한 응답 하는 방식으로 많이 설계를 하기에 이런 프레임워크가 나올 수 있지 않았나 싶다. 어쨌든 Nest.js는 결합도를 낮추기 위해 모듈성 있는 코드를 지향하며 직접적으로 객체에 의존하지 않고 의존성 주입을 통해 느슨하게 결합한다.

예외 상황과 Exception

OOP는 아니지만 비중있게 다루는 개념이 예외 상황과 처리이다. 이는 프로그래밍에 있어서 아주 중요한 부분으로 특히 외부 라이브러리를 사용할 경우 내가 컨트롤하지 못하는 부분을 처리하기 위해 주로 사용된다. 해당 강의를 듣고 그동안 만났던 문제들을 많이 정리할 수 있었다. 우선 나는 지금까지 예외가 날 수 있는 부분 모두에서 try catch를 사용하였고 이는 디버깅에 있어서 아주 큰 문제를 야기했다. 이게 try catch가 각 함수마다 덕지덕지 쌓여있다 보니 구체적으로 어디에서 어떻게 예외가 발생했는지 알기가 너무 힘들었고 결국 구조를 바꾸기 전까지 해당 문제를 해결하지 못하였다. 물론 에러 발생 스택을 파일에 기록해뒀다면 그나마 괜찮았을 텐데 에러 메세지를 내가 직접 설정하여 어디서 해당 위치를 먹어버려서 생긴 문제였다. 난 아직까지 메모리 덤프같은 기능을 쓸 기회가 없기에 강의에서 언급하는 에러 개체만으론 충분하지 않을 수 있다는 것에 와닿진 않았지만 에러를 먹어본 경험자로서 조금은 이해할 수 있었다. 또한 크로미움을 사용하여 웹 페이지를 조작하게 되면 크로미움에 대한 제어권을 100% 갖지 못한다. 만약 크로미움의 페이지 인스턴스가 꺼지던가 브라우저 인스턴스가 꺼진다면 나의 서버에 올려놓은 코드는 작동되지 않는다. 거기에 크로미움 내부에 javascript 코드를 주입한 코드에서 에러가 발생한다면 이는 나의 프로그램 스택에서 난 에러가 아니라 크로미움에서 난 에러이기에 로깅을 보면 해당 크로미움에서 에러가 낫다고만 남아있고 어떤 에러인지 알기 쉽지 않았다.

위 메세지를 보면 brwoser 인스턴스가 꺼졌다거나 page가 종료되었다는 내용이 있다. 여기서 브라우저 인스턴스를 다시 켜주는 코드를 짜줘야할지 해당 코드는 특정 분마다 작동되게 해줘야할지 아니면 기능 실행 전마다 매번 체크 후 실행해줘야할지 등등 이런저런 경우들을 생각하여야 했다. 해당 강의를 통해 제시한 설명을 나의 프로그램에 잘 적용하여 현재는 큰 문제 없이 잘 돌고 있다. 너무 행복..!

간단 회고

이게 실습 과제는 제출이 무제한이다보니 로컬 환경에서 최대한 테스트를 해보고 제출했어야 하는데 그냥 실수한 거 같은 부분 띡 고치고 제출하고 실패하고 제출하고 실패하고.. 무의미한 제출 횟수만 늘렸던 기억이 있다. 단순히 귀찮아서 그랬다. 반성한다.

그리고 다른 수강생 분들의 코드도 좀 보고 리펙토링도 좀 해봤어야 하는데!!! 과제3에 시간을 너무 써 제출 이후로 여유가 사라졌다.. 직장다닌다고 핑계를 대기엔 노는 시간이 너무 많았지..? 나름 그래도 다른 수강생 분들의 질문과 답변은 무조건 봤었고 내가 지나쳤던 부분을 알 수 있는 좋은 기회가 되었다.

실습 과제를 100% 받으면 주어지는 다이아몬드 뱃지와 토론을 열심히(?) 하면 주는 메딕이란 뱃지를 받았다. 다이아몬드 뱃지는 노력만하면 받을 수 있는건데 일정 관리..? 를 못해서 3과목에서 한 번도 받지 못했는데 드디어 받아본다. 뿌듯한 느낌. 메딕은 생각보다 슬랙에서 활동을 하지 못했는데 주어져서 그냥 기분은 좋다. 원샷 원킬은 실습, 과제를 한 번에 통과하면 주어지는데 테스트를 많이 하지 않고 제출해서인지 비교적 쉬운 실습에서도 한 번에 통과하지 못했다. 담엔 원샷 원킬을 좀 더.. 또 중간고사에선 꽤 좋은 성적을 받았다.

1%는 못들고 5% 정도에 든 것으로 보아 수능으로 치면 1등급을 턱걸이로 받았다. 중간고사에서 강의를 들으면서 여러 생각들을 많이 해보았고 예제 코드도 만들어보고 그랬다. 코딩 쓰기 능력과 읽기 능력을 적절히 평가하며 실습과 과제만으론 좋은 점수를 받기엔 조금 부족하지 않나 싶다. 왜냐면 난 기말고사에서 중간고사 만큼 잘 보진 않았기에..

수능으로 치면 2등급 정도? 이땐 과제3 하느라 강의를 듣되 막 여러 예제를 쳐보지 않았고 실습과 과제하기에 급급했다. 토일 주말을 다 썼는데도 과제3을 100% 못받아서 좀 슬펐다.. 평일엔 일에 집중력을 쓰느라 쌩쌩한 머리는 주말밖에 안나오는데!

그래도 최종 점수는 만족스럽다.

저 분도 0%를 받으셨나보다. 아마 그냥 1등은 아닌 듯..? 싶다.

포큐 아카데미에 중독된 거 같다. 대학을 1학기 다니고 중퇴하였고 고등학교 때까진 공부에 흥미가 크게 없었다보니 시험 공부의 재미를 나이 먹고 느낀다. 수업 듣고 실습, 과제하고 가끔 토론도 하고 이렇게 후기도 쓰고.. 좋은 플랫폼을 만들어주신 강사님께 큰 고마움을 느낀다.

다음 학기 수업을 듣는다면 좀 더 공부하고 질문하고 답변하고 다른 분들과 소통하고 싶다. 회사 규모가 작다보니 개발 이야기할 사람들이 별로 없기도 하고 일 마치고도 개발 이야기하면 일 얘기하는 것 같아서..

객체지향 언어 및 설계을 듣지 않고 바로 알고리듬과 자료구조?

과거의 나에게 닥치고 객체지향 언어 및 설계를 먼저 들어!라고 말하고 싶다. 코딩 테스트 경험이나 알고리즘 자료구조의 경험 혹은 꽤 많은 실무 경험으로 코딩에 아주 익숙한 분은 바로 알고리듬을 들어도 될 것이다. 다만 이건 알고리듬을 들어도 되냐 안되냐의 기준이고 OOP의 경험이 없다시피 한 분들 모두에게 OOP 강의를 강추강추강추 한다. 해당 강의를 통해 OOP에 대한 괜찮은 관점을 잡고 그 후로 여러 패턴과 설계들을 차곡차곡 잘 쌓는다면 보다 코딩을 더 아름답게 할 수 있을 거라고 믿고 있다.

아아.. 성적표에 F가 있는 것이 상당히 거슬린다.. 언제 재수강해서 리셋할까... 다시 강의료를 태우기엔 부담이..

앞으로의 계획

해당 수업을 들었다고 해서 OOP를 잘 할 수 있냐고 묻는다면 아뇨? 우선 배운 내용을 토대로 다양한 제품을 만들어 볼 생각이다. 재밌어 보인다면 따로 사이드 프로젝트로라도 OOP를 이용한 설계를 해봐야 좀 더 익숙해질 거 같다. 자료구조도 통과하지 못했으니 다음 수업을 시작하기 전까지 C언어 복습 조금 하면서 자료구조를 공부하지 않을까..? 싶다.

아직까지 나의 진로를 결정하지 못했다. 웹 프런트엔드(리액트)를 시작으로 백엔드(노드js)를 현재 맡고 있는데 그렇다고 백엔드를 커리어로 결정하기엔 아직 해보고 싶은 분야가 많다. 게임 클라이언트 개발도 해보고 싶고 앱 개발은 Flutter로 해봤지만 네이티브로 어떤 api가 있는지도 궁금하고 게임 서버 개발자로 실시간 통신은 어떻게 구현하는지 궁금하다. 거기에 요즘 대세인 인공지능이며 머신러닝이며 궁금한 분야가 너무 많다. 그래서 더욱 더 기본기를 강조하는 포큐 아카데미에 끌리는 거 같다. 우선 기본을 탄탄하게 다지면서 여러 분야를 조금씩 접해보고 내가 가장 몰입할 수 있고 잘할 수 있는 분야를 결정하려고 한다. 그러기 위해 아직 전공 지식을 다 배우지 못하였기에 다음 과목을 바로 들으려고 한다. C++과 어셈블리어를 고민하고 있지만 아마 어셈블리어를 선택하지 않을까 싶다. 지금 세일중이다.ㅋ 해당 어셈블리어, C++ 언어를 배우고 나면 어느 정도 기반 지식의 초석이 다져졌을 거 같아 응용 분야를 조금씩 다뤄볼 예정이다. 그래도 회사일은 열심히 해야지! 다음엔 어셈블리어!

수강생 미세팁

1. POCU 강의 할인은 1년에 2번 정도 한다고 포프님이 말씀 하셨고 여름엔 무조건 할인을 한다. 이번엔 시기를 놓쳐서 구매하지 못하였지만 다음 번에 들을 과목이 세일을 한다면 시기에 맞춰서 사놓을 것이다. 저번 후기에서도 언급했지만 캐나다 달러로 결제하면 카드 수수료를 감안해도 조금이라도 더 아낄 수 있다.

https://pocu-ko.teachable.com/?referral_code=C18JVD 강의가 처음이신 분들은 해당 링크에서 구매하면 15% 할인받을 수 있다! 당신도! 나도!

2. 항상 해당 주차마다 질문을 받아주시는데 이번엔 질문을 했다! 저번 과목까지 그저 다른 수강생의 질문 목록을 보며 공부를 했다면 이번엔 구글링함에도 나오지 않는 부분들을 질문하였더니 기억에 더 잘남았다. 적극적으로 질문하는 걸 추천한다.

3. 개체지향 언어 및 설계는 과제의 구현이 딱 정해져있지 않다. 만약 여러분의 시간이 꽤 여유롭다면 다양한 설계를 해보는 것을 추천한다. 이미 통과된 코드라고 하여도 그게 가장 효율적인 코드가 아닐 수 있다. 내가 제출한 코드가 그렇다.. 어쨌든 다른 수강생 분들 코드를 봤을 때 가장 도움이 많이 되는 과목이 아닌가 싶다.

4. 포큐 아카데미는 조교 제도가 있다. 조교가 되면 강좌는 아니고 풀코스 수업 쿠폰을 받는다. 활발히 활동하고 다른 분들과 소통이 잘되는 분이면 뽑아주는 거 같다. 하지만 여기서 실습, 과제 100%란 조건이 붙는다. 조교에 관심있는 분이라면 실습, 과제 기한 관리를 잘하자!

'POCU > 후기' 카테고리의 다른 글

웹개발자면 C++언어 학습하지 마세요! (4)	2024.08.22
POCU 아카데미 COMP3500 후기, 알고리즘과 자료구조 제대로 공부하기 (2)	2022.12.26
POCU 아카데미 COMP2200 후기, C언어 제대로 공부하기 (0)	2022.08.16
POCU 아카데미 COMP1500 후기 (0)	2022.04.21

현재글웹서버 개발자(?)의 OOP 제대로 공부하기

매일매일