커리어 회고, 그리고 프론트엔드 개발자였던 내가 백엔드로 직무 전환을 한 이유

지금 회사를 다니기 시작한 지는 이제 만 3년이 되어가고, 만 2년이 된 시점 즈음에 백엔드로 직무 전환을 했다.

오늘은 그 이야기를 한 번 해보려 한다. 어떤 일들이 있었고, 어떤 가치를 따라 직무 전환을 하게 되었는지에 대한 이야기다.

 

커리어의 흐름

커리어의 시작

첫 개발 커리어는 카카오브레인에서 iOS 개발 인턴으로 시작했다.

물론, 그 전에 iOS 프리랜서로 대기업에 소속되어 외주를 몇달 하기도 했지만 (iOS 개발자를 인하우스로 두지 않는 회사였다.), 내가 생각했을 때 정식으로 팀 내에 소속되어서 개발을 시작하게 된 건 인턴 때라고 생각하고 있다.

 

개발을 시작하게 된 것도 우연이었지만, iOS로 커리어를 시작한 것도 순전히 운이었다.

대학에 다니면서 이제 슬슬 코테 준비를 해봐야지 하는 마음으로 지원했던 첫 회사가 분야 중복 지원이 가능해 당시 포지션이 열려 있던 모바일, 웹프론트, 백엔드 직무를 모두 지원했다. 하지만, 코딩테스트 당일이 되어 보니 시험 참여는 한 분야밖에 되지 않아 그 당시에 그나마 가장 익숙했던 iOS를 선택해 코딩테스트를 치렀다.

 

그렇게 합격해 인턴 시절을 iOS 개발자로 보내고, iOS를 일로써 다루면서도 흥미가 사라지지 않았고, 계속해서 배우고 싶은 내용이 생겨났기 때문에 적성에 맞는구나 하고 판단하고 iOS 개발자의 길을 선택하게 됐다.

 

정규직 전환이 되어 입사했을 때 내 직무는 Software Engineer였다.

 

Unity 개발

그리고 입사 첫 날 팀에 배정이 되어 내가 할 업무가 Unity3D라는 걸 알게 되었다. 그 당시만 해도 사실 나는 개발 자체가 재미있었지, 꼭 어느 한 분야를 깊게 파고 싶다는 마음이 크지 않았기 때문에 온 힘을 다해 유니티를 공부하기 시작했다.

그 팀에서의 업무가 나에게 최적의 공부 환경이기도 했던 것이, 그 당시 팀장님의 티칭 스타일이 처음 접하는 기술이더라도 일단 프로젝트 개발에 참여해보며 새로운 언어와 프레임워크에 익숙해지도록 하는 스타일이었다. 나는 엉덩이를 붙이고 앉아 공부하는 거엔 정말 젬병인 사람이라, 지금껏 프로젝트를 해오며 새로운 기술들을 배워왔다. 그런 나에게 정말 꼭 맞는 스타일이었다.

또, 내가 혼자 공부 하는 것보다 함께 공부하고 프로젝트 하는 사람이 있으면 더 빠르게 배운다는 걸 다년 간의 개발 동아리 활동을 통해 알고 있었다. (SOPT라는 동아리다. 위에서 잠시 언급했던, 내가 개발을 시작하게 된 우연한 기회의 주인공이기도 하다.) 그래서 유니티를 빠르게 배워 회사 일에 기여하기 위해 서울대 메타버스 학회에 가입해 매주 세션을 듣고, 사람들과 함께 두 개의 프로젝트를 했다. 가만히 책을 읽거나 강의를 듣는 것보다 몇 배는 빠르게 유니티에 익숙해져갔다. 회사에서 함께 일하는, 나보다 연차가 훨씬 높은 동료들에게도 내가 배워온 개념을 설명하는 세션을 열어 지식을 나누기도 하고, 반대로 경험이 많은 그들의 아키텍처링, 깊은 개발 개념들을 어깨너머 배우기도 했다.

 

Unity + iOS 하이브리드 개발

그렇게 유니티 개발을 빠르게 학습해 나가며 PoC, MVP를 만들어 나가던 중에 유니티의 UI 한계를 마주하게 되었다.

