소프트웨어 엔지니어링의 향후 2년 (The Next Two Years of Software Engineering): ”숙련의 재정의“

 

---

 

The Next Two Years of Software Engineering

---

소프트웨어 엔지니어링의 향후 2년 | GeekNews

---

"차라리 과외 뛸 판"…취준생 변호사 574명 '역대 최다'

---

[취준] 100곳을 지원했던 2025 하반기 회고

---

'억' 소리 나는 몸값에도 “올해 연봉 인상” 기대 중인 직군은?

---

 

소프트웨어 엔지니어링의 향후 2년: AI 에이전트가 바꾸는 ‘일의 구조’ (그리고 Hacker News 반응)

출처: addyosmani.com 글 + Hacker News 토론 요약 정리

[TL;DR: 큰 흐름 5가지]

• AI 에이전트 기반 개발이 자동완성 수준을 넘어 ‘실제 작업 수행’ 단계로 진입하며, 소프트웨어 엔지니어링의 역할과 진입 구조가 빠르게 흔들리고 있음
• 주니어 채용 감소와 효율성 중심 조직이 동시에 나타나며, 소수의 숙련 인력이 AI 도구로 더 많은 일을 처리하는 구조가 확산
• 코딩 자체보다 검증·설계·판단 능력이 중요해지며, AI 출력물을 다룰 수 있는 인간 역량이 핵심 차별 요소로 부상
• T자형 인재(깊은 전문성 + 넓은 적응력)가 빠르게 변화하는 AI 환경에서 유리하며, 한 분야의 깊이와 다분야 적응력을 동시에 요구하는 흐름 가속
• 전통적인 CS 학위 중심 경로 약화와 함께 포트폴리오·부트캠프·기업 주도 교육 등 다층적 학습 생태계 확산

1. 주니어 개발자 문제

1-1) 동시에 존재하는 두 흐름
• AI가 엔트리 레벨 업무를 자동화하면서 주니어 채용이 급감하는 흐름
• 소프트웨어가 전 산업으로 확산되며 수요가 다시 늘어나는 흐름
(두 흐름이 동시에 존재)

1-2) 시장 신호 / 데이터
• Harvard의 6,200만 명 근로자 대상 연구: 기업이 생성형 AI 도입 시 주니어 개발자 고용이 약 9~10% 감소, 시니어 고용은 거의 영향 없음
• 빅테크 기업들이 지난 3년간 신입 채용을 50% 축소
• 한 엔지니어의 표현: “AI 코딩 에이전트 비용이 더 저렴한데 왜 주니어에게 9만 달러를 지불하겠는가?”

1-3) 거시 요인 + AI 가속
• 2022년경 금리 인상과 팬데믹 후 조정 같은 거시 요인이 AI 도구 확산 이전에 먼저 영향을 미쳤으나, AI가 이 추세를 가속화함

1-4) 생산성 구조 변화
• AI 보조를 활용한 시니어 엔지니어 한 명이 과거에는 소규모 팀이 필요했던 작업량을 처리 가능

1-5) 낙관적 시나리오
• AI가 기술 분야뿐 아니라 헬스케어/농업/제조/금융 등 모든 산업에서 개발자 수요를 폭발적으로 증가시킬 가능성
• 개발자를 대체하기보다 AI가 개발 작업을 코더를 고용한 적 없는 도메인으로 확산시키는 힘의 증폭기(force multiplier) 역할
• “AI 네이티브” 개발자들이 특정 니치를 위한 자동화와 통합을 빠르게 구축하는 다른 형태의 엔트리 레벨 역할 증가 가능성
  • 미국 노동통계국: 2024~2034년 소프트웨어 직종 약 15% 성장 전망

1-6) 비관적 시나리오의 장기 리스크
• 오늘의 주니어는 내일의 시니어 엔지니어이자 기술 리더
• 인재 파이프라인을 완전히 차단하면 5~10년 후 리더십 공백 발생
• 업계 베테랑: “느린 쇠퇴(slow decay)” — 후계자 양성을 중단하는 생태계

