CH 1. Develop

이직 사이에는 충분한 쉼을 가지자

올해 가장 잘한 일이라고 생각한 것은, 퇴사와 구직 사이에 충분한 휴식 시간을 둔 것이었다. 작년 11월 말에 퇴사하고 올해 3월 말에 입사했으니, 약 4개월 가량을 백수로 보낸 것이다. 물론 작년 12월 말까지는 학교 수업을 듣긴 했지만, 교양 2과목에 체육 1과목만 들었으니 거의 없다 치고…

이번에 길게 쉰 이유는 전 회사를 다니면서 온 번아웃 때문이긴 한데, 굳이 번아웃 때문이 아니더라도 이직 사이의 긴 휴식 시간은 크게 세 가지 메리트를 가진다고 느꼈다.

• 다음 회사를 보다 신중하게 고를 수 있다 - 항상 하는 이야기이지만, 회사에서 보내는 시간은 깨어 있는 시간의 반 이상을 차지하므로 현재의 행복에 큰 영향을 미치며, 이 회사에서 어떤 경험을 쌓고 어떻게 성장하느냐에 따라 미래의 행복에 큰 영향을 미친다. 그만큼 구직은 인생에서 가장 중요한 의사결정 중 하나이며, 충분한 시간을 들여 본인이 원하는 명확한 구직 방향성을 정하는 게 필요하다고 생각한다. 이런 고민은 당연히 많은 에너지와 시간을 필요로 하는데, 회사를 다니는 도중보다는 백수 상태일 때가 이러한 고민을 할 여유가 훨씬 넘쳐난다. 넘치는 시간 및 체력의 여유는 더 좋은 의사결정을 할 확률을 높여준다.

  또한, 그냥 면접 보는 것 자체가 육체적 / 정신적으로 피로하다. 이번 구직 사이클에서는 5개 회사에 지원했는데, 고작 다섯 개의 회사와 면접 일정을 조율하고, 면접을 보고, 협상을 진행하는 것도 스트레스가 이만저만이 아니었다. 만약 회사를 다니면서 이직을 준비했다면 면접 일정이 꼬여서 커뮤니케이션이 더 피곤해지거나, 피로감을 줄이기 위해 아예 지원하는 회사 수를 확 줄이는 바람에 선택지가 줄어들었을 것 같다.

• 경험이 아닌 지식을 쌓을 수 있다 - 성장을 위해서는 지식과 경험 두 가지가 함께 쌓이는 게 중요하다. 동일한 경험을 하더라도 지식의 양에 따라 깨닫는 바가 다르고, 동일한 지식을 가졌더라도 가진 경험에 따라 지식을 유용하게 활용할 수 있는 정도가 다르다. 지식은 개인의 공부를 통해, 경험은 주로 실무를 통해 쌓을 수 있다.

  회사를 3년 정도 다니고 퇴사할 무렵, 나는 3년 간 쌓은 경험의 양에 비해 지식의 양이 부족하다는 사실을 느꼈다. 회사를 다니는 도중에도 지식과 경험을 밸런스 있게 쌓아갈 수 있는 사람도 있겠지만, 나는 지식의 축적을 선호하기보다는 일단 일이 되게 하는 걸 좋아하는 사람이라 경험 쪽으로 밸런스가 치우쳐져 있었다. 이런 밸런스를 개인 시간을 더 투자해서 맞추기에는 학교와 사이드 프로젝트를 병행하고 있기도 했고, 번아웃이 와서 공부할 의욕도 나지 않았다.

  4개월의 긴 휴식 기간은 의욕을 회복하고, 그동안 쌓아 뒀던 공부하고 싶은 목록을 해치우기에 안성맞춤인 시간이었다. 휴식 시간 동안 공부했던 SRE, 소프트웨어 테스팅, gradle, coroutine, DDIA 등은 지금 다니는 회사에 적응하는 데 큰 도움을 주었다.

