왜 떠나는가

이직이다. 재직 기간 중에는 서류 합격 여부로 나의 시장가치를 가늠해 보는 습관이 있다. 코인원에서 빗썸으로 옮긴 일이 여기에 해당한다. 이직의 이유는 매번 달랐다. NHN 엔터프라이즈로 간 이유는 퍼블릭 클라우드 환경을 경험하기 위해서였고, 코인원으로 간 이유는 서포트 엔지니어에서 데이터 엔지니어로 직무를 바꾸기 위해서였다. 빗썸으로 간 이유는 더 큰 볼륨을 경험하고 싶어서였다.

빗썸에서는 이전에는 경험하지 못했던 볼륨을 다뤘다. 높은 스펙의 레드시프트 클러스터에서도 리소스가 부족해지는 경험을 했다. (물론 굉장히 사소한 부분이었지만) 25년 1월부터 1년 9개월 정도 다녔다. 다니는 동안 궁시렁댔지만, 그 속에서 얻어 간 것도 많았다. 8년 넘게 일해 오면서 이번 이직을 결심한 이유는 아래 질문들에 답을 내릴 수 있었기 때문이다. (최근 링크드인에서 봤던 글-원문링크)

1. 나는 충분히 기여했는가
2. 나는 배울 만한 사람인가
3. 뒤에서 시작할 각오가 있는가

1. 나는 충분히 기여했는가

(각자 해석하기 나름이겠지만) 데이터 플랫폼 관점에서는 충분히 기여했다고 생각한다. 데이터 플랫폼은 눈에 잘 띄는 서비스 기능은 아니지만, 제대로 없으면 모든 팀의 속도를 늦춘다. 그래서 내가 맡은 일의 기준도 단순히 기능 하나를 만드는 데 있지 않았다. 데이터를 어디서 받아오고, 어떻게 흘려보내고, 어떤 형태로 저장하고, 누가 어떤 방식으로 다시 쓰게 할 것인지 큰 그림을 잡는 일이 중요했다.

그 관점에서 데이터 플랫폼 아키텍처의 밑바탕을 만드는 데 꽤 많은 시간을 썼다. 모든 결정을 완벽하게 했다고 말할 수는 없지만, 적어도 앞으로 확장할 수 있는 방향과 각 구성 요소가 맡아야 할 역할은 계속 고민했다. 플랫폼은 한 번 만들고 끝나는 제품이 아니라, 여러 요구사항과 운영 조건을 받아내며 계속 변하는 기반이라고 느꼈다.

스트리밍 파이프라인 설계에서도 큰 역할을 했다. 오픈은 못 했지만.. 실시간에 가까운 데이터를 안정적으로 흘려보내려면 단순히 데이터를 연결하는 것 이상이 필요했다. 데이터가 늦게 들어오거나, 중복되거나, 중간에 실패했을 때 어떻게 다룰지까지 생각해야 했다. 효율적인 오케스트레이션은 아직 해결할 문제가 많이 남아 있다. 그래도 어떤 부분을 자동화하고, 어떤 부분은 운영자가 통제할 수 있게 남겨야 하는지에 대한 감각은 많이 생겼다.

2. 나는 배울 만한 사람인가

객관적으로 판단하기는 힘들다. 객관적인 판단 기준이 성과평가일 수 있겠지만, 나는 그 등급을 내 지표로 삼고 있지는 않다. (물론 잘 나오면 그때는 지표로 삼을 예정. 수고)

내가 무엇으로 팀 동료들에게 배울 만한 사람이었는지 곰곰이 생각했다. (물론 쓰는 와중에도 생각 중이다) 나는 어느 한 분야에 특출난 사람은 아니었다. 전동영처럼 협의에 강한 사람도 아니었고, 김정인처럼 데이터를 잘 뜯어보는 사람도 아니었다. 이준구처럼 컴퓨터 공학자 관점에서 기술을 바라보는 능력도 부족했다. 적당히 평범하게, 어느 정도는 했다. T자형 인재라기보다는 가로축이 넓은 사람에 가까운가? (이건 예비 배우자가 "오빠의 능력은 뭐라고 생각해?"라고 물었을 때 아무 답변도 못 했던 경험으로 썼다)