1-7) 주니어 개발자를 위한 조언(원글)
• AI 능숙도와 다재다능함 필요
• “ 주니어 한 명 + AI = 소규모 팀 출력”을 낼 수 있음을 입증
• Cursor, Antigravity, Claude Code, Gemini CLI 같은 AI 코딩 에이전트로 큰 기능을 구축하되, 대부분의 코드를 이해하고 설명할 수 있어야 함
• AI가 쉽게 대체할 수 없는 기술에 집중: 커뮤니케이션, 문제 분해, 도메인 지식
• QA, DevRel, 데이터 분석 같은 인접 역할을 진입점으로 고려
• AI API 통합 프로젝트를 포함한 포트폴리오 구축
• 수습직/인턴십/계약직/오픈소스 기여 등 다양한 경험 확보
• “훈련이 필요한 신입”이 아니라 “바로 기여 가능한 엔지니어”가 되어야 함

1-8) 시니어 개발자를 위한 조언(원글)
• 주니어 감소로 더 많은 단순 작업과 반복업무가 시니어에게 돌아옴
• 일상적 작업에 자동화 활용하되 모든 것을 혼자 하지 말 것
• CI/CD, 린터, AI 기반 테스트를 구축해 기본 문제를 초기에 차단
• 오픈소스나 타 부서 코칭을 통해 비공식적 멘토링 역할
• 경영진에게 올-시니어 팀의 장기 리스크를 명확히 전달
• 주니어 수요 회복 대비: 효과적 온보딩 + AI 기반 업무 위임 구조 준비
• 개인 생산성보다 팀 전체 출력/영향력 증폭에 가치 집중

2. 스킬 문제

2-1) 이미 일어난 변화
• 현재 개발자의 84%가 AI 보조 도구를 정기적으로 사용
• 버그나 새 기능에 직면했을 때 처음부터 코드를 작성하기보다, 프롬프트 작성 → AI 생성 코드 조각 조합 방식이 일반화

2-2) 엔트리 레벨이 “어려운 방식”을 건너뜀
• 이진 검색 트리를 처음부터 구축하거나 메모리 누수를 직접 디버깅한 적이 없을 수 있음
• 역량 중심이 알고리듬 구현에서 “AI에게 올바른 질문” + “출력 검증”으로 이동

2-3) 탈숙련화 우려
• 일부 시니어는 독립적으로 코딩하지 못하는 세대(탈숙련화)를 우려
• AI 생성 코드에는 경험이 적은 개발자가 놓치기 쉬운 미묘한 버그와 보안 취약점이 포함될 가능성

2-4) 대안 시나리오(80/20)
• AI가 반복적/일상적 80% 작업을 처리하고, 인간은 가장 어려운 20% 문제에 집중
· 아키텍처 설계, 복잡한 통합, 창의적 설계, 엣지 케이스 처리
• AI의 보편화는 깊은 지식을 쓸모없게 만들기보다 인간 전문성을 더 중요하게 만듦
• 모두가 AI 에이전트에 접근할 수 있을 때, 뛰어난 개발자를 구별하는 것은 “AI가 틀리거나 최적이 아닐 때를 아는 것”
• 한 시니어 엔지니어의 말: “최고의 소프트웨어 엔지니어는 가장 빠른 코더가 아니라 AI를 불신해야 할 때를 아는 사람”

2-5) 프로그래밍의 변화
• 보일러플레이트 작성 감소
• AI 출력물의 논리 오류/보안 결함/요구사항 불일치 검토 비중 증가
• 핵심 역량: 소프트웨어 아키텍처, 시스템 설계, 성능 튜닝, 보안 분석
• AI는 웹앱을 빨리 만들지만, 전문 엔지니어는 보안 모범 사례 준수 여부와 레이스 컨디션 가능성을 점검

2-6) 2025년 커뮤니티 논쟁(두 입장)
• 손으로 코드를 거의 작성하지 않으며 코딩 인터뷰도 바뀌어야 한다
• 기초를 건너뛰면 AI 결과가 깨질 때 더 많은 문제 대응에 시달리게 된다
• 업계 전반에서 “AI의 속도”와 “통제할 기초 지혜”를 동시에 갖춘 엔지니어를 기대하는 흐름 형성

