2025년 회고

들어가며

오랜만에 또 회고 글로 돌아오게 되었습니다. 작년엔 회고 글을 써야겠다는 생각도 못했던 것 같고, 그 정도로 한 치 앞을 예측하기 어려운 변화무쌍한 순간이 계속되었던 것 같습니다.

작년 2024 연말 평가 시즌, 본인 평가를 쓰면서 스스로 했던 생각은 “아, 좀 쉬어야 될 것 같아” 였던 것 같습니다.

그리고, 올해가 되어 지금 생각도 작년과 같네요. 2024년의 기억을 조금씩 엿보면서 2025년 회고를 써보려고 합니다.

진짜 휴식은 어떤 것일까?

1월에는 2024년 잔여 연차를 좀 연달아 사용했었습니다. 1월 13일부터 2월 2일까지 쭉 연차를 썼던 것 같아요.

쉬면서 여행이라도 다녀왔냐? 하면 그것도 아니었습니다. 여행을 가는 것에 드는 비용과 시간이 아깝다는 생각도 있었고, 제게 있어서 아직 여행이라는 것은 휴식의 개념은 아닌 것 같습니다. 여행을 간다 하더라도 느끼고 배울 수 있는 무언가를 설계하고 가야할 것 같은 압박이 다소 있거든요.

그래서 그냥 집에서 사이드 프로젝트를 했습니다. 당시 저희 팀원들끼리 박용우 선생님의 스위치온 다이어트(지금은 상표권 관련 분쟁이 있었던 것인지 마이옵티멀 다이어트가 되었더라구요)를 함께 했었는데 해당 스케줄을 도와줄 수 있는 앱을 만들어보면 어떨까란 생각이 들어 Flutter로 프로젝트를 세팅하고, 간단한 일정 관리만 할 수 있도록 MVP를 구성해서 개발했었습니다.

회사에서는 주로 백엔드 개발만 맡아서 하다 보니, 기획부터 디자인, 개발, 마케팅, 지표 분석 등을 어떻게 해볼 수 있을까란 생각에 잔뜩 들떠서 꽤 즐겁게 시간을 보냈던 것 같습니다. 꽤 열심히 했음에도 불구하고 클라이언트 개발(Flutter)에서 상태 관리나 로컬 데이터베이스 관리 그리고 배포 세팅, 앱스토어 심사 등의 장벽에 가로막혀 결국 완성해서 출시하지는 못했습니다.

그럼에도 불구하고 대략 3주간 몰입해서 제품을 혼자 만드는 경험은 분명 특별했던 것 같습니다. 회사에서는 적극적인 커뮤니케이션, 데일리 미팅을 통한 동기화 등 애자일 방법론을 좋아하는 것을 표방하고 있지만 사실 생각보다 저는 훨씬 더 많이 내향인이거든요. 제 자신과 대화하며 자료를 수집하고 모아서 무언가를 계속 키워나가는 것이 즐거웠던 것 같습니다. 복귀 이후 누군가 “휴가 때 뭐하셨어요?”라고 물어보시면 “개..발..이요… ㅎㅎㅎ;;“라고 대답해야 하는 부분이 있긴 했지만 뭐랄까 “나 다움”을 찾는 시간과도 같았던 것 같습니다. 모든 현대 사회인들이 유사하겠지만 집단과 조직에서는 자신을 조금은 깎아내고 전체의 이익을 위해 희생하고 헌신해야 하는 부분이 있을 것인데 그 부분에 있어 내 맘대로 일을 해보는 기간이 제게 주는 의미와 감성이 있었던 것이 아닐까 합니다.