그럼에도 나는, 남들이 보기에는 깊지 않을 수 있지만, 꽤 넓은 경험을 했다. 데이터가 들어오는 파이프라인부터 복잡한 비즈니스를 쿼리로 풀어내는 변형 단계, 실제 서빙 테이블에 적재하고 이를 API로 제공하는 과정까지 하나의 큰 라이프사이클을 경험했다. 재수 없게 들릴 수 있지만, 빗썸 데이터팀을 경험한 사람 중 이 과정을 온전히 겪어 본 사람은 나라고 생각한다. (진짜 재수 없네;;)

테이블 포맷에서 어떤 테이블 프로퍼티를 정의할지, 제한된 리소스 안에서 오케스트레이션 부하를 어떻게 분산할지, 데이터베이스에 부하를 덜 주면서 안정적으로 수집하려면 어떻게 해야 할지, API가 응답값을 어떻게 만들고 제공해야 할지 뜯고 맛보고 즐겼다. 완벽하지 않았을 수는 있다. 그래도 이런 경험이 쌓이면서 무엇이든 해낼 수 있다는 자신감도 같이 찾았다. 깊지는 않지만 넓은 경험을 한 동료로서, 팀원들에게 조금이라도 도움이 되는 사람이었다고 생각한다.

3. 뒤에서 시작할 각오가 있는가

사실 두렵다. 당분간 아무 짓도 하지 않아도 몇 년은 먹고살 만한 돈을 가진 기업에서, 이제 막 영업이익을 만들어내며 도약하려는 기업으로 옮기기로 했다. 막상 퇴직 신청을 하고 나니 불안한 감정이 더 올라왔다.

다시 생각해 보면 어느 기업이나 크게 다르지 않다. 잘나가는 기업도 어느 순간 인앤아웃(레이오프라 부르는 것)을 할 수 있고, 그 대상이 나일 수도 있다. 몸집이 작은 기업에서 그런 일이 더 자주 일어나는 건 맞지만, 안정적이고 큰 회사라고 완전히 다르지는 않다. 언제든 겪을 수 있는 일이고, 결국 살아남으려면 실력과 능력이 필요하다고 생각한다.

내 능력을 키우는 방법은 돈을 벌고 싶어 하고, 기민하고 빠르게 움직이는 조직에서 경험을 쌓는 것이라고 판단했다. 아직 도전하기에 늦은 나이도 아니다. 조금이라도 젊었을 때 빵꾸 난 배일지도 모르는 배에 올라타 보는 경험도 필요했다. 역경과 고난이 많지 않았던 나에게 조금 더 채찍질할 수 있지 않을까 하는 생각도 든다.

아직 늦지 않았기에 남은 커리어 기간 동안 살아남을 수 있는 능력을 키우고자 뒤에서 시작할 각오를 다졌다. 이 세 가지 질문에 답을 내릴 수 있었기 때문에 떠나기로 결정했다. (물론 연봉 인상률이 큰 역할을 함. ㅈㅅ..)

회사에서 무엇을 배웠는가

커뮤니케이션 방식을 많이 배웠다. 기술적으로 맞는 말만 하는 것과 실제로 일이 되게 만드는 말은 다르다. 같은 문제를 두고도 개발자, 데이터 소비자, 서비스 운영자가 보는 지점이 다르고, 각자가 중요하게 여기는 것도 달랐다. 그래서 해결책을 설명할 때는 내가 알고 있는 기술보다 상대가 겪는 불편과 결정해야 하는 일을 먼저 이해해야 했다.

플랫폼을 제공하는 입장에서 문제를 보는 법도 배웠다. 플랫폼 팀의 답은 "이렇게 하면 됩니다"에서 끝나면 안 됐다. 사용하는 사람이 헷갈리지 않아야 하고, 운영하는 사람이 감당할 수 있어야 하며, 장애가 났을 때 설명 가능한 구조여야 했다. 기능을 만드는 일보다 기준을 정하고, 그 기준이 여러 팀에 반복해서 적용될 수 있게 만드는 일이 더 어려웠다.

