이 글은 제미니의 개발실무 - 커머스 백엔드 기본편 강의를 듣고 느낀 필자의 주관적인 생각입니다.
Prologue
해당 강의를 들으면서 중요하거나 기억하고 싶은 부분들을 Github에 정리했습니다.
해당 강의를 듣게된 배경
-
필자는 이전부터 커머스 도메인에 대해서 관심을 가져왔고, 성장을 위해 가고자하는 부분이 커리어 방향성과 맞는지 확인하고 싶어서 이 강의를 듣게 되었다.
-
또한, 해당 강의를 만드신 분이 개인적으로 운영하고 있는 유튜브 영상도 즐겨봐왔기 때문에 강의는 어떤 식으로 만들었는지도 궁금해서 더 관심을 가진 부분도 있다.
Review
-
전반적으로 이해도는 90%, 만족도는 100%, 그 이상이었다.
-
커머스 분야에 종사하고 있지 않기 때문에, 도메인 지식에 대해 어느정도 알고는 있지만, 코드상에서 어떻게 흘러가는지에 대한 흐름은 제대로 몰랐기 때문에 90%라고 했다.
-
여러 도메인 중 개인적으로 결제, 정산 부분에 대해서만 이해가 100% 안되었고 나머지 부분들에 대해서는 이해가 잘되었다.
-
만족도를 100% 이상이라고 한 이유는 강의를 듣게된 배경에서 언급했던 부분들에 대한 궁금증이 모두 해결되었기 때문이다.
-
내가 공부하고 있는 부분이 커리어 성장에 대한 방향성과 맞는지, 커머스 분야에 대한 도메인 지식을 습득하는 것, 이 두 가지 궁금증을 모두 해결했다.
-
물론, 커머스 분야의 도메인 지식을 모두 100% 습득한 것은 아니다.
-
해당 강의는 말 그대로 기본편이고, 도메인 지식 보다는 “생각하는 힘”, “기술적 사고력”을 어떻게 기르는지에 대해 집중하기 때문이다.
-
-
결론부터 말하자면, 이 강의는 백엔드 분야의 커리어 방향성에 있어서 어떻게 성장해야 하는지 생각하는 힘을 길러주는 좋은 강의라고 생각한다.
-
해당 강의는 약 7시간 정도 되는 분량이지만, 그 시간이 아깝지 않을 만큼 좋은 강의라고 생각한다.
-
강의를 들으면서 해당 강의를 만든 분이 강의 시간을 최대한 단축해서 핵심 위주로 설명해준 부분이라고 느꼈다.
-
마치 좋은 사수가 어떻게 문제를 접근하고 해결하는지 알려주는 느낌이 컸다.
-
-
해당 강의는 Kotlin, SpringBoot, JPA의 기본적인 수준만 안다면 충분히 이해하고 들을 수 있는 내용이었다.
-
기술적인 내용에 집중하기보다는 주어진 요구사항을 구체화하는 과정 속에서 어떤 고민을 하고 기획 또는 운영팀과 소통하는지에 대해 집중한 내용이 컸다.
-
또한, 요구사항 자체도 기본적인 내용 위주였기 때문에, 강의 제목에서 “기본편”이라는 단어가 나왔지 않았을까 생각한다.
-
만약 비즈니스에 대한 요구사항과 기술적인 부분들을 많이 고려해야 한다면, 기본편이 아닌 “중급편” 혹은 “심화편” 으로 나왔을거라고 생각한다.
-
-
이 강의가 끝났다고 해서 끝난 게 아니라, ‘시작’이라는 느낌이었다.
-
강의에서는 비즈니스와 요구사항 속에서 어떤 고민을 해야하는지, 개념도를 어떻게 정의하고 작성하는지, 그리고 그러한 고민을 코드에 어떻게 접목시키고 구현해야 할지를 알려주는 가이드 느낌이었다.
-
강의에서도 매 섹션마다 강조하는 부분이 “스스로 고민을 많이 해봐라” 였다.
-
그렇기 때문에, 해당 강의를 끝나고 나서 본인 스스로 고민을 많이 해봐야 한다.
-
더불어, 스스로 고민한 것을 가지고 강의에서 제공한 예시 코드를 기반으로 직접 코드를 작성해보면서 문제를 해결해나가는 것이다.
-
-
또 하나 배운 점이 있다면, 개념도를 작성해보는 것이다.
-
(필수는 아니지만) 개발자라면 코드를 작성하는 것도 중요하지만, 작성하기 이전에 해당 도메인에 대한 개념도를 그려보는 것도 중요하다.
-
강의에서는 개념도를 ‘개념’과 ‘격벽’으로 설명해주셨다.
-
특히, 격벽을 통해 개념을 구분하는 것이 도메인간 관계를 이해하는데 매우 도움이 되었다.
-
-
기술적으로 배운 점이 있다면, Immutable 하게 테이블을 생성하고 관리해야 한다는 점이었다.
-
섹션 12장 취소 강의에서 나온것처럼 주문한 것에 대해 결제 성공 후,
-
이후에 해당 주문건을 취소할 때 취소 테이블에 “어떤 결제(ID)가 언제 취소되었다”는 내용을 새롭게 삽입(Insert) 하고, 주문 테이블에는 주문 상태를 취소로 업데이트하는 구조로 갈 경우,
-
결제 테이블을 건드리지 않고 취소 테이블만으로 히스토리를 파악할 수 있다는 장점이 있다.
-
물론 이 방법이 무조건적인 정답이라고 할 순 없지만, 이런 방법도 있다는 내용을 설명해줘서 좋은 인사이트를 얻어갔다.
-
중요한 건, 회사와 회사 내 비즈니스 상황, 요구사항, 그 외 여러가지 상황들을 고려해서 트레이드오프를 고려해봐야 한다.
-
-
해당 강의에서는 커머스 분야의 각 도메인 별로 개념 설명과 코드 설명을 이어나가는 구조였다.
-
중요한 개념을 나열해보면 상품 -> 주문 -> 결제 -> 정산 이라고 생각한다.
-
그 중에서 개인적으로 해보고 싶은 도메인은 주문, 결제 쪽이었다.
-
그 이유는 주문과 결제 쪽에서 트래픽 경험과 동시에 데이터 정합성을 고려한 설계 및 구현 경험을 쌓을 수 있기 때문이다. (그만큼 재밌는 고민거리들이 많을까 싶다!)
-
그래서 앞으로 시간이 된다면 주문과 결제 도메인 쪽으로 고민하고, 고민한 것을 바탕으로 코드를 구현하면서 예제 코드를 개선해볼 예정이다.
-
-
끝으로, 이 강의가 만약 대학 시절에 나왔다면 더 좋았겠다 싶을 정도로 예비 개발자, 신입 개발자 혹은 나처럼 저연차 개발자에게 추천해주고 싶다.
-
저연차 개발자 중에서 현재 속한 회사에서 사수가 없거나, 본인이 성장하는 방법을 모르고 있거나, 성장하고 있는지 헷갈린다면 이 강의를 보면 그 정답을 알 수 있다고 생각한다.
-
또한, 커머스 분야의 예제 코드를 기반으로 본인만의 실험을 하고 싶다면, 강의에서 제공해준 예제 코드를 활용해보면 좋을 것 같다.
-
-
이 강의를 만들어준 제미니님께 감사드리고, 지금까지 이 글을 읽어주신 모든 분들께 감사의 말씀 전합니다.