감성적인 부분을 제하고도 배운 점이 있었는데요, 제가 회사에서 배울 것이 아직 더 많이 남았다는 점이었습니다. 당시 인디해킹에 관심이 많이 생겨 퇴사하고 개인 앱이나 SaaS를 개발하는 것에 대한 꿈이 조금은 있었거든요. 그런데 혼자 앱을 개발해보니 FE, BE 개발 조금 할 수 있는 것과 제품을 만드는 것은 완전 다른 차원이라는 생각이 들었습니다. 이 전체 라이프사이클을 이해하고 각 단계에서 필요한 것들을 배우기 위해선 아무래도 IT 서비스를 활용해 사업을 영위하는 기업체로부터 배울 것이 더 많겠다는 생각을 했습니다. 비단 기획부터 디자인, 그리고 개발과 이후 데이터 분석을 통한 인사이트와 다시 그것이 제품에 미치는 영향까지 전체 그림을 더 잘 볼 수 있도록 조금이라도 더 관심을 가져봐야지라고 생각하게 된 것 같습니다.

그래서 진짜 휴식은 어떤 것일까요? 뭐랄까, 요즘 드는 생각은 나를 찾는 시간과 경험이 휴식이 아닌가 하는 것입니다. 지금은 일본이나 대만 등지의 여행과 한 달 사이드 프로젝트 하기 중 고르라고 하면 여행을 고를 것 같은데요, 당시 조직 개편 이후 새로운 업무 환경에서 1년을 보낸 저에겐 한 달 사이드 프로젝트가 좀 더 휴식에 가까웠던 것 같거든요.

멀리 가려면 함께 가라

동명의 책을 읽어본 적은 없지만, 정말 유명한 말이죠. 그리고 제게는 너무 지키기 어려운 말이기도 합니다. 멀리 가려면 함께 하라는 말은 아름다워 보이지만, 그 사이에 해결해야 하는 수많은 문제들이 작아 보이게 포장한다는 생각을 종종 했기 때문입니다.

그럼에도 불구하고 올 해 제 회사 생활에 있어 가장 마음에 담아 두고 살았던 말은 다름 아닌 “멀리 가려면 함께 가라”는 말이었습니다. 사실 올 해 제가 해야 한다고 강하게 추진한 프로젝트들의 목적은 이 부분이 가장 주된 이유였을 정도입니다.

2023년에 개발한 이후 큰 틀의 구조적 변경 없이 유지해오던 홈 서버 프로젝트의 DB를 MongoDB로 이관한 것, 그리고 종국엔 아예 홈의 구조 전체를 갈아 엎은 것이 그 예시인데요. 2025년 조직의 방향성을 공유받았을 때 처음 했던 생각이 기존 홈의 코드로는 대응하기엔 어려운 부분이 많겠다는 것이었습니다. 이것을 대응하기 위해선 새로 함께 하게 된 홈 개발자분들에게 기존 히스토리를 최대한 빠르게 전파하면서도 직관적이지 않은 부분을 풀어내야 겠다는 생각이 들었습니다.

고심 끝에 선택한 첫 해결책이 일단 홈 서버의 DB를 MySQL에서 MongoDB로 이관하는 것이었습니다. ObjectMapper 기반으로 매핑해오던 JSON 컬럼들을 적절하게 Document로 저장하고 복잡하게 추상 클래스 기반으로 공통화 되어 있던 구조를 풀어내는 작업이었는데요. 다른 개발자 분들에게 홈의 전체적인 로직을 분담해서 재구현하는 부분을 부탁드리고 저는 주로 어드민 개발 작업을 진행하는 형태로 프로젝트를 진행했습니다. MongoDB라는 러닝 커브가 있었고 다소 독단적인 선택으로 진행되기도 했지만, 그럼에도 MongoDB의 유연성 획득 그리고 무엇보다 함께 하는 팀원들이 홈 서버에 대한 이해도를 빠르게 높이는 데에 큰 도움이 되었다고 생각했습니다.

