AI는 엔지니어를 대체하지 않는다: 우리 사이트가 보여주는 인간 주도 에이전트 엔지니어링의 현실

핵심 주장: 대체가 아니라 샌드위치 구조의 재배치다

GeekNews에 소개된 글은 소프트웨어 개발을 결정(decide) — 실행(execute) — 전달(deliver)의 샌드위치 구조로 설명한다. 이 관점은 실제 AI 기반 사이트 운영 경험과 잘 맞는다. AI는 가운데 실행층을 빠르게 압축한다. 코드 초안 작성, 컴포넌트 수정, 문서 초안, 테스트 명령 실행, 오류 로그 해석 같은 작업은 과거보다 훨씬 빨라졌다. 그러나 위아래의 층은 쉽게 사라지지 않는다.

무엇을 만들지 결정하는 일은 여전히 어렵다. 사용자가 실제로 원하는 것이 무엇인지, 사이트의 정체성과 맞는지, 어떤 기능을 먼저 공개해야 하는지, 한국어와 영어 콘텐츠를 어떻게 나눌지, 도구 페이지와 글 아카이브의 균형을 어떻게 맞출지 같은 문제는 단순히 코드를 많이 생성한다고 풀리지 않는다. 반대로 전달층도 남아 있다. 빌드가 통과했는지, 렌더링이 실제로 맞는지, 공개 문구가 책임질 수 있는지, 검색엔진과 사용자가 페이지를 제대로 이해할 수 있는지 확인해야 한다.

우리 사이트의 실제 경험: AI가 만들지만 사람이 운영한다

oh-my-zhs.com의 운영 방식은 일반적인 “AI 보조 코딩”보다 한 단계 더 나아가 있다. 단순히 개발자가 Copilot으로 자동완성을 받는 정도가 아니라, 에이전트가 실제로 파일을 만들고, 글을 쓰고, 컴포넌트를 수정하고, 빌드를 실행하고, 결과를 검증한다. 최근에는 글 메뉴에 플로팅 카테고리 퀵메뉴를 만들고, 모바일에서는 별도 퀵메뉴 UX로 바꾸며, 도구 페이지 하단에 설명 콘텐츠와 noscript fallback까지 보강했다. 이런 작업은 사람이 손으로 한 줄씩 작성했다면 더 느렸을 것이다.

하지만 이 작업들이 AI 혼자 “알아서” 나온 것은 아니다. 사람 엔지니어가 방향을 주도했다. “본문 레이아웃 안쪽이 아니라 바깥쪽에 떠야 한다”, “모바일은 가로바가 아니라 Next.js portal 느낌의 퀵메뉴가 맞다”, “AdSense 심사 관점에서는 도구 페이지에 충분한 텍스트 문맥이 필요하다”, “공개 글에는 특정 메타 코멘트를 넣지 말라” 같은 판단은 인간이 주었다. AI는 그 판단을 구현 가능한 코드와 콘텐츠로 바꾸는 실행자였다.

여기서 중요한 차이가 나온다. AI가 만든 사이트라고 해서 인간이 사라진 것이 아니다. 인간의 일이 코드 타이핑에서 제품 방향, 품질 기준, 리스크 판단, 시스템 운영으로 올라간 것이다. 이것이 “vibe coding”과 “agentic engineering”의 차이다. 바이브 코딩은 AI에게 대충 맡기고 결과가 그럴듯하면 받아들이는 방식에 가깝다. 에이전트 엔지니어링은 AI를 작업자로 쓰되, 사람은 제품 책임자이자 시스템 오케스트레이터로 남는 방식이다.

사례 1: 플로팅 글 메뉴는 AI가 구현했지만, UX 판단은 사람이 했다

글 아카이브에 카테고리 퀵메뉴를 넣는 작업은 겉보기에는 단순한 UI 작업처럼 보인다. 카테고리 목록을 만들고, 글 개수를 세고, 최근 글이 있는 카테고리에 new 뱃지를 붙이면 된다. AI 에이전트는 이런 작업을 빠르게 수행한다. 데이터 구조를 계산하고, React 상태를 연결하고, Tailwind 클래스를 붙이고, lint와 build를 돌릴 수 있다.

