주니어 개발자가 2년 동안 업무를 통해 배운 것들

 

 

이번 3월을 끝으로 회사를 나오게 되었습니다.

 

저는 2년 전 개발자로 커리어 전환을 하고, 핀테크 스타트업인 *알파프라임에서 백엔드 개발자로 일했습니다. 이 글은 제가 회사에서 2년 동안 어떤 업무를 해왔는지, 그 업무를 통해 어떤 배움을 얻었는지에 대해 회고하는 글입니다.

 

*알파프라임은 [알파스퀘어]라는 스마트 트레이딩 플랫폼 서비스를 운영하고 있습니다. 

 

 

---

 

 

온보딩 프로젝트

처음 입사를 하고 약 한 달 동안 온보딩 프로젝트를 진행했습니다. 저희 회사는 신규 입사자와 사수가 함께 프로젝트를 만들어가는 방식으로 온보딩을 진행합니다. 

 

저는 온보딩 프로젝트로 주식 관심종목에 대한 CRUD를 구현했고, 그 과정에서 FastAPI, Sqlalchemy, PostgreSQL 같은 기본적인 기술들과 회원가입 & 로그인, 도커 환경 구축 등을 직접 구현해 볼 수 있었습니다.

 

특히 온보딩 프로젝트에서 제가 배울 수 있었던 것은 개발팀의 협업 프로세스였습니다. 예를 들어 commit 메시지 규칙이라든가, 코드 리뷰 방법이라든가, 깃 전략 등을 새롭게 배웠습니다.

온보딩 당시 PR 목록, 코멘트가 181개나 달린 PR이 있는데, 이는 역대 신규 입사자 중 최다라고 한다.🤣

 

온보딩에는 하루에 한 번 페어코딩이 포함되어 있었습니다. 저는 페어코딩 과정에서 개발자의 가장 중요한 덕목 하나를 알게 되었습니다. 그것은 바로 '모르는 것을 부끄러워하지 말자.'입니다.

 

하루는 페어코딩 중 사수님에게 질문을 했습니다. 제 딴에는 사소한 질문이라 쉽게 답변을 하실 줄 알았는데 사수님이 아무렇지 않은 듯 '모른다'라고 하시더군요. 당시에 저는 시니어 개발자라면 뭐든지 다 알고 있을 거라는 환상을 가지고 있었기에 '모른다'는 답변에 당황했습니다. 그런데 인상적인 것은 그다음 사수님의 말과 행동이었습니다. 사수님은 '나도 잘 모르니 함께 찾아보자.'라고 말을 하고는 함께 문서를 찾고 제게 설명해 주었습니다.

 

이때 저는 '시니어라도 모르는 게 있다. 그런데 모르는 것은 부끄러운 것이 아니고 함께 공부하고 나눌 수 있는 기회이다.'라는 것을 배웠습니다. 만약 저에게도 후배가 있다면, 모른다는 사실을 당당히 말할 수 있는 선배가 되고 싶다는 생각을 했습니다.

 

 

 

모의투자 저장소 패턴 도입

온보딩 프로젝트가 끝난 후, 모의투자 서버의 저장소 패턴 도입 프로젝트를 진행했습니다. 기존 모의투자 서버는 repository(저장소) 레이어 없이 service 레이어에서 DB 로직을 사용하고 있었는데 이를 분리하는 작업이었습니다.

 

모의투자 서버는 생각보다 코드가 많았기에 시간이 걸렸습니다. 특히 service 레이어의 모든 함수를 파악하고 DB 로직을 분리하는 과정에서 어떻게 효율적으로 일을 끝낼 수 있을지 고민했습니다. 저는 제가 잘하는 스프레드 시트를 활용하여 수십 개의 함수와 DB 로직들을 정리했고 덕분에 누락되는 함수 없이 수월하게 저장소 패턴을 적용할 수 있었습니다.

 

당시에 저는 레이어 아키텍처에 대한 개념이 없었는데 해당 프로젝트를 통해 실제 현업에 적용하며 감을 익힐 수 있었습니다. 또한 의존성 주입(DI)에 대해서도 배울 수 있었고, 특히 테스트 코드에 대한 중요성을 몸소 느낄 수 있었습니다. 운이 좋게도 당시 사내에서는 테스트 코드에 관심이 많았고, 저는 사내 테스트 코드 가이드를 직접 정리, 작성하여 개발팀에 기여할 수 있었습니다.

 

