백엔드 엔지니어로 직무를 전환한 후 반년이 넘었다. 이쯤 되면 스스로를 백엔드 엔지니어라고 소개하는 게 부끄럽지 않을 정도의 지식과 경험을 갖추고 있을 줄 알았으나, 여전히 백엔드 엔지니어라고 하기 민망한 수준이라는 생각이 들어 엔지니어라고만 소개하게 된다.

그러다 보니 내가 백엔드 엔지니어로 잘 성장하고 있는지, 잘 성장할 수 있는 유리한 환경에 놓여있는지 고민하게 되는 순간이 많아졌다. 이러한 고민은 정작 집중해야 하는 일과 학습에 시간을 쏟지 못하게 만들고 동기부여를 떨어뜨렸다. 이런 상태를 지속할 순 없기에 백엔드 엔지니어로 보낸 반년의 시간을 돌아보고 앞으로 어떻게 하면 좋을지 정리해보고자 회고를 하게 되었다.

반년 동안 어떤 시간을 보냈나?

첫 번째 팀: 온보딩 불시착, 내가 엔지니어인지 PO인지...

12월부터 3월까지 결제/포인트 도메인을 담당하는 스쿼드에서 백엔드 엔지니어로 일했다. 회사에서는 직무 전환을 지원해주는 차원에서 신규 입사자처럼 온보딩을 도와줄 짝꿍을 붙여주기도 했다. 짝꿍은 4개월 동안 내가 다양한 지식과 경험을 얻어갈 수 있게 물심양면 도와주었고, 대부분의 작업을 페어 프로그래밍으로 같이해주었다.

하지만 결론부터 말하자면 회사의 지원이 무색하게도 온보딩에서 불시착했다. 이 스쿼드는 주로 Kotlin, Java, Spring을 사용했는데 온보딩 시작 후 4개월이 지난 시점까지 내가 이 기술들을 가지고 우리 시스템에 기여할 수 있겠다는 자신감이 생기지 않았다.

불시착한 이유

불시착한 이유에는 여러 가지가 있겠지만 가장 주된 원인은 스쿼드가 제대로 운영되지 않았기 때문이라고 생각한다. 디스커버리 단계에서 우리가 해야 할 일이 탐색 되고 정의되는 과정이 매우 느리고 미흡했다. 그래서 엔지니어가 딜리버리할 작업 자체가 없거나, 작업 시작 전에 내려져야 할 의사결정을 기다려야 하는 상황이 잦았다. 때로는 엔지니어가 PO 업무의 일부를 도맡느라 엔지니어링 작업에 집중할 수 없었다.

난생처음으로 엔지니어가 할 일이 없어서 노는 상황을 보게 되었다. 보통은 백로그가 쌓여있어서 뭘 먼저 할지 고르는 게 일인데 이때는 백로그가 생기기를 기다리는 상황이었다. 백로그가 생겨도 요구사항이 제대로 파악되지 않아서 한 달 동안 시스템 설계만 3-4번 갈아엎는 일도 있었다. 이 시기를 보내며 새삼스럽게 디스버커리가 잘 되어야만 개발도 잘할 수 있다는 사실을 다시 한번 뼈저리게 느꼈다.

개발을 잘할 수 있는 상황으로 만들고자 OKR 정의와 시즌 플래닝, 이터레이션 플래닝을 서포트했다. 하지만 이것만으로는 상황이 나아지지 않았다. 시즌 말쯤에는 매주 PO, 프로덕트 디자이너분과 함께 결제/포인트 도메인의 방향성과 로드맵을 정의하고 문서화하는 일을 드라이브했다. 우리가 무엇을 해야 하는지 정의하고 스쿼드 내외부에 전파했다. 이때 CTO보다 CPO랑 얘기를 더 자주 나눴을 정도로 엔지니어보다는 PO 서포트에 신경 썼던 거 같다. (물론 수많은 PO 업무 중 매우 일부이긴 하지만..)

