마중물에서 물줄기로, 2025년 회고

마중물
명사, '마중'과 물이 결합된 단어로, 물을 '마중' 나가는 물이라는 뜻에서 유래

 

올해는 블로그를 거의 쓰지 않아서 글 목록에서 조금만 내리다 보면 볼 수 있는 2024년 회고에서,

마중물 같은 개발자의 2024년 회고

나를 '마중물 같은 개발자'라고 표현했다. 잠재성을 이끌어내는 계기를 만들어 내는,

2025년을 돌아보니, 이제는 마중물에서 시작된 물이 하나의 줄기가 되어 흐르기 시작한 것 같다.

2025년 회고는 크게 주제를 회사와 개인으로 나누어 작성할 예정이다.

---

회사

입사와 적응 (4월~6월)

작년 회고에서 '내년 상반기에도 내가 원하는 회사에 들어갈 때까지 끊임없이 도전할 것이다'라고 썼는데,

감사하게도 그 도전이 결실을 맺었다.

항공학부 출신이라 대한항공이라는 회사가 낯설지는 않았지만, 정비사가 아닌 개발자로 이 회사에 들어오게 될 줄은 몰랐다.

주변의 지인들도 정비사로 입사한 것인지 헷갈릴 정도였는데, 정말 인생은 어떻게 흘러갈지 알 수 없는 것 같다.

신갈연수원에서 보낸 시간은 당시에도 즐겁고 좋았는데, 지금 생각해보면 정말 그때가 제일 즐거운 때였다.

그 이후 전체 교육 -> 직무 교육 -> 팀교육까지 받고 지금의 자리에 오게 되었다.

본격적인 업무 시작 (7월~8월)

7~8월에서 본격적으로 일에 투입되었다.

당시 팀에 Dynatrace 재계약 시점이 다가오면서, Datadog으로 마이그레이션 할지 검토하는 PoC를 진행하게 되었다.

억 단위의 계약이 오가는 일이었고 타 업체의 임원분들과 직접 커뮤니케이션하면서 피드백을 주고받는 자리였는데,

신입이 이런 자리에 있어도 되나 싶으면서도 배우는 게 많았다.

가장 어려웠던 건 이미 운영 중인 환경에 Datadog을 실제로 적용하는 것이었다.
ECS Task Definition에 Datadog Agent 사이드카를 붙이고, pidMode 설정하고, APM/LOG/RUM을 연계하고, FluentBit으로 multiline log 처리하고, trace_id로 로그와 트레이스를 연결하고... 문서대로 했는데 안 되는 것들이 많아서 하나씩 삽질하며 해결했다.
그러던 중 결정적인 사건이 터졌다. 새벽에 1A측 장애로 홈페이지가 먹통이었는데, Datadog은 이걸 장애로 감지하지 못했다. Anomaly Detection을 PRD 환경에서 평가하던 중에 정작 실제 장애는 놓친 것이다.

반면 Dynatrace는 서드파티 장애까지 정확하게 root cause을 잡아내어 Problem으로 판단했다.

이 사건을 계기로 Dynatrace 재계약으로 결정되었다.

 

이 경험으로 억 단위 의사결정에 기여한 경험을 해보았다.

또한 해당 PoC를 진행하면서 '모니터링 툴로서 다양한 신기능이 있어도 본질적으로 장애를 못 잡으면 무슨 소용인가'라는 질문을 던져보며 본질이 더 중요한 것을 깨닫게 된 계기였다.

교육의 연속 (9월)

9월은 교육의 달이었다 

• Datadog 실습 워크숍
• DevOps 교육 (IaC, EKS)
• if(kakao) 2025 참가
• Akamai University - Security Fraud

회사의 여러 조직마다 운영하는 방법이 다르지만, 우리 팀의 경우 당시 콘솔로 관리하고 있어 운영환경의 설정을 변경해야 할 때마다 불편함이 커서 이를 코드로 관리하고 싶은 마음이 있었다.