• 시간이 넘치는 감각을 느낄 수 있다 - 왜, 그런 트위터 짤이 있지 않은가. 더 소중한 것을 낭비할수록 더 즐겁고, 낭비 중 가장 재밌는 건 돈 낭비 시간 낭비라고. 4개월간 돈은 아니지만 시간을 흥청망청 써보니까 정말 재밌었다. 처음 두 달 간은 정말 놀기만 했다. 지인들한테 연락해서 일주일에 한두 번 술 마시고, 사람 안 만나는 날에는 느지막이 일어나서 하루종일 게임하고, 게임이 살짝 질린다 싶으면 넷플릭스 켜서 그동안 못 봤던 유명한 드라마 켜놓고 가볍게 운동하고, 저녁 대충 챙겨 먹고 들어와서 다시 게임하고.

  그렇게 두 달 정도 흥청망청 놀다 보니, 슬그머니 무언가 생산적인 일을 하고 싶어졌다. 시간이 흐르는데 쌓이는 것 하나 없이 시간이 휘발되고 있다는 게 아깝게 느껴졌다. 나만 제자리에 퍼질러져 있고 세상은 앞으로 나아가는 게 똥줄이 타서 그런 거겠지. 아무튼 2월부터는 점심 때쯤 되면 밥 먹고 카페에 가서 저녁 먹을 때까지는 공부를 했다. 넓은 테이블이 있는 채광 좋은 카페에 가서 공부를 하는 느낌이 나쁘지 않았다. 사람들이 내는 소음이 얽혀서 만들어 낸 알아들을 수 없는 소음이 좋았고, 공부를 하면서 지적 호기심이 채워지는 느낌이 즐거웠다. 그렇게 한 달 정도 공부를 하니까, 이제 슬슬 사람들이랑 부대끼면서 무언가를 이루는 성취감을 느끼고 싶었다. 그래서 이직을 준비했다.

  쉬는 동안의 이야기를 횡설수설했는데, 그래서 하고 싶은 말이 뭐냐면 시간적 여유가 많다 못해 넘쳐 흐르면 내가 뭘 좋아하는지를 더 잘 알게 된다는 것이다. 마치 PMF를 찾는 것처럼, 지루함을 견디지 못해 이것저것 시도해 보면서 내가 무엇을 할 때 즐겁고 행복한지를 더 잘 알게 된다. 게임이 재밌긴 한데, 저 장르의 게임은 해보니 생각보다 별로 재미가 없고 이 장르는 생각보다 재밌네? 이건 공부해 보니까 자꾸 딴 짓을 하게 되네. 결국 인생을 더 행복하게 살기 위해서는 ‘나’를 이해하는 게 중요한데, 시간은 ‘나’에 대한 여러 ‘실험’을 하기에 필수적인 비용이다. 이러한 시간의 낭비는 백수가 아니면 누리기 힘든 사치인 것 같다.

웬만하면 다음 번 이직 때도 퇴사와 구직 사이에 충분한 쉼을 두려고 한다. 쉼없이 회사에서 일하기 위해 인생을 사는 건 아니니까. 중요한 건 나를 위해 더 좋은 선택을 하는 것이고, 더 좋은 선택에는 보통 많은 시간이 필요하다.

새로운 환경, 새로운 배움

그렇게 백수 기간을 마친 후 내가 입사하게 된 회사는 라포랩스라는 회사였다. 이번 구직에서 내가 세운 최우선 가치관은 아래 3가지였고, 라포랩스가 이 조건에 잘 맞는다고 생각했다.

• 제품 개발이 아닌, 개발팀이 더 효율적으로 일할 수 있는 구조에 대해 고민하는 경험을 쌓을 수 있는 회사
• 스톡옵션이 가치가 있는 회사 - 스톡옵션이 가져다주는 가치를 직접 느껴보고 싶다.
• 성장하고 있는 회사 - 회사가 성장해야 점점 더 어려운 챌린지가 발생한다.

새로운 회사에 입사하면서 걱정했던 부분은 크게 두 가지였다.

