Andrew Ng의 AI Engineering Skills Map: 제품 개발 방향을 정하는 역량(Shaping the build)

9bow · 9월 26, 2026, 12:00오후

AI 엔지니어가 제품 개발 방향에도 참여하는 이유

Andrew Ng가 설명한 AI Engineering Skills Map의 마지막 축은 개발 방향 설정(shaping the build) 입니다. 구현 속도가 빨라진 만큼 개발자는 주어진 명세를 코드로 옮기는 데 그치지 않고, 어떤 문제를 먼저 풀고 어떤 결과를 확인할지 결정하는 과정에도 참여할 수 있습니다. 이 글은 전체 역량 지도 소개에서 시작한 연재의 마지막 원문을 다룹니다.

원문은 기존의 제품 관리자(PM), 디자이너, 개발자 사이의 역할 경계가 흐려지고 있다고 설명합니다. AI 엔지니어링을 이해하는 개발자는 제품 결정에 더 많이 참여하고, 제품 관리자와 디자이너도 AI 도구를 이용해 구현에 참여할 수 있습니다. 모든 개발자가 다른 직무를 대신해야 한다는 주장은 아닙니다. 사용자 문제와 기술적 가능성을 함께 살펴보는 사람이 개발의 다음 단계를 더 빠르게 정할 수 있다는 설명에 가깝습니다.

Ng는 이 역할을 개발 반복 주도, 제품 결정, 소통과 리더십, 주도적인 책임감의 네 역량으로 정리합니다. 앞서 다룬 AI 애플리케이션 구축과 운영, 소프트웨어 기본기, 코딩 에이전트 활용을 제품의 가치와 연결하는 단계입니다.

개발 반복을 이끄는 일은 다음에 배울 것을 정하는 일입니다

개발 반복 주도(driving the build loop) 에서는 코드를 만들고 피드백을 받아 다음 작업을 결정하는 과정을 이끕니다. 원문은 기술적 가설을 확인할 작은 프로토타입, 사용자를 만나기 위한 최소 기능 제품(MVP), 기능 추가, 기업 환경에 맞춘 시스템 구축을 서로 다른 단계의 선택지로 제시합니다. 무엇을 먼저 할지는 제품 비전, 현재 단계, 기술적 가능성, 위험, 시간과 예산에 따라 달라집니다.

예를 들어 업무 문서를 찾아 답하는 AI 기능을 구상한다면, 첫 단계에서 전체 권한 체계와 모든 문서 형식을 구현할 필요는 없을 수 있습니다. 제한된 문서로 검색 품질을 검증한 뒤 사용자가 답의 출처를 이해하는지 살펴보고, 그 결과에 따라 제품 범위를 정할 수 있습니다. 반대로 실제 고객의 기밀 문서를 다루는 단계라면 접근 통제와 오류 대응을 뒤로 미루기 어렵습니다. 이 사례는 원문의 판단 기준을 설명하기 위해 덧붙인 것입니다.

Ng는 작은 단위로 자주 출시하고, 필요할 때 사용자와 이해관계자의 의견을 듣거나 기술 실험을 하라고 설명합니다. 성숙한 제품에서는 개선하려는 핵심 지표를 정의하고 그 변화를 관리하는 능력도 필요합니다. 빠르게 만드는 행위 자체보다 어떤 불확실성을 줄였는지에 주의를 기울이는 접근입니다.

제품 감각은 명세에 없는 결정을 다루는 데 필요합니다

제품 결정(making product decisions) 은 개발자가 제품 관리자 역할을 모두 맡아야 한다는 뜻이 아닙니다. 명세가 비어 있거나 세부 상황을 다루지 못할 때, 사용자에게 필요한 방향을 제안하고 요구사항을 정리할 수 있어야 한다는 의미입니다. 원문은 사용자 요구를 읽는 감각, 사용하기 좋은 화면을 판단하는 기본적인 디자인 감각, 시장과 비용을 이해하는 사업 감각을 함께 언급합니다. 사업 감각에는 시장 진입 방식, 시장 규모, 고객당 수익성과 비용, 손익을 따져 선택하는 일도 포함됩니다.

사용자 공감은 추측만으로 생기지 않습니다. Ng는 사용자 2~3명과의 빠른 비공식 인터뷰부터 수백 명을 대상으로 한 설문, 대규모 A/B 테스트, 많은 사용자의 행동 분석까지 여러 방법을 제시합니다. 여기서 숫자는 조사 결과가 아니라 상황에 따라 택할 수 있는 조사 규모의 예시입니다. 작은 인터뷰는 문제의 맥락을 이해하는 데, 행동 데이터는 이미 배포한 기능의 사용 양상을 살피는 데 쓰일 수 있습니다.

