AI 시대에도 코딩은 왜 안 죽는가: 스티브 크라우스가 말한 정밀함

한눈에 보기

• 출발점: 2026년 3월 21일 Steve Krouse가 코딩 종말론에 반박하는 에세이 공개
• 핵심 주장: AI가 코드를 더 빨리 만들수록 코딩의 가치가 사라지는 게 아니라 정밀한 구조의 가치가 올라감
• 쉬운 뜻: 말로만 시키면 앱이 빨리 나오긴 해도, 기능이 늘고 사용자가 몰리면 빈틈이 드러나기 쉬움
• 대표 사례: Dan Shipper의 바이브 코딩 앱 장애 경험, Slack 알림 흐름도 단순화, Val Town 프레임워크 실험
• 실무 포인트: AI는 개발자를 없애는 도구보다 어려운 문제를 더 빨리 시험하게 돕는 도구에 가까움
• 한국 시사점: 국내 팀도 빠른 시제품과 오래 버티는 구조를 따로 봐야 할 시점

서론

2026년 3월 21일, 개발자 Steve Krouse는 Reports of code's death are greatly exaggerated라는 글을 공개했다. 제목을 우리말로 옮기면 "코드의 죽음은 너무 일찍 선고됐다" 정도가 된다. 최근 몇 달 사이 AI 코딩 도구가 빠르게 퍼지면서 "이제는 코딩을 배울 필요가 없다"는 말까지 나오는데, 이 글은 그 분위기에 정면으로 반대한다.

이 글이 흥미로운 이유는 감정적인 반발로 끝나지 않기 때문이다. 스티브 크라우스가 붙잡는 단어는 정밀함이다. 처음에는 그럴듯해 보이는 말도, 실제로 앱을 만들고 운영하는 단계에 들어가면 생각보다 훨씬 더 많은 조건과 예외를 만나게 된다는 이야기다.

이번 글은 원문을 길게 번역하기보다, 핵심 메시지를 한국어 기사형으로 다시 풀어 쓴 해설이다. 어렵게 들리는 추상화 같은 용어도 중고등학생이 읽어도 이해할 수 있도록 쉬운 말로 바꿔 설명해 보겠다.

1. 스티브 크라우스 글, 한 문장으로 줄이면

• 출발 질문: AI가 코드를 대신 써 주는 시대에 코딩은 정말 덜 중요해지는가
• 스티브의 답: 오히려 더 중요한 것은 좋은 코드와 좋은 구조
• 문제의 시작: 영어 문장이나 말로 내린 지시는 처음엔 정확해 보이지만 실제로는 자주 비어 있음
• 핵심 변화: AI는 빈칸을 빨리 메워 주지만, 그 빈칸이 맞는지 끝까지 책임져 주지는 않음

스티브 크라우스는 AI가 영어를 실행 가능한 코드로 점점 더 빨리 바꿔 주고 있다는 점 자체는 인정한다. 그래서 사람들은 "말로 대충 설명하고, AI가 앱을 만들면 끝나는 것 아닌가"라는 기대를 품기 쉽다. 요즘 자주 들리는 바이브 코딩도 바로 그 흐름을 잘 보여 주는 표현이다.

하지만 여기서 빠지는 것이 있다. 처음에 "버튼을 옮겨 달라", "조금 더 파랗게 해 달라", "사용자끼리 같이 수정되게 해 달라" 같은 말은 꽤 분명하게 들린다. 문제는 서비스가 조금만 커져도 이 말 안에 숨어 있던 빈칸이 한꺼번에 튀어나온다는 점이다.

쉽게 말해 AI는 대충 말한 요구를 눈앞의 결과물로 빠르게 바꿔 주는 기계에는 가깝지만, 숨은 조건까지 자동으로 책임지는 기계는 아니다. 그래서 코딩이 덜 중요해지는 것이 아니라, 무엇을 어디까지 정확하게 정해야 하는지가 더 중요해진다.

가브리엘라 곤살레스가 2026년 3월 17일 글에서 다시 끌어온 만화다. 요구사항은 길수록 정확해질 것 같지만, 실제 구현 단계로 가면 빠진 조건이 계속 보인다는 문제를 직관적으로 보여 준다

2. 왜 말로만 시키는 개발은 금방 한계가 오나

• 겉으로 쉬운 말: 실시간 공동 편집처럼 듣기만 하면 간단해 보이는 기능
• 실제 숨은 조건: 저장 순서, 충돌 처리, 연결 끊김, 권한, 읽음 상태, 알림 시점
• 대표 사례: Dan Shipper가 2026년 3월 20일 공개한 글에서 바이브 코딩 앱 장애 경험 공유
• 핵심 교훈: AI가 초안은 빨리 만들 수 있어도 복잡함 자체를 지워 주지는 못함