그때 마침 좋은 기회로 회사와 정영진 멘토 형님에게 IaC 교육을 들었다.

현재는 여러 일들 때문에 미뤄지고 있지만, 순차적으로 Migration 할 예정인데 그때 큰 도움이 될 것 같다.

 

그리고 팀에서 CDN과 Security 쪽을 관리하는 솔루션인 Akamai의 대면 교육을 들었는데,

당시에는 외계어 수준으로 들렸던 관련 용어들이 몇 달 지난 지금은 대부분 내용을 이해하고 설정할 수 있으며 동시에 팀 내에서 내가 대표하여 운영까지 하게 되었다. 도리어보니 짧은 기간 안에 많은 성장을 한 것 같아 새삼 뿌듯하다.

 

if(kakao)는 추첨에 당첨되어 갔는데, 당시 가장 인상 깊었던 세션이 있었다.

그것은 카카오에서 발표한 '국내 최초오픈소스 가드레일: Kanana-Safeguard'였는데, LLM 응답의 안전성을 검증하는 오픈소스 프로젝트였다.

보안에 민감해진 최근 한국의 시류와 더불어 최근 팀에서 진행 중인 챗봇 프로젝트에 적용하면 좋겠다는 생각이 들었다.

그래서 바로 하루 만에 발표자료를 만들어 3분기 팀 발표 세션에서 팀원들에게 공유했다.

신입이 컨퍼런스에서 배운 걸 팀 전체 앞에서 발표한다는 게 떨렸지만 다행히 좋은 호응을 얻었다. 

배운 걸 바로 적용하려는 시도 자체가 의미 있었던 것 같다.

실전 경험 (10월~12월)

10월부터는 실전이었다. 몇 가지 예를 들자면,

Java Version Upgrade (8 to 17)

우선 첫 번째로 Java 17 PRD 배포였다.

전체 라이브러리와 마이크로서비스를 Java 17로 빌드하도록 옵션을 변경하고, base image도 업데이트했다.

버전 업그레이드는 단순해 보이지만, 운영 환경에서는 수많은 검증이 필요하다. 실제로 Admin 서비스에서 한글 인코딩 문제가 발생했는데, 8에서와 달리 버전 17에서 빌드 옵션을 지정하지 않으면 task의 기본 인코딩 옵션으로 진행되는 문제였고 관리자 서비스를 통해서 사용하는 공항 담당자분들의 내부 고객 문의를 통해서 깨닫게 되었다.

이처럼 사소해 보이는 이슈 하나가 실제 서비스에 큰 영향을 줄 수 있다는 걸 배웠다.

FluentBit 로그 아키텍처 개선

내가 처음으로 메인으로 잡고 처음부터 끝까지 진행한 첫 작업이었다.
기존에는 Task 안에서 Firehose Appender를 통해 CloudWatch로 로그를 전송하는 구조였다. 

문제는 로그가 과다하게 쌓이는 경우, 로깅 자체가 메인 Task에 과부하를 주는 상황이 종종 발생했다는 것이다.
사수도 이 문제를 인지하고 FluentBit 사이드카 방식으로 전환하려 했지만, 리소스 부족으로 미뤄지다가 내가 팀에 합류하면서 맡게 되었다.
막상 파고들어 보니 문제가 하나가 아니었다.

1. 로그 중복 저장 문제

마이크로서비스의 로그가 버킷 2개에 중복 적재되고 있었다. 원인을 추적하니 FluentBit OUTPUT 설정에서 Match 패턴이 문제였다. 이를 현재 로그 구조와 비교하여 변경해서 해결했는데, 간단해 보이지만 이 한 줄을 찾기까지 로그 흐름을 전부 추적해야 했다.

2. Task ID 추적 불가 문제
장애가 발생했을 때 어떤 Task에서 문제가 생겼는지 추적이 안 됐다.