• 회사 사람들과 잘 친해질 수 있을까 - 전 회사에는 친한 친구가 이미 입사해 있어서, 적응에 큰 도움을 받았다. 반면 라포랩스에는 내가 아는 지인이 한 명도 없었는데, 내향적인 나한테 아는 사람 하나 없는 곳에 가서 사람들과 친해지라는 것은 개발보다 훨씬 어려운 과제였다. 솔직히 직장 생활 3년 하면서 1대1로 대화하는 스킬은 그나마 꽤 능숙해졌다고 생각하는데, 모르는 사람이 다수인 환경에서 사람들과 친해지는 건 아직까지는 버겁다.
• 업무적으로 회사에 잘 적응할 수 있을까 - 내가 전 회사에 입사한 타이밍은 타다 서비스가 런칭된 지 1개월 된 시점이었다. 즉, 코드 베이스에 레거시가 거의 없었다. 그 상태에서 3년을 다니니 코드 베이스의 거의 모든 레거시와 히스토리를 알고 있었다. 반면, 내가 라포랩스에 합류하는 타이밍은 이미 라포랩스가 창립된지 1년 반 정도가 지난 시점이었다. 즉, 처음으로 레거시 시스템이 남아 있는 조직에 적응해야 하는 상황이었다. 과연 내가 레거시 시스템, 그것도 한 번도 경험해보지 못한 커머스 도메인의 레거시 시스템을 빠르게 잘 파악하고 퍼포먼스를 낼 수 있을지 의문이었다.

다행히, 두 가지 걱정 모두 기우였다. 첫 번째 걱정거리는 후술할 사내 크로스핏 동아리(?) 덕분에 자연스럽게 해결됐다. 두 번째 문제는 생각보다 나 개인의 능력도 충분했고(적응을 잘 한 덕분에 자신감이 올랐다), 팀원들의 도움도 많이 받아서 큰 문제가 되지 않았다.

이번 이직에서 가장 중요하게 배운 것은, 다양한 경험을 쌓는 게 내 생각보다 훨씬, 훨씬 더 중요하다는 점이었다. 전 회사와 현 회사는 많은 부분에서 많은 차이를 보였다. 핵심적인 요소로는 조직 구조나 팀 리더의 성향, 코드와 시스템 아키텍처, 그리고 내 R&R이 있다.

• 조직 구조 - 전 회사는 기능 조직이었지만, 현 회사는 목적 조직인 스쿼드와 crosscutting concern을 처리하는 플랫폼으로 분리되어 있다.
• 팀 리더의 성향 - 전 회사는 제품 개발 속도에 집중하고 IC로의 경향이 강하게 보였던 반면, 현 회사는 확장성과 안정성을 꽤 중요하게 여기고 조직 관리와 아키텍팅 관련된 업무를 주로 수행한다.
• 코드 아키텍처 - 전 회사는 common이라는 거대한 모듈이 있고, 도메인 간 통신이 직접적인 함수 호출로 처리된다. 한편 현 회사는 도메인별 / 계층별 모듈이 분리되어 있고, 도메인 간 통신이 주로 네트워크를 통한 API 호출이나 도메인 이벤트 발행을 통해 처리된다.
• 시스템 아키텍처 - 전 회사는 모노리스 아키텍처에 RDB, Kinesis, SQS 등을 사용했다면, 현 회사는 MSA에 RDB 뿐만 아니라 DynamoDB도 사용하고, Kafka, CDC, ES, Redis 등 역시 사용한다.
• 내 R&R - 전 회사에서는 온전히 빠른 제품 개발에 집중했다면, 현 회사에서는 자동화와 구조적인 개선을 통한 확장성과 안정성 확보가 중요하다.

전 회사와 현 회사가 이토록 여러 방면에서 다르기 때문에 두 회사에서 경험하는 것들이 상당히 다른데, 덕분에 다양한 경험을 쌓는 것의 이점을 절실히 느끼고 있다.