2-7) 주니어 개발자를 위한 조언(원글)
• AI를 의존 수단이 아닌 학습 도구로 활용
• AI가 제안한 코드가 왜 동작하는지 분석 + 잠재적 약점 식별
• 주기적으로 AI 도움을 끄고 핵심 알고리듬을 처음부터 구현
• CS 기초 역량 집중: 자료구조, 알고리듬, 시간·공간 복잡도, 메모리 관리
• 프로젝트를 두 번 구현(AI와 함께/AI 없이)해 비교
• 프롬프트 설계와 도구 사용 능력 체계적으로 습득
• 엄격한 테스트 습관: 단위 테스트, 스택 트레이스 읽기, 디버거 활용
• AI가 복제할 수 없는 보완 역량: 시스템 설계 감각, UX 직관, 동시성 사고력

2-8) 시니어 개발자를 위한 조언(원글)
• 품질과 복잡성을 책임지는 역할로 자리매김
• 전문성 강화: 아키텍처/보안/스케일링/도메인 지식
• AI 컴포넌트 포함 시스템 모델링 + 실패 시나리오 지속 점검
• AI 생성 코드에서 자주 발생하는 취약점/문제 유형 최신 인식 유지
• 멘토·리뷰어 역할: AI 사용 허용 범위 + 수동 리뷰 필수 영역(결제/안전 코드) 정의
• 반복 API 연결은 주니어+AI에 맡기고, 어떤 API를 설계할지 결정하는 창의적·전략적 역할에 집중
• 커뮤니케이션/교차 도메인 이해 등 소프트 스킬 지속 투자
• 인간을 대체 불가능하게 만드는 요소: 건전한 판단력, 시스템 사고, 멘토십

3. 역할 문제

3-1) 두 방향이 공존
• 개발자 역할이 AI 생성 코드를 감독하는 제한적 감사자로 축소되거나,
• AI 주도 시스템을 설계·조율하는 핵심 오케스트레이터로 확장될 가능성이 공존

3-2) 극단 시나리오 1: 감사자(점검자)
• 소프트웨어 구축보다 AI 출력물 감사/감독에 주력
• AI 시스템(또는 노코드 시민 개발자)이 프로덕션 담당
• 인간 개발자는 자동 생성 코드 검토, 오류/편향/보안 이슈 확인, 배포 승인
• 창작의 기쁨이 리스크 관리의 불안으로 대체
• 일부 엔지니어는 직접 코딩보다 AI PR 평가와 자동화 파이프라인 관리에 더 많은 시간을 씀
• 한 엔지니어의 말: “AI가 던져주는 것을 치우는 코드 청소부로 끝나고 싶지 않다”

3-3) 대안적 미래: 고수준 오케스트레이터
• 개발자가 기술적/전략적/윤리적 책임을 결합한 고수준 오케스트레이터로 진화
• AI “워커” 환경에서 인간 개발자는 아키텍트/총괄 계약자 역할:
· 전체 시스템 구조 설계
· 어떤 작업을 어떤 AI나 컴포넌트에 맡길지 결정
· 여러 구성 요소를 엮어 솔루션 조합
• 에이전틱 개발 환경에서 엔지니어는 작곡가처럼:
· 모든 코드를 직접 쓰진 않지만 아키텍처/인터페이스/상호작용의 멜로디를 정의
· 소프트웨어 엔지니어 + 시스템 아키텍트 + 제품 전략가 역할 결합
• 낙관적 관점: AI가 단조로운 작업을 처리하며 역할이 고가치 활동으로 이동 → 일이 더 흥미로워질 수 있음
• 방향은 조직이 AI를 통합하는 방식에 따라 달라짐
· AI를 노동 대체로 보는 회사: 팀 축소 + 자동화 유지 요청
· AI를 팀 증폭으로 보는 회사: 인원 유지 + 더 큰 문제/야심찬 프로젝트 도전