ECS 메타데이터 API를 호출해서 Task ID를 추출하고, 이를 S3 경로에 포함시키는 작업을 했다.
처음에는 Task ID를 파일명에 넣으려 했는데, Athena 파티션 구조와 충돌할 것 같아서 고민했다. 문서에는 '파티션 추가 필요'라고 되어 있었는데, 실제로 테스트해 보니 Athena가 파티션 Location 하위를 재귀적으로 스캔해서 Task ID 폴더가 있어도 정상 조회됐다. 

결과적으로, 아래의 성과를 얻었다.
- FluentBit 사이드카 구조로 전환 → 메인 Task 과부하 해소
- Match 패턴 수정 → 로그 중복 저장 해결
- Task ID를 S3 경로에 포함 → 장애 시 Task별 추적 가능

이후 DEV 환경 15개 마이크로서비스에 모두 적용하고 Athena 쿼리와 WCM 플랫폼 정상 동작까지 확인했다.

처음으로 '내가 온전히 진행한 첫 작업'이라 개인적으로 뜻깊었다.

Dynatrace MCP, Google workspace MCP 개발

팀 내의 인사 변동으로 인해 갑자기 팀의 인프라 담당이 되어버렸다.

기존에 가장 많은 역할을 해주시던 분의 부재로 일이 과하게 많이 생겨버렸는데 어떻게든 과도한 로드를 감당하기 위해서 몇 주간 주말 내내 일하는 환경을 계속 개선했다.

 

그중 하나가 Dynatrace MCP, Google workspace MCP 개발이다.

 

현재 회사 내에서 사용하는 솔루션이 Dynatrace와 모든 업무 관련 SaaS인 Google Workspace의 api를 가지고, 사내에서 사용할 수 있는 Kiro CLI가 사용할 수 있는 MCP를 제작했다.

 

Dynatrace의 경우 API 공식 문서를 기반으로 제작해서, 터미널에서 바로 Dynatrace를 조작할 수 있게 15개 도구를 TypeScript로 구현했다.

Google Workspace는 이미 기존의 mcp 오픈소스들이 존재했지만 사내 환경에서 사용하기에는 보안을 완벽하게 보장할 수 없을 것 같아 Dynatrace와 같은 구조로 구현했다.

 

그래서 이제 터미널에서 AI Agent와 연동해서 "현재 열린 Problem 있어?"라고 물으면 바로 답변을 받을 수 있게 됐고,

'~~ 제목의 메일을 검토해서 현재 ~ 경로에 ~ 소스를 검토해서 무슨 문제인지 파악해 줘'라고 하면 이 모든 워크플로우를 진행하고 나한테 보고하게끔 자동화하였다.

 

덕분에 늘어난 업무량을 그나마 감당하게 되었는데, 업무 효율화를 위해 직접 도구를 만들어 쓰는 경험을 통해서 오랜만에 개발자로서 큰 즐거움을 얻었다.

스크럼 마스터

DevOps 엔지니어 역할 외에도 MY 페이지, 공항 페이지의 스크럼 마스터를 맡고 있다.

스크럼 마스터 역할을 하면 기획-개발-도급업체 사이에서 조율하고, 일정을 관리하고, 이슈를 해결하는 역할을 맡는다.

와중에 대부분이 나보다 연차로나 직급으로나 윗사람들과 논의해야 하는 상황이 대부분이지만,

프로젝트 리딩을 많이 해봤던 과거의 경험 덕분에 다행히 잘 리딩하면서 넘어갈 수 있었던 것 같다.

그중 스크럼 마스터로서 가장 기억에 남는 업무는 마일리지 캐시 불일치 VOC 분석이다.

고객이 메인페이지에서 보는 마일리지와 상세조회 페이지에서 보는 마일리지가 다르다는 민원이 들어왔다.

원인을 파고들어 분석한 결과, 계약해서 사용 중인 솔루션이 제대로 캐시를 갱신하지 못해서 발생하는 문제였다.

이 과정에서 윗선까지 보고되어 여러 팀이 엮이게 되었는데, 당시 우리 팀은 괜히 도와줬다가 끼게 된 애매한 상황이었다.

