인텔 특강: AI Engineer vs Data Analyst vs PM 업무 비교

2월 23일에는 직무이해: AI Engineer vs Data Analyst vs PM 업무 비교 특강을 들었다. 네이버에서 ML 엔지니어로 일했고, 지금은 의료 AI 스타트업에서 CTO이자 공동대표로 일하는 분이 맡은 시간이었다. 초반부터 AI 스타트업의 3가지 모자라는 표현이 나왔는데, 실제로 한 사람이 엔지니어링, 데이터 분석, PM 역할을 다 겹쳐 써 본 경험이 바탕에 있다 보니 직무 구분이 훨씬 현실적으로 들렸다.

소개에 #Python #Engineering #Data #Business #Regulation 같은 키워드가 같이 붙어 있었는데, 그 조합 자체가 이번 강의의 결론처럼 느껴졌다. 직무를 나눠 설명하긴 하지만 실제 현장에서는 기술, 데이터, 사업, 규제가 한꺼번에 얽혀 돌아간다는 뜻이었다. 그래서 이번 특강도 “이 직무는 이런 사람이에요” 수준이라기보다, 같은 문제를 세 역할이 어떻게 다르게 보는지를 보여 주는 데 더 가까웠다.

결국 차이는 무엇을 먼저 보느냐였다

이번 강의를 듣고 가장 먼저 정리된 건 세 직무가 다 같은 서비스를 다루더라도 출발점이 다르다는 점이었다. AI Engineer는 기술적으로 무엇을 만들 수 있는지, 모델과 시스템을 어떤 구조로 구현하고 운영할지에 더 가깝다. Data Analyst는 사용자 행동과 지표 안에서 무슨 일이 일어나고 있는지 보고, 그걸 해석해서 다음 판단의 근거를 만든다. PM은 그 둘을 포함해서 “그래서 지금 무엇을 먼저 풀어야 하는가”를 정하고, 여러 사람의 일을 같은 방향으로 묶는 역할에 가깝다.

후반 비교표도 이걸 아주 간단하게 정리해 줬다. AI Engineer는 왜 에러가 나지, Data Analyst는 왜 데이터가 없지, PM은 왜 일정이 밀리지를 먼저 묻는다는 식이었다. 표현은 짧았지만 차이가 명확했다. 셋 다 같은 프로젝트에 있어도, 바라보는 첫 질문이 다르다는 뜻이었다.

AI Engineer 파트는 생각보다 더 현실적이었다

강의 초반 AI Engineer 파트의 제목이 아예 “교과서에 나오는 모델링 vs 현업의 노가다”였다. 이 표현이 좀 세긴 했지만, 하고 싶은 말은 분명했다. 우리가 상상하는 AI 엔지니어는 최신 논문을 읽고, 아키텍처를 설계하고, 하이퍼파라미터를 조정하는 사람에 가깝다. 이상적인 비율도 논문 읽기 20%, 모델 설계 40%, 튜닝 40% 식으로 제시됐다.

그런데 현실은 달랐다. 오히려 데이터 전처리와 정제 70%, API/서버 구축과 배포 20%, 이미 잘 만들어진 모델 활용 10% 쪽에 더 가까웠다. AI Engineer를 생각할 때 모델만 떠올리기 쉬운데, 실제로는 데이터를 다듬고 시스템에 연결하는 시간이 훨씬 많다는 얘기였다.

특히 의료 AI 사례가 강하게 남았다. 인슐린 추천 시스템에서 새벽 3시에 환자 혈당이 급락하는 문제가 있었는데, 겉으로 보면 모델을 더 고도화해야 할 것처럼 보인다. 그런데 실제 원인은 환자가 자다가 센서를 눌러 생긴 PSA 압박 감쇠 현상에 가까웠고, 해결도 최신 딥러닝 모델이 아니라 센서 눌림을 거르는 필터링 로직 쪽이었다고 했다. 강사님이 여기서 “엔지니어링은 최신 기술을 쓰는 게 아니라 문제를 확실하게 해결하는 것”이라고 말한 취지가 아주 선명했다.

Data Analyst는 숫자를 보는 사람이 아니라 숫자로 설득하는 사람이었다

두 번째 파트는 Data Analyst였는데, 이 부분도 오해를 꽤 많이 깨 줬다. 아예 “분석가는 코딩하는 사람이 아닙니다”라는 문장이 있었고, 대신 숫자를 무기로 설득하는 직업이라고 설명했다. 처음엔 이 말이 조금 과한가 싶었는데, 이어지는 예시를 보니 무슨 뜻인지 이해됐다.

분석가의 핵심을 “숫자가 의미하는 바가 무엇인지, 그래서 무엇을 해야 하는지 결정하는 사람”이라고 짚은 부분도 좋았다. 특히 statistically significant와 meaningful의 차이를 구분해야 한다는 대목이 인상적이었다. 통계적으로 유의하다는 말과, 실제 비즈니스나 제품에서 의미 있는 변화라는 말은 다를 수 있다는 얘기였다.

