AI/ML 엔지니어로 2~3년 뒤 이직할 때, 'AI 툴 활용 신규 제품팀(Python)'과 '대규모 코어 시스템팀(C#)' 중 어디가 유리할까요?

📌 오늘의 안건
AI/ML 엔지니어로 2~3년 뒤 이직할 때, 'AI 툴 활용 신규 제품팀(Python)'과 '대규모 코어 시스템팀(C#)' 중 어디가 유리할까요?

8월 인턴 배치를 앞두고 부서 선택을 고민 중입니다. 정규직 전환 예정이고, 2~3년 근무 후 AI/ML 엔지니어 직무로 이직하는 것이 목표입니다. 이직 판단 기준은 다음 이직처의 연봉·회사 규모 등 조건입니다.

선택지는 두 곳입니다.

1. AI 사업부 (Python)
2. LLM을 직접 연구·개발하는 조직이 아니라, 상용 AI 코딩 툴을 활용해 신규 제품을 만드는 팀입니다.
3. 개발 2주 차 초기 프로젝트라 고객이 없고 운영 경험을 쌓기 어렵습니다.
4. 아키텍처·설계를 대부분 AI에 맡기는 방식이라고 들었고, 실제로 해당 부서 재직자분들로부터 오지 말라는 조언을 받았습니다.

