▲

AI가 코딩을 쉽게 만들었다. 그러나 엔지니어링은 더 어려워졌다

 (ivanturkovic.com)
2P by GN⁺ 16시간전 | ★ favorite | 댓글 1개
  • AI 도구의 확산으로 코드 작성은 쉬워졌지만, 소프트웨어 엔지니어의 업무 강도와 복잡성은 오히려 증가함
  • AI가 생산성을 높이자 조직의 기대치와 업무량 기준선이 상승, 엔지니어들은 더 많은 일을 더 빠르게 수행해야 하는 압박을 받음
  • 코드 작성 중심의 정체성이 약화되며, 엔지니어들은 리뷰·설계·제품 사고 등 비개발 업무까지 떠맡는 상황에 직면
  • AI가 생성한 코드를 검토·디버깅하는 데 더 많은 시간이 소요되어, 품질 관리 부담과 인지 부하가 증가함
  • 지속 가능한 엔지니어링 문화를 위해서는 리더십의 공감, 역할 경계 설정, 주니어 양성, 새로운 평가 지표가 필수임

기준선의 이동과 보이지 않는 부담

  • AI 도입 이후 엔지니어의 기대 산출량이 급격히 증가, 명시적 지시 없이도 더 많은 업무가 요구됨
    • Harvard Business Review 연구에 따르면, AI를 활용한 직원들은 일찍 퇴근하지 않고 더 많은 업무를 수행함
    • 83%가 AI로 인해 업무량이 늘었다고 답했고, 번아웃 비율은 실무자 60% 이상, 경영진은 38%로 격차가 큼
  • 리더십이 “AI가 일을 쉽게 만든다”고 인식하는 반면, 현장 엔지니어는 복잡성과 피로감을 체감
  • 600명 이상을 대상으로 한 별도 조사에서도 2/3가 번아웃을 경험, 43%는 리더십이 현실을 모른다고 응답

엔지니어 정체성의 위기

  • 많은 엔지니어가 코드를 직접 작성하는 창의적 행위에서 직업적 만족을 얻어왔음
  • 그러나 AI 도입 이후 “코드를 직접 쓰지 말고 관리하라”는 암묵적 메시지가 확산
    • AI가 구현을 대신하고, 엔지니어는 감독자·리뷰어 역할로 전환됨
  • 이는 단순한 변화가 아니라 직업 정체성의 근본적 전환으로, 숙련된 기술자의 자부심이 약화됨
  • “빌더에서 심사관으로 바뀌었다”는 표현처럼, 생산량은 늘었지만 장인정신과 몰입감은 감소

역할 확장과 스코프 크리프

  • AI로 구현 속도가 빨라지자, 병목이 요구사항·아키텍처·테스트·배포 등 주변 업무로 이동
  • 조직은 이를 엔지니어에게 재배분하며, 제품 기획·리스크 평가·운영 관리까지 담당하게 됨
    • Harvard Business Review 연구에서도 역할 경계가 흐려지고, PM·리서처·엔지니어 간 업무가 교차됨
  • 45%의 엔지니어링 직무가 다분야 역량을 요구하지만, 보상이나 권한 증가는 동반되지 않음
  • 결과적으로 업무 범위는 확대되고 깊이는 얕아지며, 번아웃이 가속화됨

감독의 역설: AI 코드 리뷰의 난이도

  • AI가 생성한 코드를 검토하는 일이 직접 작성보다 어렵다는 역설이 발생
    • 작성자는 맥락을 알고 있지만, AI 코드는 의사결정 근거가 불명확해 검토 부담이 큼
  • Harness 조사에서 67%가 디버깅 시간 증가, 68%가 리뷰 시간이 늘었다고 응답
  • 관리층은 속도 향상을 기대하지만, 실제로는 품질 보증과 맥락 이해의 부담이 커짐
  • 생산 병목은 작성 단계에서 이해 단계로 이동, 이는 자동화로 해결되지 않음

가속의 함정과 지속 가능성

  • AI가 속도를 높이자 업무량이 자연스럽게 늘어나는 자기강화 루프가 형성
    • Harvard 연구는 이를 “workload creep”이라 명명, 인지하지 못한 채 과로가 누적됨
  • 과거엔 인간의 사고·타이핑 속도가 자연스러운 한계였으나, AI가 그 제한을 제거
  • 결과적으로 생산성 지표는 상승하지만 품질은 하락, 기술 부채와 피로가 누적
  • 외형상 생산성 향상처럼 보이지만, 내부적으로는 소진과 품질 저하가 진행

주니어 엔지니어의 학습 단절

  • AI가 단순 업무를 대체하면서 초급 엔지니어의 실습 기회가 급감
    • 2023~2024년 대형 기술기업의 초급 채용 25% 감소, HackerRank 보고서도 경력직 중심 채용을 확인
  • 학습용 단순 과제가 사라지면, 미래의 시니어 인력 양성 경로가 붕괴
  • “직접 만들어본 적 없는 시스템을 감독할 수 없다”는 경고처럼, 기초 역량 단절이 장기적 위험으로 지적됨

