[🤖] 점점 뼈와 살로 새겨지는 개발 패러다임 전환

✨ GPT-5.5의 요약 　

면접에서 체감한 개발자 역할 변화부터 바이브코딩의 한계와 하네스 엔지니어링의 필요성까지, AI 시대의 핵심 역량이 코딩 손기술에서 기획, 설계, 실행, 피드백, 맥락 판단으로 옮겨가고 있음을 정리한 기록.

점점 뼈와 살로 새겨지는 패러다임 전환

면접에서 박힌 결론

오늘 면접에서 제일 크게 박힌 건 이거였다.

이제 개발자에게 필요한 능력의 중심이 손으로 코드를 치는 능력에서 기획/설계/실행/피드백 능력으로 옮겨가고 있다.

거기에 전체 맥락을 파악하기 위한 개념, 도메인 지식, 직관력까지 붙어야 한다. 그냥 “AI 잘 씁니다” 정도로는 안 된다.

계속 쌓이던 감각

사실 이 감각은 계속 쌓이고 있었다.

처음에는 GPT, o3, AGI, 휴머노이드, … 특이점이 온다…에서 적었던 것처럼, GPT를 외장 뇌처럼 느끼는 압도감에 가까웠다.

그다음 개발 패러다임의 전환에서는 개발 프로세스 일부가 코딩 노가다에서 AI API를 활용한 딸깍으로 바뀌고 있다고 봤다. 그때도 context window와 output token 한계 때문에 “아직은 간단한 MVP 정도”라고 적었다.

그러니까 바이브코딩의 한계를 이제야 발견한 건 아니다. 처음부터 한계는 보였다. 다만 그 한계선이 미친 속도로 뒤로 밀리고 있을 뿐이다.

이후 AI 시대의 생존 가이드라인에서는 AI 리터러시, 맥락적 지능, 인간만의 판단 영역을 붙잡으려 했다.

VSCode Copilot AI 자동완성 수준에서는 AI에게 기획 의도를 코멘트로 전달하고, 생성된 코드의 구조를 읽고, 적용을 허락하는 방식이 현실로 내려왔다.

그리고 플러터 강좌 중단과 바이브 코딩 사업 전환에서는 더 노골적으로 “바이브 코딩이라는 새로운 패러다임이 도래했다”고 썼다.

올해 Claude Code든 Codex든, 개 폐급에 눈치 없는 천재다.에서는 문제가 더 선명해졌다. AI가 코드를 짜느냐 못 짜느냐가 아니라, 이 눈치 없는 천재들을 어떻게 멈춰 세우고, 어떻게 검증 루프 안에 가둬두느냐가 문제였다.

취업 시장의 언어로 돌아온 변화

그 흐름이 오늘 면접에서 취업 시장의 언어로 되돌아왔다. 이제는 사업가적 마인드를 겸비한 기획, 설계, 실행, 피드백 능력이 개발자에게 요구된다.

생산성은 월 500만원 이상 받던 개발자보다 높아졌는데, 받는 월급은… 하… 슬프다.

그러니까 이건 그냥 머리로 이해한 변화가 아니라, 점점 몸으로 맞고 있는 패러다임 전환이다.

코딩의 시대는 끝났다

손으로 코드 짜는 능력은 핵심이 아니다

조금 거칠게 말하면, 이제 코딩 능력 따위는 예전만큼 중요하지 않다.

물론, C언어, 어셈블리어, 기계어를 배워두면 시스템 구조 이해에 도움이 되는 것처럼, 코딩 지식 자체가 완전히 무가치해지는 것은 아니다.

다만 시장에서 더 크게 요구되는 능력은 더 이상 “내 손으로 구현할 수 있는가”가 아니다.

예전에는 파이썬으로 대다수의 복잡하지 않은 반복 작업이 해결되는 시대가 왔다. 이제는 AI로 대다수의 구현 문제가 해결되는 시대로 넘어가고 있다.

추상화의 역사는 반복된다

생각해보면 이건 갑자기 튀어나온 일이 아니다.

예전에 AI 붐 이후 인류의 운명을 건 치킨게임에서 나는 인류 기술 발전을 이런 식으로 적었다.

• 드디어 불을 만들어냈다! 기쁘다. (약 50만 년 전)
• 드디어 전기를 만들어냈다! 기쁘다. (1880년대)
• 드디어 컴퓨터를 만들어냈다! 기쁘다. (1940년대)
• 드디어 인공지능을 만들어냈다! 기쁘다. (2010년대)
• 드디어 범용 인공지능(AGI)을 만들어냈다! 기쁘다. (2030년대로 예상…?)
• 드디어 초인공지능(ASI)을 만들어냈다! 기쁘다. (2050년대…?)

그때는 인류 기술 발전 속도 자체가 너무 미친 것 같아서 적은 말이었다. 그런데 지금 다시 보면, 개발도 결국 비슷한 흐름이었다.