유니티는 자체 게임 엔진으로 UI를 띄우고 있기 때문에, 게임이 아닌 기본 앱 UI로 사용하려 하면 스크롤이나 페이지 전환 등에서 상당한 어색함이 느껴진다. 우리 팀이 만들고 있던 서비스는 본디와 비슷한, 아바타를 활용한 메신저, SNS 서비스였기에 친구 목록, 채팅방 등의 UI는 기본 앱 UI여야 했고, 아바타와 3D world 부분만 유니티로 구현하면 되었다. 하지만 앱의 모든 부분이 유니티로 구현되어 있어 앱 UI인 부분이 유저 입장에서 매끄럽지 않고 어색하다는 본질적인 문제가 있었다. 그래서 당시 PO님과 회식하며 앱 UI는 iOS 네이티브로 하고, 앱 내에 3D가 필요한 부분들만 유니티를 통합하는 게 어떻겠냐는 아이디어를 넌지시 던졌다. 며칠 지나지 않아 PO님은 유니티, iOS 하이브리드로 개발하자는 의사결정을 내리셨고, 이렇게 하이브리드로 개발하는 선례가 많지 않던 시기라 뷰 전환 시스템, 데이터 전송 시스템 등 구조를 모두 처음부터 구상하고 구현해야 했다.

 

내 몇 개의 블로그 글에서 이 문제를 해결하기 위한 싸움을 어느 정도 엿볼 수 있다.

 

Unity에서 Swift 코드 쓰기 & iOS native API 사용하기 (feat. HealthKit)

[iOS+Unity] 유니티 뷰 위에 Native iOS UI 얹고 효율적으로 관리하기

[iOS+Unity] iOS와 유니티 사이에 데이터 주고 받기 (Swift로 구현된 iOS + Unity as a Library에서)

 

그렇게 다시 나는 iOS 개발을 하게 되었다.

솔직히 너무 재밌었다. 아무도 가지 않았던, (적어도 인터넷에 자료가 많지 않았던) 유니티와 iOS를 통합해 하나의 견고한 서비스를 만들어내는 기술적 챌린지, 그리고 내가 좋아했던 iOS 개발을 원없이 할 수 있는 것, 모두 정말 재밌었다.

브레이크가 고장난 8톤 트럭처럼 밤낮없이 개발했고, 다른 팀들이었다면 1년이 넘게 걸렸을 프로덕트를 3개월 남짓한 시간에 프로덕션 레벨까지 개발해 출시했다.

 

LLM 리서치, 개발

하지만 출시가 되고 얼마 지나지 않아 회사 내부 사정으로 그 사업이 접히고, 다른 사업에 집중해야 했다.

우리 회사는 AI 도메인의 회사였고, 갑자기 GPT 등의 LLM이 급부상하며 LLM을 조금 더 활용하는 비즈니스를 탐색해야 했던 것이다. 기술의 최전방에서 누구보다 빠르게 비즈니스 소구점을 찾아내고 PoC 하며 사람들의 니즈를 날카롭게 뚫어내야 하는 우리 팀 특성상 이제는 메타버스보다 LLM에 더 집중해야 했다.

언어모델을 공부하기 시작했다. 사실 학부 때 인공지능을 부전공 하기도 했고, 특히 NLP에 관심이 많아 졸업 프로젝트도 자연어 처리 관련 프로젝트를 했던지라 이 일도 내가 많은 흥미를 가지고 할 수 있었던 일이었다.

언어모델들이 어떤 원리로 응답을 뱉어내는지, api 레벨에서는 어떻게 파라미터들을 조정해줘야 하는지, 원하는 응답값을 얻기 위해 프롬프트에서는 어떤 기교들을 부려줘야 하는지, 에이전트를 어떻게 레이어링 하는 게 결과값의 퀄리티를 높일 수 있는지 등

새로운 기술이 나올 때마다 공부하고, 바로 코드로 적용해보며 이 기술을 활용해 어떤 비즈니스 임팩트를 만들어낼 수 있을지를 연구했다.

당시 AutoGPT, AgentGPT, SuperAGI, BabyAGI 등의 에이전트 기반 AGI 표방 오픈소스들을 팀원들과 샅샅이 뜯어보고 기여하기도 했다.

 

