서론
1월에 작성하고자 했던 상반기 회고가 벌써 3월이 되어서야 작성을 시작했다. 하반기 회고도 작성해야 되는데... 시간이 너무 없는 느낌이다. 미뤄 온 것들을 풀고 있는 느낌? 시간이 갈수록 머리로 들어간 것이 많아지고 그것들을 응용해서 더 많이 머리에 집어 넣는 느낌이다. 기억을 많이 할 수록 머릿속이 복잡 해질 것이라 생각했는데 아니다. 기억을 많이 할수록 그 기억을 이용해서 더 단순하고 쉽게 기억하고 푼다. 이래서 단계 별 성장이라 하나보다. 참 신기한 것 같다.
이제 회고를 해야 하니 2023년엔 무엇을 했는지 한 번 짚어보자.
- 2023.01.01 스타트업 재직
- 2023.04.01 물류 모바일 앱 개발
- 2023.06.30 퇴사
그러면 이제 하나 하나 어떤 일들이 있었는지 생각해보자.
본론
2023.01.01 스타트업 재직
내가 다닌 스타트업은 서로를 히어로명으로 부르는 문화를 가진 회사다. 나의 이름은 "춘식" 이었다. 내가 좋아하는 카카오 캐릭터 이름이다. 모두가 서로를 히어로명으로 부르는 덕분에 동명이인 문제 해결, 이름을 부를 때 한 층 부드럽게 부를 수 있는 이점, 자신이 좋아하는 히어로명을 쓰는 덕분에 오는 책임감 등 큰 이점을 가진 문화라고 본다. 물론 몇몇 사람들은 유치하다고 할 수도 있지만 말이다. 나는 매우 만족했었다. 귀여운 것을 좋아하기 때문이겠지.
누군가 얼마나 노력 했는가를 그나마 객관적으로 생각 해볼 수 있는 방법은 내가 그 사람처럼 할 수 있을까? 생각 해보는 것이다. 본부장님과 개발 팀장님이 개발팀 문화와 분위기를 화기애애하게 만드는데 많은 노력을 하셨다. 내가 나중에 팀장이 된다면 그렇게 사람들을 화합시킬 수 있을까? 아직은 어려울 것 같다. 그만큼 나는 좋은 분위기에서 일을 할 수 있었다. 본부장님께선 주도적으로 일할 수 있도록 최대한 밀어 주시는 분위기였고 개발 팀장님은 장애물이 생기지 않도록 최선을 다 하셨다. 개발 문화는 이 곳에서 거의 다 배운 것 같다.
사람들 또한 위의 문화도 보고 온 사람들이어서 그런지 분위기 자체가 좋았다. 최대한 충돌하지 않으려 노력하는 모습이 보였고 나도 그러기 위해서 노력하게 되었다. 서로를 존중하고 배려 하면서 일을 한다는 것이 얼마나 가치 있는 것인지 다시금 생각하게 되었다. 사람들과 일을 즐기며 한다는 것을 가르쳐준 회사였다. 물론 장점만 있냐 하면 그건 아니다. 스타트업에서 가질 수 있는 단점도 당연히 있다. 많은 것들을 빠르게 시도해서 그런지 익숙하지 않은 사람들은 힘들어 했다. 문화적으로도, 일적으로도 빠른 변화는 빠른 적응과 학습을 필요로 한다. 일하던 방식이 고착된 사람일 수록 더 힘들어 한다. 이런 단점은 스타트업 뿐만 아니라 개발 조직에 적응하기 힘든 포인트로 작용하기도 한다. 하지만 이런 단점 또한 성장을 위한 밑거름이 될 것이다.
2023.03.01 물류 모바일 앱 개발
php로 되어 있던 기존 서비스를 vue와 spring boot로 탈바꿈 하기 위한 준비를 했다. 기존 서비스는 외주를 맡겨놓은 상태 였고 곧 완료가 될 상태 였기 때문에 해당 스택에 맞게 개발할 수 있는 역량을 갖추는게 가장 우선순위로 보였다. 물론 외주는 내가 맡긴건 아니다. 나는 둘 다 경험이 있으니 핸들링이 가능한데 다른 개발자 분들은 아니었기에 해당 스택에 대한 경험을 만드는 일이 필요했다. 물론 역량이 좋으신 분들이니 금방 하실텐데 개발과 운영은 다른 이야기니 단기간에 해낼 수 없는 것은 분명히 있는 법이다.
vue는 이전 회사에서 에디터 개발을 하면서 도가 텄고 spring boot는 원래 안드로이드 앱이랑 같이 코틀린으로 개발 했던 짬밥이 있으니 둘을 동시에 개발 했다. vue는 나랑 퍼블리셔 한 분이 같이 하셨고 spring boot는 백엔드 개발자 두 분이 같이 붙어서 했다. vue와 spring boot 둘 다 보일러 플레이트를 갖고 있어서 쉽게 개발을 시작할 수 있었다. 주어진 시간이 많지 않았으니 박차를 가했다. 두 분은 익숙해지는 시간이 필요했는데 얼마 지나지 않아 빠르게 개발을 하시기 시작했다. 그렇게 약 두 달의 시간이 지나고 앱의 릴리즈를 시작했다.
많이 고민 했던 부분은 어떻게 시간 안에 릴리즈하지? 였다. 시간은 꽤나 촉박했다. 화면이 5개 이상이고 복잡한 기능도 포함되었으며 디비 마이그레이션도 고려해야 해서 다중 디비 연결도 해야 했다. 새벽 시간에 사용 하는 앱인 만큼 순간적인 속도가 매우 중요했고 데이터가 많은 만큼 최적화에 대한 고민을 많이 했다. 그럼에도 주어진 시간 안에 얼추 성공적으로 프로젝트를 완료할 수 있었다. 어떻게 그럴 수 있었을까?
개인적인 생각으로 첫 번째는 사람이 중요했다고 생각한다. 누구 하나 큰 불만을 이야기 하는 사람은 없었다. 다들 작은 불만은 당연히 있을 수 있지만 그것 때문에 일을 미루는 법은 없었으며 어쩔 수 없는 경우엔 빠르게 알려 도움을 요청했다. 대표님의 적극적인 지원이 있었으며 아이디어의 문제는 본부장님께서 해결해 주셨다. 필요한 인원들이 정말 히어로처럼 빠르게 움직여 적재적소에 문제를 해결하였다. 릴리즈를 하고 나서도 마찬가지였다. 너무나 당연하게 릴리즈 하자마자 앱에서 물류 입고 확인이 안되는 버그가 터졌고, 이내 분주해지기 시작했다. 개발팀은 10분도 안돼 해당 문제를 파악 및 문제가 되는 부분을 분석하였고, 물류 전체 갯수와 입고된 갯수가 소수점으로 계산되어 정확하게 계산되지 않고 있다는 것을 알아냈다. 참고로 자바스크립트에선 소수점 계산이 정확하지 않기 때문에(모든 부동 소수점 연산을 하는 존재가 그렇지만 자바스크립트는 심하다) 프론트에서 계산을 하면 서버와 값이 달라질 수 있다. 굉장히 크리티컬한 이슈 였지만, 빠르게 해당 부분을 서버에 구현하였고, 문제를 해결할 수 있었다.
두 번째는 기획이다. 이 기획에는 기간 산정과 개발 기획이 모두 들어간다. 기획의 영역은 경험이 가장 큰 밑거름이 되는 것 같다. 개발이 필요하다는 얘기는 조금 더 일찍 들었고, 실제 개발 기간은 짧은 만큼 미리 준비를 했다. 보일러 플레이트 코드들을 정비하고 필요한 성능이 BMT가 되진 않았지만 최소한의 서버(vue는 프리티어, spring boot는 t2.medium)로 개발 가능한 상태를 만들어 두었으며 AWS에서 도메인 구매 및 설정, CICD구축, 개발-운영 환경 분리, 템플릿 및 오토스케일링 그룹 설정 등을 미리해 두었다. 그리고 SRE도 챙겨야 하므로 Cloud Watch와 슬렉을 연동해 놓고 ELK 스택 보일러 플레이트와 대시보드 구상안을 미리 생각해 두었다. 필요한 때에 준비한 것들이 바로 바로 진행 되었고 당연히 결과는 정해진 기간에 적절한 릴리즈 성공으로 다가왔다.
세 번째는 누구나 알지만 잘 알지 못하는 것이다. 내가 가장 중요하게 생각하는 것인데 바로 멘탈 관리다. 프로젝트를 진행 하는 동안에 보이는 회사의 현실, 실패 했을 때 더 크게 쌓일 짐, 나에게 오는 기대와 실망, 그리고 실적. 눈에 보이는 모든 것이 현실이 되어 나에게 다가온다. 그래서 프로젝트가 실패 해 간다면 많은 사람들이 점점 눈을 가리게 되며 먼 곳을 보고, 이내 자리를 떠난다. 게다가 사실 가장 크게 다가오는 실점은 따로 있다. 다 함께 했기 때문에, 팀원들에게도 리스크가 갈 수 있다는 것이다. 그 역파는 다 같이 맞는다. 하지만 이미 우리는 알고 있었다. 프로젝트는 성공할 수도 있고, 당연히 실패할 수도 있다는 것을. 그렇기 때문에 더더욱 눈을 가려서는 안된다. 가장 중요한 말이다. "눈을 가려서는 안된다." 되도록 많이, 더 넓게 지켜봐서 실패하더라도 주워 담을 수 있게 만들어야 한다. 많이 볼수록 프로젝트가 어느 정도 왔는가를 알 수 있게 되고 되도록 많은 실패 지점과 필요 기간이 얼마였는지 기록할 수 있게 된다. 이러한 실패 지점들은 나에게 세이브 포인트로 다가와 프로젝트가 끝난 이후로 바구니에서 떨어진 알밤을 다시 주워 담을 수 있게 해주며 이로써 생긴 새로운 계획과 미래는 다시금 기회가 되어 나에게 다가온다.
나의 경우엔 배송과 주문 테이블을 참고하는 테이블의 쿼리가 8초 가량 걸려 매우 느린 것이 장애물이 되었고 해당 부분을 해결하기 위해 파티셔닝, 샤딩 등을 고민하기엔 시간이 너무 없는 상황이었다. 게다가 "배송"과 "주문" 테이블이다. 굉장히 유의해서 건들어야 하는 부분이기에, 무엇 하나 쉽게 결정할 수 있는게 없었다. 그 때 시니어 백엔드 개발자 분 께서 임시적으로 매일 새벽에 각 테이블에서 필요한 최소한의 limit을 정해두고 집계 테이블에 기록해서 사용하되 나중에 최적화하는 방안을 내주셨다. 이로 인해 쿼리의 속도는 8초에서 1.2초로 줄어드는 쾌거를 맞이 했고 우리는 해당 부분을 빠르게 넘어갈 수 있었다. 물론 완벽히 넘어간 것은 아니니 이것도 실패 지점에 기록해야 한다. 여기서 나의 주요 실패 지점은 너무 크게 생각한 것이다. 집계 테이블에 집계 값을 기록하고 사용하는 방법은 이미 널리 사용하는 방법인데, 나는 파티셔닝, 샤딩, 더 넘어서는 디비 이중화나 CQRS까지 생각하고 있었다. 쿼리가 오래 걸리는게 문제가 되자 마자 내 생각들을 모두 말씀드리고 여쭤봤다면 몇 시간, 길면 며칠의 시간(좀 더 긴 시간을 말하고 싶은데 실제론 6시간 정도 였다. 하지만 실제 효과는 며칠만큼 났을 것이다.)을 아낄 수 있었을 것이다. 이것의 나의 주요 실패 지점이다.
다음으로 나는 이러한 실패 포인트를 내 노션에 기록해 항목화 하는 방법으로 실천하였다. 새로운 문제가 생겼을 때 노션의 항목을 따라가면 이제 개발 방법론 적으로도, 접근적으로도 같은 문제는 반복되지 않을 것이다. 정리하면 실패 지점도 하나의 사건으로 생각하는 것이다. 그리고 그 사건을 분석하여 다음을 계획하고, 그 다음 계획도 해당 사건에 포함 시키면 된다. 즉, 실패가 실패가 아니게 되는 것이다.( 얼핏 보면 주식의 물타기와 비슷해 보이는데 인정한다. 그리고 이 것은 심적으로 매우 도움이 된다.) 멘탈 관리를 하기 위한 방법은 매우 많고 나와 같은 방법이 아니어도 된다. 무엇보다 중요한 것은 실천이니, 내 방법이 아니더라도 멘탈을 관리하기 위한 한 가지 방법 이상은 꼭 보유하고 실천하길 바란다.
2023.06.30 퇴사
좋은 기회가 와서 이직을 하게 되었다. 물론 시험은 다 봤다. 코딩테스트, 면접 다 다행히도 통과하였고 좋은 분들 께서 면접을 봐주셔서 그런지 부드러웠다. 24년이 되어 회고를 작성 중인 지금도 아직 재직 중이다.
신기할 만큼 겸손하고 협력적이었던 동료들, 내 자식 같이 만든 앱, 내가 앉아 있던 자리, 선물 받은 춘식이 인형과 굿즈들. 많은 것들을 놓고 가니 아쉬움이 따랐다. 물론 굿즈들은 집에 가져왔다. 편지들도. 퇴사 전까진 인수인계 문서를 작성하느라 너무 정신이 없었다. 프론트, 백엔드, AWS에다가 카프카, 도커 파일들. 내가 하나 빠트리면 그 하나가 회사에겐 시간적 손해로 다가갈 것이란 생각에 거기에 모든 정신을 몰두했다. 정신 없이 하면 당연히 잘하고 갈 수 없다. 마무리를 잘 했는가 생각해보면 아니다. 그렇게 까지 생각한다면 퇴사를 안하는게 맞지 않는가 물어볼 수 있지만 나는 부자가 아니니까... 마무리가 아름다운 사람이 정말 아름다운 사람이라는데, 나는 아직 아름답지 못한 것 같다. 그럼에도 불구하고 팀원들은 나의 미래를 응원해주었다. 나는 정말 인복이 있는 사람인걸까. 같이 술 한잔 하고 노래방도 갔다. 나를 많이 챙겨주셨던 본부장님과 시니어 백엔드 개발자 분이 매우 많이 생각난다. 모두의 정신적 지주 같은 분들이었다. 떠나면서도 어딜 가나 리더의 역량이 집단을 성공으로 이끈다는 것을 크게 느낀다.
내가 가장 즐겁게 다녔던 회사는 어디인가 물어보면 응당 이 회사를 이야기 할 수 있다. 문화적으로도, 인간적으로도 사람들의 성장을 눈으로 보며 체감할 수 있는 회사였다. 아마 앞으로 여러 회사를 다니면서도 나의 시작 지점에 들어 있는 이 회사를 다시 생각하게 되지 않을까 싶다.
'회고' 카테고리의 다른 글
AWS 서비스 구축에서 DevOps에 대한 회고 (0) | 2023.05.23 |
---|