• 전구 스위치 딸깍. (1880년대)
• 기계어 딸깍. (1940년대)
• 어셈블리어 딸깍. (1940~1950년대)
• C언어 딸깍. (1970년대)
• 파이썬 딸깍. (1990년대)
• 프레임워크 딸깍. (2000~2010년대)
• AI 딸깍. (2020년대)
• 하네스 딸깍. (2020년대 중반~)

말장난 같지만, 결국 이런 흐름은 추상화의 역사에 가깝다.

사람은 계속 더 낮은 층을 기계에게 넘겨왔다.

전구 스위치에서 기계어로, 기계어에서 어셈블리어로, 어셈블리어에서 C로, C에서 파이썬으로, 파이썬에서 프레임워크로, 이제는 AI에게 자연어로 시키는 쪽으로 올라왔다.

매번 아래층을 모르는 사람은 불안했고, 매번 아래층을 직접 만질 줄 아는 능력은 어느 정도 중요했다. 하지만 시장의 중심은 결국 위로 올라갔다.

그러니까 내가 “코딩 능력 따위는 중요치 않다”고 한 것은, “코딩을 아예 할 줄 몰라도 된다”는 말이 아니다. 그만큼 코딩 능력이 개발의 중심에서 밀려나고 있다는 말이다.

기계어를 몰라도 파이썬을 쓸 수 있었고, 브라우저 렌더링과 HTTP를 밑바닥부터 다 몰라도 React와 Next.js를 쓸 수 있었다.

앞으로는 React 상태관리나 API 라우팅을 손으로 다 외우지 않아도 AI에게 구현을 맡길 수 있다. 문제는 그 다음이다. 프레임워크 딸깍도 결국 제품 구조를 알아야 힘을 냈다. AI 딸깍도 마찬가지다.

패러다임이 바뀌면 평가 기준도 바뀐다

이미 내 일기 안에서 계속 반복되던 감각은 결국 이것이었다.

무엇을 문제로 보고, 무엇을 잘한 일로 보고, 어떤 사람을 좋은 개발자로 볼 것인지가 바뀌고 있다.

지금 흔들리는 것은 도구 하나가 아니라 개발이라는 일의 패러다임 자체다.

예전 패러다임에서는 좋은 개발자가 직접 코드를 잘 쳐서 문제를 해결했다. 새 패러다임에서는 AI가 코드를 만들고, 사람은 문제를 정의하고, 맥락을 주고, 실행 환경을 설계하고, 결과물을 검증한다.

그래서 이 변화는 “코딩 속도가 빨라졌다”에서 끝나지 않는다. 무엇을 공부해야 하는지, 어떤 사람을 개발자로 뽑아야 하는지, 어떤 교육이 쓸모 있는지까지 같이 흔든다.

업계도 이미 같은 방향을 보고 있다

바이브 코딩

바이브 코딩은 대충 “AI에게 자연어로 의도를 던지고, 코드는 거의 보지 않거나 필요한 만큼만 보면서, 실행 결과를 보고 다시 말로 고치는 개발 방식”에 가깝다.

안드레 카파시가 이 말을 던졌을 때 핵심도 사람이 코드와 직접 붙어 씨름하는 시간이 줄고, 자연어로 의도를 던진 뒤 모델이 구현을 밀어붙이는 감각이었다.¹

카파시의 Software 3.0 논의도 같은 방향이다. 자연어가 새로운 프로그래밍 인터페이스가 되고, 모델이 상당 부분을 구현한다는 것이다.²³

거물들도 같은 말을 한다

이건 카파시 혼자 튀는 말을 한 게 아니다.

• 엔비디아 CEO 젠슨 황은 인간 언어 자체가 새 프로그래밍 언어가 됐다고 말했고, AI와 대화하며 결과물을 고치는 방식을 “사람을 프로그래밍하는 것”에 비유했다.⁴
• 메타 CEO 마크 저커버그는 2025년에 메타와 다른 회사들이 중급 엔지니어 수준으로 코드를 쓰는 AI를 갖게 될 것이라고 말했다.⁵
• Anthropic CEO 다리오 아모데이는 AI가 곧 90%의 코드를 쓰고, 더 지나면 사실상 거의 모든 코드를 쓸 수 있다는 식으로 더 세게 예측했다.⁶
• 마이크로소프트 CEO 사티아 나델라는 SaaS의 비즈니스 로직이 AI 에이전트 계층으로 넘어가면 기존 비즈니스 앱의 존재 방식 자체가 흔들릴 수 있다고 봤다.⁷
• GitHub CEO 토마스 돔케는 개발자의 역할이 코드 작성에서 위임과 검증으로 이동하고 있으며, 미래의 개발자는 코드 타이피스트가 아니라 코드의 크리에이티브 디렉터에 가깝다고 정리했다.⁸
• OpenAI CEO 샘 올트먼이 말한 1인 유니콘 가능성도 같은 축에 있다. AI가 노동과 조직 규모의 제약을 낮추면, 한 사람이 훨씬 큰 범위의 제품과 회사를 굴릴 수 있다는 뜻이다.⁹
• 마이크로소프트 공동창업자 빌 게이츠 역시 AI가 개발자를 최소 두 배 이상 효율적으로 만들고, 코딩 비용을 낮추며, 소프트웨어 개발 수요 자체를 흔들 것이라고 봤다.¹⁰
• Stability AI 창업자 이마드 모스타크의 “5년 안에 인간 프로그래머가 사라질 수 있다”는 식의 발언은 과격하지만, 적어도 이 흐름이 업계 가장자리의 농담이 아니라는 신호로는 충분하다.¹¹

