Chanhee's Dev Blog

회고록 - 데브시스터즈를 떠나며

얼마 전, 5년 가까이 다니던 데브시스터즈를 떠났습니다. 2021년 데이터 사이언티스트로 입사해서, ML 팀 빌딩도 해보고, AI/ML 엔지니어로서 프로젝트도 여럿 진행해보는 등 정말 여러 가지 역할을 맡으면서 정신 없이 보냈던 5년이었습니다. 적지 않은 시간을 데브시스터즈에서 보내면서 양적으로든, 질적으로든 많은 경험을 했던만큼, 그간 배웠던 점을 혼자 정리를 한번 해봤습니다.

데브에는 어떻게 오게 됐나?

저는 원래 대학교 때 물리학을 전공했습니다. 전공 과목 중에 ‘전산물리’라는 과목이 있었는데, 이름에서 유추할 수 있다시피 수치해석 프로그래밍(주로 C 또는 matlab)으로 물리 현상을 재현하는 것이었죠. 그 과목을 꽤나 재미있게 들었습니다. 그래서 대학원 졸업 후 제 첫 직업으로 제조공정 시뮬레이션 업무(CAE Engineer)를 시작하게 됐습니다.

그렇게 시뮬레이션 업무를 하다가, AI/ML(인공지능/머신러닝) 쪽으로 눈이 돌아가기 시작했습니다. 시뮬레이션은 AI/ML 하고는 전혀 상관없기도 하고 프로그래밍을 할 일도 없었으나 두 영역 모두 도전해볼만 하다는 생각을 하게 됐습니다.

• AI/ML: 당시 핫했던 알파고 이슈로 딥러닝에 관심이 가기 시작. 딥러닝이 결국 궁극적인 해결책이 될 것으로 보였음. 시뮬레이션은 너무 쓸모가 좁기도 함.
• 프로그래밍: 사내에서 java 로 UI 스크립팅도 해보고 python 으로 단순한 시뮬레이션 앱을 만들어보면서 어느 정도 배우면서 적응할 수 있을 것 같다는 자신감이 붙음

당시 사내에서는 딥러닝을 배울 환경이 전혀 아니어서, 배울 수 있는 곳을 탐색하기 시작했습니다. 하지만 잡 마켓에서 원하는 ML 엔지니어의 역량과 제 경험과는 좀 차이가 있었죠. 대신 당시 핫했던 DS(데이터 사이언티스트)라는 직무가 저한테 적절해보였습니다. 저도 통계와 모델링, 시각화 경험이 있으니 기여도 가능할 거고, 자연스럽게 머신러닝, 딥러닝을 배우면서 성장도 가능할 거라고 생각했죠.

처음부터 어떤 특정 업계를 특별히 고려한 건 아니었습니다. 데브시스터즈가 맨 처음 눈에 들어왔습니다. 오븐브레이크도 꽤 오래한 유저였습니다. 주변에서 덕업일치라고 축하해줬던 기억이 나네요. 마침 당시 데브에서 원하던 DS 도 딱 제가 바라던 방향과 일치했습니다.

그렇게 데브에서의 삶이 시작됐습니다.

데브에서의 삶

데이터 사이언티스트

첫 1년은 예상했던 대로 통계 지식을 이용한 데이터 분석을 많이 했습니다. 쿠키런 킹덤을 런칭한지 얼마 안된 시점이어서, 큰 방향성 측면에서 분석이 필요한 경우가 꽤 많았거든요. 그러면서 LTV(LifeTime Value) 모델도 들여다보게 되고… ‘분석하다가 ML 에 점점 발을 들인다’ 라는 계획대로 잘 가고 있다고 생각하던 그 때!

ML 팀 리더