하지만 서포트하는 것만으로는 근본적인 원인이 해결되지 않았다. 해야 할 일이 없다고 하니 (반은 장난이었겠지만) HPP 문서(Healingpaper Product Proposal, PO가 디스커버리 단계에서 쓰는 문서)를 써야 하는 일이 있지 않냐는 얘기를 듣기도 했다. 이때 처음으로 스타트업에서 일하면서 '그건 제 일이 아니에요'라는 말을 했었다.

시즌 말에 가서도 상황이 해결되지 않았기에 공동 PO를 제안받게 되었다. 직전 시즌에 PO를 했었으니 PO를 서포트해줄 수 있는 사람이라는 기대와 함께 이 스쿼드에 오긴 했지만, 이 스쿼드로 이동한 최우선 목적은 나도 회사도 백엔드 엔지니어 온보딩이었다. 또 공동 PO로 일하더라도 근본 문제가 해결되는 게 아니라 임시방편으로 주먹을 가지고 둑을 틀어막는 것처럼 느껴졌기에 거절했다.

이 시기 동안 CPO, CTO, 그리고 다른 스쿼드 구성원들과 대화를 나누고 여러 솔루션을 시도해봤지만 빠르게 해결되진 않았다. 어찌저찌 한 시즌이 지난 4개월 후에야 PO분이 퇴사하시고 새로운 PO분이 오시게 되면서 상황이 일단락되었다.

2일에 1커밋 밖에 못했던 시즌

스쿼드 일이 없다면 챕터 일을 해서라도 기술적인 경험을 하고 싶었으나 가는 날이 장날이라고 때마침 이 시기부터 백엔드 챕터에서도 진행하는 프로젝트가 없어서 더더욱 꼼짝할 수 없었다. 이제 막 직무를 전환한 시점이었기에 열심히 하고 잘 해내고 싶은 의욕과 욕심이 가득했으나 스쿼드에서도 챕터에서도 엔지니어로서 할 수 있는 일이 없는 상황이 너무 답답했다.

결과적으로 개발할 기회 자체가 적어서 새로운 기술들을 충분하게 수련하며 우리 시스템에 대한 이해도를 필요한 만큼 높이지 못했다. 단적으로 4개월 동안 올린 PR 개수가 60개 남짓이었다. 우리는 1PR을 1커밋 정도의 사이즈, 변경이 200줄 이하로 작성하는 것을 권장하는 편이기에 실질적으로 2일에 1커밋 정도의 일을 했다고 보면 된다. PR 개수가 중요한 것은 아니지만 절대적으로 작업량이 적은 것을 보여주는 지표라고 생각한다.

물론 상황이 어떠하든 새 기술들을 집요하게 공부하고 수련했다면 온보딩에 불시착하지 않았을 수도 있다. 그렇지만 변명해보자면 성향상 필요해서 하는 공부가 아니면 재미를 붙이지 못하는 편이기에 일없이 공부만 하는 상황을 지속하기 어려웠다. 또 팀이 잘 운영되지 못하는 상황에 스트레스받으며 해결책을 찾기 위해 고민하고 개발 외적으로 여러 시도를 해보며 에너지를 뺏겼다.

게다가 어쩌면 내가 엔지니어로서의 역량이 부족하기 때문에 이 답답한 상황을 타개하지 못하는 건 아닌가 하는 자기 의심도 들기 시작하면서 심적으로 지쳐버렸다. 그러다 보니 따로 공부하는 것에 충분한 에너지를 쏟지 못했다.

두 번째 팀: 제품 스쿼드가 아닌 유일한 플랫폼 스쿼드

