POG 서비스는 소환사를 즐겨찾기 하여 전적 변화 여부를 파악할 수 있습니다. 만약 즐겨찾기한 소환사의 전적이 변동됐다면, 소환사를 즐겨찾기 한 모든 사용자의 FCM 토큰을 조회해서 FCM 서버에 푸시 요청을 해야 했습니다. 1분마다 전적이 변동된 소환사를 즐겨찾기한 모든 사용자의 FCM 토큰을 조회하는 과정에서 DB에 부하를 발생시켰습니다.

FCM 공식 문서를 모두 분석하면서, FCM Topic을 활용하면 사용자의 토큰을 찾지 않아도 푸시를 보낼 수 있다는 것을 알았습니다. Topic을 활용하기 위해 사용자가 소환사를 즐겨찾기 할 경우, 클라이언트 로직에서 소환사의 id를 FCM topic으로 구독하도록 설정했습니다.

사용자의 FCM 토큰을 조회하는 로직을 제거하여 DB에 부하를 줄 수 있는 로직을 제거했습니다.

전적이 변동된 소환사가 1만 명이라고 생각했을 때, FCM Topic을 이용해서 푸시를 보내더라도, FCM 서버로 1만 개의 푸시를 전송해야 했습니다. 그 과정에서 푸시가 동기적으로 전송됐고 푸시를 전송할 때 까지 서버가 멈춰있는 문제가 발생했습니다. 또한 서버가 멈춰있는 동안, 서버에 처리해야 할 요청이 많아질 경우 서버는 견디지 못하고 장애를 발생시켰습니다. 그 과정에서 스레드에 쌓여 있던 푸시 메시지 작업이 모두 사라지는 문제가 발생했습니다.

동기적으로 동작하던 푸시 전송을 비동기적으로 처리함으로써 싱글 스레드인 Node.js에 부담을 줄일 수 있었습니다. 또한 queue에 푸시 알림 데이터를 저장하기에, 푸시를 보내는 과정에서 갑작스럽게 서버에 장애가 발생하더라도 다시 정상적으로 푸시 알림을 전송할 수 있습니다.

Redis의 Set 자료구조를 활용하여 모든 소환사 Id를 조회함으로써 DB에 부하를 줄일 수 있었습니다. 또한 Redis를 활용하여 소환사 전적 정보를 수정함으로써 DB에 부하를 줄일 수 있었습니다.

테스트 코드를 작성하지 않아서, 코드 한 줄을 바꾸더라도 코드의 변경이 어떤 문제를 일으킬지 알 수 없었습니다. 이를 통해 리팩터링의 어려움을 겪었습니다.

테스트 코드를 작성하여 코드의 품질과 서버의 안정성을 올릴 수 있었습니다.

서비스를 개발하면서, 저는 데이터베이스를 제대로 활용하는 방법을 몰랐습니다. 만약 데이터베이스 관리를 제대로 하지 않는다면 사용자에게 좋지 못한 사용자 경험을 제공할 수 있다고 생각했습니다.

인덱스를 활용하여 1,000만 건의 데이터를 기준으로 657ms 걸리던 조회 쿼리를 0.023ms의 속도로 조회할 수 있도록 쿼리 성능을 개선했습니다.

API에서 에러가 발생할 때마다, 에러 핸들링 하는 코드를 컨트롤러에 모두 작성했습니다. 그러다 보니 에러 핸들링을 할 때, 모든 경우의 수를 코드로 작성해야 하는 불편함이 있었습니다.

실패 처리를 상세하게 코드로 작성하지 않아도 에러 핸들러가 처리함으로써 불필요한 코드 작성을 피할 수 있었습니다.

기존 프로젝트를 담당하던 개발자가 Postman을 활용하면서, API 명세서를 제대로 작성하지 않아 기존 API를 살펴보는 데 어려움이 있었습니다. 또한 개발자가 증가하면서, Postman을 함께 활용할 때 비용이 발생하는 문제가 있었습니다.

