AI 시대, 개발자 커리어의 새로운 좌표
AI 시대, 개발자 커리어의 새로운 좌표
얼마 전, 4년 차 개발자와 커리어 상담을 했습니다.
회사에서 구조조정을 당했다고 했습니다. 실력 문제는 아니라는 말도 덧붙였습니다. 팀이 통째로 정리됐고, 본인은 그 안에 있었을 뿐이라고요.
그런데도 표정은 계속 그 말에 머물러 있지 않았습니다. “이제 어디로 가야 할지 모르겠다”는 쪽에 더 가까웠습니다.
이 상담은 특별한 이야기가 아닙니다
2024년 한 해 동안 전 세계 기술 업계에서 28만 명 이상이 구조조정을 겪었습니다. 2025년에도 이미 18만 명 이상이 같은 길을 걸었습니다. Microsoft, Intel, Meta, Amazon — 실리콘밸리의 대기업들도 예외가 아니었습니다.
흥미로운 건 이 숫자의 이면입니다. TechCrunch의 분석에 따르면, 2025년 구조조정의 약 4분의 1이 “AI 기반 구조조정(AI-driven restructuring)”으로 분류됩니다. 단순히 경기 침체 때문이 아니라, AI가 기존 업무를 대체하면서 발생하는 구조적 변화라는 뜻입니다.
상담을 요청한 그분도 이 흐름 안에 있었던 것이 아닐까 생각했습니다.
“개발자는 다 비슷해지는 것 같아요”
그분이 이런 말을 했습니다.
이제 개발자는 다 비슷해지는 것 같아요. AI도 있고, 프레임워크도 다 거기서 거기고요.
그 말이 틀렸다고 느껴지진 않았습니다. 오히려 꽤 정확한 진단이었습니다.
Anthropic CEO Dario Amodei는 최근 이렇게 말했습니다.
3\~6개월 내에 AI가 전체 코드의 90%를 작성하게 될 것이다. 12개월 후에는 사실상 모든 코드를 AI가 작성하는 세상이 올 수 있다.
과장일까요? Google에서는 이미 신규 코드의 25% 이상이 AI로 생성되고 있습니다. GitHub Copilot, Cursor, Claude Code 같은 도구들이 일상이 된 지금, “구현”이라는 행위의 희소성은 분명히 줄어들고 있습니다.
Morgan Stanley의 보고서는 이 변화를 이렇게 요약합니다.
AI가 코딩을 대체하는 것이 아니라, AI가 코딩의 병목을 다른 곳으로 옮기고 있다. 이제 병목은 ‘코드 리뷰’, ‘테스트’, ‘설계 결정’에 있다.
그래서 저는 기술 이야기를 하지 않았습니다
이직 전략도, 스택도, 포트폴리오도 말하지 않았습니다.
대신 이렇게 물었습니다.
지금까지 일하면서, 내가 직접 정의한 문제를 풀어본 경험이 있었나요?
잠깐의 침묵이 있었습니다.
그분의 커리어를 돌아보면 주어진 요구사항을 잘 구현해왔고, 팀 안에서도 성실한 개발자였습니다. 하지만 ”이건 우리가 풀어야 할 문제다”라고 스스로 정의해본 경험은 많지 않았다고 했습니다.
왜 “문제 정의”가 중요해졌을까요?
여기에는 구조적인 이유가 있습니다.
1. AI는 “How”를 빠르게 만들지만, “What”을 결정하지 못합니다
Anthropic의 자체 연구에 따르면, Claude Code 사용자의 79%가 어떤 형태로든 “자동화(automation)”를 경험합니다. 코드 생성, 버그 수정, 리팩토링 — 이런 작업들이 점점 AI의 영역으로 넘어가고 있습니다.
하지만 같은 연구는 이렇게도 말합니다:
자동화와 증강(augmentation)의 경계가 흐려지고 있다. 하지만 여전히 ‘피드백 루프(Feedback Loop)’ 패턴에서는 인간의 개입이 필수적이다.
AI가 코드를 작성해도, ”이 코드가 풀어야 할 문제가 맞는지”를 판단하는 건 여전히 사람의 몫입니다.
2. 주니어 개발자가 가장 먼저 영향을 받고 있습니다
9,000명의 소프트웨어 엔지니어를 대상으로 한 설문에서, 90%가 “2020년보다 취업이 훨씬 어려워졌다”고 응답했습니다. 특히 주니어 개발자들이 그렇습니다.
이유는 단순합니다. 주니어 개발자들이 경험을 쌓던 업무 — 디버깅, 테스트 코드 작성, 단순 기능 구현 — 이것들이 AI로 대체되기 가장 쉬운 영역이기 때문입니다.
반면, 시니어 엔지니어 채용은 여전히 활발합니다. 단, “AI를 통합하고 관리할 수 있는” 시니어에 한해서요.
3. 기술 업계가 원하는 개발자상이 바뀌고 있습니다
Opcito Technologies의 2025 트렌드 리포트는 이렇게 말합니다:
엔지니어들이 점점 더 아키텍트, 디자이너, 문제 해결자(problem solver)처럼 변하고 있다. 시스템 아키텍처 정의, 사용자 경험 설계 같은 고차원적 업무에 집중하게 된다.
이건 추상적인 예측이 아닙니다. arol.dev의 분석에 따르면, 2025년 가장 성공적인 소프트웨어 엔지니어의 특징은 이렇습니다:
- 제품 지향적 사고(Product-oriented thinking): 고객의 니즈와 비즈니스 결과를 기술적 결정에 연결할 수 있는 능력
- T자형 역량: 하나의 전문성을 깊게 가지면서, 여러 도메인을 넓게 이해하는 능력
- 시스템 관리 역량: 배포, 모니터링, 확장성을 코드만큼 잘 다루는 능력
Product Engineer라는 역할
그래서 저는 그분에게 AI 이야기를 꺼냈습니다. AI가 무섭기 때문이 아니라, 지금 이 막막함의 이유를 설명해주기 위해서였습니다.
앞으로는 ‘무엇을 만들 수 있느냐’보다 ‘어떤 문제를 선택하고 풀 수 있느냐’가 더 중요해질 거예요.”“Product Engineer라는 역할은 기술이 아니라 문제에 서는 사람이에요.
Product Engineer는 기획자 흉내를 내는 개발자도 아니고, 개발 잘하는 기획자도 아닙니다.
- 문제를 관찰하고
- 이게 기술로 풀 가치가 있는지 판단하고
- 구조를 설계한 다음
- 기술을 도구로 사용하는 사람
저는 그렇게 정의합니다.
현실에서 이 전환은 어떻게 일어날까요?
몇 가지 실제 장면을 공유합니다.
장면 1: “왜 이 기능을 만드나요?”
한 스타트업에서 시니어 개발자가 기획서를 받았습니다. 요구사항은 명확했습니다. “결제 페이지에 할인 쿠폰 입력 필드 추가.”
예전 같았으면 바로 구현에 들어갔을 겁니다. 하지만 그는 먼저 데이터를 봤습니다.
- 현재 결제 전환율: 67%
- 결제 페이지 이탈 사유 1위: “총 가격이 예상보다 높음”
- 쿠폰 보유 고객 비율: 12%
그는 기획자에게 물었습니다.
쿠폰 필드를 추가하면 12%의 고객에게는 도움이 되겠지만, 88%의 고객에게는 ‘나는 쿠폰이 없네’라는 심리적 손실을 줄 수 있어요. 차라리 자동 할인 적용 후 ‘얼마 절약됐는지’ 보여주는 게 전환율에 더 효과적이지 않을까요?
이게 ”문제의 자리에 서는 것”입니다.
장면 2: AI와 협업하는 방식의 차이
두 개발자가 같은 AI 코딩 도구를 사용합니다.
개발자 A: “로그인 폼 만들어줘” → AI가 코드 생성 → 복사 → 붙여넣기 → 버그 발생 → 다시 AI에게 질문 → 반복
개발자 B: “우리 서비스는 60대 이상 사용자가 40%야. 로그인 과정에서 이탈이 많은데, 큰 글씨, 단순한 단계, 에러 메시지의 친절한 표현이 핵심이야. 이 조건으로 로그인 플로우를 설계해줘” → AI가 컨텍스트를 이해한 설계 제안 → 개발자가 판단하고 수정 → 더 나은 결과
METR(Model Evaluation and Threat Research)의 2025년 연구는 흥미로운 결과를 보여줍니다. 경험 많은 오픈소스 개발자들이 AI를 사용했을 때, 오히려 19% 더 느려졌습니다.
AI 연구자들은 이렇게 해석합니다.
AI가 모든 상황에서 생산성을 높이는 것은 아니다. 특히 복잡한 코드베이스에서 맥락을 이해하고 있는 숙련된 개발자에게는, AI가 오히려 추가적인 검증 부담을 줄 수 있다.
결국 AI를 잘 쓰는 것도 “문제를 잘 정의하는 능력”에서 시작합니다.
그래서 드린 숙제
그분에게 당장 답을 준 건 아닙니다. “이렇게 해보세요세요” 같은 말도 하지 않았어요.
대신 이런 숙제를 드렸습니다.
다음 프로젝트에서는 구현부터 하지 말고, 이게 어떤 문제를 푸는 건지부터 문장으로 써보세요.
구체적으로는 이런 질문들입니다.
- 이 기능이 없으면 사용자에게 어떤 불편이 있는가?
- 이 불편은 기술로 풀 수 있는 종류인가, 아니면 프로세스나 커뮤니케이션의 문제인가?
- 기술로 푼다면, 가장 단순한 해결책은 무엇인가?
- 이 해결책이 작동했는지 어떻게 알 수 있는가?
이 네 가지 질문에 답하는 연습을 하면, 자연스럽게 “구현자”에서 “문제 정의자”로 이동하게 됩니다.
AI 시대에 커리어가 흔들리는 이유
AI 시대에 커리어가 흔들리는 이유는 실력이 없어서가 아닐 수 있습니다. 문제의 자리에 서본 적이 없었기 때문일 수도 있습니다.
IBM의 Arvind Krishna 회장은 Anthropic CEO의 예측에 이렇게 반박했습니다
AI가 코드의 90%를 작성한다는 건 과장이다. 현실적으로는 20\~30% 정도일 것이다. 단순한 사용 사례에서는 자동화가 말이 되지만, 그만큼 복잡한 사용 사례도 많다.
하지만 그조차도 이렇게 덧붙였습니다.
역사적으로 가장 생산적인 회사가 시장 점유율을 가져간다. AI가 프로그래머의 생산성을 극적으로 높인다면, 그건 더 많은 제품을 만들고 더 많은 시장을 가져가는 것으로 이어진다.
결국 살아남는 건 “더 많이 구현하는 사람”이 아니라 “더 좋은 문제를 찾는 사람”입니다.
마치며
혹시 여러분도 요즘, “다음엔 어디로 가야 하지?”라는 생각을 하고 계신가요?
그 질문 앞에서 기술 말고, 문제를 먼저 떠올려본 적은 있으신가요?
참고 자료
- TechCrunch, “A comprehensive list of 2025 tech layoffs” (2025)
- Anthropic Research, “AI’s impact on software development” (2025)
- Morgan Stanley, “AI in Software Development: Creating Jobs and Redefining Roles” (2025)
- Fortune, “Tech leaders at Anthropic, IBM, and Meta warn that AI is coming for software developer jobs” (2025)
- METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity” (2025)
- Opcito Technologies, “Top product engineering trends 2025” (2025)
- Lenny’s Newsletter, “State of the product job market in 2025” (2025)