하지만 첫 결과는 사용자가 원한 것과 달랐다. AI는 본문 레이아웃 안쪽에 사이드바를 넣었다. 기능은 맞았지만 의도는 틀렸다. 사용자가 원한 것은 본문 그리드 안의 한 칼럼이 아니라, 전체 가로폭의 바깥쪽에서 스크롤을 따라다니는 플로팅 메뉴였다. 모바일 역시 가로 스크롤 바가 아니라 하단에 떠 있는 퀵메뉴 버튼과 팝오버가 더 맞았다.

이 차이는 코드 생성 능력의 문제가 아니다. 제품 감각과 맥락의 문제다. AI는 “사이드바”라는 단어를 보며 일반적인 레이아웃 패턴을 적용했다. 사람은 실제 페이지의 시각적 의도, 레퍼런스 이미지, 모바일 사용자의 손가락 위치, 향후 프로모션 슬롯 확장 가능성까지 포함해 다시 방향을 잡았다. 결국 좋은 결과는 AI의 실행력과 인간의 교정이 결합될 때 나왔다.

사례 2: 콘텐츠 보강은 AI가 썼지만, 무엇이 위험한 문구인지는 사람이 정했다

도구 페이지를 보강할 때도 비슷했다. AI는 각 도구의 입력, 출력, 예시, FAQ를 바탕으로 하단 설명 섹션을 자동으로 만들 수 있다. “언제 쓰면 좋은가”, “권장 사용 흐름”, “결과 확인 기준” 같은 구조를 전체 도구에 적용하면 사이트는 검색엔진과 사용자 모두에게 더 이해하기 쉬워진다. noscript fallback을 넣으면 JavaScript 렌더링이 늦어도 기본 설명이 HTML 안에 남는다.

하지만 이 작업에는 명확한 편집 기준이 필요하다. 어떤 문구는 공개 콘텐츠에 들어가면 안 된다. 예를 들어 사이트 심사나 수익화 준비 같은 내부 목적은 운영 메모에는 필요할 수 있지만, 사용자에게 보이는 도구 설명에 들어가면 사이트의 신뢰를 해친다. 사용자는 도구가 어떤 문제를 해결하는지 알고 싶어 하지, 우리가 어떤 심사를 준비하고 있는지 알고 싶은 것이 아니다.

AI는 때때로 내부 목적과 공개 문구를 섞는다. 그래서 인간 운영자는 “이 내용은 내부 기준이고, 공개 페이지에는 사용자 가치만 남겨야 한다”고 선을 그어야 한다. 이것은 글쓰기 능력보다 책임의 문제다. 공개 사이트는 단순한 산출물이 아니라 약속이다. AI는 문장을 만들 수 있지만, 그 약속의 범위를 정하는 사람은 운영자다.

비슷한 사례들: AI는 실행을 늘리지만, 전달 가능한 제품은 별개의 문제다

이 패턴은 우리 사이트만의 특수한 경험이 아니다. GitHub Copilot 연구들은 개발자가 더 빠르게 코드를 작성하고 반복 작업 부담을 줄일 수 있음을 보여준다. 하지만 코드 작성량이 늘어난다는 것과 제품이 더 빨리 출하된다는 것은 같은 말이 아니다. GeekNews에 소개된 원문도 AI가 작성한 코드 비율과 노동 대체를 직접 연결하는 사고가 위험하다고 지적한다. 코드는 소프트웨어의 재료이지, 제품 전체가 아니다.

METR의 오픈소스 개발자 연구도 흥미로운 반례를 제공한다. 특정 조건에서 경험 많은 개발자들이 AI 도구를 사용할 때 오히려 작업 시간이 늘어났다는 결과가 나왔다. 이 결과는 AI가 항상 느리다는 뜻이 아니라, 생산성 효과가 작업 종류, 코드베이스 친숙도, 검증 비용, 개발자의 기대와 실제 모델 능력 차이에 크게 좌우된다는 뜻으로 읽어야 한다. 익숙한 코드베이스에서 복잡한 변경을 할 때는 AI가 만든 초안을 검토하고 되돌리는 비용이 생각보다 클 수 있다.

