2025 회고: 멈추며 배운 선택과 기준

올해 가장 고민이 컸던 결정은 무엇이었나?

2025년의 가장 큰 결정은 육아휴직을 선택하고, 복직을 준비했다가 다시 휴직에 들어간 과정 전반이었다고 생각합니다. 이 결정은 단순히 개인의 커리어 선택이 아니라, 가족의 안정과 현실적인 여건을 함께 고려해야 하는 문제였습니다.

당시 배우자는 육아로 인한 스트레스와 우울이 누적된 상태였고, 아이의 어린이집 입소 역시 대기 순번이 밀려 기약하기 어려운 상황이었습니다. 마침 정부의 6+6 육아휴직 정책이 시행되며 일정 수준의 소득 공백을 감내할 수 있겠다는 판단이 가능해졌고, 회사 역시 연구원들의 퇴사와 이직으로 프로젝트가 축소되는 국면에 있었습니다. 이런 환경 속에서 회사 동료들의 배려를 바탕으로 육아휴직을 시작할 수 있었습니다.

육아휴직 이후의 시간은 예상과는 달랐습니다. 제가 육아를 전담하는 구조라기보다는, 지난 1년간 육아를 담당해 온 배우자의 계획과 리듬에 맞춰야 했고, 그 과정에서 적지 않은 시행착오가 있었습니다. 그럼에도 불구하고 아이가 매일 성장하고 변화하는 모습을 가까이서 지켜보며, 이전과는 다른 종류의 만족과 책임감을 느낄 수 있었습니다.

그러던 중 장모님의 갑작스러운 별세를 겪으면서, 삶에서 무엇을 남기고 어떤 흔적을 만들어가고 싶은지에 대해 깊이 고민하게 되었습니다. 그 계기로 개인 홈페이지를 직접 구축했고, 제 작업과 생각을 정리해 기록하기 시작했습니다. 동시에 AWS SAA 자격증을 준비하며, 기존과는 다른 학습 방식도 시도했습니다. 단순 암기나 반복 풀이가 아닌 오답 중심 정리와 문제–정답 구조화, 그리고 ChatGPT를 활용한 교차 검증을 통해 학습 효율을 높였고, 이 방식이 실제 시험에서도 충분히 효과적이라는 경험을 얻을 수 있었습니다.

이후 아이가 어린이집에 입소하면서 복직을 준비했고, 약 6개월 만에 다시 업무에 복귀했습니다. 다만 개인적인 사정으로 다시 육아휴직을 선택하게 되었고, 현재는 월 160만 원 수준의 지원금을 바탕으로 가계의 균형을 유지하며 생활을 이어가고 있습니다.

이 과정에서 자연스럽게 비용과 지속 가능성에 대한 기준도 다시 세우게 되었습니다. 통신비를 최소 요금제로 조정하고, 개인 프로젝트 운영 비용을 줄이기 위해 인프라를 재구성했습니다. 개인 홈페이지는 Cloudflare로 이전했고, 데이터 시각화 서비스인 Economins는 Vercel 기반으로 재배포해 고정 비용을 낮췄습니다. 모든 것을 줄이기보다는, 학습과 사고를 유지하는 데 필요하다고 판단한 최소한의 도구(ChatGPT)는 그대로 유지했습니다.

돌아보면 이 선택들은 모두 ‘완벽한 결정’이라기보다는, 그 시점에서 가장 지속 가능하다고 판단한 선택들이었습니다. 2025년은 빠르게 달려 나간 해라기보다는, 기준을 다시 세우고 방향을 정렬한 해였고, 그 과정에서 저는 기술뿐 아니라 판단과 책임의 무게를 다시 배우고 있다고 느끼고 있습니다.

시니어 개발자로서 더 중요하게 보게 된 가치

2025년을 지나며 시니어 개발자로서 가장 크게 달라진 인식은, “무엇을 더 개발했는가”보다 “어떤 상황에서 어떤 선택을 했는가”가 훨씬 중요해졌다는 점입니다.

