Q. 왜 갑자기 Manager 트랙으로 뛰어들었나요?

저는 Flutter 중심으로 커리어를 쌓아왔고,
실무는 Flutter만 잘하면 된다는 전제로 굴러가지 않았습니다.
특히 웹 서비스 중심 조직에서는 모바일 우선순위가 밀리기 쉬웠고,
그 결과 앱 개발은 서버, API, 운영, 릴리즈 같은 의존성에서 자주 멈췄습니다.

가장 크게 체감한 건 API 지원 지연이었습니다.
앱 기능은 서버가 받쳐줘야 하는데 지원이 늦어지면 앱은 멈추고,
기다리는 동안 요구사항은 변하며 일정은 흔들립니다.
문제는 속도가 느린 것이 아니라 책임의 경로가 불명확하다는 점이었습니다.

모바일의 고유 프로세스도 조직 내에서 소홀해지기 쉬웠습니다.
사이닝, 스토어 심사 제출, 배포 파이프라인 같은 작업은 익숙하지 않은 경우가 많았고,
그 결과 “누가 리드해야 하는지 모른다”는 상태가 반복되었습니다.
앱은 코드만으로 완성되지 않으며,
출시까지 가는 체계가 있어야 제품이 됩니다.
그 체계가 없으면 개발 속도는 개인 역량과 무관하게 구조적으로 느려집니다.

Q. 스택 경계를 넘나들게 된 계기는 무엇이었나요?

풀스택을 하고 싶어서라기보다,
지원이 없고 우선순위가 낮은 환경에서 앱을 앞으로 밀어내려면 어쩔 수 없는 선택이었습니다.
그래서 자연스럽게 서버, 관리자 웹, 배포 자동화까지 범위를 넓혔고,
문제가 보이면 그 문제를 해결할 수 있는 위치로 이동해야 했습니다.
모바일이 지연되면 전체 제품이 지연된다는 현실을 더 자주 보게 되었습니다.

이 과정에서 저의 역할은 점점 바뀌었습니다.
특정 기능을 만드는 사람이라기보다 제품이 멈추지 않게 만드는 사람에 가까워졌고,
문제를 해결한다는 말이 코드 외부의 병목을 제거하는 의미가 되기 시작했습니다.

Q. 전환을 결심하게 만든 사건이 있었나요?

스택을 확장해가던 중 회사는 모바일 앱 서비스를 중단했고 서비스가 정리되었습니다.
그 과정에서 다니던 회사를 나오게 되었고, 결과적으로 저는 직무를 다시 선택해야 했습니다.
이 시점은 “개발자를 계속할 것인가”가 아니라 “내가 문제를 풀어온 방식이 앞으로도 유효한가”라는 질문이었습니다.

Q. IC 트랙과 M 트랙 사이에서 무엇을 고민했나요?

IC(Individual Contributor) 트랙은 더 깊은 기술 성장에 집중하는 방향이었고,
M(Manager) 트랙은 사람과 제품의 흐름을 끝까지 책임지는 방향이었습니다.
IC 트랙과 M 트랙에 대한 내용은 이 링크의 글을 확인해보시면 좋아요.

IC 트랙으로 더 나은 환경이나 연봉을 제시한 곳도 있었지만,
AI 시대에 접어들면서 매니징의 역할이 더 중요해질 것이라 봤습니다.
또 나 자신도 그쪽에 조금 더 강점이 있을 것이라 판단했습니다.

그때 떠올랐던 건 최근의 변화였고,
AI Agent를 활용하면 낯선 영역을 빠르게 따라가며 문서와 의사결정, 검증까지 묶어
병목을 줄일 수 있지 않을까 하는 생각이 들었습니다.
단순히 코드를 더 빨리 짜는 것이 아니라 팀이 더 빠르게 학습하고 정렬하도록 만드는 방식이었습니다.

제가 하고 싶었던 건 “내가 더 잘 만드는 것”이 아니라 “팀이 더 잘 끝내게 만드는 것”에 가까웠고,
그래서 M 트랙의 역할이 더 잘 맞는다고 느꼈습니다.

Q. M 트랙을 선택하면서 어떤 역할을 상상했나요?

개발을 내려놓기 위한 선택이 아니었고,
개발 경험을 기반으로 제품을 끝까지 내는 과정, 예를 들면 목표와 정렬, 검증, 출시, 운영까지 책임지는 역할로 확장하고 싶었습니다.
스택은 정체성이 아니라 도구가 되어 가고 있었으며,
제 다음 단계는 어떤 스택을 쓰느냐보다 무엇을 왜 어떻게 끝까지 가져가느냐에 더 가까워져야 한다고 판단했습니다.

그래서 역할의 이름보다 역할의 책임을 기준으로 움직이기로 했고,
개발과 운영의 경계가 얇아질수록 이 기준이 더 중요해질 것 같았습니다.

Q. 그 판단을 뒷받침한 신호는 무엇이었나요?

첫째는 일정 지연의 원인이 코드 외부에 있다는 사실을 반복해서 봤다는 점이고,
둘째는 팀이 어려움을 겪는 지점이 기술 난이도보다 결정 구조에 있다는 점이었습니다.
셋째는 문서와 합의가 없을 때 같은 문제가 반복된다는 점이었고,
이 신호들이 “개발자로서 더 깊게 파는 것”만으로는 충분하지 않다는 생각을 굳히게 했습니다.