저장소 패턴 도입 프로젝트는 '레이어 아키텍처'와 '의존성 주입', '테스트 코드'라는 굵직굵직한 개발의 기본기를 배우게 해 준 소중한 프로젝트였습니다.

 

프로젝트에 대한 자세한 내용을 당시에 글로 남겼으니 관심이 있다면 읽어보시기 바랍니다.

저장소 패턴(Repository Pattern) 도입기

 

 

 

지수/환율/원자재 시장지표 추가

당시 저희 서비스는 해외 지수나 환율, 원자재 등의 시장지표를 제공하지 않았기 때문에 이를 추가하는 프로젝트를 제가 맡게 되었습니다. 이 프로젝트는 외부 벤더사로부터 시세 데이터를 받아오고, 이렇게 받아온 시세 데이터를 기존 모듈 구조에 맞게 추가하는 작업이었습니다.

 

이 프로젝트는 지금 생각해도 어렵게 느껴지는데, 그 이유는 모듈의 구조가 복잡하게 얽혀있어 모든 구조를 한눈에 파악하기 어려웠기 때문입니다. 이런 내부적인 문제뿐만 아니라 벤더사가 제공하는 데이터에도 여러 문제가 있었습니다. 데이터에 문제가 있는지 없는지 다른 시세 제공 서비스와 비교하며 직접 눈으로 체크해야만 했습니다.

 

시장지표 프로젝트에서 제가 배운 것은 두 가지입니다.

 

첫 번째는 저만의 '이슈 관리 방법'입니다. 먼저 이슈가 발생하면 이슈의 '크기'를 최우선으로 파악합니다. 이슈의 크기에 따라 내가 바로 해결할 수 있는 이슈라면 '선조치 후보고'로 진행했습니다. 바로 해결할 수 없는 이슈라면 조치할 내용을 팀원들에게 먼저 공유하는 '선보고 후조치'로 진행했습니다.

 

두 번째는 '다음 사람을 위한 문서 남기기'입니다. 앞서 말씀드렸듯이 시장지표 추가는 매우 복잡한 프로젝트였습니다. 이 말인즉슨, 다른 사람들이 제 코드를 보았을 때 쉽게 이해가 되지 않을 것이고, 그것은 미래의 제 자신에게도 마찬가지라는 뜻입니다. 그래서 저는 아주 상세한 개발 가이드 문서를 작성해 두었습니다. 어디에 어떤 코드를 추가해야 하는지, 어떻게 테스트하고 무엇을 체크해야 하는지 등을 스크린샷과 함께 상세히 적었습니다.

 

실제로, 이후에 시장지표를 추가하는 일이 종종 있었습니다. 그때마다 제가 작성한 가이드를 참고하며 며칠이 걸릴 수도 있는 일을 단 몇 시간 만에 끝낼 수 있었습니다. 복잡한 업무일수록 문서화를 해두는 것이 생산성을 비약적으로 높여준다는 사실을 배웠습니다.

 

프로젝트에 대한 자세한 내용을 당시에 글로 남겼으니 관심이 있다면 읽어보시기 바랍니다.

시장지표(지수/환율/원자재) 프로젝트 회고

 

 

 

제 3회 모의투자 대회

23년 1분기에 저희 서비스는 제 3회 모의투자 대회를 개최했습니다. 모의투자 서비스는 이미 구현이 되어있었지만, 투자 대회에 대한 로직은 추가로 보완할 부분이 있어 제가 그 부분을 맡아 진행하게 되었습니다.

 

프로젝트 작업 중에는 카카오톡 알림톡을 활용해 투자대회 알림을 발송했는데요. 유저들에게 직접적으로 메시지를 전송하는 일은 처음이라 메시지를 보낼 때 굉장히 긴장했었던 기억이 납니다.

 

사실 모의투자 대회 프로젝트 전까지는 도메인 지식이 부족하고 서비스에 대한 이해도가 낮았는데, 이 프로젝트를 통해 다른 직군들과도 협업해보고 서비스에 대한 이해도도 높일 수 있었습니다. 

 

 

 