스티브 크라우스가 원문에서 가장 설득력 있게 가져오는 사례 중 하나는 Dan Shipper의 글이다. Dan Shipper는 2026년 3월 20일 공개한 글에서 바이브 코딩으로 만든 문서 편집기 Proof가 출시 직후 장애를 겪었다고 설명했다. 스티브 크라우스는 여기서 특히 실시간 공동 편집 같은 기능이 얼마나 쉽게 복잡해지는지 짚는다.

듣기만 하면 이 기능은 단순해 보인다. 여러 사람이 동시에 같은 문서를 수정하면 되는 것 아니냐는 생각이 먼저 든다. 그런데 실제로는 누가 먼저 저장했는지, 동시에 같은 문장을 바꿨을 때 무엇을 남길지, 한 사람의 인터넷이 끊겼다가 돌아왔을 때 어떤 상태를 기준으로 합칠지 같은 문제가 바로 따라온다.

이 지점이 중요하다. 복잡한 기능은 복잡해서 어려운 것이 아니라, 처음에는 복잡해 보이지 않아서 더 위험하다. 말로 설명할 때는 한 줄이면 끝나지만, 제대로 돌아가는 서비스로 만들려면 수십 개의 판단이 뒤에서 동시에 맞물려야 한다.

장면	겉으로 쉬운 요청	실제로 필요한 정밀함
공동 편집	같이 수정되게 해줘	충돌 처리, 저장 순서, 연결 복구, 권한 관리
알림 기능	중요한 것만 알려줘	방해 금지, 멘션, 읽음 상태, 기기별 조건
AI 코딩	앱 하나 만들어줘	데이터 구조, 오류 처리, 테스트, 확장 방식

표를 보면 감이 더 잘 잡힌다. 사람이 말로 내리는 지시는 보통 왼쪽 열에 머문다. 하지만 실제 서비스는 오른쪽 열까지 채워 넣어야 한다. AI는 왼쪽에서 오른쪽으로 넘어가는 속도를 높여 주지만, 빈칸이 무엇인지 스스로 결정해 주는 존재는 아니다.

학교 생활로 비유하면 더 쉽다. 반 친구들이 함께 쓰는 발표 문서를 만든다고 해 보자. 선생님이 "같이 편집하게 하면 되지"라고 말하는 것과, 실제로 누가 어떤 부분을 고쳤는지 기록하고 실수로 지운 내용을 되살리고 발표 직전 마지막 버전을 정하는 일은 완전히 다르다. 코딩에서 어려운 부분은 대개 뒤쪽이다.

3. 여기서 더 중요해지는 것이 추상화다

• 쉬운 뜻: 복잡한 조건을 사람이 다룰 수 있는 덩어리로 다시 묶는 일
• 나쁜 오해: 추상화는 애매하게 덮는 기술이라는 생각
• 실제 역할: 복잡함을 숨기기보다 더 높은 단계에서 정확하게 다루게 해 주는 구조
• 대표 예시: Sophie Alpert가 2024년 10월 30일 Slack 알림 흐름도를 더 단순하게 다시 그림

추상화라는 말은 어렵게 들리지만, 뜻은 생각보다 단순하다. 복잡한 내용을 통째로 외우는 대신, 사람이 이해할 수 있는 묶음으로 다시 정리하는 일이다. 수학에서 긴 계산을 기호 하나로 묶는 것과 비슷하고, 지하철 노선도에서 실제 거리를 줄이고 핵심 연결만 남기는 것과도 비슷하다.

스티브 크라우스는 이 지점을 강조하면서 Slack의 복잡한 알림 흐름도와, Sophie Alpert가 다시 정리한 더 단순한 버전을 함께 언급한다. 같은 문제를 다뤄도 무엇을 하나의 묶음으로 볼지를 잘 정하면 이해와 검증이 훨씬 쉬워진다는 뜻이다.

좋은 추상화는 현실을 가리는 안개가 아니다. 오히려 현실을 더 정확하게 다룰 수 있게 만드는 새 층위에 가깝다. 그래서 스티브 크라우스는 AI 시대일수록 이런 능력이 더 필요하다고 본다. AI가 코드를 많이 만들어 줄수록, 사람은 그 많은 코드 위에서 무엇이 같은 문제이고 무엇이 다른 문제인지 더 잘 묶어야 하기 때문이다.

Sophie Alpert가 2024년 10월 30일 공개한 단순화 버전이다. 복잡한 시스템을 이해하기 쉽게 다시 묶는 것이 좋은 추상화라는 점을 보여 주는 대표 예시다