LLM의 빠른 발전을 체감하면서, 시장에서 개발자에게 요구되는 역할 자체가 변하고 있다는 생각을 하게 되었습니다. 과거에는 새로운 아키텍처를 학습하고, 모르는 기술을 찾아 정리하는 것만으로도 충분한 경쟁력이 되었지만, 이제는 코드 생성과 정리, 보일러플레이트 구현까지 LLM이 상당 부분을 대체할 수 있는 단계에 이르렀다고 느꼈습니다. 실제로 LLM을 단순 참고용이 아니라 구현 단계와 코드 검토 단계에까지 활용해보며, 기술 산업의 최전선에 있다고 생각하면서도 정작 그 변화를 온전히 따라가고 있지는 않았다는 자각도 들었습니다.

이 문제의식을 바탕으로, 개인 프로젝트로 한국은행 통화정책방향 결정회의 회의록 요약 서비스를 직접 설계·구현했습니다. 기준금리 발표 이전에 공개되는 회의록을 대상으로, LLM API를 활용해 핵심 내용을 요약하는 서비스입니다. 로컬 환경에서 LLM을 직접 운영하는 방안도 검토했지만, 제한된 GPU 메모리와 소규모 파라미터 모델로는 대용량 문서 요약의 품질을 확보하기 어렵다고 판단했습니다. 대신 실시간성이 중요하지 않은 특성을 활용해 배치 기반 API를 선택했고, 비용과 품질 사이의 균형을 맞추는 방향으로 아키텍처를 구성했습니다.

이 경험을 통해 느낀 것은, 이제 “무엇을 더 만들었는가” 자체는 점점 덜 중요해지고 있다는 점입니다. 대신 특정 제약 조건 하에서 최적의 구조를 설계할 수 있는 능력, 장애나 이상 상황이 발생했을 때 원인을 빠르게 좁히고 대응할 수 있는 역량, 그리고 LLM이 만들어내는 결과물의 한계와 환각을 인지하고 이를 올바른 방향으로 보정할 수 있는 판단력이 훨씬 중요해졌다고 생각합니다.

흔히 말하는 T자형 인재의 관점에서도, 넓은 수평 축은 점점 LLM이 담당하게 될 가능성이 크다고 느낍니다. 그럴수록 사람은 더 뾰족한 전문성을 가져야 살아남을 수 있습니다. 그 뾰족함은 단순한 기술 나열이 아니라,

• 초당 10회 제한과 같은 정교한 Rate Limiter 설계와 성능 검증,
• 일 2천만 건 규모의 대량 데이터 처리와 운영 경험,

• 실제 서비스 환경에서의 AIOps 설계와 운영 안정화

  와 같은, 현실적인 운영 문제를 끝까지 책임지며 해결해 본 경험에서 만들어진다고 생각합니다.

2025년은 이러한 관점의 전환을 통해, 기술을 “잘 쓰는 사람”이 아니라 불확실한 환경에서도 지속 가능한 선택을 할 수 있는 엔지니어로 성장하고자 기준을 다시 세운 해였습니다.

2024년의 나는 ‘좋은 개발자’를 어떻게 정의했나

2024년까지 제가 생각한 좋은 개발자는 미시적인 문제 해결에 강한 개발자였습니다.

구체적으로는, 요구사항을 실무 관점에서 다시 해석하고, 기획·연구원과의 논의를 통해 그것이 실제로 해결해야 할 문제인지 점검한 뒤, 디자인·프론트엔드와 협업하며 구현까지 책임지는 역할을 잘 수행하는 사람을 좋은 개발자라고 정의했습니다.

즉, 요구사항의 맥락을 이해하고, 구현의 완성도를 높이며, 협업 과정에서 발생하는 마찰을 줄이는 능력이 핵심이라고 보았습니다.

이 관점은 실제 업무 환경에서는 분명 의미가 있었고, 팀 내에서는 성과로도 이어졌습니다. 다만 구직 시장에 직접 뛰어들어 보며, 이 정의가 외부에서는 평가되기 어렵다는 한계도 분명히 느끼게 되었습니다.

도메인이 다른 조직에서는 이런 문제 해결 방식이 잘 드러나지 않고, 정성적인 협업 역량이나 상황 맥락은 이력서나 짧은 면접 과정에서 충분히 전달되기 어렵다는 점을 체감했습니다.

이 경험을 통해, 시장이 요구하는 ‘좋은 개발자’는 조금 다른 지점에 있다는 생각을 하게 되었습니다. 미시적인 실행력도 여전히 중요하지만, 그보다 더 크게는 거시적인 관점에서의 문제 해결 능력이 평가의 기준이 된다는 점이었습니다.