Swagger 문서를 활용함으로써 API 명세서를 제대로 작성할 수 있었고, 비용 문제 또한 발생하지 않았습니다.

기존 프로젝트를 담당하던 개발자의 코드를 분석하면서, 계층 간의 역할과 책임이 제대로 분리되지 않았습니다. 이 때문에 하나의 로직을 추가하거나 수정하더라도 광범위한 코드를 수정해야 했고, 코드의 응집도 또한 떨어지는 문제가 발생했습니다.

계층별로 역할과 책임이 분리되게끔 코드를 작성함으로써 코드의 응집도를 높였고, 의존성을 줄일 수 있었습니다.

커뮤니티 게시글을 보기 위해서는 하단 네비게이션 탭 바의 커뮤니티 탭을 누르고, 특정 게시판에 입장해서 특정 글을 선택해야만 했습니다. 게시글을 보려면 세 단계를 거쳐야 하는 UI&UX 접근성에 문제가 있었습니다.

하단 네비게이션 탭 바에서 커뮤니티 탭을 눌렀을 때 특정 게시물의 정보가 노출되게끔 수정했습니다. 커뮤니티 서비스 개편을 위해 기존에 있던 커뮤니티 API를 수정했습니다.

커뮤니티 기능 개편을 통해 DAU 지표를 개선시킬 수 있었고, 앱 회원 수를 3,000명에서 5,000명으로 증가시킬 수 있었습니다.

기능 개편이 지표 개선에 도움이 되는 것을 보고서, 앞으로 기능을 만들 때 비즈니스 성장에 도움이 될 수 있으려면 어떻게 일해야 할까 고민해야겠다고 생각했습니다. 이 경험을 통해 백엔드 개발자 또한 비즈니스 드리븐하게 일하는 것이 필요하다는 것을 배웠습니다.

커뮤니티 기능 개편을 통해 회원 수는 증가하지만, 재방문율 지표가 떨어지는 문제가 발생했습니다. 어떻게 하면 서비스 재방문율을 올릴 수 있을까 고민했습니다.

재방문율을 올릴 수 있는 방안으로 알림 서비스를 기획하고 개발했습니다. 게시글에 댓글 또는 대댓글이 생성될 때 푸시 알림이 가도록 설정했고, Node Schedule 모듈을 활용하여 전체 고객에게 특정 시간에 이벤트 공지를 알리는 푸시 알림이 가도록 설정했습니다.

내부 및 푸시 알림 서비스 개발을 통해 앱 재방문율을 7일 후 기준 5%에서 10%으로, 5% 증가시킬 수 있었습니다. 하지만 전체 고객에게 푸시 알림을 보낼 때, 푸시 전송이 동기적으로 처리되어 3초 이상의 시간이 걸리는 문제를 해결하지 못하고 팀에서 나오게 됐습니다.

백엔드 개발자는 비즈니스를 위해 빠르게 기능개발을 하는 것도 중요하지만, 서비스의 안정성을 반드시 함께 고려해야 한다는 것을 배웠습니다. 특히 푸시 알림을 개발하면서 성능 개선의 중요성을 파악했습니다. 만약 다음에도 푸시 알림 서비스를 개발한다면, 최우선 적으로 성능을 개선시킬 수 있는 방법을 고안해보고 싶습니다.

개발자로서 처음 협업을 하는 과정에서, 협업은 어떻게 해야 하는지 모르는 문제가 있었습니다. 그리고 사진을 찍고 S3에 사진을 저장시킬 때 높은 용량의 이미지가 그대로 저장되는 문제가 있었습니다.

개발자로서 더 나은 협업을 하려면 어떻게 해야 할까? 고민하며 프로젝트 시작 전, '코드 컨벤션', '커밋 컨벤션', 'git flow', 'git 명령어 가이드', '이슈 PR 관리'에 대해 공부하고, 공부 내용을 블로그에 정리해서 팀원들에게 공유했습니다. 또한 이미지 업로드 시 AWS Lambda가 이미지 크기를 줄여서 S3에 이미지를 저장할 수 있도록 프로젝트에 적용했습니다.

