코딩에 정답을 찾지말자. 고민을 통해 더 나아짐을 시작하자.

Joshua_Kim·3일 전
7
post-thumbnail

🌱 2주차 회고를 들어가며

1주차보다 더 시간이 빠르게 지나간 것 같다.
2주차를 한마디로 이야기하자면 '뿌-듯' 이었다.
이유는 이번 2주차 과제를 통해 정말 많은 고민들을 했고, 그 고민들을 통한 성장이 너무나 잘 느껴졌기 때문이었다.

다만, 이번 2주차에 들어가면서 마음에 하나 걸렸던 것은 와이프였다.
퇴근 후 바로 과제를 하느라 컴퓨터 앞에서 끙끙대고 있는 남편을 안타까움 + 서운함으로 바라보고 있는 와이프에게 참 많이 미안했다.
오죽하면 항해를 떠났는데 원양어선 타고 항해를 떠난 것 같냐고 하더라..😅
멀티가 안되는 태생 싱글코어로 살아와서 과제에 폭 박혀서 집중을 하면 아무것도 들어오지 않았다.
회고 글을 들어가며 먼저 와이프에게 미안함과 감사를 함께 드린다.

🍇 2주차 항해 여정 회고

2주차 과제는 클린 아키택처와 TDD 를 통한 [특강 신청 서비스] 를 구현하는 것.

아래는 구현해야할 과제와 요구사항이다.

[2주차 과제 요구사항]


1️⃣ (핵심) 특강 신청 API POST /lectures/apply

  • 특정 userId 로 선착순으로 제공되는 특강을 신청하는 API 를 작성합니다.
  • 동일한 신청자는 한 번의 수강 신청만 성공할 수 있습니다.
  • 각 강의는 선착순 30명만 신청 가능합니다.
  • 이미 신청자가 30명이 초과되면 이후 신청자는 요청을 실패합니다.
  • 어떤 유저가 특강을 신청했는지 히스토리를 저장해야한다.


    2️⃣ (기본) 특강 목록 API GET /lectures
  • 단 한번의 특강을 위한 것이 아닌 날짜별로 특강이 존재할 수 있는 범용적인 서비스로 변화시켜 봅니다.
  • 이를 수용하기 위해, 특강 엔티티의 경우 기본 과제 SPEC 을 만족하는 설계에서 변경되어야 할 수 있습니다.
  • 특강의 정원은 30명으로 고정이며, 사용자는 각 특강에 신청하기전 목록을 조회해볼 수 있어야 합니다.


    3️⃣ (기본) 특강 신청 완료 여부 조회 API GET /lectures/application/{userId}
  • 특정 userId 로 특강 신청 완료 여부를 조회하는 API 를 작성합니다.
  • 특강 신청에 성공한 사용자는 성공했음을, 특강 등록자 명단에 없는 사용자는 실패했음을 반환합니다.

2주차 과제에서 가장 고민 했던 것.

1. 요구사항을 어떻게 풀어 낼 것인가.

백엔드 개발자의 역량 중 중요한 것 중 하나가 바로 '요구사항을 어떻게 코드로 풀어낼 것인가' 이다.
그러기 위해서 나는 구현해야 할 API 별로 다음과 같이 접근 했다.

    1. 핵심 요구사항이 무엇인가?
      이 요구사항을 통해 해결하고자 하는 문제가 무엇인가?
      즉, 구현해야 할 핵심 로직이 무엇인가.
    1. 제약사항은 무엇인가?
      이 요구사항을 해결하기 위해 로직을 설계할 때 제한 해야할 부분은 무엇인가?
      즉, 예외를 감지해야할 부분이 무엇인가.
    1. 어떤 부분이 기술적으로 시간이 가장 소요가 되는가?
      이 요구사항을 해결할 때 내가 가장 약하거나 부족한 부분은 무엇인가?

위의 생각의 흐름으로 요구사항을 분석했고, 로직을 구현햇다.


2. 서비스 레이어의 의존관계는 어떻게 풀어 낼 것인가.

이번 주차에서 내가 가장 많이 고민 했던 부분이었다.

"서비스 레이어에서 계층이 생겼을 때, 서로 의존을 하게 되면 순환참조가 일어나게 되는 것 아닐까?"