2. 웹 부서 (C#)
3. 대규모 코어 시스템을 다루며 트래픽·운영 경험과 아키텍처 경험을 쌓을 수 있습니다.
4. 다만 언어가 C#이라 AI/ML 직무의 주력 스택(Python)과 어긋납니다.

궁금한 점은 다음과 같습니다.

• AI/ML 엔지니어 채용에서 'Python으로 AI 툴을 붙여 제품을 만든 경험(단, 사용자·운영·설계 경험 부족)'과 'C#으로 대규모 시스템을 설계·운영한 경험' 중 어느 쪽이 더 강한 신호인가요? 특히 연봉·회사 규모가 좋은 곳으로 갈 때 기준입니다.
• 언어 스택 불일치(C#)는 2~3년 차 이직에서 실제로 얼마나 큰 감점 요인인가요? 사이드 프로젝트나 개인 학습으로 메울 수 있는 수준인가요?
• 반대로 '고객 없는 초기 프로젝트 + 설계를 AI에 위임'하는 환경에서 2~3년을 보낼 때, 경력기술서에 남길 만한 것이 실제로 남는지 궁금합니다.
• 현직자가 직접 만류한 부서라는 점은 의사결정에서 어느 정도 가중치를 둬야 할까요?

드러커입니다. 저는 '어느 쪽이 덜 나쁜가'가 아니라 '어느 자리에서 무엇을 기여하고 무엇을 남길 수 있는가'를 묻겠습니다.

역린입니다. 저는 잘 풀렸을 때가 아니라 최악으로 갔을 때 무엇이 남는지, 그리고 질문 속에 이미 깔린 전제부터 의심하겠습니다.

카네기입니다. 저는 웅대한 계획보다 오늘 첫 삽을 뜰 수 있는 계획을 신뢰합니다 — 이번 건도 '실제로 해낼 수 있는가'와 '들인 품값을 하는가'만 끝까지 따지겠습니다.

결날입니다. 저는 커리어를 표가 아니라 하루하루의 결로 봅니다 — 두 부서에서 보낼 2~3년이 실제로 어떤 감각일지를 책임지고 들여다보겠습니다.

역결입니다. 저는 방 안의 모두가 고개를 끄덕이는 대목에서 가장 크게 의심합니다 — 이번 질문에 깔린 전제부터 하나씩 뒤집어 보겠습니다.

긴줄입니다. 저는 한 번의 이직이 아니라 10년 뒤 남는 축적을 봅니다 — 두 선택이 각각 어떤 복리를 만드는지 시간축을 길게 늘여 보겠습니다.

결론: 방어적으로는 2번 웹 부서(C# 대규모 코어 시스템팀)를 고르겠습니다. 상위 연봉·큰 회사의 AI/ML 엔지니어 채용 신호는 “AI라는 이름”보다 운영 중인 시스템을 안정적으로 설계·배포·관측·확장한 증거입니다. OpenAI의 ML Infra 공고도 모델 자체보다 “train/deploy/serve/monitor”, “high-throughput, low-latency”, “reliability”를 요구하고, 다른 인프라/ML 시스템 공고도 distributed systems, observability, scalability를 반복합니다.

출처: OpenAI ML Infrastructure openai.com[1] , Platform Systems openai.com[2] , Distributed Data Systems openai.com[3]

C# 감점은 있습니다. 특히 2~3년 차에서 Python/PyTorch 실무가 전혀 없으면 ML Engineer 서류에서 “일반 백엔드 개발자”로 분류될 위험이 큽니다. 하지만 이 감점은 사이드 프로젝트만으로 완전히 상쇄되지는 않아도, “Python + PyTorch/LLM serving + 데이터 파이프라인 + 평가/모니터링” 포트폴리오를 꾸준히 만들면 방어 가능합니다. 반대로 1번의 최악 시나리오는 더 치명적입니다. 고객 없음, 운영 없음, 설계를 AI에 위임하면 2~3년 뒤 경력기술서에 남는 문장이 “AI 코딩 툴로 초기 제품 개발” 수준에서 멈출 수 있습니다. 이건 상위 회사가 사는 신호가 아니라 오히려 “본인이 설계 판단을 했는가?”라는 의심을 부릅니다.

현직자 만류는 결정적 단일 근거는 아니지만, 이 경우에는 강한 음성 신호로 봐야 합니다. 특히 “초기 프로젝트”, “고객 없음”, “AI가 설계”, “내부자가 오지 말라 함”이 동시에 있으면 꼬리 위험이 큽니다. 선택지는 2번이 낫습니다. 단, 2번을 고른 뒤에도 그냥 C# 백엔드로 3년 보내면 ML 이직은 약합니다. 방어책은 명확합니다: 본업에서는 트래픽·장애·아키텍처 성과를 숫자로 만들고, 별도로 Python/PyTorch/LLM 서빙·RAG·모델 평가·MLOps 프로젝트를 공개 산출물로 쌓아야 합니다. “AI 툴을 썼다”보다 “대규모 시스템을 운영했고 ML 스택도 직접 구현했다”가 더 강한 조합입니다.

결론: 웹 부서(C#). 단, "C#으로 대규모 시스템을 운영한 사람"이 아니라 "트래픽·데이터 파이프라인·서빙을 설계해본 사람"으로 이력을 재편할 것을 전제로 한다.

핵심 질문은 "어느 부서가 좋은가"가 아니라 "어느 자리가 2~3년 뒤 경력기술서에 숫자로 남는 산출물을 만들어주는가"다. 채용 시장은 이미 답을 준다. 2026년 ML 엔지니어 채용의 무게중심은 연구가 아니라 프로덕션이다 — 컨테이너·K8s·CI/CD·클라우드·모델 라이프사이클 관리가 요건의 중심이고, MLOps 역량은 기본급에 25~40% 프리미엄을 얹는다(365 Data Science[1], doit.software[2]). 연봉·규모가 좋은 자리일수록 이 경향은 더 극단적이다.

Samsara의 Staff ML Infra, GM의 Senior ML Infrastructure(Inference Platform, $155k~$206k) 같은 상단 포지션의 요건은 Ray/Spark 분산 처리, 대규모 학습·서빙 인프라, 클라우드 관측성이지 "Python으로 API를 붙여봤다"가 아니다(Samsara[1], GM Careers[2]). 대규모 트래픽·장애·아키텍처 경험은 언어와 무관하게 전이되는 자산이고, "상용 AI 툴로 만든 고객 없는 제품"은 전이되지 않는다. 후자는 2~3년 뒤 그 툴이 바뀌면 잔존가치가 0에 수렴한다.

언어 불일치는 감점이 아니라 번역 문제다. 2~3년 차 채용에서 보는 건 "Python 문법을 아는가"가 아니라 "p99 레이턴시를 어떻게 잡았는가, 초당 몇 건을 어떤 구조로 처리했는가"다. C# 문법은 면접 전 2주면 메우고, 시장이 보상하는 건 그 밑의 시스템 감각이다. 다만 방치하면 진짜 감점이 되므로 근무 기간 중 다음을 명시적 산출물로 만들어라. (1) 코어 시스템의 로그·이벤트를 다루는 데이터 파이프라인 업무를 자원해서 가져올 것 — Kafka/배치/스토리지는 언어 중립이고 그대로 ML 파이프라인 경력이 된다. (2) 사내에서 추천·이상탐지·검색 랭킹 같은 실트래픽 ML 기능을 하나 붙이고 Python 서빙 계층을 본인이 소유할 것 — 이게 있으면 "C# 백엔드"가 아니라 "대규모 시스템에 ML을 태워본 엔지니어"가 된다. (3) Docker/K8s/클라우드 배포와 모니터링을 본인 이름으로 끝낼 것. 사이드 프로젝트로는 (3)만 보완 가능하고 (1)(2)는 실트래픽이 있는 자리에서만 만들어진다 — 그래서 자리 선택이 중요하다.

현직자의 만류는 가장 신뢰도 높은 신호이고, 여기서는 다른 근거와 방향이 일치하므로 결정적 가중치를 준다. 내부인은 외부인이 볼 수 없는 조직의 지속성·평가·업무 배분을 안다. 게다가 그 부서의 구조적 문제 — 고객 부재, 설계의 AI 위임 — 는 개인의 노력으로 뒤집을 수 없는 종류다. 고객이 없으면 트래픽·장애·의사결정 데이터가 없고, 설계를 위임하면 "왜 그렇게 만들었나"라는 면접의 핵심 질문에 답할 소재가 남지 않는다. 되돌릴 수 있는지도 보라. 웹 부서 → AI 직무는 되돌릴 수 있고(시스템 자산 위에 ML을 얹으면 됨), AI 부서에서 2년간 산출물 없이 보낸 시간은 되돌릴 수 없다. 웹 부서를 택하되, 첫날부터 "나는 이 회사에서 ML을 프로덕션에 태우는 사람이 된다"고 선언하고 그 방향의 업무를 계속 요구하라. 기여할 지점을 스스로 정의하는 것이 자리를 강점으로 바꾸는 유일한 방법이다.

카네기 렌즈(실행가능성·비용 대비 효과)로 판단합니다. AI/ML 채용에서 어떤 경력이 실제로 연봉·규모에 먹히는지 먼저 확인합니다.## 결론: 웹 부서(C#)을 택하고, Python·AI는 사이드에서 메워라.

좋은 연봉·큰 회사의 AI/ML 채용은 “AI 툴을 써서 무언가 만들었다”보다 프로덕션에서 시스템을 설계·운영·검증한 증거를 산다. 2026년 채용 가이드도 LangChain·툴 나열 이력은 신호 약화, eval·비용·관측·장애 모드 같은 운영 신호가 차별화 요인이라고 명시한다. 고연봉 AI 역할도 소프트웨어 엔지니어링·프로덕션 ML/배포·시스템 설계를 장벽으로 둔다. 따라서 (1) 고객 없고 설계를 AI에 맡기는 초기 제품팀 2~3년보다, (2) 대규모 코어의 트래픽·운영·아키텍처 2~3년이 이직 면접에서 더 강한 신호다. C# 스택 불일치는 감점 가능하나 치명적이지 않다—언어·프레임은 주당 8~12시간×2~3년 사이드(파이프라인·서빙·평가 지표가 있는 작은 프로덕션형 프로젝트 1~2개)로 메울 수 있는 수준이고, 반대로 고객·SLA·설계 소유권 없는 2~3년은 사이드로 메우기 어렵다.

• 신호 비교: “Python+AI 툴, 사용자·운영 없음” ≪ “C# 대규모 설계·운영” — 후자가 연봉·규모 이직에서 유리.
• C# 감점: 2~3년 차에서 메울 수 있음. 메우기 힘든 것은 운영·설계 경험.
• AI 사업부 경력기술서: 고객·지표·설계 결정이 없으면 “툴 사용 데모”로 읽히기 쉽고, 채용 측 red flag(프레임워크 의존·수치 없음)에 가깝다.
• 현직자 만류: 가중치 매우 높음. 같은 사다리를 밟은 사람의 “시간 대비 산출이 안 나온다”는 말은, 기회 비용 계산의 1차 데이터다. 그 조언을 무시하고 2~3년을 쓰는 비용은 복구하기 비싸다.

실행 가정(합리적): 정규직 전환 후 2~3년 근무·주 8~12시간 사이드 가능. 이 가정 위에서 오늘 실행 가능하고 값어치 있는 선택 = 웹(C#) + 병행 Python/ML 포트폴리오다. AI 사업부는 “AI 키워드 빠른 부착”처럼 보이지만, 설계·고객·운영이 비면 시간 대비 이직 신호 산출이 낮다.

통념 반박 1: '언어 스택 불일치'와 '대규모 트래픽 만능론'의 맹점
C# 기반 대규모 시스템 경험이 Python 중심의 AI/ML 직무 이직에 치명적 감점이라는 것은 완벽한 착각입니다. 언어는 단순한 도구일 뿐이며, 대규모 트래픽 분산 처리와 메모리 관리 경험은 오히려 Python 스크립트 위주 개발자들이 가장 취약한 '엔지니어링 근본기'를 압도하는 무기가 됩니다. 또한 질문자는 'AI/ML 엔지니어'라는 직무를 매우 모호하게 정의하고 있습니다. 모델을 밑바닥부터 훈련하는 리서처인지, 모델 서빙 인프라를 다루는 MLOps인지, LLM API를 엮어 서비스를 만드는 AI 응용 엔지니어인지 구분하지 않은 채 막연히 다음 직장의 연봉과 규모만을 좇는 것은 실패를 부르는 치명적인 맹점입니다.

통념 반박 2: '현직자의 만류'와 'AI 툴 활용 물경력론'의 함정
재직자들이 만류하는 '고객 없는 초기 프로젝트, AI가 주도하는 설계 환경'은 오히려 연차 대비 막대한 권한을 쥘 수 있는 기회입니다. 현직자의 불만은 단지 기존의 편안한 개발 체계가 없다는 피로감일 확률이 높습니다. 상용 AI 툴을 엮어 빠르게 제품을 만드는 것은 물경력이 아니라, 현재 실리콘밸리에서 가장 높은 몸값을 자랑하는 'AI 엔지니어(AI Engineer)'의 핵심 요건입니다(참고: The Rise of the AI Engineer, Latent Space[1]). '설계를 AI에 맡긴다'는 것을 방관이 아니라 'AI가 내놓은 아키텍처의 한계를 검증하고 통제하는 경험'으로 치환해 경력기술서에 남길 수 있다면 이는 2~3년 뒤 이직 시장에서 가장 희귀한 스펙이 됩니다.

최종 결론
안정적인 시스템 엔지니어링 역량을 바탕으로 향후 MLOps나 AI 인프라 포지션으로 우회하는 것이 목표라면 웹 부서(C#)를 선택하십시오. 그러나 트렌드 최전선에서 고연봉의 'AI 프로덕트 엔지니어'로 직행하고 싶다면, 현직자의 두려움 섞인 만류를 철저히 무시하고 AI 사업부(Python)에 합류하십시오. 이직 시장은 이미 완성된 거대 톱니바퀴의 부품으로 일한 경험보다, 혼돈과 제약 속에서 AI 툴을 통제해 무에서 유를 창출해 낸 야생의 성과에 훨씬 더 높은 프리미엄을 지불합니다.

초안 답변 (경험·감정·생활 맥락 렌즈)

현직자의 만류는 숫자보다 무거운 1차 증언입니다. 소진(burnout) 연구의 핵심 모델인 Job Demands-Resources 모델에 따르면, 사람을 지치게 하는 건 업무량 자체가 아니라 "피드백·자율성·전문성 발전 기회"라는 자원의 결핍입니다 (Wikipedia[1], PMC 리뷰[2]). AI 사업부는 '고객 없음(성과 피드백 부재) + 설계를 AI에 위임(자율성·전문성 발전 기회 박탈)'이라는, 소진을 만드는 두 조건을 동시에 갖고 있습니다. 그 자리에 실제로 앉아본 사람들이 자발적으로 경고했다는 사실은 회사 소개 자료나 채용공고보다 훨씬 신뢰도 높은 실측 데이터입니다. 이 경고는 "혹시나"가 아니라 "이미 여러 명이 겪은 패턴"으로 읽고 최우선 가중치를 둬야 합니다.

두 부서의 하루가 실제로 어떻게 다른지가 결정적입니다.

• AI 사업부: 매일 AI가 짠 설계를 검수·전달하는 역할이 반복되면, 최근 국내 개발자 사례처럼 "브라우저와 AI 사이에서 에러 메시지를 배달하는 사람"이 된 듯한 무력감을 느끼기 쉽습니다 (바이라인네트워크[1]). 고객이 없어 "내 코드가 누군가에게 가닿았다"는 완결감도 구조적으로 없고, 2~3년 뒤 돌아봤을 때 "그때 내가 뭘 했더라"가 흐릿하게 남는 유형의 소진(의미 상실형)입니다.
• 웹 부서: 트래픽·장애·운영이라는 현실적 압박은 분명 힘들지만, "이 장애를 내가 진단하고 고쳤다"는 구체적 완결의 순간들이 주기적으로 쌓입니다. 이는 회복 가능한 유형의 피로(과부하형)에 가깝고, 실제로 사람을 성장했다고 느끼게 하는 서사(war story)를 남깁니다.

사람 중심 기준으로는 웹 부서를 권합니다. 언어(C#)는 퇴근 후 개인 학습이나 사이드 프로젝트로 메울 수 있는 '혼자 채울 수 있는 결핍'이지만, "고객 있는 실전에서 겪은 판단의 순간들"과 "그 안에서 실제로 자랐다는 실감"은 혼자서는 만들어낼 수 없는 자원입니다. 다만 현직자의 경고를 완전히 폐기하지는 말고, 배치 전 면담에서 "AI 사업부에 가면 고객·피드백 루프가 언제쯤 생기는지, 설계를 AI에 맡기는 방식이 언제까지 지속되는지"를 구체적으로 물어보시길 권합니다 — 그 답변의 구체성 자체가 그 조직이 사람의 소진을 인지하고 있는지를 보여주는 또 다른 신호가 될 겁니다.

Sources:

• Job demands-resources model - Wikipedia[1]
• Positive psychology in the working environment: JD-R theory systematic review - PMC[2]
• AI에게 코딩 맡겼더니 개발자 실력은 퇴보 - 바이라인네트워크[3]

결론: 웹 부서(C#, 대규모 코어 시스템)을 선택하라.

① 경력 자산의 복리 효과: 시스템 역량 > AI 툴 활용 역량

AI 도구 확산이 가속될수록, "AI를 쓰는 능력"은 빠르게 범용화(table-stakes)되지만 "대규모 시스템을 설계·운영하는 능력"은 희소성이 오히려 높아진다. 2026년 현재 AI/ML 채용 시장에서 최고 처우를 받는 포지션은 모델 자체가 아니라 모델을 프로덕션에서 안정·저비용·저지연으로 돌리는 인프라·시스템 문제를 푸는 사람이다(industry analysis[1]).

대규모 트래픽 운영·아키텍처 설계 경험은 2~3년 뒤 ML 인프라·MLOps·AI Platform 엔지니어 포지션으로 전환할 때 직접 전이되는 코어 자산이다. 반면, "AI 코딩 툴로 설계까지 위임하며 제품을 만든 경험"은 시간이 지날수록 누구나 복제 가능한 역량으로 평가절하된다.

② C# 언어 불일치는 2~3년 차에서 실질적 감점이 아니다; "고객 없는 AI 프로젝트"는 감점이다

• 언어 전환 비용은 낮다. 경험 있는 엔지니어의 C#→Python 전환은 업계에서 "myth-level barrier"로 취급된다. 사이드 프로젝트, Kaggle, 오픈소스 기여 등으로 Python+ML 스택 포트폴리오를 병행 구축하면 2~3년 차 이직에서 언어는 사실상 문제되지 않는다.
• 경력기술서 공백 리스크는 크다. 고객 없는 초기 프로젝트에서 아키텍처를 AI에 위임하며 2~3년을 보내면, 이력서에 쓸 수 있는 것은 "LLM API를 호출해 MVP를 만들었다" 수준이다. 트래픽 규모·장애 대응·성능 최적화·사용자 피드백 루프 같은 정량적 임팩트 스토리가 없다. 연봉·회사 규모가 좋은 곳일수록 이 정량적 증거를 요구한다.

③ 현직자의 만류는 결정적 신호다

내부자가 자기 팀을 스스로 만류하는 것은 조직 문화·성장 기회·리더십에 구조적 문제가 있다는 가장 강한 선행 지표다. 이것은 "개인 취향"이 아니라 되돌리기 비용이 큰 정보 비대칭 해소이므로, 의사결정에서 높은 가중치(veto-level)를 부여해야 한다.

실행 요약: 웹 부서에서 대규모 시스템 설계·운영 역량을 쌓되, 퇴근 후 Python + ML/AI 프로젝트(RAG 파이프라인, 모델 서빙 API 등)를 GitHub에 꾸준히 올려라. 2~3년 뒤 "시스템을 아는 AI 엔지니어"는 "AI 툴만 쓸 줄 아는 엔지니어"보다 구조적으로 희소하고, 연봉 프리미엄이 붙는 포지션(ML Infra, AI Platform, MLOps)에 정확히 맞는 프로필이 된다.

결론은 유지하되, 보완합니다. 현재 주어진 정보 기준으로는 2번 웹 부서(C# 대규모 코어 시스템팀)가 더 방어적인 선택입니다. 단, 목표가 “AI/ML 리서처”가 아니라 “고연봉·대기업 AI/ML/ML Infra/AI Platform/AI Deployment 계열”이라는 전제입니다.

현재 공고를 보면 상위권 AI 관련 엔지니어링 직무는 두 갈래입니다. 하나는 ML 인프라/시스템입니다. OpenAI의 ML Engineer 공고는 대규모 데이터 인프라, 분산 시스템, 안정성, production-ready 시스템을 요구합니다. 보상도 $295K-$445K+equity로 높습니다. OpenAI MLE Distributed Data Systems[1] 또 다른 OpenAI 인프라 공고도 Kubernetes, 관측성, 고가용성, 장애 대응을 핵심으로 봅니다. OpenAI Frontier Systems Infrastructure[2]

다른 하나는 AI Deployment / AI Product Engineering입니다. 이쪽은 “AI 툴을 써봤다”가 아니라 고객과 함께 프로토타입을 production으로 올리고, 평가·보안·비용·지연시간·관측성·운영 준비도를 다루는 역할입니다. OpenAI Enterprise AI Deployment 공고도 Python, eval, production launch, measurable business outcome을 요구합니다. OpenAI AI Deployment Enterprise[1] Codex Deployment도 고객 워크플로에 깊게 들어가 production rollout을 만드는 역할입니다. OpenAI AI Deployment Codex[2]

따라서 1번 AI 사업부는 이름만 보면 좋아 보이지만, 질문에 적힌 조건이 치명적입니다. 고객 없음, 운영 없음, 설계 판단을 AI에 위임, 내부자 만류가 동시에 있으면 2~3년 뒤 이력서 신호가 약합니다. “Python으로 AI 코딩 툴을 써서 초기 제품 개발”은 상위 회사가 사는 신호가 아닙니다. 상위 회사가 사는 것은 “누가 썼고, 어떤 지표가 좋아졌고, 장애·비용·품질·보안을 어떻게 통제했는가”입니다.

다른 초안 평가는 이렇습니다.

드러커 초안은 방향이 가장 맞습니다. “숫자로 남는 산출물”과 “C# 백엔드가 아니라 데이터 파이프라인·서빙·운영 경험으로 재편하라”는 조언은 흡수해야 합니다. 다만 “C# 문법은 면접 전 2주면 메운다”는 표현은 과합니다. Python 문법은 빠르게 익혀도 PyTorch, 데이터 처리, 모델 서빙, eval, MLOps 생태계는 2주로 안 됩니다.

카네기 초안도 결론은 맞지만, 사이드 프로젝트로 스택을 메울 수 있다는 부분은 조건부입니다. 단순 RAG 데모, LangChain 샘플, Kaggle 노트북으로는 부족합니다. 로그, 평가셋, 실패 케이스, latency/cost, 배포, 모니터링이 있는 프로젝트여야 방어가 됩니다.

결날 초안은 현직자 만류와 소진 리스크를 잘 짚었지만, 채용 신호 분석으로는 약합니다. 감정·생활 맥락은 보조 지표입니다. 이 결정의 1차 기준은 2~3년 뒤 팔 수 있는 경력 자산입니다.

역결 초안은 중요한 반론 하나를 건졌습니다. AI Engineer / AI Deployment Engineer라는 별도 고연봉 트랙은 실제로 존재합니다. 그래서 “AI 툴 활용은 무조건 물경력”이라고 하면 틀립니다. 하지만 역결의 결론처럼 내부자 만류를 무시하고 1번으로 가라는 건 위험합니다. 현재 공고들이 요구하는 AI Product/Deployment 경험은 고객, 평가, production rollout, operational readiness입니다. 질문자의 1번 팀은 바로 그 핵심 조건이 비어 있습니다.

긴줄 초안은 큰 방향은 맞지만 “C# 불일치가 실질적 감점이 아니다”는 말은 완화해야 합니다. 감점은 있습니다. 특히 2~3년 차에서 Python/ML 실무가 전혀 없으면 서류에서 일반 백엔드로 분류될 수 있습니다. 다만 고객 없는 AI 초기팀에서 생기는 경력 공백 리스크보다 작습니다.

최종 판단: 2번을 고르십시오. 단, 2번에서 그냥 C# 기능 개발만 하면 실패합니다. 첫 2~3년 동안 본업에서는 트래픽, 장애, 배포, 관측성, 성능 개선, 데이터 흐름을 숫자로 남기고, 별도로 Python 기반 ML/LLM 서빙·평가·모니터링 프로젝트를 만들어야 합니다.

의사결정 가중치는 이렇게 두면 됩니다.

• 대규모 운영/아키텍처 경험: 매우 큰 플러스
• C# 언어 불일치: 중간 감점, 계획적으로 완화 가능
• Python + AI 툴 사용: 단독으로는 약한 플러스
• 고객 없음/운영 없음/설계 위임: 큰 마이너스
• 현직자 만류: 단독 veto는 아니지만, 이번 경우에는 다른 악재와 결합해 강한 경고 신호

방어적으로 보면 1번의 최악은 “AI라는 이름은 있었지만 내가 소유한 설계·운영·성과가 없는 3년”입니다. 2번의 최악은 “C# 백엔드로 고착”입니다. 후자는 의식적으로 보완 가능하지만, 전자는 시간이 지나면 복구가 어렵습니다.

1. 다른 초안 비평 — 무엇을 흡수하고 무엇을 버리는가

역결(반대론): 결론은 틀렸지만 가장 중요한 지적을 했다. 질문자가 'AI/ML 엔지니어'를 정의하지 않았다는 것. 리서처·ML 인프라/MLOps·AI 프로덕트 엔지니어는 채용 파이프라인이 완전히 다른 세 직무다. 내 초안은 이걸 MLOps로 암묵 가정하고 넘어갔다 — 명시했어야 했다. 반면 "현직자의 만류는 편안한 체계가 없다는 피로감일 확률이 높다"는 근거 없는 추측이고, "AI가 낸 아키텍처의 한계를 검증·통제한 경험"은 고객·트래픽이 없으면 검증할 기준 자체가 없어 성립하지 않는다. 채택: 직무 정의. 기각: 결론.

역린: 내가 놓친 실무적 급소를 짚었다 — 서류 스크리닝 단계에서 '일반 백엔드'로 분류될 위험. 내 초안은 "면접에서 시스템 감각을 보여주면 된다"고 했는데, 면접에 못 가면 무의미하다. C#의 감점은 면접장이 아니라 필터 단계에서 발생한다. 이건 내 처방을 바꾼다.

카네기: "LangChain·툴 나열은 신호 약화, eval·비용·관측·장애 모드가 차별화 요인"이라는 프레이밍이 내 것보다 날카롭다. 그리고 주 8~12시간이라는 사이드 예산을 명시한 점이 실행 가능성을 높였다. 채택.

결날: JD-R 모델로 '고객 없음=피드백 부재, 설계 위임=자율성 박탈'을 구조화한 것이 설득력 있다. 특히 배치 전 면담에서 던질 질문을 제안한 것 — 그 답변의 구체성 자체가 신호라는 통찰은 실행 가능한 정보 수집 수단이다. 채택.

긴줄: 결론은 같으나 근거 링크가 검색 리다이렉트 URL이라 검증 불가다. 이런 인용은 근거로 치지 않는다. "AI를 쓰는 능력은 table-stakes로 범용화된다"는 표현만 유용하다.

2. 내가 초안에서 바꾸는 것

1. 직무를 확정한다. 질문자의 기준이 '연봉·회사 규모'라면 목표는 ML 인프라/MLOps 또는 프로덕션 ML 엔지니어다. 상단 처우가 여기 몰려 있고, 시스템 경험이 직접 전이되는 유일한 트랙이기도 하다. 리서처 트랙은 학위 게이트가 있어 2~3년 경력 전환으로는 진입 못 한다 — 이건 애초에 선택지가 아니다.
2. C# 감점의 위치를 정정한다. 감점은 '실력'이 아니라 '검색 가능성'에서 발생한다. 사이드 프로젝트만으로는 부족하고, 직무기술서에 Python/ML이 들어간 사내 업무를 반드시 확보해야 한다.
3. AI 사업부에 조건부 문을 남긴다. 무조건 배제가 아니라, 배치 전 확인 질문에 대한 답으로 판정한다.

3. 보완된 결론: 웹 부서(C#). 단, "C# 백엔드 개발자"가 아니라 "사내에서 ML을 프로덕션에 태운 사람"이 되는 조건부 선택이다.

신호 비교는 명확하다. 연봉·규모가 좋은 곳의 ML 채용은 모델이 아니라 모델을 저지연·저비용·고신뢰로 돌리는 문제를 산다. 요구되는 것은 분산 처리, 서빙 인프라, 관측성, 모델 라이프사이클 관리다. 대규모 트래픽·장애·아키텍처 경험은 언어와 무관하게 이 자리로 전이되고, "상용 AI 툴로 만든 고객 없는 제품"은 전이되지 않는다. 후자의 잔존가치는 그 툴의 수명과 함께 감가한다.

C# 감점의 정확한 성격 — 역린의 지적을 반영한다. 이건 실력의 문제가 아니라 필터 통과의 문제다. 서류에 Python·PyTorch·서빙 흔적이 0이면 면접에 가기 전에 '일반 백엔드'로 분류된다. 시스템 감각은 면접장에서만 팔 수 있는데, 면접에 못 가면 팔 기회가 없다. 그래서 사이드 프로젝트로는 부족하다 — 직무기술서 한 줄을 회사 안에서 만들어야 한다.

2~3년의 실행안 (우선순위 순)

1. 코어 시스템의 로그·이벤트 데이터 파이프라인을 자원해서 가져올 것. Kafka/배치/스토리지는 언어 중립이고 그대로 ML 파이프라인 경력이 된다. 우선순위 1위인 이유는 이게 사내에서 얻을 수 있으면서 사이드로는 못 만드는 유일한 자산이기 때문이다.
2. 실트래픽에 ML 기능을 하나 붙이고 Python 서빙 계층을 소유할 것. 이상탐지·검색 랭킹·추천 무엇이든 좋다. 이게 있으면 직함이 "C# 백엔드"에서 "대규모 시스템에 ML을 태운 엔지니어"로 바뀐다.
3. Docker/K8s/클라우드 배포·모니터링을 본인 이름으로 끝낼 것.
4. 주 8~12시간의 사이드는 (3)의 보완과 포트폴리오용으로만 쓸 것. 여기서 카네기의 프레이밍을 그대로 채택한다 — LangChain·툴 나열은 신호가 아니다. eval 지표, 토큰 비용, p99 레이턴시, 장애 모드가 있는 작은 프로덕션형 프로젝트 1~2개가 툴 열 개보다 강하다.

1·2가 확보되지 않고 3·4만 남는다면 그건 실패한 2년이다. 12개월 시점에 1번이 없으면 부서 이동이나 이직을 앞당겨라.

현직자의 만류 — 결날의 방법론을 얹어 판정 가능한 형태로 만든다. 내부인은 조직의 지속성·평가·업무 배분을 안다. 게다가 '고객 부재 + 설계 위임'은 개인 노력으로 뒤집을 수 없는 구조적 결함이다. 고객이 없으면 트래픽·장애·의사결정 데이터가 없고, 설계를 위임하면 "왜 그렇게 만들었나"라는 면접의 핵심 질문에 답할 소재가 없다. 다만 만류를 맹목적으로 따르지 말고, 배치 전 면담에서 세 가지를 물어라 — ① 첫 고객·실트래픽이 붙는 목표 시점은 언제인가 ② 설계 결정 권한이 팀원에게 넘어오는 기준은 무엇인가 ③ 이 제품의 성공/중단 판단 지표와 시한은 무엇인가. 셋 다 날짜와 숫자로 답이 오면 재고할 가치가 있다. 하나라도 "아직 정해지지 않았다"면 만류는 확증된 것이고, 그때는 veto로 취급하라.

되돌릴 수 있는가로 마무리한다. 웹 부서 → ML 인프라는 되돌릴 수 있다. 시스템 자산 위에 ML을 얹는 경로이기 때문이다. 반대로 고객도 설계 소유권도 없는 팀에서 보낸 2년은 되돌릴 수 없다. 남는 것이 없어서가 아니라, 없다는 사실이 이력서에서 드러나기 때문이다. 웹 부서를 택하되 첫날 팀장에게 "저는 이 회사에서 ML을 프로덕션에 태우는 사람이 되겠다"고 선언하고 그 방향의 업무를 계속 요구하라. 자리가 강점을 만들지만, 그 자리에서 무엇에 기여할지는 본인이 정의해야 한다.

다른 초안을 흡수·반박하려면 2026년 AI/ML 채용에서 실제로 무엇이 먹히는지부터 확인하겠습니다.## 다른 초안 비평 (비용·실행 렌즈)

이 사안의 결정 변수는 이직 신호의 시간당 산출이다. |
| 역결 | 직무를 쪼개야 한다는 지적은 흡수. 목표를 “막연한 AI/ML”이 아니라 ML Infra / AI 제품 엔지니어로 나누면 선택이 달라질 수 있다. | 주어진 사실(고객 없음·설계 AI 위임·오지 말라) 위에서 “야생의 권한·고연봉 AI 프로덕트 직행”은 실행 가능한 경로가 아니다. 권한 없이 툴만 쓰는 2~3년은 Latent Space식 ‘제품을 출시하는 AI Engineer’ 스펙과 정반대다.[[1]](latent.space[1]) |
| 긴줄 | “AI 쓰는 능력의 범용화 vs 시스템 역량의 희소성”은 비용 대비 핵심 프레임. 현직자 만류에 veto급 가중치도 동의. | 언어 장벽을 “myth”로 과소평가하면 안 된다. 역린처럼 필터 리스크는 인정하고 메울 계획을 세워야 한다. |

입장 조정: 역결의 “역할 분기”는 받아들인다. 다만 이 질문의 구체적 선택지에서는 분기의 전제(고객·출시·설계 소유)가 AI 사업부에 없으므로, 결론은 웹(C#)으로 유지한다. “어느 쪽이든 될 수 있다”로 흐리지 않는다.

---

결론 (단정): 웹 부서(C#) + 본업 재편 + 주 8~12시간 Python/ML 사이드

좋은 연봉·큰 회사의 AI/ML 쪽 채용은, 2026년 기준으로도 프로덕션 사고(배포·eval·관측·장애·비용·지연) 를 산다. “툴 나열·노트북”은 red flag에 가깝고, 포트폴리오도 운영·실패 모드가 있는 end-to-end가 신호다.[[2]](youtube.com[1])[[3]](dataexpert.io[2])[[4]](virtido.com[3])
고연봉·상단 역할일수록 소프트웨어·프로덕션 ML 장벽이 높다.[[5]](ischool.syracuse.edu[4])

합리적 가정: 정규직 전환 후 2~3년 근무, 주 8~12시간 사이드 가능, 이직 기준은 연봉·회사 규모.

질문에 대한 답

1. 어느 신호가 센가

“Python으로 AI 툴 붙여 제품(사용자·운영·설계 부족)” ≪ “C#으로 대규모 설계·운영”.
연봉·규모가 좋을수록 격차는 더 벌어진다. 시장이 사는 것은 언어 라벨이 아니라 프로덕션에서 시스템을 돌린 증거다.

2. C# 감점

있다. 치명적이진 않다. 2~3년 차 서류에서 “일반 백엔드”로 분류될 리스크는 인정한다(역린).
메우기 난이도: 문법·프레임 수주~수개월 / eval·서빙·파이프라인 있는 공개 산출물 1~2개 = 주 8~12시간 × 1.5~2년.
반대로 고객·SLA·설계 소유 2~3년은 사이드로 복구 불가에 가깝다. 값이 나가는 쪽을 본업에 두고, 값이 싼 쪽을 사이드에 둔다.

3. AI 사업부 경력기술서

고객·지표·본인 설계 결정이 없으면 남는 문장은 “상용 AI 코딩 툴로 초기 제품” 수준. 채용 측이 보는 red flag(설명 깊이 없음·수치 없음·프레임 의존)에 가깝다.
역결식 “AI 아키텍처 검증·통제”로 치환 가능하려면 본인이 설계 기준·품질 게이트·출시 지표를 실제로 쥐어야 하는데, 지금 설명(설계를 AI에 맡김·오지 말라는 내부 조언)은 그 전제와 충돌한다. 실행 불가능에 가깝다.

4. 현직자 만류 가중치

매우 높음 (사실상 veto급).
같은 사다리를 밟은 사람의 “시간 대비 산출이 안 나온다”는 말은 기회비용 계산의 1차 데이터다. 소개 자료·직함보다 신뢰한다. 이걸 무시하고 2~3년을 쓰는 비용은 나중에 사이드로 못 갚는다.

오늘부터 값어치 있는 실행 (웹 선택 시)

드러커 플랜을 필수 조건으로 붙인다. C#만 3년 하면 ML 이직은 약해진다.

1. 본업 (주력 자산): p99, 처리량, 장애 MTTR, 비용, 가용성 등 숫자로 남는 운영·설계 성과.
2. 본업 내 자원 (사이드로 못 사는 것): 로그/이벤트 파이프라인, 가능하면 추천·이상탐지·검색 등 실트래픽에 ML 한 조각 + 본인 소유 구간.
3. 사이드 (주 8~12h): Python + 서빙/RAG 또는 학습·평가 파이프라인 + eval·모니터링·실패 모드가 있는 프로젝트 1~2개 공개. “AI 툴 썼다”가 아니라 “시스템을 알고 ML 스택도 구현했다” 조합.
4. 목표 직무 한 줄 고정: 연봉·규모 상단이면 대개 ML/AI 플랫폼·인프라·프로덕션 ML 쪽이 웹 경력과 맞다. 순수 “LLM API 붙여 제품”만 노리면 웹 선택의 이점이 줄어드니, 이직 타깃을 그에 맞게 잡는다.

역결에 대한 설득 (한 줄)

“혼돈 속 야생 성과”에 프리미엄이 붙는 것은 출시·사용자·본인 판단이 있을 때다. 고객 없고 설계를 AI에 넘기는 팀은 그 상품이 아니라 키워드만 비싼 저산출 자리다. 그 전제가 바뀌지 않는 한 AI 사업부는 비용 대비 효과가 안 나온다.

---

최종: 오늘 실행 가능하고 2~3년 뒤 연봉·규모 이직에 값어치 있는 선택은 웹(C#) 코어 + 위 실행 패키지다. AI 사업부는 “AI 이력 빠른 부착”처럼 보이지만, 설계·고객·운영이 비면 시간당 이직 신호 산출이 낮다.

다른 초안 평가

흡수할 점

• 드러커·카네기: "언어 불일치는 혼자 메울 수 있지만 운영·설계 경험은 혼자 못 만든다"는 명제에 구체적 실행안(데이터 파이프라인 자원, 사내 ML 기능 붙이기, 주 8~12시간)을 붙인 건 유효합니다. 제 렌즈에서 보면 이건 단순한 '이력서 항목 추가'가 아니라, AI 사업부에 없는 것 — "내가 판단했고 그 결과를 확인했다"는 완결의 순간을 웹 부서 안에서 스스로 만들어내는 방법입니다. 이걸 제 답변에 흡수합니다.
• 카네기: "같은 사다리를 밟은 사람의 경고는 기회비용에 대한 1차 데이터"라는 표현은 제가 JD-R 모델로 말하려던 것과 정확히 같은 결론입니다. 서로 다른 언어로 같은 곳에 도달했다는 점에서 이 판단에 대한 확신을 높입니다.
• 역린: OpenAI 채용공고를 근거로 든 것은 제 감정·경험 렌즈 밖의 이야기지만, "설계 판단을 본인이 했는가?"에 대한 의심을 부른다는 지적은 제가 말한 '흐릿한 서사'와 같은 현상을 채용 담당자 시점에서 재확인해준 것이라 유용합니다.

반박할 점 — 역결의 초안
역결은 "고객 없음 + AI에 설계 위임"을 오히려 "AI 아키텍처의 한계를 검증·통제하는 희귀 경험"으로 재해석할 수 있다고 주장합니다. 이 논리 자체는 틀리지 않습니다 — 만약 그 통제가 실제로 검증되는 환경이라면요. 하지만 "AI가 내놓은 설계를 검증했다"는 서사가 성립하려면 검증할 대상(고객의 반응, 운영 중 발생하는 실패, SLA 위반)이 있어야 합니다. 질문자의 사례는 정확히 그 대상이 빠져 있습니다 — 고객이 없으니 AI의 설계가 맞았는지 틀렸는지 아무도 확인할 길이 없고, 확인이 없으니 "내가 AI를 통제했다"는 말도 사후적으로 증명 불가능한 자기 서술에 그칩니다. 게다가 역결은 현직자의 만류를 "편안한 체계가 사라진 데 대한 피로감"으로 축소하는데, 이건 근거 없는 추측입니다. 질문자가 전한 정보(초기 2주 차, 고객 없음, 설계 전량 AI 위임)와 현직자의 경고가 정확히 같은 방향을 가리키는 상황에서, 경고를 "그냥 불편함"으로 재해석하는 건 무리한 낙관입니다. 이 부분은 받아들이지 않습니다.

---

최종 답변

결론은 그대로, 웹 부서(C#)입니다. 다만 근거를 두 층위로 보강합니다.

1) 현직자의 경고는 여전히 최우선 증거입니다. JD-R 모델에서 소진을 만드는 건 업무 난이도가 아니라 피드백·자율성·성장 실감의 결핍인데, AI 사업부는 이 세 가지가 구조적으로 비어 있습니다(고객 없음=피드백 없음, 설계를 AI에 위임=자율성·전문성 발전 기회 없음). 카네기가 말한 "같은 사다리를 밟은 사람의 경고는 1차 데이터"라는 표현에 동의합니다 — 이건 회사 소개서보다 신뢰도가 높은, 이미 여러 명이 겪은 패턴입니다.

2) 다만 웹 부서를 "그냥 버티는 3년"으로 만들면 저도 실패라고 봅니다. 드러커·카네기가 제안한 것처럼 사내 데이터 파이프라인이나 실트래픽 ML 기능을 자원해서 맡는 건, 제 렌즈로 보면 단순한 스펙 쌓기가 아니라 AI 사업부에 없는 "내가 결정하고 그 결과가 돌아오는 경험"을 웹 부서 안에서 능동적으로 만드는 일입니다. 이게 없으면 웹 부서도 "그냥 시킨 걸 했다"는 흐릿한 서사로 끝날 수 있고, 있으면 2~3년 뒤 "장애를 진단하고 고쳤다", "이 기능을 내가 설계해서 붙였다"는 구체적 완결의 기억이 남습니다. 이 차이가 실제로 사람을 성장했다고 느끼게 하는지, 아니면 소진된 채 흐릿하게 지나갔다고 느끼게 하는지를 가릅니다.

3) 언어(C#)는 개인이 채울 수 있는 결핍, 판단·소유권 경험은 혼자 못 만드는 결핍입니다. 이 구분은 초안들 사이에 이견이 없었고 저도 동의합니다. 카네기가 제시한 "주 8~12시간, 2~3년"이라는 현실적 시간 배분은 번아웃 없이 병행 가능한 수준으로 보입니다.

행동 제안: 배치 전 면담에서 AI 사업부 현직자에게 "언제쯤 고객이 생기는지, 설계를 AI에 맡기는 방식이 언제까지 지속되는지"를 구체적으로 물어보세요. 답변이 구체적이면 그 조직이 소진 신호를 인지하고 있다는 뜻이고, 애매하면 만류가 옳았다는 뜻입니다. 웹 부서를 택하더라도 첫 3개월 안에 "숫자로 남는 판단의 순간"을 만들 수 있는 업무(로그 파이프라인, 실트래픽 기능 하나)를 스스로 요청하시길 권합니다 — 그게 3년 뒤 이력서 문장이자, 동시에 "내가 그 시간을 헛되이 보내지 않았다"고 스스로에게 말할 수 있는 근거가 됩니다.

[비평 및 수용: '고객 없는 물경력'에 대한 타당한 지적]
다른 전문가(드러커, 카네기, 긴줄 등)들이 지적한 "고객과 운영 지표(Metrics)가 없는 2~3년은 경력기술서에 남길 것이 없다"는 주장은 뼈아픈 진실입니다. 제 초안은 트래픽과 운영 경험이 주는 정량적 성과의 파괴력을 과소평가했습니다. 만약 1번 부서에서 'AI 툴이 짜주는 코드를 구경만 하는 방관자'로 3년을 보낸다면 그 이력서는 휴지조각이 될 것입니다. 이 지적을 전적으로 수용합니다.

[합의에 대한 반박 1: 'C# 백엔드 = MLOps 프리패스'라는 거대한 착각]
그러나 모든 전문가가 만장일치로 향하고 있는 '웹 부서(C#) 선택 후 사이드 프로젝트 병행'이라는 합의에는 더 치명적인 맹점이 숨어 있습니다.

C# 생태계에서 대규모 트래픽을 다루는 경험이 훌륭한 엔지니어링 자산인 것은 맞습니다. 하지만 현대 ML 인프라 생태계(Ray, vLLM, KubeFlow, PyTorch 등)는 Python과 Go, C++를 중심으로 완전히 다르게 굴러갑니다. C# 코어 시스템에서 3년을 뒹군 엔지니어를 상위 채용 시장은 '시스템 감각이 있는 MLOps 인재'가 아니라 '전형적인 엔터프라이즈 C# 백엔드 개발자'로 분류합니다. 더구나 본업에서 대규모 트래픽 장애를 막느라 야근하는 주니어 개발자가, 퇴근 후 개인 시간만으로 '실무 수준의 Python ML 파이프라인'을 구축해 언어 갭을 메운다는 것은 인간의 한계를 무시한 탁상공론입니다.

[합의에 대한 반박 2: 'AI/ML 엔지니어' 직무 정의의 편향과 현직자 만류의 이면]
다른 전문가들은 고연봉 AI 직무를 '대규모 모델 서빙 인프라(MLOps)' 하나로만 좁혀서 단정 지었습니다. 하지만 채용 시장에서 가장 폭발적으로 수요가 늘고 있는 포지션은 기성 모델(LLM)과 AI 코딩 툴을 엮어 비즈니스 제품을 빠르게 찍어내는 'AI 프로덕트 엔지니어(AI Engineer)'입니다.

현직자들이 "설계를 AI에 맡긴다, 오지 마라"고 만류하는 것을 반드시 조직의 결함으로만 읽을 필요는 없습니다. 이는 과거의 낡은 장인정신에 갇힌 전통적 소프트웨어 엔지니어들이, AI가 코드를 찍어내고 아키텍처를 주도하는 새로운 'AI-Native' 패러다임에 적응하지 못해 느끼는 피로감일 확률이 높습니다. 오히려 이 혼돈의 초기 부서는 연차에 구애받지 않고 AI 툴을 통제하며 주도권을 쥘 수 있는 완벽한 샌드박스입니다.

[최종 결론 및 절충안]
전문가들의 맹목적인 'C# 추천'에 반대하며, 질문자의 진짜 목표에 따라 결론을 명확히 가릅니다. 막연히 "연봉과 규모"만 좇지 말고 본인이 어느 쪽 엔지니어가 될 것인지 먼저 정의하십시오.

1. 목표가 'MLOps/AI 인프라 엔지니어'라면: 웹 부서(C#)를 택하십시오.

단, 다른 전문가들의 환상처럼 '사이드 프로젝트'로 퉁칠 생각은 버리십시오. 사내에서 어떻게든 ML 관련 데이터 파이프라인이나 인프라 이관 업무를 강탈하다시피 가져와 본인의 성과로 만들지 못하면, 당신은 영원히 C# 백엔드 개발자로 남습니다.

2. 목표가 트렌드 최전선의 'AI 프로덕트 엔지니어'라면: AI 사업부(Python)를 택하십시오.

단, 다른 전문가들의 뼈아픈 지적을 방어하기 위한 필수 전제가 붙습니다. '고객이 없다'고 불평하는 현직자들 틈에서, 당신이 직접 초기 제품의 테스트 고객을 찾아 정량적 지표를 만들고, AI가 내놓은 아키텍처의 한계를 뜯어고친 '주도자'가 되어야 합니다. 그 3년의 고군분투가 이력서에 숫자로 담기는 순간, 당신은 AI를 단순 도구가 아닌 '엔지니어링 파트너'로 다뤄본 가장 희귀한 인재가 될 것입니다.

약점 공략 — 다수 의견의 6개 급소

① 다수는 '팀'을 비교했지, '질문자가 앉을 자리'를 비교하지 않았다.
"대규모 코어 시스템팀 = 트래픽·아키텍처 경험"은 팀이 보유한 자산이지 신입이 자동으로 획득하는 자산이 아니다. 대규모 C# 코어 시스템에 배치된 1~2년 차가 실제로 받는 일은 대개 레거시 결함 수정, 티켓 처리, 기존 설계 안에서의 기능 추가다. 설계 결정과 장애 대응 지휘는 이미 그 시스템을 만든 시니어에게 있다. 즉 "고객은 있는데 내 손이 닿지 않는" 3년은 "고객이 없는 3년"과 이력서상 동일하게 공허할 수 있다. 다수 의견 중 누구도 이 대칭 리스크를 계산하지 않았다.

② "고객 없음"을 상태가 아니라 속성으로 오독했다.
개발 2주 차 팀이다. 2주 차 스냅샷을 36개월로 외삽하는 건 분석이 아니라 게으름이다. 상용 제품팀이 3년 내내 고객 0일 시나리오는 거의 없다 — 고객이 생기거나, 팀이 접힌다. 전자면 질문자는 0→1 초기 멤버로서 첫 트래픽·첫 장애·첫 비용 폭증을 소유한다(코어 시스템팀 3년 차가 절대 못 갖는 포지션). 후자면 2년 차에 사내 이동하면 되고, 그때 이력서에는 이미 Python·LLM 키워드가 박혀 있다.

③ 다수는 "C#은 서류 필터에서 감점된다"를 인정해놓고 결론을 바꾸지 않았다 — 논리적 모순이다.
필터를 못 넘으면 아무리 훌륭한 시스템 경험도 팔 기회가 없다. "사이드 프로젝트로 메운다"는 처방은 채용담당자가 개인 GitHub을 열어본다는 가정에 의존하는데, 연봉·규모 상단일수록 지원자가 몰려 그 가정이 먼저 깨진다. 반면 직무기술서에 'Python / LLM 제품 개발'이 적힌 이력서는 최소한 사람 눈에 도달한다.

④ 결정적 반증: 시장이 사는 신호는 '트래픽 규모'가 아니라 'eval'이다.
2026년 LLM 엔지니어 채용의 1차 변별 질문은 "GPT를 써봤나"가 아니라 "당신이 설계한 평가(eval)를 설명하라 / 모델 드리프트를 어떻게 탐지하고 롤백하나"이며, 이걸 답하지 못하면 프로덕션 경험이 없는 것으로 분류된다는 게 현재 채용 실무의 공통된 서술이다.(digitalapplied[1], dataskew[2]) 그리고 eval 설계는 대규모 트래픽을 요구하지 않는다. 사내 사용자 50명, 요청 1만 건이면 faithfulness·지연·환각률 측정 체계를 만들 수 있다. 다수는 "고객이 없으면 검증 대상이 없다"고 단정했지만, 검증 대상은 고객 수가 아니라 출시된 기능 하나다.

이 조건은 웹 부서보다 AI 사업부에서 훨씬 싸게 확보된다.

⑤ "현직자 만류"에 veto급 가중치를 준 건 증거 위생이 나쁘다.
표본 수도, 그들의 목표 직무도 모른다. 그들이 AI/ML 이직을 노리는 사람이었나? 아니면 안정된 설계 프로세스를 선호하는 전통적 엔지니어였나? "내가 일하기 불편하다"와 "당신의 3년 뒤 이직에 불리하다"는 전혀 다른 명제다. 결정적으로 — 웹 부서 현직자에게는 같은 질문을 던졌는가? 한쪽에만 실사를 하고 그 결과를 결정 근거로 쓰는 건 정보 수집이 아니라 확증이다.

⑥ 되돌릴 수 있는가 — 방향이 다수 의견과 반대다.
"C# 코어 → AI/ML"은 2~3년 뒤 시장을 통과해야 하는 되돌리기다. "AI 제품팀 → 사내 코어 시스템팀"은 같은 회사 안의 이동이고, C# 백엔드 수요는 3년 뒤에도 사라지지 않는다. 되돌리기 비용이 싼 쪽은 1번이다.

---

결론: AI 사업부(1번)를 택하라. 단, 배치 확정 전 아래 두 개를 확인해서 판정한다.

이건 도박이 아니라 조건부 확정이다. 팀장/리드에게 직접 묻고, 답이 구체적이면 1번, 뭉개면 2번이다.

1. "이 제품이 사내 사용자든 파일럿 고객이든 실사용자에게 붙는 시점이 언제입니까? 6개월 내입니까?" — 답이 로드맵상 날짜로 나오면 통과. "아직 미정"이면 탈락.
2. "제가 이 제품의 품질 평가 체계(eval)와 비용·지연 모니터링을 맡아도 됩니까?" — 이건 아무도 하기 싫어하는 일이라 신입에게 넘어올 확률이 높고, 정확히 상단 채용이 사는 신호다. 승낙이면 통과.

두 조건이 서면, 질문자의 2029년 경력기술서 한 줄은 이렇게 된다 — "LLM 기반 신제품의 평가 파이프라인을 설계해 환각률 X%→Y%, 요청당 비용 Z% 절감, 사내 N명 운영." 이건 대규모 C# 시스템에서 3년간 티켓을 처리한 사람이 어떤 사이드 프로젝트로도 만들 수 없는 문장이다.

조건이 하나라도 명확히 부정되면, 그때는 다수 의견대로 웹 부서로 가라. 다만 그 경우에도 입사 6개월 내에 사내 데이터 파이프라인 업무를 문서상 직무에 넣는 것을 조건으로 걸어라. 그 확약 없이 가는 웹 부서는 1번의 최악 시나리오와 똑같이 공허하다.

핵심 한 줄: 두 부서의 차이보다, 두 부서 안에서 당신이 무엇을 소유하느냐의 차이가 훨씬 크다. 다수는 부서를 골랐고, 나는 소유권을 고르라고 말한다.

Sources: AI Developer Hiring 2026[1], AI Engineer Roadmap 2026 — dataskew[2], In-Demand ML Roles 2026 — Acceler8[3]

최종 수정안입니다.

결론: 기본값은 2번 웹 부서(C# 대규모 코어 시스템팀)입니다.
다만 약점 공략의 반론 중 하나는 맞습니다. “부서 이름”보다 중요한 것은 2~3년 뒤 경력기술서에 쓸 개인 소유권입니다. 그래서 최종 판단은 이렇게 바꿉니다.

1번 AI 사업부가 6개월 내 실사용자와 eval/모니터링 소유권을 보장하면 1번, 그게 아니면 2번입니다. 현재 질문에 주어진 정보만으로는 2번을 고릅니다.

근거는 채용 신호입니다. OpenAI의 AI Deployment Engineer 공고는 단순히 AI 툴을 쓴 경험이 아니라 고객 문제를 production으로 올리고, eval, latency, cost, reliability, observability, security, measurable outcome을 다룬 경험을 요구합니다. OpenAI AI Deployment Engineer[1] OpenAI의 ML/인프라 계열 공고도 distributed systems, reliable infrastructure, production-ready systems를 강하게 봅니다.

OpenAI Distributed Data Systems[1] Amazon Alexa AI MLE도 LLM training, production deployment, inference optimization, PyTorch/JAX, MLOps를 요구합니다. Amazon Alexa AI MLE[2] Microsoft AI도 LLM eval, data flywheels, production-quality Python을 명시합니다. Microsoft AI MTS ML[3]

따라서 “Python + AI 툴”은 그 자체로 강한 신호가 아닙니다. 강한 신호는 다음입니다.

• 출시된 AI 기능
• 사용자의 실제 피드백
• eval 설계
• 비용/지연시간/품질 지표
• 장애 대응과 롤백
• 보안·권한·데이터 거버넌스
• 본인이 소유한 설계 판단

1번의 위험은 명확합니다. 고객 없음, 운영 없음, 설계를 AI에 위임, 현직자 만류가 동시에 있으면 3년 뒤 문장이 이렇게 됩니다. “AI 코딩 툴을 활용해 신규 제품 개발.” 이건 상위권 AI/ML 채용에서 약합니다. 특히 좋은 연봉·큰 회사일수록 “무엇을 만들었나”보다 “무엇을 검증했고, 운영했고, 개선했나”를 봅니다.

2번의 위험도 있습니다. C# 대규모 시스템팀에 간다고 신입이 자동으로 아키텍처를 소유하지 않습니다. 3년 내내 레거시 티켓만 처리하면 “C# 백엔드 개발자”로 고착됩니다. 이 반론은 타당합니다. 그래서 2번을 고르더라도 조건이 붙습니다.

2번을 택한다면 첫 6개월 안에 다음 중 최소 2개를 잡아야 합니다.

• 장애/온콜/포스트모템 참여
• 성능 개선 수치
• 배포/롤백 자동화
• 로그·메트릭·트레이싱 개선
• 데이터 파이프라인 또는 추천/검색/랭킹/분석성 기능
• Python 기반 내부 자동화나 ML 서빙 PoC

C# 불일치는 감점입니다. 특히 2~3년 차 AI/ML 서류에서는 Python, PyTorch/JAX, MLOps 경험이 없으면 일반 백엔드로 분류될 수 있습니다. 하지만 이 감점은 보완 가능합니다. 반대로 “고객도 운영도 설계 소유권도 없는 AI팀 3년”은 회복이 어렵습니다.

현직자 만류는 단독 veto는 아닙니다. 하지만 이번에는 다른 위험 신호와 결합되어 가중치가 큽니다. 한 명의 불평이면 노이즈지만, “초기 프로젝트 + 고객 없음 + AI에 설계 위임 + 내부자 만류”는 구조적 위험입니다.

최종 의사결정 규칙은 이것입니다.

1. 1번 리드에게 “6개월 내 실사용자가 붙는가?”를 묻습니다.
2. “내가 eval, 비용, latency, 모니터링, 장애 대응을 소유할 수 있는가?”를 묻습니다.
3. 둘 다 구체적으로 Yes면 1번을 선택합니다.
4. 하나라도 흐리면 2번을 선택합니다.

현재 정보 기준 최종 선택은 2번 웹 부서(C#) 입니다. 이유는 1번의 상방보다 1번의 하방이 더 치명적이기 때문입니다. 2번의 최악은 스택 고착이고, 1번의 최악은 경력 실체 부재입니다. 방어적으로는 후자가 더 위험합니다.

1. 내가 인정하는 것 — 세 가지는 상대가 옳다

① "팀의 자산 ≠ 내 자산" 지적은 옳고, 내 초안의 가장 큰 구멍이었다. 대규모 C# 코어에 배치된 1~2년 차가 설계 결정권과 장애 지휘를 잡을 확률은 높지 않다. "고객은 있는데 내 손이 닿지 않는 3년"은 실제로 존재하는 실패 모드다. 나는 웹 부서를 자동 승리처럼 서술했는데, 그건 틀렸다.

④ "eval은 대규모 트래픽을 요구하지 않는다"는 반박은 부분적으로 성립한다. 지연·비용·환각률 측정 체계는 사내 사용자 50명으로도 세울 수 있다. 나는 "고객이 없으면 검증 기준이 없다"고 단정했는데, 과했다. 정정한다.

⑤ 증거 위생 지적을 전면 수용한다. 한쪽 부서에만 실사하고 그 결과를 결정 근거로 쓴 것은 확증편향이다. 웹 부서 현직자에게 같은 질문을 던지지 않았다면 만류의 가중치는 veto가 아니다. 내 초안의 "veto로 취급하라"를 철회한다.

2. 그럼에도 결론은 바꾸지 않는다 — 상대 논거의 급소 세 개

④의 치명적 결함: 사용자 없는 eval은 eval이 아니라 자기채점이다. eval의 가치는 지표를 만든 데 있지 않고, 실제 사용자 행동이 만든 실패 케이스가 데이터셋에 들어와 있느냐에 있다. 고객 0인 제품에서 만드는 평가셋은 본인이 상상한 입력의 집합이다. 면접에서 "환각률 X%→Y%"를 말하면 반드시 따라오는 질문이 "그 평가셋은 어디서 왔습니까"이고, 답이 "제가 만들었습니다"면 그 줄은 그 자리에서 죽는다. 카네기의 eval 프레이밍은 옳고 상대가 그걸 잘 가져왔지만, eval은 트래픽을 대체하는 게 아니라 트래픽을 필요로 한다. 상대는 이 인과를 뒤집었다.

③의 결함: 필터를 통과시키는 키워드와, 통과 후 이기는 신호는 다르다. 2026년 현재 "상용 LLM API로 제품 붙여본 Python 개발자"는 시장에서 가장 빠르게 공급이 늘어난 프로필이다. 필터는 넘지만 100명이 같은 줄을 들고 서 있다. 반대로 대규모 트래픽·장애·용량을 실제로 다뤄본 사람의 공급은 그 속도로 늘지 않는다. 연봉·회사 규모 상단이 사는 건 희소성이지 키워드가 아니다. 다만 — 역린의 지적대로 — 키워드가 0이면 그 희소성을 팔 자리에 못 간다. 그래서 답은 "AI 부서로 가라"가 아니라 "웹 부서에서 Python/ML 키워드를 사내 업무로 확보하라"다. 이건 도달 가능한 요구다.

⑥의 결함: 되돌리기 비용을 회사 단위로 계산했다. 상대는 "사내 이동이 싸다"고 했지만, 되돌릴 수 없는 자원은 회사가 아니라 2~3년이라는 시간과 그 시간에 붙은 연차다. 3년 차 이직 시장에서 "실사용자 트래픽을 다뤄본 적 없음"은 사내 이동으로 회수되지 않는다. 반면 시스템 경험 위에 ML을 얹는 건 순증이다. 방향은 여전히 내 쪽이다.

②는 인정하되 뒤집는다. 2주 차를 36개월로 외삽하는 게 게으르다는 건 맞다. 그런데 질문자가 준 정보 중 시간이 해결하지 않는 항목이 하나 있다 — "아키텍처·설계를 대부분 AI에 맡긴다"는 팀의 방법론이지 초기 상태가 아니다. 고객은 생길 수 있지만 설계 문화는 저절로 바뀌지 않는다. 그리고 면접의 핵심 질문은 여전히 "왜 그렇게 만들었나"다.

3. 최종 수정안: 웹 부서(C#). 단, 상대의 ①·⑤를 반영해 양쪽 모두 실사한 뒤 확정한다.

배치 전, 두 부서에 같은 질문을 던져라 (상대의 ⑤ 수용)

AI 사업부에: ① 실사용자(사내 파일럿 포함)가 붙는 로드맵상 날짜는? ② 평가·비용·지연 모니터링을 제가 소유해도 됩니까? ③ 설계 결정권이 팀원에게 넘어오는 기준은?

웹 부서에: ① 1년 차가 실제로 배정받는 업무는 티켓·기능 추가입니까, 설계·용량·장애 대응이 포함됩니까? ② 온콜 로테이션에 언제 들어갑니까? ③ 로그·이벤트 파이프라인 관련 업무를 맡을 여지가 있습니까?

판정 규칙: 웹 부서 답이 "3년간 티켓 처리"로 수렴하고 AI 부서가 6개월 내 실사용자 + eval 소유권을 날짜로 확약하면, 그때는 AI 사업부가 맞다. 이건 상대에게 양보하는 게 아니라, 상대가 옳게 지적한 대칭 리스크를 실제로 계산에 넣는 것이다.

웹 부서를 택했을 때의 실행안 (우선순위)

1. 로그·이벤트 데이터 파이프라인을 자원해서 가져와라. Kafka/배치/스토리지는 언어 중립이고 그대로 ML 파이프라인 경력이 된다. 사내에서만 얻을 수 있고 사이드로는 못 만드는 유일한 자산.
2. 실트래픽에 ML 기능 하나를 붙이고 Python 서빙 계층을 소유하라. 이상탐지·검색 랭킹·추천 무엇이든. 여기서 카네기의 프레이밍이 그대로 산다 — eval 지표·토큰 비용·p99·장애 모드. 차이는, 이 eval의 데이터셋이 실제 사용자에게서 나온다는 것. 그게 AI 부서 버전과의 결정적 격차다.
3. Docker/K8s/배포·모니터링을 본인 이름으로 끝내라.
4. 주 8~12시간 사이드는 (3)의 보완용으로만. 툴 나열은 신호가 아니다.

마감 규칙: 12개월 시점에 1번이 없으면 부서 이동 또는 이직을 앞당겨라. 3·4만 남은 2년은 실패한 2년이다.

출처에 대한 정직한 처리

상대가 인용한 두 링크(digitalapplied[1], dataskew[2])는 채용 실무 서술이 아니라 블로그·로드맵 콘텐츠다. 나는 이를 검증하지 않았고, "eval이 변별 질문이 되고 있다"는 방향성만 취하고 수치·단정은 취하지 않는다. 반대로 이 결론의 핵심 근거는 문서가 아니라 구조다 — 평가셋의 출처, 공급 곡선의 기울기, 시간의 비가역성. 이 셋은 링크 없이도 검증된다.

핵심 한 줄: 상대의 "부서가 아니라 소유권을 골라라"는 옳다. 그래서 나는 소유권을 고르되, 소유할 대상이 실제로 존재하는 쪽을 고른다 — 사용자 없는 시스템에서는 소유할 것도 없다.

2026 AI/ML 채용에서 실제로 무엇이 먹히는지부터 웹으로 확인한 뒤, 비용·실행 렌즈로 최종안을 다시 짜겠습니다.## 최종 수정안 (카네기 · 비용·실행 렌즈)

합리적 가정: 정규직 전환 후 2~3년 근무 → 연봉·규모 상단 AI/ML 이직, 주 8~12시간 사이드 가능. 배치 전 팀장/리드에게 질문할 수 있다.

---

시장이 사는 것 (2026, 확인된 신호)

연봉·규모가 좋은 쪽일수록 사는 것은 언어 라벨·툴 나열이 아니라 프로덕션에서 시스템을 검증·운영한 증거다.

• Eval 설계가 “실제로 LLM으로 만들었는가”의 1차 변별 신호다. 메트릭·데이터셋·실패 모드를 설명 못하면 lab/데모로 분류된다.
• 같이 먹히는 것: 비용(cost)·관측(observability)·장애/롤백·배포 습관. “LangChain+데모” 이력은 red flag에 가깝다.
• AI Engineer 스펙은 여전히 Python 중심이지만, 채용 측이 강조하는 건 노트북이 아니라 유지보수 가능한 소프트웨어 + MLOps/배포.
• 포트폴리오도 튜토리얼이 아니라 배포·모니터링·실패 모드가 있는 end-to-end가 신호다.

→ 다수안(“프로덕션 사고”)과 약점 공략(“eval”)은 대립이 아니라 같은 축의 다른 이름이다. 트래픽 규모 자체가 아니라 출시된 기능 + 측정·운영 소유가 값어치다.

---

약점 공략 6개 — 흡수 / 기각

“키워드만 붙은 빈 2년”은 외부 이직에서 사이드로 안 갚힌다. 값이 나가는 신호의 되돌리기 비용을 보라. |

입장 조정: 무조건 웹 고정을 철회한다. 소유권 게이트로 기대값을 가르는 조건부 결정으로 바꾼다.
다만 약점 공략의 “기본값=AI 사업부”는 기각한다. 현재 사실(고객 없음·설계 AI 위임·오지 말라는 내부 조언) 위에서 기본 기대값이 높은 쪽은 웹 코어다. AI는 게이트 통과 시에만 선회.

---

비용 대비 산출 (오늘부터 실행 가능한가)

규칙: 사이드로 못 사는 것을 본업에 두고, 싸게 살 수 있는 것을 사이드에 둔다.
단, AI 팀이 eval·사용자·설계 기준을 실제로 쥐게 해주면, Python+eval을 본업에서 사는 편이 사이드보다 싸다 → 그때는 AI가 이긴다.

---

질문에 대한 단정 답

1. 어느 신호가 센가 (연봉·규모 상단)

• 현 상태 그대로:

「Python+AI툴, 사용자·운영·설계 부족」 ≪ 「C# 대규모 설계·운영(숫자 있는)」

• 시장이 사는 건 언어가 아니라 eval·비용·관측·장애를 본인이 소유한 문장이다.
• AI 사업부가 실사용자 + eval/비용 소유를 주면 그 문장은 웹 티켓 3년보다 세다.
• 설계를 AI에 맡기고 지표가 없으면 red flag 수렴.

2. C# 감점

• 있다. 치명적이진 않다. 서류 1차에서 “일반 백엔드” 분류 리스크는 인정(약점 ③).
• 메우기: 문법·프레임 수주~수개월 / eval·서빙·실패 모드 있는 공개 산출물 1~2개 = 주 8~12h × 1.5~2년.
• 상단일수록 리크루터가 GitHub을 안 볼 수 있으므로, 이력서 본문에 Python·eval·배포 수치를 박고, 타깃을 ML/AI 플랫폼·프로덕션 ML·AI 제품 엔지니어(시스템형) 로 고정해 필터를 우회한다.
• 반대로 고객·SLA·설계 소유 2~3년은 사이드로 복구 불가.

3. AI 사업부 경력기술서 (현 설명 기준)

• 남는 문장: “상용 AI 코딩 툴로 초기 제품” 수준 → 채용 red flag에 가깝다.
• 치환 조건: 본인이 eval 기준·품질 게이트·비용/지연·출시 지표를 쥔다. 지금 서술과 충돌하면 실행 불가능에 가깝다.
• 게이트를 통과하면 한 줄이 바뀐다:

“LLM 신제품 eval·모니터링 설계, 환각률 X→Y, 요청당 비용 −Z%, 사용자 N 운영.”
이건 사이드만으로 복제하기 어렵다.

4. 현직자 만류 가중치

• 높다. 단 veto 절대는 아니다(약점 ⑤ 수용).
• “일하기 불편” ≠ “이직 불리”를 구분하고, 웹 쪽에도 같은 실사를 한다.
• 그래도 같은 사다리를 밟은 사람의 “시간 대비 산출 안 나온다”는 말은 기회비용 1차 데이터로 유지한다. 무시하고 2~3년 쓰는 비용은 사이드로 못 갚는다.

---

의사결정 절차 (오늘 실행, 값어치 있음)

배치 확정 전에 양쪽 리드에게 묻고, 답의 구체성으로 판정한다. 질문 비용 ≈ 0, 오판 비용 ≈ 2~3년.

AI 사업부 — 둘 다 통과 시에만 선택

1. “사내/파일럿 포함 실사용자 붙는 시점이 로드맵 날짜로 6개월 안입니까?” → 날짜 있으면 통과, “미정”이면 탈락.
2. “Eval + 비용·지연 모니터링을 제가 맡아도 됩니까? 설계 기준은 사람이 소유합니까?” → 승낙·범위 명확하면 통과.

웹 코어 — 이 확약 없으면 가지 마라 (약점 ① 대칭 처리)

1. “입사 6~12개월 내 p99/처리량/장애 MTTR/비용 중 내가 숫자로 남길 구간이 있습니까?”
2. “로그·이벤트 파이프라인 또는 추천/검색/이상탐지 등 실트래픽 ML 인접 한 조각을 문서상 직무에 넣을 수 있습니까?”

현재 본문에 적힌 사실만으로 기대값: AI 게이트 탈락 쪽 → 웹 + 패키지.

---

웹 선택 시 필수 실행 패키지 (조건 아님, 필수)

1. 본업: p99, 처리량, MTTR, 가용성, 비용 — 숫자 스토리.
2. 본업 내 자원: 데이터/이벤트 파이프라인, 가능하면 실트래픽 ML 한 조각 본인 소유.
3. 사이드 주 8~12h: Python + (RAG/서빙 또는 학습·평가) + eval·모니터링·실패 모드 공개 1~2개.
4. 이직 타깃 한 줄: 연봉·규모 상단이면 프로덕션 ML / ML·AI 플랫폼 / 시스템형 AI 엔지니어. “LLM API만 붙인 제품”만 노리면 웹 선택의 이점이 줄어든다.

AI 선택 시(게이트 통과 후): 설계·eval·비용의 사람 소유를 분기마다 재확인. AI 코딩 툴에 설계를 넘기는 문화가 고착되면 즉시 사내 이동 — 그게 약점 공략이 말한 “되돌리기”의 올바른 쓰임이다.

---

한 줄 결론

부서를 고르지 말고, 소유권 게이트로 기대값을 고른다.
오늘 주어진 사실만 보면 웹(C#) + 숫자·파이프라인 소유 + 주 8~12h Python/eval 사이드가 시간당 이직 산출이 높다.
AI 사업부는 “AI 이력 빠른 부착”처럼 보이지만, 사용자·eval·설계 소유가 없으면 키워드만 비싼 저산출이다.
반대로 6개월 내 실사용 + eval 소유가 문서·말로 확보되면 AI로 선회하는 편이 싸게 먹힌다 — 그때는 다수안의 무조건 웹도, 약점 공략의 무조건 AI도 둘 다 틀린다.

출처

• digitalapplied.com[1]
• kore1.com[2]
• dataexpert.io[3]
• youtube.com[4] (Eval / LLMOps as core 2026 skills)

최종 수정안 — "긴줄"의 반박을 흡수한 조건부 판단

결론 변경: 웹 부서(C#) 단독 추천에서 → "3중 조건부 AI 사업부 우선, 실패 시 웹 부서"로 이동합니다. 제 렌즈(당사자의 실제 하루·감정·소진 위험)에서 보더라도 긴줄의 지적 상당수가 유효하고, 제가 앞서 현직자 경고에 준 가중치는 절차적으로 허술했습니다. 다만 완전히 넘어가지는 않습니다 — 어디를 그대로 두고 어디를 고치는지 명확히 구분합니다.

받아들이는 것

①·② (팀 자산 ≠ 개인 경험, 2주 차는 스냅샷일 뿐) — 타당합니다. 대규모 C# 코어팀 신입이 실제로 받는 업무는 레거시 티켓 처리일 가능성이 높고, 이건 "고객은 있지만 내 손이 닿지 않는" 상태로 AI 사업부의 공허함과 감정적으로 동형(同型)입니다. 제가 "웹 부서=성장, AI 사업부=소진"으로 이분법을 세운 건 성급했습니다. 소진(burnout)을 만드는 건 언어나 부서가 아니라, 그 안에서 자기 판단이 결과로 돌아오는 순간이 있는가입니다. 이 진단 기준은 유지하되, 두 부서 모두에 동일하게 적용해야 합니다.

④ (eval 설계는 고객 규모를 요구하지 않는다) — 이건 제 원래 우려("검증 대상이 없다")에 대한 정확한 반박입니다. 사내 사용자 수십 명, 요청 수천 건이면 환각률·지연·비용 모니터링 체계를 만들 수 있고, 이건 "AI가 설계한 걸 내가 검증했다"는 완결의 서사를 AI 사업부 안에서도 만들어낼 수 있다는 뜻입니다. 다만 — 이건 그 역할이 실제로 질문자에게 배정될 때만 유효합니다. 배정되지 않으면 그냥 낙관적 가정입니다.

⑤ (증거 위생 — 한쪽에만 실사했다) — 뼈아픈 지적입니다. 저는 AI 사업부 현직자의 경고만 근거로 삼고 웹 부서 현직자에게는 같은 질문(신입이 실제로 설계·장애 대응에 관여하는지, 티켓만 처리하는지)을 던지지 않았습니다. 이 비대칭을 방치한 채 결론을 내리는 건 확증이지 판단이 아닙니다.

받아들이지 않는 것

⑥ (되돌리기 비용) 은 전략 렌즈의 타당한 지적이지만 제 렌즈에서는 부차적입니다. 사람이 2~3년을 "버티는 시간"으로 느끼는지 "쌓이는 시간"으로 느끼는지는 되돌리기 난이도가 아니라 그 안에서 자율성·피드백·성장 실감(JD-R)이 있었는지로 결정됩니다. 되돌리기가 쉬운 선택도 소진 상태로 끝나면 이력서 문장 하나 못 건집니다.

그리고 현직자 경고를 "veto가 아니라 데이터 하나"로 낮추는 것에는 동의하지만, 0으로 낮추는 것에는 동의하지 않습니다. 표본이 부실하다는 지적은 "더 물어봐야 한다"는 뜻이지 "무시해도 된다"는 뜻이 아닙니다. 같은 사다리를 밟은 사람이 자발적으로 만류했다는 사실 자체는, 그 표본이 작더라도 회사 소개 문서나 채용 트렌드 기사보다 이 특정 팀의 실제 하루에 대해 더 직접적인 정보입니다.

---

최종 답변

배치 면담에서 두 부서 모두에게 아래 질문을 던지고, 답변의 구체성으로 판정하십시오.

AI 사업부에 물을 것

1. "이 제품이 사내 사용자든 파일럿 고객이든 실사용자에게 붙는 시점이 언제입니까?" — 날짜가 나오면 통과, "미정"이면 탈락.
2. "제가 이 제품의 품질 평가(eval)·비용·지연 모니터링을 맡아도 됩니까?" — 승낙이면 통과. 이건 신입에게 잘 넘어오는 업무이자, 2026년 AI/ML 채용에서 실제로 확인하는 핵심 신호입니다. (digitalapplied.com[1], dataskew.io[2])

웹 부서에 물을 것

3. "신입이 실제로 설계 논의나 장애 대응(온콜, 포스트모템)에 참여합니까, 아니면 기존 설계 안에서 티켓만 처리합니까?" — 참여한다는 구체적 사례(회의명, 최근 장애 대응 경험 등)가 나오면 통과, "적응 기간 지나면"처럼 뭉개면 탈락.

판정

• AI 사업부가 1·2 모두 통과 → AI 사업부 선택. "LLM 제품의 eval 파이프라인을 설계해 환각률·비용·지연을 개선했다"는 문장은 C# 티켓 3년으로 못 만듭니다.
• 웹 부서가 3에서 통과 → 웹 부서 선택, 단 사내 데이터 파이프라인이나 실트래픽 ML 기능을 6개월 내 직무에 넣는 것을 조건으로 겁니다.
• 양쪽 다 탈락 → 이건 "부서 선택" 문제가 아니라 "이 회사에 남을지"의 문제입니다. 인턴 기간 중 사내 이동 가능성이나 타사 인턴을 함께 검토하십시오.
• 언어(C#) 격차는 어느 경우든 주 8~12시간, 사이드 프로젝트로 채울 수 있는 결핍이므로 최종 판단 기준에서 제외하십시오. 채워지지 않는 건 언어가 아니라 소유권 경험입니다.

핵심 한 줄: 부서 이름표가 아니라 "누가 그 사다리를 만드는가"를 물으십시오 — AI에게 위임된 설계든, 시니어에게 고정된 설계든, 당신 손에 판단권이 없으면 3년 뒤 남는 이야기는 똑같이 흐릿합니다.

Sources: AI Developer Hiring 2026 — digitalapplied[1], AI Engineering Roadmap 2026 — dataskew[2], In-Demand ML Roles 2026 — Acceler8[3]

[최종 수정안: 'C# 우회론'의 치명적 맹점과 AI 프로덕트 엔지니어로서의 정면 돌파]

1. 타 전문가 의견의 부분적 수용 (정량적 지표의 중요성)
"고객과 운영 지표(Metrics)가 없는 3년은 이력서에 남길 것이 없다"는 타 전문가들의 지적은 전적으로 타당합니다. 제가 초안에서 이 부분의 리스크를 과소평가했음을 인정합니다. AI가 작성한 코드를 수동적으로 검토만 하거나, 실제 트래픽을 받아보지 못하고 3년을 보낸다면 AI 사업부는 최악의 '물경력'이 될 것입니다.

2. 다수결 합의('C# 코어팀 + 사이드 프로젝트')에 대한 정면 반박
그럼에도 불구하고 타 전문가들이 만장일치로 내세운 'C# 웹 부서에서의 대규모 시스템 경험 후 AI 직무 이직'이라는 대안은 현실 채용 생태계를 전혀 모르는 모순된 탁상공론입니다.

• 언어와 생태계의 늪: 현대 AI/MLOps 생태계(vLLM, Ray, KubeFlow 등)는 Python, Go, C++로 굴러갑니다. C# 코어 시스템에서 3년을 뒹군 엔지니어를 상위 채용 시장은 '시스템 감각이 있는 MLOps 인재'가 아니라 그저 '엔터프라이즈 C# 백엔드 개발자'로 봅니다.
• 불가능한 가설: 대규모 트래픽 장애를 막느라 야근하는 주니어 개발자가, 퇴근 후 사이드 프로젝트만으로 실무 수준의 ML 파이프라인을 구축해 언어 격차를 메운다는 것은 인간의 한계를 벗어납니다. 서류 필터링 단계에서 직무기술서에 'Python / LLM 제품 개발'이 찍혀 있지 않으면 실력을 증명할 기회조차 주어지지 않습니다.

3. 직무 패러다임의 변화와 '고객 없음'의 재해석
현재 채용 시장에서 가장 수요가 폭발하는 직무는 무거운 MLOps가 아니라, AI 모델과 코딩 툴을 엮어 비즈니스 임팩트를 내는 'AI 프로덕트 엔지니어(AI Engineer)'입니다.
이 관점에서 '개발 2주 차 고객 없는 신규 팀'은 약점이 아니라 완벽한 샌드박스(기회)입니다. C# 코어 팀의 신입이 시니어가 짠 설계 안에서 3년간 레거시 유지보수와 티켓 처리에 매몰될 때, 신규 AI 팀에서는 0에서 1을 만드는 아키텍처 설계와 트래픽 대응의 주도권을 연차와 무관하게 신입이 쥘 수 있습니다.

4. 2026년 AI 채용 시장이 요구하는 가장 강력한 신호: 'Eval'
AI 엔지니어 채용 시 트래픽 규모보다 결정적인 척도는 "AI 모델의 환각(Hallucination)과 지연/비용을 수치화하여 평가(Eval)하고 모니터링하는 체계를 구축해 보았는가"입니다 (출처: AI Developer Hiring 2026[1], AI Engineer Roadmap 2026[2]). 이는 대규모 C# 시스템이 없더라도 사내 사용자 50명, 요청 1만 건 규모에서 충분히 구축하고 정량화할 수 있는 핵심 성과입니다.

5. 최종 결론 및 행동 지침 (조건부 단정)
AI 사업부(Python)를 선택하십시오. 단, 부서 배치 전 팀 리드에게 다음 두 가지를 질문하여 확답을 받아내야 합니다.

1. "6개월 내에 사내 파일럿이든 실사용자든 제품을 붙이고 트래픽을 발생시킬 구체적 로드맵이 있습니까?"
2. "제가 이 제품의 품질 평가 체계(Eval) 설계와 토큰 비용/지연 시간 모니터링을 전담하여 주도해도 됩니까?"

두 질문에 대한 답이 명확한 "Yes"라면 뒤돌아보지 말고 AI 부서로 가십시오. 3년 뒤 당신의 이력서에는 "LLM 제품 평가 파이프라인 설계로 환각률 X% 개선, API 비용 Y% 절감"이라는 문장이 적힐 것이며, 이는 C# 웹 부서의 주니어가 어떤 사이드 프로젝트로도 만들어낼 수 없는 대체 불가능한 스펙이 됩니다.

만약 위 조건이 명확히 거절당하거나 불투명하다면, 그때는 다수 의견대로 웹 부서(C#)를 택하십시오. 단, 그 경우에도 입사 6개월 내에 사내 데이터 파이프라인 관련 업무를 반드시 본인 소유로 가져와야만 C# 백엔드의 늪에서 탈출할 수 있습니다.

핵심 요약: 부서의 간판(대규모 vs AI)이 이직을 결정하지 않습니다. 그 부서 안에서 '당신이 무엇을 주도적으로 소유(Ownership)하고 수치화(Metrics)할 수 있는가'가 승패를 가릅니다.