2025년 회고

스터디

알고리즘 스터디

올해는 알고리즘 스터디를 여러 개 진행했다.

알고리즘을 시간 내에 푸는 훈련을 매일 하며 남들이 어떻게 푸는지 보는 것도 나름의 의미가 있었지만, 가장 도움이 된 건 내가 왜 이 알고리즘을 선택했고 왜 이렇게 풀었는지 남에게 설명하는 능력이 늘어난 점이었다.

내가 암묵적으로 넘어가던 부분들을 다른 사람들이 질문했고, 그걸 말로 풀어내다 보니 면접이나 협업하는 상황에서도 내 코드의 의도를 더 잘 설명할 수 있어진 것 같다고 느낀다.

알고리즘 스터디지만 커뮤니케이션 스킬의 성장을 체감했다.

우먼잇츠스터디: 가상 면접 사례로 배우는 대규모 시스템 설계 영어면접 스터디

가상 면접 사례로 배우는 대규모 시스템 설계 책이 공부하고 싶기도 했고 영어면접 준비에도 관심이 있어서 두 가지를 동시에 하는 스터디에 들어갔다. 책의 주제별로 관련 경험이 있으신 분이 정리해온 이력서를 바탕으로 매주 영어 Mock System Interview를 진행했다. 나보다 경력이 많으시고 쟁쟁한 서비스 기업에서 다양한 경험을 하신 분들과 함께하다 보니 인사이트를 많이 얻었다. 특히 3~7년차쯤 되면 무엇을 질문하는지, 어떤 질문에 대비하는지가 보이기 시작했고 저연차인 나도 설계 선택의 근거(트레이드오프, 병목, 장애 대응)를 질문하며 사고의 기준을 확장할 수 있었다. 동시에 시니어들이 어떤 기준으로 설계를 설명하고 검증하는지도 관찰할 수 있었다. 그리고 무엇보다 다들 열심히 사시는 분들이다보니 만날 때마다 에너지를 얻고 동기부여가 되는 점도 좋았다.

SQL 스터디

SQL Booster라는 책으로 스터디를 진행했다. 책이 오라클 기반이기는 했지만 챕터 내용을 바탕으로 각자 회사에서 쓰는 PostgreSQL/MySQL/OracleDB에 맞게 변형해 적용하면서 쿼리 튜닝 사례를 공유했다. DB별로 동작 방식이 어떻게 다른지, 컨셉이 무엇인지 러프하게나마 잡히기 시작했고, 특히 인덱스가 왜 성능을 개선하는지, 복합 인덱스 설계 노하우, DB 내부 동작을 반복해서 같이 공부하면서 개념을 확실히 이해하고 넘어갈 수 있었던 게 좋았다. 실행 계획을 찍어보고 실제로 그렇게 동작하는지 확인하고, 인덱스가 정말 타는지도 검증하면서 SQL 실무의 기초 체력을 기를 수 있었다. 특히 복합 인덱스 설계 파트 발표를 내가 맡게 되었었는데 준비하면서 다른 사람에게 설명을 충분히 잘 할 수 있도록 개념을 다 이해하고 넘어가려고 공부하다보니 혼자서 공부할때보다 더 열심히 하게 되어서 좋았다. 인덱스에 대한 이해도가 엄청 올라가서 나중에 인덱스 구축할때도 많은 도움이 되었다. → 블로그 글 이렇게 스터디한 결과 회사에서 쿼리튜닝 및 인덱스 구축으로 DB 병목 장애를 해결해 실질적인 성과를 내는 데에도 상당한 도움이 되었다. 쿼리 비용을 58% 절감하고 실행 시간을 5시간에서 5분으로 줄인 이야기가 궁금하면 → 블로그 글

주니어 개발자가 반드시 알아야 할 실무 지식 스터디

회사 점심시간이 1시간 30분이라 밥을 빨리 먹고 동기들과 함께 진행했다.