같은 데이터를 누구에게 설명하느냐에 따라 문장이 완전히 달라진다는 예시도 재밌었다. 당화혈색소(HbA1c) 개선 데이터를 개발자에게는 로그와 결측치 없는 정상 수집 데이터로 말할 수 있고, 의사에게는 임상적 효용성 검증으로, 투자자에게는 경쟁사 대비 빠른 시장 진입 가능성으로 설명할 수 있다는 식이었다. 이걸 보고 나니 분석은 숫자를 잘 계산하는 일보다, 숫자의 의미를 상대에 맞게 번역하는 일이 더 크다는 생각이 들었다.

PM은 작은 CEO라기보다 통역사라는 말이 더 맞았다

PM 파트에서 가장 기억에 남는 문장은 “PM은 미니 CEO가 아니라 통역사”였다. 이 표현이 좋았던 건 PM을 거창하게 포장하지도 않고, 그렇다고 단순 조율자로 축소하지도 않았기 때문이다.

개발자의 언어와 비즈니스의 언어를 나란히 놓고 비교한 부분도 기억에 남는다. 개발자는 기술 부채 때문에 리팩토링이 필요하다, 응답 속도를 위해 캐싱 레이어를 도입해야 한다, 현재 구조로는 2주 더 걸린다고 말한다. 반면 비즈니스 쪽에서는 다음 달 마케팅 캠페인 전에 기능이 필요하다, 사용자 이탈률을 줄이기 위해 로딩 속도를 개선해 달라, 경쟁사가 먼저 나오니 출시 일정을 앞당겨야 한다고 말한다.

PM은 그 사이에서 양쪽 말을 다 알아듣고 서로 움직일 수 있는 언어로 다시 바꾸는 사람에 가까웠다. 이 비유가 좋았던 건, PM의 핵심을 회의나 문서가 아니라 번역과 정렬로 설명했기 때문이다. 결국 PM이 잘해야 하는 건 “누가 맞나”를 따지는 게 아니라 “지금 어떤 기준으로 움직일 것인가”를 팀이 납득하게 만드는 일이라는 뜻으로 들렸다.

규제 산업 사례를 들으니 세 역할이 왜 자주 부딪히는지 알 것 같았다

가장 현실적으로 느껴진 파트는 의료 AI 스타트업 사례였다. 개발은 3개월이면 끝나지만, 승인은 식약처 6개월이라는 식의 문장이 있었고, 실제로는 비의료기기 MVP 런칭 -> 인허가 -> 임상 -> 정식 출시 같은 단계로 움직인다고 했다.

이 사례가 좋았던 이유는, 세 직무가 왜 따로 분리해서 생각하기 어려운지가 그대로 보였기 때문이다. AI Engineer는 기능을 구현하고 시스템을 안정화해야 한다. Data Analyst는 어떤 데이터를 수집하고 어떤 지표로 성과를 판단할지 설계해야 한다. PM은 여기서 규제를 피할 수 있는 초기 MVP 범위를 정하고, 언제 유료화 전환을 할지, 인허가 전후에 어디까지 갈지 결정해야 한다. 하나라도 빠지면 프로젝트가 제대로 굴러가기 어렵다.

즉 실제 현장에서는 셋이 병렬로 존재하는 게 아니라, 같은 문제를 서로 다른 언어로 잡아당기고 있는 구조에 더 가깝다. 그래서 한 직무만 알아서는 전체 판단이 어렵다는 말이 설득력 있게 들렸다.

직무 이름보다 더 중요했던 건 결국 How to Work였다

중간부터는 HOW TO WORK라는 표현이 반복해서 나왔다. 이 부분이 이번 특강의 핵심처럼 느껴졌다. 직무 이름은 회사마다 조금씩 달라도, 결국 중요한 건 일의 흐름을 어떻게 가져가느냐는 뜻이었다. 특히 PM, PO, Project Manager가 비슷하게 보이지만 실제로는 다르게 움직인다는 설명도 이 맥락 안에서 들어왔다.

Product Manager, Product Owner, Project Manager를 한 묶음으로 놓고 비교한 부분도 좋았다. 셋이 완전히 같은 역할은 아니고, Product Manager는 제품의 방향과 우선순위를 고민하는 쪽에 가깝고, Product Owner는 백로그와 실행 단위에 더 가까우며, Project Manager는 일정과 조율, 진행 관리에 더 무게가 실린다는 식이었다. 회사마다 섞여 쓰이는 경우도 있지만, 적어도 어떤 책임을 중심에 두느냐는 분명히 다르다는 점이 잘 보였다.