이 그림이 말해 주는 핵심은 선명하다.

• 나쁜 구조: 조건이 늘 때마다 규칙이 사방으로 새어 나가는 상태
• 좋은 구조: 비슷한 규칙을 한 자리에서 다루고, 예외도 같은 문맥 안에서 읽히는 상태
• 실무 해석: 기능을 더 많이 붙이는 것보다, 구조를 더 잘 묶는 일이 오래 남는 경쟁력

결국 코딩의 가치도 여기에 있다. 코드는 단순히 컴퓨터를 움직이는 문장이 아니라, 복잡한 현실을 사람이 다시 읽고 고칠 수 있는 형태로 눌러 담은 기록이다. AI가 빨라질수록 이런 기록의 품질은 더 중요해진다.

4. AI는 코딩을 없애는 대신 코딩의 숙제를 바꾼다

• 더 쉬워진 것: 시제품 제작, 초안 생성, 반복 작업, 기본 리팩터링
• 더 중요해진 것: 구조 선택, 검증 기준, 예외 처리, 유지보수 판단
• 스티브의 예시: Opus 4.6이 Val Town용 전면형 React 프레임워크 문제 해결에 도움
• 핵심 시선: AI의 가장 큰 가치는 더 싼 대충 코드보다 더 좋은 구조 실험에 있을 가능성

스티브 크라우스가 흥미롭게 보는 지점은 여기다. 많은 사람이 AI가 똑똑해질수록 사람은 더 이상 코드 구조를 고민하지 않아도 된다고 생각하지만, 그는 오히려 반대로 본다. 정말 강한 AI가 있다면 가장 먼저 시킬 일은 값싼 결과물을 더 많이 찍어내는 일이 아니라, 지금까지 풀기 어려웠던 구조 문제를 더 잘 푸는 일이라는 것이다.

원문에서 스티브는 실제 사례도 든다. 그는 Claude Opus 4.6이 Val Town에서 쓰는 전면형 React 프레임워크 실험을 도와주며, 자신이 오래 붙잡고 있던 문제 목록을 한 번에 많이 줄여 줬다고 설명한다. 여기서 중요한 것은 AI가 사람을 밀어냈다는 점이 아니라, 사람이 더 높은 수준의 구조를 시험할 수 있게 됐다는 점이다.

이 해석은 꽤 현실적이다. 이미 현장에서는 AI가 초안 작성, 테스트 보강, 반복 수정, 이름 정리, 파일 분리 같은 일을 빠르게 도와준다. 대신 사람은 "이 기능을 어떤 구조 위에 올릴지", "지금 편한 선택이 나중에 얼마나 큰 빚이 될지", "장애가 났을 때 어디서 고칠 수 있는지"를 더 많이 봐야 한다.

실무자 관점에서는 아래 네 줄로 정리할 수 있다.

• 초안 생산: 훨씬 빨라짐
• 구조 실험: 이전보다 싸짐
• 검증 책임: 여전히 사람 몫
• 좋은 코드의 기준: 오히려 더 또렷해짐

그래서 "AI 때문에 코딩이 끝난다"는 말은 절반만 맞다. 단순 반복 코딩의 비중은 줄어들 수 있다. 하지만 복잡한 문제를 잘 나누고 오래 버티는 구조를 만드는 능력은 더 중요해질 가능성이 크다.

5. 중고등학생 눈높이로 보면 더 쉽다

• 계산기 비유: 계산이 쉬워져도 수학 개념이 사라지지는 않음
• 카메라 비유: 사진을 더 쉽게 찍어도 좋은 구도와 장면 선택은 더 중요
• 번역기 비유: 문장을 옮겨도 맥락과 책임 판단은 남아 있음

이 글을 가장 쉽게 이해하는 방법은 계산기를 떠올리는 것이다. 계산기가 생겼다고 해서 수학 공부가 끝나지는 않았다. 오히려 단순 계산 시간을 줄인 덕분에, 사람은 더 어려운 문제를 풀고 더 큰 개념을 배울 수 있게 됐다.

AI 코딩도 비슷하다. 화면 하나 띄우고 버튼 하나 붙이는 일은 더 쉬워질 수 있다. 하지만 서비스가 커질수록 중요한 것은 "어떤 코드를 몇 줄 썼느냐"가 아니라 "이 구조가 오래 버티느냐"다. 즉 쉬운 작업이 줄어드는 대신, 더 어려운 판단이 앞으로 나오게 된다.

