[프로젝트 회고] 퀘스트마인 리워드 앱 리뉴얼 개발

개요

아이브 코리아에서 진행한 '퀘스트마인(리워드 앱)' 리뉴얼 프로젝트에 대한 회고 입니다. 

약 1년 4개월(25년 1월 ~ 26년 4월) 동안 기존 앱 서비스 코드와 DB를 전면 재구축하고, 수년 간 쌓인 레거시 데이터의 마이그레이션 작업을 진행했습니다. 이후 베타테스트를 거쳐 리뉴얼 된 정식 버전을 출시하였고, 안정화 된 제품을 바탕으로 최근까지도 서비스 고도화를 진행하였습니다.

 

프로젝트 진행 과정을 되돌아보면, 순탄치 않다고 느꼈던 순간이 여러번 있었던 것 같습니다. 초기 방향성이 제대로 잡히지 않은채 시작된 프로젝트는 중반에 많은 흔들림이 있었고, 리뉴얼 중단 논의 등과 같은 극단적인 위기도 발생하게 되었습니다. 당시에 그런 부정적인 이슈들로 인해 팀원 모두가 답답함을 느끼며 힘들어 했었는데 서로 격려해가며 조금씩 나아갔고, 결국엔 마침표를 찍을 수 있었습니다.

 

1년여 기간 동안 겪은 당시의 상황, 좋았거나 아쉬웠던 점 들을 글로 남기고 싶었고, '어쨌든 버티면 결말엔 도달한다', '완료를 하지 못했을 때를 생각하면, 어떻게든 완료 해 결과를 낸 것은 잘한일..' 이라는 그런 가치가 저에겐 남은 것 같습니다. 만약 이후 비슷한 어려운 상황을 마주하는 상황이 오더라도 묵묵히 같이 노력해 완료한 이때의 기억을 떠올리면, 다시 이겨 낼 에너지를 얻을 수 있지 않을까 생각합니다. 

 

퀘스트마인 서비스 개요

한 줄 소개: 게임 미션 수행부터 플레이 타임 측정기반 보상 까지, 유저의 활동을 포인트로 전환하는 리워드 앱테크 플랫폼

주요 기능

• 미션형 리워드 시스템 : 게임 설치, 사전예약, 특정 컨텐츠 참여 등의 수행을 통해 포인트 적립
• 실시간 플레이 타임 측정 : 유저의 게임 플레이 시간을 트래킹하여 시간 비례형 보상 지급
• 다양한 몰입형 콘텐츠 : 채굴, 일일 미션, 뽑기 등 유저 참여를 유도하는 게이미피케이션 콘텐츠
• 미션 기반 리워드 : 앱 설치, 사전예약, 특정 미션 클리어 등 다양한 활동을 통해 점수 및 포인트 획득
• 보상 교환 : 적립된 포인트를 기프티콘 및 다양한 상품권으로 즉시 교환 가능한 리워드 시스템
• 랭킹 시스템 : 앱 내 활동 데이터 기반의 랭킹 시스템을 통해 경쟁 요소를 통한 리텐션 강화 및 추가 보상 제공

https://play.google.com/store/apps/details?id=kr.ive.quest_mine&hl=ko

 

리뉴얼 프로젝트 배경

리뉴얼 프로젝트는 다음에 배경과 여러 긍정적인 목적성을 가지고 시작 되었습니다.

 

프로젝트 배경