Q. 전환을 고민하는 사람에게 어떤 이야기를 해주고 싶나요?

스택을 바꾸는 게 아니라 책임의 범위를 넓히는 일이라고 말하고 싶습니다.
코드를 잘하는 것은 여전히 중요하지만,
그것만으로 제품이 끝까지 나가지는 않습니다.
제품을 끝까지 내는 과정은 결정과 정렬, 운영과 검증의 연속이며,
그 흐름을 이해하면 선택의 기준도 달라집니다.

또 하나는 역할 변화가 반드시 직급 변화와 같지 않다는 점입니다.
역할은 회사를 옮기지 않아도 지금 자리에서도 조금씩 만들어갈 수 있고,
결정을 기록하고 리스크를 정리하며 작은 실험의 흐름을 만드는 것부터 시작할 수 있습니다.

Q. 이 글에서 남기고 싶은 결론은 무엇인가요?

개발자의 문제 해결 범위는 코드 안에서 끝나지 않는다는 점을 더 또렷하게 봤습니다.
특히 모바일처럼 의존성이 많은 영역일수록 제품을 끝까지 내는 구조가 중요했고,
그래서 역할의 이름보다 역할의 책임을 기준으로 움직이기로 했습니다.
이 결론은 지금도 계속 검증 중입니다.

Q. 스택 경계가 얇아진다는 말은 무엇을 의미하나요?

제가 말하는 스택 경계의 약화는 기술이 쉬워졌다는 의미가 아니라,
역할이 섞이고 책임이 연결된다는 의미에 가깝습니다.
예전에는 서버 문제는 서버가 해결하고 앱 문제는 앱이 해결하는 구조가 많았는데,
지금은 그 구분이 곧바로 일정 지연으로 이어집니다.
그래서 경계를 구분하는 것보다 연결을 관리하는 일이 더 중요해졌습니다.

Q. 전환을 고민하는 사람에게 현실적인 체크리스트가 있을까요?

저는 다음 질문을 스스로에게 던졌습니다.

내가 자주 해결하는 문제는 코드 안에 있는가, 밖에 있는가
지금의 성과가 개인 역량에만 의존하고 있지는 않은가
팀이 반복적으로 막히는 지점은 무엇인가
그 병목을 내가 해결할 수 있는가, 혹은 누군가 해결해야 하는가

이 질문에 대한 답이 “코드 밖이 더 크다”라면 역할 확장을 고민할 때가 되었다고 느꼈습니다.

Q. 역할을 확장하면 기술 성장은 느려지지 않나요?

이 부분은 저도 걱정했기 때문에, 기술을 내려놓지 않으려는 기준을 세웠습니다.

내가 선택하는 기술의 깊이는 줄어들 수 있지만 결정의 맥락은 더 깊어질 수 있고,
그 맥락을 이해하려면 기술을 완전히 놓을 수 없습니다.

결국 기술과 운영은 분리되지 않는다고 생각합니다.

Q. M 트랙에서 기대한 일의 범위는 무엇이었나요?

제품을 끝까지 내는 과정 전체에 책임을 지는 역할을 기대했고,
목표를 정렬하고 리스크를 검토하며 검증을 설계하는 일이라고 생각했습니다.
그리고 팀이 같은 방향을 보도록 만드는 구조를 만드는 일이기도 합니다.
이 범위는 넓지만 동시에 명확해야 했고, 그래야 책임의 경계도 선명해집니다.

Q. 전환 초기에 가장 조심하려고 한 태도는 무엇인가요?

모든 문제를 내가 해결하려는 태도를 경계했습니다.
역할이 바뀌면 해결의 방식도 바뀌어야 합니다.

문제를 직접 해결하기보다, 문제가 해결되도록 구조를 만드는 일이 더 중요했습니다.
그래서 “나의 성과”보다 “팀의 반복 가능성”을 더 보려고 했습니다.

Q. 전환에 따른 리스크는 무엇이라고 생각했나요?

가장 큰 리스크는 정체성 혼란이었습니다.
내가 무엇을 잘하는지 모호해질 수 있습니다.
또 다른 리스크는 책임만 커지고 권한은 충분하지 않은 상태입니다.
이 균형을 맞추는 일도 TechPM의 중요한 역할이라고 느꼈습니다.

Q. 이 글을 읽는 분들이 기억했으면 하는 한 문장은 무엇인가요?

스택을 바꿨다는 말보다, 책임의 범위를 넓혔다는 말이 더 정확합니다.
그 책임은 문제를 끝까지 가져가는 과정 전체를 포함합니다.
저는 그 책임을 선택했고, 그 과정에서 배운 것을 기록하고 있습니다.

Q. 다음 글에서는 무엇을 이야기하나요?

다음 글에서는 합류 초기에 팀이 왜 표류했는지, 그리고 어떻게 정렬을 다시 만들었는지를 다룹니다.
목표와 리듬, 심리적 안전이 왜 기술보다 먼저였는지 풀어보려 합니다.