코딩 모델에서 엔지니어링 에이전트로

OpenAI도 이미 Codex를 ‘코딩 모델’이 아니라 ‘소프트웨어 엔지니어링 에이전트’로 밀고 있다.

Codex는 기능 작성, 버그 수정, 테스트 실행, PR 제안까지 맡는 방향으로 소개되었고,¹² GPT-5.2-Codex는 장기 작업, 리팩터링, 마이그레이션, 터미널 환경에서의 에이전트 작업을 강조한다.¹³

코딩 문법 공부의 시대는 끝났다

기초는 여전히 검증의 토대다

물론 이런 시대에도 기초를 배우는 일은 의미가 있다.

C언어와 어셈블리어를 배우면 컴퓨터가 어떻게 움직이는지 감이 생기고, 자료구조와 네트워크와 운영체제를 알면 AI가 뽑아낸 결과물을 더 잘 판단할 수 있다.

빌 게이츠도 개발 효율이 올라가면 코딩 수요가 오히려 늘 수 있다고 봤고,¹⁰ 돔케 역시 기초는 여전히 검증 능력의 토대라고 했다.⁸

그러니 “아무것도 몰라도 된다”는 말은 아니다.

문법 암기만으로는 부족하다

하지만 이런 시대에도 “코딩 문법을 익히면 취업한다”는 식의 코딩 강의가 아직도 성행하는 것은 참 슬픈 일이다. 교육은 이미 시대를 완전히 놓쳐 도태된 안타까운 사람들을 양성할 뿐이다.

AI가 이미 중급/고급 엔지니어 수준의 작업과 장기 코딩 에이전트 작업을 향해 가고 있기 때문이다.⁵¹³¹⁴

우리는 AI가 만든 구현물을 보고 말할 수 있어야 한다.

• “이건 방향이 틀렸다.”
• “여기서 사용자 흐름이 깨진다.”
• “이 구조는 나중에 유지보수에서 터진다.”
• “지금 필요한 건 기능 추가가 아니라 문제 정의다.”

바이브코딩은 시작점일 뿐이다

코드는 나오는데 제품은 아직 아니다

작은 프로토타입을 만들 때는 바이브코딩이 거의 마법처럼 느껴진다. 대충 원하는 걸 말하면 화면이 생기고, API가 붙고, 데이터가 흐르고, 버튼이 움직인다.

예전 같으면 며칠 걸릴 일을 몇 시간 안에 밀어붙일 수 있다.

문제는 그 다음이다. 앱이 조금만 커지면 “그럴싸하게 돌아가는 코드”와 “계속 고쳐가며 운영할 수 있는 구조”는 완전히 달라진다.

• 요구사항이 중간에 바뀐다.
• 예외 케이스가 튀어나온다.
• 권한과 데이터 흐름이 꼬인다.
• UI는 움직이는데 제품 의도와 어긋난다.
• 테스트는 없고, 수정할수록 다른 데가 터진다.
• AI가 방금 만든 구조를 다음 턴에서 스스로 잊어버린다.

컨텍스트와 권한이 없으면 사고가 난다

더 위험한 건 AI가 룰을 놓쳤을 때다.

지시 파일에 “절대 하지 말라”고 써둔 일을 세션이 길어지면서 놓치거나, 사용자가 대충 “정리해줘”, “고쳐줘”, “다 밀어줘”라고 던진 말을 너무 넓게 해석하면 진짜 사고가 난다.

• 개발 DB인 줄 알고 운영 DB를 날린다.
• 테스트 계정만 지우려다가 실제 유저 데이터를 삭제한다.
• 마이그레이션을 되돌린다며 백업 없는 destructive query를 실행한다.
• 권한 정책을 단순화한다며 private 데이터를 public으로 열어버린다.
• 빌드 에러를 없애겠다고 검증 코드를 지우거나 타입을 any로 덮는다.
• “안 쓰는 파일 정리”라는 말 하나로 사용자 작성 초안, 번역, 설정 파일까지 같이 지운다.
• 배포를 빠르게 하겠다고 실패한 체크를 우회하고, 나중에야 서비스가 깨진 걸 안다.

이런 예시는 과장이 아니다. AI가 악해서가 아니라, 컨텍스트와 권한과 검증이 허술하면 이런 방향으로 미끄러지기 쉽다는 뜻이다.