다양한 경험이 중요한 첫 번째 이유는 사람의 사고가 경험에 기반할 수밖에 없기 때문이다. 망치 든 사람의 눈에는 세상 모든 게 못으로 보인다는 말이 있듯이, 개발자 역시 어떤 문제를 맞닥뜨렸을 때 자신이 익숙한 도구로 먼저 해결하려는 경향을 보인다고 생각한다. 예를 들어, 메세지 큐 중 Kafka만 사용해 본 사람은 메세지 큐가 필요한 상황에 가장 먼저 Kafka를 떠올릴 것이다. 반면 RabbitMQ, SQS, 인메모리 큐 등을 모두 사용해 본 사람이라면 더 적합한 기술을 선택할 가능성이 높다. 이러한 사고의 제한은 당연히 나 역시 경험하고 있는데, 예를 들어 나는 전 회사에서 RDB만 사용해 봤기 때문에 MongoDB나 DynamoDB 등의 NoSQL을 왜 써야 하는지 아직 잘 모르겠다. schema-on-read가 필요하다면 JSON column 타입이 있는데 굳이 NoSQL을? 하지만 NoSQL을 직접 사용해 본다면 생각이 달라질 수…도 있겠지? ㅋㅋ

두 번째 이유는 개인적인 이유다. 나는, 적어도 아직까지는, 내가 경험하지 못하고 뇌피셜로 만들어낸 솔루션 - 코드 아키텍처, 조직 구조, 협업 프로세스 등 - 에 확신을 가지고 타인을 설득하며 밀어부칠 만한 개발 능력이나 소프트 스킬을 가지고 있지 않다. 그래서 내게 필요한 건 내가 떠올린 솔루션이 이 조직, 이 상황에서 잘 working 할 것이라는 경험적 확신이라고 느꼈다. 예를 들어, 이전 회사의 코드 베이스는 도메인 간 강결합이 상당히 강했는데, 이 때문에 새로운 사람이 합류했을 때 코드 베이스를 이해하는 데 상당한 어려움을 겪었다. 그래서 도메인 이벤트를 도입해서 의존성을 역전시켜 끊어버리면 어떨까 싶어서 도입을 시도해 봤는데, 결국 시간도 부족하고 확신도 없어서 흐지부지 끝났다. 하지만 도메인 이벤트를 제대로 사용하는 코드 베이스를 경험해 본 지금이라면 확신을 가지고 끝까지 추진했을 것 같다. 머리가 나쁘면 몸이 구르면서 사고를 확장시켜야지!

언제까지 일할 수 있을까

한편, 올해는 스스로 어떻게 성장해야 할지에 대한 고민이 많이 되는 한 해였다. 올해 가장 답답함을 느끼고 있는 부분은, 회사를 다니며 스스로 성장했다는 느낌이 잘 안 든다는 점이다. 전 회사를 다니던 3년간은 매년 알을 깨는 느낌 혹은 점프 업한 느낌을 받았다. 1년차에는 시니어의 도움 없이 혼자 작은 기능을 책임지고 개발할 수 있겠다는 감각을, 2년차에는 제품 개발 사이클과 도메인 설계에 대해 실용적인 수준까지 이해했다는 감각을, 3년차에는 IT 제품에서 있을 만한 웬만한 대규모 기능 개발은 기획부터 배포까지 컨트롤 가능하다는 감각을 느꼈다.

반면 올해는 알을 깨고 시야가 넓어진다는 느낌을 받지는 못했다. 물론 새로운 도메인, 새로운 사람들, 처음 경험해보는 플랫폼이라는 조직, 그리고 새 R&R에서 배운 것 자체는 상당히 많다.

• 모니터링과 장애 대응
• 삽질을 체계적으로 하는 방법
• 코드베이스 설계
• MSA 환경에서의 개발 경험 및 monolith → MSA 분리 경험
• 도메인 이벤트의 유용성과 운영 방식
• Kafka, CDC, Redis 사용 경험
• 속도가 아닌, 안정성과 확장성이 가치판단의 기준이 되는 사고 방식

하지만, 배운 것 자체는 많아도 정작 내가 할 수 있는 일의 범위가 확장되었다는 느낌이 들지는 않는다. 조금 더 구체적으로 설명해 보자면, 지금 내가 가지고 싶은 능력은 크게 두 가지가 있다.

• 기술적으로, 애플리케이션 레벨을 벗어나서 더 로우 레벨의 디버깅이 가능해지는 것
• 개발팀의 병목 지점을 정확히 진단하거나 예측하고, 이를 해결할 적합한 방안을 제시하는 것