1. 기술 부채 및 운영 효율성 저하: 기존 안드로이드/PHP 레거시는 타 메인 서비스의 코드/DB 테이블 등과 결합되어 강한 의존성 구조를 가지고 있었으며, 또한 전담 관리자 부재와 맞물려 작은 수정에도 사이드 이펙트 발생이나 기술적 의사결정 및 서비스 개선이 장기간 정체되는 구조였음
2. 서비스 정체와 플랫폼 확장 니즈: 5년 이상 된 앱의 발전이 없다보니, 지속적인 유저 감소가 이루어지는 추세였고, 추세를 반전시키기 위한 사용자 경험 개선과 iOS 플랫폼 확장 및 앱 서비스의 지속적인 운영 등이 필수적인 상황이였음
3. 비즈니스 연속성 위기 : 구글 스토어 정책 변화(라이브러리 지원 중단 등)로 인해 앱 서비스 중단이라는 구체적인 데드라인이 명시되었고, 이에 따라 신규 앱 개발 혹은 기존 서비스 업데이트에 대한 전략적 결정이 필수가 됨
4. 우리팀의 제품 : 개발실 팀 자체에서 빠르고 민첩하게 주도하여 사이클을 운영할 수 있는, 개발실 내의 제품을 확보 해보면 좋겠다의 내부 의견과 목표가 있었음

 

프로젝트 진행

1. 프로젝트 초기 설계 및 핵심 기능 개발

기간 : 25년 1월 ~ 25월 4월

사용 기술 : Python (FastAPI), MySQL

핵심 내용 

• 코어 도메인 재설계 및 로직 고도화 : 유저, 퀘스트, 사전예약, 랭킹 등 서비스의 핵심 도메인의 모델과 복잡한 비즈니스 로직을 재설계하여 구현함. 특히 기존 구조의 한계점 등을 고려하여 로직을 재구성함으로써, 향후 서비스 확장시에도 유연하게 대응 가능하도록 설계를 진행함
• 배치 프로세스 설계 및 서비스 분리 : 서비스 운영을 위한 다양한 배치성 작업을 재설계 하고, 배치 로직 실패/실패 후 복구 등의 상황이 고려된 코드로 작성함. 또한 파일 관리 서비스등 여러 공통된 기능들을 Lambda 환경으로 분리하여 서버 부하를 분산하고 안정적인 서버 환경이 되도록 구성함
• 기존 몰입형 콘텐츠 고도화 : 채굴, 일일 미션, 뽑기 등 유저 참여를 유도하는 게이미피케이션 콘텐츠들을 기존에 누적되어 있던 유저 요구사항들을 함께 개발을 진행 하여, 유저 중심의 편의성 개선으로 긍정적인 리뉴얼 경험을 유도 하고자 함
• 어드민 시스템 독립 및 운영 효율 개선 : 타 서비스와 결합되어 있던 어드민 도메인을 독립적으로 분리하여, 유지보수 독립성을 확보하고자 함. 또한 CS 처리 과정에서 도출 된 운영팀의 페인포인트를 참고하여 API 맟 자동화 기능 등을 추가해, 이전의 비효율적인 CS 처리 업무에 대한 생산성을 확보하고자 함

 

회고

