AI 코딩 딸깍론, 일정 줄이면 망합니다

요즘 개발 관련 유튜브를 조금만 보면 AI 코딩 영상 썸네일이 비슷비슷하게 뜹니다. 실제 캡처를 붙인 건 아니지만, 내가 말하는 건 이런 종류의 문구입니다.

 

유튜브 썸네일식 문구

 

‘AI 코딩 상위 1%만 아는 루프 엔지니어링.’

 

‘하네스 엔지니어링으로 개발자 없이 앱 만들기.’

 

‘클로드 코드로 10분 만에 서비스 완성.’

 

딸깍. 끝.

 

그리고 그 영상을 본 대표님이 슬랙에 링크를 던집니다. “이거 보니까 우리도 내부툴 하나는 하루면 되겠는데?” 이 문장을 보는 순간 개발자는 잠깐 말문이 막힙니다. 영상 속 앱에는 로그인도, 권한도, 결제도, 장애도, 개인정보도, 월요일 아침 CS도 없거든요. 버튼이 눌린 겁니다. 아직은 화면이 움직인 정도입니다.

 

이번 글의 출발점은 이 장면입니다. AI 코딩 영상은 분명 흥미롭지만, 회의실로 들어오는 순간 ‘보여주기용 화면’이 ‘실제 일정’으로 번역되곤 합니다.

내 생각은 단순합니다. AI 코딩 에이전트는 진짜 강해졌습니다. 다만 “기획부터 운영 제품까지 딸깍”은 아직 다른 장르입니다. 그건 제품 출시라기보다 잘 만든 화면 시연에 가깝습니다.

 

AI를 낮춰 볼 생각은 없습니다. 나는 요즘 AI 코딩 도구를 꽤 진지하게 봅니다. OpenAI가 말하는 하네스 엔지니어링, Anthropic이 말하는 장시간 에이전트 운영, GitHub Copilot cloud agent, Sentry Autofix 같은 흐름을 보면 이제 ‘AI가 코드 조금 도와준다’ 수준은 이미 지났습니다. 조건이 맞으면 사람이 코드를 많이 치지 않아도 그럴듯한 결과물이 나옵니다.

 

그 성공담이 유튜브 제목으로 줄어들면 얘기가 달라집니다. “검증 가능한 작은 작업을 에이전트에게 맡기고, 테스트와 로그와 PR 리뷰로 묶었다”는 말은 조회수가 잘 안 나옵니다. “딸깍하면 완성”은 잘 나오죠. 그래서 오늘은 이 차이를 좀 세게 나눠보려고 합니다.

 

루프 엔지니어링은 마법 주문이 아니다

먼저 용어부터 정리해야 합니다. 요즘 말하는 루프 엔지니어링은 대충 이런 흐름입니다. AI에게 일을 시킵니다. AI가 코드를 씁니다. 테스트를 돌립니다. 실패 로그를 읽습니다. 다시 고칩니다. 그다음 작업을 찾습니다. 이 반복을 사람 손가락 대신 시스템 안에서 굴리는 겁니다.

 

말만 들으면 멋있습니다. 실제로 쓸 만한 부분도 많습니다. Addy Osmani가 정리한 Loop Engineering 글이나 GeekNews 요약을 보면, 루프는 단순 프롬프트가 아니라 automations, worktrees, skills, connectors, sub-agents, memory가 엮인 작업 방식에 가깝습니다. 사람이 매번 ‘이제 뭐 해?’라고 묻는 대신, 에이전트가 일을 쪼개고 검증하고 다음 단계로 넘어가게 만드는 겁니다.

 

그런데 여기서 유튜브식 오해가 붙습니다. 루프가 있다고 해서 정답이 갑자기 생기지는 않습니다. 틀린 방향으로도 아주 성실하게 달릴 수 있습니다. 엉뚱한 요구사항을 받으면 엉뚱한 기능을 열심히 만들고, 테스트가 허술하면 허술한 통과를 반복합니다. 사람도 삽질을 하는데, AI는 그 삽질을 자동화할 수 있습니다. 웃긴데 좀 무섭습니다.

 

루프 엔지니어링의 핵심은 ‘AI를 오래 돌리는 것’보다 ‘틀렸을 때 바로 들키게 만드는 것’에 가깝습니다.

 

하네스 엔지니어링은 안전벨트에 가깝다

하네스 엔지니어링은 더 오해받기 쉽습니다. OpenAI의 Harness engineering 글은 내부 베타 제품을 만들면서 Codex가 사실상 모든 코드, 테스트, CI, 문서, 관측 도구를 작성한 사례를 소개합니다. 겉으로 보면 대표님들이 좋아할 만한 문장입니다. “봐라, AI가 다 했네.”

 