이후에는 바로 네이티브 클라이언트의 API 스펙을 개선하는 과제를 진행하려고 했습니다. 기존 API 스펙으로는 도저히 2025년 앞으로의 과제를 효율적으로 받아낼 수 없겠다는 생각이 들었기 때문입니다. 개선 방향을 논의해보던 중 내부적인 논의와 상위 의사 결정으로 인해 네이티브 클라이언트 홈을 FE 기반의 홈으로 개편하는 것으로 결정되어 FE 홈 개편 프로젝트를 진행하게 됐습니다.

사실 네이티브 클라이언트나 FE나 저의 마음가짐은 비슷했습니다. 오히려 제게는 여러 조직 개편으로 히스토리 파악만으로도 큰 허들을 느끼고 있는 ‘홈’ 팀 전체에 있어 모두가 홈의 기능적 부분에 대해서만이라도 빠르게 이해할 수 있는 기회가 될 것이라고 생각했기 때문입니다. 프로젝트를 진행하며 주 2회의 퀵싱크 미팅, 격주로 진행하는 “좀 긴 싱크” 미팅을 셋업해 빠르게 서로의 현황을 파악할 수 있게 했고, 기능 히스토리를 혼자만 알고 있는 제가 최대한 기존 기획 스펙 시트를 설명하면서도 최신 스펙들을 별도 문서로 정리하여 PM분들께 전달해 개발과 기획 사이의 다리 같은 역할이 될 수 있도록 많은 노력을 했던 것 같습니다. 이외에도 API 전체 구조를 설계한다거나, 데이터 분석에 도움이 될 수 있도록 ID 체계를 정리하고 ETL 타임라인 등을 설정한다거나 등 많은 부분에서 좀 앞장서서 프로젝트를 진행해보는 경험을 많이 했던 것 같습니다.

물론 그럼에도 직무가 개발자라는 점과 결국 프로덕트에 대한 코어 오너십은 PM이 가져야 한다는 암묵적인 룰이 있었기 때문에 제가 프로젝트 매니징을 한다거나 아니면 기획을 정리하는 것에 대해 주변에서 우려의 시선을 받기도 했습니다. 그 부분을 무시할 수 없었기 때문에 프로젝트 매니징은 당시 PjM 역할을 하시던 분께 지원을 부탁드렸고, 실제 프로젝트의 오너십도 스펙이 정리되기 시작하는 시점에 PM분께 넘겨드리는 방향으로 진행했습니다.

지금 와서 생각해보면 이래도 됐나라는 생각이 많이 드는 것 같습니다. 기능 과제가 준비되어 들어오는 시점에 DB 자체를 MongoDB로 바꿔버리는가 하면, 홈 FE 전환을 할 때엔 기획의 범주나 프로젝트 매니징 등의 업무 범위까지 넘나들며 업무를 진행했기 때문입니다. 멀리 가기 위해, 그리고 또 함께 가기 위해 한 나름의 선택이었음에도 불구하고 모두를 존중하며 함께 갈 수 있는 선택을 했는가에 대한 부분에는 스스로 의문이 많이 남기 때문입니다. 다소 독단적이면서도 구성원들에게 부담을 지우는 선택도 많이 했던 것 같고, 그 때문에 프로젝트 기간 동안 팀 전체가 야근도 많이 했던 것 같기도 합니다. (벌써부터 동료 평가가 조금은 두렵달까요?)

어떤 것이 맞는가에 대한 생각은 아직도 명확하지는 않지만, “갈아 넣어야 해” vs “쉬면서 해야 효율이 높아” 둘 중 하나에 답이 있다기 보단, 그 사이 어딘가에 답이 있다는 생각은 확실히 드는 것 같습니다. 나름의 명확한 기준을 찾을 수 있으면 좋겠네요.

프로젝트 취소의 아픔