Federal Reserve의 AI와 코더 고용 관련 자료 역시 단순한 대체 서사를 조심스럽게 보게 한다. AI가 고용 증가 속도나 직무 구성에 영향을 줄 수는 있지만, 곧바로 엔지니어 대량 대체로 이어진다는 증거는 훨씬 복잡하다. 기업이 “AI 때문에”라고 말하는 감원도 실제로는 비용 압박, 조직 슬림화, 투자자 요구, 제품 수요 변화와 얽혀 있는 경우가 많다. AI는 때때로 원인이 아니라 명분으로 쓰인다.

현장에서 더 자주 보이는 것은 대체보다 재구성이다. 주니어 개발자가 하던 반복 구현의 일부는 AI가 가져간다. 문서 초안, 테스트 케이스 초안, 간단한 UI 변형, 스크립트 작성 같은 작업은 빨라진다. 대신 사람에게는 더 높은 수준의 질문이 올라온다. 이 기능이 정말 필요한가, 이 변경은 사용자 흐름을 해치지 않는가, 이 자동화가 실패하면 누가 알 수 있는가, 이 글은 우리 브랜드의 목소리와 맞는가. 실행이 쉬워질수록 결정의 질이 더 중요해진다.

그래서 엔지니어는 왜 남는가: 암묵지, 책임, 시스템 이해

AI가 소프트웨어 엔지니어를 완전히 대체하기 어려운 이유는 엔지니어가 키보드를 잘 치기 때문이 아니다. 더 근본적인 이유는 엔지니어가 시스템의 암묵지를 품고 있기 때문이다. 코드베이스의 이상한 역사, 이전에 실패한 결정, 사용자들이 실제로 불편해한 지점, 배포 후 사고가 났던 경로, 조직이 감당할 수 있는 리스크 수준은 문서에 완전히 적혀 있지 않다.

oh-my-zhs.com에서도 마찬가지다. 어떤 도구 페이지가 사이트 정체성을 강화하는지, 어떤 글이 실제 사용자에게 도움이 되는지, 어떤 기능이 너무 이른지, 어떤 문구가 공개 사이트에서 불필요하게 방어적으로 보이는지는 repo만 읽는다고 자동으로 나오지 않는다. AI는 많은 힌트를 찾을 수 있지만, 최종 판단은 운영 맥락을 가진 사람이 한다.

책임도 핵심이다. AI가 만든 코드가 빌드를 깨거나, 잘못된 계산 결과를 보여주거나, 부적절한 공개 문구를 남기면 사용자에게 책임지는 것은 AI가 아니다. 사이트 운영자가 책임진다. 그래서 인간이 전달층에 남는다. “작동하는 것처럼 보임”과 “공개해도 됨” 사이에는 큰 간격이 있다. AI는 앞쪽을 빠르게 만들고, 사람은 뒤쪽을 검증한다.

우리가 실제로 쓰는 에이전트 엔지니어링 패턴

AI만으로 사이트를 운영한다고 할 때 가장 위험한 오해는 “사람이 아무것도 하지 않는다”는 생각이다. 실제로는 반대에 가깝다. 사람은 더 적은 손동작으로 더 많은 결정을 내려야 한다. 좋은 에이전트 운영은 다음과 같은 패턴을 따른다.

• 첫째, 작업을 작게 쪼갠다. “사이트를 좋게 만들어줘”가 아니라 “글 메뉴를 본문 바깥 플로팅 퀵메뉴로 바꾸고, 모바일은 하단 버튼 팝오버로 구현해줘”처럼 결과의 형태를 지정한다.
• 둘째, 검증 명령을 반드시 포함한다. lint, build, route 확인, 생성 HTML의 핵심 문구 확인처럼 완료 기준을 명령 수준으로 고정한다. 에이전트의 완료 보고만 믿지 않는다.
• 셋째, 공개 문구와 내부 목적을 분리한다. 내부적으로는 심사, 전환율, 운영 리스크를 고려하더라도 공개 페이지에는 사용자에게 필요한 설명만 남긴다.
• 넷째, Git 스코프를 좁힌다. 한 번의 커밋에는 한 가지 목적만 담는다. 글 작성, UI 수정, 인증 태그 추가, 콘텐츠 보강을 섞으면 나중에 되돌리기 어렵다.
• 다섯째, 사람이 마지막 제품 판단을 한다. AI가 “좋다”고 말해도 실제 화면, 문맥, 브랜드 톤, 사용자 동선을 보고 다시 판단한다.