1. 내가 무엇을 모르고 있는지를 뼈아프게 짚어줬다. SQL 스터디로 깊게 공부한 덕에 DB 파트는 너무 당연한 내용이 나와있었지만, 네트워크 등 경험이 부족한 영역은 내가 정말 모르고 있다는게 실감날 정도였다.
2. 실무에서 꼭 고려해야 하는 팁들이 사례로 정리되어 있어, 문제를 겪고 나서가 아니라 미리 방지하는 설계를 하는 사고방식에 도움이 됐다. 지금 읽고 있는 Release It!과 함께 운영 단계에서 생길 수 있는 문제를 예측하고 방지하는 감각을 키우는 데 도움이 될 것 같다.
3. “내가 여태까지 한 설계가 정말 잘한 일이었을까..?”를 시니어의 조언을 듣는 기분으로 다시 검토하게 됐다. 스터디원들과 책 내용만 스터디하는게 아닌 해당 챕터의 주제로 자유롭게 공부해와서 발표하기를 했는데, 나는 추가로 연관있는 내용 정리 혹은 관련있는 과거의 개발 경험이 계속 생각나서 그걸 더 찾아보고 되짚어보는 시간을 많이 가졌던 것 같다. 과거 채팅 시스템을 만들 때 나는 보안과 인증을 매우 빡빡하게 설계했는데, Slack/Discord 사례를 보며 보안이 중요한 실제 서비스 레벨에서도 하지 않는 수준의 보안과 성능 트레이드오프를 내가 선택했구나…를 깨달았다. 좋은 개발자는 보안이 70%로 중요한지 30%로 중요한지 가치 판단을 잘 하고 최적의 설계를 해내는 사람일 거란 생각이 들었다. → Github

내 개발적 사고의 지평을 넓혀주고 더 합리적인 의사결정을 하는데 도움을 준 굉장히 좋은 책이었다. 내가 주니어일때 이 책을 읽을 수 있어서 정말 운이 좋았다. 실무에서의 선택을 근거 기반으로 재점검하게 했고, 이후 설계 시 보안,성능,운영성 등 많은 요소를 함께 고려하게 되는 계기가 됐다.

토스 러너스 하이 2기

토스같은 회사에서는 어떤 가치를 중요하게 생각하는지, 어떤 방식으로 일하는지 엿볼 수 있어서 좋았다.

• 누가 시켜서 정해진 요구사항만 수행하는 게 아니라 스스로 기준을 세운다.
• 왜 이 일을 하는지, 실제로 무엇이 바뀌었는지를 끝까지 연결해 수치적 임팩트로 증명하고 다른 사람을 데이터로 설득할 수 있다.
• 제약 조건 안에서 최선의 해답을 찾는다.

인상깊었던 파트는 똑같은 업무, 똑같은 팀이지만 거기서 일하는 사람에 따라 그곳에서 하는 업무가 더 의미있게 만들 수 있고 같이 일하고 싶은 긍정적인 기운을 주게 진화시킬 수도 있다는 것이었다. 나 또한 그런 사람이 되려고 노력해 팀의 기준과 생산성을 끌어올리는 방식으로 기여해보고 싶다는 생각을 했다.

기존에는 회사에서 하는 일이 나의 미래 커리어에 어떤 식으로 도움이 될까를 주로 생각하며 일했었다. 토스 러너스 하이를 하며 내가 지금 회사에서 하는 일에서 어떻게 임팩트를 낼 수 있을지, 회사가 정말 필요로 하는 문제는 무엇인지를 고민하며 일을 하는 경험을 하게 되었다. 그 과정에서 일하는 태도 자체가 한 단계 성숙해졌다는 느낌을 받았다. 그리고 내가 하는 일을 더 잘 하려고 노력하는 과정이 역설적으로 내 능력 향상에 더 도움이 되고 다른 조직에 가서도 조직이 가장 필요로 하는 일을 파악하여 일을 잘 해내는 능력을 기르는 데에도 도움이 될 것이라고 느꼈다.

한 달간 가장 집중했던 것은 일하는 데에 가장 병목이 되고 가장 큰 ROI를 만드는 지점을 찾아 해결하는 것이었다. LLM 에이전트 개발 과정에서 반복되는 QA 부담, 느린 실험 속도라는 구조적 문제를 발견했고, 이를 자동화로 해결하는 데 집중했다.

개발하며 수행하는 테스트를 8시간에서 20분으로 바꾼 이야기 → Github

실무: 3번의 프로젝트, 3번의 성장

2025년에는 성격이 전혀 다른 세 개의 프로젝트를 거치며 폭넓은 경험을 할 수 있었다.

AI 보이스봇(KT 100번 고객센터) 고도화