홈을 FE로 성공적으로 전환한 이후 만보기를 활용한 과제를 진행하게 되었습니다. 기존의 대결 프로덕트를 종료하고 새로운 챌린지성 프로덕트를 출시하는 작업이었는데, 나름 프로덕트에 엣지 케이스도 많고 기존 코드가 워낙 레거시 코드이다 보니 그걸 파보는 것도 즐거웠습니다. 그런데 QA 진행을 하기도 이전에 만보기 프로덕트가 타 조직으로 이관될 것이라고 공유를 받았습니다. 해당 프로덕트를 포함하여 이관하는 방법도 있겠지만, 받아가시는 조직 입장에서 활용하실지에 대한 여부도 불투명하고, 그렇게 될 경우 QA 리소스를 아깝게 활용하는 경우가 될 수도 있을 것 같아 해당 프로젝트는 드랍하고 최대한 코드 정리만 하여 이관하게 되었습니다.

대략 한달 정도 많이 몰입해서 진행했던 과제이다 보니 함께 진행했던 팀원분과 함께 굉장히 시원섭섭한 기분이 들었던 것 같습니다. 또한 당시엔 이런 프로덕트 간 이동이 진행되고 있는 프로젝트가 있는 상황에서 발생하는 것이 아쉬운 의사결정으로 느껴지기도 했습니다.

그럼에도 불구하고 만보기 컨슈머 성능 개선이나 잠재적으로 장애로 이어질 수 있을 만한 부분들을 고쳐서 이관했다는 부분은 그래도 스스로 뿌듯하게 생각이 되기도 했습니다. 그러면서도 개발자로서 언제든지 다른 부서로 이관하더라도 부끄럽지 않은 코드를 작성하기 위해 앞으로도 꾸준히 노력해야겠다는 생각이 들기도 했던 것 같습니다.

인간 시대의 끝이 도래했다

스스로에 대한 회고를 인간의 관점에서 써보려고 노력함에도 불구하고 빼놓을 수가 없는 주제인 듯 합니다.

AI가 요 몇년새 눈부신 발전을 이룩하는 바람에 올 해 거의 매일, 매달 바쁘게 해당 소식을 따라가며 놀람의 박수만 치고 있습니다. 인간인 제 가치는 어디서 나오는 것일까 고민도 종종 하게 되지만, 솔직히 AI가 없던 시절에도 그것에 대한 의문을 명확히 설명해내지 못했기 때문에 명쾌하게 답을 내리지 못하는것 같기도 합니다.

무서우면서도 하나의 도구로서 이것을 활용할 수 있는 능력을 키워야 된다는 부분에는 확실히 동의가 됩니다. 그러면서도 “개발자”라는 틀 안에 스스로를 가두지 않아야겠다는 생각도 많이 하게 됩니다. 모 기업에서 활용한 적이 있는 Problem Solver라는 직무가 정말 언젠간은 생기지 않을까 싶은 생각도 드는 것 같습니다.

현재의 LLM도 정말 뛰어난 성과를 보여주고 있고 또한 인간들도 오개념을 기반으로 자체 할루시네이션을 하는 일은 비일비재해왔다고 생각합니다. 적어도 가까운 미래 동안은 LLM Agent를 동료 내지는 조수의 느낌으로 받아들이는 것이 어떨까 싶은 생각을 종종 합니다.

성장, 회사, 나

올해 성장라이팅이라는 용어가 인터넷 등지에서 종종 보였던 것 같습니다. 어떤 의미로 사용되는지는 맥락에 따라 항상 다르지만, 제가 주로 이 말을 들었을 때에는 “지속적으로 성장해야만 해!” 라는 그 사상 자체에 대한 가스라이팅의 맥락이 컸던 것 같습니다.

올 해 대학 동기들을 몇 번 만나 알게된 것이 제가 그 성장라이팅을 하는 사람이었다는 것입니다. 동기들은 같이 살던 시절 제가 항상 “무릇 개발자는 ~~해야 한다”라고 말했다고 저를 “무릇 개발자교”의 교주라고 하더라구요. 너무 웃겨서 한참을 웃었지만, 모임에서 집으로 돌아오면서는 그렇게 무릇 개발자는~을 외치던 나는 과연 잘 성장하고 있을까?라는 생각이 들었습니다. 위에 적은 많은 내용들에서 제가 어떤 사람이 되어가고 있는지 사실 모르겠거든요. 개발자로서 개발을 잘하는 개발자가 되는 방향성보다는 마치 개발 커뮤니케이터, 나쁘게 말하면 입개발자가 벌써 되어가는 것 같달까요. 고작 3년차 주제에 말이죠.