그런데 그 글을 자세히 읽으면 오히려 다른 장면이 보입니다. 그들은 AI에게 빈 들판을 주고 ‘도시 지어’라고 시킨 게 아닙니다. 에이전트가 일할 수 있는 저장소 구조, 테스트, 린터, 관측 가능성, 문서, 의사결정 기록, 작업 단위를 만들었습니다. AI에게 마음껏 하라고 풀어준 게 아니라, AI가 틀렸을 때 숨을 곳을 줄인 겁니다.

 

Anthropic의 장시간 에이전트 글도 비슷합니다. ‘claude.ai 클론 만들어줘’ 같은 높은 수준의 지시만 던지면 강한 모델도 프로덕션급 웹앱을 만들지 못한다고 말합니다. 대신 초기화 에이전트가 작업 로그, 기능 목록, 실행 스크립트, 초기 커밋을 만들고, 코딩 에이전트는 한 번에 한 기능씩 처리하며 상태를 남기는 방식이 필요하다고 설명합니다.

 

그러니까 하네스는 날개라기보다 안전벨트에 가깝습니다. 차선 이탈 경고를 달고, 브레이크가 먹는지 확인하는 일입니다. 쇼는 덜 납니다. 대신 회사에서는 이쪽이 더 오래 갑니다.

 

진짜 잘 되는 곳은 있다. 특히 실패 신호가 선명한 곳

그렇다고 ‘AI 코딩? 다 과장이지’라고 말하면 그것도 너무 쉽게 접는 겁니다. 잘 되는 영역은 분명합니다. 작은 기능 구현, CRUD 골격, UI 프로토타입, 테스트 보강, 코드 정리, 문서화, 마이그레이션 초안, 에러 재현. 이런 작업은 AI가 꽤 잘합니다.

 

공통점이 있습니다. 범위가 좁고, 성공/실패를 확인할 수 있고, 기존 코드나 로그라는 참고 자료가 있습니다. AI가 길을 잃어도 다시 붙잡을 손잡이가 있는 작업입니다.

 

 

Sentry Autofix 같은 영역이 강한 이유는 여기에 있습니다. 이미 문제가 터졌고, 로그·트레이스·프로파일·코드라는 실마리가 있기 때문에 AI가 붙잡을 수 있는 맥락이 많습니다.

 

Sentry의 Seer/Autofix는 좋은 예입니다. Sentry 문서는 Seer가 issue details, tracing data, logs, profiles 같은 관측 데이터를 사용해 문제 해결을 돕고, Autofix는 root cause를 찾아 코드 수정안과 PR 생성까지 이어질 수 있다고 설명합니다.

 

이 영역이 AI에 잘 맞는 이유는 단순합니다. 이미 문제가 터졌고, 로그·트레이스·프로파일·코드라는 실마리가 있기 때문입니다.

 

앱 하나를 처음부터 끝까지 맡긴다는 이야기와는 거리가 있습니다. 이미 발생한 오류를 추적하고, 관련 코드와 로그를 근거로 수정 후보를 만드는 일입니다. 그래서 실무적으로 훨씬 설득력이 있습니다.

 

 

GitHub Copilot cloud agent도 비슷하게 봐야 합니다. 저장소를 조사하고 구현 계획을 만들고 브랜치에 변경을 만든 뒤 PR로 이어질 수 있습니다. 하지만 이 역시 ‘검토 가능한 PR’ 단위입니다. 회사에 필요한 제품을 알아서 기획하고, 이해관계자를 설득하고, 릴리즈 책임까지 지는 존재와는 거리가 있습니다.

 

내가 보기엔 기준이 꽤 선명합니다. 성공과 실패를 확인할 수 있는 반복 작업에서는 AI가 강합니다. 반대로 회사 안에서 아직 합의도 안 된 문제를 던지면, 결과물은 그럴듯해도 책임은 공중에 뜹니다.

 

유튜브 영상은 성공한 루프만 보여준다

여기서 유튜브 문법이 끼어듭니다. 유튜브를 탓하려는 얘기는 아니고요. 영상은 빠르게 보여줘야 합니다. 10분 안에 놀라움을 줘야 합니다. 그러려면 화면 시연이 좋아야 합니다. 깨끗한 새 프로젝트, 미리 준비된 API 키, 간단한 요구사항, 예쁜 UI, 행복한 경로. 이 조합이면 화면만 봐서는 정말 마술처럼 보입니다.

 