4월부터는 CTO가 리드로 있는 플랫폼 스쿼드에서 일하게 됐다. CTO를 포함하여 경험 많은 엔지니어가 있는 팀이기에 기술적인 성장을 많이 할 수 있을 거라는 기대가 컸다. 또 이전 팀의 짝꿍분이 그러했듯 이번 팀에서도 한 분이 짝꿍 역할을 해주시며 나에게 여러 가지 지식과 경험을 전파하려고 노력해주셨다. 페어 프로그래밍 경험을 향상하고자 같이할 작업을 혼자서 미리 설계해보고 코딩해보면서 준비해주시는 정도였다.

이번에도 결론부터 얘기해보자면 기술적으로 배울 게 많은 사람들이 있는 것은 맞았지만 상황상 개발할 기회가 많지 않았다. 결과적으로 아예 성장하지 못한 것은 아니었으나 아쉬웠다. 3달 동안 PR 60개 정도를 올렸다.

그래도 지난 팀과 달리 새로운 기술들을 활용하여 우리 팀에서 메인으로 구현하고 있는 포인트 시스템에 대해서는 피쳐 개발이나 운영 CS에 대응할 수 있을 정도가 되었다. 하지만 지난 팀보다 나아졌을 뿐 여전히 충분하지 않다고 느꼈다.

아쉬웠던 이유

이번 팀에서도 작업이 잘 정의되지 않거나 작업이 없어서 놀게 되는 상황이 자주 생겼다. 우리 팀의 리드와 협업하는 팀의 리드 모두 여러 역할을 겸직(두 분 다 C레벨 역할 겸직ㅠㅠ)하느라 바쁘다 보니 요구사항 정의나 일정 조율 같은 것이 삐걱거리거나 느렸다. 회고에서 한 달이면 끝날 일을 두 달 동안 한 것 같다는 얘기를 하기도 했다.

그러다 보니 놓쳐지는 부분을 나와 다른 팀원분이 챙기게 되었다. 물론 팀원이 팀의 일을 챙기는 건 당연하지만, 놓쳐지는 일을 아무리 챙겨도 팀이 잘 굴러가지는 않다 보니까 이게 맞는건가하는 의문이 들었다. 팀에 작업이 없어서 기술적 경험을 하지 못하고 다른 일에 시간은 뺏기는데 팀이 성과를 내는 것은 아닌 상황이 이전 팀과 오버랩되면서 현타가 많이 왔다.

이때 팀원으로서는 리더가 겸직하는 상황에 대한 회의감이 들었다. 회사 상황상 어쩔 수는 없다는 걸 알아도 구성원으로서는 힘들었다. 최대한 팔로워십을 발휘하여 팀이 움직일 수 있도록 노력해봤지만 팀원으로서 챙길 수 있는 일에는 한계가 있었다.

기술적인 성장에 대한 기대가 가장 컸던 팀에서 또다시 기술적 성장을 충분하게 하지 못했다 보니 내가 이 회사에 남아있는 게 현명한 선택인지에 대한 고민을 많이 하게 됐다. 나는 엔지니어로 성장하고 싶어서 이 회사에 왔는데 이 회사에서는 엔지니어가 엔지니어로 일하는 게 이렇게 힘든 일인가 싶었다.

바꾸든지 떠나든지

상황을 바꾸든지 아니면 떠나든지 라는 마음으로 상황을 바꾸고자 하는 여러 시도와 떠나게 되는 퇴사 고민을 반복했다. 그래도 이왕이면 퇴사보다는 지금 속해있는 강남언니에서 잘 해내고 싶었다. 또 좋은 경험을 가진 사람이 있는 팀에서 마냥 성장하기 어려운 환경이라고만 생각하는 건 내가 개선할 점이 있지 않을까 하는 생각도 들었다.

지금 상황에서 내가 해볼 수 있는 일은 더 없는지 고민해보기 시작했다. 지난달부터는 다른 팀원분과 함께 팀 리드와 이야기 나누면서 다음 시즌에는 더 나은 상황을 만들고자 노력해보고 있다.