• 프로젝트 초반은 다들 열정이 넘쳐, 새 제품에 대해 적극적으로 아이디어도 내며 임하는 등 활발하게 진행되었었다.
• 개발 협업 및 속도 : 백엔드는 나 포함 2명이서 진행하게 되었는데, 약 4개월 간 밀도 높게 개발을 진행하였다. 개발 극 초기 단계에서 프로젝트 구조나 스타일을 맞추기 위해 PR을 몇 번 만 진행하였고, 이후에는 셀프 머지(Self-merge) 및 핵심 내용 중심의 간결한 공유를 하는 방식으로 진행해 많은 양의 코드를 속도감 있게 큰 문제 없이 모을 수 있었다. (사실 직전 프로젝트에서의 협업 경험도 있어, 서로의 작업 스타일, 생각 등이 많이 공감대가 있어 조금 더 수월했던 것 같다. )
• 레거시 '블랙박스' 서비스: 기존 프로젝트 코드베이스는 히스토리가 소실되어 있거나, 특정 사람에게만 정보가 종속되어 있어, 히스토리 추적 및 분석에 어려움이 있었다. 이에 담당자에게 양해를 구하고 2~3시간 씩 붙잡고 물어보고 정리해서 팀에 공유하는 등의 작업을 여러번 진행했다. 또 리뉴얼 제품으로서의 유저의 추가 요구/개선 사항들도 같이 반영 하려다 보니, 다소 정리가 복잡한 경우도 더러 있었다.
• 프로젝트 초기 앱과 어드민을 포괄한 전체 시스템에 대한 충분한 정리 없이 앱 쪽의 개발 위주로 먼저 착수되었었다. 그러다 보니, 앱과 어드민 간의 기능 동기화가 이루어지지 않는 문제가 종종 발생하였고, 또한 아무래도 어드민보다 앱쪽에 팀 논의 중심이 관성적으로 맞춰 진행되다 보니, 어드민 제품 개발시 진행에 다소 어려움이 있었다. (ex. 앱에는 있는 기능인데, 어드민에는 관련 개념이 없다거나, 기능 공유가 안되어 있다거나 등) 
• 콘텐츠 개선 과정에서는 팀원들이 더 좋은 제품을 만들기 위해 많이 고민하였던 것 같다. 예를 들어 액션 인터렉션의 밀리초 단위의 시간 조절에 대해 토론이 벌어졌었고 (ex. 액션 중에 돌덩이 굴러오는게 있는데, 2초가 낫냐, 1.5초가 낫냐 등) 고갱님께서는 최종 내 의견을 반영 해주셨다.
• 차후 지속적인 서비스 운영을 위해, 프로젝트 진행 도중 발견된 기획적·기술적 개선 사항을 모두 백로그로 기록해 두었다. (이것은 리뉴얼 런칭 이후 서비스 고도화 과정에서 귀한 자산으로 쓰이게 되었었다.)

---

2. 프로젝트 과도기 및 위기

프로젝트 과도기 기간 이자, 프로젝트 중단 논의까지 갔었던 모두가 가장 힘들어했던 기간이였다.

기간 : 25년 5월 ~ 25월 6월

핵심 내용 

• 제품 정체성에 대한 인식 격차와 의사결정 혼란 : 리뉴얼이란 목표에 대해 경영진은 기존 데이터 흐름, 다운로드 수, 디자인 스타일 모두를 그대로 유지하는 '리뉴얼' 관점의 제품을 지향한 반면, 실무진은 기존 데이터, 히스토리와 단절된 새로운 UX와 디자인 스타일을 적용한 ‘복제 성격의 신규 제품’으로 방향을 목표하고 있었음. 이 같은 인식 차이가 조율되지 못한 채 체류되자, 뱃사공이 점점 많아지며, 개발 방향이 수시로 번복되게 되었고 프로젝트 자체가 장기간 정체되는 상황을 맞이하게 됨.
• 레거시 '블랙박스'의 문제점 : 개발이 심화될수록, 기존 시스템의 복잡하게 얽힌 '블랙박스'형태의 레거시 로직들이 발견되었고, 문서화되지 않은 레거시 설계와 비즈니스 로직은 당초 예상한 이전 규모 비용을 한참 상회 만들었으며, 이는 전체 프로젝트 일정에 큰 부담으로 작용하게 됨
• 정보 파편화와 과도한 소통 비용: 잦은 방향성 수정은 정보의 파편화를 초래하게 되었고,.구 버전과 신규 버전 사이의 차이를 팀 외부의 QA 담당자에게 설명하고 조율하는 과정에서도 막대한 커뮤니케이션 비용이 발생하여, 실무진에게 업무 부하가 가중되었음
• 이러한 혼란을 해결하기 위해, 실무진이 직접 전면에 나서 파편화된 비즈니스 로직과 히스토리를 문서화하고, 이를 바탕으로 체계적인 QA 가이드 등을 수립하였음. 또한 정체된 의사 결정 문제를 해결하고자 ‘베타 테스트’를 제안하였고, 때마침 기존 앱 서비스가 8월 말 부로 종료된다는 구글 측의 데드라인 통보가 더해지며, 최종 베타 테스트를 통한 피드백 수렴 후 개선사항 반영 및 런칭하는 것으로 방향성이 합의 정리 되었음

 