이 지점에서 바이브코딩은 한계를 드러낸다.

그냥 “느낌대로 만들어줘”만 반복하면 AI는 계속 뭔가를 만들기는 한다. 하지만 그 결과물이 지금 제품의 맥락에 맞는지, 유지보수 가능한지, 사용자가 실제로 원하는 흐름인지까지 책임지지는 않는다.

더구나 컴퓨터 지식이 거의 없는 비개발자가 이걸 함부로 만지면, 초반에는 “와, 된다” 싶다가 결국 컨텍스트 한계에 부딪힌다.

뭐가 위험한 명령인지, 어떤 파일이 소스 오브 트루스인지, DB와 스토리지와 인증과 배포가 어떻게 이어져 있는지 모르면 AI의 결과물을 검수할 수가 없다.

피드백은 감정 배설이 아니라 조준이다

여담이지만 물론, 가끔은 “아니, 내가 말한 게 그거냐 이 XX아”가 먼저 튀어나오기도 한다. 하지만, 그걸 그대로 던지는 건 나한테도 별로 좋지 않다.

욕한다고 항상 모델 성능이 떨어진다고 단정할 근거는 없지만, 프롬프트의 톤과 감정 프레이밍이 출력에 영향을 준다는 연구는 있다.¹⁵¹⁶¹⁷

그리고 결국 가장 큰 문제는 AI의 기분이 아니라 내 이성이다. 욕을 계속 던지면 내가 더 감정적으로 되고, 지시사항은 더 흐려지고, 스트레스만 쌓인다.

진짜 한계는 구현보다 맥락이다

Anthropic의 장기 에이전트 글이 말하는 것도 이 지점이다. 단순한 고수준 프롬프트만으로는 production-quality 앱까지 가기 어렵고, 작업 분해와 지속 메모리, 컨텍스트 관리, 검증 루프가 필요하다.¹⁴

Reddit에서도 비슷한 불안이 나온다. AI가 코드를 너무 빠르게 만들면, 오히려 사람이 검토하고 품질을 관리하는 쪽이 병목이 된다.¹⁸

결국 바이브코딩의 진짜 한계는 코드를 못 만든다는 데 있지 않다. 코드는 만든다. 너무 잘 만든다.

한계는 그 코드가 무엇을 위해 존재하는지, 어디까지 고쳐도 되는지, 어떤 기준을 통과해야 하는지, 어떤 맥락을 깨면 안 되는지를 AI 혼자 안정적으로 붙들기 어렵다는 데 있다.

그래서 기업들이 바이브코딩의 한계를 하네스로 잡으려는 것이다.

그래서 하네스가 본게임이다

하네스는 모델 주변의 실행 구조다

하네스는 원래 마구, 안전벨트, 동물에게 채우는 줄처럼 힘 있는 대상을 붙잡아 원하는 방향으로 쓰기 위한 장치를 뜻한다.

프롬프트 엔지니어링은 한 번의 대화에서 무엇을 어떻게 말할 것인가에 가깝다. 하지만 하네스 엔지니어링은 모델 주변의 실행 환경 전체를 설계하는 일이다.

LangChain은 에이전트를 “Model + Harness”로 설명하면서, 하네스가 상태, 도구 실행, 피드백 루프, 강제 가능한 제약을 제공한다고 정리한다.¹⁹

마틴 파울러의 글도 비슷하다. 코딩 에이전트를 덜 감시하고 쓰려면, 에이전트가 처음부터 더 잘하도록 feedforward를 주고, 잘못된 결과를 스스로 고치도록 feedback sensor를 붙여야 한다는 것이다.²⁰

OpenAI의 Codex 하네스 글에서도 병목은 코드 생산이 아니라 사람이 검수할 수 있는 용량이었다. 그래서 로그, 메트릭, 브라우저 조작, 구조적 테스트 같은 것들을 에이전트가 직접 볼 수 있게 만들었다.²¹

이처럼 이제 중요한 건 “어느 모델이 코드를 더 잘 짜느냐”만이 아니다.

• 어떤 컨텍스트를 줄 것인가.
• 어떤 도구를 열어줄 것인가.
• 어떤 권한은 막을 것인가.
• 어떤 테스트를 반드시 통과하게 할 것인가.
• 어떤 리뷰 에이전트를 붙일 것인가.
• 어디서 인간이 개입할 것인가.

이게 경쟁력이 된다.

하네스 구조가 곧 경쟁력이다

최근 사건들도 같은 방향을 가리킨다.

Claude Code 소스 코드 유출 사태가 그렇게 시끄러웠던 이유도 여기에 있다.

분석 글들을 보면 유출된 것은 단순한 프롬프트 한 줄이 아니었다.

Claude Code가 컨텍스트를 어떻게 조립하고, 도구와 가드레일을 어떻게 엮고, 사용자 지시와 시스템 지시를 어떤 구조로 다루는지에 가까웠다.²²²³²⁴