그 공부의 극히 일부가 이 글들에 담겨있다.

[Typescript] OpenAI의 ChatGPT API로 나만의 챗봇 만들어보기 Part. 1

[Typescript] OpenAI의 ChatGPT API로 나만의 챗봇 만들어보기 Part. 2

 

다양한 연구와 시도를 거듭하다 보니, LLM이 research assistant나 personal assistant로서의 기능을 유의미하게 수행할 수 있겠다는 잠정적 결론에 다다랐다. LLM으로 여러 단계의 Agent를 만들어 적절히 쌓으면 사람보다 빠른 속도로 많은 양의 정보를 탐색하고 결론을 제공하는 research assistant가 되고, 거기서 더 나아가 개인의 다양한 정보를 input으로 넣어주면 적절한 타이밍에 적절한 도움을 주는 personal assistant가 되겠다고 기대했던 것이다.

 

MacOS, LLM 개발

그래서 MacOS app으로 PoC 앱을 만들어 보기 시작했다. 맥 앱은 iOS 앱과 동일하게 swift로 개발할 수 있기에 빠르게 학습해서 개발할 수 있었다. 둘은 다른 프레임워크를 사용해야 했기 때문에, MacOS App 개발 프레임워크에 적응하는 아주 짧은 시간 정도만 필요했다.

그때부터 LLM에 요청을 넣은 후 응답을 받아내고, Vector DB에 저장하고, 그걸 프론트엔드에 적절하게 전달하는 백엔드 엔지니어로서의 일과 MacOS 앱개발자로서의 일을 병행하기 시작했다. 학생 때 친구들과 무수히 많은 사이드 프로젝트를 하며 프론트뿐만 아니라 zero-to-one, end-to-end 백엔드 경험도 어느 정도 있었던 상태였기에 가능했다.

 

사이드 프로젝트 개발 이야기는 아래 글에 담겨있다.

 

사이드 프로젝트에 미친 사람이 서비스 20개 만들면서 느낀 것들

 

백엔드 엔지니어

백엔드 직무 전환의 포문

그렇게 프론트/백 할 것 없이 정신없이 개발하고 있던 와중, 상위 조직장님께서 잠시 얘기 하자고 하셨다.

거두절미 하고 본인의 팀에 와서 백엔드 개발을 맡아줬으면 좋겠다고 하셨다. 우리 팀 백엔드 시니어 개발자 분이 개인적으로 밥도 사주시고 틈날 때마다 백엔드 기술 이것저것을 나한테 알려주시면서 내가 백엔드 개발자로 넘어오기를 설득하고 계셨던 터라 내가 백엔드 개발에 어느 정도 호의적으로 설득된 상태라는 게 조직장님들 사이에 공유가 된 듯 했다.

그러면서 그 팀을 리딩하고 계신 분이 지금껏 얼마나 큰 개발 성과를 내 온 대단한 개발자인지, 전 회사들에서 얼마나 많은 주니어들이 그 분 밑에서 일하려고 했는지, 그리고 거의 한 시간가량 그 팀에서 활용하고 있는 코틀린 스프링이 얼마나 섹시한 기술인지에 대한 강의(어필?)를 해주셨다.

마침, 스페셜리스트가 되지 못하고 끝없이 제너럴리스트만 되고 있던 내 커리어에 회의를 느끼던 중이라 거진 세 달에 거친 긴 고민 끝에 그 제안을 수락했다.

 

백엔드 직무 전환을 고민하며 했던 생각들

세 달 동안 어떤 고민들을 했냐면,

개발자로서 내가 그리는 이상적인 미래, 회사 내에서의 성과, 켜켜이 쌓여가는 내 커리어, 그리고 내가 장난삼아 말하고 다니는 "세상의 대부분의 CTO는 백엔드 출신이다, 어쩌면 기술의 정수는 백엔드에 있지 않을까"라는 말, 같은 것들을 고민했다.

 

가장 결정적이었던 생각부터 적어보자면,