회고

• 이 과도기는 사실 초기부터 느끼던 모호함/불편함 등을 제대로 짚고 넘어가지 못한 것들이, 쌓이고 쌓여 결국 수면 위로 드러나게 된 것 이라 생각한다.
• 가장 아쉬웠던 건, 제품의 방향성을 동기화 하고, 경영진과 실무진 사이의 의도를 명확하게 조율해 줄 ‘중간 관리자’ 혹은 ‘책임자’의 부재였다. (별개로 프로젝트 합류 초기에 '무언가 잘못되었다' 는 불안함을 느껴 팀 리더에게 조언을 구하기도 했으나, 결과적으로 명확한 R&R이 조정 되지 않고 방치 진행되다 보니 결국 나중엔 소모적인 논쟁 과정으로 많은 비용이 소모되었다.
• 또한 배에 이상한 사공들이 늘어나면서 혼란은 중첩되었고, 투입된 사람 대비 작업 진행이 계속 지지부진한 상황이 되어, 이는 팀의 실무진의 의지를 크게 꺾어놓음과 더불어 작업자로서도 성취감보다 회의감이 많이 드는 기간이였다. (+팀 내 다른 프로젝트를 진행하는 인원들도 이로 인해 제대로 된 지원을 못 받는 등의 여파가 전달됬다.)
• 결국 문제를 해결하기 위해 실무진들이 많이 전면으로 나서게 되었고, 요구사항의 본질적인 부분을 이해하여 우선순위를 직접 조율하는 등 한참을 고생 하고서야 다음 단계로 넘어 갈 수 있었다.

---

3. 베타 테스트 및 정식 출시 (+데이터 마이그레이션)

기간 : 25년 7월 ~ 25년 9월

핵심 내용 

• 베타 테스트를 통한 최종 방향성 확립 : 약 100명의 기존 유저들을 대상으로 내부 테스트를 진행하고 의견을 수렴한 결과 대부분 많은 유저들이 트렌디한 UI와 앱 방향성에 만족도를 보였음. 다만 촉박한 데드라인으로 인해, 반영 사항에서는 디테일한 부분은 우선 제외됨. 최종 의사 결정은 기존 서비스의 히스토리와 데이터 흐름은 유지하되, UI/UX등은 개선된 형태의 리뉴얼로 진행하는 것으로 최종 정리됨.
• 데이터 마이그레이션 : 기존 시스템의 데이터를 신규 플랫폼으로 안전하게 이전하기 위해선 정교한 마이그레이션 전략이 요구되었음. 약 100여개의 DB를 일일이 분석하여 최종 서비스 연속성에 필요한 유저 정보, 포인트, 핵심 콘텐츠(퀘스트) 참여 내역 등은 이전 대상으로 분류하고, 불필요 로그성 데이터인 알림 내역 등의 정보는 과감히 제외하여 데이터 효율화를 높임. 이후 각 테이블별로 맞춤형 마이그레이션 스크립트를 작성하고, 데이터 정합성 검증(ex. 데이터 개수, 테이블 관계 정합 등)을 여러번 진행하며 런칭을 준비함
• 정식 런칭 : 서비스의 연속성을 위해 런칭은 포인트 정산이 종료되는 8월 마지막주 토요일 18시를 기점으로 진행. 세부 타임테이블을 수립하고, 진행할 스크립트를 리허설 하며 위험요소를 반복적으로 점검함. 18시 기존 앱에 서비스 점검 화면 처리 후 ~ 0시 신규 버전 업데이트를 진행 및 오전 2시까지 모니터링 및 테이블 로그를 모니터링하며 서비스 전환을 최종 완료함
• 안정화 작업 및 운영 지원 : 런칭 후 9월 한 달 간은 서비스 안정화에 집중하며 라이브 환경에서 발생하는 각종 변수에 대응함. 마이그레이션 과정에서 발생한 데이터 정합성 이슈, 서비스 이용자 증가에 따른 데드락 분석, 기타 버그 제보등을 개선하며 시스템 가용성을 확보하고자 함. 또한 촉박한 데드라인으로 어드민에서 지원하지 못했던 기능을 CS 등을 쿼리로 지원하며, 기능화 하여 운영 효율을 빠른 시일 내 보완함

 

회고

• 긴 과도기를 거치며 많이 소진 되었던 팀 분위기는 유저들의 베타 피드백 의견을 받아보며 많이 회복되었다. 유저들이 생각보다 열심히 의견을 남겨주기도 했었고, 팀 모두가 같이 회의실에 모여 수집된 베타 피드백을 리뷰하며, 더 나은 서비스를 고민했던 시간은 좋은 동기 부여가 됬었다. (재미로 고갱님(FE)께서는 맘에 안드는 일부 유저의 피드백을 보고는 우스겟소리로 부정하며 팽하자고도 했었음)
• 마이그레이션을 준비 하는 기간은 정말x100 개발자란 직업을 한 이래로, 가장 어려웠던 기간이였던 것 같다. 수십개의 테이블이 6시간 안에 안정적으로 이관이 완료될 수 있게 테이블마다 스크립트를 작성하고 검증이 필요했고, 런칭 날이 가까워 질 수록 홀로 시스템을 책임져야 하다 보니 외로운 순간도 있었고, 부담도 많이 되어 심적 부담감이 점점 커졌었던 것 같다. 
• 함께 고생한 동료 백엔드 개발자가 불가피하게 휴직을 하게 되었는데, 마지막 까지 정말 최대한 애쓰고 간게 나중에 남겨진 코드에서도 티가 났다. 그래서 그 동료가 나중에 돌아왔을 때, 이 제품이 일하기 좋은 환경으로 만들어 두고 싶다는 개인적인 책임감도 가지게 되었었다. (이 프로젝트에 대해 많이 하고 싶어 했었기도 하고, 가기 전까지 무리해서 고생을 많이 했었다.)
• 정식 런칭 당일(주말 회사 출근은 또 처음이라 카드키를 안 챙겨서 밖에 한 2시간 서있었는데 팀 리더님이 기꺼이 출근해서 구해주심..) 그동안의 수 번의 리허설 과정에도 불구하고, 문제점이 발견되어 끙끙대다, 점검 시간을 30분 연장해야 했을 때, 그리고 그 30분 간의 긴장감은 아직도 생생하다... 새벽 2시 까지 로그를 확인하다, 택시를 타고 퇴근 하던 길에서는 후련함과 '어쨌든 끝내서 다행이다' 라는 안도감이 많이 들었던 것 같다.
• 이 기간을 돌이켜봤을 때 개인적으로 큰 도전 이였던 것 같고. '어쨌든 버티면 결말엔 도달한다', '어떻게든 끝까지 해낸다'는 그런 목표가 성취로 돌아오며, 느낀점이 참 많았던 것 같다.

---

4. 추가 리뉴얼 및 수익화 모델 확장

기간: 25년 10월 ~ 25년 12월

핵심 내용

• UX 추가 개편 : 초기 리뉴얼에서 부족했던 디테일 사항들을 페이지별로 보완하고, 경영진이 강조하는 서비스 핵심 요소등을 좀 더 부각하기 위한 추가 개편을 약 2개월 간 진행하였음. 
• 수익화 모델 구축 및 제품 고도화 : 광고 SDK를 연동하여 수익 창출 기반을 마련하고, 또한 신규 몰입형 컨텐츠들을 배포함. 12월에는 크리스마스 등의 대규모 이벤트 시스템 개발을 지원하며 서비스 활성화를 도모함
• 운영 체계의 효율화 : UX 개편과 신규 컨텐츠 추가 등이 맞물리며, 백엔드에서는 짧은 시간 동안 많은 API들이 deprecated 및 신규 개발 되었고, 늘어난 API 버전들을 관리하기 위해 'API 하위 호환 지원 정책', 기술 부채의 주기적인 청산을 위한 'API 최소 버전 지원' 등 현 조직 규모에 맞는 지속 가능한 API 관리 체계등을 주도적으로 수립함

 

회고

• 이번 기간은 '두 번째 리뉴얼'이라 정의할 만큼, 초기 데드라인 등으로 생략되었던 디테일을 개선하고 시스템의 코어 안정성을 확보하는 과정이였다. 특히 앱 서비스의 특성상 강제 업데이트가 어려운 환경에서 API의 버전이 빠르게 올라가고 교체 되다 보니, 버전마다 배수로 증가하는 유지보수 리소스가 생기게 되었다. 이를 해결하고자 프론트팀과 긴밀히 협력하여 하위 호환성 정책, API의 주기적인 청산 반영 등을 정립하게 되었고, 그 논의 과정에서 앱 서비스 생태계에 대한 이해도가 많이 높아졌던 것 같다. 
• 런칭 후 발생한 기술적 이슈나, 어드민 기능 보완 등 11월까지 서비스의 근간을 견고히 다지었다. 두 번에 걸친 변경에 대해 '지속적인 개선'에 대해 긍정적인 리뷰를 남겨주는 유저도 있었지만, 잦은 변경으로 인한 적응의 어려움등으로 지표의 하락을 겪기도 했었다. 이후 근간을 바탕으로 12월에는 크리스마스 이벤트를 진행했는데, 이후 유저가 소폭 반등하며 제품의 성장 가능성을 확인한 것은 좋은 보람이였다.
• 아쉬웠던 점은 개발 과정에서 제품의 본질적인 경쟁력(광고 없는 환경, 합리적인 포인트 지급 등)과 전략적 운영 방향(과도한 광고 유도와(1분~2분 광고 위주, 광고 중간 클릭 필수), 비효율적인 포인트 지급/회수 구조 등 공감하기 어려운 의사결정이 몇 번 나왔고, 이에 대해선 아쉬움이 많이 느껴졌다. 
• 결과적으로 이 기간은 짧은 시간 동안 압축적인 경험을 통해 개발자로서 앱 서비스에 대해 이해하고 기술적 고민도 많이 해 보고 배울 수 있었던 기간 같았다. 비록 전략적 의사결정에 대해 개인적인 아쉬움은 있었지만, 그런 걸 생각하는 과정에서도 배운게 있어 전체적으로 성장이 많이 된 기간이였던 것 같다. 

---

5. 자유로운 서비스 확장 및 효율성 개선

기간: 26년 1월 ~ 25년 4월

핵심 내용

• 서비스 확장 및 콘텐츠 고도화 : 프로젝트 초기 목표였던 '유연한 서비스 확장'이 본격적으로 구현던 기간. '매치퍼즐', '카드 맞추기' 등 게임형 콘텐츠를 빠르게 추가하였고, '모으기 탭'의 API화 및 플레이 타임 기반의 보상 로직을 설계하여 유저 리텐션(Retention)을 강화하는 등의 고도화를 진행함
• 정교한 푸시 타겟팅 시스템 : 기존 푸시 로직을 세분화하여 타겟팅 로직을 고도화하고, 예약 발송 기능 및 제약 조건 설정 등을 통해, 랭킹전 시작, 신규 콘텐츠 알림 등 서비스 상황별로 최적화된 푸시 수신/발송 체계를 구축함.
• 개발 생산성 향상 : 팀에 Claude 등 AI 도구를 적극적으로 도입하여 개발 업무의 효율을 높이는 시도를 진행함. AI를 사용하더라도 팀 내 일관된 코드 스타일과 패턴을 유지하기 위해 rules.md를 설계하는 등, 협업 효율을 높이고 코드 퀄리티를 다듬음
• PM/기획 관리 역량 수행: 개발 업무와 더불어 팀의 전체적인 생산성을 높이기 위해 스프린트 관리 및 PM 역할을 주도적으로 수행하게됨. 운영팀의 요구사항이나 파편화 된 기술적 백로그를 체계적으로 분류 및 우선순위를 조율하였고, 팀 내에서 유휴 자원 없이 속도감 있게 개발이 진행이 될 수 있도록 보조 역할을 수행함 (Jira 티켓과 Slack 등에 파편화된 요구사항을 통합 관리하고, 팀 내외부의 스프린트 규칙을 보다 명확하게 정리함)

 

회고

• 이번 기간은 팀이 프로젝트 시작 시점부터 목표했던 '자유로운 서비스 확장'이 마침내 기술적/조직적으로 구현된 느낌의 시기였다. 지난 1년 간 겪었던 레거시 문제와 의사결정의 혼란과 불안정한 시기를 거쳐, 이제는 기획 요구사항이 빠르게 서비스로 구현 될 수 있는 시스템과 프로세스가 어느정도 완성된 기간이였다.
• 특히 이 기간에서는 개발자로서의 역할 외에도, 스프린트 관리 등의 PM 업무를 수행하며, 산재해 있는 일감 들을 한데 모으고, 구조화하여 관리한 결과, 처리 속도와 전체적인 진행 효율 면에서 팀의 높은 생산성이 발현 되어 개인적으로도 속시원 하기도 했고, 뿌듯하기도 했던 것 같다.
• 또한 휴직을 마치고 복귀한 동료와 함께 AI 도구를 적극적으로 활용하며, 생산적인 티키타카를 주고 받으며 AI 환경에서도 협업 안정성을 높이며 개발해 나갔던 과정도 인상적인 경험이였다.

---

마치며

앞선 프로젝트 할 때도 마찬가지였지만 지난 1년 4개월 간의 시간은 개발자로서 단순 기술적인 성장을 넘어, 팀으로서 함께 위기를 마주하고 이겨낸 의미있는 시간인 것 같습니다. 개인적으로는 리뉴얼 출시일에 마이그레이션이라는 거대한? 과업을 완수하며 느꼈던 어떤 긴장감과 해방감. 그리고 최근 4개월 간의 '자유롭고 속도감 있는 개발' 실현이 가장 기억에 남는 것 같고, 앱 서비스의 전 과정을 온몸으로 겪어내며, 제품의 탄생부터 안정화, 고도화에 이르는 모든 과정을 배울 수 있었던 것도 많이 성장의 계기가 된 것 같습니다. 

 

복귀한 동료와 비록 함께 더 긴 시간을 나누지 못한 것은 아쉽지만, 그동안 함께 만든 서비스를 바탕으로, AI를 도입하여 협업을 하는 등 마지막에 그래도 같이 다시 보고 일하고 갈 수 있어서 좋았던 것 같습니다. 

 

지난 1년간 스스로가 너무 치열하게 몰입했는지 번아웃이 왔다고 느껴지기도 했고, AI 시대에 개발자 커리어를 한 번 돌아보며 깊이 있게 고민해 보고도 싶어, 이 프로젝트를 마지막으로 회사를 떠나게 되었습니다. 마지막에 어느정도 적정한 시점에 떠나는 것 같았고, 그동안 숱한 시행착오를 겪으며 미션을 완료 하기 위해 열심히 노력했던 모든 시간이, 다음 여정을 위한 좋은 자산이 되지 않을까 싶습니다. 

 

결론은 많이 배우고, 성장한 좋은 시간이였던 듯 합니다! 이만 끝!