내 성격상 내 일 아니어도 최대한 돕자는 마인드였는데, 이 일을 계기로 항상 좋은 마음으로 모든 일을 돕는 것이 능사는 아니라는 생각하게 되었다.

문서화의 힘

올해 가장 많이 한 일 중 하나가 문서화다.

팀에 들어오니, 인프라 파트를 제외한 다른 부분에선 인수인계가 거의 없었다.

그래서 맨 땅에 헤딩하는 식으로 직접 부딪히며 배워가보니, 다음 사람은 뭔가 배울 수 있는 가이드 문서가 있으면 좋을 것 같았다.

그 김에 나도 잘 모르는 내용들에 대해서 같이 배우는 느낌으로 가이드 문서들을 비롯해서 많은 내용들을 문서화했다.

 

팀에 제대로 합류한 것이 6월이니, 약 6개월 동안 140+개의 문서를 문서화했다.

문서화를 하는 것 자체는 시간과 정성이 꽤나 드는 작업이지만 하고 난 이후에 다른 사람에게 내 지식과 경험을 공유할 때 훨씬 편리하고, 결론적으로 나뿐만 아니라 많은 사람들의 시행착오를 줄여준다는 점에서 조직적인 관점에서는 오히려 일하는 시간을 줄여주는 윈윈하는 수단이었다.

회고록 시스템 구축

문서화의 일환으로, 10월 말부터 매일 회고록을 작성하기 시작했다. 처음에는 귀찮았지만 지금은 습관이 되어 꽤나 익숙해졌다.

오늘 뭘 했는지, 뭘 배웠는지, 내일 뭘 해야 하는지를 정리하면 업무를 다시 시작할 때 몰입하는데 드는 시간이 줄어들고 장기간의 템포를 가지고 가는 작업을 할 때 계속 진행되는 듯한 느낌을 받을 수 있다.

 

또한 회고록을 작성하기 시작한 이유는 추후에 설명할 AI 워크플로우에서 핵심이 되는 '컨텍스트'를 유지하기 위함이었다.

# YYYY-MM-DD 회고

## 진행한 업무
## 트러블슈팅
## 회의 및 커뮤니케이션
## 배운 점 / 궁금한 점
## 내일 할 일

 

결론적으로 회고록을 쓰게 됨으로써,

1. 하루를 정리할 수 있게 되고

2. 현재 일의 진행사항을 트래킹 할 수 있고

3. AI의 컨텍스트를 지속적으로 관리할 수 있으며

4. 내 업무 성과를 증명할 자료를 만들 수 있었다.

 

그리고 이 회고록들이 모여서 지금 이 연말 회고를 쓸 수 있게 됐다.

개인

위에 내용과 일부분 겹칠 수 있지만, 아래는 개인적으로 성장한 것에 대한 내용이다.

개인 AI 워크플로우 구축

회사 업무 외에도 개인적으로 jchat이라는 AI 개발 환경을 구축했다.

(근데 지금은 또 opencode를 이용한 새로운 환경으로 이관 중이다ㅋ..)

(++ 글을 쓰는 와중에 opencode에서 또 opencode처럼 kiro cli를 wrapping 한 새로운 라이브러리를 tui 환경을 구축 중이다)

 

단순히 'AI를 사용했다'가 아니라, 최대한 AI의 구루들의 아이디어와 Open AI, Gemini, Antrophic 등의 회사에서 매주 발표하는 방법론들과 팁들을 녹여가며 나만의 AI 워크플로우 아키텍처를 구축하려고 노력했다.

 

핵심 철학은, 단순히 AI를 도구로만 사용하는 것이 아니라 하나의 팀원으로 두고 사용하려고 노력했다.

AI를 단순 코드 생성기로 쓰면 한계가 명확하다. 맥락을 모르니까 엉뚱한 답을 하고, 같은 실수를 반복한다.

그래서 AI에게 role과 context를 부여하는 시스템을 만들었다.