이 설명은 AI Engineer나 Data Analyst를 이해할 때도 도움이 됐다. 결국 어떤 조직이든 직무를 이해하려면 명함에 적힌 이름보다 “이 사람이 어떤 질문을 주로 던지는가”, “어떤 결과에 책임을 지는가”를 먼저 봐야 한다는 뜻으로 들렸기 때문이다.

실제 프로세스 안에서 보면 역할 차이가 더 잘 보인다

중반부에는 Real Process와 Kick-off를 중심으로 실제 협업 흐름을 설명하는 내용이 나왔다. 이 파트가 특히 현실적이었다. 서비스나 기능 하나가 그냥 갑자기 만들어지는 게 아니라, 먼저 어떤 문제가 있는지 정의하고, 왜 이게 필요한지 정리하고, 누가 무엇을 맡을지 나눈 다음, 실행과 검증으로 넘어가는 흐름이 있다는 점을 다시 보여 줬다.

이 과정에서 PM은 전체 맥락을 붙들고 우선순위를 조정하는 역할을 맡고, Data Analyst는 데이터로 지금 상황을 해석하거나 이후 성과를 판단할 기준을 만드는 쪽으로 연결된다. AI Engineer는 실제 구현 가능성과 모델 적용 방식, 품질과 운영 문제를 구체화하는 데 더 가깝다. 결국 셋은 서로 대체 관계라기보다, 같은 프로세스의 다른 구간에서 핵심 역할을 맡는 구조처럼 보였다.

개인적으로는 이 부분이 가장 도움이 됐다. 취업 준비를 할 때는 직무 이름만 보고 완전히 다른 길이라고 생각하기 쉬운데, 실제 협업 장면으로 놓고 보면 세 역할은 훨씬 더 자주 부딪히고 섞인다. 그래서 어느 직무를 목표로 하더라도, 나머지 둘이 무엇을 중요하게 보는지는 반드시 알아야 한다는 생각이 들었다.

비교표 한 장이 생각보다 많은 걸 정리해 줬다

후반부 직무별 핵심 비교도 기억에 남는다. 도구도 각각 달랐다. AI Engineer 쪽에는 Python, Docker, Cloud, Data Analyst 쪽에는 SQL, Tableau, Excel, PM 쪽에는 Jira, Notion, Slack이 놓여 있었다. 기여 방식도 달랐다. AI Engineer는 모델 성능과 시스템 안정성, Data Analyst는 인사이트와 지표, PM은 출시 품질과 일정 쪽에 더 가까웠다.

커리어 방향 비교도 재밌었다. AI Engineer는 CTO/Tech Lead, Data Analyst는 CDO/Growth Lead, PM은 CPO/CEO 쪽으로 연결해서 보여 줬는데, 이걸 보니 단순히 당장 하는 업무만 다른 게 아니라 장기적으로 키우는 관점도 달라진다는 게 보였다.

비전공자 전략은 꽤 직설적이었다

이 강의가 좋았던 또 하나의 이유는 비전공자에게 지나치게 낭만적인 말을 하지 않았다는 점이다. 아예 "코딩 실력으로 승부하지 마세요"라는 문장이 있었다. 처음 보면 좀 과격해 보일 수 있는데, 이어지는 설명이 현실적이었다. 코딩 진입장벽은 ChatGPT나 Copilot 같은 도구 때문에 점점 낮아지고 있고, 속도전으로 전공자와만 경쟁하면 불리할 수밖에 없다는 것이다.

대신 비전공자의 과거 경험과 도메인 이해를 더 큰 무기로 봤다. 의료, 금융, 고객 심리, 운영, 현장 프로세스처럼 이미 알고 있는 세계를 AI와 연결하는 능력이 더 중요하다는 식이었다. 무턱대고 “전공자가 아니어도 괜찮다”는 말이 아니라 “그 대신 네가 이미 알고 있는 걸 어떻게 활용할 건데?”라고 묻는 쪽에 가까웠다.

포트폴리오는 하나의 프로젝트를 세 관점으로 써 보라는 조언이 인상적이었다

후반에는 One Project, Three Views라는 표현이 나왔다. 프로젝트를 하나 했더라도 그걸 Engineering, Analysis, PM 세 관점으로 각각 설명해 보라는 조언이었다. 이 부분은 정말 실용적이었다.

예를 들어 같은 프로젝트라도 엔지니어링 관점에서는 어떤 구조를 설계했고 어떤 기술적 갈등을 해결했는지 쓸 수 있다. 분석 관점에서는 어떤 데이터를 보고 어떤 인사이트를 발견했는지 정리할 수 있다. PM 관점에서는 어떤 우선순위를 잡았고, 어떤 팀 조율을 했고, 어떻게 런칭을 밀어붙였는지 풀 수 있다. 하나의 경험을 더 입체적으로 보여 줄 수 있다는 점에서 꽤 좋은 조언이었다.