그런데 이것은 제가 선택한 저의 정체성이라기보단 회사라는 맥락에서 발현되는 제 정체성이라는 생각이 들었습니다. 회사의 조직이 프로덕트를 어떻게 성장시킬 것인가에 대한 고민이 메인에 깔려 있고, 개발자는 그 중에서 코딩을 잘 할 수 있는 사람이란 관점으로 존재하는 사람이라고 스스로 생각했기 때문입니다. 회사를 떼어 놓고 보면 저는 아직도 기술 그 자체에 대해 흥미가 많은 사람임에도 불구하고 회사에 가면 엔지니어링 내지는 임팩트의 관점에서 그 기술적 선택의 중요성이 조금은 낮아지기 때문에 일상에서 회사의 비율이 높아지면 높아질수록 오히려 기술로부터는 거리가 멀어지는 것 같다는 생각이 들었습니다.

정말 아이러니하죠. 제 직업은 IT 서비스에선 가장 기술에 가까운 개발자인데요. 그러면 회사에서 나의 업무 성향을 바꿔야 할까? 아니면 환경을 바꿔야 할까? 이것에 대한 답은 섣불리 내리지는 못할 것 같습니다. 솔직히 아직은 전혀 모르겠습니다. 나는 이미 이 조직에서 가치가 있는 사람인 것 같은데, 그러면 과연 조직적 맥락이 달라졌을 때에도 나는 가치 있는 사람일까? 내 가치는 어떻게 판단해야 할까? 스스로 나의 가치를 정의할 수 있는가? 와 같이 생각이 좀 빙빙 돌더라구요.

지금 내릴 수 있는 결론은 아직은 경험이 부족하기 때문에 판단하기 쉽지 않다는 것입니다. 제가 다른 회사를 많이 경험해본 것도 아니고, 사실 이런 경험들은 잘 공유되지도 않아서 간접적으로 경험하기도 어렵다고 생각하거든요. 그리고 설령 공개된다고 하더라도 백인백색인 이 세상에서 그것을 온전히 공감하기도 어려울 것 같구요.

스스로 어떤 선택을 내려야 할지 많은 고민이 되는 시점인 것 같기도 합니다. 다만 어떤 선택을 내렸을 때 그 결과로 후회가 되거나 아니면 힘든 시점이 오면 스스로 돌아보면서 내가 그 선택을 했던 이유를 다시 잘 상기할 수 있으면 좋겠습니다.

마치며

개인적인 총평으로는 애매한 2025년이었던 것 같습니다. 정말 열심히 했던 것 같은데, 막상 돌아보면 아쉬운 부분도 많고 또 너무 빨리 시간이 지나가버린 것 같다는 생각도 듭니다. 글로는 써낼 수 없는 더 많은 일과 복합적인 감정이 있었는데요, 앞으로는 더 많은 부분을 명확하게 글로 표현할 수 있길 기대해봅니다.

주변에서 연말 분위기가 많이 안난다는 이야기를 많이 듣습니다. 개인적으로는 한 해가 끝난 것처럼 느껴지지 않아서, 뭔가 매듭을 잘 못지은 것 같아서 더 그런 것 같기도 합니다. 내년에는 매듭을 잘 짓고 다음 단계로 또 뛰어 넘어갈 수 있었으면 좋겠습니다.

혹여 이 글을 읽어 주신 분들 모두 2026년 새해 복 많이 받으십시오. 2025년 고생 많으셨습니다.

끝.