그런데 회사 제품은 대체로 반대입니다. 요구사항은 흐립니다. 데이터는 더럽습니다. 권한은 꼬여 있습니다. 예전 담당자가 만든 배치가 밤 3시에 돌고 있습니다. 결제는 해외 카드에서 한 번씩 터집니다. 개인정보 보관 기간이 걸립니다. 운영팀은 엑셀을 버리지 못합니다. 고객은 버튼을 상상과 다르게 누릅니다.

 

영상에서 보이는 것 회사에서 빠지면 터지는 것 현실적인 AI 역할

새 프로젝트에서 버튼이 눌린다	기존 사용자 데이터, 권한, 예외 케이스, 마이그레이션	프로토타입과 테스트 케이스 초안
예쁜 랜딩 페이지가 나온다	브랜드 톤, 접근성, 모바일 QA, 성능, 실제 콘텐츠	UI 초안, 컴포넌트 변형, 카피 후보
로그인 화면이 생긴다	세션 만료, 권한 분리, 감사 로그, 보안 리뷰	인증 흐름 초안과 테스트 보강
버그를 고친 것처럼 보인다	재현 조건, 회귀 테스트, 배포 후 관측	Sentry/로그 기반 원인 분석과 PR 초안
업로드까지 자동화된다	정책, 라벨, 저작권, 계정 신뢰, 사고 시 롤백	보류함, 검수 큐, 기록 자동화

 

그래서 ‘AI가 10분 만에 앱을 만들었다’는 말은 반은 맞고 반은 위험합니다. 10분 앱은 가능합니다. 10분 회사 제품은 다른 장르입니다. 마치 컵라면을 끓였다고 식당 운영을 끝냈다고 말하는 느낌입니다. 배는 찰 수 있습니다. 위생점검은 아직입니다.

 

화면 시연은 앞쪽 노트북에서 빛납니다. 하지만 운영 제품은 뒤쪽의 케이블, 단말기, 권한, 결제, 파일, QA 장비까지 같이 굴러가야 합니다.

대표님이 착각하면 팀은 이상한 방향으로 빨라진다

내가 더 찝찝한 건 기술보다 회의실에서 벌어지는 번역입니다. 대표님은 유튜브에서 속도를 봅니다. 개발자는 운영 부담을 봅니다. 그런데 대화가 잘못 붙으면 개발자의 신중함은 게으름처럼 보이고, 대표의 기대는 ‘변화해야 한다’는 말로 단단해집니다.

 

그때 꼭 나오는 말이 있습니다. “AI 쓰면 이 정도는 금방 되지 않아?” 짧은 말인데, 듣는 쪽은 바로 방어 태세가 됩니다. ‘이 정도’가 뭘 뜻하는지 아무도 정하지 않았기 때문입니다. 화면 하나인지, 권한이 있는 기능인지, 장애 대응까지 포함한 출시인지, 6개월 뒤 유지보수까지 포함한 제품인지가 빠져 있습니다.

 

GitLab의 2026 AI Accountability Report는 이 간극을 꽤 잘 보여줍니다. 조사 대상 조직의 80%는 AI 도구를 정책보다 빠르게 도입했고, 92%는 AI 생성 코드 거버넌스 문제를 겪고 있다고 답했습니다. 특히 85%는 병목이 코드 작성에서 리뷰와 검증으로 이동했다고 봤습니다. 이게 핵심입니다. 코드는 빨리 나오는데, 책임은 더 빨리 사라지지 않습니다.

 

METR의 숙련 오픈소스 개발자 연구도 찬물 같은 자료입니다. early-2025 AI 도구를 쓴 개발자들이 예상과 달리 작업 완료 시간이 19% 늘었다는 결과가 나왔습니다. 이 연구 하나로 ‘AI는 쓸모없다’고 말하면 과합니다. 조건이 있고, 도구는 계속 바뀝니다. 하지만 적어도 한 가지는 분명합니다. 화면에서 빨라 보이는 것과 실제 완료 시간이 줄어드는 것은 다릅니다.

 

AI 도입의 병목은 이제 ‘코드를 누가 치느냐’보다 ‘누가 이해하고, 검증하고, 운영 책임을 지느냐’ 쪽으로 옮겨가고 있습니다.

 

AI가 만든 코드는 공짜가 아니다. 이해 비용이 붙는다

Addy Osmani는 이 문제를 comprehension debt, 이해 부채라는 말로 설명합니다. AI가 코드를 빠르게 만들수록, 사람이 그 코드를 이해해야 하는 부담이 뒤늦게 쌓인다는 뜻입니다. 이 표현은 꽤 마음에 듭니다. 기술 부채보다 더 얄밉습니다. 코드는 돌아가는데, 팀이 그 코드가 왜 그런지 모르면 빚은 이미 생긴 겁니다.

 