리더십이 해야 할 일

  • 변화의 어려움을 공감하고 명시적으로 인정하는 것이 신뢰 유지의 출발점
  • 실질적 재교육 제공: 시스템 설계, 보안, 제품 사고, AI 코드 평가 등 고급 역량 강화
  • 역할 범위 명확화 및 보상 조정, 무한 확장을 방지해야 함
  • 성과 지표 재정의: 속도·라인 수보다 품질·안정성·팀 건강을 중시
  • 주니어 채용 유지는 장기적 인재 생태계 유지를 위한 필수 조건

엔지니어 개인이 취할 전략

  • 기초 기술 역량 유지: 아키텍처, 디버깅, 성능·보안 이해는 오히려 중요성 증가
  • 가속 함정에 경계: AI가 가능하게 한 최대 속도를 무조건 추구하지 말고 지속 가능한 리듬 유지
  • 확장된 역할 중 흥미 있는 영역 수용, 커리어 성장 기회로 활용
  • 번아웃과 고립감 공유, 동료와의 대화로 현실 인식 확산
  • 기술 변화는 반복되어 왔으며, AI도 근본 기술자의 수요를 대체하지 못함

우리가 직면한 역설

  • AI가 코딩을 쉽게 만들었지만 엔지니어링을 어렵게 만든 현실은 동시에 존재
  • 기대치 상승, 역할 확장, 지원 부족이 결합해 지속 불가능한 문화를 초래
  • 이 역설을 인정하지 않으면 신뢰와 인재 유지가 불가능
  • 도구가 아닌 사람이 제품을 만든다는 원칙을 잊지 말아야 하며,
    AI 시대의 진정한 경쟁력은 인간의 한계를 이해하고 보호하는 조직에서 나온다는 결론