머신러닝 팀 빌딩을 처음부터 하게 됐습니다. 첫 1년 동안 느꼈던 게, 아무리 모델을 잘 만들려고 노력해도 실제로 사용해야할 사람들이 쓰기 불편하면 가치가 퇴색된다는 것이었습니다. 사내 유저에게 실질적인 도움이 되고 싶었습니다. 그래서 기존에 잘하던 것들을 웹서비스를 비롯한 친숙한 형태로 만들자는 방향을 잡았습니다. (지금 생각하면 조금 무모했던 것 같지만…)

이 때부터 제 커리어 계획과는 좀 달라졌습니다. 팀 리더라는 역할도 있고, 미래를 상상하는 걸 좋아하다보니, 주로 서비스 기획하는 부분을 많이 하게 됐습니다. 하지만 서비스를 만든다는게 정말 많은 걸 고려해야 하는 거였던 것을… 그때는 잘 몰랐습니다.

• 기술적: 이것저것 하게 됨. MLOps, 데이터 엔지니어링, …
• 기술 외적: 피플 매니징, 프로젝트 관리 (일종의 PO 역할), 서비스 운영 정책, 사내 협업 부서의 프로세스 컨설팅…

대충 2년 동안 이거저거 해보면서 배우는 것도 많았지만, 역설적으로 배우는 즐거움을 느끼기 힘든 시기였던 것 같습니다. 여기저기 신경쓸 것도 많았고 부족한 것만 눈에 띄었거든요. 세상에 없던 서비스를 처음 기획하고 추진하는 것까지는 잘 진행이 됐지만, 사내에 어느 정도 쓰임새가 생긴 이후부터가 문제였습니다.

아무리 사내 서비스라지만, 어떤 서비스가 도입될 때는 그 팀의 업무 프로세스가 변경되는 것은 필수적입니다. 그렇게 한번 도입되고 나니 최소한의 신뢰성을 챙겨야 한다는 책임감이 생겼고, 그런 서비스가 3개 이상이 쌓이고 나니 그에 필요한 기술적, 비즈니스적인 결정 때마다 인지 부하가 심하게 걸려서 힘들어했던 기억이 납니다.

그 시점에서 왜 그렇게 힘들었을까 주변 사람들에게 도움을 요청해봤습니다. 여러 사람들과 논의해보니 여러가지 이유가 나왔습니다. 하지만 그 중에는 제가 어쩔 수 없는 종류의 문제도 있었죠. 다만 제가 변화를 줄 수 있는 범위 안에서 “제 핸즈온 프로그래밍 경험이 더 필요하다.” 는 결론을 내리게 됐습니다. 그때는 그런 결론을 내리면서도 이게 옳은 방법일까 확신이 없었는데, 최근에 소프트웨어 설계에 대한 책과 강의를 여럿 보니 결국 맞는 방향이었던 것 같습니다. 당시 제일 고민이었던 소프트웨어 설계나 유지보수는, 아무래도 이론보다는 실무에서 바텀-업 방식으로 배우는 부분인데, 제가 직접 연습하고 실험할 기회가 충분치 않았던 것 같습니다.

AI Engineer

이후 2년 정도는 앞에서 나온 결론대로 “핸즈온 프로그래밍 경험을 더 쌓자.” 는 방향으로 업무가 주어졌습니다. 주로 LLM 애플리케이션을 많이 다루는 새로운 업무였습니다. 새로운 역할에 적응하기 위해 처음에는 langchain 을 통해서 슬랙 챗봇도 만들어보고, vector DB 활용해서 RAG 도 구현해보면서 기초적인 LLM 애플리케이션에 대한 감을 익혔습니다.

어느 정도 기초적인 감을 잡은 뒤에는 LLM 을 어떻게든 쉽게 활용하기 위해서라면 무슨 일이든 가리지 않고 진행했습니다.

• FastAPI + pgvector 를 통해서 AI 번역 백엔드 서비스 구성하기
• 코딩 경험이 아예 없던 바이브 코더(본업은 번역가)와 협업해서 풀스택 웹 서비스 구성하기
• helm 차트 작성해서 사내 쿠버네티스 클러스터에 배포하기

