일하는 ai

✍️ 11. 코드는 죽지 않았다

19 min read

-

요즘 가장 그럴듯하게 들리는 문장 중 하나는 이것이다. “이제 코딩은 끝났다.” 말 몇 마디면 화면이 나오고, 앱이 뜨고, 기능이 붙는 시대에 이 문장은 너무 쉽게 상식이 된다. 하지만 실제 현장으로 한 발만 더 들어가 보면, 사라지는 것은 코드가 아니라 손으로 한 줄씩 타이핑하던 노동의 비중에 가깝다. 오히려 남는 것은 더 까다롭다. 무엇을 정확히 만들고 싶은지, 어디까지 추상화하고 어디서 현실의 거친 면을 드러내야 하는지 끝까지 붙드는 감각이다.

AI 활용 고지: 이 글은 생성형 AI를 활용해 구조를 정리하고 초안을 확장한 뒤, 원문과 참고 링크를 다시 확인하며 표현과 해석을 다듬어 완성했습니다.

원문 링크

flowchart LR
A[말로 빠르게 만든다] --> B[처음엔 잘 되는 것처럼 보인다]
B --> C[기능 증가 · 사용자 증가]
C --> D[복잡성이 새어 나온다]
D --> E[버그 · 예외 · 운영비용 증가]
E --> F[더 좋은 추상화 필요]
F --> G[좋은 코드는 더 중요해진다]

처음엔 정말 다 끝난 것처럼 보인다

처음 AI 코딩 도구를 써보면 누구나 비슷한 감정을 느낀다. 마치 생각이 곧바로 현실이 된 것 같은 기분이다. “로그인 화면 하나 만들어줘.” “버튼을 조금 더 파랗게.” “이 페이지를 대시보드처럼 바꿔줘.” 예전 같으면 반나절 걸릴 것도 몇 분 안에 형태가 잡힌다. 그러면 자연스럽게 이런 생각이 따라온다.

정말로, 이제 코드는 덜 중요해진 걸까?

이 질문이 위험한 이유는, 초반 체감이 너무 강력해서다. 작은 기능, 짧은 흐름, 적은 사용자, 적당한 복잡성. 이 구간에서는 AI가 만들어 준 결과물이 놀라울 정도로 잘 먹힌다. 사람은 이 성공 경험을 전체 미래로 일반화하고 싶어진다. “이 정도면 나머지도 다 되겠는데?”라는 자신감이 붙는다.

그런데 소프트웨어 세계는 늘 같은 방식으로 복수한다. 처음엔 편하게 해주고, 나중에 몰아서 계산서를 보낸다.

바이브는 방향을 주지만, 경계선을 그어주지는 않는다

Steve Krouse 글의 핵심은 여기 있다. AI는 자연어를 빠르게 작동하는 결과물로 바꿔주기 때문에, 우리는 오랫동안 내가 말한 것이 충분히 정밀하다고 착각하기 쉽다. 바이브 코딩이 강력한 이유도 바로 그것이다. 사람은 여전히 영어와 한국어 수준의 감각으로 일하고, AI는 그 감각을 화면과 코드로 번역해준다.

문제는 바이브가 어디까지나 분위기라는 점이다. 분위기는 방향은 알려줘도, 경계 조건까지 못 박아주지는 않는다.

예를 들어 “실시간 협업 문서 편집기”라는 요구는 너무 익숙해서 정밀해 보인다. 우리는 구글 독스도 써봤고, 노션도 써봤다. 그래서 이 문장을 듣는 순간 이미 머릿속엔 완성된 제품이 떠오른다. 하지만 구현 단계로 내려가면 질문이 갑자기 폭증한다.

  • 두 사람이 동시에 같은 줄을 고치면 무엇이 먼저 보일까?
  • 네트워크가 흔들릴 때 커서는 어디에 있어야 할까?
  • 오프라인에서 수정한 내용은 언제, 어떤 규칙으로 합쳐질까?
  • 알림은 지금 보내야 할까, 편집이 끝난 뒤 보내야 할까?
  • 충돌이 났을 때 사용자에게 보여줄 최소 단위는 무엇일까?

불과 몇 초 전까지만 해도 “실시간 협업”은 아주 정확한 말처럼 보였다. 하지만 실제 세계에서는 그 말 하나가 수십 개의 결정과 수백 개의 예외를 품고 있다.

Dan Shipper가 바이브 코딩으로 만든 앱이 바이럴된 뒤 장애를 겪은 경험담도 같은 지점을 보여준다. 빠르게 만드는 것은 가능하다. 하지만 사용자가 몰리고 실제 운영이 시작되는 순간, 추상화 아래 숨어 있던 현실이 모습을 드러낸다. 그때 필요한 건 더 많은 분위기가 아니라, 더 구체적인 모델과 더 좋은 구조다.