AI 기능은 데모에서 인상적인 답변을 내놓더라도 사용자가 실제 업무를 끝내는 데 도움이 되지 않을 수 있습니다. 따라서 정답률 외에도 사용자가 결과를 신뢰할 수 있는지, 수정할 수 있는지, 실패했을 때 다른 경로로 일을 마칠 수 있는지를 물어야 합니다. 이런 질문은 제품 판단을 기술 선택과 연결합니다.

소통은 여러 직무의 제약을 한 결정으로 모읍니다

소통과 리더십(communicating and leading) 이 중요한 이유는 AI 엔지니어가 더 넓은 작업에 참여하기 때문입니다. 원문은 마케팅, 재무, 법무 등 프로젝트에 영향을 주는 다른 기능 조직과의 협업을 예로 듭니다. 기술적으로 가능한 구현이라도 출시 일정, 비용, 개인정보 처리, 고객 안내 조건과 맞지 않으면 제품으로 제공하기 어렵습니다.

개발자는 모델의 한계와 구현 비용을 이해관계자가 판단할 수 있는 말로 설명할 수 있어야 합니다. 반대로 다른 직무가 제시한 요구를 기술 작업으로 옮길 때도, 무엇이 반드시 필요한 조건이고 무엇이 추후 검토 가능한 선택인지 확인해야 합니다. 사용자와의 대화 역시 같은 소통 역량의 일부이며, 제품 판단의 근거가 됩니다.

원문은 AI 기술이 빠르게 바뀌면서 비개발 직무도 기술의 가능성과 업무 영향을 이해하려 한다고 설명합니다. 이때 엔지니어는 막연한 가능성을 약속하기보다, 현재 가능한 범위와 검증이 필요한 가정을 구분해 조직의 결정을 도울 수 있습니다.

주도적인 책임감은 조직의 우선순위 안에서 발휘됩니다

주도적인 책임감(high-agency ownership) 은 누군가 완전한 지시를 내릴 때까지 기다리지 않고 문제를 발견하고, 해결안을 제안하고, 실행 결과를 책임지는 태도입니다. Ng는 기술이 무엇을 할 수 있는지 조직의 의사결정자가 아직 알지 못할 수 있다는 점을 지적합니다. 현장의 개발자가 사용자 문제와 기술적 기회를 함께 볼 때 새로운 과제를 제안할 여지가 생깁니다.

그렇다고 마음대로 범위를 넓히라는 뜻은 아닙니다. 원문은 조직의 우선순위와 제약을 존중하면서 행동할 것을 명시합니다. 중요한 문제를 고르고, 모호한 상황에서도 필요한 정보를 모으며, 실패가 생기면 원인을 해결하고, 완료한 작업의 수보다 만들어 낸 가치를 기준으로 결과를 평가해야 합니다.

이 역량은 한 번의 프로젝트로 끝나지 않습니다. 새로운 도구를 익히고 작업 방식을 조정하며, 무엇이 효과가 있었는지 되돌아보는 학습이 필요합니다. 앞선 세 편에서 다룬 기술적 판단이 제품의 목표와 만나는 지점이 바로 여기입니다.

네 가지 역량을 함께 적용할 때 개발의 다음 단계가 선명해집니다

이 연재의 네 축은 서로 경쟁하는 역할 목록이 아닙니다. AI 애플리케이션을 만들고 평가하는 역량은 무엇이 기술적으로 가능한지 보여줍니다. 소프트웨어 기본기는 이를 실제 서비스의 제약 안에 놓고, 코딩 에이전트 활용은 구현과 검증의 반복을 돕습니다. 개발 방향 설정은 그 결과를 사용자에게 필요한 가치와 연결합니다.

Ng의 마지막 글을 실무 질문으로 옮기면 간단합니다. 지금 만들 기능이 어떤 사용자 문제를 풀고, 다음 작은 실험으로 무엇을 확인하며, 그 결과를 바탕으로 누가 어떤 결정을 내릴 것인가입니다. 이 질문에 답할 수 있을 때 구현 속도는 제품을 개선하는 속도로 이어집니다.

제품 개발 방향 설정 역량 원문

AI Engineering Skills Map 전체 개요 원문

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임은 이런 글들을 한국어로 정리해 나누고 있습니다. 회원으로 가입하시면 주요 글들을 이메일로 보내드리고, 텔레그램(Telegram)과 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 다음 글을 정리하는 데 힘이 됩니다~