3-4) 주니어 조언(원글)
• 단순 코드 작성 범위를 넘어 역할 확장 모색
• 테스트 케이스, CI 파이프라인, 모니터링 등 감사자·관리자 역량 확보
• 개인 프로젝트로 ‘직접 만드는 경험’ 유지(창의적 동기 보존)
• 시스템적 사고: 컴포넌트 통신 이해, 잘 설계된 API 특징 학습
• 블로그/시스템 설계 케이스 스터디 지속 학습
• 코드 생성 외에도 오케스트레이션 프레임워크/AI API 등 자동화 도구 이해 확장
• 문서를 남에게 설명하듯 명확하게 쓰는 습관
• 시니어에게 “동작하나?”를 넘어 “중요 요소를 빠뜨렸나?” 질문
• 단순 코더가 아니라 검증자·설계자·커뮤니케이터로 성장 준비

3-5) 시니어 조언(원글)
• 리더십과 아키텍처 책임 수용
• AI와 주니어가 따를 표준/프레임워크 정의
• 코드 품질 체크리스트 + 윤리적 AI 사용 정책 정의
• 규정 준수/보안 이슈 최신 인식 유지
• 시스템 설계/통합 전문성: 데이터 흐름 매핑, 실패 지점 사전 식별
• 오케스트레이션 플랫폼(Kubernetes, Airflow, 서버리스, 에이전트 오케스트레이션 도구) 숙련
• 멘토 역할 강화: 코드 리뷰, 설계 토론, 기술 가이드라인
• 다른 사람(또는 무언가)의 코드를 빠르게 평가하고 고수준 피드백 제공 능력
• 제품/비즈니스 감각(왜 만드는지, 고객이 뭘 중요시하는지) 개발
• 프로토타입/해커톤/신기술 탐구로 창작 에너지 유지
• 코드를 쓰는 사람에서 시스템을 지휘하는 사람으로의 전환

4. 전문가 vs 제너럴리스트 문제

4-1) 좁은 전문성의 리스크
• 좁은 영역 전문가는 니치가 자동화되거나 빠르게 가치가 사라질 위험
• 모델/도구/프레임워크가 빠르게 부상·쇠퇴하는 상황에서 단일 스택 올인은 위험
• 레거시 프레임워크 전문가는 AI가 최소한의 인간 개입으로 동일 작업을 처리하는 순간 수요 급감 가능
• 특정 스택/프레임워크/제품 영역에만 좁게 특화된 개발자는 영역이 쇠퇴/중복될 때 방향 상실 가능
· COBOL, Flash, 전환하지 않은 모바일 게임 엔진 전문가 사례처럼
• AI 자동화는 특정 프로그래밍 작업을 순식간에 사소한 일로 만들어 역할을 약화시킬 수 있음
• 한 가지만 아는 전문가(SQL 미세 조정, Photoshop→HTML 슬라이싱)는 AI가 90% 처리하는 상황에 직면 가능
• 채용 시장은 최신 니치를 쫓음: 과거 클라우드 인프라 → 현재 AI/ML 수요 급증
• 어제 기술에 좁게 특화된 인력은 니치 매력 소멸로 커리어 정체 체감

4-2) T자형 개발자(대안)
• 한두 영역의 깊은 전문성(수직) + 다양한 영역에 대한 넓은 친숙함(수평)
• 다학제 팀에서 “접착제” 역할: 다른 전문가들과 소통하고 공백을 채움
• 회사는 너무 얕거나 좁게 집중된 사람보다, 강한 핵심 역량 + 스택 전반을 다루는 인재 선호
• T자형은 핸드오프 대기 없이 종단간 해결 가능 → 효율성 향상, 지식 결합으로 혁신 가능성 확대
• AI 도구가 제너럴리스트를 더 증폭:
· 백엔드가 UI 구현 가능 / 프론트가 서버 보일러플레이트 생성 가능
• AI가 풍부한 환경에서 한 사람이 넓은 범위를 다루기 쉬움
• 반대로 깊이만 있는 인력은 니치 일부 자동화 시 확장 경로 제한 가능
• 현재 엔지니어링 직무의 약 45%가 다중 도메인 숙련 요구
· 프로그래밍 + 클라우드 인프라
· 프론트엔드 + 기본 ML 이해