복잡성은 사라지지 않는다. 다만 늦게 나타날 뿐이다

많은 사람이 AI 시대를 오해하는 이유는, 복잡성이 사라질 거라고 기대하기 때문이다. 사실 복잡성은 사라지지 않는다. 잠시 보이지 않을 뿐이다.

이걸 건축 비유로 바꾸면 이해가 쉽다. AI는 마치 실내 인테리어를 번개처럼 해주는 팀 같다. 벽지 색, 조명 느낌, 가구 배치, 출입 동선까지 엄청 빠르게 제안한다. 그런데 건물의 하중 계산, 배수 설계, 화재 시 피난 동선까지 자동으로 해결해 주는 건 아니다. 겉은 빠르게 완성되지만, 구조는 여전히 구조의 언어로 다뤄야 한다.

소프트웨어도 비슷하다. 화면은 빨리 나온다. 데모는 금방 된다. 그런데 운영은 다른 이야기다.

미니 사례 A: 혼자 쓰는 자동화와 여러 사람이 쓰는 제품은 다르다

혼자 쓰는 개인 자동화 도구는 바이브 코딩만으로도 꽤 오래 잘 굴러갈 수 있다. 실패해도 내가 다시 고치면 되고, 데이터 규모도 작고, 책임 범위도 좁다. 반면 여러 사람이 동시에 쓰는 제품은 다르다. 로그인, 권한, 알림, 복구, 성능, 관측, 장애 대응이 모두 따라붙는다. 전자는 “되면 좋다”의 세계이고, 후자는 “언제나 되어야 한다”의 세계다.

미니 사례 B: 초안 속도와 최종 품질은 다른 지표다

AI 도구 덕분에 초안 속도는 크게 오른다. 하지만 그 결과물의 신뢰성까지 자동으로 오르지는 않는다. Simon Willison이 지적했듯, 더 나쁜 코드를 더 빨리 내보내는 것도 가능하고, 더 좋은 코드를 더 낮은 비용으로 다듬는 것도 가능하다. 차이는 도구가 아니라 운영 선택에서 나온다. 즉, AI는 품질을 자동으로 보장하지 않는다. 대신 품질을 올리기 위한 반복 작업의 비용을 극적으로 낮춰준다.

🧠 칠판 치트시트

  • AI는 모호한 요구를 빠르게 형태로 만든다.
  • 하지만 형태가 곧 정밀함은 아니다.
  • 규모가 커질수록 추상화 아래의 예외가 드러난다.
  • 그래서 좋은 코드는 사라지는 게 아니라 더 높은 층위로 이동한다.

좋은 코드는 결과물이 아니라 사고의 압축본이다

“코드는 그냥 결과물을 만들기 위한 수단 아닌가?”라고 묻는다면, 절반만 맞다. 물론 코드는 무언가를 작동시키기 위한 도구다. 하지만 그것만으로는 설명이 부족하다. 잘 짜인 코드는 누군가가 문제를 어떻게 나누어 보았는지, 무엇을 묶고 무엇을 드러냈는지, 어디를 일반화하고 어디를 구체화했는지까지 담고 있다.

그래서 좋은 코드를 읽으면 기능보다 먼저 관점이 보인다. “아, 이 사람은 복잡성을 여기서 끊었구나.” “이 상태 변화는 이 수준에서 다뤄야 한다고 판단했구나.” “예외는 여기서 흡수하고, 밖에는 단순한 인터페이스만 보여주려는구나.” 이런 식의 생각이 코드에 눌러 담긴다.

이 지점에서 코드는 문학과 조금 닮는다. 문장이 많아서 좋은 글이 아니라, 많은 의미를 적은 공간에 정확히 압축해서 좋은 글이 되듯이, 좋은 코드도 많은 줄 수가 아니라 높은 밀도의 판단 때문에 아름답다.

Dijkstra가 말한 핵심도 비슷하다. 형식 언어는 인간을 괴롭히기 위해 존재하는 게 아니라, 말의 세계에서 너무 쉽게 숨어버리는 헛소리를 줄이기 위해 존재한다. 자연어는 편하다. 하지만 편한 만큼 애매하다. 사람끼리는 그 애매함을 맥락으로 메꿀 수 있어도, 시스템은 그렇게 넘어가지 않는다. 시스템은 반드시 어느 한쪽으로 굳는다.

AGI가 와도 없어지지 않는 것

어떤 사람은 이렇게 말한다. “인간 수준, 아니 인간 이상의 AI가 오면 그때는 정말 코드가 필요 없지 않겠냐”고. 얼핏 미래적인 질문처럼 보이지만, 나는 오히려 반대로 본다. 정말로 강력한 AI가 생기면, 사람은 더 허술한 결과물을 대량 생산하는 데 그 능력을 쓰기보다 지금은 너무 복잡해서 엄두 못 내던 문제에 달려들 가능성이 더 크다.

  • 더 자연스러운 협업 도구
  • 더 견고한 개인용 에이전트
  • 더 설명 가능한 자동화 시스템
  • 더 읽기 쉬운 추상화 계층
  • 더 낮은 유지보수 비용을 가진 구조