회사에서 제일 위험한 AI 코드는 ‘틀린 코드’가 아닐 수 있습니다. 틀린 코드는 테스트에서 걸리거나 장애로 들킵니다. 더 위험한 건 대충 맞아 보이는 코드입니다. 당장은 돌아갑니다. PR도 그럴듯합니다. 그런데 예외 케이스가 오면 아무도 이유를 모릅니다. 그때 개발팀은 AI가 만든 코드를 사람이 고고학 발굴하듯 파기 시작합니다.

 

그래서 AI 코딩을 잘 쓰는 팀은 오히려 더 꼼꼼해집니다. 스펙을 씁니다. 테스트를 만듭니다. 에이전트에게 브랜치를 나눠 줍니다. PR 설명을 요구합니다. 실행 로그를 남깁니다. 스크린샷을 비교합니다. 실패하면 왜 실패했는지 기록합니다. 느려 보이지만, 이게 빨라지는 길입니다.

 

그러면 회사는 무엇을 해야 하나

대표가 먼저 할 일은 압박보다 질문을 바꾸는 겁니다. ‘왜 유튜브처럼 빨리 못 해?’가 아니라 ‘우리 업무 중 어디를 검증 가능한 AI 루프로 바꿀 수 있나?’라고 물어야 합니다. 이 차이는 큽니다. 앞 질문은 사람을 움츠러들게 만들고, 뒷 질문은 시스템을 고치게 합니다.

 

내가 회사에서 AI 코딩 에이전트를 제대로 붙인다면, 처음부터 제품 전체를 맡기지 않습니다. 아래 같은 일부터 시작합니다.

 

• 장애 대응 루프: Sentry/로그 기반으로 원인 후보, 재현 절차, 테스트, PR 초안을 만들게 한다.
• 테스트 보강 루프: 기존 버그나 신규 기능에 대해 회귀 테스트를 먼저 만들게 한다.
• 문서 최신화 루프: 코드 변경 후 README, API 문서, 운영 노트를 같이 업데이트하게 한다.
• 작은 내부툴 루프: 명세가 선명한 CRUD나 관리자 화면을 브랜치 단위로 맡긴다.
• QA 루프: 화면 캡처, 접근성, 모바일 폭, 에러 상태를 자동 점검하게 한다.

그리고 하네스를 만듭니다. `setup.sh`나 `make dev`처럼 에이전트가 환경을 띄울 수 있는 명령. seed data. 테스트. 린트. 타입체크. preview URL. 로그. PR 템플릿. 롤백 기준. 권한 범위. 이걸 먼저 정해야 합니다. AI에게 일을 맡긴다는 건 사실 이 지루한 것들을 더 잘 정리한다는 뜻입니다.

 

 

AI 개발의 마지막 장면은 ‘자동 완성’이 아니라 승인 게이트여야 합니다. 제품 책임은 아직 사람과 조직에 남아 있습니다.

 

좋은 AI 개발 조직은 에이전트를 무한히 믿지 않습니다. 틀렸을 때 바로 들키게 만듭니다.

 

유튜브가 완전히 틀린 것도 아니다

한쪽으로만 몰아가면 곤란합니다. 유튜브 영상들을 전부 허황되다고 몰아붙일 수도 없습니다. 실제로 개발 속도는 바뀌고 있습니다. 예전에는 하루 걸릴 작은 관리자 화면이 몇 시간 안에 골격을 잡기도 하고, 익숙하지 않은 SDK 사용법을 빠르게 뚫기도 합니다. 테스트 작성도 도움을 많이 받습니다. 문서 초안은 말할 것도 없습니다.

 

또 하나. 유튜브는 많은 사람에게 새로운 도구를 처음 보여주는 통로입니다. 과장된 제목이 짜증나긴 하지만, 그 영상을 보고 실험을 시작하는 사람도 있습니다. 따져볼 건 영상 자체보다 그 영상을 본 뒤 회사가 어떤 결론을 내리느냐입니다.

 

나쁜 결론은 이쪽입니다. ‘이제 개발은 쉬워졌으니 일정 줄이자.’ 좋은 결론은 반대쪽입니다. ‘이제 반복 작업을 에이전트 루프로 만들 수 있으니, 어떤 검증 장치를 먼저 만들까?’ 비슷한 말처럼 보여도 현장에서는 완전히 다르게 들립니다. 하나는 압박이고, 하나는 투자입니다.

 

내가 대표라면 이렇게 묻겠다

대표 입장에서도 궁금할 수밖에 없습니다. AI가 이렇게 발전했는데 개발팀은 왜 그대로 바빠 보이나. 이 질문은 필요합니다. 피할 질문도 아니고요. 다만 조금 더 정확하게 던져야 합니다.

 