인앱 결제 구현

처음 인앱결제를 구현하는 업무를 맡았을 때는 앞이 막막했습니다. 인앱 결제를 a부터 z까지 정리한 문서는 거의 찾을 수 없었고(외국 블로그에 있긴 했습니다만...) 안드로이드와 ios의 구현 방식도 일부 상이하기에 두 플랫폼의 문서를 열심히 뒤져가며 구현을 했습니다.

 

가장 겁이 났던 부분은 제 코드가 각 플랫폼의 API를 잘 호출하고 기대한 대로 동작하는지 여부였습니다. 서버에서 단독으로 인수테스트하기가 어려워 제가 지금 작성하는 코드가 맞는 코드인지 하루에도 몇 번이나 의심했습니다. 다행히도 클라이언트를 담당하신 선우님의 도움으로 인수 테스트를 진행할 수 있었고 플랫폼의 실제 응답값을 확인해 가며 개발을 진행할 수 있었습니다.

 

당시 선우님의 한 마디가 제게 큰 도움이 되었습니다. "계속 고민해도 해결되지 않는 문제라면 일단 해보고 뚜까 맞으면서 배우죠!" 이 말은 이후에 뚜디디(Ttukka-Driven Development)로 불렸고, 단 한 가지 조건만 추가하여 제 개발과 삶의 행동지침으로 삼았습니다. (한 가지 조건은 '뚜까 맞더라도 죽지 않을 정도로만 맞자'입니다.)

 

시장지표 프로젝트에서 배웠듯이 인앱 결제도 구현 가이드 문서를 남겼습니다. 다른 개발자들이 저처럼 헤매지 않기를 바라며, 제가 직접 경험하고 배운 내용을 플랫폼별로 정리했습니다.

 

당시에 작성한 글은 다음과 같습니다.

인앱결제 서버 구현 _ 앱스토어 편

인앱결제 서버 구현 _ 플레이스토어 편

 

 

 

매출/성과 대시보드 구현

결제가 추가됨에 따라 회사의 매출과 성과를 측정하기 위한 대시보드가 필요했습니다. 마침 데이터에 관심이 있던 제가 대시보드 구현 프로젝트를 맡게 되었습니다.

 

저는 백엔드 개발자이다 보니 처음에는 대시보드를 어떻게 만들어야 할지 몰랐습니다. 때마침 제가 속한 글또 커뮤니티(개발자 글쓰기 커뮤니티)에서 대시보드를 구축한 데이터 분석가를 알게 되었고 그분과의 커피챗을 통해 지식과 노하우를 얻을 수 있었습니다. 

 

대시보드를 만들어주는 서비스, 혹은 직접 구축할 수 있는 오픈소스 등이 고려대상이었으나, 현재 조직의 상황에 가장 적절한 대시보드 툴은 '스프레드 시트'라고 결론 내렸습니다. 그 이유는 스프레드 시트는 제게 익숙하기 때문에 러닝커브가 없었고, 코드 베이스가 아닌 실시간 수식을 사용하기 때문에 수정이 즉각 반영되어 생산성 측면에서도 압도적이었습니다. 스프레드 시트 대시보드는 결과적으로 저뿐만 아니라 다른 팀원분들로부터도 긍정적인 평가를 받았습니다. 

 

제가 대시보드 구현 프로젝트에서 배운 것은 두 가지입니다.

 

첫 번째는 '먼저 경험한 선배의 의견을 듣자'입니다. 제가 데이터 분석가와 커피챗을 하지 않았다면 제 작업에 대해 확신을 가지지 못했을 것이고, 결과를 만들어내는데 더 오랜 시간이 걸렸을 것입니다. 저는 커피챗을 통해 업무에 대한 시야를 넓혔을 뿐만 아니라, 데이터 직군의 생각과 일하는 방식을 배울 수 있었습니다.

 

두 번째는 '대중적인 기술이 곧 적정한 기술을 의미하지는 않는다'입니다. 보통은 현재 가장 많이 사용하는 기술을 따르려고 합니다. 아무래도 대중적인 기술일수록 인터넷에 더 많은 정보가 있고, 많은 사람들이 쓰는 기술이 곧 최선의 선택인 것처럼 여겨지기 때문입니다. 하지만 '적정한 기술'이란 결국 현재 상황에서 해당 문제를 풀 수 있는 가장 적합한 솔루션을 뜻하겠지요. 그런 면에서 스프레드 시트는 그 어떤 툴보다 저희에게 적정한 기술이었습니다.

 