그저 모델 성능만 중요한 시대라면 이런 유출은 그냥 소소한 구경거리였을 것이다. 하지만 저 유출 사태는 개발 업계에서 꽤 큰 이슈가 됐다. 이제는 하네스 구조가 제품 경쟁력이다.

여담이지만, 물론 그 사태가 있었다고 Claude Code가 갑자기 망한 것도 아니다. 여전히 잘한다. 오히려 역설적으로, 사람들이 그 내부 구조를 보고 “아, 이렇게 정교하게 구성해놔서 Claude Code가 가장 잘했구나”를 확인한 면도 있었다.

위험한 모델일수록 더 강한 하네스가 필요하다

Mythos와 Project Glasswing은 같은 흐름을 보안 쪽에서 더 세게 보여준다.

Mythos는 Anthropic이 만든 미공개 프런티어 모델이다. 그냥 코딩 잘하는 챗봇이 아니라, 소프트웨어 취약점을 찾고 그 취약점을 실제 공격으로 이어지게 만드는 exploit, 즉 공격 코드까지 구성하는 능력이 인간 최고 전문가급에 가까워진 모델이다. Anthropic은 Claude Mythos Preview가 주요 운영체제와 브라우저에서 수천 개의 고위험 취약점을 찾았다고 설명했다.²⁵

Project Glasswing은 그런 고성능 모델을 그냥 세상에 풀어버렸을 때 생길 수 있는 파장을 막기 위한 방어 프로젝트에 가깝다. Anthropic은 Mythos급 모델이 공격자 손에 퍼지면 경제, 공공 안전, 국가 안보에 심각한 후폭풍이 올 수 있다고 봤고, 그래서 AWS, Apple, Google, Microsoft, NVIDIA, CrowdStrike, Palo Alto Networks 같은 파트너에게 접근을 제한적으로 열어 중요한 소프트웨어를 방어 목적으로 먼저 스캔하게 했다.²⁵

그러니까 핵심은 “강한 보안 모델 나왔다”가 아니다. 너무 강해서 오히려 아무 데나 풀 수 없으니, 접근 권한, 대상 코드베이스, 결과 공개, 패치 검증, 악용 가능성 차단까지 전부 구조로 묶어야 했다는 점이다.

더 무서운 건 발견이 아니라 속도다.

Axios는 Mythos가 공개된 취약점 정보를 바탕으로 몇 시간 안에 작동하는 공격 코드를 만들 수 있고, Windows 커널 취약점에 대해서는 31분 만에 proof-of-concept exploit을 만들었다고 보도했다.²⁶

Cloudflare도 Project Glasswing으로 Mythos를 실제 코드베이스에 돌려보며, 단일 버그 탐지가 아니라 여러 취약점을 연결해 실제 공격 경로, 즉 exploit chain을 구성하는 능력이 이전 모델과 다르다고 적었다.²⁷

그러니까 이건 벤치마크 자랑이 아니다. 취약점을 찾는 비용과 시간이 박살나면 보안 산업의 전제도 같이 흔들린다.

Project Glasswing은 이후 약 150개 신규 조직으로 확대됐다. 전력, 수도, 의료, 통신, 하드웨어처럼 공격이 터지면 파장이 큰 분야도 포함됐다.²⁸

그 과정에서 Project Glasswing에 들어간 대형 보안사는 유리한 위치를 잡고, 그렇지 못한 취약점 관리/분석 업체들은 시장에서 압박을 받는다는 분석도 나왔다.²⁹

이 정도 능력을 가진 모델을 그냥 일반 유저들에게 풀어버리면 대참사가 일어날 수 있다.

누가 접근할 수 있는지, 어떤 코드베이스를 스캔할 수 있는지, 어떤 결과를 공개할지, 어떤 패치를 누가 검증할지, 공격 코드 생성은 어디서 막을지까지 전부 강력한 하네스 구조로 묶어야 한다.

이것이 바로 모델 성능이 올라갈수록 하네스가 더 중요해지는 이유다.

약한 하네스는 모델을 붙잡지 못한다

내가 AI Studio류의 하네스가 답답하게 느껴지는 지점도 여기에 있다.

물론 AI Studio가 무조건 쓰레기라는 말은 아니다. Google도 AI Studio Build mode를 빠르게 앱을 만들고, Gemini 기능을 시험하고, 자연어로 프로토타입을 뽑는 도구로 설명한다.³⁰ 그 용도라면 충분히 쓸모가 있다.

다만 운영 가능한 소프트웨어를 계속 고쳐가며 굴리는 하네스는 다른 문제다. 실제 개발 하네스라면 repo, 터미널, IDE, diff, 테스트, 리뷰, 배포 로그, 권한 경계까지 붙어야 한다. Google이 AI Studio와 별도로 Gemini CLI, Gemini Code Assist 같은 터미널/IDE 기반 도구를 따로 밀고 있는 것도 결국 그 지점과 맞닿아 있다.³¹³²