라포랩스에서 일한 8개월 동안 점프 업을 하지 못한 것 자체는 충분히 그럴 수 있다고 생각한다. 매년 점프 업할 것이라는 기대는 하지 않았으니까. 앵간한 테크 기업의 레벨제를 생각해보면 최고 레벨이 10을 넘지 않는데, 커리어는 대충 20년 정도라고 생각하고 무식하게 평균을 내면 한 번의 점프 업에 2~3년 정도 걸리는 게 맞다. 문제는, 위 능력을 갖추기 위해 무엇을 공부 / 경험해야 하는지조차 감이 안 잡힌다는 것이다. 내가 좋아하는 지인의 이야기 중에, 다음 레벨로 올라가기 위해서는 현재 레벨의 업무를 잘하는 게 아니라 다음 레벨처럼 생각하고 일하는 게 중요하다는 말이 있다. 근데 다음 레벨처럼 생각하고 일하기 위한 방법을 잘 모르겠다.

성장하지 못하고 있다는 감각에서 더욱 초조함을 느끼는 이유는, 현 회사에서 면접관으로 활동하면서 시니어 면접을 많이 봤기 때문이다. 나보다 경력이 훨씬 긴 업계 선배님들께 다양한 이유로 불합격을 드리면서, 과연 나는 40살, 50살이 됐을 때 불합격을 받지 않을 수 있을까… 하는 생각이 자꾸만 들었다. 나는 뛰어난 사람들과 일하는 게 즐겁고, 행복하다. 팀원과 손발이 착 맞는 느낌, 그리고 다 같이 어려운 문제를 풀어 나가는 성취감이 좋다. 그런 팀에 있으려면 나 역시 뛰어남을 유지해야 한다.

시니어 면접에 몇 번 들어가고 개인적으로 받은 느낌은, 성장에는 데드라인이 있다는 것이다. 이 정도 연차에는 최소 이 정도까지는 성장해야 한다, 라는 데드라인. 일반적으로 이직을 하든 한 회사 내에서 연봉 협상을 하든 연봉은 단조 증가하고, 그만큼 그 사람에게 기대하는 바가 커진다. 이러한 상황에서 성장의 정체가 오래 지속되면 그 사람이 창출하는 비즈니스 가치가 연봉에 비해 확연히 적어지는 타이밍이 오는데, 이 시점부터는 구직이 급격히 힘들어진다. 시니어 롤을 기대하고 채용하기에는 능력적인 측면에서 불합격이고, 낮은 연봉을 주고 IC를 시키기에는 동일한 연봉의 저년차 개발자를 채용하는 게 낫기 때문이다.

사실 아직 27살밖에 되지 않았고, 이런 걱정을 하기에는 상당히 이른 시점이긴 하다. 그래도 주변 사람들이 빠르게 성장하는 것을 보고 있으니… 마음 한 켠에서 작은 초조함이 항상 느껴진다. 뭐, 그래도 지금까지처럼 어떻게든 되지 않을까? 내가 할 수 있는 것이라곤 결국 지금까지와 동일하게 명확한 방향성을 가지고 노력을 꾸준히 쌓아가는 것밖에 없다.

계단정복지도 : 개발 이야기

내 2022년을 이야기하기 위해서는 사이드 프로젝트 이야기를 빼놓을 수 없다.

홍보도 할 겸 내가 참여하고 있는 사이드 프로젝트에 대해 가볍게 소개하고 넘어가려고 한다. 나는 2021년부터 <계단정복지도>라는 서비스를 만드는 데 참여하고 있다. 계단정복지도는 건물과 장소의 접근성 정보를 수집하고 제공하기 위한 서비스인데, 원활한 정보 수집을 위해 오프라인에서 사람들을 모아 할당량 만큼의 정보를 수집하는 오프라인 활동도 함께 운영하고 있다. 후자를 ‘계단뿌셔클럽 활동’, 혹은 간단하게 클럽 활동이라고 한다. 2021년에는 성남을 대상으로 운영했고(이하 시즌 1), 2022년에는 서울로 지역을 확장하기 위한 베타 서비스를 운영했다(이하 시즌 2). 2023년 봄~여름 즘에 서울 전역에 오픈하는 것을 목표로 하고 있다.