생산 비용이 내려가면 수요는 줄기보다 늘어날 수 있다

AI 대체론에서 자주 빠지는 부분은 수요의 확장이다. 소프트웨어를 만드는 비용이 내려가면, 이전에는 만들지 못했던 작은 도구와 마이크로 서비스가 경제성을 갖는다. oh-my-zhs.com의 많은 도구도 이 관점에서 이해할 수 있다. 평수 변환기, KST 시간 변환기, 개발자 텍스트 도구, 이미지 편집 도구, PDF 도구, 웹훅 포맷터 같은 작은 유틸리티는 거대한 팀이 붙어서 만들 만한 제품은 아닐 수 있다. 하지만 AI 에이전트가 실행 비용을 낮추면 이런 작은 문제들도 사이트의 일부가 될 수 있다.

이것은 엔지니어 수요가 사라진다는 말과 반대 방향이다. 오히려 만들 수 있는 것의 범위가 넓어진다. 과거에는 “이 정도 기능은 ROI가 안 나온다”고 버렸던 일들이 이제는 시도 가능해진다. 물론 모든 사람이 안정적인 커리어를 보장받는다는 뜻은 아니다. 단순 실행만 하던 역할은 압박을 받을 수 있다. 하지만 제품 감각, 시스템 이해, 사용자 문제 정의, 검증 책임을 가진 엔지니어의 가치는 더 넓은 범위에서 필요해질 수 있다.

위험한 반대편: AI를 믿고 결정층까지 비우는 조직

AI가 엔지니어를 대체하지 않는다고 해서 안심만 할 일은 아니다. 가장 위험한 조직은 AI를 실행층의 도구로 쓰는 조직이 아니라, 결정층과 전달층까지 비우는 조직이다. 요구사항을 제대로 쓰지 않고, 사용자를 이해하지 않고, 테스트를 돌리지 않고, 배포 후 책임 구조도 없이 “AI가 만들었으니 빠르다”고 말하는 방식이다.

이런 방식은 초반에는 놀라운 속도로 보인다. 데모가 빨리 나오고, 화면이 그럴듯하고, 코드 줄 수가 늘어난다. 하지만 운영 단계에서 문제가 터진다. 사용자가 실제로 원하는 흐름과 다르거나, 예외 케이스에서 깨지거나, 문구가 책임질 수 없는 약속을 하거나, 여러 에이전트가 같은 파일을 서로 다른 방향으로 고친다. AI가 빠르게 만든 만큼, 잘못된 방향도 빠르게 쌓인다.

그래서 인간 주도 에이전트 엔지니어링은 “AI에게 맡긴다”가 아니라 “AI가 빠르게 움직일 수 있는 안전한 레일을 만든다”에 가깝다. 레일이 없으면 속도는 장점이 아니라 사고 규모를 키우는 힘이 된다.

AI 개발 생산성을 볼 때 코드 비율 대신 봐야 할 지표

AI가 작성한 코드 비율은 보기 쉬운 지표지만, 제품 관점에서는 부족하다. 어떤 조직은 신규 코드의 상당 부분이 AI로 생성되었다고 말한다. 그러나 그것만으로 엔지니어가 대체되었다고 볼 수는 없다. 중요한 것은 작성량이 아니라 전달량과 품질이다.

• 릴리스까지 걸린 시간: 코드 초안이 아니라 실제 사용자에게 도달한 기능 기준으로 본다.
• 리뷰와 수정 비용: AI가 만든 코드를 사람이 고치느라 쓴 시간을 포함한다.
• 회귀 버그 수: 기존 기능을 깨지 않고 변경했는지 확인한다.
• 요구사항 변경 대응력: 사용자가 방향을 바꿨을 때 코드와 콘텐츠가 얼마나 안전하게 수정되는지 본다.
• 운영 책임 가능성: 문제가 생겼을 때 원인을 추적하고 되돌릴 수 있는지 본다.

우리 사이트 운영에서도 체감상 가장 중요한 것은 “AI가 얼마나 많이 썼는가”가 아니다. 실제로 빌드가 통과했는지, 페이지가 생성됐는지, 글 순서가 맞는지, 사용자가 봤을 때 자연스러운지, 커밋이 되돌릴 수 있게 나뉘었는지가 더 중요하다.

미래의 엔지니어는 크레인 운전사에 가까워진다

