안녕하세요 Niro 🚗 입니다!

🔗 [SOPT / 앱잼] Adapter Pattern 적용한 소셜 로그인 개발 회고록 (1)

🔗 [SOPT / 앱잼] UseCase 를 적용한 소셜 로그인 개발 회고록 (2)

위의 두편의 글을 읽어보셨나요?

소셜 로그인을 구현하면서 다양한 디자인 패턴을 적용해보고 SOLID 원칙 중 한개라도 만족시켜보자!

라는 마음으로 앱잼에 임하였고 다짐한대로 프로젝트가 성공적으로 마무리가 되었습니다.

이번 글은 전문적인 개발 내용이 아닌 프로젝트를 진행하면서 고민하고 결정했던 부분을 공유하고자 합니다!

⬇️ 들어가기 앞서서!

개발자를 꿈꾸는 분들은 아마도 다수의 프로젝트를 진행하셨을거라 생각합니다.

저 또한 마찬가지였고 이번 프로젝트 이외에 로그인 관련 로직을 담당한 적이 있었는데 허상에 불과 했습니다.

토큰을 관리하지 않고 단순하게 kakao, apple 로그인을 구현했 것에 그쳤기 때문입니다.

이번 앱잼을 통해

• 다양한 파트분들과 서로의 분야에 대해 깊은 얘기를 할 수 있었고,
• 서비스 내에서 실제로 토큰을 관리하고,
• 토큰을 통해 유저 정보를 불러오고,
• 서버 파트에서 제공하는 API 를 사용할 때 토큰을 헤더에 할당하고,
• 다른 개발자들도 제가 구현한 기능을 사용할 수 있도록 작성!

하는 경험을 할 수 있었습니다.

다양한 파트 (웹, 앱, 서버 등) 분들과 함께 서비스를 만들 수 있는 경험은 흔히 할 수 없는 경험이라 생각하여 굉장히 뜻깊었고

TOASTER 라는 서비스의 시작을 담당할 수 있게 되어 너무 영광이였습니다.

자, 이제 본론으로 넘어가 보겠습니다.

프로젝트를 진행하고 팀원들과 회고를 하면서 가장 큰 의문점이 생겼는데

여러 디자인 패턴을 공부해보고 적용해보여 '꼭 패턴을 사용해야만 더 잘하는 개발자'이고, '사용하지 않으면 훌륭하지 않은 코드'일까요?

⌨️ 절대 바로 코드를 작성할 수 없다.

나무를 보지 말고 숲을 봐라!

라는 문장을 많이 보셨을 겁니다.

지금 닥쳐있는 현실에 집중하다 보면 큰 틀을 생각하지 못하고 실수를 저지르거나 전혀 다른 방향으로 가고 있는 걸 깨닿게 된다는 의미이죠

지금 저의 상황에 가장 알맞는 말이였고

급급하게 기능을 구현하기 보다 앞으로 추가될 기능을 예상해보고 대응할 수 있도록 구조화 시키고 공통적인 부분을 패턴화 시키는 것이 더욱 나은 개발자가 될 수 있다고 생각했습니다.

위와 같은 행동이 습관화 되어있지 않다면 디자인 패턴을 적용하는 것은 너무 어려운 일인거 같습니다.

코드를 바로 작성하기 보다 '어떻게 계층을 나눌까?' , '어떤 부분을 바꾸는게 효율적일까?' 라는 생각으로 전체적인 그림을 그리며 틀을 만드는 것이 더욱 중요합니다.

다만... 디자인 패턴을 적용해보면서

"다양한 디자인 패턴도 공부해야겠다"

가 아니라 프로그래밍 언어를 더욱 깊게 알고 있어야만 적용할 수 있고 이미 잘 알고 있다면 '나도 모르게, 알고보니 패턴을 적용한 코드를 작성하고 있다' 라는 걸 깨달을 수 있을거라 생각합니다.

🤷🏻 사실 그냥 구현해도 문제는 없다!

수학이라는 학문을 제외하면 이 세상에 정답이 하나만 있는건 없다 생각합니다.

제가 Adapter 패턴을 적용하고 UseCase 를 통해 높은 추상화를 구현했지만 이게 정답은 아니라는거죠!

각자 진행하는 프로젝트 상황에 알맞는 방법이 존재할 것이고 로그인 버튼에 인증 관련 로직을 넣어도 앱을 사용하는데 있어 전혀 지장이 없습니다...

디자인 패턴을 적용해서 유연해졌다, 확장성이 높아졌다 등 많은 장점이 있겠지만..

우리 같은 주니어 개발자에게는 파일을 개수가 많이 늘어나고 여러 측면에서 신경써야할 것이 많아지고... 이게.. 효율적인가....? 라는 의문도 생기게됩니다..

🤦🏻 서비스를 만들지만 유지보수 한 경험은 거의 없다.

개발 경험을 쌓기 위해 많은 분들이 다양한 프로젝트를 진행한다고 글 초기에 적었습니다.

서비스를 현실화 시키기 위해 프로젝트를 세팅하고 초기부터 진행하는 경험은 많을거라 생각합니다. 하지만.. 서비스를 만들기 위해 많은 노력을 하고 출시가 되면 끝이라 생각하기도 합니다...

많은 이유가 있겠지만 각자의 일상으로 돌아가기도 하고 더 이상 참여을 못하는 분들도 생기기 마련이라 어쩔 수 없는 부분도 있습니다.

하지만 진짜 게임은 출시 이후라 생각합니다.

사용자의 피드백을 처리하고 서비스를 운영하면서 생긴 오류를 해결하고자 기존 코드를 수정하고 걷어내고 많은 작업을 하게 될 거라 생각합니다.

실제 회사에 취업을 해도 서비스를 초기부터 만들기보다 유지 보수가 주된 업무일겁니다.

위에서 디자인 패턴을 적용하는 것이 효율적이지 잘 와닿지 않을 수 있다고 했습니다.

만약 패턴을 쓰지 않았다고 가정하고 네이버 소셜 로그인을 추가해달라고 하면 어떤 생각이 드시나요?

과도하게, 아무런 이유 없이, 남들이 쓰니까 적용하는 것은 나쁘지만 여러 기능을 추가하고 수정하게 되면 손을 못 댈 정도로 엉망인 경험을 했기 때문에 여기서 디자인 패턴을 왜 사용하는지 제대로 느낄 수 있을 거라 생각합니다.

구조화 시키고 패턴을 적용하는 것이 지금 당장 큰 이득을 가져다 줄 수는 없습니다.

서비스를 효율적으로, 빠른 대응과 함께 영위하기 위해선 기존 코드를 계속 구조화 시키고 패턴화 시키는 것이 나중에는 큰 이득을 가져오게 할거 같습니다.

📌 글을 마무리 하며...

좋은 분들과 뜻깊은 경험을 할 수 있었고 개발자로서 많이 배웠던 프로젝트였습니다.

효율적인 코드를 작성하기 위해 디자인 패턴을 적용해보고 UseCase 를 통해 높은 추상화를 진행했고
그 과정 중 어떤 고민을 했고 어떤 것을 느꼈는지에 대해 적어보았습니다.

글을 읽으시는 분들 중에서도 공감하시는 분도 있고 아닌 분도 있을거라 생각합니다.
각자의 의견들 통해 더욱 좋은 개발자가 될 수 있도록 많은 의견 적어주시면 너무 좋을거 같습니다.

긴글 읽어주셔서 감사하고 많은 피드백과 질문 대환영입니다!