4-3) 주니어 조언(원글)
• 커리어 초기에 넓은 기반을 의식적으로 구축
• 특정 역할로 채용돼도 사일로 밖 영역을 꾸준히 관찰
• 모바일은 백엔드 기초, 프론트는 간단 서버 구현 경험 확보
• Docker, GitHub Actions 등 배포/운영 도구 학습
• 흥미 있는 한두 영역을 깊게 파고들어 수직 전문성 형성
• 하이브리드 브랜딩
· 예: 클라우드 보안 중심 풀스택
· 예: UX 전문 프론트엔드
• AI 도구로 새로운 도메인 빠른 학습(초보 단계에서 AI로 기본 API 생성 후 구조 이해)
• 재숙련을 습관화
• 해커톤/크로스펑셔널 프로젝트 참여로 강제 확장
• 매니저에게 다른 영역 참여 의사 표현
• 커리어 초반에는 적응력 자체가 가장 강력한 경쟁력

4-4) 시니어 조언(원글)
• 스킬 그래프를 명확히 파악(깊이 영역 + 인접 도메인)
• 인접 영역 1~2개를 대화 가능한 수준까지 끌어올리기
· DB 전문자라면 최신 프론트엔드 프레임워크 또는 ML 파이프라인 기초
• AI 지원으로 약한 영역에서 작은 실험 프로젝트 수행
• 기존 전문성을 새로운 맥락에 연결(웹 성능 최적화 → ML 추론 최적화 등)
• 역할을 더 크로스펑셔널하게 설계하거나 포지션 제안
• 통합 챔피언(책임자) 역할 자원
• 멘토링하며 기술 전파 + 새로운 관점 습득
• 이력서에 다재다능함/확장성 반영
• 반복 패턴과 이전 가능한 지식 정리
• T자형 롤모델: 깊이(권위) + 수평 확장

5.  교육 문제

5-1) 큰 질문
• CS 학위가 황금 표준으로 남을지, 부트캠프/온라인/고용주 주도 훈련이 대체할지 불확실
• 산업 변화 속도를 대학이 따라잡기 어려운 구조가 될 가능성

5-2) 시나리오 1: 대학은 중요하지만 관련성 유지 어려움
• 학위는 기본 자격이나 커리큘럼 개편이 느림(관료적 승인 절차)
• 산업과 단절된 이론/구식 실습이라는 인식
• 졸업생들이 클라우드/현대 DevOps/AI 도구를 배운 적 없다고 보고
• 높은 비용 대비 낮은 관련성 교육이면 “비싼 게이트키퍼” 위험
• 회사가 학사 요구를 유지 → 부담이 학생에게 전가(부트캠프/온라인/독학으로 보완)
• 학자금 대출 부채 증가 + 기업의 신입 훈련 비용(직무 기술 부족)
• 대학이 AI 윤리/클라우드 과목을 추가해도, 도입 시점엔 업계 도구가 이미 바뀌었을 수 있음

5-3) 시나리오 2: 전통 교육이 새로운 시스템으로 대체
• 부트캠프/온라인 인증/독학 포트폴리오/고용주 훈련 아카데미
• Google, IBM 등 일부 직무에서 학위 요건 철폐
• 2024년 기준 기업의 약 45%가 일부 포지션에서 학사 요건 폐지 계획
• 부트캠프 성숙: 상위 기업 채용 인력 배출, 12주 집중 등 짧고 실용적
• 채용 기준이 학위보다 포트폴리오/마이크로 자격증/검증된 기술로 이동
• GitHub 포트폴리오/공신력 인증이 학위 우회 수단
• 고용주 주도 교육 확대(자체 파이프라인, 부트캠프 파트너십)
• 일부 빅테크는 비전통 인재 대상 내부 교육 프로그램 운영
• AI가 학습 방법 자체를 바꿈: AI 튜터, 대화형 코딩 샌드박스, 맞춤형 학습 환경
• 모듈식 학습 생태계가 4년제 학위보다 접근성/유연성 우위
• CS 대학이 없는 나라에서도 Coursera 등으로 동일 강좌/포트폴리오 구축 가능