하지만 예전같이 일이 재미있지 않았습니다. 개인적으로는 일이 재미없게 느껴지는 게 처음이라 당황하기도 했습니다. 곰곰히 생각해보니 이제 저도 데브시스터즈도 달라졌고, 그러다보니 이제는 제가 하고 싶은대로 일을 진행하기 어려운 환경이 된 것 같았습니다. 달리 생각해보면 입사했을 때처럼 그렇게 서로 방향이 잘 맞았던 것이 참 행운이었던 것 같기도 합니다.

데브를 떠난 이후

저는 계속 AI 에 대해서 배우고 싶습니다. GPT-3.5 나올 때쯤만 해도 이걸 AI 라고 불러주기는 좀 아쉽지 않나 싶었는데, 어느새 성능도 많이 발전했고, 지능의 구성요소를 조금씩 갖춰가는 모습을 보면 알 수록 재미있는 분야 같습니다.

특히 코딩 쪽의 성능 발전은 다들 아시다시피 무시무시합니다. 예전에는 AI 없이 어떻게 개발했나 싶은 생각이 들 정도로 점점 표준이 되어가는 것 같습니다. AI 기반 코딩 도구들도 많이 생겼고, 프로세스나 문서화도 점점 AI 가 내 코드베이스를 잘 이해할 수 있는 방향으로 흘러가고 있습니다. 아직 사람이 해야할 부분은 많지만, 제가 못하던 것이나 오래 걸릴 수 있는 것들은 확실히 실현 가능해진 것 같습니다. 상상력이 풍부한 편이라 AI 를 이용해서 해보고 싶은게 참 많습니다.

지능에 대한 근본적인 탐구도 해보고 싶다는 생각입니다. 인공”지능”인데 지능이 무엇으로 이뤄져있는지, 어떻게 각 구성요소들이 상호작용하는지 등등… 지능에 대한 개념은 아직 제대로 합의된 것이 없습니다. 이런 문제가 좀더 명확하게 윤곽이 잡히면 어떤 종류의 문제든 조금 더 해결하기 쉬워질 것 같습니다.

AI 에 대해서 확실하게 말할 수 있는 것은, LLM 처럼 텍스트만으로 지식을 저장하고 전달하는 것은 효율적이지 않다는 것입니다. 현재는 에이전트 방식이 그 한계를 넘기 위한 최선의 방식이고, 그 토대에서 컨텍스트 엔지니어링이나 RL 방식의 최적화 과정이 지금 최전선에 있는 것 같습니다. 더 멀리는 온톨로지, 공간 지능, large reasoning models, 월드 모델 등이 AGI 를 향한 유망한 후보들인 것 같습니다. 저는 다음 행선지에서 공간 지능에 대한 경험을 좀더 할 수 있을 것 같습니다.

덧붙임

대학생 때 물리 학술 동아리 활동도 꽤나 활발히 했었는데, 발표 주제로 Slinky drop 을 물리학적으로 모델링하고 matlab 으로 시뮬레이션했던 기억이 납니다. Slinky drop 은 용수철 모양 장난감을 자유 낙하시켰을 때 나타나는 흥미로운 현상을 말하는 건데요. 이 유튜브를 보면 꽤나 흥미롭습니다. 나중에 반응이 좋으면 파이썬으로 다시 짜고 설명해도 재미있겠네요.

덧붙임 2

기존에 코딩 경험이 없는 순수 바이브 코더와의 협업은 아무나 해볼 수 있는 경험은 아닌 것 같습니다. 그 프로젝트를 진행하면서 “다음에도 바이브 코더와 협업하게 되면 어떻게 진행하면 좋을 것 같다” 에 대한 멘탈 모델이 어느 정도 만들어졌는데 이런 얘기를 나중에 나눠봐도 재미있을 것 같습니다. 앞으로 바이브 코더가 개발자를 대체할 수 있을 것인가에 대해서도 어느 정도 저만의 의견이 생기기도 했구요.