작년부터 이어온 프로젝트의 오픈과 안정화를 맡았다. 특히 통계와 로깅 파트를 개발하며 OpenSearch를 다뤄볼 수 있었다. 특히 환경별로 상이했던 로그 구조를 표준화하고, 검색 인덱스 템플릿을 단일화하여 데이터 정합성 문제를 해결한 과정이 기억에 남는다. → 블로그 글

AI 스피커(GiGA Genie) 모델 생성 데이터 플랫폼

모델 학습용 데이터 파이프라인 운영 및 배치 스케줄링을 관리하기, 보안성 검토에 걸리는 코드들을 수정하는 것이 주된 업무라고 듣고 갔는데 가자마자 서버의 강제 OS 재설치/재구축이 진행되면서 매일같이 실전 장애대응 훈련을 하게 되었다. 리눅스에도 많이 친숙해질 수 있는 기회가 되었다. 컨테이너화되지 않은 환경에서 라이브러리 충돌과 버전 문제를 해결하는 과정이 쉽지는 않았지만, 덕분에 인프라의 중요성을 체감했다. 특히 DB 병목 장애 상황에서 쿼리 튜닝 및 인덱스 설정을 해 실행 시간을 5시간에서 5분으로 단축하는 값진 경험을 얻었다.

쿼리 비용을 58% 절감하고 실행 시간을 5시간에서 5분으로 줄인 이야기가 궁금하면 다음 링크로… 블로그 글

글로벌(Viettel) AI Speaker(Tammi) AI Agent 백엔드 개발

이 프로젝트에서는 날씨 에이전트를 혼자 전담하며 설계부터 구현까지 주도적으로 해볼 수 있었다. 에이전트 개발을 밑바닥부터 내 손으로 직접 해볼 수 있다는 점이 재미있었고, 엔지니어로서의 경험치를 늘릴 수 있었던 시간이었다. 영문 문서와 이슈 트래킹 중심으로 협업하며 글로벌 프로젝트의 개발 문화와 커뮤니케이션 방식을 경험할 수 있었다.

다단계 Fallback 로직 설계로 위치 인식 실패율 감소, LLM 데이터 전처리를 통한 토큰 비용 99.5% 절감, 리그레션 테스트 자동화로 검증 리소스 95.8% 절감 등 수치화된 임팩트를 냈다.

LLM 에이전트 리그레션 테스트 자동화 파이프라인 구축이 궁금하면 여기로… → Github

첫 회사 성과평가

비상 인력처럼 뛰어다니며 프로젝트 수습과 장애 대응에 쏟은 에너지에 비해 낮은 평가 결과가 나왔다. 역량 평가는 높게 받았지만 성과 평가가 기대보다 낮아 당황스러웠다. 그래서 왜 성과가 저렇게 나왔는지 내가 무엇을 놓쳤는지 고민하게 되었다.

팀장님께 낮은 성과의 이유와 내년 개선 방향을 여쭤보니 팀장님이 내가 무엇을 하는지 가시적으로 알기 어려웠던 점(다른 팀에 가서 일을 했다), 그리고 성과를 조직 내에서 공유하거나 가시화하는 과정이 부족해 상위의 의사결정자분들에게 이름이 오르내리지 못한 점을 요인으로 꼽았다.

특정 서비스를 장기적으로 책임지는 역할을 맡지 못했고 공식적인 공유 구조 안에서 성과를 축적하지 못한 점이 평가에 영향을 준 것으로 보인다. 여러 프로젝트를 오가며 일한 것도 가시성을 낮춘 요인이었던 것 같다. 원래 팀의 고도화 개발 인력이 이직해서 그 포지션으로 입사했다. 이후 고도화 프로젝트가 끝나니 내 포지션이 애매해졌다. 개발이 하고싶다는 지속적인 의지를 보여 다른 개발 프로젝트들에 투입되었는데 그 결과 성과를 온전히 인정받기에는 구조적 공백이 존재했던 것 같다. 담당 프로젝트가 바뀌며 다른 팀에 가서 일을 하게 되었는데 지금 일하는 팀에서도 그 팀 소속이 아니니 주간보고의 프로젝트에 내 이름이 같이 올라가지 않았고 원래 팀의 프로젝트가 아니니 원래 팀에서도 같이 보고되지 않았다(팀장님께만 목요일마다 무슨 일을 했는지 보고드렸음). 당시에는 조직에서 성과를 인정받는 역할을 맡는 것이 중요하다는 점을 잘 모르고 주니어일때 개발자로서 문제를 직접 해결하는 경험을 더 많이 쌓고 싶어 개발할 수 있는 곳에 갈 기회가 생겼을 때 흔쾌히 가겠다고 했다.

