2025 WONIZZ.LOG
안녕하세요. 정리하는 개발자 워니즈입니다. 매년 마지막 즈음이 되면 한 해를 마무리하며 회고 글을 하나씩 남기고 있습니다.
누군가에게 보여주기 위한 글이라기보다는, 나중에 다시 펼쳐보며 “그때의 나는 어떤 고민을 하고 있었을까”를 되짚어보기 위한 개인적인 기록에 가깝습니다. 올해도 어김없이, 그런 마음으로 이 글을 시작해보려 합니다.
올해를 한 문장으로 정리하자면,
“역할이 바뀌면서 시야가 바뀌었고, 시야가 바뀌면서 책임의 무게를 처음으로 실감한 해”였던 것 같습니다.
작년까지의 저는 여전히 손으로 만드는 사람에 가까웠다면, 올해의 저는 조금씩 판을 설계하고 기준을 만드는 사람으로 이동해갔던 한 해였습니다.
테크리드(TL) 역할을 맡게 되면서, 단순히 기술을 잘 아는 것만으로는 부족하고 왜 이 방향이어야 하는지, 이 선택이 조직과 서비스에 어떤 영향을 주는지를 끊임없이 설명하고 결정해야 하는 위치에 서게 되었습니다.
그 과정이 솔직히 말해 쉽지는 않았습니다. 조직 구조의 변화, 독립망 환경에서 사내 클라우드로의 이관,비용과 안정성, 속도 사이에서의 수많은 선택들, 그리고 사람과 프로세스 사이에서 생기는 미묘한 긴장감까지. 기술적인 난이도보다도 결정의 책임감이 체력과 멘탈을 더 소모시키던 해였던 것 같습니다.
그럼에도 불구하고, 돌아보면 “이건 분명 의미 있었다”고 말할 수 있는 장면들이 또렷하게 남아 있습니다.
- 독립된 네트워크 환경을 정리하고 사내 클라우드로 이관하며 비용과 운영 복잡도를 동시에 줄였던 경험
- Slack Bot 기반 예약 배포 프로세스를 설계하며 배포를 ‘사람의 기억’에서 ‘시스템의 신뢰’로 옮겼던 순간
- DORA Dashboard를 통해 막연했던 DevOps 성과를 숫자와 지표로 처음 마주했던 일
- k6 기반 성능 테스트 프로세스를 새로 설계하며 “안정성은 감이 아니라 연습의 결과”라는 걸 체감했던 경험
- SET 팀을 대상으로 Playwright 기초 교육을 진행하며 혼자 잘하는 것보다, 같이 기준을 맞추는 일이 더 중요하다는 걸 느꼈던 시간
- 그리고 Claude Code 기반 GitHub Actions를 만들며, AI를 ‘보조 도구’가 아니라 ‘업무 구조를 바꾸는 도구’로 처음 활용해본 시도
일적으로는 분명 많은 것들을 해냈고, 자동화·안정성·비용·가시화라는 키워드 위에서 꽤 단단한 결과들도 만들 수 있었습니다. 하지만 동시에, 이 모든 과정이 제 자신에게는 “나는 이제 어떤 엔지니어가 되어가고 있는가”를 끊임없이 묻게 만들었던 한 해이기도 했습니다.
이제부터는, 올해 제가 했던 일들과 그 안에서의 고민들을 하나씩 천천히 되짚어보려 합니다.
기술적인 성과뿐 아니라, 역할이 바뀌며 흔들렸던 생각들까지 함께 기록해두는 것이 미래의 저에게는 가장 의미 있는 회고가 될 것이라 믿으면서요.
1. 2025년에 목표 한 것은 다 이루었나요?
매년 회고를 하다 보면 가장 먼저 스스로에게 던지게 되는 질문이 있습니다.
“작년에 세웠던 목표들을, 올해의 나는 얼마나 이뤄냈을까?”
2024년 초에 적어두었던 목표들은 지금 다시 보니 지금의 저를 어느 정도 예견하고 있었던 것 같기도 합니다.
당시 적어두었던 목표는 아래와 같았습니다.
- 작은 조직 구성해보기(?)
- SRE 업무 영역 확장 및 업무 수행
- 강의 제작해보기 ( 사내 클래스 ? )
- 건강 챙기기, 가족과 시간 많이 보내기
- 취미 생활 유지하기 ( 골프 ? )
하나씩 솔직하게 돌아보겠습니다.
▪️ 작은 조직 구성해보기 → 어느 정도는 달성
“작은 조직을 직접 구성해보고 싶다”는 목표는 결과적으로 테크리드(TL) 역할을 맡게 되면서 일정 부분 대체되었다고 생각합니다.
정식 조직을 새로 만들지는 않았지만, 시니어 엔지니어들과 협업하는 구조 안에서 업무를 설계하고, 방향을 제시하고, 기준을 맞추는 역할을 수행하면서 ‘조직을 운영한다’는 감각을 처음으로 체감해볼 수 있었습니다.
다만 여전히 저는 강한 IC 성향을 가진 TL이고, 이 부분은 앞으로도 의식적으로 조절해나가야 할 영역이라고 느끼고 있습니다.
▪️ SRE 업무 영역 확장 → 분명히 달성
이 부분은 개인적으로 가장 만족도가 높은 목표였습니다.
- 로그 수집 체계 정비
- 배포 자동화 및 안정성 강화
- k6 기반 성능 테스트 자동화
- DORA Dashboard 구축을 통한 DevOps 메트릭 가시화
이 모든 것들이 단발성 작업이 아니라 SRE 관점에서 “지속 가능한 운영 체계”를 만드는 방향으로 이어졌다고 생각합니다.
“데브옵스가 열심히 하고 있다”가 아니라 “우리가 어느 지점에 와 있는지 숫자로 말할 수 있게 되었다”는 점에서 조직적으로도 의미 있는 변화였던 것 같습니다.
▪️ 강의 제작해보기 → 아쉽게도 미달성
이 목표는 솔직히 달성하지 못했습니다.
사내 클래스를 한 번쯤은 만들어보고 싶었지만, 업무 우선순위와 체력 문제로 인해 끝내 실행으로 옮기지는 못했습니다.
다만 하반기에 QA 팀을 대상으로 한 교육과 AI를 활용한 자료 제작 경험을 통해 “완전히 못 해본 목표는 아니었다”는 정도로 위안을 삼고 있습니다.
이 목표는 2025년으로 그대로 이월해도 좋을 것 같습니다.
▪️ 건강 챙기기 & 가족과 시간 보내기 → 의외로 가장 크게 달성
작년 회고를 쓸 때만 해도 이 목표는 늘 적어두지만 늘 부족하다고 느끼는 항목이었습니다.
그런데 올해는 조금 달랐습니다.
- 최근 –9kg 감량
- 재택근무 환경에서도 주말은 최대한 가족과 보내기
- 4월에는 오키나와 가족 여행
- 곧 첫째 아이에게 스키를 가르쳐볼 계획
돌아보면 여전히 일에 많은 시간을 쓰고 있지만, 적어도 “일만 하고 있는 상태”는 아니게 되었다는 점에서개인적으로는 꽤 큰 변화라고 느낍니다.
특히 재택근무임에도 불구하고 사무실에 있는 것보다 더 오래 자리에 앉아 일하고 있다는 자각이 들면서,이제는 의식적으로라도 몸과 일상을 챙겨야겠다는 생각을 하게 되었습니다.
1-2. 개인적인 취미 갖기
올해 회고를 하며 다시 느끼는 것은, 일만으로는 사람의 균형이 오래 유지되지 않는다는 사실이었습니다.
약 3개월 전부터 몸이 유독 무겁게 느껴졌고, “이 상태로 계속 가다가는 안 되겠다”는 생각이 들었습니다.
그래서 큰 결심이라기보다는,매일 할 수 있는 최소한의 루틴부터 만들기로 했습니다.
점심시간을 활용해
- 시티런 형태로 4~5km 런닝을 하고
- 이후 헬스장에서 2분할 루틴으로 대근육 위주 운동을 진행하고 있습니다.
처음에는 체중 감량이 목적이었지만, 지금은 오히려 하루의 리듬을 다시 잡는 시간에 가깝습니다.
현재까지 약 –9kg 감량을 했고, 앞으로 11kg 정도를 추가로 감량하는 것을 목표로 하고 있습니다.
이 목표는 단기간이 아니라,2026년까지 1년을 두고 천천히 가져가는 목표이기 때문에 현실적으로도 충분히 가능하다고 생각합니다.
운동을 하다 보니 자연스럽게 런닝화나 장비 같은 것들에도 관심이 생기기 시작했습니다. 무언가를 새로 “사야 할까 말까” 고민하는 이 과정마저도 요즘의 저에게는 꽤 즐거운 변화입니다.
무엇보다도 런닝이 마음에 드는 이유는, 제 성향과 아주 잘 맞는 취미라는 점입니다.
- 혼자 할 수 있고
- 정해진 규칙이 명확하고
- 성과가 숫자로 바로 드러나며
- 남과 비교하지 않아도 되는 활동
그래서인지 부담 없이 시작했지만, 지금은 앞으로 평생 가져가도 괜찮겠다는 생각이 드는 취미가 되었습니다.
일을 하면서도 늘 머릿속을 가득 채우던 생각들이 런닝 중에는 자연스럽게 정리되는 느낌이 들고, 몸이 단단해질수록 마음도 함께 단단해지고 있다는 걸 체감하고 있습니다.
이제는 “운동을 해야 한다”기보다는,이 루틴을 잃고 싶지 않다는 쪽에 더 가깝습니다.
월별 결산
4월 🌸 – 6월 ☀️
테크리드(TL)로의 역할 전환과 정렬의 시간
4월부터는 공식적으로 테크리드(TL) 역할을 맡게 되면서, 업무의 성격이 눈에 띄게 달라지기 시작했습니다. 직접 손으로 모든 것을 처리하기보다는, 함께 일하는 시니어 엔지니어 두 분이 가장 잘 움직일 수 있는 환경을 만드는 것이 저의 주요 역할이 되었습니다.
이 시기의 핵심 키워드는 조정과 정렬이었던 것 같습니다.
- 누가 어떤 영역을 책임지는지
- 데브옵스 팀이 조직 내에서 어떤 역할을 수행해야 하는지
- “지금 당장”이 아니라 “앞으로도 유지 가능한 방향”은 무엇인지
를 계속해서 고민하고, 문서화하고, 설명하는 시간이 많았습니다.
기술적인 성과가 눈에 확 띄는 시기는 아니었지만, 이 시기를 통해 ‘내가 잘하는 것’이 아니라 ‘팀이 잘 굴러가는 구조’를 의식적으로 만들기 시작했다는 점에서 개인적으로 의미가 컸습니다.
이후 진행되었던 대형 작업들(인프라 이관, 자동화, 메트릭 정비)이 큰 마찰 없이 진행될 수 있었던 것도,돌이켜보면 이 시기의 역할 정리와 방향 합의가 있었기 때문이라고 생각합니다.
7월 🌊 – 9월 🍂
인프라 이관, DevOps 가시화, 그리고 기준 만들기
7월부터 9월까지는 올해 전체를 통틀어 가장 밀도 높고, 가장 긴장감이 컸던 시기였습니다.
1) Kubernetes 클러스터 사내 클라우드 이관
가장 크게 기억에 남는 작업은 기존 별도의 IDC 환경에 구축되어 있던 Kubernetes 클러스터를 사내 클라우드로 이전하는 작업이었습니다.
- 수많은 유관 부서와의 협의
- 무중단 이관이라는 명확한 제약 조건
- 서비스 안정성과 비용 절감이라는 두 가지 목표
속에서, 이관 전략 수립 → 일정 계획 → 태스크 분해 → 역할 분배까지 전체 흐름을 설계하고 조율하는 역할을 맡았습니다.
직접 모든 작업을 수행하지는 않았지만, 시니어 엔지니어 분들이 혼란 없이 판단하고 실행할 수 있도록 가이드하는 것이 테크리드로서의 가장 중요한 역할이라는 걸 이 시기에 강하게 체감했습니다.
결과적으로 이관은 무사히 완료되었고, 현재는 운영 안정성과 함께 눈에 띄는 비용 절감 효과까지 이어지고 있습니다.
2) DORA Dashboard 구축 – DevOps를 숫자로 말하다
이 시기 또 하나의 중요한 작업은 DORA Dashboard 구축을 통한 DevOps 메트릭 가시화였습니다.
기존에도 빌드, 배포, 장애, 알림 등 다양한 데이터는 수집되고 있었지만 이것들이 하나의 흐름으로 “살아 움직이는 지표”처럼 보이진 않았습니다.
DORA 4대 지표를 중심으로 대시보드를 구성하면서,
- 서비스별 배포 빈도
- 변경 리드 타임
- 장애 복구 시간
- 변경 실패율
등이 한눈에 보이기 시작했고, 이를 통해 조직 내 DevOps 가속도가 어느 정도인지 가늠할 수 있는 기준점을 처음으로 만들 수 있었습니다. 물론 당시에 AI(Gemini CLI)를 통해서 Vibe Coding으로 만들었습니다. 이제는 누구나 손쉽게 아이디어만 있다면 원하는 형태의 결과물은 금방 제작할 수 있을 것 같다는 생각을 하게 됐습니다.
이제 DevOps는 “열심히 하고 있다”가 아니라 “어디까지 왔는지”를 이야기할 수 있는 영역이 되었습니다.
3) k6 성능 테스트 프로세스 도입
성능 테스트 영역에서도 큰 변화가 있었습니다.
기존에는 개발팀이 ngrinder를 통해 각자 필요할 때 성능 테스트를 수행하는 구조였다면, 이를 DevOps에서 제공하는 CI/CD 파이프라인과 자연스럽게 연결하고 싶었습니다.
- k6 기반 성능 테스트 도입
- CI 파이프라인 연계
- Datadog APM과의 연결
- DORA Dashboard 내 성능 탭 신설
을 통해, 성능 테스트 결과가 일회성으로 끝나는 것이 아니라 지속적으로 축적되고 비교 가능한 데이터로 남도록 설계했습니다.
이 역시 “테스트를 한다”보다 “우리가 얼마나 안정적인 방향으로 가고 있는지”를 보여주는 기준을
만드는 작업이었다고 생각합니다.
9월 🍁 – 12월 ❄️
AI 활용 실험에서 표준으로
하반기로 갈수록, 개인적으로는 AI를 어떻게 ‘잘 쓰는가’가 아니라 ‘업무 구조 안에 어떻게 녹여낼 것인가’에 대한 고민이 많아졌습니다.
1) 장애 관제 시나리오와 QA 팀 교육
이미 DevOps에서 구축해두었던 장애 관제 시스템을 기반으로, 시나리오 작성 영역을 QA 팀으로 이관하는 시도를 했습니다.
- 역할 분리
- 타 팀의 역량 강화
- DevOps의 과도한 책임 집중 해소
를 목표로, AI를 활용해 교육 자료를 생성하고 QA 팀 멤버들에게 직접 교육을 진행했습니다.
AI 덕분에 교육 준비 부담이 크게 줄었고, 저 역시 타 팀을 대상으로 기술을 설명하고 정리하는 경험을 처음으로 비교적 여유 있게 해볼 수 있었던 좋은 기회였습니다.
2) Claude Code GitHub Actions – AI를 표준으로 만들다
가장 의미 있었던 AI 활용 사례는 Claude Code GitHub Actions의 표준 설계 및 도입이었습니다.
사내에서 Claude Code를 사용하고는 있었지만, 이를 각 팀이 제각각 사용하는 것이 아니라 DevOps 관점에서 표준적인 GitHub Actions 형태로 제공하고자 했습니다.
- PR 리뷰 자동화
- 코드 변경 사항에 대한 상세 분석
- Blocking issue 사전 탐지
를 통해, 개발팀은 더 이상 PR 리뷰를 전적으로 사람에게 의존하지 않아도 되었고 코드 완성도와 안정성 측면에서 분명한 개선 효과를 얻을 수 있었습니다.
이 경험을 통해 AI는 단순한 생산성 도구를 넘어 팀의 일하는 방식을 바꾸는 인프라 요소가 될 수 있다는 확신을 갖게 되었고, 해당 내용은 추후 사내 테크 블로그에 정리할 예정입니다.
3. 2026년 목표는?
2025년을 바라보며 세운 목표들은, 무언가를 더 해내겠다는 욕심보다는 지금의 상태를 오래 유지할 수 있는 방향으로 정리하는 것에 가깝습니다.
우선 가장 중요한 목표는 테크리드(TL)로서의 역할을 보다 안정적으로 수행하는 것입니다. 여전히 실무를 좋아하고, 직접 손으로 만드는 일에서 성취감을 느끼지만 앞으로는 혼자서 모든 것을 끌고 가기보다는 팀 단위로 판단하고, 맡기고, 함께 결과를 만들어가는 방식에 조금 더 익숙해지고 싶습니다.
“내가 없으면 안 되는 구조”가 아니라 “내가 없어도 굴러가는 구조”를 만드는 것이 2025년의 중요한 기준이 될 것 같습니다.
또 하나의 목표는 그동안 쌓아온 경험과 고민들을 어떤 형태로든 정리해보는 것입니다. 사내 강의가 될 수도 있고, 조금 욕심을 낸다면 책이라는 형태일 수도 있겠지만, 중요한 것은 완성도보다는 처음으로 끝까지 만들어보는 경험 자체라고 생각합니다. 기술을 아는 사람에서, 기술을 설명하고 전달할 수 있는 사람으로한 단계 더 나아가고 싶습니다.
개인적인 목표도 분명히 세워두었습니다. 건강을 되찾는 일은 이제 부가적인 목표가 아니라 일을 지속하기 위한 전제 조건이 되었습니다. 현재까지 감량한 체중을 발판 삼아 앞으로 11kg 추가 감량을 목표로 하고 있으며, 이는 단기간이 아니라 2026년까지 이어지는 장기 목표로 가져갈 생각입니다. 꾸준히 달리고, 규칙적으로 운동하며 몸과 리듬을 지켜내는 것을 가장 우선에 두려고 합니다.
조금 더 느린 목표도 있습니다. 바쁜 와중에도 독서를 놓치지 않는 것, 속도를 줄이고 생각을 정리할 수 있는 시간을 의식적으로 만드는 것 역시 2025년에 꼭 지키고 싶은 목표 중 하나입니다. 성과를 내기 위해 읽는 것이 아니라, 시야를 넓히기 위해 읽는 독서를 해보고 싶습니다.
이 모든 목표를 한 문장으로 정리해보자면, 2026년은 더 빨리 가는 해가 아니라, 더 오래 갈 수 있는 방식을 연습하는 해가 되었으면 합니다. 혼자가 아니라 팀으로, 소모가 아니라 지속으로,성과만이 아니라 삶까지 함께 챙길 수 있는 방향으로 말입니다.
- 테크리드(TL)로서의 역할을 보다 안정적으로 수행
- 사내 강의 혹은 집필
- 건강 – 11kg 감량
- 독서 (생각하는 힘)
4. 마치며…
올해를 돌아보면, 기술적인 성장보다도 사람과 구조, 그리고 역할의 변화 앞에서 스스로를 다듬는 법을 배운 한 해였다고 느낍니다. 그 과정은 결코 매끄럽지 않았으며, 때로는 내가 선택한 길이 맞는지 스스로에게 끊임없이 질문해야 했던 시간이었습니다.
조직 안에서 저는 오랫동안 ‘잘하는 개인 기여자’로 살아왔습니다. 문제를 발견하면 직접 해결했고, 막히는 지점이 보이면 대신 뛰어들었습니다. 이 방식은 분명 빠르고 효율적이었지만, 역할이 바뀌기 시작하면서 한계를 드러내기 시작했습니다. 모든 것을 끌어안는 태도는 조직을 단단하게 만들기보다는, 오히려 특정 개인에게 의존하는 구조를 고착화시키고 있었습니다.
이 과정에서 저는 한 가지 중요한 사실을 깨달았습니다. 리더십이란 더 많이 하는 것이 아니라, 더 명확히 나누는 일이라는 점입니다. 방향과 기준은 제시하되, 실행과 책임까지 대신 짊어지는 순간 조직은 성장하지 않습니다. 누군가의 실패를 미리 막아주는 것이 배려처럼 보일 수 있지만, 그 실패를 통해 배워야 할 기회까지 함께 지워버릴 수 있다는 점도 알게 되었습니다.
솔직히 말하면, 이러한 깨달음에 이르기까지 마음이 편했던 적은 많지 않았습니다. 특히 올해 4~5월은 개인적으로 가장 힘든 시기였습니다. 역할에 대한 혼란과 책임의 무게가 겹치면서, 잠시 도피하듯 이직을 진지하게 고민했고 실제로 합격 제안까지 받아둔 상태이기도 했습니다. 안정적인 선택지 앞에서 흔들리지 않았다고 말한다면 그것은 거짓일 것입니다.
그럼에도 불구하고 최종적으로 그 선택을 내려놓은 이유는 단순했습니다. 이번 역할 변화만큼은 끝까지 받아들이고, 스스로 감당해보고 싶다는 개인적인 욕심이 있었기 때문입니다. 도망치듯 환경을 바꾸는 대신, 지금의 자리에서 내가 어디까지 버티고 성장할 수 있는지를 직접 확인해보고 싶었습니다. 이 선택이 언제나 정답이라고는 할 수 없겠지만, 적어도 저에게는 한 단계 성숙해질 수 있는 계기가 되었다고 믿고 있습니다.
이 경험을 통해 저는 더 이상 ‘모든 것을 책임지는 엔지니어’가 아니라, 구조를 만들고 사람을 연결하는 엔지니어로 나아가고 있습니다. 여전히 부족하고 서툰 부분은 많지만, 불안을 감정으로 처리하기보다 시스템과 구조로 풀어내려는 태도만큼은 분명 이전과 달라졌습니다.
앞으로도 쉽지 않은 순간들은 반복될 것입니다. 그러나 이번 경험을 통해 저는 한 가지를 확신하게 되었습니다. 역할의 변화는 저를 약하게 만드는 과정이 아니라, 훌륭한 엔지니어로 오래 살아남기 위해 반드시 통과해야 할 단계라는 사실입니다.
이 글은 그 과정을 지나고 있는 지금의 나를 위한 기록이자, 언젠가 같은 갈림길에 서게 될 미래의 나에게 남기는 하나의 이정표입니다.