5-4) 지망생/주니어 조언(원글)
• CS 과정만으로 충분하다고 가정하지 말 것
• 실전 프로젝트(웹 앱, 오픈소스)로 보강
• 인턴십/산학협력 적극 활용
• 빠진 최신 주제는 온라인으로 보완
• GCP/AWS/Azure 인증으로 실무 역량 시그널링
• 독학/부트캠프라면 “잘 문서화된 실질 프로젝트” 최소 1개
• 커뮤니티 활동(오픈소스, 글쓰기)
• LinkedIn/밋업/행사 네트워킹
• 추천/신뢰 확보
• 지속 학습 전제(기술 유효 기간은 짧음)
• AI를 개인 튜터로 활용
• 포트폴리오/인증/작업을 지적으로 말하는 능력으로 기술 증명

5-5) 시니어/리더 조언(원글)
• 과거 학위/자격증만으로 영원히 버틸 수 없음
• 지속 교육(강좌/워크숍/컨퍼런스/인증)
• 실제 문제로 역량 평가하는 인터뷰 준비
• 신기술 사이드 프로젝트 지속
• 직무 요건 재평가(정말 CS 학위가 필요한가 vs 기술/학습 능력이 필요한가)
• 기술 중심 채용으로 인재 풀 확대
• 내부 훈련/도제형 역할 지원
• 비정규 배경 주니어 위한 멘토십 서클 지원
• 학계/대안 교육과 교류(자문, 초청 강연, 커리큘럼 피드백)
• 커리어 성장에 반영: 실제 성과 + 지속 학습이 추가 학위보다 중요

관통하는 핵심(원글)
• 시나리오들은 배타적이지 않으며 현실은 섞여서 전개됨
• 어떤 기업은 주니어를 줄이고, 다른 기업은 새로운 도메인에서 개발 인력을 확장
• AI가 일상 코딩을 자동화할수록, 인간이 직접 다루는 코드 품질 기준은 오히려 상승
• 오전에는 AI 결과물 검토, 오후에는 고수준 아키텍처 설계 같은 업무 흐름도 가능
• 변화만이 유일하게 변하지 않는 요소
• 트렌드 + 회의적 시각을 함께 유지할수록 과도한 기대/비관에 휘말릴 가능성 감소
• 기술을 지속 업데이트하고 역량을 확장하며, 창의성·비판적 사고·협업 같은 인간 강점에 집중할수록 흐름에서 이탈하지 않음
• 코딩 르네상스든 자동 코드 시대든, 전체를 보고 학습하며 문제 해결에 기술을 적용하는 엔지니어 수요는 항상 존재
• 미래를 예측하는 가장 좋은 방법은 그것을 적극적으로 엔지니어링하는 것

[Hacker News 의견들]

1. “지금은 모든 게 도박 같다”는 불안

• 기술/학력/인맥/직장 중 어느 것도 안정된 기반을 보장하지 못한다는 느낌
• 빚/집/가족이 있는 사람은 앞으로의 편안함을 걸고 도박, 학자금 대출과 불안정 기반의 신입은 인생 자체를 거는 셈
• 젊을 땐 안전했지만 가족이 생기면 이사/절약 모드 전환이 어려워 더 불안
• 희망을 품기 어렵고 모두가 대체될지 모른다는 불안감
• 미국 경제가 엉망이라 살기 힘든 시기라는 말
• 지난 3년간 배경 불안감, 사회적 기술이 부족해도 가질 수 있던 안정적 직업을 잃을까 두려움
• 4년 반 후 재정 독립이 가능할 텐데 그때 기분이 궁금
• 25살 신입은 다시 시작해도 되지만 42살+가족이면 큰 스트레스
• 지금이라도 FI(재정적 독립) 준비: 가장 좋은 시기는 커리어 초반, 두 번째는 지금

2. “LLM은 자동화보다 속도 도구”라는 실사용

