안녕하세요! 어피닛 Tech Foundation Service(TFS) 팀에서 8개월째 일하고 있는 주니어 개발자 Mike입니다!
많은 분들이 AI 시대에 PM이 대체될 수 있다는 도발적인 제목을 보고 들어오셨을 거라 생각합니다.
이에 대한 결론을 내리기 위해서는 우선 문과 출신인 제가 어떻게 어피닛에서 개발자로 일하고 있는지, Tech Foundation Service가 어피닛에서 무슨 일을 하고 있는 팀인지, 마지막으로 그래서 문과 출신 주니어 개발자가 도대체 무슨 일을 한 건지 설명해드려야 할 것 같습니다.
사학과 출신이 개발자만 있는 팀에 들어가기까지
대학 시절 사학과를 전공한 저는 불과 1년 전만 해도 코딩을 한 줄도 할 줄 모르던 문과 그 자체였습니다. 그러다가 ‘AI 서비스 기획’이라는 부트캠프를 거쳐 운좋게 어피닛에 인턴으로 입사하게 되었습니다.
어피닛의 TFS팀은 전사 AI 도입을 위해 결성된 팀입니다. 사내에 AI 도구들을 셋업하고, 비개발자도 직접 업무를 자동화할 수 있게 바이브코딩을 도와줍니다. 그래서 인턴 면접 때도 “바이브코딩에 앞서서 프롬프트를 어떤 단계로 설계하는지”를 가장 중점적으로 보셨습니다.
제가 비개발자 시점을 가장 잘 대변할 수 있는 사람이라서, 개발자들로만 이루어져 있는 Tech Foundation Service 팀에 제가 할 수 있는 역할이 분명 있을 것이라는 생각에 저를 뽑으셨을 거라고 생각하고 있습니다. 비개발자를 위한 AI 도구를 만드는 팀에 비개발자 출신이 들어온 것. 어쩌면 가장 자연스러운 캐스팅이었는지도 모르겠습니다.
개발자들만 모인 팀의 진짜 어려움
하지만 처음 TFS팀에 들어왔을 때는 다양한 어려움이 한꺼번에 다가왔습니다.
TFS팀에는 하루 30분씩 서로의 얼굴을 보며 각자 하는 일에 대해 브리핑하고, 서로 궁금한 점을 물어보는 데일리 스크럼 시간이 있습니다. 입사 첫 날 들어갔던 데일리 스크럼은 지금 돌이켜봤을 때 저에게는 혼자 말이 안 통하는 해외여행을 떠난 기분과 같았습니다. 분명 들리는 건 한국말인데 무슨 말인지 따라갈 수가 없는 느낌….?
특히 TFS팀은 각자 하는 일이 너무나 달랐기에 본인이 하고 있는 일을 설명하는 것만 30분 이상 걸렸고, 각자 어떤 일을 하는지 미리 올려놓는다 하더라도 7명 정도 되는 사람들이 하는 일을 전부 이해하기 위해서는 매일 한시간 정도 되는 시간을 투자해야 했습니다.
두세 달이 지나며 도메인 지식과 개발 언어가 손에 익자 회의는 따라갈 수 있게 되었습니다. 하지만 더 근본적인 어려움이 남아 있었습니다.
바로 ‘목표를 어떤 주기로 잡을 것인가’였습니다.
하루에도 수십 개의 에이전트가 쏟아져 나오는 AI Native 시대에, 목표를 잡고 앞으로 나아가려 해도 주변 환경이 빠르게 변하니 잡았던 목표가 유명무실해주는 경우가 많았습니다. 팀원 모두가 최소 3개 분야를 병렬로 진행하다 보니, 목표를 세우는 행위 자체가 피로가 됐습니다.
처음에는 폭발적으로 변해가고 있는 개발 시장에서 목표를 정하지 못하고 각자 눈앞에 닥친 일들을 처리해나가는 업무 방식이 당연하다고 느껴졌지만, 이 때문에 목표 관리에 소홀해지니 우리 팀의 최종 목적지와 이번 달에 최소한 어디까지 나아가야 할지를 팀 구성원들이 망각하고 일하게 되는 상황이 펼쳐졌습니다.
그래서 결국, 우리는 TFS팀에도 PM이 필요하다는 결론에 다다르게 되었습니다. 다만 사람 PM이 아닌 ‘AI PM’을요.
그래서, 목표 관리를 AI에게 맡겼습니다
한 가지 짚어두면, 여기서 말하는 PM은 제품의 방향을 정하는 Product Manager가 아니라 팀의 목표와 진척을 챙기는 프로젝트 관리(Project Management)에 가깝습니다.
분명히 같은 팀인데, 각자가 다른 목표를 세우고 그 목표를 향해 저마다 다른 일을 하고 있었습니다. 그러다 보니 옆 사람이 지금 무슨 일을, 왜 하고 있는지 서로 따라가질 못했습니다. 입사 첫 날 데일리 스크럼에서 느꼈던 막막함이, 사실은 저만의 문제가 아니라 팀 전체가 겪고 있던 구조적인 문제였던 거죠. 그 모습을 보면서 저희가 진짜로 깨달은 결론은 따로 있었습니다.
“목표를 더 자주 정해야 한다”가 아니라, “목표 관리 자체도 AI에게 맡겨야 한다.”
각자의 일을 큰 그림에 꿰어 맞추고, 서로 동떨어지지 않게 정렬하는 일 - 그걸 사람이 매주 붙들고 있으면, 결국 누군가는 또 PM노릇을 해야 합니다. 하지만 이 일을 하지 않는다면 TFS팀 전체가 과연 어떤 목표를 달성하기 위해 지금 하고 있는 일을 하는 건지 의문을 가질 거라고 생각했습니다. 그래서 사람이 하기에는 시간을 많이 쓰게 되는 그 역할을, AI에게 맡기기로 하였습니다.
마침 그 무렵 저희 팀장님인 잭이 책 한 권을 권해주셨습니다.
<구글이 목표를 달성하는 방식>이라는 책이었는데, OKR이 어떤 원칙으로 설정되어야 하는지를 다룬 책이었습니다.
읽다 보니 이 원칙들을 사람이 매번 떠올리는 게 아니라, AI가 안내자 역할을 해주면 어떨까 하는 생각이 들었습니다.
그래서 책 내용을 정리해 제가 만든 손석희 봇(TFS팀의 데일리스크럼을 AI Native로 주관하게 만든 슬랙봇)에게 학습시켰습니다. OKR을 어떻게 설계해야 하는지, 큰 목표와 주간 목표가 어떻게 정렬되어야 하는 지의 원칙을, 봇이 매주 인터뷰할 때 기준으로 삼을 수 있도록 말입니다.
저희 팀의 OKR 구조는 단순합니다.
큰 목표 3개(분기마다)
각 목표 밑에 세부 KR 2~3개씩, 총 8개
여기서 KR(Key Results)이란 큰 목표가 얼마나 달성됐는지를 보여주는 구체적인 지표라고 이해하시면 됩니다. 이 여덟 개가 분기 동안 저희 팀이 잊지 말아야 할 좌표입니다. 평소엔 일에 묻혀 눈앞의 것만 보다가도, 이 여덟 개의 KR을 다시 펼쳐보면 우리 팀의 최종 목적지가 또렷해집니다.
AI Native 환경에서 세부 목표는 매주, 매일 빠르게 변했습니다. 하지만 큰 틀의 여덟 개 좌표를 분기 동안 고정해 두고 늘 염두에 두며 일하니, 각자가 다른 일을 하더라도 결국은 공통된 하나의 길로 나아가는 느낌을 받았습니다.
이전까지 서로의 일이 따로 노는 것처럼 느껴졌던 건, 공통의 기준점을 생각하면서 세부 목표를 정하지 않았기 때문입니다. 이제는 같은 여덟 개의 좌표를 모두 공유하고 데일리 스크럼 시간마다 리마인드하면서, 누군가의 일을 들어도 “아, 저건 이 KR을 풀기 위한 일이구나” 하고 같은 지도 위에 올려놓고 볼 수 있게 됐습니다. 세부 목표가 아무리 자주 바뀌어도 모두가 분기 KR만큼은 리마인드하며 그 안에서 방향을 트니, 큰 그림에서 동떨어진 목표가 튀어나오는 일도 사라졌고요. 목표는 여전히 빠르게 바뀌지만, 바뀌는 방향이 전부 같은 좌표를 향하게 된 겁니다.
매주 화요일, TFS 팀원들은 ‘weekly-kr-setup’ 스킬로 이번 주 목표를 정합니다. 인상적인 건 봇이 빈 양식을 던지지 않는다는 점입니다.
봇이 먼저 지난 한 주의 GitHub 커밋/Jira 티켓/구글 캘린더를 훑어 정리
“이 작업들은 아마 이 KR에 해당할 것 같아요”하고 매핑 초안까지 제시
사용자는 그걸 검수만 하면 끝
처음엔 검수조차 귀찮았지만, 한 달쯤 반복하니 깨달음이 왔습니다.
‘분기 목표가 무의미한 게 아니라, 너무 늦게 검증되는 게 문제였구나.’
매주 다시 묻기 때문에 매주 다시 답하게 되고, 그러다 보니 분기 목표가 살아있는 채로 한 주를 살게 됩니다.
매일 일하면, 봇이 알아서 KR에 꽂아줍니다
화요일에 KR 세 개를 정해두면 그 주의 좌표는 잡힙니다. 하지만 좌표는 잡혔어도, 매일의 작업이 정말 그 좌표를 향해 가고 있는지를 확인하는 일은 또 다른 문제입니다. 사실 PM의 일 중 가장 큰 비중을 차지하는 것도 바로 이 추적 노동입니다. 어떤 PR이 어떤 KR에 해당하는지를 사람이 일일이 따라다니며 정리해줘야 하니까요. 저희는 이 부분도 AI에게 맡겨보기로 했습니다.
화요일에 정한 이번 주 KR 3개는 ‘daily-pulse-okr.yaml’에 저장됩니다. 이름은 거창하지만, “이 사람이 이번 주 집중하기로 한 목표 3개”가 적힌 메모지라고 보시면 됩니다. 그리고 ‘daily-pulse’ 에이전트가 흩어진 하루치 활동을 한곳에 모아옵니다.
GitHub PR
로컬 파일
구글 캘린더
Jira
하지만 이건 아직 “어제 뭐 했는지” 나열한 todo 리스트에 불과합니다. 손석희 봇은 여기서 한 걸음 더 나아가, 오늘 한 작업 하나하나를 알맞은 KR에 꽂아줍니다. 문제는 단어만 겹치는지로 판단하면 애매한 작업이 너무 많다는 것, 그래서 두 단계로 거릅니다.
결정론적 점수화 – 규칙에 따라 점수를 매겨 1차 분류
의미 기반 보정 – 점수만으론 애매한 작업을 문맥의 의미로 한 번 더 건져 올림
쉽게 말해 기계적으로 한 번, 의미로 한 번 더 거르는 이중 필터입니다.
그 결과 매일 아침 받게 되는 데일리 리포트가 평탄한 작업 목록이 아니라 KR 단위로 그룹핑된 형태로 정리됩니다. 본인은 그냥 평소처럼 일했을 뿐인데, 그 일이 화요일에 정한 목표 안에 알아서 분류되어 있는 구조입니다. “오늘 뭘 했지”가 아니라 “이번 주 내 KR들이 어디까지 왔지”가 매일 한눈에 보입니다.
11시 45분, 손석희가 회의를 엽니다
KR로 정리된 데일리 리포트, 그리고 손석희 봇이 가장 활약하는 순간은 바로 매일 11시 45분입니다. 사람들은 11시 45분까지 슬랙 채널에 본인의 데일리 리포트를 올리고, 이후 15분 동안 대면이 아닌 비대면으로 회의가 진행됩니다.
매일 11시 45분, 팀원들은 슬랙 채널에 각자의 데일리 리포트를 올립니다. 이후 15분간, 대면이 아닌 비대면으로 회의가 진행됩니다. 그리고 이 회의의 진행자도 사람이 아니라 손석희 봇입니다.
손석희의 기본 원칙은 하나입니다. “회의 진행자는 최대한 회의에 끼어들지 않는다.” 대신 봇이 회의에 기여하는 방식은 크게 두 가지입니다.
리포트를 주제별/KR별로 묶어 보여준다
누가 비슷한 일을 하고 있는지 한눈에 보이니, 그동안 따로 일하던 팀원들이 데일리 스크럼에서 의견을 주고받게 됐습니다. 특히 대면에서는 확실한 맥락 없이 의견을 꺼내기 어려운데, AI가 맥락을 정리해주니 더 편하게 생각을 말하게 됩니다.
도움 요청이 오면, 끼어들지 말지 판단해 초안을 제안한다
예를 들면 이렇게 말입니다.
“OOO님이 회의 일정을 물어보셨습니다. 팀원들 캘린더를 확인하니 이때가 비는데, 이 시간대로 제안할까요?”
저는 그 초안을 보고 그대로 보낼지, 다듬을지, 다른 방향으로 갈지를 정합니다.
이 구조에서 흥미로운 점은 사람과 봇의 역할이 명확하게 나뉜다는 것입니다.
봇은 듣고, 분류하고, 초안을 만든다.
사람은 그 초안을 보고 최종 판단을 내린다.
봇은 회의의 운영을 맡지만, 회의의 흐름을 정하는 책임은 끝까지 사람에게 남습니다.
그래서 PM은 정말 대체될까?
다시 처음의 질문으로 돌아오겠습니다. AI 시대에 PM은 정말 대체될까요?
3개월을 겪어본 제 결론은 “지금 당장 완전히 대체되지는 않는다”입니다. 여전히 사람의 몫인 일들이 있습니다.
우선순위를 두고 사람을 설득하는 일
팀의 방향을 놓고 갈등을 조율하는 일
비즈니스 측과 협상하는 일
손석희 봇도 회의의 흐름을 정하는 책임만큼은 끝까지 저에게 남겨두었습니다.
다만 한 가지는 분명해졌습니다. PM의 일 중에는 – PM이 없는 팀이라면 개발자 각자가 떠안는 일 중에는 – 매번 신경 쓰기엔 번거로워서 자꾸 미뤄지는 운영 노동이 있습니다. 목표를 매주 다시 정렬하고, 내 작업이 어떤 KR에 닿는지 추적하고, 회의를 주제별로 묶어 정리하는 일. 저희는 바로 이 부분을 손석희 봇에게 위임했습니다.
그러자 신기한 일이 일어났습니다. 아무도 “목표를 관리하는 사람”이 되지 않았는데, 팀은 오히려 목표를 더 또렷하게 바라보게 됐습니다.
그래서 저는 “AI가 PM을 대체한다”보다 “AI가 PM의 부담을 덜어준다”가 더 정확하다고 생각합니다.
어쩌면 진짜 질문은 “PM이 대체될까”가 아니라,
“사람이 무엇을 할 때 가장 빛나는가”일지도 모르겠습니다.