채팅창과 실행 버튼과 모델 선택지는 있는데, 정작 작업 범위, 권한 경계, 롤백, 테스트, 리뷰, 소스 오브 트루스, 장기 컨텍스트 관리가 제대로 붙어 있지 않으면 좋은 개발 하네스라고 보기 어렵다.

모델이 아무리 좋아도, 그 모델에 채우는 목줄이 부실하면 결국 모델이 목줄 끊어버리고 폭주하는 건 당연지사이다.

사람은 기획/설계/실행/피드백을 맡는다

결국 핵심은 “AI 딸깍”이 아니다. 얼마나 정교한 시스템을 기획하고, 설계하고, 실행시키고, 피드백하느냐가 중요하다.

그러면 사람에게 남는 능력은 코드를 직접 많이 치는 능력이 아니다. 무엇을 만들지 기획하고, AI가 움직일 판을 설계하고, 실제로 굴려서 실행시키고, 나온 결과물에 피드백을 걸어 다시 방향을 잡는 능력이다.

그리고 이 피드백을 제대로 하려면 전체 맥락을 파악할 수 있는 개념과 도메인 지식, 그리고 결과물의 이상함을 빠르게 감지하는 직관력이 있어야 한다.

제품이 무엇을 하려는지, 사용자가 어디서 막히는지, 데이터가 어떻게 흐르는지, 권한과 배포와 유지보수에서 무엇이 위험한지 알아야 한다.

손으로 구현하는 능력은 중심에서 밀려난다. 대신 구현을 지휘하고, 검수하고, 방향을 다시 잡는 능력이 중심으로 온다.

바이브코딩은 입구다. 느낌으로 시작할 수는 있다. 하지만 제대로 굴리려면 결국 구조로 붙잡아야 한다.

결국 파도를 타는 수밖에

여기서 바로 “그러니 다함께 쓰나미급 AI 파도에 올라타자”로 끝내면 확실히 비약이다. 온갖 두려운 문제점들을 다 건너뛰고 갑자기 낙관으로 포장하는 꼴이 된다.

내가 말하려는 것은 “AI 시대가 왔으니 신난다”가 아니다. 코딩 손기술의 가치가 내려가고, AI가 구현을 가져가고, 사람에게는 기획/설계/실행/피드백의 책임이 더 크게 남는 흐름은 싫다고 멈출 수 있는 게 아니라는 말이다.

선택지는 대충 둘이다.

• 예전 방식의 코딩 공부와 문법 암기에 집중하여 도태되거나,
• 아니면 AI에게 코딩을 전담시키고, 내가 직접 프롬프트를 다듬고 더 나아가 하네스를 설계하면서 AI 리터러시를 키워나가서 살아남거나.

나는 이제 후자밖에 답이 없다고 확신한다.

물론, 파도를 타겠다는 말은 마냥 즐겁다는 뜻만은 아니다. 밀려오는 쓰나미같은 거대한 파도에 무방비로 휩쓸리지 않으려면, 오히려 먼저 올라타서 방향을 잡고 자세를 유지할 줄 알아야 한다는 말에 가깝다.

지금으로서는 도저히 예측하지 못할 대혼돈의 시대가 너무나도 자명하게 예견되지만, 어쩌겠나. 이 거대한 쓰나미에 휩쓸리지 않으려면 그저 파도를 타며 버티고, 가능하면 즐길 수밖에.

참고 자료

1. 안드레 카파시, X 게시글, 2025-02-02. 자연어로 의도를 던지고 코드 자체를 거의 보지 않는 새 코딩 방식을 설명했다. https://x.com/karpathy/status/1886192184808149383 ↩

2. Y Combinator의 카파시 강연, 2025. Software 3.0, 자연어 인터페이스, 모델 기반 구현 흐름을 설명한다. https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again ↩

3. TechRadar Pro, 2026-05. Software 3.0 흐름을 개발자의 역할 변화, 검증, 오케스트레이션 문제와 연결한다. https://www.techradar.com/pro/software-3-0-is-speeding-up-coding-but-delivery-is-a-different-story ↩

4. Business Insider의 젠슨 황 인터뷰 보도, 2025-06-09. 인간 언어가 새 프로그래밍 언어가 됐고, AI가 기술 접근성을 평준화한다는 발언을 다룬다. https://www.businessinsider.com/nvidia-ceo-jensen-huang-ai-prompts-human-lets-anyone-program-2025-6 ↩

5. ITPro의 저커버그 인터뷰 발언 보도, 2025-01-14. 메타가 중급 엔지니어 수준의 코드 작성 AI를 예상했다고 정리한다. https://www.itpro.com/software/development/a-sign-of-things-to-come-in-software-development-mark-zuckerberg-says-ai-will-be-doing-the-work-of-mid-level-engineers-this-year-and-hes-not-the-only-big-tech-exec-predicting-the-end-of-the-profession ↩ ↩²