1. 역할 기반 전환 시스템 (16개 역할)
작업 유형에 따라 AI가 자동으로 역할을 전환한다. architect, frontend, backend, reviewer, bug-fixer, security 등 16개 역할을 정의하고, 각 역할마다 체크리스트와 행동 규칙을 만들어뒀다.
예를 들어 '설계해 줘'라고 하면 architect 역할로 전환되어 SOLID 원칙, 트레이드오프 분석, ADR 작성 등을 자동으로 고려한다.

2. Scale Adaptive System
모든 작업을 같은 프로세스로 처리하면 비효율적이다. 그래서 복잡도에 따라 워크플로우를 자동 선택하는 시스템을 만들었다.
Quick Flow: 버그픽스, 소기능 → 바로 개발
Standard Flow: 새 기능 → Tech Spec → TODO → 개발 → 리뷰
Full Flow: 새 프로젝트 → 기획 → 리서치 → 개발 → 테스트 → 배포

3. 3단계 합의 프로세스
AI가 마음대로 파일을 수정하면 위험하다. 그래서 모든 생성/수정/삭제 작업에 3단계 합의를 적용했다.
1) Kiro 계획 수립 → 사용자 승인 요청
2) Codex 리뷰 → 피드백 수집
3) Kiro + Codex + 사용자 합의 → 실행

4. Compounding Engineering (실수 누적 방지)
AI가 같은 실수를 반복하면 steering 문서에 기록해서 다음부터 같은 실수를 안 하도록 했다. 

AI가 학습하는 게 아니라, 규칙 문서가 점점 정교해지는 방식이다.

5. MCP 서버 연동 (7개)
Kiro CLI에 MCP 서버 7개를 연동해서 AI의 능력을 확장했다. codex(코드 리뷰), github(이슈/PR 관리), notion(문서 연동), context7(라이브러리 문서 검색), memory(세션 간 기억), sequential-thinking(복잡한 작업 분해), playwright(브라우저 자동화) 등등이 있다. 여기에 필요한 경우 직접  mcp를 구축해서 더 하였다.

 

이외에도 매주 AI 관련 소식을 아카이빙 하고, 주말마다 내 워크플로우에 반영할 부분들을 검토 후에 반영하는 등 끊임없이 개선하고 효율적으로 일을 하려고 노력한다.

 

안드레 카파시가 말한 것처럼, 프로그래밍이 점점 코드를 짜는 게 아니라 AI 도구를 엮어내는 능력의 싸움이 되고 있는 것을 느낀다. 

현재도 구현하는 부분에서 많은 개발자들을 뛰어넘는 수준을 보이는데, 불과 몇 년 안에 구현하는 것은 아예 비교가 되지 않을 거라고 생각한다.

 

다만 AI는 안드레 카파시의 비유처럼 AI는 '사용설명서 없는 외계 도구'와 같은 상태이고,

이를 잘 다루기 위해선 agent, tools, context 같은 새로운 추상화 계층을 다루는 방법을 배워야 한다. 

 

매주 급격하게 발전하는 ai 생태계처럼 내 워크플로우도 매주 새롭게 변화하는데, 기회가 된다면 관련해서 글을 자세하게 써볼까 고민 중이다.

운동

올해 운동 부분에선 큰 변화가 생겼다.

작년 회고에서 '내년 상반기부터는 헬스를 다시 제대로 시작해 볼 생각이다'라고 작성했고 실제로 이전의 고점인 450에 거의 근접한 440 정도까지 중량을 복구했었다.

다만 운동을 건강 관리의 목적보다는 순전히 재미 때문에 하였는데, 갑자기 어느 순간 얼굴에 실핏줄 터져가며 중량을 드는 게 말 그대로 재미 없어졌다.

 

그래서 그날 바로 회원권을 동생에게 넘기고, 운동 장비를 전부 처분했다.

약 5년 넘게 꾸준히 해오던 헬스라서 나에게도 큰 변화였지만 즐거움 없이 파워리프팅을 하는 이유를 찾지 못한 게 컸다.

 