대용량 트래픽을 직접 다뤘다고 말하기는 애매하다. 내가 더 많이 고민한 쪽은 큰 데이터였다. 큰 데이터를 어떤 쿼리와 테이블 설계로 풀어낼지, 어떤 형태로 쌓아야 나중에 다시 읽기 좋은지, 비용과 성능 사이에서 어디까지 타협할 수 있는지를 계속 생각했다. 레드시프트 같은 OLAP 환경을 쓰면서 단순히 데이터를 많이 넣는 것보다 어떻게 읽히게 만들 것인가가 훨씬 중요하다는 걸 경험했다.

회사에 아쉬운 점은 무엇인가

가장 아쉬웠던 건 다소 수직적인 조직 문화였다. 문제가 생겼을 때 원인을 찾고 구조를 고치기보다 책임 소재와 징계가 먼저 떠오르는 분위기가 아쉬웠다. 실수는 줄여야 하지만, 실수를 다루는 방식이 사람을 위축시키면 결국 더 많은 문제가 숨겨진다고 생각한다. 장애는 언제나 발생할 수 있다. 잘 예측하고 이를 방지하기 위한 장치를 마련하는 연습도 물론 필요하다. 하지만 내가 느끼기에는 그 대가가, 상상의 나래를 펼치려는 사람들에게 오히려 걸림돌이 되었다.

나와 비슷한 문제의식을 가진 동료들이 하나둘 떠난 것도 아쉬움으로 남는다. 좋은 동료가 있다는 건 단순히 같이 일하기 편하다는 뜻이 아니었다. 같은 문제를 보고 답답해하고, 더 나은 방식을 상상하고, 때로는 귀찮아 보이는 개선을 끝까지 밀어붙이는 사람이 주변에 있다는 뜻이었다. 그런 사람들이 모두 이직하고 나니 조직 안에서 내가 기대던 기준도 같이 사라지는 느낌이 들었다. 물론 지금 남아 있는 분들이 그런 성향이 아니라는 말은 아니다. 단지 나와 비슷한 동료가 없다고 느낀, 굉장히 주관적인 의견이다.

서비스를 운영하는 조직에서 외주에 의존하는 구조가 아쉬웠다.
IT 업계 전반의 문제일 수도 있지만, 운영 노하우는 결국 직접 해보는 과정에서 쌓인다고 생각한다. 시간이 조금 더 걸리더라도 내부에서 직접 만들고, 장애를 겪고, 고쳐 보고, 그 기록을 남겨야 다음 문제를 감당할 수 있다. 외주는 당장의 속도를 만들어 줄 수 있지만, 운영하는 조직이 배워야 할 감각까지 대신 쌓아주지는 못한다. 물론 최근에는 무조건 외주가 옳지 않다는 생각이 조금 바뀌었다. (때때로 불필요한 리소스로 속도를 늦추는 구간은 외주로 해결할 수 있다) 다만 적어도 팀 이름을 달고 있는 데이터 플랫폼 영역에서의 외주는 아직까지 이해하기 힘들다.

앞으로의 계획은 무엇인가?

앞으로는 소규모 증권사에서 AI를 곁들인 서비스에 기여하는 소프트웨어 엔지니어로 업무를 이어갈 예정이다. 큰 조직에서 정해진 역할을 잘 수행하는 것도 의미가 있지만, 지금은 조금 더 가까운 거리에서 문제를 보고 싶다. 사용자의 요구, 데이터의 흐름, 서비스의 제약을 한꺼번에 보면서 직접 손을 대는 일을 하고 싶다.

AI가 서비스에 들어간다고 해서 모든 문제가 자동으로 풀리지는 않을 것이다. 오히려 데이터가 어떻게 쌓여 있는지, 그 데이터를 믿을 수 있는지, 사용자가 어떤 맥락에서 결과를 받아들이는지가 더 중요해질 것 같다. 나는 그 사이에서 데이터를 이해하는 소프트웨어 엔지니어로 일하고 싶다. 데이터를 잘 쌓고, 잘 읽고, 실제 서비스에서 쓸 수 있는 형태로 만드는 사람이 되고 싶다.