예를 들어,

• 초당 10회 제한과 같은 Rate Limiter 설계와 검증,
• 내부 서비스 환경에서의 API Gateway 인증 및 권한 관리,
• 서비스 규모 확장에 따른 대용량 데이터 처리를 고려한 DB 설계,

• 파일 시스템, 스토리지 구조 등 운영 단계에서 필연적으로 발생하는 문제들을

  직접 겪어보았거나, 최소한 해결 전략을 설명할 수 있는지 여부가 더 중요하게 보인다는 것을 알게 되었습니다.

LLM은 이러한 문제들에 대해 빠르게 방향성을 제시할 수 있지만, 그 답변이 항상 올바르거나 현실적인 것은 아닙니다. 결과의 타당성을 검증하고, 할루시네이션을 구분하며, 상황에 맞는 선택지로 이끌어 나가기 위해서는 여전히 사람의 판단과 경험이 필요합니다.

이렇게 돌아보면, 2024년의 저는 ‘현장에서 잘 구현하는 개발자’를 좋은 개발자로 정의했다면, 지금은 시스템 전체를 바라보며 위험과 제약을 관리할 수 있는 개발자가 좋은 개발자라는 쪽으로 관점이 확장되었습니다.

가장 재미있었던 프로젝트는 무엇이었나

• economins/monetary-report : 한국은행 통화정책방향 결정회의 요약
• hyeonki-min.com : 개인 홈페이지
• tech.hyeonki-min.com : 개인 기술 블로그
• economins-sam : AWS Serverless ETL 프로젝트
• spring-labs : 스프링 기반 기술 구현 프로젝트
• news-bot : naver news api 기반 슬랙 봇

2025년에 가장 재미있었던 프로젝트들은 공통적으로 “지금 나에게 실제로 필요한 문제”에서 출발했다는 점이 인상 깊었습니다. 누군가에게 보여주기 위한 포트폴리오보다는, 삶의 맥락과 관심사에서 자연스럽게 시작된 프로젝트들이었고, 그만큼 끝까지 고민하고 개선할 수 있었습니다.

가장 대표적인 프로젝트는 economins/monetary-report입니다. 한국은행의 기준금리 발표에 앞서 진행되는 통화정책방향 결정회의의 회의록은 분량이 방대하지만, 경제 흐름을 이해하는 데 중요한 단서가 많이 담겨 있습니다. 이 자료의 핵심 맥락만 빠르게 파악할 수 있다면, 경제가 어떤 방향으로 움직이고 있는지 훨씬 쉽게 읽을 수 있을 것이라는 문제의식에서 이 프로젝트를 시작했습니다.

이를 해결하기 위해 ChatGPT API를 활용한 회의록 요약 서비스를 설계했습니다. 실시간으로 제공할 필요는 없다고 판단했기 때문에 배치 기반 처리 구조를 선택했고, 이를 통해 운영 비용도 함께 고려했습니다. 로컬 환경에서 LLM을 직접 운영하는 방안도 검토했지만, 제한된 GPU 자원으로는 대용량 문서를 안정적인 품질로 요약하기 어렵다고 판단해 API 기반 접근이 더 현실적인 선택이라고 결론 내렸습니다.

이 프로젝트는 단순히 요약 기능을 구현하는 데서 그치지 않고, LLM을 실제 서비스 환경에서 어떤 조건과 제약 아래 활용하는 것이 합리적인지를 끝까지 고민해볼 수 있었던 경험이었습니다.

개인 홈페이지(hyeonki-min.com)와 기술 블로그(tech.hyeonki-min.com)는 기술 프로젝트라기보다, 스스로를 정리하는 도구에 가까웠습니다. 커리어, 프로젝트, 생각을 흩어진 형태가 아닌 하나의 흐름으로 정리하고 싶었고, 직접 설계·구현하며 인프라 비용, 배포 구조, 유지 관리까지 함께 고민했습니다. 특히 육아휴직 기간 동안 비용을 최소화해야 하는 상황에서, Cloudflare와 GitHub Pages 기반으로 인프라를 단순화하며 기술 선택이 곧 생활의 지속 가능성과 연결될 수 있다는 점을 체감했습니다.