그 고민끝에 나는 '퍼사드 패턴'을 활용해서 구현을 하기로 결정했다.

서비스 레이어 (어플리케이션 레이어) 의 계층을 나누고, 각각의 도메인들의 로직을 책임을 지는 Manager 들을 만들고, Service 에서 조립을 하도록 했다.
감사하게도 내 PR 을 검사해주신 코치님께도 해당 시도에 대해 좋은 평가를 받았다. 😁

3. 동시성 이슈를 어떻게 처리할 것인가.

요구사항 중, 같은 요청이 동시에 들어올 때, 정원이 가득찼다면 그 이후의 요청은 모두 수강 실패로 만들어야 하는 요구사항이 있었다.

Redis 를 통한 분산락을 구현하는 것이 아닌 우선을 DB 락을 통해 구현하라는 코치님에 조언에 따라 비관적 베타락을 걸었다.

석범 코치님의 따봉..🥹 뿌-듯!

🍐 달콤한 결과, 감사한 팀원들의 존재

명예의 전당에 오르다. 🏆

헿.. 명예의 전당에 올랐다!

2주차 과제부터 명예의 전당이라는 것이 도입되었다.
감사하게도, 가장 베스트프랙티스라고 코치들이 생각한 과제들을 발제 전에 소개하는 시간이었다.
그곳에 내 과제물도 있었다...! 🥳

어찌나 뿌듯하고 기쁘던지..🥹
매일 퇴근 후 새벽까지 과제하고 고민하고 계속 코드를 수정하면서 고생했던 것이 한 순간 보상을 받는 기분이었다.

최선을 다했던 내 과제 PR들..

난 16조라 행복해. ❤️‍🔥

2주차를 마치며 항해의 Chapter1 이 마무리 되었다.
마무리를 하면서, 각자의 개인 회고를 팀원들과 나누는 시간이 있었다.
항해 플러스 백엔드 과정을 하면서 기대했던 것 중 하나는, 좋은 사람들과 알아가게 되는 것이었다.
발제를 통한 백엔드 개발자로서의 공부를 하는 것도 너무 중요하고 얻는 것도 많았지만, 좋은 사람들을 얻는 것은 또 다른 결의 복이다.
위의 사진의 회고에도 적었지만, '좋은 팀원들과 함께 의견을 나누는 것의 즐거움'을 제대로 누리고 있다.
각자의 생각과 코드가 다름에도 각자의 생각을 존중하고, 더 좋은 방법에 대해 같이 나누고 이야기하면서 성장하는 것이 너무 느껴졌던 이번 한 주 였다.
남은 과정들이 아직도 많이 남았고, 매우 도전적인 것들이 많겠지만, 이런 좋은 팀원들과 함께 한다면 충분히 같이 해내갈 수 있을 것 같다.
참 감사하다.


🍉 코딩에 정답을 찾지말자. 고민을 통해 더 나아짐을 시작하자.

코치님들도 생각이 모두 다르다. 💡

정말 재미있었던 것은, 코치님들의 생각이 모두 다르다는 것이었다.
한가지의 주제에 대해서 각자 다양한 생각을 가지고, 또 나름의 이유와 논리를 가지고 계신다는 것을 발견하면서 너무 재미있었다.
A 코치님은 아키텍처를 설계할 때 퍼사드패턴은 도리어 로직의 복잡도를 가지고 올 수 있으니 서비스끼리의 참조를 어느정도 허용해도 괜찮다고 하셨다.
하지만 B 코치님은 매우 엄격하게 그 부분에 대해서 순환참조의 여지를 남기는 것 자체를 좋지않다고 생각하셨고 퍼사드패턴을 강조하셨다.

이렇듯, 코치님들이 각자의 다른 생각으로, 다른 방법으로 코딩을 하고 자신만의 기준과 신념을 바탕으로 프로그래밍을 하고 계신다는 것이 너무나 흥미로웠다.


은탄환은 없다. 다만, 최선을 다할 뿐 🔫

