마이크로소프트에 입사한 지 7년이 넘었다. 그동안 PM과 개발자 역할의 구분은 늘 명확했다. PM은 고객들의 어려움을 이해하고 해결책을 정의한다. 개발자는 이 해결책을 코딩으로 구현한다. 하지만 PM인 내가 AI를 이용해 실제 서비스 코드를 바꾸고 나서부터 우리 팀에는 혼란이 생겼다.
내가 맡은 업무의 리더들은 모두 내 시도에 열광했다. 더 과감하게 이것저것 해보라며, 개발자들도 실수하는데 너라고 못할 건 뭐냐며, 열심히 실패하면서 열심히 배우고 같은 실수만 반복하지 말라고 했다. 개발 팀장은 내가 안전하게 실패할 수 있도록, 내 실수에 서비스 코드가 쉽게 망가지지 않게끔 하는 조치까지 해줬다.
며칠 전 AMA*에서 누군가가 이런 질문을 했다. “PM이 AI로 코드를 짜는 건 문제가 있다. 속도가 목표라면 PM은 AI로 더 좋은 보고서를 만드는 데 집중해야 하는 거 아닌가. 리더십도 AI가 개발 전문성을 대체 못한다고 했는데 왜 PM한테 구현을 시키는지 모르겠다.”
나를 겨냥한 질문이라고 느꼈다. 우리 팀에서 서비스 코드를 바꾼 PM은 나뿐이니까. 내 시도에 호의적이지 않은 팀원들이 많다는 건 알고 있었다. 네 일이나 잘하지 왜 내 일을 빼앗냐며 열받아하는 개발자들, 이제 코딩까지 해내야 하는 거 아니냐며 불안해하는 PM들. 대충 짐작 정도만 하고 있던 반응이 수면 위로 드러났다. 리더들은 AI 사용을 장려한다는 식의 대답 정도만 하고 넘어갔다. 이 답이 썩 만족스럽지 않던 나는 내가 왜 AI로 코딩을 시작했는지 곱씹어봤다.
PM의 전통적인 프로젝트 진행 방식은 다음과 같다. 유저 인터뷰, 문제점 발견, 해결책 연구, 관련 전문가 자문, 기획서 및 시각 자료 작성, 유저 및 관련 전문가 검토, 수정, 검토, 수정 …. 요즘도 나는 이렇게 일한다. 대신 AI를 이용해 수많은 유저 인터뷰에서 패턴을 찾고 해결책도 같이 의논한다. 기획서 작성 전에 AI로 작동 가능한 시제품부터 만든다. 관계자들은 길고 따분한 기획서보다 직관적인 프로토타입에 반응이 더 좋다. 덕분에 피드백도 더 구체적이고 현실적이다. 모든 피드백을 반영하는 데는 한 시간도 안 걸린다. 예전엔 몇 달씩 걸리던 프로젝트가 지금은 일주일 안에 해결된다.
이때 개발자에게 일을 넘기기 위해서는 AI에게 시제품을 기획서로 써달라고 해야 한다. 개발자는 그 기획서를 보고 코드를 짠다. 낭비다. 그래서 나는 서비스 코드를 직접 바꾼다. 물론, 내가 뭘 하고 있는지 완전히 이해하고 있을 때만.
내가 AI로 코딩을 계속 시도해 보는 건 개발자의 속도가 느려서도, 모든 일을 독차지하려는 욕심 때문도 아니다. AI가 코드를 써준다 한들, 그게 내가 원했던 게 맞는지 확인하는 데 시간이 더 걸릴 수도 있다. 그 검증이 완벽했다고 자신도 못한다. 개발자가 AI를 적극적으로 활용하면 나보다 훨씬 뛰어난 결과를 낼 수 있다.
나는 AI를 활용해 전체적인 일의 효율을 높이는 데 관심이 많다. 어떻게 하면 잘 쓸 수 있을지는 많이 써봐야, 여러 시도를 해봐야 안다. AI가 일자리를 빼앗을까 걱정만 하는 사람은 AI를 어떻게 잘 써먹어볼까 치열하게 고민해보지 않은 사람일 가능성이 높다. AI로 이것저것 적극적으로 해본 사람은 AI가 열어줄 가능성에 설레게 된다.
*우리 팀에서는 한 달에 한 번씩 AMA(Ask Me Anything)라는 시간을 가진다. 한국어로 하면 ‘무엇이든 물어보세요’ 정도가 되겠다. 사원들은 리더들에게 궁금한 점을 게시판에 익명으로 올릴 수 있다. 이 질문은 모든 팀원들이 볼 수 있고 ‘올려요’ 버튼으로 공감을 표현할 수 있다. 팀 리더들은 AMA에서 ‘올려요’ 수가 많은 순서대로 질문에 대답한다.