이런 문제는 지금도 중요하지만, 어렵고 귀찮고 예외가 많아서 종종 뒤로 밀린다. AGI가 와도 이 문제들이 사라지지는 않는다. 오히려 도전 가능한 문제 목록이 확장될 뿐이다. 그러면 그다음 병목은 늘 같다. 어떤 구조가 오래 버티는가, 어떤 추상화가 사람과 기계를 동시에 덜 괴롭히는가.

즉, 미래에 줄어드는 것은 ‘손코딩의 비중’일 수 있어도, 늘어나는 것은 ‘정밀한 설계와 추상화의 가치’일 가능성이 크다.

앞으로 더 비싸지는 사람은 누구일까

나는 AI 시대에 개발자의 가치가 없어질 거라고 보지 않는다. 다만 가치의 중심은 분명 옮겨갈 거라고 본다.

예전에는 “얼마나 빨리 구현하나”가 중요한 경쟁력이었다면, 앞으로는 여기에 몇 가지가 더 붙는다.

  • 모호한 요구를 테스트 가능한 형태로 바꾸는 사람
  • 문제의 핵심 예외를 먼저 발견하는 사람
  • 잘못된 추상화를 빨리 버리고 다시 묶는 사람
  • AI가 만든 초안을 운영 가능한 시스템으로 다듬는 사람
  • 코드와 문서와 검증 루프를 함께 설계하는 사람

쉽게 말해, 타이핑 속도보다 복잡성을 견디는 감각이 더 비싸진다. 버튼을 움직이는 능력보다, 왜 그 버튼이 거기 있어야 하는지 끝까지 묻는 능력이 더 중요해진다. 앱을 뽑아내는 능력보다, 그 앱이 한 달 뒤에도 망가지지 않게 만드는 능력이 더 비싸진다.

그래서 지금 무엇을 배워야 하나

이 글을 “그래도 결국 코딩을 열심히 하자” 정도로 읽으면 조금 아쉽다. 더 정확한 결론은 이렇다.

앞으로 배워야 하는 건 문법만이 아니다.

  1. 요구를 정밀하게 쓰는 법
    • “예쁜 화면”이 아니라 어떤 사용자가 어떤 상황에서 무엇을 해야 하는지까지 적는 힘.
  2. 검증 루프를 설계하는 법
    • 초안 생성 다음에 무엇을 확인하고, 어디서 실패를 잡고, 누가 최종 승인을 하는지 정하는 힘.
  3. 추상화를 바꾸는 법
    • 처음 설계가 틀렸을 때 집착하지 않고, 더 좋은 개념 단위로 다시 묶어내는 힘.
  4. 도구를 운영 체계로 바꾸는 법
    • 모델 하나 잘 쓰는 것에서 끝나지 않고, 문서·테스트·리뷰·관측까지 한 세트로 연결하는 힘.

이 네 가지는 AI가 좋아질수록 더 중요해질 가능성이 크다. 왜냐하면 초안 자체의 희소성은 떨어지지만, 좋은 최종 구조의 희소성은 오히려 더 커질 수 있기 때문이다.

마지막 장면

인쇄기가 나왔다고 이야기가 죽지 않았던 것처럼, AI가 나왔다고 코드가 죽지는 않는다. 오히려 이제부터 코드의 진짜 역할이 더 선명해질 가능성이 크다. 코드는 단순한 명령문 묶음이 아니라, 인간이 복잡성을 붙잡기 위해 만든 가장 정교한 압축 형식 중 하나이기 때문이다.

대충 말해도 뭔가가 나오는 시대가 오면, 사람은 처음엔 환호한다. 그런데 시간이 지나면 결국 같은 질문으로 돌아온다.

“그래서, 이건 정말 어떻게 작동하는가?”

그 질문을 끝까지 붙드는 사람에게는 여전히 코드가 필요하다. 아니, 어쩌면 예전보다 더 필요하다. 단지 예전과 다른 점이 있다면, 이제 코드는 더 이상 손가락의 일이 아니라 사고의 밀도를 드러내는 일이 된다는 것이다.

결국 미래에 오래 남는 사람은 많이 치는 사람이 아니라, 정확히 묻고, 정확히 나누고, 정확히 닫는 사람일 가능성이 크다.

코드는 죽지 않았다. 다만 이제 우리에게 더 높은 수준의 정밀함을 요구하고 있을 뿐이다.

다음 읽기

참고 링크

그래프 뷰

백링크