이번 멘토링 세션에서 석범님과 이런 이야기를 나눴다.
결국, 은탄환은 정말 없다. 요구사항에 따라 최선의 방법을 찾는 것일 뿐 정답은 존재하지 않는다.
결국 가장 중요한 것은 문제를 해결할 때, 내가 가진 생각이 일관되고 합리적이어서 그것을 통해 다른 생각을 가진 개발자들의 고개를 끄덕이게 할 수 있느냐다.
이러한 역량을 기르기 위해서는 더 좋은 고민을 하기 위해 많은 것들을 경험을 해야한다.


개발자는 기계적으로 코드를 작성하는 사람들이 아니다. 👨🏻‍💻

작년 인프콘에서 토비님의 강연을 통해 들었던 이야기가 언뜻 머리에 스쳤다.

"스프링을 사용한다는 것은, 그저 기계적으로 @Service 붙이고, @Repository 붙이고, @Controller 붙여서 API를 만들어 내는 것에 그치는 것이 아닙니다."

개발자란, 기계적으로 혹은 관습적으로 코드를 찍어내는 사람들이 아니다.
2주차가 지나는 시점에서 요구사항을 풀기위해 많은 고민들을 하고 있다.
그 고민들을 하면서 그동안 신변잡기식으로 읽어오고 들어왔던 이야기들이 조금씩 조립이 되고 맞춰지는 기분이다.

개발과 철학은 상당히 밀접해 있는 것 같다.
대학교때 철학개론 교수님께서 철학에 대해 이렇게 말씀하셨던 기억이 있다.

"철학은 정답을 찾기 위한 학문이 아니다. 더 좋은 고민을 하기 위한 학문이다."

이 지점에서 개발이 상당히 철학과 맞닿아 잇는 것 같다.
개발자란 코드를 통해 세상의 문제를 해결함에 있어서 정답을 찾는 것이 아니다.
항상 더 좋은 방법과 코드를 고민해야 하는 사람이다.
그리고, 그 방법은 모두 다르며 그 모두 다른 방법들에 대해 즐겁게 논의하고 생각하며 공유 할 수 있는 너무나 즐거운 과정을 수행하는 사람들이다.


🙏🏻 글을 마치며

Chapter1 이 끝나고 본격적인 서버 구축 과정인 Chapter2 가 기다리고 있다.
이제 막 2주차가 지났음에도 돌이켜보면 꽤 성장한 것 같다.
고민을 어떤 방향으로 해야할지, 어떻게 생각하고 사고해야할지가 잡히는 것 같다.

다음 주 회고때도 치열하고 후회없이 보낸 회고를 작성하길 소망한다.

화이팅!

지난 회고 보러가기

1주차 회고 - 테스트코드를 모르던 내게 찾아온 TDD

profile
인문학 하는 개발자 💻

5개의 댓글

comment-user-thumbnail
2일 전

항해 과정이 어떻게 진행되고, 그것을 통해 무엇을 얻을 수 있는지 한 눈에 딱 들어오는 글이네요.
그리고 중간 중간 개발에 대한 민재님의 생각, 신념이 드러나게 작성해주신 부분도 넘 좋습니다. 글 잘 읽었습니다!

  • 그동안 최선을 다하는 그대를 옆에서 지켜보면서, 생각을 좀 바꿨습니다. 이젠 원양어선도 좋고 돛단배도 좋고 다 좋습니다. 항해 나간 김에 열심히 하고 오십셔. 또 언제 나가보겠어요? 집안일에 좀 소홀하더라도 이해하겠습니다. 침몰하지만 말고 무사히 항해 잘 마치고 돌아오시길~ㅋㅋ
1개의 답글
comment-user-thumbnail
2일 전

좋은 내용 잘 읽고 갑니다!

더 성장하기 위해 어떤 고민을 하셨는 지가 잘 느껴져서 저도 동기부여가 되는 글 이었습니다!!

그리고 글을 읽으면서 한가지 여쭤보고 싶은게 생겼습니다

  1. 서비스 레이어에서 "퍼사드 패턴"을 쓰신 이유랑 동시성 이슈에 대해서 "비관적 락"을 쓰신 이유에 관해서 혹시 어떤 점들을 고려하여 사용하신 것인지 조금 더 말씀해주실수 있으실까요 ??
    (저도 해당 상황일때 어떤 점들을 고려해서 어떤 선택을 해야하는지 혜안을 나눠주실수 있으실까요🙇)
1개의 답글