economins-sam 프로젝트는 AWS Serverless 기반 ETL 구조를 실험한 프로젝트입니다. Lambda, S3, Event Bridge를 활용해 데이터 수집·변환·적재 흐름을 구성하며, 서버를 소유하지 않는 구조에서 운영 책임이 어떻게 이동하는지를 직접 경험할 수 있었습니다. 단순히 “서버리스”라는 키워드가 아니라, 언제 서버리스가 적합하고 언제 한계가 드러나는지를 체감한 점이 의미 있었습니다.

spring-labs는 스프링 기반 기술을 단순히 이론으로 아는 것이 아니라, 실제로 구현하고 검증하기 위한 실험 공간이었습니다. 인증, Rate Limiter, 트랜잭션 처리 등 운영 환경에서 자주 등장하지만 쉽게 추상화되는 주제들을 직접 코드로 구현해 보며, 프레임워크가 대신해주는 영역과 개발자가 책임져야 할 영역의 경계를 다시 확인할 수 있었습니다.

마지막으로 news-bot은 Naver News API를 활용한 Slack 봇 프로젝트로, 정보 수집과 전달의 자동화를 실험한 작업이었습니다. 단순 알림을 넘어, 어떤 정보가 팀이나 개인에게 의미 있는지, 노이즈를 줄이기 위해 어떤 기준이 필요한지를 고민하게 만든 프로젝트였습니다.

일과 삶의 균형에 대해 현실적으로 받아들이게 된 것

개발자는 끊임없이 배워야 한다는 말에 오랫동안 동의해 왔습니다. 기술 트렌드는 빠르게 변하고, 뒤처지지 않기 위해 계속 새로운 것을 따라가야 한다는 압박도 자연스럽게 받아들였습니다. 하지만 2025년을 지나며, 이 말이 모든 기술을 끝없이 좇아야 한다는 의미는 아니라는 점을 현실적으로 받아들이게 되었습니다.

모든 트렌드를 따라가는 일은 시간과 에너지 면에서 오래 지속하기 어렵다는 것도 분명해졌습니다. 특히 일과 삶의 경계가 분명해진 상황에서는 더더욱 그랬습니다. 대신, 본질적인 컴퓨터 사이언스 지식을 바탕으로 지금 내가 다루고 있는 서비스와 아키텍처에 실제로 필요한 영역을 골라 깊게 파는 방식이 훨씬 효율적이라는 결론에 이르렀습니다.

그래서 이제는 새로운 기술을 접할 때, “이걸 꼭 배워야 하나?”라는 질문보다 “이 기술이 지금 내가 설계하거나 운영하는 시스템의 문제를 정말로 해결해 줄 수 있을까?”를 먼저 묻게 됩니다. 그 질문에 스스로 납득할 만한 답이 있을 때만 시간을 쓰고, 그렇지 않은 경우에는 흐름을 이해하는 정도에서 멈추는 선택도 자연스럽게 하게 되었습니다.

이런 선택은 배움을 포기한 것이 아니라, 배움의 방향을 다시 정한 것에 가깝습니다. 한정된 시간 안에서 더 나은 판단을 하기 위해, 공부의 양보다 맥락과 연결성을 더 중요하게 보게 되었습니다. 그 덕분에 업무 외 시간에도 무리하게 스스로를 몰아붙이기보다는, 장기적으로 유지할 수 있는 리듬을 만들 수 있었습니다.

돌이켜보면 2025년을 지나며 제가 받아들인 일과 삶의 균형은, 일을 덜 하겠다는 선언이 아니라 무엇에 집중하고, 무엇은 내려놓을지에 대한 기준을 세우는 일에 가까웠습니다. 이 기준이 생긴 이후로, 배움과 삶 모두를 조금 더 오래 가져갈 수 있겠다는 확신도 함께 얻게 되었습니다.

올해 가장 값비싼 배움 - 시니어 개발자 구직 경험을 통해

2025년의 가장 값비싼 배움은, 시니어 개발자로서 구직 시장이 실제로 무엇을 기준으로 사람을 평가하는지 직접 확인했다는 점이었습니다. 약 30곳에 지원했고, 서류 전형을 통과한 곳은 3곳이었습니다. 숫자 자체보다도, 그 결과가 제게 던진 메시지가 더 오래 남았습니다.