그래서 학생 입장에서도 코딩 공부가 무의미해지는 것은 아니다. 이제는 문법만 외우는 공부보다 문제를 잘게 나누는 힘, AI가 낸 답을 의심하고 확인하는 힘, 여러 조건을 빠뜨리지 않는 힘이 더 중요해진다고 보는 편이 맞다.

6. 한국 시장에서는 어떻게 봐야 하나

• 스타트업: 시제품 출시 속도는 빨라져도 운영 구조와 장애 대응 체계는 더 중요
• 사내 자동화: 보고서, 고객 응대, 문서 처리 자동화는 쉬워져도 예외 처리 설계는 여전히 핵심
• 교육 시장: 코딩을 안 배워도 된다는 주장보다 AI와 함께 검증하는 학습이 현실적
• 개발 조직: 빨리 만드는 능력과 오래 유지하는 능력을 분리해서 봐야 함

한국 시장에서도 이 글의 메시지는 가볍지 않다. 국내 스타트업과 SaaS 팀은 이미 AI로 시제품을 빠르게 만드는 흐름에 익숙해지고 있다. 하지만 실제 고객을 받기 시작하면 개인정보, 결제, 로그, 장애 대응, 관리자 권한 같은 문제는 그대로 남는다.

특히 금융, 교육, 커머스, B2B 업무 도구처럼 예외가 많은 분야는 더 그렇다. 화면은 빨리 만들어도, 뒤에서 누가 어떤 정보에 접근하는지, 틀린 결과가 나왔을 때 어떻게 되돌리는지, 사람이 마지막 승인 권한을 어디서 가지는지 같은 구조를 빼면 오래가기 어렵다.

교육 현장도 비슷하다. "어차피 AI가 코드를 짜 주는데 왜 배우나"라는 말은 짧게 보면 그럴듯해 보이지만, 실제로는 AI에게 무엇을 맡기고 무엇을 확인해야 하는지 배울 필요가 더 커진다. 앞으로는 코딩 교육이 사라진다기보다, 검증과 구조 이해 중심으로 이동한다고 보는 편이 현실적이다.

7. 이 글을 읽을 때 같이 봐야 할 한계

• 글의 성격: 연구 논문이 아니라 현장 감각이 강한 의견 에세이
• 맞는 범위: 실제 운영 서비스, 협업 제품, 구조가 복잡한 개발
• 덜 맞는 범위: 하루 이틀 안에 끝나는 단순 시제품, 내부 실험, 일회성 도구
• 균형 포인트: 바이브 코딩이 쓸모없다는 말이 아니라, 오래 갈수록 정밀함이 다시 중요해진다는 뜻

균형 있게 보면 스티브 크라우스의 주장도 모든 상황에 똑같이 들어맞는 것은 아니다. 사내에서 잠깐 쓸 자동화 도구, 이벤트용 홍보 페이지, 일회성 시연 앱이라면 AI가 대충 만든 코드로도 충분할 수 있다. 이런 영역에서 생산성이 크게 올라가는 것도 사실이다.

다만 사용자가 늘고, 데이터가 쌓이고, 장애 비용이 커지는 순간 이야기가 달라진다. 그때부터는 AI가 빨리 써 준 코드보다 사람이 얼마나 구조를 이해하고 다시 고칠 수 있느냐가 더 중요해진다. 스티브 크라우스의 글은 바로 그 경계선을 분명하게 보여 준다는 데 의미가 있다.

결론

Steve Krouse의 2026년 3월 21일 글이 남기는 메시지는 분명하다. 그의 주장에 따르면 AI 시대에 약해지는 것은 코딩 그 자체라기보다, 대충 만든 코드도 오래 버틸 것이라는 착각에 더 가깝다.

AI는 분명히 코딩을 더 빠르게 만들고 있다. 하지만 빠르게 만든 결과물이 실제 서비스에서 오래 살아남으려면, 결국 정밀한 조건 정리와 좋은 추상화, 검증 가능한 구조가 필요하다. 그래서 앞으로 중요한 사람은 손으로만 코드를 오래 치는 사람보다, 복잡한 문제를 더 정확하게 나누고, AI가 만든 답을 다시 구조화할 수 있는 사람일 가능성이 크다.

코딩이 끝나는 시대라기보다, 코딩의 기준이 더 높아지는 시대라고 보는 편이 맞다. 이 변화는 생각보다 오래 갈 가능성이 크다.

참고 자료

• Reports of code's death are greatly exaggerated - Steve Krouse, 2026년 3월 21일
• A sufficiently detailed spec is code - Haskell for all, 2026년 3월 17일
• When Your Vibe Coded App Goes Viral—And Then Goes Down - Every, 2026년 3월 20일
• Everyone is wrong about that Slack flowchart - Sophie Alpert, 2024년 10월 30일