▲
GN⁺ 16시간전  [-]
Hacker News 의견들

  • 이 에세이는 부분적으로 AI 생성이거나 LLM으로 강하게 편집된 흔적이 보임
    “It’s not X, it’s Y” 같은 문장 구조가 반복되고, 2015~2025년 사이 거의 활동이 없던 블로그가 갑자기 폭발적으로 글을 올리기 시작한 것도 의심스러움

    • 이제 LLM 관련 글은 거의 전부 LLM이 직접 쓰거나 도움을 받은 것 같음
      이런 글쓰기 방식이 많은 사람을 질리게 하지만, 업계에서 성공을 노리는 사람들에겐 중요하지 않은 듯함
    • 나도 LLM의 도움으로 개인적인 글을 써본 입장에서, 이 글은 몇 개의 불릿 포인트에서 생성된 것처럼 보임
      반복적인 리듬과 문체가 전형적인 LLM 산출물 같음. 인간적인 감정이 부족하고 내용이 비어 있음
    • 댓글들도 마찬가지로 AI 흔적이 보임. 구체적인 단서는 말하지 않겠지만, HN이 점점 읽기 힘든 곳이 되어감
      아직 AI가 덜 침투한 소규모 고품질 커뮤니티를 소중히 해야 할 시점임
    • 제목부터 이미 LinkedIn식 자극적인 문구 냄새가 남
    • 나도 몇 문단 읽고 흥미로워 동료에게 공유하려 했지만, 곧 AI가 쓴 게 너무 명확해져서 진지하게 받아들일 수 없었음

  • “The job changed. The expectations changed. And nobody sent a memo.” 같은 문장은 정말 AI가 쓴 듯한 느낌임

    • 글이 너무 장황하고 요점을 몇 개의 불릿으로 요약할 수 있을 정도였음. 중간에 지루해서 읽다 말았음
    • 왜 AI는 이렇게 글을 못 쓰는지 모르겠음. 문체가 마치 선정적인 뉴스 기사 같음
    • Pangram에 따르면 이 글은 100% AI 생성임
    • 전체적으로 AI 특유의 문체가 확실히 느껴짐

  • 실제로 본 문제 중 하나는 AI 배포 실수임. ‘Vibe Coders’ 같은 사람들에게는 IT/Dev 멘토가 필요함
    예를 들어, 한 외과의사가 Claude로 수술 기록용 웹앱을 만들었는데, 보안이 걱정돼 나에게 검토를 부탁했음
    코드와 DB는 괜찮았지만, 그는 프로젝트 전체를 zip으로 묶어 웹 루트에 올려두고 index 파일이 없었음
    그래서 누구나 백업 파일을 다운로드할 수 있었고, 그 안에는 DB, API 키, AWS 키 등 모든 비밀이 들어 있었음
    그는 index 파일의 존재 이유조차 몰랐고, 결국 Claude에게 보안 방법을 물어보겠다고 했음

    • 이런 취약점은 곧 국가 단위 공격자가 자동으로 악용할 수 있을 정도로 발전할 것 같음
      몇 달 뒤면 스크립트 키디들도 대규모로 사용할 것이고, 누군가가 그걸로 스와팅을 시도해 인명 피해가 날 수도 있음
      그때 책임 논의는 어떻게 될지 궁금함
    • Claude는 코딩은 정말 잘하지만, ‘모르는 것을 모르는 사람’ 에게는 손을 잡아주지 않음

  • “대부분의 엔지니어는 코드를 쓰는 걸 좋아한다”는 말에 나는 해당되지 않음
    나는 코드를 쓰기보다는 무언가를 설계하고 만드는 일에 더 흥미가 있음
    AI에 찬성하느냐 반대하느냐는 결국 “코딩을 좋아하느냐, 세상을 위한 제품을 만드는 걸 좋아하느냐”의 차이 같음

    • 나는 품질 높은 소프트웨어를 만들고 싶어서 이 일을 함
      하지만 AI는 그 수준에 도달하지 못함. 컴파일조차 안 되는 코드가 많고, 제대로 작동하지 않으면 최적화는 의미가 없음

  • 많은 댓글이 이 글이 AI가 쓴 것 같다고 비판하지만, 나는 30년 넘게 프로그래밍하고 20년간 팀을 이끌어온 입장에서 깊은 통찰이 느껴졌음
    글쓴이가 누구든, 내용은 가치 있다고 생각함. 플래그된 게 의외였음

    • 나는 AI 생성 글 자체엔 반대하지 않음. 다만 작성 과정의 투명성이 중요함
      예를 들어 “내가 핀테크 팀을 운영하며 느낀 점” 같은 문장이 실제 경험이 아니라면 의미가 사라짐
      반면 실제 경험을 AI로 다듬은 거라면 전혀 문제없음
    • 글을 생성한 프롬프트를 공개했으면 좋겠음. 마치 실행 파일보다 소스 코드를 보고 싶듯이
    • 결국 플래그가 해제되었지만, 이런 ‘AI 슬롭’이 남고 비판적인 글이 정치적이라며 막히는 건 HN의 우선순위 문제 같음
      “AI는 피할 수 없다” 같은 진부한 문구엔 더 이상 지혜가 없음

  • AI 시대에는 엔지니어링 사고방식이 달라짐
    기존에는 문제를 깊게 파고드는 수직적 사고였다면, 이제는 수평적·메타적 사고가 필요함
    예를 들어 Claude 환경을 최적화하려고 문서를 읽다가, 그냥 Claude에게 프로젝트 맥락을 주고 최적화를 요청했더니
    필요한 플러그인과 에이전트를 자동으로 제안하고 생성해줬음
    결국 중요한 건 세부 구현이 아니라, 프로젝트의 구조를 정의하는 능력임

  • 글의 요지는 맞음. 자동화는 쉬운 일을 없애고 어려운 문제에 집중하게 만듦
    계산기를 예로 들면, 숫자 더하기에 능숙하던 회계사는 이제 더 높은 수준의 문제를 다뤄야 함

    • 핵심은 “쉬운 부분이 사라졌다”는 것임. 어려운 일은 여전히 어렵고, 그게 본질적인 일임
    • 나는 코딩보다 시스템 설계가 더 흥미로움. AI나 주니어 개발자에게 구현을 맡기고, 나는 설계에 집중할 수 있다면 이상적임
      하지만 초보자에게는 오히려 코딩이 사라지는 게 악몽일 수도 있음
    • 오히려 AI는 어려운 부분을 없애고 질 낮은 콘텐츠만 양산함
      문학으로 치면, AI는 새로운 Terry Pratchett를 빠르게 만드는 게 아니라, 그가 묻히게 만드는 존재임
      AI 블로그 글을 구분 못한다면, 나쁜 코드도 구분 못할 것임
    • Pangram에 따르면 이 글도 100% AI 생성임
    • 실제로는 일자리를 찾기 어려워져서 신입 개발자들이 진입조차 못 하는 현실이 더 큰 문제임

  • 나는 글이 LLM이 쓴 건지 잘 구분 못하지만, 요즘 글을 읽으면 피로감이 심함
    단어가 너무 많고, ADHD 성향인 사람에게는 특히 읽기 힘듦

  • 이 글은 Pangram 기록에 따르면 100% AI 작성임

    • 하지만 AI 글 감지 도구는 대부분 정확하지 않음
    • 그 사실이 오히려 아이러니함

  • LLM 사용이 생산성 향상으로 이어지지 않는다는 연구도 있음
    이런 글들은 그 효과를 당연한 전제로 두지만, 실제로는 경영진의 기대와 현장의 현실이 다름
    엔지니어의 관점에서 보면 그 격차가 명확함

답변달기