그동안 저는 현장에서 맡아온 역할과 책임을 기준으로 스스로의 역량을 평가해 왔습니다. 문제를 해결하고, 시스템을 안정적으로 운영하며, 팀 안에서 신뢰를 쌓아온 경험은 분명 의미가 있다고 믿었습니다. 하지만 구직 과정을 거치며, 현장에서 쌓은 역량과 채용 단계에서 기대되는 역량 사이에는 분명한 차이가 존재한다는 사실을 인정하게 되었습니다.

이 경험으로 좌절하기보다는 방향을 다시 점검하게 되었습니다.이력서를 다시 쓰고 포트폴리오를 정리하면서, 단순히 ‘무엇을 해왔다’를 나열하는 방식으로는 충분하지 않다는 것을 느꼈습니다. 대신 왜 그 일을 했는지, 어떤 판단을 내렸는지, 그리고 무엇을 끝까지 책임졌는지를 설명할 수 있어야 한다는 점이 더 중요하게 다가왔습니다. 동시에, 커리어를 외부의 평가나 기회에만 맡기기보다는 스스로 설계하고 설명할 수 있어야 한다는 문제의식도 생겼습니다.

면접 과정에서의 대화는 또 다른 힌트를 주었습니다. 데이터 엔지니어링, MLOps, 자동화 경험이 이력서를 훨씬 입체적으로 보이게 만든다는 점을 체감했고, 이는 제가 앞으로 어떤 방향으로 역량을 쌓아가야 할지에 대한 힌트가 되었습니다. 단순히 기능을 구현하는 개발자가 아니라, 데이터의 흐름을 설계하고, 데이터 양과 특성에 맞게 변환·정제·저장 구조를 고민하며, 이를 자동화까지 연결할 수 있는 경험이 필요하다는 생각에 이르렀습니다.

돌아보면 2025년의 가장 큰 배움은, 부족함을 발견한 것이 아니라, 그 부족함을 기준 삼아 앞으로의 길을 다시 그려볼 수 있게 되었다는 점입니다.

내년의 나는 어떻게 일하고 싶은가

2026년의 저는, 외부 환경이나 당장의 역할 변화에 쉽게 흔들리기보다 스스로 설정한 커리어 방향을 기준으로 일하는 사람이고 싶습니다. 실제 업무가 그 방향과 완전히 일치하지 않더라도, 주어진 환경 안에서 필요한 역량을 차분히 쌓아가며 장기적인 목표를 향해 나아가고자 합니다.

기술적으로는 온프레미스 환경을 기반으로 한 문제 해결 경험을 계속 확장하되, 서비스의 확장성과 운영 효율을 함께 고려하며 항상 클라우드 기반의 대안을 염두에 두는 시각을 유지하고 싶습니다. 특정 환경이나 기술에 스스로를 가두기보다, 주어진 제약 조건 안에서 가장 합리적인 선택지를 설계할 수 있는 엔지니어로 일하고자 합니다.

또한 데이터 엔지니어링 역량을 장기적인 성장의 축으로 삼아, 규모가 크지 않더라도 토이 프로젝트를 지속하며 데이터 수집·처리·운영 전반을 직접 다뤄볼 계획입니다. 눈에 보이는 단기 성과보다는, 실제 운영 관점에서 쌓이는 경험을 더 중요하게 여기고 싶습니다.

무엇보다도 바쁘게 일하고 있다는 사실 자체를 성과로 착각하지 않는 것이 중요하다고 생각합니다. 그래서 내년에는 일의 속도보다 방향을 점검하기 위해, 스스로에게 다음과 같은 질문들을 반복해서 던지며 일하고자 합니다.

• 이게 정말 구현 방법을 몰라서 막힌 걸까, 아니면 지금 어떤 선택을 해야 할지 결정하지 못해서 멈춰 있는 걸까?
• 나는 지금 당장의 불편함을 없애는 데 급급한가, 아니면 조금 느리더라도 왜 이런 문제가 생겼는지부터 정리하고 있는가?
• 지금 이 상황에서 누군가는 해야 하지만 아무도 맡고 있지 않은 일을, 내가 대신 맡고 있는가?
• 지금 내가 하고 있는 일은 문제를 하나 줄이고 있는가, 아니면 단순히 해야 할 일을 처리하고 있는 것에 그치고 있는가?

이 질문들에 스스로 답할 수 있는 상태로 일하는 것, 그리고 제 선택과 행동을 스스로 설명할 수 있는 엔지니어로 남는 것이 2026년을 향해 제가 세운 목표입니다.