강의 마지막에 나온 지금 당장 해야 할 3가지도 비슷한 결이었다. 관심 과정을 좁히고, 더러운 데이터를 직접 만지고, 실패와 삽질까지 기록하라는 말이었다. 깔끔하게 정리된 성공 사례보다, 정제되지 않은 데이터를 다뤄 본 경험과 그 과정에서 무엇을 배웠는지가 오히려 더 강한 포트폴리오가 될 수 있다는 이야기였다.

AI를 쓰는 법도 직무별로 다를 수밖에 없었다

중간 이후에는 HOW TO USE AI, Tips for Using AI 같은 내용도 따로 나왔다. 이 부분도 단순히 “AI를 써라”는 얘기로 끝나지 않아서 좋았다. 직무마다 AI를 쓰는 방식도 다를 수밖에 없다는 게 핵심이었다.

AI Engineer에게 AI는 구현 속도를 높이거나 실험 아이디어를 정리하는 보조 도구일 수 있지만, 결국 마지막 판단은 성능과 구조 이해 위에서 내려야 한다. Data Analyst에게는 데이터 탐색, 쿼리 초안 작성, 지표 해석 보조 같은 쪽이 될 수 있지만, 숫자를 읽는 맥락까지 대신해 주지는 못한다. PM에게는 PRD 초안 작성, 리서치 정리, 회의 구조화, 아이디어 정리 같은 데 도움을 줄 수 있지만, 우선순위를 정하고 팀을 설득하는 책임까지 가져가 주진 않는다.

이 설명을 듣고 나서 AI 활용 능력도 결국 직무 기본기가 있어야 의미가 있다는 생각이 들었다. AI를 잘 쓰는 사람은 단순히 프롬프트를 잘 쓰는 사람이 아니라, 무엇을 물어봐야 하고 어떤 답은 걸러야 하는지 아는 사람이라는 얘기였다.

앞으로의 일자리는 더 섞이고 더 압축될 것 같았다

마지막 파트는 Market Shifts, Future Job, Quantity < Quality, AI Leverage, Native Value 같은 키워드로 정리됐다. 이 부분은 직무 소개를 넘어 앞으로 어떤 사람이 더 유리해질지를 말하는 내용에 가까웠다.

내가 이해한 핵심은 이랬다. 예전처럼 역할을 아주 잘게 나눠서 사람을 많이 두는 방식보다, 앞으로는 AI를 잘 활용하면서도 본질적인 판단을 할 수 있는 사람이 더 중요해질 수 있다는 것. 양보다 질이 중요해지고, 단순 반복 업무보다 맥락을 이해하고 연결하는 능력이 더 비싸질 수 있다는 이야기였다. 그래서 강의에서는 AI를 잘 쓰는 사람과, 애초에 AI 시대의 방식에 익숙한 사람 사이의 차이도 암시하고 있었다.

결국 AI Engineer, Data Analyst, PM 중 어느 길을 가더라도 앞으로 더 중요해질 건 비슷해 보였다. 도구를 다루는 것만이 아니라, 문제를 구조화하고, 근거를 만들고, 다른 직무와 연결해서 결과를 내는 능력이다. 직무 이름은 달라도 살아남는 사람의 기준은 점점 비슷해질 수도 있겠다는 생각이 들었다.

들으면서 남긴 내 생각

이번 2월 23일 특강은 직무를 고르는 데도 도움이 됐지만, 그보다 “직무를 어떤 방식으로 이해해야 하는가”를 다시 보게 한 강의였다. 나도 예전에는 AI Engineer, Data Analyst, PM을 꽤 분리된 길처럼 봤는데, 이번에는 셋이 결국 같은 제품과 같은 문제를 서로 다른 위치에서 다루는 관계라는 점이 더 크게 남았다.

특히 좋았던 건 AI Engineer 파트에서 멋있는 모델링보다 데이터 정제와 시스템 연결이 훨씬 크다고 솔직하게 말해 준 점, Data Analyst를 숫자를 계산하는 사람이 아니라 숫자로 조직을 설득하는 사람으로 설명한 점, PM을 작은 CEO가 아니라 기술과 비즈니스 사이의 통역사로 정리한 점이었다. 세 문장만으로도 직무 차이가 꽤 또렷해졌다.

결국 이번 특강을 듣고 정리한 한 문장은 이것이다. 어떤 직무를 택하든, 자기 역할만 아는 사람보다 일의 전체 흐름을 이해하는 사람이 더 강하다. 그리고 비전공자라면 남들보다 부족한 것을 세는 데 시간을 쓰기보다, 이미 알고 있는 도메인과 새 기술을 어떻게 연결할지부터 정하는 편이 훨씬 낫다. 2월 23일 특강은 그걸 꽤 실무적인 언어로 보여 준 시간이었다.