두번째 직장 온보딩 회고
부제: 소프트 스킬의 중요성
원래 개발과 상관없는 일을 8년 정도 했고, 어머니 수술을 계기로 개발을 독학으로 5개월가량 공부했다. 그리고 첫 회사에서 1년 6개월 정도의 경력을 마무리하고 8월 16일부로 개발자로서 두 번째 직장에 출근을 시작했다.
이번 주로 온보딩이 마무리되어 회고를 작성한다.
현재 재직 중인 회사는 시리즈 B, 누적 투자 규모 약 300억원의 스타트업이며, 다음 라운드를 준비하고 있다. 그리고 내가 이 회사에 입사하게 된 계기는 다음과 같다.
- 팀 차원에서 기술 부채 청산을 생존의 관점으로 생각하고 있다
- 파이썬 2.7로 된 레거시를 자바 or 코틀린으로 갈아엎을 수 있는, 돈을 주고도 경험 해보지 못 할 값진 경험을 해볼 수 있다
- 회사가 시장에서 경쟁력이 있다고 판단했다
- 새로운 투자를 받은 시기가 자이언트 스텝 이후였다
- 주관적으로 BM이 아주 좋다고 생각했다
- 기존에 다니던 회사보다 규모가 더욱 컸다
- 더 큰 규모의 IT 기업에서 일해보고 싶었다
- 규모가 더 큰 만큼, 대기업에서 오신 시니어 개발자분들도 다수 계셨다
- 도메인도 물론 중요하지만, 기술적인 역량은 도메인에 독립적이다
- 도메인 지식은 해당 분야에서 경력을 쌓으면 쌓을수록 자연스럽게 증대될 수 있다
- 기술적인 역량은 퇴근 후 개인의 노력이 가장 중요하지만, 경험이 풍부한 시니어들이 많으면 더욱 빠르게 증대될 수 있다
- 기술적인 역량은 부족한데, 도메인 지식만 풍부하면 다른 도메인으로 이직했을 때 아무것도 못하는 사람이 될 수 있다
그런고로 나는 자바와 코틀린밖에 할 줄 모르지만… 최근에 파이썬(그것도 2.7이다)을 새로 학습해서 기존 시스템을 개선하는 데 심혈을 기울이는 중이다.
기존 레거시가 파이썬 2.7에 자체 개발된 프레임워크(😒)라는 보기 드문 레거시라 신규 비즈니스 요구 사항을 충족시키는데 매우 많은 리소스가 점유 되고 있다. 즉, 그린 필드였다면 5~10분이면 끝났을 작업도 이러한 브라운 필드에서는 몇 일씩 걸리는 작업이 될 수도 있는 것이다. 아무튼, 스트레스를 꽤 많이 받을거라 예상하면서 들어왔지만, 오히려 생각보다 즐겁게 일하고 있다. 왜 그런지 생각을 해봤는데, 일이라기보다는 전부 다 내 경험치로 보이는 상태에 더 가까운 것 같다. 온보딩 기간이라 비중 있는 업무는 안할줄 알았지만, 생각보다 비중 있는 업무들을 맡고 있고 오히려 매우 만족스럽다. 최근에는 퇴근 후에 하던 개인 공부 시간을 모조리 회사 레거시 개선에 쏟고 있다. 그냥 회사에서도 일하고 집에서도 일하는데, 이게 일이라고 느껴지지는 않는다. 이런 게 워라블인가 싶기도 하다. 🧐
온보딩 기간 동안 느낀 점으로는 그동안 해온 CS 공부, 코드 카타 등이 이 정도의 브라운 필드에서도 비즈니스 요구 사항을 별 문제없이 충족시킬 수 있을 만큼 내 하드 스킬을 확실하게 끌어 올려줬다고 생각하는 부분이 있고, 이렇게 애자일한 팀에서 일하는데 내 소프트 스킬이 생각보다 미흡하다고 느껴지는 부분도 있다. 내 생각을 글로 풀어 쓰는 건 자주 해와서 익숙하고 편한데, 내 생각을 실시간으로 여러 사람에게 전달하는 건 생각보다 몹시 어렵다. 컴퓨터만 붙들고 산 방구석 아싸의 한계에 봉착했다는 생각도 든다.
현재는 회사 차원에서 기술 부채 청산에 많은 리소스를 투자하고 있기 때문에, 내 작업의 상당수는 기존 레거시를 개선해서 우리 회사 임직원들의 업무 효율을 개선하는 쪽에 치중되어있다. 이러한 작업을 하면서 역시 크게 느낀 부분은, 개발자라고 요구 사항만 넙죽넙죽 받아서 코딩만 하면 되는 게 아니라는 것이다. 원래도 이러한 생각을 갖고 있기는 했는데, 이렇게 내 생각을 직접적으로 업무에 적용하고 그 여파를 느끼며 일해보는 건 또 처음이라 꽤 신선하다.
IT 회사들은 아주 크게 보면 사업 -> 기획 <- 제품(디자인, 개발 등) 정도의 구조로 이뤄져 있다고 생각한다. 사업은 회사가 돈을 벌어서 성장해나갈 수 있게 시장을 개척하는 사람들이다. 그리고 이 사람들의 생각을 실제 제품으로 구현해 시장에서 임팩트를 내기 위해서는 디자이너, 개발자들이 필요한데, 문제는 이 사람들은 사업을 모르고, 사업하는 사람들은 디자인과 개발을 모른다. 그러니 중간에서 이들을 조율해줄 수 있는 사람들이 필요한데, 이 사람들이 바로 기획이다. 즉, 기획은 사업의 말을 제품 그룹이 잘 알아먹을 수 있게, 혹은 반대로 번역해주는 사람들에 가깝다. 주로 요구 사항을 정리하는데 많은 시간을 쏟는 이유도 이와 일맥상통한다고 생각한다.
문제는, 현재 우리가 하는 작업들의 주 목적은 우리 제품 그룹의 업무 효율을 개선하는 데 있기 때문에 중간에 기획이 없다. 그래서 타 부서 동료들의 요구 사항이 우리에게 다이렉트로 넘어온다는 점이다. 우리 개발자들은 타 부서 동료들이 어떻게 일하고 있는지 대체로 잘 모르며, 마찬가지로 타 부서의 동료들 또한 우리 개발자들이 어떻게 일하는지 잘 모른다. 그러니 타 부서 동료들의 요구 사항이 딴에는 쉽다고 생각되어도 막상 개발로 넘어오면 굉장히 난해한 요구 사항이 될 수도 있는 것이다.
어떻게 해결해야 할까? 답은 생각보다 간단하다. 개발자들이 직접 타 부서 동료들과 마주하고 그들이 어떻게 일하고 있는지 관심을 기울이면 된다. 그럼 그들의 요구 사항이 더욱 명확하게 와닿기도 하고, 그들의 요구 사항보다 더욱 좋은 해결방안이 떠오르기도 한다. 혹은 해당 요구 사항이 굳이 개발하지 않아도 되는지도 알 수 있으며(개발 자체가 비용이기 때문에, 때로는 아예 개발하지 않는 것이 더 좋은 경우도 분명 존재한다.), 혹은 해당 요구 사항이 굉장히 중요한 급 건인지도 알 수 있다. 나 같은 경우엔 직접 요구 사항을 전해온 동료의 자리로 가 어떻게 일하고 있고, 무엇 때문에 불편한지 보여달라고 요구한다.
최근에는 기억나는 작업 중 하나로는 어떤 업무를 자동화해달라는 요구를 받았는데, 티켓을 전달 받은 것이 아니고 해당 실무자분이 내 자리로 직접 와서 요구해 오셨다. 그래서 대체 어떻길래 직접 찾아와가면서 요구를하시는지 궁금해 어떻게 일하고 계시는지 보여주실 수 있냐고 여쭤봤는데, 그 자리에서 바로 보여주시더라. 구글 시트에서 고객의 휴대폰 번호를 복사해 우리 어드민에 붙여 넣은 다음 일부 상태를 변경하는 작업이었다. 문제는 이걸 하루에 수백 번씩 반복하고 있다는 것이었고… 당연히 최대한 빠르게 처리해야 할 일이라는 생각이 들었다.
이제 남은 문제는 어떻게 처리할 것인지였는데, 나는 우선 도메인 자체가 비효율적이기 때문에 이런 상황이 된 게 아닌가? 라는 의문을 가졌다. 우리 모두의 업무 프로세스와 코드는 결국 도메인을 따라가기 때문에, 도메인이 명확하다면 업무 효율 개선에 큰 도움이 된다. 하지만 나는 입사한 지 이제 2주 차였기 때문에 도메인에 대해 무지했고, 당장 이분들의 루틴한 업무를 개선해드리기 위해 도메인 파악을 먼저 하기에는 시간이 부족했다. 아무리 봐도 나한테 하루에 수백 번씩 그 짓거리를 하라고 하면 나 같아도 지칠 것 같았다. 그러니 일단 땜질을 해서라도 빠르게 자동화부터 하고 보자는 생각이 들었고, 시스템 구조를 살펴봤는데, 또 SaaS가 너무 많이 붙어있어 모든 시스템을 자동화하기에는 공수가 굉장히 많이 들어갈 것으로 판단됐다.
그래서 실무진분들과 미팅을 잡아, 이러한 상황을 설명해 드리고 생각할 시간이 약간 필요하다고 말씀을 드렸는데, 이분들이 “그러면 고객 휴대폰 번호만 보내드리면 쉽게 될수도 있나요?” 라고 역제안을 해오시는 것이다. 내 입장에서는 그렇게 되면 그냥 어드민에 휴대폰 번호를 수신해서 상태 업데이트만 하면 끝나게 되기 때문에 매우 간단해지는 부분이었고. 근데 나는 그게 어떻게 가능한지를 잘 몰라서 또 여쭤봤는데, 마케터분들이 쓰시는 브레이즈(Braze)라는 툴이 그걸 가능하게 해줬나 보다.
이 대목에서 나한테 어떤 부분이 부족한지를 또 느꼈었는데, 나는 아무래도 개발자다 보니 평소에 “필요하면 직접 만들지.” 라는 마인드를 갖고 있는데, 그러다 보니 오히려 여러 가지 유용한 툴들을 잘 알지 못한다고 느꼈다. 오히려 개발을 모르시는 분들이기 때문에 유용한 노코드 툴들을 폭넓게 알고 활용하실 수 있는 건가? 싶기도 했고. 내가 저런 유용한 도구들을 잘 알고 있고 이것들을 잘 활용할 수도 있고, 소통하는 데도 쓸 수 있다면 생산성이 많이 늘어날 수도 있겠다는 생각이 들었다.
이번 주 수요일에는 리팩토링 데이라 하여 CTO님과 다른 동료 개발자 한 분, 나까지 총 세 명이서 10인실을 종일 사용했다. 알림톡 시스템을 어떻게 개선할지 계속해서 논의했고, 서로 키보드를 번갈아 잡아가며 코딩했다. 식사는 배달을 시켜 먹었고, 그 날은 외부의 어떠한 인터럽트도 들어오지 않았다. 우리는 하루를 온전하게 리팩토링에 투자할 수 있었다. 굉장히 재미있고 유익한 시간이었다고 생각한다. 이러한 경험을 더 많이 할 수 있으면 좋겠다는 생각도 들었다.
아무튼, 한 달 정도밖에 출근하지 않았지만, 현재로서는 이 회사가 굉장히 마음에 든다. 요즘 좀 엉뚱한 생각을 하는데, 또라이 보존의 법칙이라고 직장을 좀 다니신 분들은 아실 것이다. 근데 우리 회사에는 내가 볼 때 아무리 봐도 모난 사람이 딱히 없는 것 같은데, 이쯤 되니까 내가 또라이인 게 아닐까? 싶기도 하고…
다음 달에는 회사 사무실이 역삼역 GFC로 이전한다. 현재 사무실의 크기가 좁다는 생각은 안 드는데, 사무실 대비 인원이 많아지다 보니 사무실이 비좁게 느껴지기는 한다. 특히 회의실… 그래서 회사 이전이 많이 기대된다. 여기서 질 좋은 많은 경험을 하고, 사업적으로나 개발적으로나 내 역량이 크게 좋아질 수 있기를 기원한다. 물론 그만큼 내 시간과 노력도 많이 투자되어야 할 것이다.