협업에 관하여 공부한 내용을 팀원들과 공유하며, 협업이 처음인 개발자끼리 원활한 협업을 할 수 있도록 도왔습니다. 또한 AWS Lambda를 활용하여 이미지를 저용량으로 저장할 수 있었습니다. 협업을 위해 노력한 결과 SOPT 서버 MVP, 해커톤 대상을 수상할 수 있었습니다.

개발자끼리 어떻게 해야 협업을 더 잘할 수 있는지에 대해 배울 수 있었습니다. 또한 프로젝트에서 Sequelize를 사용했는데, 개발하는 과정에서 Sequelize에서 문제가 생겨도, SQL을 전혀 알지 못해서 현재 어떤 문제가 발생했는지 알지 못하는 문제가 있었습니다. 이 경험 덕분에 SQL 공부를 시작해야겠다고 생각할 수 있었습니다.

당뇨약 복용 사실을 잊고, 재복용한 결과 저혈당 쇼크가 와서 병원에 실려 간 지인을 보며, 당뇨 환자의 약 복용 여부를 기록하는 서비스의 필요성을 느꼈습니다.

오픈서베이를 활용하여 당뇨 환자 50명에게 당뇨 관리를 어떻게 하는지 설문조사 했습니다. 조사 결과 당뇨 환자들은 약 복용 여부를 수기로 기록하는 것을 불편해하고 있었고, 당뇨 관리에 적합한 식단 정보를 찾고 싶은데 정보 찾기가 어렵다는 사실을 알았습니다. 당뇨 환자가 약 복용 여부를 기록하는 부분과 식단 정보를 찾는 것이 어떤 불편함이 있는지 상세하게 알기 위해 당뇨 환자 3명과 인터뷰를 진행했습니다. 그 결과 약 복용 여부를 자동으로 기록할 수 있고, 식단 정보를 공유할 수 있는 약 케이스와 애플리케이션 개발의 필요성을 느꼈습니다.

학교 지원사업에서 총 300만원의 지원금을 받았습니다. 이 금액을 활용해서 약 케이스 모델링을 업체에 맡길 수 있었고, 약케이스와 앱과의 통신을 위해 아두이노 부품을 구매해서 아두이노의 기초를 공부하며 약 케이스 설계를 진행했습니다. 그리고 애플리케이션을 제작하기 위해 직접 개발 공부를 진행했습니다. 외주를 맡기고 싶었으나, 외주를 맡긴다면 제품을 지속 해서 성장시킬 수 없다고 판단했습니다. 그러면 마음이 맞는 개발자를 구해야만 했는데, 마음이 맞는 개발자를 구하기란 쉽지 않았습니다. 개발자가 없어도 원하는 프로덕트를 만들고 싶다는 생각에 직접 프로그래밍을 공부하며 애플리케이션을 제작하기 위해 노력했습니다.

제품 제작부터 프로그래밍까지 모두 진행해보면서, 만들고 싶은 제품을 제작하기 위해서는 기획 역량 뿐 아니라 메이커 역량을 갖춰야 한다는 것을 배웠습니다. 이 경험을 통해 원하는 것을 만들 수 있는 개발자가 되기로 결심했습니다.

다문화가정지원센터에서 근무하며 무슬림 결혼이주여성분들이 일자리를 구하기 어려워한다는 문제를 파악했습니다. 그들은 종교적으로 지켜야할 것들이 많았기 때문에 일터에서 차별을 겪는 문제가 있었습니다. 그리고 무슬림 관광객들은 한국에서 무슬림 친화적인 여행을 즐기기 힘들다는 문제를 파악했습니다. 무슬림 결혼이주여성과 무슬림 관광객을 이어줄 수 있다면 결혼이주여성은 양질의 일자리를 제공받을 수 있고, 관광객은 무슬림 친화적인 여행을 할 수 있을 것으로 생각하여 프로젝트를 시작했습니다.