그리고 새로운 취미로 주짓수, 클라이밍, 러닝을 후보로 두고 고민하다가, 러닝으로 시작하였다.

 

이유는 헬스와 마찬가지로 자세가 괜찮다면 나이가 들어서도 꾸준히 할 수 있는 운동이라는 것이고, 

초기 비용이 들지 않으면서, 현재 체력이 부족해 하고싶은 게 많아도 못하는 이 상황을 타개할 수 있을 것이라 생각했다.

 

그래서 군대에서도 전부 특급이었지만 구보가 2급이어서 특급전사를 못했던 내가 달리기를 시작했고, 

처음에 3km 7분 페이스도 힘들었는데 한 달 만에 515 페이스로 10km를 달릴 수 있게 되어 큰 성취감을 느꼈다.

 

그래서 회사에서 점심에 요가 또는 간단한 맨몸운동을 하고, 퇴근 후에 러닝을 하는 게 내 새로운 운동루틴으로 자리 잡게 되었다.

2026년 목표는 풀마라톤 330이다. 

생각만 해도 고되지만, 뭐 안되면 말고~

독서

올해 읽은 책은 많지 않다. 작년 회고에서 읽을 책 목록을 잔뜩 적어놨는데, 거의 못 읽었다. 이 부분은 좀 아쉽다.

그나마 읽은 책:

• 마법의 연금 굴리기
• 행복의 기원
• 자몽살구크럽

2026년에는 월 1권이라도 읽는 것이 목표다.

재테크

작년에 부동산 공부를 시작하겠다고 했는데, 아직 시작 못 했지만 대신 주식 투자는 꾸준히 하고 있다.

연금저축펀드, ISA 계좌 등을 통해 세금 공제를 이용한 장기 투자를 진행하고,

기본적으로 자산 배분 + 계절성을 통한 안정성 포트폴리오와 공격적인 자산에 투자하는 투더문 포트폴리오로 나누어 진행하고 있다.

 

그리고 이를 매번 수동으로 관리하는 게 어려워, 12월에 Folio라는 사이드 프로젝트를 시작했다.

노션에 정리해 둔 재테크 전략들을 자동으로 실행하고, 실제로 자산 관리를 자동화하는 개인 자산 관리 플랫폼이다.

아직 MVP 단계지만, 2026년에는 제대로 완성해 볼 예정이다.

---

마무리하며

작년 회고에서 이렇게 썼다:

다음에 회고할 때의 내가 지금의 나를 귀엽다 생각할 수 있도록 2025년도 열심히 살아볼 예정이다

 

근데 취준 하는 당시에 너무 고생하며 열심히 했어서, 아직도 그때의 내가 귀여워 보이기는커녕 참 고생 많이 했다는 생각이 든다.

 

지금도 열심히 자기 계발을 하지만 하기 싫은 걸 하는 능력이 정말 바닥을 치고 있다(예를 들어서 토익스피킹)

매일 번아웃이 오면서, 하기 싫은 것을 매일 했었던 과거의 나에게 위로를 보내고 싶다.

 

그런 노력 끝에 시작된 마중물이 이제 하나의 줄기가 되어 흐르고 있다.

아직 작은 물줄기지만, 꾸준히 흐르다 보면 언젠가 강이 될 거라고 믿는다.

 

2026년 목표는 아래 3가지다.

• 업무: 연차나 직급에 한계를 두지 않고 프로젝트를 제대로 책임지고 이끌기
• 기술: AI 워크플로우 지속적으로 발전시켜 사이드 프로젝트 하기, AWS SAA, SAP 자격증 취득
• 개인: 풀마라톤 3시간 30분 / 영어회화 (비즈니스 활용) / Folio 프로젝트 완성 / 책 월 1권 이상 독서

위 목표를 성공하든 못하든, 내년에도 또 돌아와 회고 글을 남기기를~

긴 글 읽어주셔서 감사합니다.