하지만 상황이 바로 나아지는 것은 아니기에 지속해서 회사에 대해 불평불만 하게 되는 나를 발견하였는데 그 모습이 마음에 들지 않았다. 누군가는 내 상황을 보고 배부른 고민이고 좋은 환경을 잘 이용하지 못한다고 생각할 수도 있을 것 같았다. 그래서 내가 정말 이렇게 많은 불평불만만 내뱉을 상황인지를 정리하고자 이 회고를 시작했다.

다시 돌이켜보니

스트레스를 받았던 이유

누군가는 일없이 노는 상황을 반길 수도 있는데 나는 왜 퇴사를 고민할 정도로 스트레스를 받았는가 하면 크게 두 가지 이유가 있었다.

첫 번째는 직무 전환을 할 때 다시 신입부터 시작한다는 마음으로 임하긴 했지만, 실제로 신입인 건 아니기에 빠르게 역량을 높여야 한다는 조급함이 있었다. 조급하다 보니 시야가 좁아져서 배우고 있는 것은 보지 못하고 지금 당장에 내가 덜 기여하고 있다는 사실만 크게 바라보았던 것 같다.

두 번째는 회사에서 참여하는 모든 일에서 만족스러운 속도와 결과물이 나올 수 없는데 이를 두고 보기 힘들어했다. 이 부분에 대한 민감도가 높아서 상황 대비 과하게 스트레스를 받기도 한 것 같다. 마침 이 글을 쓰던 중에 CTO와의 1on1에서 상황이 어떠하든 가장 최우선 목표는 엔지니어로서의 성장이니 어느 정도는 이기적인 마음으로 주변에 신경을 끄고 할 일에 더 많은 신경을 써보라는 피드백을 받기도 했다.

그래서 내 시야를 다시 줌아웃하여 지금 내가 배우고 있는 것은 무엇인지, 앞으로 어떻게 하면 좋을지 점검해봤다.

배운 점

동료들의 도움으로 배웠던 것

첫 번째 팀에서 보낸 시간을 다시 돌이켜보면 기술적으로 배운 게 없지는 않았다. 짝꿍분이 온보딩을 많이 신경써주셨기 때문이다. 백엔드 챕터가 일하는 방식을 익혔고, 서버 개발할 때는 어떤 식으로 TDD를 하는지도 배웠다. 또 요구사항이 주어졌을 때 어떤 과정을 거치면서 시스템을 설계하는지에 대한 감도 익혔다. 특히 가장 많이 배운 점은 나와 성향이 매우 다른 개발자와 밀접하게 붙어 일해보면서 내가 가지지 못한 시야나 사고방식을 조금은 배워볼 수 있었다.

두 번째 팀에서도 역시나 짝꿍의 도움으로 새로운 기술과 패턴 등을 비교적 수월하게 익혔다. 이 팀은 유일하게 C#과 .NET을 사용하고, 인프라도 주로 Azure를 쓴다. 또 말로만 들어왔던 DDD, CQRS, 이벤트 소싱 등이 활용되고 있다. 이 방대한 것들을 짝꿍과 함께 페어 프로그래밍을 하고 설명도 들어가면서 빠르게 익힐 수 있었다.

DDD라던가 CQRS, 이벤트 소싱 같은 개념들은 따로 시간을 내어 공부하지 않으면 이해조차 할 수 없기에 혼자서 공부하는 시간도 필요하긴 했지만, 그 과정에서 책을 보며 이론적으로만 이해하는 게 아니라 실제로 구현된 프로젝트를 보며 공부할 수 있어서 더 효율적으로 학습할 수 있었다. 돌이켜보면서 잘되어있는 코드를 볼 수 있고, 이에 대해 편하게 질문할 수 있다는 것만으로도 큰 도움이라는 걸 깨달았다.

또 내가 배우는 게 없다고 징징거리니 자신의 작업을 초반 설계부터 공유하여 모든 코드를 처음부터 끝까지 리뷰 요청하여 우리 시스템의 코드를 더 많이 볼 수 있게 해준 백엔드 챕터 동료도 있었다. 덕분에 Java/Spring의 주된 기능은 금방 익힐 수 있었다.