이태원 이슬람 사원 앞에서 무슬림 관광객 20명을 대상으로 여행을 하면서 어떤 문제를 겪는지 인터뷰했습니다. 그 과정에서, 기도하는 곳을 찾기 힘들며, 무슬림 친화 레스토랑을 찾기 어렵다는 이야기를 들을 수 있었습니다. 인터뷰를 통해 무슬림 결혼이주여성분들과 에어비앤비 '트립' 서비스를 한국에 방문하는 무슬림 관괭객을 대상으로 진행해봐야겠다고 생각했습니다.

인천광역시 동인천 지역을 바탕으로 무슬림 친화적인 여행코스를 기획했습니다. 그 과정에서 3곳의 기도실을 확보하고, 5곳의 무슬림 친화 레스토랑 업체와의 제휴를 맺을 수 있었습니다.

'트립' 서비스를 런칭하기 앞서, '트립' 서비스의 일자리가 안정적이지 못하다는 이유로 결혼이주여성분들이 서비스에서 이탈하는 문제가 생겼고, 결국 프로젝트를 진행할 수 없었습니다. 이 과정에서 기획할 때 린하게 사업을 시작하는 것도 대단히 중요하지만, 사업과 관련된 이해당사자의 정확한 니즈를 파악하고 사업을 시작해야 한다는 교훈을 얻을 수 있었습니다.

덕적도 관광객의 80%인 백패커는 덕적도 여행을 하면서 돈을 사용하지 않았습니다. 캠핑에 필요한 모든 짐을 가방에 챙겨서 여행했고, 돈을 사용하지 않는 관광객이 섬에 방문하는 것을 마을 주민들은 반기지 않았습니다.

마을주민 20명을 현장에서 인터뷰하며 문제 및 니즈를 도출했습니다. 조사 결과, 마을 주민들은 관광객들이 '호박 회관'에 방문했으면 하는 니즈가 있었습니다. 마을 주민들은 덕적도에서 '호박 회관' 카페를 협동조합 형태로 운영하며 관광객을 대상으로 커피, 간식 등을 판매하고 있었지만, 관광객들이 '호박 회관'에 방문하지 않고 있었습니다. 왜 관광객들은 돈을 사용하지 않을까 알기 위해 백패커 20명을 현장에서 인터뷰했습니다. 백패커들은 덕적도 여행에서만 즐길 수 있는 컨텐츠가 있다면 컨텐츠를 구매하고 싶어 했지만, 즐길 수 있는 컨텐츠가 없다고 판단했기에, 돈을 사용하지 않고 있었습니다. 심지어 20명 중 19명의 백패커들은 '호박 회관'에 대한 인지도가 전혀 없는 상태였는데, '호박 회관'에 대해 홍보한 후에는 19명 중 10명의 백패커들에게 '호박 회관'에 방문하고 싶다는 피드백을 받을 수 있었습니다.

가족 단위로 캠핑을 즐기는 관광객을 타겟으로 한 '호박 캠핑' 사업을 기획해서 백패커와 마을 주민들의 니즈를 동시에 충족시킬 수 있는 방안을 도출했습니다. 이에 대한 내용을 담아서 경쟁 PT를 진행했고 결과 우수상을 수상했습니다. 덕적도에서만 즐길 수 있는 컨텐츠를 만들어서 백패커가 컨텐츠를 소비하고, 여기서 나온 돈이 마을 주민들에게 들어갈 수 있게끔 지역 경제를 살리는 방안을 제시했습니다.

이해관계자가 어떤 문제를 겪고 있고, 어떤 니즈가 있는지 파악하는 기획자가 되기 위해서는 현장에서 발로 뛰어서 배워야 한다는 것을 배웠습니다.