시작하기에 앞서
•
2023년 상반기 회고 에서도 얘기했던 것 처럼 2023년 상반기에는 사이드 프로젝트를 진행했다.
•
이때 비사이드 라는 사이드 프로젝트 플랫폼을 이용했는데, 팀 빌딩부터, 사이드 프로젝트를 잘 진행하기 위한 여러 템플릿과 일정 관리 등을 해주어서 많은 도움이 되었다. 20만원이 넘는 비용이 드는게 아쉽게 느껴질 수 도 있었겠지만, 되려 “이만큼 돈을 내고 들어오는 사람들인 만큼 어느정도 필터링된 사람들로 구성될 수 있겠다” 라고 생각도 들었다.
•
사이드 프로젝트를 진행하면서 느꼈던 점이나 생각들을 그때 그때마다 틈틈이 노션문서에 작성하며 그 순간 순간에 느낀 생각과 감정들을 기록해보았다.
1주차~3주차: 초기 팀빌딩 & 아이템 선정
•
개발자로 커리어를 시작하면서 회사 바깥에서 새로운 서비스를 만들어보는게 이번이 처음이었다. 주변에서 사이드 프로젝트에 대한 악명을 워낙에 많이 들었던지라 낯선 사람들과 팀을 꾸려서 잘 헤쳐 나갈 수 있을지 시작 전에 다소 우려가 되었다.
•
팀이 꾸려진 이후, PM이었던 민수님께서 자기 소개 템플릿을 만들어주셔서 덕분에 수월하게 자기 소개 내용을 채워 넣을 수 있었다. 특히 각자의 성향이나 팀원들에게 바라는 점들을 작성하고 살펴보다보니 팀원분들의 성향을 손쉽게 알 수 있었다.
•
처음 1주차 회의때 화상으로 각자 자기소개를 하며 그라운드 룰을 만들었다. 서먹서먹하고 낯설었지만 다들 의견을 적극적으로 많이 내주시고 조금씩 다가가려고 노력해주셔서 첫 느낌이 되게 좋았다. 얘기를 나누다 보니 팀 내부적으로 지향하는 바가 어느정도 비슷하다는 것을 알게 되었다. 이를 바탕으로 우리만의 그라운드 룰을 세웠다.
◦
프로젝트를 성공적으로 완수하는 것, MVP 출시하기
◦
자주 소통하기, 빨리 친해지기, 오프라인 모임을 가지기
•
많으면 많다고 할 수 있는 8명이라는 사람들이 한 팀으로 모여 프로젝트를 진행하는게 절대 쉽지 않을거라고 생각했다. 팀원 모두가 마음속으로 생각하는 얘기들을 솔직하게 할 수 있는 분위기가 형성되어야하고, 최대한 팀원들끼리 유대감이 형성되고 친해지는게 중요하다고 생각했다. 다행히 팀원분들 모두 이러한 생각에 많이 공감하고 있어서 많은 방면으로 서로가 친해지기 위해 노력했다.
◦
조금 작위적일수도 있겠지만 매일 한명씩 돌아가며 슬랙에 랜덤 질문을 던지고 놀면서 어색함을 풀어나가려고 했다.
◦
백엔드 개발을 함께하는 분과의 핏이 무엇보다도 중요하다고 생각했다. 그래서 1주차 미팅이 끝나자마자 1:1 커피챗을 제안드려서, 서로를 알아가는 시간을 가지며 친해지려고 많은 노력을 했다. 팀미팅에서는 다소 내성적인 분인지라 걱정이 되었었는데 1:1 커피챗에서는 적극적으로 많은 의견을 말씀해주셔서 함께 일하기에 어려움이 없을 것 같다고 생각했다.
◦
2주차부터 빠르게 오프라인 모임을 가지게 되었다. 오프라인 모임으로 실제 얼굴을 뵙고 미팅을 진행했고, 이후 밥을 먹고 뒷풀이도 가지며 즐거운 시간을 보냈다. 언택트로만 만나는것보다 훨씬 분위기가 좋아지고 팀원들간의 라포가 더 많이 형성된 것을 느낄 수 있었다.정말 다행이라고 생각했다.
•
팀원분들 모두가 노력한 덕분인지 시간이 갈수록 팀 분위기가 좋아졌고, 다들 적극적으로 아이템 선정을 위한 아이디어를 내고 솔직하게 의견을 공유하면서 아이템을 확정 할 수 있었다.
•
아이템을 선정하는 기준을 설정하는데 있어 다들 많은 의견을 내주셨지만 그중 공통적으로 나온 내용은 재밌고 뾰족한 서비스를 만들면 좋겠다는 것이었다. 어디에서나 흔히 볼 수 있는 서비스가 아니라 우리만의 특색있는 서비스를 만드는게 재밌을 것 같다는데 공감이 되었다. 그 결과 약속 지각 방지를 위한 실시간 위치 공유 서비스가 아이템으로 선정되었다.
•
개발 파트에서는 개발반장을 뽑게 되었다. 개발 파트를 이끌면서 회의를 진행하며 일정이나 태스크를 관리하고, 타 파트 분들과 협업하며 이슈를 공유하는등 미니 CTO 같은 역할이었다. 벌여놓은 일이 너무 많이 있었던지라 개발반장을 다른분께 제안 드리고 서포트를 잘 하려고 했으나 만장일치로 내가 개발반장을 맡게 되었다. 잘할 수 있을지 걱정반 우려반이다.
4주차~6주차: 프로젝트 초기 셋팅 + 요구사항 논의
•
개발반장으로서, 개발파트에서는 무엇보다도 아래 두가지가 가장 중요하다고 생각했다.
◦
개발 일정 관리
◦
커뮤니케이션
•
서비스를 결국 만들어 내는 건 개발파트의 역할인데, 개발파트에서 잘못된 에픽/태스크 관리로 인해 프로젝트 일정이 지연되는 사태는 최대한 막고 싶었다. 우선 개발파트 분들을 위한 노션 페이지를 별도로 만들고, 큰 에픽단위는 간트차트를 활용하고, 태스크 단위는 칸반 보드를 활용하였다.
◦
프로젝트를 끝나고 나서 돌이켜보면 여기서 아쉬움이 다소 있었다. 노션의 타임라인(간트차트), TODO (칸반보드)가 서로 Align 되어 있지 않아서 작업자의 입장에서는 태스크를 에픽 단위로 관리하기 쉽지 않았다. 그렇다 보니, 프로젝트 중간 중간 칸반보드를 sync 할 것을 요청 드렸지만, 칸반 보드는 사실상 잘 관리가 안되었다. 그리고 나는 백엔드 개발자다 보니, 프론트 개발자분들의 태스크를 관리하기에는 업무적인 한계도 있었다.
◦
차라리 노션을 쓰지 않고 협업 툴로 Jira를 활용했으면 서로 태스크와 에픽을 관리하기 쉽지 않았을까 라는 아쉬움도 있었다.
•
요구사항이 확정되기 전인 4주~6주차까지는 프로젝트를 위한 초기 셋팅 및 사전에 필요한 작업들을 계획했고, 7주차~11주차 (5주)는 본격적인 개발 집중 기간으로 설정하여 이 기간 내에 최대한 개발이 끝날 수 있도록 요청을 드렸다.
•
현업에서 에픽을 진행하면서 많이 느꼈던 것은, private한 곳에서 진행되는 커뮤니케이션은 tracking이 되지 않아 외부에 공유를 해야할 때 컨텍스트를 파악하기 어렵다는 것이었다. 프론트/백엔드 별로 각각 2분씩이었기 때문에 각자 DM으로 커뮤니케이션을 할 것이 분명했고, 서로 private 환경에서 커뮤니케이션을 진행하기보다는 public한 환경에서 뭐든 커뮤니케이션해주실 것을 부탁 드렸다. 많은 사람들이 있는 채널에 커뮤니케이션하는 것의 부담감을 최소화하고자 개발 파트만 따로 별도의 슬랙 채널을 팠고 여기서 대부분의 커뮤니케이션을 진행하면서 이슈가 레이징되면 바로 스레드를 보고 컨텍스트를 파악해서 논의를 진행했다.
•
그외 개발 파트에서 정의한 컨벤션이나 논의사항들을 최대한 쉽게 관리가능한 형태를 유지하고자 노션에 문서화를 신경쓰고자 했다.
•
백엔드파트에서는 크게 레포 초기 셋팅 및 소셜 로그인 구현 과 인프라 설정 및 CI/CD 구현 2가지의 굵직한 태스크로 구분되었는데, 나는 인프라 설정 및 CI/CD 구현을 맡게 되었다.
◦
인프라로는 Naver Cloud Platform을 사용했는데, 아무래도 비사이드에서 제공하는 100만원의 크레딧을 무시하기 어려웠다. 아무것도 없는 상태에서 인프라를 처음 설정하는게 처음이다보니, 정말 많은 삽질과 시행착오를 겪었다. 어느정도 인프라가 구축된 상태에서 인프라 작업을 회사에서 했던건 정말 거인의 어깨에서 쉽게 개발한거였구나.. 라는걸 많이 느끼는 순간이었다.
•
기획 파트분들이 정말 빠르게 정책을 정의하고 요구사항문서를 작성해주셔서 생각보다 빠르게 설계를 진행할 수 있었다. 회사에서는 에픽의 요구사항과 정책이 노션문서에 작성되고 UI만 피그마에 작성되는 형태로 작업이 진행되었는데, 이번에 함께 협업하는 기획 파트 분들은 피그마를 엄청 적극 활용해주셨다. 주요한 정책을 제외한 대부분의 내용이 피그마에 작성되었고, 피그마에는 화면정의서라는 포맷으로 각 화면에 따라 필요한 요구사항과 UI에 대한 설명이 정의되어 있었다. 새로운 포맷의 요구사항을 접해보다보니 낯설고 불편한 점도 없잖아 있었지만 (예, 피그마 코멘트로 논의가 진행되다보니 tracking 하기 어려움), 요구사항의 다양한 포맷을 경험하여 시야의 폭을 조금은 더 넓힐 수 있지 않았나 생각했다. 새로운 사람들과 협업하며 얻는 이러한 경험이 사이드 프로젝트의 장점이 아닐까 싶었다.
•
MVP 스펙을 조정하려고 많은 노력을 쏟았다.
◦
기획 파트에서 좋은 아이디어를 바탕으로 기능과 정책을 정의해주신것은 정말 감사할 따름이었다. 그러나 우리에게는 현실적으로 사이드 프로젝트에 집중할 수 있는 시간과 일정이 제한적이었다. 기획 파트에서 정의해주신 범위를 모두 수용하기에는 현실적으로 사이드 프로젝트 기간 내에 개발을 완료하는 것이 어려워보였다.
◦
팀 회의시간때, 우리가 정의한 기능들이 MVP에 필요한 스펙이 맞는가? 에 대해 지속적으로 말씀을 드렸다. 특히 사이드 프로젝트 MVP 치고는 UI 및 페이지의 수가 상당히 많았기 때문에 프론트 파트 분들의 업무가 과중될 것이 불보듯 뻔했다. MVP 기능 리스트를 우선순위에 따라 리스트업할 것을 요청 드렸고, 우선순위 중, 우선순위 하 는 과감히 MVP 스펙에서 제외한다고 말씀을 드렸다.
7주차: 개발집중기간 (1) - 시작
•
본격적인 개발 집중기간이 시작되었다. 빠른 커뮤니케이션과 논의를 위해 개발파트 분들과 오프라인 미팅을 진행했다. 매번 슬랙이나 게더로 얘기를 하다가 오프라인으로 미팅을 진행하니 확실히 미팅의 밀도가 높다는게 느껴졌다.
•
구현해야하는 API 수를 살펴보니 대략 30개 가량 나오더라. 사이드 프로젝트 MVP 치고는 역시 너무 큰 것 같다. 화면 정의서 등이 나왔을때 조금 더 확실히 MVP 스럽게 가자고 의견을 제안드렸어야 하나 스스로 아쉬움이 들었다.
•
개발 집중 기간으로 설정한 5주라는 기간이 생각보다 길지 않아서 그 기간 내에 잘 마무리할 수 있을지 우려가 조금 된다. 그렇다보니 함께 백엔드를 맡고 있는 시우님께 조금씩 푸시를 드리게 되는데.. 현업도 하면서 이걸 병행하는게 쉽지 않다는걸 아는데 푸시를 할 수 밖에 없는 입장이 조금 난감했다.
•
인프라 작업은 계속해서 발목을 잡고 있다. 비용을 최대한 줄여보기 위해 여러 방법을 찾아보았고, 개발반장 미팅에서 다른 팀들은 어떤지 확인해봤지만 딱히 소득은 없었다. 결국 NCP 크레딧을 쓰면서 최소한의 비용을 내기위해 VPC → Class 플랫폼으로 한번 더 마이그레이션을 진행하려고 한다. 인프라 작업을 최대한 빨리 끝내고 구현에 집중을 해야할 것 같다.
•
Nestia PoC를 마무리했다. 백엔드에서 사용하는 Response / Request Schema를 보통 swagger로 나타내 클라이언트 개발자분들이 다시 자료구조를 정의하기 나름인데, 이 라이브러리는 코드를 분석하여 빌드된 결과 파일을 SDK로 말아 NPM 에 업로드한후 프론트 단에서 import 하여 사용 가능하다. 오프라인 미팅 때 감도를 여쭤봤는데 아주 많이 만족하셔서 일단 도입하긴 잘한 것 같다고 생각든다. sdk로 말아서 npm에 올리고 클라이언트에서 쓰는 일련의 과정들이 현업에서는 잘 경험하기 힘든데, 사이드 프로젝트에서는 다양한 라이브러리를 써볼 수 있는 점은 참 좋은 것 같다. 개발자로서의 시야를 넓히는데 많은 도움이 된다.
8주차: 개발집중기간 (2) - 중간 회고
•
팀 빌딩이 되었을때 주기적으로 회고 및 피드백을 전달하자라는 그라운드 룰이 있었는데, 아직까지 회고 및 피드백 미팅을 진행못했었다. 늦기 전에 한번 진행하면 좋을 것 같아 먼저 PM 분께 제안을 드렸고, 8주차에 회고 및 피드백 미팅을 진행을 할 수 있었다.
•
회고 때 특히 공통적으로 나왔던 얘기들이 있었다. 팀원 한분 한분 빠짐없이 모두들 강한 열정과 책임감을 가지고 프로젝트에 임하고 있고, 적극적으로 아이디어를 제공하며 커뮤니케이션을 해줘서 좋았다는 내용이었다. 나 또한 사이드 프로젝트에 대한 안좋은 경험들을 주변에서 많이 들었던 지라.. 다소 많이 걱정도 되었었는데 팀원분들이 정말 다들 열심히 해주셔서 많이 공감되었다.
회고 내용 일부 발췌
•
개인 회고에서 역시나 가장 기억에 남은건 인프라 설정이었다. 보안도 중요하고, 안정성도 중요하고 다 좋지만.. 결국 현실에 주어진 조건에 맞는 적절한 의사결정을 하는것이 매우 중요하다는걸 이번 사이드 프로젝트에서 많이 느낄 수 있었다. 가장 최적의 옵션을 선택하기 위해 처음부터 주어진 조건들을 잘 파악하고 정리해놨다면 인프라 작업을 2번, 3번 하는 번거로움은 덜 했을 것이다.
•
인프라 작업이 마무리되고 본격적으로 나도 개발 및 구현을 시작하였다. 지금 정해진 일정대로만 작업이 진행된다면 큰 문제없이 프로젝트가 잘 마무리 될 것 같다. 사이드 프로젝트 외에도 지금 여러가지 일들로 인해 상당히 많이 바쁜 상황인데 하루 하루를 잘 계획해서 모든 일들을 잘 마무리 해야겠다.
9~11주차: 개발집중기간 (3) - 마무리
•
본격적인 개발 집중 기간을 7주차 ~ 11주차 (5주간)으로 잡았었는데, 백엔드 파트의 목표는 5주 내에 모든 API 개발을 완료하는 것이었다. 물론 일정을 조금 더 여유롭게 갖고 갈 수도 있었겠지만 14주차에 앱 출시를 위한 목표를 세운 만큼 못해도 11주차까지는 API 구현이 완료되어야 이후 남은 작업들 (API Integration, QA, 프로덕션 인프라 설정)들을 조금 여유롭게 갖고갈 수 있을거라 판단했다. 뿐만 아니라 혹시 모를 추가적인 이슈 대응을 위한 버퍼 기간을 두고 싶은 욕심도 있었다.
•
문제는 이 3주가 그 어느때보다 바쁜 기간이 되었다는 것이다. 사이드 프로젝트 외적으로 해야할 태스크들이 너무 많았다. 방송대 기말고사가 코앞으로 다가와서 많은 시간을 공부 및 강의를 듣는데 사용해야 했고, 엎친데 덮친격으로 회사에서 급하게 매우 큰 에픽을 들어가게 되었는데 일정도 매우 타이트해서 야근이 잦았다. 그 외에 스터디 및 헬스까지 겸해서 하려니 정말 몸이 열개라도 모자라다는걸 느낄 수 있었다. 그럼에도 발등이 불이 떨어졌고 해야할 일이 많으니, 잠을 쪼개고 주어진 시간을 최대한 잘 활용해서 태스크들을 쳐내기 시작했다.
•
현업과 다른 일들을 겸하면서 사이드 프로젝트를 한다는게 쉽지 않다는걸 많이 느낀 3주였는데, 앱 출시를 가장 큰 우선순위를 두다보니, 빠른 개발 속도를 중점적으로 작업을 진행하게 되었다. 자연스레 코드 리뷰를 디테일하게 진행하지 못하고 현실에 타협하는 상황이 나오는 것에 스스로가 많이 아쉬웠다. 시간에 쫒기다보니 하루는 회사에서 연차를 쓰고 사이드 프로젝트 개발에만 오롯이 집중하는 날도 나왔다. 
사이드 프로젝트를 위해 쏟은 시간을 돌아보면 주 평균 20~30시간을 썼던것 같다.
사이드 프로젝트를 위해 쏟은 시간을 돌아보면 주 평균 20~30시간을 썼던것 같다. •
서로 바쁘고 빠르게 개발을 하다보니 개발 방향에 대한 의사결정이 슬랙에서 주로 이루어지는 경우가 있었고, 히스토리를 추적하기가 어려워지고 컨텍스트를 파악에 어려움이 생기는 경우가 많아졌다. 바쁘더라도 중간 중간에 이러한 내용들을 잘 관리하는게 중요하다고 판단되어 주기적으로 백엔드 회의에서 업무 진행상황을 공유하고 요구사항을 Sync 맞추는 작업을 진행하였다.
•
개발 팀장의 역할을 맡다보니 일정에 대한 무언의 압박을 개발파트에 있는 동료분들께 종종 할 수 밖에 없었는데 3분 모두 정말 엄청난 책임감과 열정으로 프로젝트에 임해주시고 잘 따라와주셔서 정말 감사하고 감사하다는 생각이 많이 들었다.
•
결과적으로 11주차까지 성공적으로 API 개발을 완료하고 Dev환경에 배포를 완료하고 함께 작업하신 시우님 (백엔드 개발자 동료분)과 함께 화상으로 박수를 치며 고생했다는 말을 주고 받았다. 기존에 세웠던 목표를 달성했을때 오는 그 성취감과 보람은 일로 말할 수 없었다. 역시 나는 목표지향적인 사람이구나… 라는 걸 다시 한번 느끼는 순간이었다.
•
10주차 중간에 오랜만에 팀원 7분 모두 오프라인에서 모임을 가졌다. 서먹서먹했던 2주차에 처음 만났던게 엊그제 같았는데 벌써 이렇게 10주차가 된게 놀랍기도 했다. 그사이에 프로젝트를 진행하면서 동고동락을 하다보니 이전보다 더 편하고 부드러운 분위기에서 즐겁게 시간을 보낼 수 있었다. 이 멤버 그대로 1년에 4번씩 사이드 프로젝트를 진행해서 대박나서 엑싯하자!? 라는 농담도 주고 받았던게 기억에 남는다.
12~14주차: QA & 출시 준비
•
팀내 다른분들이 본격적으로 QA를 위한 작업들을 진행 해주셨고, 나는 운영환경 셋팅을 시작했다. Dev 환경 셋팅을 미리 해두고 이미지를 떠놔서 생각보다 수월하게 진행할 수 있었던 것 같다.
•
HTTPS / SSL + 도메인 구매 및 적용 등은 AWS 콘솔에서 손쉽게 한 적이 있는데, 인프라를 통하지 않고 직접 설정한 적이 없어서 시간이 얼마나 걸릴줄 몰라 넉넉하게 일정을 잡았었다. 그런데 막상 해보니까 생각보다 별게 없었다. 로드밸런서를 항상 많이 써와서 Nginx는 정말 오랜만에 써봤는데 Nginx를 써보는것도 나름 재밌는 경험이었다.
•
앞서 개발 집중 기간동안 정말 빠르게 달려왔는데 마무리 주차 동안에는 조금 숨을 돌리면서 쉬어가며 작업을 진행하고 있다.
•
추후 필요한 작업들을 백로그로 관리하면서 틈틈이 하나씩 진행중에 있다.
15주차 ~
•
QA에서 나오는 이슈들을 대응하면 기능 안정성을 높여나갔다. 우리 서비스는 사이드 프로젝트 치고는 UI/레이아웃 수가 상당히 많았는데 그렇다보니 프론트엔드 개발자분들이 엄청 많이 고생하셨다. 작업량이 많다보니 어쩔 수 없이 프론트엔드 쪽 QA 이슈가 많이 나왔는데 이를 어떻게 옆에서 도와 드릴 수 있는 방법이 없어서 개인적으로 안타까웠다.
•
우선 크리티컬한 이슈들을 대응하고 앱스토어/플레이스토어에 심사를 제출하고 우리는 결과를 기다렸다.. 다행히 16주차에 예정된 최종 프로젝트 경험 공유 밋업 직전에 앱스토어 심사를 통과했고 이어서 플레이스토어도 심사를 통과했다는 소식을 듣게 되었다.
•
무엇보다 프로젝트를 처음시작했을 때 팀원들과 함께 세웠던 목표를 달성하게되어 매우 뿌듯하고 기뻤다. 단순히 목표를 달성한것에 그치지 않고 꾸준히 서비스를 운영하면서 초기 기획 단계에서 제외된 요구사항들을 추가 하는등 고도화를 진행해보려고 한다.
사이드 프로젝트를 마치며
•
회사를 다니면서 따로 사이드 프로젝트를 하는게 절대 쉽지 않다는 것을 다시 한번 느꼈다. 필자 또한 조금 가벼운 마음으로 시작을 했으나, 생각보다 엄청 많은 리소스가 사이드 프로젝트에 사용 되었다. 정말 바쁠때는 1주에 50~60시간도 썼던것 같다.
•
우리 팀이 사이드 프로젝트를 성공적으로 마무리하며 목표를 달성한데는 여러 이유가 있었겠지만 개인적으로는 아래의 이유들이 가장 컸던 것 같다.
◦
빨리 친해지려고 각 팀원들이 노력했던 점
▪
라포가 형성되고 편안한 분위기가 형성됨
▪
솔직하고 자유롭게 의견을 내며, 피드백을 주고 받을 수 있게 됨
◦
팀원 모두가 바라본 공통된 목표
▪
기간 내에 MVP를 출시하고 서비스를 런칭하는 것
◦
목표 달성을 위해 각자 맡은 R&R에 따라 강한 책임감과 열정을 다해 사이드 프로젝트에 임한 것
◦
적절히 조율된 MVP 스펙
•
프로젝트가 잘 마무리된 것도 있지만 개인적인 아쉬움도 남았다.
◦
MVP 스펙을 잘 조율했다고 하지만 여전히 개발 파트의 업무가 과중되었던 지라, 화면 정의서가 전달되었을때 조금 더 적극적으로 MVP 스펙 조율을 하려고 노력하지 않았던 점
◦
개발 반장으로써의 R&R을 수행하며 항상 시간에 쫓기다보니, 팀 회의때 회의 안건 본질에만 집중을 많이 했던 것 같음. 그러다보니 다소 엄격하고 딱딱한 태도와 이미지로 팀원들을 대하게 되었던 것 같다. 조금은 더 여유를 가졌으면 더 좋지 않았을까
◦
인프라를 구축하는데 많이 헤맸던 점. 엔지니어로써 가장 중요한 것은, 우리에게 주어진 조건에 맞는 가장 적절한 환경을 구축하는 것
•
사이드 프로젝트는 회사에서 경험하지 못하는 새로운 다양한 경험들을 할 수 있게 되는 것 같다. 작은 규모의 인원들로 프로덕트를 만들다보면, 마치 초기 스타트업을 꾸려나가는 것과 같은 경험을 하게 된다. 아이템 선정, MVP 스펙 정의, 기술 스택 정의, 개발 프로토콜 정의, 요구사항 리뷰, 구현 설계 작성, 구현, 인프라 구축, QA, 프로덕션 출시 등등 하나의 서비스가 세상에 나오기까지 필요한 A to Z를 직접 경험할 수 있다. 회사 외적으로 이러한 새로운 프로덕트 경험들을 하고 싶다면 사이드 프로젝트를 적극 추천 드린다.
•
마지막으로 우리가 만든 서비스를 공유드리며 포스팅을 마치고자 한다. 앞으로도 서비스 안정화 및 고도화를 준비중에 있으니 많은 관심 부탁 드립니다!
