그럼에도 불구하고,

거의 3달 이상을 달려와서 그럴까... 순식간에 가을이 된 줄도 몰랐다.
어릴 때 자주 봤던 만화 드래곤볼이 생각난다. 그냥 "정신과 시간의 방"에 들어갔다 나온거 마냥 체감상 3달이 3년 같았다.

 
상황이 나를 만들었다기보단, 어떤 상황에 마주한들 나의 선택이 나를 만든다고 생각하며 사는게 내가 살아가는 방식이라 지금 이렇게 지칠 정도까지일까 싶다면 그것 마저도 내가 선택했으니 딱히 할말은 없다...
 
하늘이 무너진 것 마냥 멘탈이 가장 박살나던 시기는 8월 말이었다. 가족 문제로 본가에 좋지 않은 일이 있었어서 그 바쁘고 정신없는 와중에도 급하게 장남인 내가 챙기고 해결해야 했었다. 금요일 하루 급하게 연차내고 내려가서 내가 할 수 있는 일들을 다 했고, 마음 추스를 시간도 없이 월요일 새벽 첫 기차로 서울에 올라와 바로 출근까지 했던 강행군이었다. 그렇다고 내 개인적인 사정마저 티내봐야 무슨 소용일까?
 
나는 원래 불필요한 야근을 지양하는 편이지만, 최근 3개월은 피할 수 없었다. 평일에 수면 시간이 부족하다 보니 주말마다 점점 피폐해졌다. 그래도 “다음 주를 준비해야 한다”는 마음으로 주말에도 학습과 준비를 반복했다.
 
멀쩡한 사무실을 두고도 물리적인 제약 조건이 있어 판교 본사에 직접 가야하는 날들도 점점 늘어났었다. 이제와서 캘린더를 다시 보니 워킹데이 기준 8월은 총 6일, 9월은 풀로 편도 1시간 반을 이동해서 판교로 출퇴근을 하는 실정이었다.
 
이정도면 많이 지칠만 하다. 09 ~ 18을 넘어서 08 ~ 21을 하는 날들도 많았으니까. 그와중에 신세 한탄을 하기보단, 할 수 있는걸 최대한 다 해보고자 했다. 내가 부족한 사항들은 겪어보며 습득하고자 많이 노력했었고 잠이 들면서도 이슈 사항들이 생각나서 "왜 이게 안됐을까? 아침에 출근하면 저거부터 해보고 이슈처리 해보자" 같은 생각까지 할 정도로 몰입했었다.
 
이제 모든 사항들을 하나하나 다 정리했고 다음 주 빅이벤트 하나만 남아있는 상황인데, 그래도 숨 쉴 시간은 생겼다. 말도 안됐던 일정과 인력이었으나, 계획과 예상보다 일주일 가량 앞당겨서 준비 잘 했으니까 이젠 기도만 해야지...
 
꾹꾹 참다 중간중간 화나고 억울한 상황들도 분명히 존재했다. 우리 회사는 직급체계부터가 잘못되어있다보니 내가 달고있는 직급은 본사 기준 최소 7~8년차 이상이니 내부 실정을 알아달라는 것도 아니고 그 사람들이 알 수 있는 것도 아니다. 나 혼자서 모든 걸 다 하고 있는 상황에서 난이도도 상당히 높은데, 속도 또한 빨라야 하는 상황에서 "저 3년차 주니어니까 못하겠어요" 이딴 소리는 죽어도 하기 싫었다. 왠지 모르게 내 자존심이 상하기도 하고, 웃기지만 회사를 대표해서 업무를 하고 있는거나 다름없는 상황이었어서 안그래도 바쁘시고 힘드실 CTO님 어깨의 짐은 덜어드리고 싶었던게 엄청 컸다.
 
내가 소속된 DevOps 팀과는 별개로 이 프로덕트는 온전히 내가 처음부터 설계하고 개발했고 누가 해줄 수 없는 일들이다보니 리드하고 있는 내가 무너지면 곧, TF팀이 무너지는거나 다름 없다는 책임감으로 임했다. 제3자들에겐 왜 혼자서 다 하고 있냐는 질문들도 많이 받았다.
이에 대한 대답은 솔직하게 말하면, 몇 가지로 추릴 수 있을 것 같다.