아래 이미지는 스프레드 시트로 만든 대시보드의 예시입니다. 

스프레드 시트로도 충분히 훌륭한 대시보드를 구현할 수 있다.

 

 

 

 

쿠폰 시스템 구현

더 많은 사람들이 저렴한 가격으로 서비스를 사용할 수 있도록 쿠폰 시스템 백엔드 부분을 맡아 구현하였습니다. 쿠폰에 대한 전반적인 기획이 저에게 전달되었고 거기에 맞춰 직접 서버를 설계하여 진행하였습니다.

 

구현 과정에서 예상되는 문제상황과 세부적인 디테일은 기획자와 자주 소통하며 보완했습니다. 쿠폰 사용에 대한 경우의 수가 정말 많아서 머리가 아팠습니다만,,, 제가 직접 설계하고 구현해나가는 과정을 통해 개발자로서 성장하고 있다는 느낌을 받았습니다.

 

쿠폰 시스템을 구현하며 배운 것은 '실제 코드로 구현하기 전에 설계 문서를 먼저 리뷰받자'입니다. 특히, 코드 리뷰어들에게는 구현 전에 먼저 문서 형태로 리뷰를 받아야 한다는 걸 알게 되었습니다. 만약 일부 리뷰어가 설계문서를 보지 못한 상태에서 코드를 리뷰할 경우, 비즈니스 로직을 이해하기 어려워 리뷰가 지연되거나 심하게는 코드 전체를 뒤엎는 경우가 생길 수도 있습니다. 그렇기 때문에 코드를 작성하기 전, 문서를 먼저 리뷰 받는 것이 가장 빠르고 효율적인 방법이라는 걸 배웠습니다.

 

 

 

서버 통합 마이그레이션

기존에는 일부 도메인의 서버가 분리되어 있어 개발 운영에 불편함이 있었습니다. 저희 개발팀은 모노레포로 돌아갈 것을 결정했고, 일부 마이그레이션 프로젝트를 제가 맡아 진행하였습니다.

 

마이그레이션 프로젝트에는 Django 프레임워크를 FastAPI로 옮기는 작업이 포함되어 있었습니다. Django의 ORM 은 정말이지 너무 쉽고 편하지만.. 그만큼 추상화가 잘 되어있어 이를 Sqlalchemy로 옮기는 과정이 쉽진 않았습니다. 저는 이 작업을 통해 Sqlalchemy에 대한 이해도를 높이고, 기존 서비스의 로직을 전반적으로 파악해 볼 수 있는 기회로 삼아 나름 즐겁게? 작업했습니다.

 

마이그레이션 프로젝트에서 가장 크게 배운 것은 테스트 코드의 중요성이었습니다. 만약에 테스트 코드가 없었다면, 그리고 테스트 코드가 다수의 비즈니스 로직을 커버하지 못했다면 마이그레이션은 굉장히 어려운 작업이 되었을 것입니다. 테스트 코드는 작업자의 심신 안정과 작업 생산성에 매우 매우 큰 이점을 가져다주었습니다.

 

 

 

내통장결제 PG 연동

유저들이 더 쉽고 편하게 결제를 할 수 있도록, 내통장결제 PG 연동 프로젝트를 진행했습니다. PG 연동에 대해 업체가 제공하는 개발문서가 따로 있었는데 처음에는 어렵게 느껴졌으나 찬찬히 읽어보고 플로우를 직접 도식화하면서 쉽게 이해할 수 있었습니다. 이전에 인앱결제를 구현해 본 경험이 있었기에 결제 PG 연동이 어렵게 느껴지진 않았습니다.

 

