▲

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

 (addyosmani.com)
110P by GN⁺ 1달전 | ★ favorite | 댓글 9개
  • 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가 생성한 결과물을 검토하고, 오후에는 고수준 아키텍처를 설계하는 식의 업무 흐름도 가능
  • 전반을 관통하는 맥락은 변화만이 유일하게 변하지 않는 요소라는 인식
  • 기술 트렌드와 그에 대한 회의적 시각을 함께 유지할수록, 과도한 기대나 비관에 휘말릴 가능성 감소
  • 기술을 지속적으로 업데이트하고 역량을 확장하며, 창의성·비판적 사고·협업 같은 인간 고유의 강점에 집중할수록 흐름에서 이탈하지 않음
  • 코딩의 르네상스가 오든, 코드가 스스로 작성되는 시대가 오든, 전체를 보고 지속적으로 학습하며 실제 문제 해결에 기술을 적용하는 엔지니어에 대한 수요는 항상 존재
  • 미래를 예측하는 가장 좋은 방법은 그것을 적극적으로 엔지니어링하는 것
▲
xguru 1달전  [-]

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

답변달기
▲
ragingwind 1달전  [-]

저도 가끔 같은 생각함. 끝이 없음.

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

답변달기
▲
illiil1lii 1달전  [-]

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

답변달기
▲
joypinkgom 1달전  [-]

진짜 통찰력이 있는 글이라 생각합니다.
23년차 현업 시니어 개발자이고, 24년 하반기부터 LLM을 통한 개발과 바이브 코딩을 극한으로 몰아서 사용해보는 중입니다. AOS/iOS, 웹서비스 풀스택, 배치, 모델 파인튜닝까지 정말 다양하게 활용중이고 에이전트 5개 정도를 띄워서 작업합니다.
시간가는줄 모르고 개발하다가 잠드는 경험을 2000년 초반 이후 다시하게 될 줄은 몰랐네요 ㅎㅎ.

각설하고, 최근 제 생각은 이미 개발의 영역은 이제 누구나 할 수 있는 것이라는 판단입니다.
코딩 에이전트들의 발전은 더 가속화 되고, 개발은 더욱 쉽고 편해질겁니다. 엑셀이나 워드 문서 작성하는 수준이 되겠죠.
안드레 카파시 말대로 최고의 개발 언어는 "영어(언어)"이라는데 동감합니다.

개인적으로는, AI 논문을 더 많이 읽고, 논리적으로 표현하기 위해 글을 더 많이 작성해보고 있습니다.(AI와 대화하는 것도 더 많이 하려고 노력중이구요)
정말 흥미진진한 요즘이네요.

답변달기
▲
gomjellie 1달전  [-]

번역글이 있어서 공유드립니다.

https://rosetta.page/post/…

답변달기
▲
bungker 1달전  [-]

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

답변달기
▲
fantajeon 1달전  [-]

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

답변달기
▲
GN⁺ 1달전  [-]
Hacker News 의견들

  • 솔직히 지금은 모든 게 거대한 도박처럼 느껴짐
    기술, 학력, 인맥, 직장 중 어느 것도 인생의 안정된 기반을 보장하지 못함
    빚을 갚고 집을 사고 가족을 꾸린 사람은 앞으로의 편안함을 걸고 도박하는 셈이고, 학자금 대출과 불안정한 사회적 기반을 가진 신입은 인생 자체를 걸고 있는 셈임

    • 젊었을 때는 훨씬 안전하다고 느꼈음
      지금은 가족이 생겨서 쉽게 이사하거나 절약 모드로 살 수 없기 때문에 훨씬 불안함
    • 요즘은 희망을 품고 사는 게 어렵다는 생각임
      프로그래머든 아니든, 모두가 곧 대체될 거라는 불안감 속에서 살고 있음
      미국 경제도 엉망이라 지금은 살기 힘든 시기임
    • 지난 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”라는 말을 배워야 함
      안정적인 회사에서 천천히 배우며 일할 수도 있고, 트렌드를 좇으며 빠르게 성장할 수도 있음
      결국 본인의 목표와 가치관에 달린 문제임
    • 컴퓨터를 좋아하지 않는다면 잘못된 선택일 수도 있음
      하지만 돈이 목적이라면 그걸 달성했다면 문제없음
      다만 최고가 되고 싶다면, 일 자체를 사랑해야 함
답변달기
▲
kangmumu 1달전  [-]

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

답변달기