프론트엔드 개발자가 시니어가 되었을 때의 모습이 내가 그리는 이상과 가깝지 않았다는 것이었다. 내가 그리는 이상은 백발의 개발자가 어린 개발자에게 진득한 지혜를 나눌 수 있는 모습이었다.

내가 3년 간 개발자로 일하면서, 그리고 회사의 다양한 시니어 개발자 분들과 이야기 하면서 느꼈던 것인데, 프론트엔드 개발은 끊임없이 바뀌는 기술을 따라가야 하고, 그 점은 시니어가 되도 바뀌지 않는다는 것이었다. 연차가 쌓여도 계속해서 새로운 기술을 공부해야 하고, 기술이 언제 바뀔지 모른다. 하지만 새로운 것을 배우는 건 주니어도 시니어 못지 않게 잘 하는 일이다. 오히려 나이가 어린 주니어가 더 잘할 때가 있다. 퇴근 후 지켜야 할 가정이 없을 확률이 높고, 양육해야 할 대상이 없을 확률이 높고, 그래서 기술 공부에 더 많은 시간을 할애할 수 있기 때문에. 프론트엔드는 기술이 내 안에 있는 게 아니라 (경험의 가치가 비교적 약하기에) 내 바깥에 존재하고 (새로운 기술이 계속 등장하기에), 나는 연차와 관계 없이, 끊임없이 그 바깥에 존재하는 기술을 내재화하는 일을 해야 할 것만 같았다. 백발의 개발자가 되었을 때까지 치열하게 새로운 기술을 머리에 넣는 모습은 내가 그리는 이상과 멀었다.

반면, 벡엔드 개발자는 처음에 배워야 할 것은 무지 많다. 정말 너무 너무 많다. 하지만 한 번 배워놓으면, 코어한 영역의 기술은 드라마틱하게 변화하지 않는다. 기술이 변화하는 속도보다 내가 많은 경험을 통해 더 좋은 아키텍처를 짜고, 사소한 결정의 순간들에 조금씩 더 나은 의사결정을 내리게 되는 속도가, 그렇게 하드스킬보다 소프트스킬이 발전하는 속도가 더 빠르다고 생각했다. 그저 패러다임의 흐름에 몸을 맡기고 내 경험의 영역에 연륜을 차곡차곡 쌓아 넣으면 된다. 한 마디로, 경험이 쌓였을 때의 가치가 백엔드 개발자일 때 더 높아 보였다.

 

또, 앞에서 잠깐 언급했듯, 나는 제너럴리스트의 길을 걸어왔다. Software Engineer라는 포지션으로, 비즈니스 임팩트를 내기 위한 수단으로서의 개발을 해왔다. 기술 자체를 공부하기 위한 개발의 경험이 상대적으로 부족했다. 그래서 잠시 동안은 스페셜리스트가 되고 싶다는 갈증을 느끼기 시작하던 차였다. 흔히 T자형 인재라고들 하는데, 나는 지금껏 ㅡ를 열심히 만들어 왔다면, 이제는 l를 파고 싶다는 일종의 로망을 가지게 된 것이다. 나는 기술 자체보다는 하나의 프로덕트를 만들어 가는 것에 훨씬 관심이 많았기 때문에, 궁극적으로는 제너럴리스트가 내 이상에 부합하지만, 한 사람이 제너럴리스트일 수만 있다면 속된 말로 잡부가 되고, 스페셜리스트가 될 수도 있으면서 선택에 따라 제너럴리스트가 될 수 있어야 비로소 진정한 제너럴리스트일 수 있다고 생각하게 되었다. 그래서 한 분야를 딱 찍고 몇 년 간 진득하게 공부해보겠다는 의사결정을 내렸고, 나를 설득하던 타 팀 조직장님의 말대로 정말 기술적으로 본받을 점이 많은 분 아래에서 그 과정을 밟을 수 있다면 나에게는 더할 나위 없이 좋은 기회라고 생각했다.

 