• 우리 제품에서 명세가 선명하고 테스트 가능한 작업은 무엇인가?
• AI가 만든 PR을 누가, 어떤 기준으로 리뷰할 것인가?
• 코드 작성 시간이 줄었을 때 리뷰/QA/배포 병목은 어디로 이동하는가?
• 에이전트가 접근해도 되는 저장소와 데이터 범위는 어디까지인가?
• 실패한 AI 작업은 어디에 기록하고 다음 루프에 어떻게 반영할 것인가?

이런 질문을 하는 대표는 개발자를 압박하지 않아도 속도를 올립니다. 반대로 유튜브 링크 하나 던지고 ‘이제 되지?’라고 하는 대표는 팀을 빠르게 만드는 게 아니라 대화를 망가뜨립니다. 개발자는 방어하고, 대표는 답답해하고, AI는 둘 사이에서 괜히 만능 버튼 취급을 받습니다. 버튼 하나가 너무 많은 일을 뒤집어쓰는 겁니다.

 

내가 개발팀이라면 이렇게 방어하지 않겠다

개발팀도 방어만 하고 있으면 안 됩니다. ‘그거 안 돼요’만 반복하면 설득력이 떨어집니다. 진짜로 되는 영역까지 같이 막아버리면, 밖에서 보기에는 변화 거부처럼 보입니다. 과장된 영상도 문제지만, 아무것도 안 바뀐 척하는 태도도 오래 못 갑니다.

 

개발팀은 오히려 먼저 제안해야 합니다. ‘대표님, 영상처럼 제품 전체를 딸깍하는 건 안 됩니다. 대신 장애 자동 분석 루프부터 붙이면 이번 분기 안에 효과를 볼 수 있습니다.’ 이런 식으로요. 스스로 실험 범위를 잡고, 성공 기준을 정하고, 작은 승리를 만들어야 합니다.

 

AI 도구를 막는 개발팀보다, AI가 실패하지 못하게 하네스를 만드는 개발팀이 더 강합니다. 앞으로 좋은 개발자는 코드를 잘 치는 사람에서, AI가 치는 코드가 회사 안에서 살아남을 수 있게 만드는 사람으로 조금씩 이동할 겁니다. 싫다고 피하면 뒤처지고, 막 던지면 사고 납니다. 그 사이를 잡는 일이 앞으로 더 비싸질 겁니다.

 

그래서 결론: 유튜브 10분 영상과 회사 제품은 다르다

2026년에 AI 코딩은 이미 다른 단계로 넘어왔습니다. Codex, Claude Code, Copilot cloud agent, Cursor, Sentry Seer 같은 흐름을 보면 이제 개발자는 AI와 같이 일하는 방식을 피하기 어렵습니다. 단순 자동완성 시대는 이미 지나갔고, 에이전트에게 일을 나누고 검증하는 시대로 가고 있습니다.

 

하지만 이 변화를 ‘개발자가 필요 없어졌다’로 읽으면 거의 반드시 틀립니다. 조금 더 정확히 말하면, 개발자의 일이 코드 입력에서 작업 설계, 검증, 관측, 리뷰, 운영 책임으로 이동하고 있습니다. 별로 낭만적이지 않죠. 그런데 원래 제품은 낭만보다 운영으로 살아남습니다.

 

그러니 다음에 누군가 AI 코딩 영상을 보내며 ‘이거 딸깍하면 되는 거 아냐?’라고 묻는다면, 나는 이렇게 답하겠습니다.

 

딸깍으로 끝나는 건 화면 시연입니다.

 

진짜 제품은 그 다음부터 시작됩니다.

 

검증하고, 책임지고, 장애까지 버티는 그 구간부터가 제품입니다.

 

자료 확인 기준: 2026년 6월 29일. OpenAI - Harness engineering · OpenAI - How agents are transforming work · Anthropic - Effective harnesses for long-running agents · Claude Code best practices · GitHub Copilot cloud agent · Sentry Seer · Sentry Autofix · GitLab AI Accountability Report · METR - Early-2025 AI productivity study · METR - Measuring AI ability to complete long tasks · Addy Osmani - Loop Engineering · Addy Osmani - My LLM coding workflow going into 2026 · Addy Osmani - Comprehension Debt · Addy Osmani - Vibe coding is not AI-assisted engineering · Simon Willison - Vibe engineering · Simon Willison - Agentic engineering patterns · GeekNews - Loop Engineering · GeekNews - Harness Engineering · GeekNews - AI 코딩 주장의 허상