2025년은 직함이 바뀐 해라기보다 커리어 방향을 다시 정리한 해였습니다.
12월부터 Team Leader 겸 Tech PM 역할을 맡게 되었지만, 올해의 중심은 “Team Leader가 됐다”가 아니라 “그 결정을 하게 된 과정”에 가깝습니다.
그래서 이 글은 직무의 변화보다 그 과정과 생각의 변화를 정리하는 기록입니다.
올해의 질문은 단순했습니다.
나는 지금 어떤 개발자이고, 앞으로 어떤 엔지니어로 남고 싶은가.
이 질문에 답하려고 한 해 내내 조금씩 방향을 바꿔 왔습니다.
혼자 잘하려고 했던 상반기
상반기에는 혼자 잘하려는 마음이 컸습니다.
기술 글을 쓰고, 발표를 하고, 사이드 프로젝트도 이어 갔는데, Flutter 시리즈를 시작하며 Android와 iOS 빌드 이슈를 루틴처럼 정리했습니다.
시리즈를 쓰면서는 “어차피 내가 한 번 겪은 걸 정리해 두면 누군가는 도움이 되겠지”라는 마음이 있었고, 시간이 늘 부족했지만 글을 쓰는 순간만큼은 그 부족함을 핑계로 삼지 않으려 했습니다.
첫 글은 개발 생산성 향상 가이드로 시작했는데, 그 글을 쓰면서 스스로도 작업 흐름을 다시 점검하게 되었습니다.
‘좋은 도구를 모으는 것’보다 ‘흐름을 끊지 않는 것’이 더 중요하다는 걸 확인했고, 두 번째 글에서는 Android 빌드 이슈를 다루며 Gradle과 AGP, Manifest의 작은 설정이 전체 빌드를 막는 경험을 정리했습니다.
Android는 상대적으로 쉬울 거라고 생각했지만, 막상 깊이 들어가면 다른 면이 있었습니다.
세 번째부터는 iOS로 넘어갔습니다.
Xcode 기본 설정과 프로젝트 구조가 생각보다 많은 함정을 갖고 있었고, 아무 것도 하지 않았는데도 빌드가 깨지는 상황을 몇 번 겪었습니다.
Android와 다른 점이 많아서 한 번에 정리하기는 어려웠고, 그래서 iOS 파트는 두 편으로 나눌 수밖에 없었습니다.
iOS 빌드는 한 번 더 깊게 다뤘습니다.
Flavor 설정, FCM 연동, APNs 키 문제처럼 로컬과 배포 환경의 간극이 자주 드러났고, 로컬에서는 잘 되던 것들이 TestFlight나 App Store에서 다른 결과를 내놓기도 했습니다.
이때부터는 “최신 SDK와 플러그인 업데이트를 준비해야 한다”는 메시지를 더 강조하기 시작했습니다.
앱 서명과 배포 키 관리 글도 썼습니다.
키 관리가 주니어에게 어렵다는 말을 자주 들었고, 나 역시 어려움을 겪었는데, 이 글은 실제로 피드백을 많이 받았습니다.
“이걸 보고 처음으로 키 관리가 이해됐다”는 말이 기억에 남았고, 그래서 이후 글에서는 가능하면 “실제로 막히는 포인트”를 먼저 꺼내기 시작했습니다.
글을 쓰는 과정은 결국 나를 다시 가르치는 시간이었습니다.
내가 잘 알고 있다고 생각했던 부분이 실제로는 허술하다는 것도 드러났고, 이 과정이 쌓이니 “안다고 착각하는 것”을 줄이는 데 도움이 됐습니다.
결국 글쓰기는 학습 방법이기도 했습니다.
발표도 이어 갔습니다.
라이브코딩 발표는 생각보다 훨씬 어렵고, 실시간으로 코드를 작성하면서 설명까지 하려면 집중도가 크게 올라가는데, 문제는 크고작은 변수들이 계속 생긴다는 점입니다.
준비를 해도 현장에서 흔들리는 경험을 여러 번 했고, CodeFactory 이그나이트에서 Flutter와 Supabase로 CRUD 테이블을 만드는 라이브코딩을 했을 때도 같은 문제를 느꼈습니다.
이 경험은 “기술을 안다”와 “전달할 수 있다”의 차이를 뚜렷하게 보여 줬습니다.
사내 내부 밋업도 준비했는데, 온라인 발표를 영상으로 남기는 과정에서 말투나 흐름을 다시 점검하게 되었고, 기술 내용이 좋아도 전달 방식이 매끄럽지 않으면 가치가 줄어든다는 걸 체감했습니다.
결국 발표는 전달력이 핵심이라는 결론에 도달했습니다.
기술 블로그도 올해는 더 많이 써보려고 노력했습니다.
영문 블로그는 Medium에서, 한국어 블로그는 Tistory로 옮겼을 때는 기대가 컸지만 예상치 못한 문제가 생기면서 다시 고민해야 했고, 기술 글을 쓸 때는 “글이 남을 자리”가 생각보다 중요하다는 걸 배웠습니다.
그래서 글쓰기 리듬을 만들기 위해 의도적으로 시리즈 형태를 택했습니다.
사이드 프로젝트도 꾸준히 했습니다.
Flutter에서 릴리즈 환경 로그가 잘 쌓이지 않아 고민이 많았고, 이를 보완하기 위한 로그 수집 보조 라이브러리를 만들었는데, 이 프로젝트는 완성보다 “일단은 릴리즈”에 의미를 두었습니다.
Firebase Dynamic Link가 종료된다는 소식을 듣고는 개인 프로젝트로 대체 서비스를 만들기도 했습니다.
CuroLink를 만들면서 서비스가 사라지는 순간 사용자와 팀이 얼마나 빠르게 흔들릴 수 있는지 다시 느꼈고, 개인 프로젝트였지만 실제로는 운영과 배포의 복잡함을 그대로 마주하게 되었습니다.
그 복잡함을 다뤄본 경험이 실무에서도 도움이 된다는 확신이 생겼습니다.
CuroLink를 만들면서는 Go와 PHP를 함께 다루는 경험도 있었고, 기술 스택이 늘어날수록 “내가 어디까지 커버할 수 있는가”를 자주 고민했습니다.
하루 수십 개 Flutter 앱 빌드 파이프라인을 정리하던 시기도 이때였는데, 특히 iOS 인증서 관리가 얼마나 까다로운지 몸으로 배웠습니다.
Riverpod 3.0 업데이트를 앞두고는 실제 적용 전에 기능을 꼼꼼히 확인하며 블로그로 정리했고, 새 기능이 얼마나 편해지는지보다 기존 코드와의 호환과 운영 안정성이 더 중요하다는 점을 다시 확인했습니다.
이 시기의 저는 “내가 더 잘하면 된다”는 생각에 집중해 있었고, 혼자서 성과를 만드는 데 익숙했지만 시간이 갈수록 “내가 만든 방식이 팀이나 서비스에 남지 않는다”는 불안이 커졌습니다.
한계를 자주 마주한 하반기
글을 쓰고, 발표를 하고, 실험을 하면서도 한계는 분명했습니다.
“내가 이해한 것”과 “팀이 함께 이해한 것”의 거리가 생각보다 컸고, 혼자 잘하는 것만으로는 충분하지 않다는 결론에 가까워졌습니다.
특히 iOS 배포 과정에서 그 차이를 크게 느꼈습니다.
로컬에서는 잘 되던 것들이 TestFlight나 App Store에서 다른 결과를 내놓는 일이 반복됐고, 문제는 지식이나 숙련도보다 “이걸 팀이 함께 다루는 방식”에 더 가깝다고 느꼈습니다.
그래서 문서를 남기고, 일의 진행 과정을 팀과 더 자주 공유하려고 했습니다.
이 시기에는 커리어에 대한 질문도 조금씩 커졌습니다.
Commit 행사에 참석했을 때 “내 꿈은 무엇인지 찾아보라”는 문장이 특히 남았고, 최근에는 관성적으로 일과 공부를 반복하는 습관이 생겼다는 것도 인정하게 되었습니다.
그때부터는 개발자를 몇 살까지 할지 같은 질문이 실제 고민으로 자리 잡았고, 개발자로만 살아야 하는지, 다른 역할이나 방향을 열어둬도 되는지 생각했습니다.
문제는 답보다, 질문을 놓치지 않는 것이라는 생각이 들었습니다.
그래서 올해는 Flutter 커피챗은 물론 다양한 개발자 그리고 관리자 분들도 자주 만나뵈려고 노력했고, 사람과의 연결이 생각보다 중요한 순간들이 많다는 걸 다시 느꼈습니다.
이 질문은 팀 관점으로 전환하는 데도 영향을 줬습니다.
개인의 성취보다 팀과 서비스에 남는 방식이 더 중요하다는 결론에 가까워졌고, 특히 결과를 만들어내는 방식이 재현 가능해야 한다는 점이 크게 느껴졌습니다.
그래서 문서의 형식을 조금씩 통일하려고 했습니다.
하반기에는 오픈소스 작업도 남았습니다.
curompt v1.0.0을 공개했고, 로컬 환경에서 프롬프트 히스토리를 수집하고 분석하는 흐름을 만들었는데, “스캔 한 번으로 끝내는 경험”을 목표로 했고 구조를 자동 인식하는 방식도 붙였습니다.
기술적으로는 간단해 보일 수 있지만, 실제로는 프롬프트의 불규칙함을 다루는 일이 더 어려웠습니다.
Open To Work 글도 올렸습니다.
의도하지 않았으나, 회사를 나오게 되어 그 동안 신세진 동료들에게 감사 인사를 전했고, 새로운 자리와 도전을 탐색했습니다.
이 시기에는 내가 어떤 가치를 제공할 수 있는지를 다시 정리하게 되었고, Flutter에서는 제품 검증과 출시 속도, 성능 최적화 같은 키워드를 정리했습니다.
Go나 백엔드에서는 gRPC, REST, Postgres 같은 기반 기술을 다시 묶어 보았고, 풀스택 경험과 DX 관점도 함께 강조했습니다.
AI가 바꾼 접근 방식
이 전환의 중심에는 AI 활용이 있었습니다.
예전에는 모르는 영역이 나오면 조사 비용과 실패 비용이 부담이어서 시작을 미루곤 했지만, AI를 쓰기 시작한 뒤에는 어디부터 확인할지, 어떤 가설을 먼저 검증할지를 빠르게 잡을 수 있었습니다.
탐색 비용이 낮아지니 시도 횟수가 늘었고, 두려움이 줄면서 도전 범위도 넓어졌습니다.
AI는 “멋있어 보이는 도구”가 아니라 “시작을 가능하게 만드는 장치”에 가까웠습니다.
이 작은 변화가 반복되면서 결국 방향을 넓게 보는 태도가 생겼고, 그 넓어진 시야가 커리어를 다시 정리하게 만든 촉매가 되었습니다.
개인적으로는 Claude나 Codex 같은 도구를 적극적으로 써 보면서 생산성을 실험했습니다.
하지만 단순히 빠르게 만드는 것이 목표는 아니었고, 내가 어떤 가설을 세우는지, 어디에서 시간을 쓰는지 다시 보려 했습니다.
AI를 쓰면 나의 사고 흐름이 더 잘 드러난다는 점이 인상적이었습니다.
curompt 같은 도구를 만든 것도, AI를 쓰는 과정을 더 나은 방식으로 다듬고 싶었던 실험의 연장선이었습니다.
프롬프트 히스토리를 자동으로 수집하고 구조를 잡아 보는 과정은 “내가 어떻게 생각하고 시도하는지”를 다시 보게 해줬습니다.
AI를 통해 새로운 기술을 접할 때, 이전보다 덜 부담스럽게 접근할 수 있었습니다.
“완벽히 이해하고 시작하자”가 아니라 “작게 검증하고 움직이자”로 사고가 바뀌었고, 이 작은 태도 변화가 실무에서도 큰 차이를 만들었습니다.
AI를 적극적으로 쓰면서 사고 방식이 조금씩 바뀌었습니다.
완벽한 계획보다 빠른 가설 검증이 중요해졌고, 실패의 비용을 낮추면 시도 자체가 많아진다는 점을 경험으로 확인했습니다.
이 경험이 팀 리드 역할을 준비하는 데도 도움이 되었고, 다만 AI의 한계와 위험도 동시에 체감하면서 보안이나 운영 관점에서 어떤 기준이 필요한지 고민하게 되었습니다.
LLMOps에 대한 관심이 커진 것도 이때였습니다.
Software Engineer라는 단어가 더 좋았던 이유
저는 “Developer”보다 “Software Engineer”라는 단어를 더 좋아합니다.
과거에 Broadcast Engineer로 일하면서 “안 되는 걸 해결해 주는 사람”이라는 정체성이 좋았고, 개발도 결국 서비스가 고통받는 지점을 프로그래밍으로 해결하는 일이라고 믿습니다.
그래서 올해는 “혼자 잘하는 개발자”보다 “구조와 서비스를 만드는 엔지니어”에 더 끌렸습니다.
이 생각을 더 또렷하게 만든 사건이 『Flutter Engineering』 한국어판 번역 참여였습니다.
주 역자로 참여하면서 단순한 위젯이나 API 나열이 아니라, 소프트웨어 엔지니어링 관점의 깊이를 전달하는 일이 중요하다는 것을 다시 확인했습니다.
실무에서 마주하는 아키텍처, 상태관리, 테스트, CI/CD, 보안, 접근성 같은 주제를 “왜 그런지”와 함께 풀어내는 과정이 크게 남았습니다.
번역 과정은 단순히 텍스트를 옮기는 일이 아니라, 내가 무엇을 중요하게 생각하는지 확인하는 시간이기도 했습니다.
번역 경험은 “지식을 어떻게 전달할 것인가”에 대한 감각을 키워 줬고, 그래서 올해는 글의 구조를 더 의도적으로 짜 보려고 했습니다.
커뮤니티 소식도 종종 공유했습니다.
플러터 관련 행사나 정보가 있을 때는 가능하면 소개하려 했고, 누군가에게는 작은 링크 하나가 새로운 기회가 될 수 있다고 믿었습니다.
컨퍼런스와 스터디 경험도 큰 자극이었습니다.
디자인 시스템의 자동화, 실시간 알림 구조, AI 보안과 LLMOps 같은 주제를 보며 현대 개발자는 단순히 코드를 생산하는 사람이 아니라 더 나은 구조와 서비스를 만들어야 한다는 생각이 선명해졌고, 디자인 패턴 스터디를 열고 기본기를 다시 다지는 과정 역시 같은 흐름에 있었습니다.
Flutter 자체의 큰 변화도 정리했습니다.
The Great Thread Merge를 다루면서 앞으로의 개발 경험이 어떻게 바뀔지 고민했고, UI, 래스터, 플랫폼 스레드가 하나로 합쳐지는 변화는 단순한 성능 이슈가 아니라 구조 변화로 보였습니다.
외부 변화와 선택
올해에는 예상치 못한 외부 변화로 선택을 해야 하는 상황도 있었습니다.
완전히 제가 주도한 전환은 아니었지만, 오히려 그 과정에서
“사실 내가 개발을 시작했을 때 궁극적으로 원하던 Software Engineer의 롤모델에 가까운 방향 아닌가?”라는 생각이 들었습니다.
그래서 방향을 다시 정리했고, 그 선택이 지금의 역할로 이어졌습니다.
팀 리드 역할을 맡으면서는 시야가 더 넓어졌습니다.
개인의 속도보다 팀이 함께 움직이는 방식, 서비스가 유지되는 구조에 더 관심이 갔고, 혼자 잘하는 것이 아니라 팀과 서비스 관점에서 문제를 보는 일이 더 중요해졌습니다.
이때부터는 “내가 해결한 문제”보다 “팀이 다시 마주하지 않게 만든 문제”가 더 중요하게 느껴졌습니다.
선택을 고민할 때는 One Way Door와 Two Way Door 관점을 떠올렸습니다.
대부분의 결정은 되돌릴 수 있는 Two Way Door라는 점을 생각하면 부담이 조금 줄었고, 그래서 완벽한 답을 찾기보다 작은 실험과 빠른 검증을 반복하는 쪽에 가까워졌습니다.
외부 변화가 없었다면 이런 전환을 바로 선택했을지는 잘 모르겠습니다.
하지만 결과적으로는 “원래 원하던 방향”에 더 가까워졌습니다.
그래서 올해는 아쉬움보다 납득이 더 큰 해였습니다.
2026년에 바라보는 방향
2026년에는 “AI를 더 잘 쓰는 방법”을 넘어서, 팀과 회사와 커뮤니티에 어떻게 기여할지를 더 고민하고 싶습니다.
팀 단위의 AI 활용 표준화, DX와 플랫폼 관점의 설계, 안전과 보안, 품질까지 포함한 운영 방식이 관심사입니다.
이 과정을 지식으로 남기고, 다른 팀이나 커뮤니티가 참고할 수 있게 만드는 일도 꾸준히 해보고 싶습니다.
예를 들면 이런 것들입니다.
팀 단위의 프롬프트 운영 방식과 기록 구조를 정리해 보고 싶고, 검토 가능한 로그를 남기고 품질 기준을 합의하는 방식도 필요합니다.
AI가 만든 결과물이 실제 서비스에 반영되기까지의 책임 구조도 고민해야 합니다.
DX 관점에서는 빌드와 배포, 모니터링까지 이어지는 흐름을 더 단단하게 만들고 싶습니다.
개인의 노하우가 아니라 팀의 시스템으로 남아야 한다는 생각이 계속 들었고, 작은 자동화라도 팀 전체의 시간을 줄일 수 있다면 가치가 있습니다.
커뮤니티 관점에서는 “개인 경험을 구조화해 전달하는 방식”을 더 개선하고 싶습니다.
번역이나 스터디를 통해 얻은 감각을 다시 글과 실무 사례로 연결해 보려 합니다.
AI 활용이 조직 차원의 생산성과 안전으로 이어지려면, 사람과 프로세스가 함께 움직여야 한다고 생각합니다.
그래서 개인 역량을 넘어 팀 차원의 실험 설계가 중요해질 것 같습니다.
문서화와 교육, 운영 기준을 함께 만드는 일이 필요하다고 느낍니다.
올해는 불확실한 변화를 맞으면서도, 결국 내가 좋아하던 “Engineer”에 더 가까워진 해였습니다.
내가 잘하는 것보다, 우리 팀과 서비스가 잘 되는 방향을 더 고민하게 되었고, 그 고민이 지금의 선택으로 이어졌습니다.
이 글을 읽고 비슷한 고민을 하고 계시거나, AI 활용을 팀 단위로 어떻게 정착시키는지 사례를 나누고 싶으신 분이 계시다면 편하게 이야기 나눠주세요.
커피챗이나 가벼운 네트워킹도 환영합니다.