마지막으로, 장난삼아 얘기하고 다닌 것이긴 하지만, 내가 본 대부분의 CTO는 백엔드 출신이거나 적어도 백엔드 개발 경험이 있는 분들이었다. 내가 CTO가 되고 싶다는 이야기는 전혀 아니다. 오히려 그 반대에 가깝다. 나는 기술로도 인정 받는 프로덕트 오너가 되고 싶다. 다시 돌아가, 기술의 수장을 백엔드에서 많이 맡는다면, 어쩌면 내가 알지 못하는 기술의 정수가 백엔드에 있고, 백엔드를 공부하는 것 자체가 내 기술적 견문을 넓혀줄 수도 있지 않을까 하는 기대가 있었다.

 

그렇게 백엔드로 직무 전환을 하고, 그로부터 많은 시간이 흐르지 않아 카카오브레인이 카카오로 합병 되어 브레인 때에 비해 비교적 직무 전환이 자유롭지 못해지며 정식으로 백엔드 개발자가 되었다.

 

백엔드 개발자가 되고 나서 느낀 것들

그리고 1년 동안 백엔드 개발자로서 일하면서 느낀 것은, 기술의 정수는 백엔드를 공부하면서 만나게 되는 게 어느정도 맞는 것 같다는 생각이다. 적어도 내가 재밌어하고, 내가 동경하는 기술의 정수는 백엔드에 있었다.

프론트엔드를 하면서는 특정 깊이 아래로 내려가기 전까지 네트워크나 컴퓨터구조, OS와 같은 학부 때 배운 CS 지식을 활용할 기회가 비교적 적었다. 하지만 백엔드를 하려면 API 개발만 하게 되지 않는 이상 첫 날부터 이것들을 마주하게 된다. 다시 대학교재를 펼쳐보고, 그때 배웠는데 그게 뭐였지, 하면서 되짚어 가는 게 퍽 흥미로웠다.

 

여전히 공부해야 할 게 많다는 게 설레기도, 막막하기도 하지만, 단순히 기술을 공부하는 게 아니라 많은 지식과 경험을 쌓아가며 내가 좀 더 나은 기술적 의사결정을 내릴 수 있는 여지를 점차 만들어 내고 있다는 사실이 신나기도 한다.

 

너무 백엔드 예찬론자 같지만, 내 성격상 내가 현재 하고 있는 일을 정말 사랑하게 되는 사람이라 백엔드에 매우 호의적일 수밖에 없다.

몇년 후에 나는 다시 다른 기술을 예찬하고 있을 것이다.

 

스페셜리스트의 길을 걷게 되며 적어도 회사에서는 다른 기술을 다룰 기회들이 적어지고, 프로덕트 자체에 기여할 기회는 적어졌다는 게 조금 아쉽지만, 여전히 사이드 프로젝트를 하며 iOS 개발을 하고, 웹 프론트 개발을 하고, 그리고 백엔드는 더 잘해지고, 내가 만들고 싶은 서비스를 고민하고 사람들을 그 방향으로 이끌고, 또 누군가의 리드를 팔로우, 서포트 하는 일을 하고 있다.

 

앞으로 꿈꾸는 것

최근에 '개발'의 범주가 점차 넓어지고 그 경계가 흐려지고 있는 것 같다는 이야기를 친구들과 한 적이 있다.

AI가 발전하면서 다양한 기술을 다룰 수 있는 제너럴리스트가 AI를 등에 업고 더 큰 성공을 일궈낼 수도, 아니면 아예 반대로 스페셜리스트가 AI는 감히 손도 대지 못하는 깊이의 기술을 다루며 그 가치를 높일 수도 있다. 아무도 모른다. 둘 다일 수도 있다.

그러니, 어느 하나에 집착하지 않고 내가 생각하는 내가 즐길 수 있는 것, 그리고 내가 채워야 할 곳곳의 구멍들을 채우다 보면 언젠가 어떤 형태로든 건실한 한 명의 시니어가 되어 있지 않을까 기대한다. 꼭 시니어 '개발자'가 아니어도 된다. 비즈니스와 기술을 모두 잘 아는 시니어일 수도, 지혜로운 기술적 의사결정을 내리는 시니어일 수도, 효율적인 코드를 정말 깔끔하게 쓰는 시니어가 될 수도 있다.

 

어떤 형태든 언제나 함께 하는 누군가에게 영감이 될 수 있는 사람이었으면 좋겠다.