직접 구현하면서 헷갈리거나 이해가 되지 않는 부분은 업체 담당자와 이메일로 소통하며 체크했습니다. 한 번은 코드 리뷰어가 제가 구현한 코드가 이해되지 않는다며  담당자에게 확인할 것을 요청한 적이 있었습니다. 실제로 담당자에게 확인을 해보니 제가 문서를 잘못 이해한 상태로 구현한 것이었습니다. 만약 리뷰어가 지적하지 않았다면 자칫 큰 문제가 발생할 수도 있었던 거죠. 이 경험을 통해 저는 애매한 부분은 내 마음대로 추측하지 말고 꼭! 꼼꼼하게 확인하자는 교훈을 얻었습니다.

 

 

 

그로스 팀 리드

제품 매출을 높이기 위해 회사에서 그로스 팀을 임시로 만들었습니다. 그로스 팀에 지원한 팀원들이 많았기 때문에 팀이 2개로 나뉘었고, 그중에 저는 [유저탐구생활]이라는 이름의 팀의 리드로 활동했습니다.

 

팀원들과 함께 우리 서비스에 어떤 문제가 있고, 이 문제를 해결하기 위해 무엇을 해야 할지 고민했습니다. 그 과정에서 비즈니스의 가장 본질인 유저에 대해 탐구하기로 했고 [유저탐구생활]이라는 팀명을 정했습니다.

 

당시 우리팀의 로고

 

결국 매출은 잠재고객에 의해 이루어지므로 우리는 유저에 대해 알고 싶었습니다. 우리 서비스를 사용하는 유저는 누구인가? 사용하지 않는 유저는 누구인가? 유저로부터 배우기 위해 우리가 할 수 있는 액션은 무엇인가? 이러한 물음들을 바탕으로 현재 우리의 문제와 솔루션을 기획하여 전체회의에 발표했습니다.

 

결국 우리의 기획은 실행되지 않았지만, 회사의 결정을 빠르게 수용하고 팀을 해체시켰습니다. 회사의 리소스를 분산하기보다는 한 곳에 집중하는 것이 좋겠다고 생각했고, 저 스스로도 솔루션에 대한 확신이 없었습니다. 저는 경험이 없었고, 정보도 부족했기에 실행에 대한 두려움이 더 컸습니다.

 

이후 다시 백엔드 개발자로 복귀하며 주어진 업무에 집중했습니다. 하지만 이전과는 마음가짐이 달라졌습니다. 비즈니스에 대한 관심이 높아졌고 이후 매일 비즈니스 아티클을 읽는 습관을 만들었습니다. 저에게 주어진 업무를 오퍼레이터 관점이 아닌, 메이커의 관점으로 보게 되었습니다.

 

그로스 팀에 참여하면서 저는 문제를 발견하고, 근거를 찾고, 솔루션을 제안하는 경험을 했습니다. 비록 그 솔루션을 실행하지 못했을지라도 제겐 매우 값진 경험이었고, 회사 생활 2년 중에서 가장 크게 배우고 성장한 한 달이었습니다.

 

 

 

---

 

 

 

마무리

돌이켜보니 팀원들과 정말 많은 일을 해왔고, 많은 것들을 배웠다는 생각이 듭니다. 퇴사하는 입장에서 아쉬운 마음도 있지만,, 지금은 잠시 이별하고자 합니다. 기회가 된다면 다시 볼 날이 오기를..!

 

개인적으로 업무를 하며 느낀 저의 아쉬운 점은 제 개발역량에 대한 부분이었습니다. 같은 실수를 반복하지 않기 위해 PR 회고를 진행하고 수시로 기록했지만 아무래도 제 성향이 기술에 대한 디깅보다는 개발 외의 비즈니스에 더 관심이 많다 보니 기술적으로 디테일한 부분에 부족함이 느껴졌습니다. 그때마다 우철님과 선우님의 꼼꼼한 리뷰 덕분에 많이 배우고 성장할 수 있었습니다.

 

특히, 제품을 만드는 과정에서 서로 토론하고, 합의하며, 함께 성장하는 경험들이 저에겐 가장 인상적이었습니다. 단순히 지시하고 명령하는 것이 아닌, 직급과 경력에 상관없이 서로 배우고 성장할 수 있다는 것을 이 회사와 팀원들을 통해 배웠습니다.

 

 

'업무를 통해 배운 것들' 회고는 여기서 마치겠습니다. 다음에는 '업무 외에 했던 것들'에 대해 말해보겠습니다. 다음 글도 기대해주세요!