6. Skeptics Stack Exchange, 2025-09. Business Insider가 보도한 다리오 아모데이의 2025년 예측을 인용하고, 90% 코드 작성 주장의 정의와 검증 문제를 함께 다룬다. https://skeptics.stackexchange.com/questions/59213/as-at-september-2025-is-ai-not-writing-90-of-code ↩

7. CX Today의 사티아 나델라 인터뷰 정리, 2024-12-23. 에이전트 AI 시대에 비즈니스 로직이 AI 계층으로 이동하며 기존 SaaS 구조가 흔들릴 수 있다고 본다. https://www.cxtoday.com/customer-analytics-intelligence/microsoft-ceo-ai-agents-will-transform-saas-as-we-know-it/ ↩

8. 토마스 돔케·이리니 칼리아바쿠, “Developers, Reinvented”, 2025-08-03. AI를 쓰는 개발자 인터뷰를 바탕으로 역할이 코드 작성에서 위임, 검증, 제품 이해, 시스템 설계로 이동한다고 정리한다. https://ashtom.github.io/developers-reinvented ↩ ↩²

9. Fortune의 올트먼 발언 보도, 2024-02-04. AI 덕분에 직원 없는 1인 10억 달러 기업이 가능해질 시점을 두고 이야기했다고 보도됐다. https://fortune.com/2024/02/04/sam-altman-one-person-unicorn-silicon-valley-founder-myth/ ↩

10. 빌 게이츠, GatesNotes, 2026. AI가 개발자를 최소 두 배 이상 효율적으로 만들고 코딩 비용 하락과 노동시장 변화를 일으킬 수 있다고 설명한다. https://www.gatesnotes.com/meet-bill/tech-thinking/reader/ai-agents ↩ ↩²

11. 피터 디아만디스, 2024-02-08. 이마드 모스타크가 “5년 안에 인간 코더가 사라질 수 있다”는 취지의 발언을 했다고 소개하고, AI 코딩 자동화의 근거들을 함께 검토한다. https://www.diamandis.com/blog/abundance-37-no-human-coders ↩

12. OpenAI, “Codex is now generally available”, 2025-10-06. Codex가 연구 프리뷰에서 더 신뢰도 높은 코딩 협업자로 발전했고, 터미널/IDE/클라우드에서 작동한다고 설명한다. https://openai.com/index/codex-now-generally-available/ ↩

13. OpenAI, “Introducing GPT-5.2-Codex”, 2025-12. 장기 작업, 리팩터링, 마이그레이션, 터미널 벤치마크, 에이전트 코딩 성능을 강조한다. https://openai.com/index/introducing-gpt-5-2-codex/ ↩ ↩²

14. Anthropic, “Effective harnesses for long-running agents”, 2025-11. 장기 작업 에이전트가 단순 고수준 프롬프트만으로는 부족하며, 작업 분해와 지속 메모리, 검증 루프가 필요하다는 실험을 다룬다. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents ↩ ↩²

15. Ziqi Yin 외, “Should We Respect LLMs? A Cross-Lingual Study on the Influence of Prompt Politeness on LLM Performance”, arXiv, 2024-02-22. 무례한 프롬프트가 성능 저하와 연결되는 경우가 있지만, 과도한 공손함이 항상 더 좋은 결과를 내지는 않고 언어·모델별 차이가 있다고 분석한다. https://arxiv.org/abs/2402.14531 ↩

16. Om Dobariya·Akhil Kumar, “Mind Your Tone: Investigating How Prompt Politeness Affects LLM Accuracy”, arXiv, 2025-10-06. ChatGPT-4o 객관식 실험에서 무례한 톤이 더 높은 정확도를 보인 사례를 보고하지만, 단일 모델과 제한된 문항 수의 단기 연구라 일반화에는 주의가 필요하다. https://arxiv.org/abs/2510.04950 ↩

17. Cheng Li 외, “Large Language Models Understand and Can be Enhanced by Emotional Stimuli”, arXiv, 2023-07-14. 감정적 중요도나 동기 프레이밍을 덧붙인 EmotionPrompt가 여러 과제에서 성능을 개선할 수 있음을 보였다. https://arxiv.org/abs/2307.11760 ↩

18. Reddit r/LocalLLaMA, “How do you manage quality when AI agents write code faster than humans can review it?”, 2026. AI가 코드 생산 속도를 높일수록 리뷰와 검증이 병목이 된다는 실무자들의 문제의식. https://www.reddit.com/r/LocalLLaMA/comments/1q7hywi/how_do_you_manage_quality_when_ai_agents_write/ ↩

19. LangChain, “The Anatomy of an Agent Harness”, 2026. 에이전트를 Model + Harness로 정의하고, 하네스가 상태, 도구 실행, 피드백 루프, 제약을 제공한다고 설명한다. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness ↩

20. 마틴 파울러, “Harness engineering for coding agent users”, 2026-04-02. 코딩 에이전트를 신뢰하기 위해 feedforward와 feedback sensor를 갖춘 사용자 하네스가 필요하다고 설명한다. https://martinfowler.com/articles/harness-engineering.html ↩

