화면 앞에 앉아 AI 코딩 에이전트에게 “로그인 페이지에 소셜 로그인 버튼을 추가해줘”라고 입력합니다. 몇 초 뒤 코드가 통째로 만들어집니다. 예전 같으면 개발자에게 스펙 문서를 넘기고, 화면 설계서를 그리고, 리뷰를 몇 차례 주고받아야 나왔을 결과물입니다. 이 장면을 지켜본 사람이라면 자연스럽게 다음 질문이 따라옵니다. “그럼 이제 PM은 뭘 해야 하나요?”
v0, Lovable, Bolt.new처럼 자연어 지시와 와이어프레임을 곧바로 풀스택 코드로 만들어주는 AI 도구가 보급되면서, 실리콘밸리 프로덕트 커뮤니티에서는 이 질문에 답하기 위한 새로운 표현이 등장했습니다. 바로 컨텍스트 엔지니어링(context engineering)입니다. 레니의 뉴스레터(Lenny’s Newsletter)를 비롯해 마티 케이건, 테레사 토레스 같은 프로덕트 매니지먼트 논객들의 논의를 통해 이 표현은 빠르게 퍼졌고, Product School 같은 교육 플랫폼은 이미 AI PM 전용 커리큘럼까지 만들었습니다.
컨텍스트 엔지니어링이란, AI 에이전트가 올바른 결과를 내놓을 수 있도록 필요한 배경 정보와 제약 조건, 과거 결정의 맥락을 체계적으로 구성해서 제공하는 작업을 말합니다. 여기서 말하는 배경 정보는 단순히 무엇을 만들어라라는 지시 한 줄이 아닙니다. 이 제품이 왜 만들어졌는지, 어떤 사용자를 위한 것인지, 과거에 어떤 선택을 했고 왜 그 선택을 했는지, 지금 건드리면 안 되는 영역은 어디인지까지 포함하는 전체 그림입니다.
컨텍스트 엔지니어링은 프롬프트 엔지니어링과 자주 혼동되지만, 업계 논의에서는 이 둘을 분명히 다른 스킬로 구분합니다. 프롬프트 엔지니어링이 AI에게 지시를 잘 내리는 한 줄의 기술에 가깝다면, 컨텍스트 엔지니어링은 AI가 작업을 수행하는 데 필요한 문서, 예시, 제약 조건, 의사결정 이력 전체를 설계하고 정리하는 작업입니다. 프롬프트를 잘 쓰는 사람은 많아졌지만, 그 프롬프트가 참조할 배경 정보 자체를 정확하고 일관되게 관리하는 역할은 여전히 사람의 몫으로 남아 있고, PM 커뮤니티는 바로 이 지점을 PM의 새로운 역할로 지목하고 있습니다.
AI 코딩 도구와 에이전트가 실제 코드를 짜는 비중이 늘어나면서, PM이 맡아온 정확한 스펙 문서를 써서 개발자에게 전달한다는 업무 자체가 줄어들고 있는 것은 사실입니다. 스펙 문서 작성, 화면 설계서 정리, 개발자와의 커뮤니케이션 조율처럼 PM의 업무 시간을 상당 부분 차지해온 일들이 AI로 대체되기 시작하면, 그럼 PM이라는 역할 자체가 왜 필요한가라는 질문이 나오는 것도 당연합니다. 채용 시장에서 PM의 역할과 채용 기준이 흔들린다는 감각을 가진 사람이 많은 것도 이런 배경 때문인 듯합니다.
반대로 PM 커뮤니티에서는 지금 더 우세한 논조가 있습니다. AI가 코드를 짜준다고 PM이 필요 없어지는 것이 아니라, 오히려 무엇을 만들지, 왜 만들지, 어떤 맥락에서 만들지를 판단하는 역할이 더 중요해진다는 주장입니다. 코드를 만드는 실행 단계의 병목이 풀릴수록, 그 앞단에 있는 무엇을 만들 것인가라는 판단의 병목이 상대적으로 더 크게 드러나기 때문입니다. AI 에이전트는 주어진 맥락 안에서는 빠르고 정확하게 움직이지만, 그 맥락 자체를 설계하고 우선순위를 정하고 잘못된 방향을 잡아내는 일은 여전히 사람의 판단이 필요한 영역입니다.
두 주장은 서로 반대처럼 보이지만 실제로는 같은 현상을 다르게 해석한 것에 가까운 것 같습니다. PM의 업무 중 문서를 써서 전달하는 실행형 업무는 줄어들고, 무엇을 왜 어떤 맥락에서 만들지 판단하고 그 판단을 AI가 이해할 수 있는 형태로 구조화하는 업무의 비중은 늘어나는 방향으로 역할 자체가 재편되고 있다고 보는 쪽이 지금까지 나온 논의에 더 가깝습니다.
이 변화 앞에서 PM이 지금 당장 점검해볼 만한 것이 있습니다. 자신이 쓰는 문서가 사람만을 대상으로 하는지, 아니면 AI 에이전트가 참조해도 헷갈리지 않을 만큼 배경과 제약이 명시되어 있는지부터 돌아볼 만합니다. 왜 이 기능을 이렇게 만들기로 했는가라는 결정의 이유를 기록해두는 습관은, 예전에는 신규 팀원 온보딩을 위한 것이었다면 이제는 AI 에이전트의 판단 정확도를 좌우하는 입력값이 됩니다. 여기에 더해 실행 속도가 빨라진 만큼 방향을 잘못 잡았을 때의 손실도 커진다는 점을 감안해서, 무엇을 먼저 검증하고 무엇을 나중으로 미룰지에 대한 판단 기준도 더 명확히 세워둘 만합니다.
PM을 채용하거나 평가하는 대표 입장이라면, 이제 스펙 문서를 얼마나 꼼꼼하게 쓰는가보다 이 사람이 왜 이 결정을 내렸는지 설명할 수 있는가, 그 맥락을 팀과 AI 도구 모두가 이해할 수 있게 정리할 수 있는가를 평가 기준에 넣어볼 만합니다. 지금 여러분의 PM 조직에서는 스펙 문서를 쓰는 시간과, 왜 그렇게 결정했는지를 기록하는 시간 중 어느 쪽이 더 깁니까. 그 답이 지금 조직이 어느 방향으로 준비되어 있는지를 보여주는 첫 번째 신호입니다.
그 다음 걸음을, 함께
다음 성장은, 여기서 시작됩니다.