• LLM은 코딩을 자동화한다기보다 속도를 높여주는 도구
• 원하는 해결책을 머릿속에 그리고 블록 단위로 설명하며 코드를 쌓아감
• 라이브러리 함수/문법 검색이 줄어든 게 가장 큼
• 나쁜 코드도 자동화하고 좋은 코드도 빠르게 만들 수 있음(나쁜 코드도 수익성이 있을 때가 문제)
• 프로토타입/PoC엔 괜찮지만 유지보수 코드에는 부적합하다는 시각
· “벤치 vs 댐” 비유: 누구나 벤치는 만들 수 있지만 댐은 다름
• HN에서 “vibecoding” 같은 과장만 돌아 실질 논의가 어렵다는 불만
• 현실과 과대광고의 괴리: 자율성은 늘지만 속도는 점진적
• 비개발자가 자기 일을 자동화할 수 있게 되는 게 진짜 변화라는 관점
• 주니어에게 최고 조언이 “AI 쓰지 마라”라는 주장(코드 줄 늘리기는 성취가 아니라 기술 부채)
• minfx.ai 사용 경험: 제약을 많이 둘수록 품질이 좋아짐, Rust가 특히 도움, 시스템이 커질수록 개발이 쉬워지는 역설

3. “주니어가 사라지는 게 아니라 정의가 바뀐다”

• AI가 주니어 업무를 자동화한다면 ‘주니어의 정의’가 바뀌는 것
• 인턴 채용이 지표: 2024년 14명 → 2025년 4명(예산 60~70% 삭감)
• 주니어 포지션은 AI 이전부터 줄고 있었고, 예전엔 팀 절반이 신입이었는데 지금은 올-시니어 팀이 됨

4. “모든 산업에서 개발자 수요 폭발?”에 대한 엇갈림
(공감)

• 수요 폭발 시나리오에 공감하지만 역할이 꼭 ‘개발자’일 필요는 없음
• 각 산업의 기존 직무가 AI를 잘 다루는 방향으로 진화
• 핵심은 도메인 지식 + AI 활용 능력
• CTO들이 SaaS를 대체할 수 있음을 깨닫는 순간 내부 솔루션 개발 붐이 올 것
(회의)
• 이미 소프트웨어는 모든 산업에 깊게 들어와 있고 남은 건 완전 자동화뿐
• 병목은 기술이 아니라 정치/현실 문제
• AI는 효율 향상이지 새 일자리 창출은 아니라는 의견(자동차 혁명처럼 새 직업군을 만들진 않음)
• 유럽(특히 독일)은 수요가 늘 수 있다는 지역 관점
• LLM 이전부터 소프트웨어 중심 사고가 과도하다는 우려가 있었다는 지적

5. “검증 속도”가 핵심 + 리뷰 UX의 함정

• AI 시대 핵심은 검증 속도
• 직접 코드를 쓰면 이해도가 높아지고, 이해가 있어야 검증 가능
• 속도 vs 정확성 트레이드오프를 받아들여야 함
• 리뷰 과정에서 유혹이 많음: 코드가 쏟아지고 속도/FOMO 때문에 검토 품질이 떨어질 위험
• 도구 UX 자체가 방심을 유도할 수 있음

6. “원글이 핵심 질문을 놓친 듯”이라는 비판(전문가/대학)

• “전문가는 자동화될 위험”이라는 말은 반대라는 주장
• 전문가는 도구를 감독하고, 비전문가는 도구의 지시를 따름
• 대학도 마찬가지로 이론을 아는 사람이 기계를 통제한다는 논리

7. 현실 농담 + 커리어 피로감

• “그냥 모든 걸 포기하고 싶다”는 농담
• COBOL: 14년 전에도 은행 COBOL, 지금도 그대로(시장은 당신이 파산하기 전까지 비이성적일 수 있음)
• 시니어가 돼도 공부/사이드 프로젝트를 요구받는 피로
• JS 프레임워크 변화(Angular→React 등)로 커리어가 도박 같았다는 체감
• “좋은 개발자”로 만족하면 괜찮지만 탁월함을 원하면 추가 노력이 필요(둘 다 정당)
• “언제 취미를 하냐”는 사회적 문제: 회사는 수익이 목적이니 개인 삶은 스스로 지켜야
• 시니어라면 “It depends”를 배워야 함: 안정적인 회사 vs 트렌드 추적은 목표/가치관 문제
• 컴퓨터를 좋아하지 않으면 잘못된 선택일 수도, 돈이 목적이면 달성했으면 OK. 다만 최고가 되려면 일을 사랑해야 한다는 말

---