동료들의 도움으로 배운 것들을 인지하니 그간 배우는 게 없다고 징징거리던 내 모습이 미안스러웠다. 여러 동료가 시간과 마음을 써가며 많은 배움을 주고 있었는데 내가 이 배움들을 너무 과소평가하고 있었다. 이런 좋은 동료들의 도움과 도움받을 수 있는 환경을 당연하게 여기지 않도록 주의하자고 다짐했다.

좋은 설계의 중요성과 설계하는 방법

여태까지 좋은 설계로 인한 이점을 누려본 적이 없었기에 나쁜 설계로 인한 힘겨움을 인지하지 못했었다. 막연하게 속도를 높이기 위해 설계를 생략하며 개발해왔다고 생각했다. 설계에 시간을 쏟는 건 어떤 시스템을 처음 만들기 시작할 때 아키텍처를 정하기 위해서나 필요한 일인 줄 알았다.

그러나 두 번째 팀에 와서 설계가 잘 된 시스템을 경험하며 설계에 대한 공부를 하고나니 그동안 설계를 생략한 것이 아니라 나쁜 설계를 해왔다는 걸 알게 됐다. 또 그간 나쁜 설계로 인해 확장성과 안정성, 유지보수성이 낮은 결과물을 내거나, 그로 인해 고통받고 있다는 걸 알아차리게 되었다. 좋은 걸 보고 나니 개선점이 보였다.

"설계가 필수적인인지, 안 해도 괜찮은지에 대한 질문은 요점에서 많이 벗어나 있다. 설계는 필연적이다. 좋은 설계의 반대는 나쁜 설계다. 절대 설계하지 않는 것이 아니다." 책 <Design: A Practical Introduction> by 더글라스 마틴

특히 설계를 잘한 후에는 예측할 수 없는 사이드 이펙트가 확연하게 적었으며, 개발하던 중에 몰랐던 걸 알게 되거나 구현에 필요한 걸 뒤늦게 발견해서 작업이 뒤엎어지거나 일정이 크게 틀어지는 경우가 줄었다. 또 초반에 설계를 잘해두면 새로운 요구사항에 대응하는 비용이 현저히 낮아지는 것도 체험할 수 있었다.

물론 신중함과 신속함 사이의 균형점을 잘 찾아야겠지만 여태까지 나는 단기적 속도에만 치우쳐있던 사람이기에 의식적으로 설계에 시간을 투자하는 노력이 필요했다. 최소한 시스템의 경계를 잘 구분 짓는 것이라도 놓치지 않아야겠다고 생각했다. 돌이켜보니 지금은 크든 작든 모든 작업에서 당연하게 설계 과정을 거치고 있음을 인지할 수 있었다.

또 설계하는 과정에 참여하면서 설계하는 방법도 배울 수 있었다. 단순히 해야 하는 백로그를 적는 게 다가 아니라 시스템의 구조를 그려가면서 각 요소가 어떤 책임과 관계를 가지고 있어야 하는지 등을 잘 파악하고 정의해야 한다는 걸 배웠다.

지식의 중요성

위에서 나는 필요한 것만 딱 배우는 편이라고 말했었는데 이는 온전히 내 착각이었다. 지식이 적기 때문에 내가 필요한 걸 배웠다고 알 수 없기 때문이다. 뭐가 있는지를 알아야 나에게 적절한 도구나 기법을 선택할 수 있다. 다양한 경험을 가지신 분들과 일해보면서 이 사실을 체감할 수 있었다.

지식이 많을 때 일을 얼마나 효율적으로 해낼 수 있는지 보면서 평소에 지식 쌓는 일에 소홀했던 내 태도를 바꿔야겠다고 반성했다. 특히 패턴이나 인프라 지식의 중요성을 많이 체감했다. 지식이 많으면 작업량을 줄여주거나 훨씬 더 나은 결과물을 낼 수 있다는 걸 보았다.

