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

> Clean Markdown view of GeekNews topic #25769. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25769](https://news.hada.io/topic?id=25769)
- GeekNews Markdown: [https://news.hada.io/topic/25769.md](https://news.hada.io/topic/25769.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-13T02:33:51+09:00
- Updated: 2026-01-13T02:33:51+09:00
- Original source: [addyosmani.com](https://addyosmani.com/blog/next-two-years/)
- Points: 110
- Comments: 10

## Summary

**AI 에이전트 기반 개발**이 실험 단계를 넘어 실제 업무 흐름에 들어오기 시작했고, 일부 팀에서는 **숙련된 엔지니어 1명이 여러 AI 도구를 활용해 과거 팀 단위에 가까운 생산성을 내는 사례**가 등장했습니다. 각 개인과 팀이 어떻게 **조직 구조와 개발 프로세스 전반을 다시 설계**해야 할지 짚어주는 글입니다. 주니어와 시니어 모두 **필독**

## Topic Body

- **AI 에이전트 기반 개발**이 자동완성 수준을 넘어 실제 작업 수행 단계로 진입하며, 소프트웨어 엔지니어링의 역할과 진입 구조가 빠르게 흔들리고 있음  
- **주니어 채용 감소와 효율성 중심 조직**이 동시에 나타나며, 소수의 숙련 인력이 AI 도구로 더 많은 일을 처리하는 구조 확산  
- **코딩 자체보다 검증·설계·판단 능력**이 중요해지며, AI 출력물을 다룰 수 있는 인간 역량이 핵심 차별 요소로 부상  
- **T자형 인재(깊은 전문성 + 넓은 적응력)** 가 빠르게 변화하는 AI 환경에서 유리하며, 한 분야의 깊이와 다분야 적응력을 동시에 요구하는 흐름 가속  
- **전통적인 CS 학위 중심 경로 약화**와 함께 포트폴리오·부트캠프·기업 주도 교육 등 다층적 학습 생태계 확산  
---  
  
### 1. 주니어 개발자 문제  
  
- **AI가 엔트리 레벨 업무를 자동화**하면서 주니어 개발자 채용이 급감하는 흐름과, 소프트웨어가 전 산업으로 확산되며 수요가 다시 늘어나는 흐름이 동시에 존재  
- Harvard의 6,200만 명 근로자 대상 연구에서 기업이 생성형 AI 도입 시 주니어 개발자 고용이 약 **9-10% 감소**하는 반면 시니어 고용은 거의 영향 없음  
- 빅테크 기업들이 지난 3년간 **신입 채용을 50% 축소**  
- 한 엔지니어의 표현: "AI 코딩 에이전트 비용이 더 저렴한데 왜 주니어에게 9만 달러를 지불하겠는가?"  
- 2022년경 **금리 인상과 팬데믹 후 조정** 같은 거시 요인이 AI 도구 확산 이전에 먼저 영향을 미쳤으나, AI가 이 추세를 가속화함  
- AI 보조를 활용한 시니어 엔지니어 한 명이 과거에는 **소규모 팀이 필요했던 작업량을 처리** 가능  
- **낙관적 시나리오**: AI가 기술 분야뿐 아니라 헬스케어, 농업, 제조, 금융 등 모든 산업에서 개발자 수요를 폭발적으로 증가시킬 가능성  
  - 개발자를 대체하기보다 AI가 개발 작업을 코더를 고용한 적 없는 도메인으로 확산시키는 **힘의 증폭기(force multiplier)** 역할  
  - "AI 네이티브" 개발자들이 특정 니치를 위한 자동화와 통합을 빠르게 구축하는 다른 형태의 엔트리 레벨 역할 증가 가능성  
- **미국 노동통계국**은 여전히 2024-2034년 소프트웨어 직종에서 약 15% 성장 전망  
- 비관적 시나리오의 장기 리스크: 오늘의 주니어가 내일의 시니어 엔지니어이자 기술 리더이므로, 인재 파이프라인을 완전히 차단하면 5-10년 후 **리더십 공백** 발생  
  - 업계 베테랑들은 이를 "느린 쇠퇴(slow decay)"라고 표현: 후계자 양성을 중단하는 생태계  
- ## 주니어 개발자를 위한 조언  
  - **AI 능숙도와 다재다능함**을 갖춰야 함  
  - 주니어 한 명 + AI가 소규모 팀 수준의 출력을 낼 수 있음을 입증해야 함  
  - Cursor, Antigravity, Claude Code, Gemini CLI 같은 **AI 코딩 에이전트**로 더 큰 기능을 구축하되, 대부분의 코드를 이해하고 설명할 수 있어야 함  
  - AI가 쉽게 대체할 수 없는 기술에 집중: **커뮤니케이션, 문제 분해, 도메인 지식**  
  - QA, DevRel, 데이터 분석 같은 **인접 역할**을 진입점으로 고려  
  - AI API를 통합한 프로젝트를 포함한 포트폴리오 구축  
  - 수습직, 인턴십, 계약직, 오픈소스 기여 등 다양한 형태의 경험 확보  
  - "훈련이 필요한 또 다른 신입"이 아니라, 빠르게 학습하여 바로 기여 가능한 **즉시 활용 가능한 엔지니어**가 되어야 함  
- ## 시니어 개발자를 위한 조언  
  - 주니어 감소로 **더 많은 단순 작업과 반복업무**가 시니어에게 돌아옴  
  - 일상적 작업에 자동화 활용하되, 모든 것을 혼자 하지 말 것  
  - CI/CD, 린터, AI 기반 테스트를 구축해 기본적인 문제를 초기에 차단  
  - 오픈소스나 다른 부서 동료 코칭을 통해 **비공식적 멘토링** 역할 수행  
  - 경영진에게 **올-시니어 팀이 가지는 장기적 리스크**를 명확히 전달해야 함  
  - 주니어 수요가 다시 늘어날 경우를 대비해, 효과적인 온보딩과 AI 기반 업무 위임 구조 준비  
  - 개인 생산성이 아니라 **팀 전체의 출력과 영향력을 증폭**시키는 역할에 가치 집중  
  
### 2. 스킬 문제  
  
- 현재 **개발자의 84%가 AI 보조 도구를 정기적으로 사용**  
- 버그나 새 기능에 직면했을 때, 처음부터 코드를 작성하기보다 **프롬프트를 작성하고 AI가 생성한 코드 조각을 조합**하는 방식이 일반화  
- 엔트리 레벨 코더들이 "어려운 방식"을 건너뜀: 이진 검색 트리를 처음부터 구축하거나 메모리 누수를 직접 디버깅한 적이 없을 수 있음  
- 역량의 중심이 알고리듬 구현에서 **AI에게 올바른 질문을 하고 출력을 검증**하는 방법으로 이동  
- 일부 시니어 엔지니어들은 이 흐름이 **독립적으로 코딩하지 못하는 세대**, 즉 탈숙련화를 낳을 수 있다고 우려  
- AI가 생성한 코드에는 경험이 적은 개발자가 놓치기 쉬운 **미묘한 버그와 보안 취약점**이 포함될 가능성 존재  
- ## 대안 시나리오  
  - AI가 반복적이고 일상적인 **80%의 작업을 처리**하고, 인간은 가장 어려운 **20%의 문제**에 집중  
    - 아키텍처 설계, 복잡한 통합, 창의적 설계, 엣지 케이스 처리  
  - AI의 보편화가 깊은 지식을 쓸모없게 만들기보다 **인간 전문성을 더욱 중요**하게 만듦  
  - 모든 사람이 AI 코딩 에이전트에 접근할 수 있을 때, 뛰어난 개발자를 구별하는 것은 **AI가 틀리거나 최적이 아닐 때를 아는 것**  
  - 한 시니어 엔지니어의 말 처럼 "최고의 소프트웨어 엔지니어는 가장 빠른 코더가 아니라 **AI를 불신해야 할 때를 아는 사람**"  
- ## 프로그래밍의 변화  
  - 보일러플레이트 작성은 줄어들고, AI 출력물의 **논리 오류·보안 결함·요구사항 불일치**를 검토하는 비중 증가  
  - 핵심 역량: **소프트웨어 아키텍처, 시스템 설계, 성능 튜닝, 보안 분석**  
  - AI는 웹 애플리케이션을 빠르게 만들 수 있지만, 전문 엔지니어는 **보안 모범 사례 준수 여부와 레이스 컨디션 발생 가능성**을 점검  
  - 2025년 개발자 커뮤니티에서는 논쟁이 두개로 나눠짐  
    - 손으로 코드를 거의 작성하지 않으며 코딩 인터뷰도 바뀌어야 한다는 입장  
    - 기초를 건너뛰면 AI 결과가 깨질 때 더 많은 문제 대응에 시달리게 된다는 입장  
  - 업계 전반에서 **AI의 속도와 이를 통제할 기초적 지혜**를 동시에 갖춘 엔지니어를 기대하는 흐름 형성  
- ## 주니어 개발자를 위한 조언  
  - AI를 의존 수단이 아닌 **학습 도구**로 활용  
  - AI가 제안한 코드가 왜 동작하는지 분석하고, 잠재적 약점 식별  
  - 주기적으로 AI 도움을 끄고 핵심 알고리듬을 처음부터 구현  
  - **CS 기초 역량**에 집중: 자료구조, 알고리듬, 시간·공간 복잡도, 메모리 관리  
  - 프로젝트를 두 번 구현(AI와 함께, AI 없이)하고 비교  
  - 프롬프트 설계와 도구 사용 능력을 체계적으로 습득  
  - 엄격한 테스트 습관 형성: 단위 테스트 작성, AI에 즉시 묻지 않고 스택 트레이스 읽기, 디버거 활용에 익숙해지기  
  - AI가 복제할 수 없는 보완 역량 강화: **시스템 설계 감각, 사용자 경험에 대한 직관, 동시성 문제에 대한 사고력**  
- ## 시니어 개발자를 위한 조언  
  - **품질과 복잡성을 책임지는 역할**로 자리매김  
  - 핵심 전문성 강화: 아키텍처, 보안, 스케일링, 도메인 지식  
  - AI 컴포넌트를 포함한 시스템을 모델링하고 **실패 시나리오**를 지속적으로 점검  
  - AI 생성 코드에서 자주 발생하는 취약점과 문제 유형에 대한 최신 인식 유지  
  - 멘토 및 리뷰어 역할 수용: AI 사용 허용 범위와 수동 리뷰 필수 영역(결제나 안전 코드) 정의  
  - 반복적인 API 연결 작업은 주니어+AI 조합에 맡기고, **어떤 API를 설계할지 결정하는 창의적·전략적 역할**에 집중  
  - 커뮤니케이션 능력과 교차 도메인 이해 등 소프트 스킬에 지속 투자  
  - 인간 개발자를 대체 불가능하게 만드는 요소에 집중: **건전한 판단력, 시스템 수준의 사고, 멘토십**  
  
### 3. 역할 문제  
  
- 개발자 역할이 **AI 생성 코드를 감독하는 제한적 감사자**로 축소되거나, **AI 주도 시스템을 설계·조율하는 핵심 오케스트레이터**로 확장될 가능성이 공존함  
- 극단적 시나리오 1:   
  - 개발자가 창의적 책임이 축소되어 소프트웨어 구축보다 **AI 출력물 감사 및 감독**에 주력  
  - AI 시스템(또는 노코드 플랫폼을 사용하는 "시민 개발자")이 프로덕션 담당; 인간 개발자는 자동 생성 코드 검토, 오류·편향·보안 이슈 확인, 배포 승인  
  - 제작자가 점검자로 변모되어, 코드 창작의 기쁨이 **리스크 관리의 불안**으로 대체  
  - 일부 엔지니어들이 처음부터 코드를 작성하는 시간보다 AI 생성 풀 리퀘스트 평가와 자동화 파이프라인 관리에 더 많은 시간을 쓰고 있음  
  - 한 엔지니어의 말: "AI가 던져주는 것을 치우는 **코드 청소부**로 끝나고 싶지 않다"  
- ## 대안적 미래: 고수준 오케스트레이터  
  - 개발자가 기술적, 전략적, 윤리적 책임을 결합한 **고수준 오케스트레이터**로 진화  
  - AI "워커"로 인해 인간 개발자가 **아키텍트 또는 총괄 계약자** 역할 수행:   
    - 전체 시스템 구조 설계  
    - 어떤 작업을 어떤 AI나 소프트웨어 컴포넌트에 맡길지 결정  
    - 여러 구성 요소를 엮어 솔루션 조합  
  - 에이전틱 개발 환경에서는 엔지니어가 **AI 에이전트와 서비스 앙상블을 지휘하는 작곡가**에 가까운 역할 수행  
    - 모든 코드를 직접 쓰지 않지만, 아키텍처·인터페이스·에이전트 상호작용이라는 멜로디를 정의  
    - 소프트웨어 엔지니어, 시스템 아키텍트, 제품 전략가의 역할이 결합된 형태  
  - 낙관적 관점: AI가 단조로운 작업을 처리하면서 개발자 역할이 필연적으로 **고가치 활동**으로 이동. 일자리가 더 흥미로워질 수 있음  
  - 어느 방향으로 갈지는 조직이 AI를 통합하는 방식에 따라 다름  
    - AI를 노동 대체 수단으로 보는 회사: 개발 팀 축소, 남은 엔지니어에게 자동화 유지 요청  
    - AI를 팀 증폭 수단으로 보는 회사: 인원 유지하되 각 엔지니어가 더 큰 문제와 야심찬 프로젝트에 도전  
- ## 주니어 개발자를 위한 조언  
  - 단순한 코드 작성 범위를 넘어 역할 확장 모색  
  - 테스트 케이스 작성, CI 파이프라인 구성, 애플리케이션 모니터링 등 **감사자·관리자 성격의 역량** 확보  
  - 개인 프로젝트를 통해 직접 만드는 경험을 유지하며 창의적 동기 보존  
  - **시스템적 사고방식** 개발: 컴포넌트 통신 방식 이해, 잘 설계된 API의 특징 학습  
  - 엔지니어링 블로그와 시스템 설계 케이스 스터디 지속적으로 학습  
  - 코드 생성 외에도 오케스트레이션 프레임워크와 AI API 등 **자동화 도구 전반**에 대한 이해 확장  
  - 문서를 다른 사람에게 설명하듯 명확하게 작성하는 습관 들이기  
  - 시니어에게 “코드가 동작하는가”를 넘어 “중요한 요소를 빠뜨리지 않았는가”를 질문  
  - 단순 코더가 아니라 **검증자·설계자·커뮤니케이터**로 성장할 준비  
- ## 시니어 개발자를 위한 조언  
  - 리더십과 아키텍처 책임을 적극적으로 수용  
  - AI와 주니어가 따를 **표준과 프레임워크**를 정의  
  - 코드 품질 체크리스트와 윤리적 AI 사용 정책 정의  
  - AI가 생성한 소프트웨어와 관련된 **규정 준수·보안 이슈**에 대한 최신 인식 유지  
  - **시스템 설계 및 통합 전문성**에 집중; 서비스 간 데이터 흐름 매핑 및 실패 지점 사전 식별  
  - 오케스트레이션 플랫폼(Kubernetes, Airflow, 서버리스 프레임워크, 에이전트 오케스트레이션 도구)에 익숙해지기  
  - 기술 멘토 역할 강화: 더 많은 코드 리뷰, 설계 토론, 기술 가이드라인  
  - 다른 사람(또는 무언가)의 코드를 빠르게 평가하고 **고수준 피드백**을 주는 능력 연마  
  - **제품 및 비즈니스 감각** 개발: 기능이 왜 만들어지는지, 고객이 무엇을 중요하게 여기는지에 대해 이해하기   
  - 프로토타입, 해커톤, 신기술 탐구를 통해 창작 에너지 유지  
  - **코드를 쓰는 사람에서 시스템을 지휘하는 사람**으로의 전환  
  
### 4. 전문가 vs 제너럴리스트 문제  
- 좁은 영역에만 특화된 전문가는 자신의 니치가 **자동화되거나 빠르게 가치가 사라질 위험**이 있음  
- 빠르게 변화하는 AI 환경에서 **T자형 엔지니어**(넓은 적응력 + 하나 또는 두 개의 깊은 기술)가 유리  
- 모델, 도구, 프레임워크가 빠르게 부상하고 쇠퇴하는 상황에서 **단일 기술 스택에 커리어를 거는 것은 위험**  
- 레거시 프레임워크 전문가는 새로운 AI 도구가 최소한의 인간 개입으로 동일 작업을 처리하는 순간, 수요 급감할 가능성이 있음  
- "특정 스택·프레임워크·제품 영역"에만 좁게 특화된 개발자는 그 영역이 쇠퇴하거나 중복될 때 방향을 상실할 수 있음  
  - COBOL 개발자, Flash 개발자, 업계가 이동할 때 전환하지 않은 모바일 게임 엔진 전문가 들 처럼   
- 과거와의 차이는 **변화 속도**로, AI 자동화가 특정 프로그래밍 작업을 순식간에 사소한 일로 만들어 해당 작업 중심 역할을 약화시킬 수 있음  
- 한 가지만 아는 전문가(SQL 쿼리 미세 조정, Photoshop 디자인을 HTML로 슬라이싱)는 AI가 그 작업의 90%를 처리하는 상황에 직면 가능  
- 채용 시장은 최신 니치를 쫓음: 몇 년 전 클라우드 인프라 전문가를 원했으나 지금은 AI/ML 엔지니어 수요가 급증  
- 어제의 기술에 좁게 특화된 인력은 니치의 매력이 사라지며 **커리어 정체**를 체감  
- ## T자형 개발자: 대안적 결과  
  - "다재다능한 전문가" 또는 **T자형 개발자**: 한두 영역의 깊은 전문성(수직 획) + 다른 많은 영역에 대한 넓은 친숙함(수평 획)  
  - 이 엔지니어들이 다학제 팀에서 **"접착제"** 역할: 다른 유형의 전문가들과 소통하고 필요시 공백 채움  
  - 회사들이 너무 얕거나 너무 좁게 집중된 개발자가 아닌 **강력한 핵심 역량 + 스택 전반을 다룰 수 있는 인재** 선호  
  - T자형 엔지니어는 핸드오프 대기 없이 문제를 종단간으로 해결할 수 있어 **효율성** 향상  
    - 서로 다른 영역의 지식이 결합되며 **혁신 가능성** 확대  
  - AI 도구가 실제로 **제너럴리스트를 더 많이 증폭**함: 한 사람이 여러 컴포넌트를 더 쉽게 처리 가능    
    - 백엔드 엔지니어가 AI 도움으로 기본적인 UI 구현 가능  
    - 프론트엔드 개발자가 AI로 서버 보일러플레이트 생성 가능  
  - AI가 풍부한 환경에서는 한 사람이 더 넓은 범위를 다루는 것이 쉬워짐  
  - 반대로 깊은 전문성만 가진 인력은 니치가 부분적으로 자동화될 경우 확장 경로가 제한될 수 있음  
  - 현재 **엔지니어링 직무의 약 45%** 가 다중 도메인 숙련도 요구  
    - 프로그래밍 + 클라우드 인프라 지식  
    - 프론트엔드 + 기본적인 ML 이해  
- ## 주니어 개발자를 위한 조언  
  - 커리어 초기에 **넓은 기반**을 의식적으로 구축  
  - 특정 역할로 채용되더라도 해당 사일로 밖의 영역을 꾸준히 관찰  
  - 모바일 개발자는 백엔드 기초를, 프론트엔드 개발자는 간단한 서버 구현 경험 확보  
  - Docker, GitHub Actions 등 **배포와 운영 도구** 학습  
  - 개인적으로 흥미를 느끼는 한두 영역을 선택해 깊이 파고들어 **수직 전문성** 형성  
  - 하이브리드 브랜딩 구축  
    - 예: 클라우드 보안 중점의 풀스택 개발자  
    - 예: UX 전문성을 갖춘 프론트엔드 개발자  
  - AI 도구를 활용해 새로운 도메인을 빠르게 학습  
    - 백엔드 초보 단계에서 AI로 기본 API 코드를 생성하고 구조 이해  
  - **지속적인 재숙련**을 일상적인 습관으로 정착  
  - 해커톤이나 크로스펑셔널 프로젝트에 참여하여 강제로 제너럴리스트 역할로 확장할 것  
  - 매니저에게 프로젝트의 다른 영역에 참여하고 싶다고 말할 것  
  - 커리어 초반에는 **적응력 자체가 가장 강력한 경쟁력**  
- ## 시니어 개발자를 위한 조언  
  - 자신의 **스킬 그래프**를 명확히 파악  
    - 본인이 깊이를 가진 전문 영역  
    - 피상적으로만 접한 인접 도메인들  
  - 인접 영역 한두 개를 선택해 **대화 가능한 수준**까지 끌어올리기  
    - 데이터베이스 전문가라면 최신 프론트엔드 프레임워크에 익숙해지거나 ML 파이프라인 기초 학습  
  - AI 지원을 활용해 자신이 약한 영역에서 **작은 실험 프로젝트** 수행  
  - 기존 전문성을 새로운 맥락에 연결  
    - 웹 앱 성능 전문가라면 그 기술이 ML 추론 최적화에 어떻게 적용되는지 탐구  
  - 역할을 더 **크로스펑셔널**하게 설계하거나 그런 포지션을 적극 제안  
  - 여러 영역이 얽힌 프로젝트에서 **통합 챔피언(책임자)** 역할 자원  
  - 다른 사람을 멘토링하여 기술을 전파하면서 그들로부터 새로운 관점 및 무언가 습득  
  - 이력서에 **다재다능함과 확장성**이 드러나도록 업데이트  
  - 축적된 경험을 바탕으로 반복되는 패턴과 이전 가능한 지식 정리  
  - T자형 롤모델이 될 것: 전문 분야에 깊이(권위와 자신감 부여) 있으면서 수평적으로 적극 확장  
  
### 5. 교육 문제  
  
- 전산학(CS) 학위가 계속해서 황금 표준으로 남을지, 부트캠프·온라인 플랫폼·고용주 주도 훈련 같은 **더 빠른 학습 경로가 이를 대체할지 불확실**  
- 몇 달 단위로 변하는 산업 속도를 **대학이 따라잡기 어려운 구조**에 놓일 가능성도 있음  
- ## 시나리오 1: 대학은 여전히 중요하지만 관련성 유지에 어려움  
  - 학위는 기본 자격으로 남아 있으나, 느린 커리큘럼 개편 주기와 관료적 승인 절차로 변화 속도에 뒤처짐  
  - 학생과 고용주는 학계가 산업과 단절되어 **직무 기술로 전환되지 않는 이론이나 구식 실습**을 가르친다고 느낌  
  - 최근 졸업생들이 학위 과정에서 클라우드 컴퓨팅, 현대적 DevOps, AI 도구에 대해 배운 적 없다고 보고  
  - 대학이 높은 시간과 재정 투자를 요구하면서 낮은 관련성 교육을 제공하면 **비싼 게이트키퍼**로 보일 위험도 있음  
  - 많은 회사가 관성으로 학사 학위를 여전히 요구하므로, 부담이 학생에게 전가되어 부트캠프, 온라인 강좌, 독학 프로젝트로 격차 채움  
  - **학자금 대출 부채가 막대**하고, 회사들이 신입 졸업생 훈련에 수십억 달러 지출(직장에서 필요한 기술 부족 때문)  
  - 대학이 AI 윤리 수업이나 클라우드 컴퓨팅 선택과목을 추가할 수 있으나, 실제 도입 시점에는 업계 도구가 이미 바뀌어 있을 가능성이 있음  
- ## 시나리오 2: 전통 교육이 새로운 시스템으로 점점 대체  
  - 코딩 부트캠프, 온라인 인증, 독학 포트폴리오, 고용주 생성 훈련 아카데미  
  - Google, IBM 같은 주요 기업들이 특정 기술 직무에서 **학위 요건을 철폐함**  
  - 2024년 기준, 기업의 약 **45%가 일부 포지션에서 학사 학위 요건 폐지 계획**  
  - 부트캠프가 성숙 단계에 진입하며, CS 전공자와 함께 상위 기업에 채용되는 인력 배출  
  - 이 프로그램들이 더 짧고(12주 집중) **실용적 기술**에 집중: 현재 프레임워크, 클라우드 서비스, 팀워크  
  - 채용 기준이 학위보다 **실제 포트폴리오, 마이크로 자격증, 검증된 기술**로 이동  
  - 탄탄한 GitHub 포트폴리오나 공신력 있는 인증이 학위 요건을 우회하는 수단으로 작동  
  - **고용주 주도 교육** 확대: 회사들이 자체 훈련 파이프라인 생성 또는 부트캠프와 직접적인 파트너십 형성  
  - 일부 빅테크 기업은 비전통적 인재를 위한 내부 교육(대학) 프로그램 운영 시작  
  - AI 자체가 새로운 학습 방법 제공: **AI 튜터, 대화형 코딩 샌드박스, 대학 외부에서 제공되는 맞춤형 학습 환경**  
  - 모듈식 학습 생태계가 고비용의 4년제 학위보다 **접근성과 유연성**에서 우위  
  - 강력한 CS 대학이 없는 나라의 학습자가 실리콘밸리 사람과 같은 Coursera 강좌를 수강하고 같은 포트폴리오 구축 가능  
- ## 지망생/주니어 개발자를 위한 조언  
  - 전통적인 CS 과정에 있더라도 그것만으로 충분하다고 가정하지 않기  
  - 실제 프로젝트로 수업 보강: 웹 앱 구축, 오픈소스 기여  
  - 인턴십이나 산학 협력 프로그램 적극 활용  
  - 커리큘럼에서 빠진 최신 주제는 온라인 플랫폼으로 보완  
  - GCP, AWS, Azure 등 **업계 인증**을 획득해 실무 역량을 명확히 시그널링 하기   
  - 독학이나 부트캠프 중이라면 **설득력 있는 포트폴리오**에 집중: **잘 문서화된 최소 하나의 실질적 프로젝트**  
  - 개발자 커뮤니티에서 활동: 오픈소스 기여, 기술 포스트 작성  
  - LinkedIn, 밋업, 개발자 행사 등을 통한 네트워킹  
  - 경험 있는 개발자의 **추천과 신뢰** 확보  
  - 지속적인 학습을 전제로 사고하기 : 기술 역량의 유효 기간은 짧음  
  - AI를 개인 튜터로 적극 활용  
  - 구체적 방법으로 기술 증명: 포트폴리오, 인증, 작업에 대해 지적으로 말하는 능력이 문을 열어줌  
- ## 시니어 개발자 및 리더를 위한 조언  
  - 과거의 자격증이나 학위만으로 영원히 버틸 수 없음  
  - **지속적 교육에 투자**: 온라인 강좌, 워크숍, 컨퍼런스, 인증  
  - 새로운 방식으로 기술 검증; 실제 문제를 통해 현재 역량을 평가하는 인터뷰 준비  
  - 새로운 기술을 활용한 사이드 프로젝트 지속  
  - 직무 요건 재평가: 정말 CS 학위가 필요한지, 아니면 특정 기술과 학습 능력이 필요한지?  
  - **기술 중심 채용** 추진으로 인재 풀 확대  
  - 내부 훈련 프로그램이나 도제 스타일 역할 지원  
  - 정규 배경이 없는 주니어 개발자를 위한 멘토십 서클 지원  
  - 학계 및 대안 교육과의 교류 : 자문위원회, 초청 강연, 커리큘럼 격차에 대한 피드백  
  - 자신의 커리어 성장에 반영: **실제 성과와 지속적 학습**이 추가 학위보다 중요  
  
### 관통하는 핵심  
  
- 제시된 시나리오들은 서로 배타적이지 않으며, **현실은 각 시나리오의 요소가 뒤섞인 형태로 전개**  
- 일부 기업은 주니어 채용을 줄이는 한편, 다른 기업은 새로운 도메인에서 개발 인력을 확장  
- AI가 일상적인 코딩을 자동화할수록, 인간이 직접 다루는 코드에 대한 **품질 기준은 오히려 상승**  
- 개발자는 오전에는 AI가 생성한 결과물을 검토하고, 오후에는 고수준 아키텍처를 설계하는 식의 업무 흐름도 가능  
- 전반을 관통하는 맥락은 **변화만이 유일하게 변하지 않는 요소**라는 인식  
  
* 기술 트렌드와 그에 대한 회의적 시각을 함께 유지할수록, 과도한 기대나 비관에 휘말릴 가능성 감소  
* 기술을 지속적으로 업데이트하고 역량을 확장하며, **창의성·비판적 사고·협업** 같은 인간 고유의 강점에 집중할수록 흐름에서 이탈하지 않음  
* 코딩의 르네상스가 오든, 코드가 스스로 작성되는 시대가 오든, **전체를 보고 지속적으로 학습하며 실제 문제 해결에 기술을 적용하는 엔지니어**에 대한 수요는 항상 존재  
* 미래를 예측하는 가장 좋은 방법은 **그것을 적극적으로 엔지니어링하는 것**

## Comments



### Comment 52647

- Author: kandk
- Created: 2026-03-09T10:36:37+09:00
- Points: 1

potran이 가고, c++이 나와도 java가 나와도 nextjs가 나와도 SWE는 CS를 알아야하는것 처럼, AI가 나와도 CS에 대한 기본지식은 필수라고 생각합니다. 결국 도구만 바뀔뿐 본질은 같음.. IT업계에 있는 이상 계속 공부해야하는것은 숙명..

### Comment 49189

- Author: xguru
- Created: 2026-01-14T10:31:14+09:00
- Points: 3

넘 좋네요. 주니어부터 시니어까지 다 읽어봐야할 글  
작년부터 내년까지가 소프트웨어 엔지니어링에서 가장 큰 전환기가 될 것 같아요.  
여기서 시대의 흐름을 놓치면 한참 뒤쳐져 버릴수도.

### Comment 49200

- Author: ragingwind
- Created: 2026-01-14T13:17:53+09:00
- Points: 1
- Parent comment: 49189
- Depth: 1

저도 가끔 같은 생각함. 끝이 없음.  
  
"가끔 소프트웨어 개발을 선택한 게 잘못된 결정이었나 싶음  
시니어가 되어도 여전히 공부와 사이드 프로젝트를 요구받음  
언제쯤 취미나 사회생활을 할 수 있을지 모르겠음"

### Comment 49193

- Author: illiil1lii
- Created: 2026-01-14T11:47:59+09:00
- Points: 1
- Parent comment: 49189
- Depth: 1

지금 AI를 직무에 충분히 녹이지 못 하고 있다면, FOMO를 가지는 것도 좋아보입니다.

### Comment 49725

- Author: joypinkgom
- Created: 2026-01-23T09:06:54+09:00
- Points: 1

진짜 통찰력이 있는 글이라 생각합니다.   
23년차 현업 시니어 개발자이고, 24년 하반기부터 LLM을 통한 개발과 바이브 코딩을 극한으로 몰아서 사용해보는 중입니다. AOS/iOS, 웹서비스 풀스택, 배치, 모델 파인튜닝까지 정말 다양하게 활용중이고 에이전트 5개 정도를 띄워서 작업합니다.   
시간가는줄 모르고 개발하다가 잠드는 경험을 2000년 초반 이후 다시하게 될 줄은 몰랐네요 ㅎㅎ.   
  
각설하고, 최근 제 생각은 이미 개발의 영역은 이제 누구나 할 수 있는 것이라는 판단입니다.   
코딩 에이전트들의 발전은 더 가속화 되고, 개발은 더욱 쉽고 편해질겁니다. 엑셀이나 워드 문서 작성하는 수준이 되겠죠.  
안드레 카파시 말대로 최고의 개발 언어는 "영어(언어)"이라는데 동감합니다.  
  
개인적으로는, AI 논문을 더 많이 읽고, 논리적으로 표현하기 위해 글을 더 많이 작성해보고 있습니다.(AI와 대화하는 것도 더 많이 하려고 노력중이구요)   
정말 흥미진진한 요즘이네요.

### Comment 49491

- Author: gomjellie
- Created: 2026-01-20T07:11:13+09:00
- Points: 1

번역글이 있어서 공유드립니다.  
  
https://rosetta.page/post/번역-the-next-two-years-of-software-engineering-27vKG

### Comment 49376

- Author: bungker
- Created: 2026-01-17T10:01:53+09:00
- Points: 1

통찰력 있는 글이네요 계속 읽고 또 읽고 있어요

### Comment 49271

- Author: fantajeon
- Created: 2026-01-15T18:51:48+09:00
- Points: 1

Archecture, QA Engineer가 살아남는 시대가 되리라. 이것이 맞는 지 안 맞는 지 판단하는....

### Comment 49103

- Author: neo
- Created: 2026-01-13T02:33:51+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46580703) 
- 솔직히 지금은 모든 게 **거대한 도박**처럼 느껴짐  
  기술, 학력, 인맥, 직장 중 어느 것도 인생의 안정된 기반을 보장하지 못함  
  빚을 갚고 집을 사고 가족을 꾸린 사람은 앞으로의 **편안함**을 걸고 도박하는 셈이고, 학자금 대출과 불안정한 사회적 기반을 가진 신입은 인생 자체를 걸고 있는 셈임
  - 젊었을 때는 훨씬 **안전하다고 느꼈음**  
    지금은 가족이 생겨서 쉽게 이사하거나 절약 모드로 살 수 없기 때문에 훨씬 불안함
  - 요즘은 희망을 품고 사는 게 어렵다는 생각임  
    프로그래머든 아니든, 모두가 곧 **대체될 거라는 불안감** 속에서 살고 있음  
    미국 경제도 엉망이라 지금은 살기 힘든 시기임
  - 지난 3년간 계속 **배경 불안감**이 있었음  
    재정적인 부분도 있지만, 사회적 기술이 부족해도 가질 수 있었던 안정된 직업을 잃을까 두려움  
    4년 반 후면 기본적인 재정 독립이 가능할 텐데, 그때의 기분이 어떨지 궁금함
  - 신입들은 괜찮을 것 같음  
    25살이면 다시 시작해도 되지만, 42살에 가족이 있으면 그건 정말 **스트레스**일 것 같음
  - 지금이라도 **재정적 독립(FI)** 을 준비해야 함  
    가장 좋은 시기는 커리어 초반이었고, 두 번째로 좋은 시기는 바로 지금임

- 내 경험상 LLM은 코딩을 **자동화**한다기보다 **속도를 높여주는 도구**임  
  원하는 해결책을 머릿속에 그리고, LLM에게 블록 단위로 설명하면서 코드를 쌓아감  
  라이브러리 함수나 문법을 검색할 필요가 줄어든다는 점이 가장 큼
  - LLM은 나쁜 코드를 자동화할 수도 있고, 좋은 코드를 빠르게 만들 수도 있음  
    문제는 나쁜 코드도 종종 충분히 **수익성**이 있다는 점임  
    프로토타입이나 개념 증명에는 괜찮지만, 유지보수 가능한 코드에는 적합하지 않음  
    벤치와 댐의 비유처럼, 누구나 벤치는 만들 수 있지만 댐은 그렇지 않음  
    LLM은 저품질 코드를 쉽게 만들게 하지만, 고품질 코드는 여전히 필요함
  - 나와 내가 아는 대부분의 사람들도 LLM을 이렇게 씀  
    그런데 HN에서는 “vibecoding” 같은 과장된 얘기만 하느라 **실질적인 논의**가 어려움
  - 현실과 **과대광고의 괴리**를 느끼고 있음  
    LLM이 점점 더 자율적으로 일할 수 있게 발전 중이긴 하지만, 그 속도는 점진적임  
    오히려 비개발자들이 처음으로 자신들의 일을 자동화할 수 있다는 점이 진짜 변화라고 봄  
    이는 산업 전반에 큰 영향을 줄 것이고, 결국 **컴퓨터의 본래 목적**에 가까워지는 일임
  - 주니어에게 줄 최고의 조언은 “**AI 쓰지 마라**”임  
    AI로 코드 줄 수 늘리는 건 성취가 아님, 오히려 **기술 부채**를 쌓는 일임
  - minfx.ai를 써보니, 코드에 **제약을 많이 둘수록** 품질이 좋아짐  
    Rust가 특히 도움이 됨  
    시스템이 커질수록 오히려 개발이 쉬워지는 **역설적인 경험**을 함

- AI가 주니어 업무를 자동화한다면, 그건 단지 **‘주니어의 정의’가 바뀌는 것**임  
  주니어가 사라지는 게 아니라, 역할이 달라지는 것임
  - 인턴 채용이 좋은 지표임  
    2024년에 14명이던 인턴이 2025년엔 4명으로 줄었음 — **예산 60~70% 삭감**
  - 사실 주니어 포지션은 AI 이전부터 줄고 있었음  
    예전엔 팀의 절반이 신입이었는데, 지금은 전부 시니어 팀이 됨

- 나는 AI가 각 산업에서 **개발자 수요를 폭발적으로 늘릴 것**이라는 시나리오에 공감함  
  다만 그 역할이 꼭 ‘개발자’일 필요는 없다고 생각함  
  각 산업의 기존 직무가 AI를 잘 다루는 방향으로 진화할 것임  
  결국 중요한 건 특정 도메인 지식을 배우면서 동시에 **AI 활용 능력**을 익히는 것임  
  - AI를 잘 다루는 개발자는 여전히 **전문 SWE 역할**을 수행해야 함  
    다만 CTO들이 SaaS를 대체할 수 있다는 걸 깨닫는 순간, **내부 솔루션 개발 붐**이 올 것임

- AI가 코드를 대신 짜주는 시대라면, 핵심은 **검증 속도**임  
  직접 코드를 쓰면 이해도가 높아지고, 이해가 있어야 검증이 가능함  
  결국 속도와 정확성 사이의 **트레이드오프**를 받아들여야 함
  - 리뷰 과정에서 **인간의 유혹**이 많음  
    코드가 한꺼번에 쏟아지고, 빠른 속도에 대한 FOMO 때문에 검토 품질이 떨어질 위험이 큼  
    도구의 UX 자체가 방심을 유도함

- AI가 모든 산업에서 개발자 수요를 늘릴 거라는 주장에는 회의적임  
  이미 소프트웨어는 모든 산업에 깊게 들어와 있고, 남은 건 **완전 자동화**뿐임  
  하지만 그 병목은 기술이 아니라 **정치적·현실적 문제**임
  - 나도 동의함. AI는 본질적으로 **효율 향상**을 위한 것이지, 새로운 일자리를 만드는 게 아님  
    자동차 혁명처럼 새로운 직업군을 창출하지는 않음
  - 유럽에서는 오히려 수요가 늘 수 있음  
    **소프트웨어 의존성 탈피**가 필요하고, 특히 독일은 이제 본격적으로 컴퓨터를 써야 함
  - 이미 LLM 이전부터도 **소프트웨어 중심 사고**가 과도하다는 우려가 있었음

- 원글 작성자는 AI 관련 **핵심 질문들에 대한 이해가 부족**해 보임  
  예를 들어, “전문가는 자동화될 위험이 있다”는 말은 반대임  
  전문가는 도구를 **감독**하고, 비전문가는 도구의 **지시를 따름**  
  대학도 마찬가지로, 이론을 아는 사람이 기계를 통제함

- 아, 그냥 **모든 걸 포기하고 싶다는 농담**을 던짐

- 웃긴 건, 글쓴이가 COBOL 얘기를 했는데 내 이웃도 여전히 **은행에서 COBOL**로 일함  
  14년 전에도 그랬고 지금도 그대로임
  - 시장은 당신이 **파산하기 전까지 비이성적**으로 남을 수 있음

- 가끔 소프트웨어 개발을 선택한 게 **잘못된 결정**이었나 싶음  
  시니어가 되어도 여전히 공부와 사이드 프로젝트를 요구받음  
  언제쯤 취미나 사회생활을 할 수 있을지 모르겠음
  - “기술 스택에 인생을 걸지 말라”는 말에 공감함  
    JS 프레임워크가 바뀔 때마다 커리어가 **도박** 같았음  
    Angular에 올인했다가 React로 바뀌는 걸 보며 늘 어디에 투자해야 할지 고민했음  
    결국 평생 **불안 속에서 베팅**하는 기분이었음
  - 만약 ‘좋은 개발자’로 만족한다면 괜찮음  
    하지만 **탁월함**을 원한다면 추가 노력이 필요함  
    둘 다 정당한 선택임
  - “언제 취미를 할 수 있나”라는 질문은 결국 **사회적 문제**임  
    회사는 수익을 내는 게 목적이므로, 개인의 삶은 스스로 지켜야 함
  - 시니어라면 “**It depends**”라는 말을 배워야 함  
    안정적인 회사에서 천천히 배우며 일할 수도 있고, 트렌드를 좇으며 빠르게 성장할 수도 있음  
    결국 본인의 **목표와 가치관**에 달린 문제임
  - 컴퓨터를 좋아하지 않는다면 잘못된 선택일 수도 있음  
    하지만 돈이 목적이라면 그걸 달성했다면 문제없음  
    다만 최고가 되고 싶다면, **일 자체를 사랑**해야 함

### Comment 49230

- Author: kangmumu
- Created: 2026-01-15T05:47:13+09:00
- Points: 1
- Parent comment: 49103
- Depth: 1

도움이 많이 되었습니다 👍👍