이런 경험을 통해 중요한 사실을 깨달았다. 혼자 조용히 깊게 고민하며 일하는 것보다 내가 낸 임팩트를 조직의 언어로 가시화하고 동료들에게 알리는 과정이 중요하다는 점이다. 그리고 열심히 일하는 것과는 별개로 조직 안에서의 내 확실한 포지션을 굳혀야 한다는 생각도 했다. 프로젝트를 이동하며 발생한 성과의 공백을 메우기 위해, 단순히 기술적 완결성에 매몰될 것이 아니라 내 업무가 조직의 목표에 어떻게 기여했는지 더 적극적으로 소통하고 어필했어야 했다는 반성을 했다. 이번 경험으로 기술 실력뿐만 아니라 자신의 가치를 증명하고 설득하는 능력 또한 중요한 덕목임을 깨달을 수 있었다.

2025 깨달은 점

루틴은 심플하게

2025년에는 5가지의 책을 병렬학습하면 내가 더 빨리 성장할 것 같아 백엔드 개발자에게 필요한 모든 분야를 동시에 발전시키고 싶은 욕심이 있었다. 요일별로 어떤 것을 몇시간동안 공부할지 모두 계획을 세워두었다. 그러나 회사는 매일 주어진 시간에 끝나지 않았고… 예상치 못한 야근이 생겨서 해당 요일의 책 공부할 시간이 빠지거나 하면 스트레스를 받고 진도 관리도 잘 되지 않았다. 과도한 병렬 학습 계획으로 인해 계획을 달성하는 즐거움보다 계획이 어긋나는 좌절만 겪다보니 동기부여에 전혀 도움이 되지 않아 전략을 수정했다. 장기 플랜 및 여러 개 병행보다 한 달 단위의 매일 실행 가능한 최소 루틴이 나에게 더 효과적이었다.

• 코테 하나 풀기
• 아이엘츠 문제 하나 풀기
• 한 달에 한 권의 책을 읽기
• 한 달에 릴리즈할 사이드프로젝트 기능 범위 정하고 구현

성과는 눈에 보이게

조금씩이라도 성장하고 있다는 것은 체감되지만 블로그, 깃허브, 링크드인에 정리할 여유 없이 흘려보내다 보니 외부에는 전혀 어필되지 않겠다는 생각을 했다. 2026년에는 블로그 정리, 자격증 취득, 사이드 프로젝트 런칭 등 내 성장을 외부에서도 확인할 수 있는 지표로 남기는 데 집중할 것이다. 단순히 나름 열심히 했다는 주관적 느낌이 아니라, 어떤 임팩트를 냈는지 명확히 짚어낼 수 있는 한 해를 만들고 싶다.

협업은 이상과 타협의 균형

올해는 동료들과의 협업을 통해 적정 기술에 대한 감각을 익혔다. 사이드 프로젝트나 실무에서 내가 생각하는 최선의 설계(성능)가 팀의 실행 속도와 맞지 않는 순간들이 있었다. 처음에는 조직의 의견에 따르면서도 더 좋은 설계를 놓치는 것 같아 아쉬웠지만, 지금은 조직의 상황과 리소스에 맞춰 몰입의 정도를 조절하는 법을 배우는 과정이라고 생각한다.

동료들과 보조를 맞추되, 내가 지키고 싶은 엔지니어링 가치는 데이터와 임팩트로 설득하는 태도를 갖추려 노력 중이다. 단순히 “이게 더 성능이 좋다”라고 말하기보다, 성능 개선 폭을 수치로 제시하고 투입되는 노력 대비 효과(ROI)까지 계산해 설명했더라면 논의의 결과도 달라졌을 수 있겠다는 생각이 나중에서야 들었다. 이후에는 기술적 우수성뿐 아니라 조직의 의사결정에 바로 활용할 수 있는 근거를 함께 제시하는 방향으로 소통 방식을 바꾸고 있다.