원문은 미래의 소프트웨어 엔지니어를 크레인 운전사에 비유한다. 무거운 것을 직접 손으로 들지는 않지만, 어디로 옮길지, 얼마나 들어 올릴지, 어떤 순서로 움직일지, 주변 안전은 괜찮은지 판단한다. 이 비유는 에이전트 시대의 엔지니어에게 잘 맞는다.

AI 에이전트는 인지적 무거운 작업을 들어 올린다. boilerplate를 만들고, API를 연결하고, 스타일을 조정하고, 테스트 초안을 쓰고, 긴 글을 구조화한다. 하지만 크레인이 강력할수록 운전자의 책임은 작아지지 않는다. 오히려 잘못 움직였을 때 피해가 커진다. 에이전트도 마찬가지다. 빠르게 많은 코드를 만들 수 있기 때문에, 사람은 방향과 안전을 더 엄격하게 봐야 한다.

이 변화는 엔지니어에게 위협이면서 기회다. 단순히 손으로 구현하는 능력만으로는 방어력이 약해질 수 있다. 그러나 문제를 구조화하고, 제품 방향을 잡고, 에이전트를 검증하고, 시스템 전체의 책임을 지는 능력은 더 중요해진다. 즉, 엔지니어의 중심 역량이 손끝에서 운영 판단으로 이동한다.

FAQ

AI가 소프트웨어 엔지니어를 대체하지 않는다는 말은 너무 낙관적인가?

개별 역할과 커리어는 흔들릴 수 있다. 특히 반복 구현만 맡던 역할은 압박을 받을 가능성이 높다. 그러나 제품 결정, 시스템 이해, 검증, 책임까지 포함한 소프트웨어 엔지니어링 전체가 곧바로 대체된다는 서사는 현재의 실무 경험과 증거를 충분히 설명하지 못한다.

AI만으로 운영되는 사이트라면 인간 엔지니어는 무엇을 하나?

무엇을 만들지 정하고, 우선순위를 잡고, 공개 가능한 품질 기준을 세우고, AI가 만든 결과를 검증하며, 문제가 생겼을 때 책임지는 역할을 한다. 실행은 AI가 많이 맡지만 방향과 책임은 사람이 잡는다.

vibe coding과 agentic engineering의 차이는 무엇인가?

vibe coding은 AI에게 넓게 맡기고 그럴듯한 결과를 받아들이는 방식에 가깝다. agentic engineering은 작업 범위, 검증 기준, 커밋 스코프, 공개 책임을 사람이 설계하고 AI를 실행자로 쓰는 방식이다.

AI 개발 생산성을 무엇으로 측정해야 하나?

AI 작성 코드 비율보다 릴리스 속도, 리뷰 비용, 회귀 버그, 사용자 가치, 운영 책임 가능성을 봐야 한다. 코드가 많아지는 것과 제품이 좋아지는 것은 다르다.

결론: AI는 엔지니어를 지우는 것이 아니라, 엔지니어가 책임져야 할 층을 더 선명하게 만든다

AI가 소프트웨어 개발을 바꾸고 있다는 점은 의심할 필요가 없다. 실행층은 이미 압축되고 있고, 앞으로 더 압축될 것이다. 하지만 그 변화가 곧 엔지니어의 소멸을 뜻하지는 않는다. 오히려 엔지니어가 무엇으로 가치를 만드는지 더 선명하게 드러낸다. 코드를 많이 쓰는 사람이 아니라, 무엇을 만들지 알고, AI에게 일을 맡길 수 있게 구조화하고, 결과를 검증하고, 사용자와 제품에 책임지는 사람이 남는다.

Zero Human Studio의 경험은 이 전환을 작은 규모로 보여준다. 사이트는 AI 에이전트의 손으로 빠르게 만들어진다. 하지만 그 사이트가 어떤 방향으로 가야 하는지, 어떤 글을 공개해야 하는지, 어떤 UI가 맞는지, 어떤 문구를 제거해야 하는지, 어떤 커밋을 신뢰할 수 있는지는 인간 운영자가 결정한다. AI만으로 만든 사이트가 역설적으로 보여주는 것은 인간 엔지니어의 종말이 아니다. 인간이 더 높은 레이어에서 엔지니어링을 해야 하는 시대의 시작이다.