계단정복지도 프로젝트와 팀에 대한 소개는 각각 서비스 소개 페이지와 팀 소개 페이지에 보다 자세히 적혀 있으므로 관심 있으신 분은 해당 페이지를 읽어 보시면 될 것 같다. 또한, 이미 안드로이드 / iOS 베타 앱이 나오긴 했지만 앱마켓에는 아직 올리지 않았는데, 혹시 앱을 사용해 보고 싶은 분이 있다면 이메일로 연락 부탁드린다 :)

서비스 소개는 이쯤하고, 개발 이야기로 넘어가자. 시즌 1을 회고하며 나왔던 아쉬웠던 부분은 크게 세 가지였다.

1. 수집 대상이 성남에 한정되어 있었다.
2. 웹이 아니라 앱이 있었다면 사용성도 더 좋았을 것 같고, 더 재밌는 기능들도 많이 넣어 봤을 것 같다.
3. 서비스가 수집에만 초점이 맞춰져 있어서 정보 조회가 어렵다.

시즌 2에서는 정확히 이 세 가지 문제를 해결하고자 했다. 앱을 만들고, 클럽 활동을 서울로 확장하자. 그리고 정보 조회 플로우를 위한 기능을 추가하자. 명확하고 좋다.

하지만 결론부터 말하자면 문제를 푸는 과정은 정말 힘들었다. 그냥 순수하게 시간이 부족한 관계로 잠을 덜 자서 힘들었다. 보통 평일 동안의 내 하루 일과는 9시 기상 → 출근 → 9시 퇴근 → 크로스핏 → 밤 11시 반 ~ 12시쯤 집에 도착이었는데, 여기에 사이드 프로젝트 개발까지 끼워 넣으려니 잠을 잘 시간이 살짝 부족해졌다. 여기에 자업자득인 요소도 있었다. 혼자 서버 개발을 했던 시즌 1과는 달리 시즌 2에서는 친한 개발자 한 명을 꼬셔서 둘이서 서버 개발을 했는데, 둘이 이것저것 새로운 기술도 써보고, 평소에 구상하던 아키텍처도 도입해 보겠다고 욕심을 내다가 개발 스펙이 마구 증식했다. 개발 막바지에는 새 기술을 쓰겠다고 한 과거의 내가 미웠다 ㅋㅋ 제품 스펙만 개발하는 것보다 거의 3~4배는 걸린 것 같다. 결국 2022년에는 정보 조회 플로우는 하나도 구현 못 하고, 앱 출시 + 정보 수집 플로우 보강 정도에서 그쳤다.

하지만 그렇게 고생한 덕분에, 그냥 기능을 찍어내는 데만 집중했다면 경험하지 못했을 것들을 많이 경험했다.