21. 라이언 로포폴로, “Harness engineering: leveraging Codex in an agent-first world”, OpenAI, 2026-02-11. OpenAI 내부 팀이 수동 작성 코드 없이 Codex로 제품을 만들며, 인간의 일이 코드 작성에서 환경 설계·의도 명세·피드백 루프로 이동했다고 설명한다. https://openai.com/index/harness-engineering/ ↩

22. Varonis Threat Labs, “A Look Inside Claude’s Leaked AI Coding Agent”, 2026-04-03. Claude Code npm 패키지에 포함된 .map 파일로 소스가 노출됐고, 아키텍처·도구·가드레일·권한 구조가 드러났다고 분석한다. https://www.varonis.com/blog/claude-code-leak ↩

23. Engineer’s Codex, “Diving into Claude Code’s Source Code Leak”, 2026-04-01. 2026년 3월 31일 Claude Code npm 업데이트에 sourcemap이 포함되어 코드가 확산됐고, Anthropic 엔지니어가 개발자 실수였다고 확인했다는 내용을 정리한다. https://read.engineerscodex.com/p/diving-into-claude-codes-source-code ↩

24. Drew Breunig, “How Claude Code Builds a System Prompt”, 2026-04-04. Claude Code가 정적 시스템 프롬프트 하나가 아니라 조건부 구성요소, 도구 정의, 사용자/시스템 컨텍스트를 조립해 풍부한 실행 컨텍스트를 만든다고 분석한다. https://www.dbreunig.com/2026/04/04/how-claude-code-builds-a-system-prompt.html ↩

25. Anthropic, “Project Glasswing: Securing critical software for the AI era”, 2026-04-07. Claude Mythos Preview가 주요 운영체제와 웹브라우저를 포함한 핵심 소프트웨어에서 수천 개의 고위험 취약점을 찾았고, 이런 능력이 무분별하게 확산될 경우 경제·공공 안전·국가 안보에 심각한 후폭풍이 생길 수 있어 제한적 방어 프로젝트로 운영된다고 설명한다. https://www.anthropic.com/glasswing ↩ ↩²

26. Axios, “Anthropic: Mythos AI rapidly exploits new software flaws”, 2026-06-08. Mythos가 공개된 취약점을 몇 시간 안에 exploit, 즉 실제 공격 코드로 전환할 수 있고, Windows 커널 취약점 proof-of-concept를 31분 만에 만들었다고 보도한다. https://www.axios.com/2026/06/08/exclusive-anthropics-mythos-can-exploit-new-flaws-in-hours ↩

27. Cloudflare, “Project Glasswing: what Mythos showed us”, 2026. Cloudflare가 Project Glasswing에서 Mythos를 실제 코드베이스에 적용하며, 여러 취약점을 연결한 공격 경로 구성과 proof generation 능력, 그리고 이를 대규모로 쓰기 위한 하네스 문제를 정리한다. https://blog.cloudflare.com/cyber-frontier-models/ ↩

28. Anthropic, “Expanding Project Glasswing”, 2026-06-02. 초기 약 50개 파트너에서 15개국 150개 안팎의 핵심 인프라 조직으로 확장하며, Mythos급 모델이 보안의 기본 전제를 바꿀 수 있다고 설명한다. https://www.anthropic.com/news/expanding-project-glasswing ↩

29. BankInfoSecurity, “Claude Mythos Preview Creates Early Edge for Cyber Titans”, 2026-04-09. Project Glasswing 참여 기업과 비참여 보안 업체 사이의 격차, 취약점 관리 업체 주가 하락, 대형 보안사의 선점 효과를 분석한다. https://www.bankinfosecurity.com/claude-mythos-preview-creates-early-edge-for-cyber-titans-a-31381 ↩

30. Google AI for Developers, “Build apps in Google AI Studio”, 2026. AI Studio Build mode를 최신 Gemini 기능을 시험하는 앱을 빠르게 만들고 배포하는 도구로 설명하며, 자연어 프롬프트로 웹 앱과 Android 앱을 만드는 흐름을 안내한다. https://ai.google.dev/gemini-api/docs/aistudio-build-mode ↩

31. Google, “Gemini CLI: your open-source AI agent”, 2025-06-25. Gemini CLI를 터미널에서 코딩, 문제 해결, 작업 관리를 수행하는 오픈소스 AI 에이전트로 소개한다. https://blog.google/innovation-and-ai/technology/developers-tools/introducing-gemini-cli-open-source-ai-agent/ ↩

32. Google for Developers, “Code with Gemini Code Assist”, 2026. Gemini Code Assist가 VS Code와 JetBrains IDE에서 코드 생성, diff 기반 코드 변환, 코드 완성, 저장소 컨텍스트 활용을 제공한다고 설명한다. https://developers.google.com/gemini-code-assist/docs/write-code-gemini ↩