• 이전 기술지원팀 해체 이후, 나를 포함한 5명은 각각 다른 팀으로 흩어졌다. 하지만 팀이 바뀌었다고 해서 TF팀으로 구성된 이 업무가 사라진 건 아니었고, 모두가 본래 팀의 일을 병행하며 여전히 이 프로젝트를 이어가야 했다. 회사 입장에서는 이 일만 계속 붙잡고 있는 게 이상해 보였고, 그런 관용을 허락하지 않는 분위기 속에서 결국 나는 TF 리드로서 이 업무를 끝까지 책임져야 했다.
  • 반대로 그렇게 바라보시는 분들이 이 일을 해주실수도 없잖아요...
• 솔직히 말해 실력과 태도의 문제도 있었다. 속도와 품질을 동시에 요구받는 상황에서, 본사와 직접 맞붙어 대화하며 이슈를 해결할 수 있는 사람은 드물었다. 아니 솔직히 없었다고 봐야했다.
• 개발뿐만 아니라 인프라, SRE, DB까지 아우르는 지식이 필요했고, 빠른 의사결정과 커뮤니케이션 능력이 절실했다.

이 사업의 규모와 더나아가 독자적인게 아닌 본사의 일부로 들어가는 신규 서비스라는 특징때문에 개발한 프로덕트의 파급력은 솔직히 아무도 예상할 수도 없었다.
덕분에 단순히 코드만 다루는 수준을 넘어, 전사 시스템 구조와 히스토리까지 꿰뚫어야 했다. 인프라, SRE, DB 전범위를 아울러야 하는 만큼, 이 프로덕트의 코드와 아키텍처를 전체적으로 이해하면서도 세부적인 부분까지 디테일하게 파악해야 했다. 쉽진 않았지만 배움은 많았다.
 
특히 협업하던 본사 담당자들은 각자의 영역에서 최고 수준의 전문가처럼 움직였고, 그들이 문제의 범위를 좁혀가며 해결하는 방식은 개발을 넘어 모든 영역에 통하는 “문제를 해결하는 힘”을 보여주었다. 규모가 큰 조직일수록 당연히 이렇게 구조가 잡히는 법이겠지만, 그 속에서 함께 일하며 가장 크게 배울 수 있었던 부분이었다. 아무리 바쁘고 정신없는 상황에서도, 문제가 발생하면 어디서부터 시작해 원인을 좁혀가야 하는지 명확히 보여주는 과정은 큰 인사이트였다.
 
다만 그들의 범위를 넘어서는 부분들은 결국 이 프로덕트를 실제로 개발하고 운영하는 내가 알고 있어야 했기에, 미처 몰랐던 부분이나 어렴풋이 알고 있던 것들을 직접 테스트하고 검증해가며 대응해야 했다. 덕분에 문제 해결 속도도 빨라지고, 시스템 안정성도 높아졌다. 이런 과정 자체는 만족스러웠다.
 
하지만 동시에 현타가 오기도 했다. 본사와 협업하면서 경험한 규모와 수준은 분명 배움의 기회였지만, 내가 아무리 노력해도 우리 회사나 TF팀, 그리고 각 구성원들이 쉽게 바뀌지 않는다는 현실 때문이다. 내가 다 같이 잘할 수 있도록 애써도 결국 변화하지 않는 환경 속에서 혼자 더 많은 걸 감당해야 하는 상황, 게다가 내게 더 많은걸 요구하는 구조, 그것이 가장 큰 한탄이자 아쉬움으로 남았다. (개발을 모른다고 생각될 정도의 몇몇 마인드들도 한몫한 것 같다.)
그간 사수없이 개발하던 상황이 늘 불만이었지만, 반대로 내가 남들보다 두 배로 노력해서 시니어가 되고 다 같이 잘할 수 있는 상황을 만들고자 너무 노력했었다보니 어쩌면 이젠 진절머리가 났을지도 모르겠다. 어쩌면 간절히 소망해도 되는 연차기도 하지만…
한 명의 스타 플레이어가 되는 것보다 fit이 맞는 동료가 옆에 얼마나 많은지, 그러한 동료들과 다 같이 잘할 수 있도록 기반을 다져주는 사람이 결국 잘하는 사람의 기준이라 생각했거든.
 
이 경험을 통해 나는 ‘일을 잘한다’는 것이 단순히 기술력만의 문제가 아니라는 걸 다시 배웠다. 이미 다들 떠나셨지만, 이전 개발실장님이나 FE팀 선배님들의 모습을 봐왔어서 이렇게 정신없는 시간속에서도 무조건 아래 사항들은 지키면서 일하려고 했다.