• 도메인별 gradle 모듈 분리 및 hexagonal architecture 도입 - 개발자가 100명을 넘어가면 또 모르겠지만, 적어도 웬만한 개발팀 사이즈에는 이 구조가 가장 적절하다고 느꼈다. 도메인별 모듈 분리가 가져다 주는 캡슐화, 그리고 hexagonal architecture를 통한 use case의 명시적 분리가 코드를 이해하기 쉬운 구조로 유지해준다.
• PostgreSQL - 하드하게 안 써봐서 MySQL과 비교가 좀 어렵긴 하지만, sql 문법이나 도구들이 생각보다 꽤 달라서 mysql에 익숙했던 나는 사용하기 상당히 불편했다. 대충 찾아본 봐로는 고성능이 필요한 경우 PostgreSQL이 더 유리하다고 봤는데, uber도 MySQL로 버틸 수 있는데 굳이 성능 때문에 PostgreSQL을 사용할 필요는 없지 않을까 싶다.
• SOPS - 마음에 쏙 든다. secret을 git repository에 커밋할 수 있어서 이력 관리도 되고, 리뷰도 가능해진다. diff도 yaml path 단위로 따로 떠진다. 앞으로 항상 도입하고 싶은 도구.
• SQLDelight - JPA의 query method가 얼마나 편한지 알 수 있었다. ORM이 아닌 단순한 query mapper가 필요한 경우에도 JPA query method의 편의성만 보고 JPA를 선택할 만하다고 생각했다. 쿼리 직접 짜는 게 별 거 아닌 것 같아 보이지만, 생각보다 진짜 귀찮았다… 그리고 트랜잭션 관리 시스템을 새로 구축하는 것도 상당히 귀찮았다.
• K3s - 내가 설치하진 않아서 설치가 얼마나 힘든지는 잘 모르겠는데, k8s 환경에서 운영은 하고 싶지만 EKS 등의 managed kubernetes service를 쓰는 건 너무 비싼 경우에 매우 적절한 선택이 될 것 같다.
• AWS Lightsail - free tier를 사용하지 않는다면, 확실히 가격은 싼 것 같다. 사이드 프로젝트를 해보니 서버비 절약의 필요성을 절실히 느끼게 됐는데, 맨날 회사 돈으로 클라우드 비용 지불하다가 사비로 부담하려니까 욕이 절로 나오는 가격이었다… 시즌 1에서는 처음에 EKS 써보고 싶어서 EKS로 띄웠다가 첫 달에 20만원 내고 바로 ECS로 바꿨는데, ECS보다도 비용이 반으로 줄어서 마음에 든다. 하지만 상당히 불편하다. 테라폼 지원도 잘 안 되는 것 같았고(인프라 작업은 주로 동료 개발자가 해서 정확히는 모른다), 다른 AWS 컴포넌트와의 통합도 잘 안 되는 것 같았다. 그냥 Lightsail만의 세상이 있는 느낌? 개발 속도가 중요한 프로덕션 레벨의 개발에서 사용하긴 힘들 것 같았다.

가장 중요한 점은, 나(와 동료 개발자)가 생각하는 서버 개발의 best practice에 대해 고민하고 구축했다는 것이다. 회사에서는 여러가지 이유로 도입하기 어려운 이론적인 아이디어를 사이드 프로젝트에서는 직접 코드로 구현하고 몸으로 맞아가면서 아이디어의 효과를 검증할 수 있다. 그러면서 자연스럽게 우리가 했던 고민들이 그저 말이 아닌, 누군가가 실제로 사용하는 서비스의 코드 베이스라는 형태로 남는다. 회사 코드가 아니니까 소스 코드를 오픈하여 다른 사람과 공유할 수도 있다. 언제든지 참고할 수 있는 나만의 best practice가 코드로 구현되어 있다는 게 참 멋지지 않은가?

또한, 무언가 새로운 기술이나 개념을 사용해 보고 싶을 때 이 코드 베이스를 테스트베드로 사용할 수도 있다. 그냥 TODO 앱 같은 토이 프로젝트에서 깔짝깔짝 기술을 사용해 보는 건 거의 의미가 없다고 생각하는데, 계단정복지도 서비스는 제품 스펙도 회사에서 운영하는 IT 제품 정도는 아니지만 꽤나 복잡하고, 실제로 사용자가 존재하는 서비스이기 때문에 운영적인 측면도 고려하며 개발을 진행해야 한다. 그러면서도 내 맘대로 이것저것 고쳐도 반대할 사람이 없다. 테스트베드로 사용하기 아주 적절하다.

내년에는 올해 일정이 밀려 개발하지 못한 정보 조회 플로우를 주로 개발하게 될 것이다. 정보 조회 플로우가 개발되면 사용자 수가 많이 늘어날 수 있으니, 운영적인 측면도 많이 보강해야 한다. 현재는 안정적인 서비스 운영을 위해 해 놓은 작업이 거의 아무것도 없다. 모니터링 시스템을 구축해야 하는데, 사이드 프로젝트라 비용적인 부분이 상당히 중요해서 datadog 같은 걸 쓸 수는 없고, 수기로 구축해야 한다. 또한 앱을 앱마켓에 출시하면 잘못 수집된 정보를 수정하는 등의 운영이 필요할 테니, 운영을 위한 어드민도 어느 정도 개발해야 한다. 이 외에도 앱의 이점을 살리기 위한 푸시 발송 시스템(like braze)이나 데이터 분석을 지원하기 위한 데이터 파이프라인도 만들어야 한다. 내년도 진짜 즐겁고… 힘들겠다 ㅋㅋ

(다음 글에서 이어집니다)