왜 떠나는가
(이직, 창업, 휴식 등 다른 구성원들이 납득할 수 있는 구체적이고 솔직한 이유를 공유합니다.)
이직이다. 재직기간 중 나의 시장가치 판단을 서류 합격으로 보는 습관이 있다. (코인원에서 빗썸 이직이 부분에 해당) 이직의 사유는 다양하다. NHN 엔터프라이즈 로 간 이유는 퍼블릭 클라우드 환경에서의 경험을 위해, 코인원으로 간 이유는 서포트 엔지니어에서 데이터 엔지니어로 직무 변경을 위해, 빗썸으로 간 이유는 더 많은 볼륨을 경험하기 위해서 였다.
빗썸에서 이전과 경험할 수 없는 볼륨을 경험했다. 높은 스펙의 레드시프트 클러스터에서 리소스가 부족한 경험도 했다. (물론 굉장히 사소한 부분이었지만) 25년 1월부터 1년 9개월 정도 다녔다. 다니는 동안 궁시렁 댔지만 그속에서 얻어간 것도 많았다. 그러면서 8년넘게 업무를 하며 이직을 결심한 이유는 다음 질문에 답을 내릴 수 있어서 였다. (최근 링크드인 에서 봤던 글-원문링크)
- 나는 충분히 기여했는가
- 나는 배울 만한 사람인가
- 뒤에서 시작할 각오가 있는가
나는 충분히 기여했는가
(각자 해석하기 나름이겠지만) 데이터 플랫폼 관점에서는 충분히 기여했다고 생각한다. 데이터 플랫폼은 눈에 잘 띄는 서비스 기능은 아니지만, 제대로 없으면 모든 팀의 속도를 늦춘다. 그래서 내가 맡은 일의 기준도 단순히 기능 하나를 만드는 데 있지 않았다. 데이터를 어디서 받아오고, 어떻게 흘려보내고, 어떤 형태로 저장하고, 누가 어떤 방식으로 다시 쓰게 할 것인지 큰 그림을 잡는 일이 중요했다.
그 관점에서 데이터 플랫폼 아키텍처의 밑바탕을 만드는 데 꽤 많은 시간을 썼다. 모든 결정을 완벽하게 했다고 말할 수는 없지만, 적어도 앞으로 확장할 수 있는 방향과 각 구성 요소가 맡아야 할 역할을 계속 고민했다. 플랫폼은 한 번 만들고 끝나는 제품이 아니라, 여러 요구사항과 운영 조건을 받아내며 계속 변하는 기반이라고 느꼈다.
스트리밍 파이프라인 설계에서도 큰 역할을 했다. 실시간에 가까운 데이터를 안정적으로 흘려보내려면 단순히 데이터를 연결하는 것 이상이 필요했다. 데이터가 늦게 들어오거나, 중복되거나, 중간에 실패했을 때 어떻게 다룰지까지 생각해야 했다. 효율적인 오케스트레이션은 아직 해결할 문제가 많이 남아 있다. 그래도 어떤 부분을 자동화하고, 어떤 부분을 운영자가 통제할 수 있게 남겨야 하는지에 대한 감각은 많이 생겼다.
나는 배울 만한 사람인가
뒤에서 시작할 각오가 있는가
회사에서 무엇을 배웠는가
커뮤니케이션 방식을 많이 배웠다. 기술적으로 맞는 말만 하는 것과 실제로 일이 되게 만드는 말은 다르다. 같은 문제를 두고도 개발자, 데이터 소비자, 서비스 운영자가 보는 지점이 다르고, 각자가 중요하게 여기는 것도 달랐다. 그래서 해결책을 설명할 때는 내가 알고 있는 기술보다 상대가 겪는 불편과 결정해야 하는 일을 먼저 이해해야 했다.
플랫폼을 제공하는 입장에서 문제를 보는 법도 배웠다. 플랫폼 팀의 답은 "이렇게 하면 됩니다"에서 끝나면 안 됐다. 사용하는 사람이 헷갈리지 않아야 하고, 운영하는 사람이 감당할 수 있어야 하며, 장애가 났을 때 설명 가능한 구조여야 했다. 기능을 만드는 일보다 기준을 정하고, 그 기준이 여러 팀에 반복해서 적용될 수 있게 만드는 일이 더 어려웠다.
대용량 트래픽을 직접 다뤘다고 말하기는 애매하다. 내가 더 많이 고민한 쪽은 큰 데이터였다. 큰 데이터를 어떤 쿼리와 테이블 설계로 풀어낼지, 어떤 형태로 쌓아야 나중에 다시 읽기 좋은지, 비용과 성능 사이에서 어디까지 타협할 수 있는지를 계속 생각했다. 레드시프트 같은 OLAP 환경을 쓰면서 단순히 데이터를 많이 넣는 것보다, 어떻게 읽히게 만들 것인가가 훨씬 중요하다는 걸 경험했다.
회사에 아쉬운 점은 무엇인가
가장 아쉬웠던 건 딱딱한 조직 구조였다. 문제가 생겼을 때 원인을 찾고 구조를 고치기보다, 책임 소재와 징계가 먼저 떠오르는 분위기는 마음에 들지 않았다. 실수는 줄여야 하지만, 실수를 다루는 방식이 사람을 위축시키면 결국 더 많은 문제가 숨겨진다고 생각한다.
나와 비슷한 문제의식을 가진 동료들이 하나둘 떠난 것도 아쉬움으로 남는다. 좋은 동료가 있다는 건 단순히 같이 일하기 편하다는 뜻이 아니었다. 같은 문제를 보고 답답해하고, 더 나은 방식을 상상하고, 때로는 귀찮아 보이는 개선을 끝까지 밀어붙이는 사람이 주변에 있다는 뜻이었다. 그런 사람들이 모두 이직하고 나니 조직 안에서 내가 기대던 기준도 같이 사라지는 느낌이 들었다. 물론 지금 남아있는 분들이 이런 성향이 아니다 라는 말은 아니다. 단지 나와 비슷한 동료가 없다 라 느낀 굉장히 주관적인 의견이다.
서비스를 운영하는 조직에서 외주에 의존하는 구조가 아쉬웠다. IT 업계 전반의 문제일 수도 있지만, 운영 노하우는 결국 직접 해보는 과정에서 쌓인다고 생각한다. 시간이 조금 더 걸리더라도 내부에서 직접 만들고, 장애를 겪고, 고쳐 보고, 그 기록을 남겨야 다음 문제를 감당할 수 있다. 외주는 당장의 속도를 만들어 줄 수 있지만, 운영하는 조직이 배워야 할 감각까지 대신 쌓아주지는 못한다. 물론 최근 무조건 외주 가 옳지 않다 라는 생각은 조금 바뀌었다. (때때로 불필요한 리소스로 속도를 늦추는 구간은 외주 로 해결할 수 있다) 다만 적어도 팀 이름을 달고 있는 데이터 플랫폼 안에서의 외주는 아직까지 이해하기 힘들다.
앞으로의 계획은 무엇인가?
앞으로는 소규모 증권사에서 AI를 곁들인 서비스에 기여하는 소프트웨어 엔지니어로 업무를 이어갈 예정이다. 큰 조직에서 정해진 역할을 잘 수행하는 것도 의미가 있지만, 지금은 조금 더 가까운 거리에서 문제를 보고 싶다. 사용자의 요구, 데이터의 흐름, 서비스의 제약을 한꺼번에 보면서 직접 손을 대는 일을 하고 싶다.
AI가 서비스에 들어간다고 해서 모든 문제가 자동으로 풀리지는 않을 것이다. 오히려 데이터가 어떻게 쌓여 있는지, 그 데이터를 믿을 수 있는지, 사용자가 어떤 맥락에서 결과를 받아들이는지가 더 중요해질 것 같다. 나는 그 사이에서 데이터를 이해하는 소프트웨어 엔지니어로 일하고 싶다. 데이터를 잘 쌓고, 잘 읽고, 실제 서비스에서 쓸 수 있는 형태로 만드는 사람이 되고 싶다.