1. 사전에 준비하라
   케이스는 다양하게 잡되, 닥쳐서 대응하는 게 아니라 미리미리 준비해야 한다.
2. 히스토리를 남겨라
   혼자 일하는 게 아니다. 개발, SRE/DevOps, DBA 모두 함께 가야 한다. 그때그때 기록이 없으면 결국 같은 문제를 반복한다. 이슈가 생기면 누가 어떻게 대응할꺼야?
3. 글을 잘 써라
   가독성 있는 글을 쓰는 사람이 결국 일을 잘한다. 코드, PR, 업무 Task까지 명확히 정리하면, 본인도 까먹지 않고 리드할 수 있으며, 보는 사람도 빠르고 정확하게 이해한다. 특히 유관부서는 개발이나 이 프로덕트에 대해 모른다는 걸 명심해야 한다. 더 나아가 높은 위치의 사람일수록 시간이 더 없으시다. 그분들도 같이 일하려면 '개발만 잘하면 된다'는 건 착각이다.
   그리고 글을 잘 쓰는 사람은 코드도 결국 잘 작성한다. 글처럼 코드는 읽는 사람을 위한 언어다. 명확하고 간결하게 구조화된 글이 이해를 돕듯, 잘 짜인 코드는 동료 개발자와 미래의 나 자신이 빠르고 쉽게 이해할 수 있게 만든다. 글쓰기와 코딩은 별개가 아니라, 본질적으로 같은 힘을 요구한다.
4. 코드는 기억하라
   시간이 지났다고 내가 짠 코드를 모른다는 건 반성해야 한다. AI가 코드를 생성해 줄 수는 있지만, 그것이 곧 실력은 아니다.
5. 제때 공유하라
   이슈가 있든 없든, 작은 것이라도 제때 정리해서 공유해야 한다. 혼자 감당하기 힘들다면 반드시 도움을 구해야 한다. 민망하거나 어렵더라도 해야 한다.
6. 질문하고 요구하라
   모르는 사항, 공유되지 않은 정보가 있다면 담당자에게 계속 물어야 한다. 질문하는 사람이 결국 문제를 해결한다.

이제는 나도 앞으로의 길을 고민해야 할 시점인 것 같다. 개발이든 SRE/DevOps든, 어느 한쪽의 노선을 정해 깊이를 만들어가야 한다는 생각이 든다. 모든 걸 동시에 붙잡고 가는 방식은 분명 큰 성장을 안겨줬지만, 그만큼 지치기도 했고, 연차가 쌓여가는 지금 “이 길이 곧 내 퀄리티로 이어질까?”라고 묻는다면 선뜻 그렇다고 말하기 어렵다. 언젠가는 선택과 집중이 필요하다. 지금까지의 경험이 내 가능성을 넓혀주었다면, 앞으로는 그 넓어진 가능성 위에 제대로 된 전문성을 세워야 하지 않을까 싶다.
 
회사가 작고 조직 문화가 썩 건강하지 않다 보니, 나에 대한 평가와 평판이 좋다 해도 늘 의심할 수밖에 없었다. ‘내가 정말 잘하고 있는 걸까?’ 스스로 끊임없이 되뇌었다. 그런데 본사 개별 담당자들과 함께 일하면서 내 연차를 아시는 분들이 “이건 말도 안 되는 일정과 난이도라 아무나 할 수 없는 일인데도 잘 해결했다”, “정말 고생 많으셨다, 감사하다”는 말과 평가를 직접 해주시니, 이제서야 비로소 내가 어느 정도 수준에 와 있는지 체감할 수 있었다. 모든 상황을 알고있는 개발 팀원 한명은 심지어 내가 시니어인척 해도 어색하지도 않아서 저분들이 더 좋게 보시는것 같다고 하더라.
(아마 선임님 안계셨다면 저도 힘들었을 겁니다...^^; 실무레벨에선 처음으로 제 사수 같았어요. 진심입니다.)
 
그래서일까 어쩌면 나는 언제든 떠나도 이상하지 않을 사람일지 모른다. 하지만 아직은 남아야 할 이유가 몇 가지는 남았다고 생각되고, 그 개인적인 찝찝함을 풀어가는 과정을 발판 삼아 언젠가 더 큰 물에서 제대로 성장해보고 싶다. 그것이 지금 내게 남은 마지막 선택이고, 또 내가 원하는 길이다. 다들 미쳤다고 생각할테지만…