엔터프라이즈 규모의 시스템 경험

사실 이전에도 백엔드 개발을 안 해본 것은 아니었다. 비록 Node.js이긴 했지만 트레바리 때 혼자서 서버를 구현하고 운영했다. 그렇지만 스스로를 신입 백엔드 엔지니어라고 칭했던 이유는 흔히 말하는 크고 복잡한 엔터프라이즈 규모의 시스템 경험이 아니라고 생각했기 때문이다. (사실 이제 생각해보면 거대한 트래픽은 아니었으나 복잡도에 있어서든 충분히 복잡했던 거 같다. 그런데 내 역량이 부족해서 복잡도 대비 단순하게 느꼈던 거 같기도 하다...)

트래픽 대응을 위한 분산이나 여러 팀이 협업하면서 발생하는 이슈 같은 건 작은 시스템에서 절대 겪을 수 없는 경험이었다. 작은 시스템에서는 좋은 설계, 효과적인 패턴, 클라우드의 가용성 같은 것들에 대한 필요성을 체감하기 어렵기 때문이다. 이를 돌이켜보면서 규모있는 시스템을 개발하는 것 자체로도 배움이 많은 경험임을 상기할 수 있었다.

엔지니어로서 가진 나쁜 습관

safe zone에서 벗어나서 온전히 엔지니어의 역할로만 일해보니 엔지니어로서 가진 나쁜 습관을 훨씬 더 선명하게 느낄 수 있었다. 나는 구현에 급급한 편이라 어떠한 기술이나 패턴 등을 활용할 때 정확하고 깊게 공부하여 이해하고 쓰기 보다는 귀납적으로 되는지 안 되는지를 직접 해보고 추측하여 익히고 동작하게끔만 결과물을 내버리는 경우가 많았다.

이제는 귀납적으로 익히고 제대로 이해하지 않고 학습을 끝내버리는 습관을 버릴 때가 왔다. 모르는 건 쓰지 않겠다는 원칙을 세워서 좋은 습관으로 덮어쓰려고 시도해보고 있다.

뛸 때도 있고 걸을 때도 있다

회사에서는 바쁜 시기가 있는 것처럼 덜 바쁜 시기도 있다. 덜 바쁜 시기가 올 때마다 매번 이렇게 스트레스를 받는다면 오래 일하기는 힘들 거라는 생각이 들었다. 또 바삐 움직이며 끊임없이 결과를 만드는 게 능사가 아니라는 것도 깨달았다. 어쩔 때는 기를 모아서 크게 한 방을 쏘는 것도 필요하다.

그러기 위해서는 걷는 시기를 잘 활용하는 법을 아는 것도 필요했다. 덜 바쁜 시기가 오면 체력도 비축할 겸 바빠서 하지 못했던 공부나 고민을 할 수 있는 기회로 삼고자 한다.

맺으며

사실 회고를 시작할 때만 해도 내가 반년 동안 배우고 성장한 부분이 많지 않다고 생각했다. 그런데 마음을 다잡고 다시 돌이켜보니 배운 점이 많았고, 아직은 내가 해볼 일과 노력이 남았다는 걸 알게 되었다. 더 잘해야 한다는 욕심과 더 빠르고 크게 성장하고 싶다는 조급함 때문에 부족한 면만 보고 있었다. 당분간은 환경에 대한 고민을 멈추고 집중하고자 하는 일에 시간과 집중을 쏟을 수 있을 것 같다.

이제는 환경 탓을 멈추고 나중에 돌이켜봤을 때 아쉬움이 없도록 더 치열하게 목표했던 엔지니어로서의 성장에 집중하고자 한다. 환경을 바꾸는 건 내가 할 수 있는 걸 다한 후에 고민해봐도 늦지 않을 것 같다. 일단은 나 자신부터 바꿔보고 싶다.