▲

Vibe coding과 agentic engineering이 내가 원하는 것보다 더 가까워지고 있다

 (simonwillison.net)
1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • vibe coding과 agentic engineering은 원래 코드 검토와 책임성 기준으로 구분됐지만, 코딩 에이전트의 신뢰도가 높아지면서 실제 프로덕션 작업에서 경계가 흐려지고 있음
  • vibe coding은 코드를 거의 보지 않고 원하는 결과가 나오면 받아들이는 방식이라 개인 도구에는 유용할 수 있지만, 다른 사람의 정보와 사용 경험이 걸린 소프트웨어에는 무책임한 방식으로 보임
  • Claude Code 같은 에이전트가 JSON API 엔드포인트, SQL 쿼리, 테스트, 문서화를 반복적으로 잘 처리하면서 생성된 모든 코드 줄을 검토하지 않는 일이 생기고, 이는 사람 팀과 달리 평판이나 책임이 없는 대상에 대한 신뢰라는 위험을 만듦
  • 이제는 커밋 100개, 좋은 README, 전체 테스트가 있는 저장소도 30분 만에 만들 수 있어 겉모습만으로 품질을 판단하기 어려워졌고, 실제 기준은 누군가 그 소프트웨어를 꾸준히 사용했는지가 됨
  • AI 도구는 소프트웨어 엔지니어의 경험을 대체하기보다 증폭하며, 코드 생산 속도가 하루 200줄에서 2,000줄로 늘면 병목은 설계, 검증, 운영, 실제 사용으로 이동함

Vibe coding과 agentic engineering의 경계

  • Heavybit High Leverage 팟캐스트 Ep. #9에서 AI 코딩 도구를 다루며, vibe coding과 agentic engineering이 실제 작업에서 서로 더 가까워지고 있다고 보게 됨
  • 이전에는 Not all AI-assisted programming is vibe coding (but vibe coding rocks)에서 vibe coding과 책임 있는 AI 보조 프로그래밍을 분명히 구분했으며, 후자를 이후 agentic engineering이라고 부르기 시작함
  • vibe coding은 코드를 거의 보지 않고, 프로그래밍을 모를 수도 있는 사용자가 원하는 결과물을 요청한 뒤 동작하면 받아들이고, 안 되면 다시 요청하는 방식으로 구분됨
  • 개인 도구처럼 버그가 자기 자신에게만 피해를 주는 경우에는 vibe coding이 유용할 수 있지만, 다른 사람의 정보와 사용 경험이 걸린 소프트웨어를 만들 때는 무책임한 방식으로 보임
  • agentic engineering은 전문 소프트웨어 엔지니어가 보안, 유지보수성, 운영, 성능 같은 제약을 이해한 상태에서 AI 도구를 자기 역량의 최대치로 활용하는 방식임
  • 목표는 더 낮은 품질의 결과물을 더 빠르게 만드는 것이 아니라, 더 높은 품질의 프로덕션 시스템을 더 빠르게 만드는 데 있음
  • 문제는 코딩 에이전트가 더 신뢰 가능해지면서, 프로덕션 수준 작업에서도 생성된 모든 코드 줄을 더 이상 검토하지 않게 됐다는 데 있음

코드 검토를 생략하게 만드는 신뢰

  • Claude Code에 JSON API 엔드포인트를 만들고, SQL 쿼리를 실행해 결과를 JSON으로 출력하도록 요청하면 제대로 처리할 것이라는 확신이 생김
  • 자동화 테스트와 문서화를 추가하게 해도 결과물이 괜찮을 것이라고 기대하게 되며, 그 과정에서 실제 코드를 검토하지 않는 경우가 생김
  • 코드를 검토하지 않았다면 프로덕션에 사용하는 것이 책임 있는 일인지에 대한 죄책감이 남음
  • 큰 조직에서 엔지니어링 매니저로 일할 때 다른 팀의 소프트웨어를 사용하는 방식과 비슷하게 볼 수 있음
    • 다른 팀이 이미지 리사이즈 서비스를 제공하면, 보통 그 팀이 작성한 모든 코드 줄을 읽지 않음
    • 문서를 보고 이미지를 리사이즈해 본 뒤 자기 기능을 출시함
    • 버그나 성능 문제가 보일 때에야 Git 저장소를 들여다볼 수 있음
    • 대부분의 경우 해당 서비스를 반쯤 블랙박스처럼 다룸
  • 에이전트도 점점 같은 방식으로 다루게 되지만, 사람 팀과 달리 Claude Code에는 전문적 평판이나 책임(accountability)이 없음
  • 사람 팀은 과거에 좋은 소프트웨어를 만들며 평판을 쌓을 수 있고, 형편없는 결과물이 자신의 전문적 평판에 영향을 준다는 압박을 받음
  • Claude Code는 그런 평판을 가질 수 없지만, 반복적으로 단순한 작업을 선호하는 스타일에 맞게 올바르게 처리하면서 신뢰를 쌓고 있음
  • 여기에는 일탈의 정상화 요소가 있음
    • 모델이 가까이 감시하지 않아도 올바른 코드를 작성할 때마다 신뢰가 커짐
    • 나중에 잘못된 순간에 과신해 피해를 볼 위험도 함께 커짐

소프트웨어 평가가 더 어려워짐

  • 예전에는 GitHub 저장소에 커밋 100개, 좋은 README, 자동화 테스트가 있으면 프로젝트에 상당한 정성과 주의가 들어갔다고 판단하기 쉬웠음
  • 이제는 커밋 100개, 아름다운 README, 모든 코드 줄을 포괄하는 테스트가 있는 Git 저장소를 30분 만에 만들 수 있음
  • 이런 저장소는 오랜 정성과 주의가 들어간 프로젝트와 겉보기에는 동일하게 보일 수 있음
  • 실제로 그만큼 좋을 수도 있지만, 겉으로 봐서는 알기 어렵고 자기 프로젝트에 대해서도 같은 문제가 생김
  • 테스트와 문서의 품질보다 더 중요하게 보는 기준은 누군가가 그 소프트웨어를 실제로 사용했는지임
  • vibe coded 결과물이라도 만든 사람이 지난 2주 동안 매일 사용했다면, 거의 실행해 보지 않고 뱉어낸 결과물보다 훨씬 더 가치 있다고 봄

병목은 코드 작성에서 다른 단계로 이동함

  • 하루에 코드 200줄을 만들던 상황에서 2,000줄을 만들 수 있게 되면, 소프트웨어 개발 생애주기의 다른 부분이 깨지기 시작함
  • 기존 소프트웨어 개발 생애주기는 하루에 코드 몇백 줄을 만드는 속도를 전제로 설계돼 있었음
  • 병목 변화는 하류 단계뿐 아니라 상류 단계에도 영향을 줌
  • Jenny Wen의 발표에서는 기존 디자인 프로세스가 “디자인을 제대로 맞춰야 한다”는 전제를 갖고 있다고 봄
    • 엔지니어에게 넘긴 뒤 잘못된 것을 3개월 동안 만들면 재앙이 되기 때문임
    • 디자인이 값비싼 작업으로 이어지기 때문에 광범위한 디자인 프로세스를 둠
    • 하지만 빌드에 3개월이 걸리지 않는다면, 잘못됐을 때 비용이 크게 낮아졌기 때문에 디자인 프로세스가 훨씬 더 위험을 감수할 수 있음

그래도 소프트웨어 엔지니어 커리어가 끝났다고 보지 않는 이유

  • 에이전트와의 대화는 대다수 사람에게 알아듣기 어려운 “moon language”처럼 보임
  • 컴퓨터가 스스로 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 보지 않는 이유 중 하나는, 이런 도구가 기존 경험을 증폭하기 때문임
  • 무엇을 하고 있는지 아는 사람은 AI 도구와 함께 훨씬 더 빠르게 움직일 수 있음
  • AI 도구를 사용할수록 소프트웨어 제작 자체가 매우 어렵다는 사실이 반복적으로 확인됨
  • 모든 AI 도구가 주어져도 달성하려는 일은 여전히 어렵다고 봄
  • Matthew Yglesias는 트윗에서 “5개월이 지나고 보니 vibecode를 하고 싶지 않다. 전문적으로 관리되는 소프트웨어 회사들이 AI 코딩 보조를 사용해 더 많고, 더 좋고, 더 저렴한 소프트웨어 제품을 만들어 나에게 돈을 받고 팔았으면 한다”고 썼고, 여기에 동의함
  • 배관 관련 YouTube 영상을 충분히 보면 직접 집 배관을 고칠 수도 있지만, 배관공을 고용하는 편을 선호한다는 비유로 정리됨

SaaS와 사내 제작의 위험

  • 기업이 SaaS를 쓰지 않고 자체 솔루션을 만들 수 있게 되는 위협에 대해서도, 실제 사용으로 검증된 소프트웨어를 선호한다는 기준이 그대로 적용됨
  • 개인 프로젝트에서는 적어도 몇 주 동안 만든 사람이 직접 사용한 도구를 선호함
  • 엔터프라이즈 버전으로 바꾸면, 적어도 두 개의 다른 대기업이 6개월 동안 성공적으로 사용한 CRM이 아니라면 도입하고 싶지 않다는 기준이 됨
  • 위험을 감수하기 전에 실제로 작동한다고 입증된 솔루션을 원함

함께 보면 좋은 글 β

▲
GN⁺ 3시간전  [-]
Hacker News 의견들

  • 바이브 코딩과 LLM이 규율 없는 엔지니어링 조직이나 엔지니어를 만든 게 아니라, 기존 문제를 드러내고 가속했을 뿐임
    많은 엔지니어가 코드 작성 기준과 실천이 느슨하거나 아예 없고, 많은 팀도 코드를 운영 환경에 배포하는 기준이 약함
    이건 새로운 현상이 아니라, 소프트웨어 개발 생명주기에서 기준을 지켜본 적 없는 개인과 팀이 훨씬 더 많은 코드를 만들고 아이디어를 구체화하기 쉬워졌다는 뜻

    • 나쁜 엔지니어는 계속 나쁘고, 좋은 엔지니어는 계속 좋음
      코드를 빨리 쓴다고 좋은 엔지니어가 된 동료는 본 적이 없음
      내가 아는 최고의 엔지니어들은 경험과 신중한 판단을 바탕으로 팀에 중요한 통찰을 공유해 시스템 방향을 좋게 이끈 사람들이었음
      “Claude, 시스템 하나 만들어줘. 근데 잘 만들어줘. 고마워!”
    • 많은 사람이 “문제가 되면 그때 고치자”는 사고방식으로 성장해 왔음
      예전에는 코드베이스가 기능 개발에 저항하기 시작하면 당장의 병목을 고치고, 다음 저항 지점까지 미루는 식이었음
      기능을 만들면서 어느 정도 리팩터링하는 방식이었는데, 최전선 모델들이 “문제가 되는 순간”을 뒤로 밀어버림
      주어진 코드 더미를 어느 정도까지는 처리해 주기 때문에, LLM이 회귀를 더 만들거나 요구사항을 더 놓치는 식으로 드러나지만 사람에게 일이 더 어려워진 느낌은 덜함
      그러다 어느 순간 너무 많이 깨져서 고쳐야 하는데, 전체 코드베이스가 내가 내리지 않은 결정들의 프랙털식 층이 되어 있어 풀어내기 어려움
      직접 코드를 편집하지 않으니 “이걸 이런 방식으로 추가하면 긴장이 크다”는 몸으로 느끼는 반응이 사라져 리팩터링 돌파구를 잡기도 힘들어짐
    • 테스트나 불변조건이 거의 없는 바이브 코딩 앱이 스파게티 코드가 되는 건 당연함
      코드는 언제든 리팩터링할 수 있고, 에이전트에게 작고 모듈화된 조각과 파일을 쓰게 강제할 수 있음
      에이전트가 썼든 사람이 썼든 좋은 엔지니어링은 좋은 엔지니어링임
      아직은 사람이 최소한 아키텍처를 이해하고 주도해야 하며, 에이전트는 정찰과 제안에서 아주 잘 도와줄 수 있음

  • 몇 주 사이의 발전을 놓친 게 아니라면, AI가 더 믿을 만해졌다기보다 오류가 더 미묘해진 것으로 보임
    코드가 컴파일되지 않으면 찾기 쉽고, 컴파일되지만 동작하지 않아도 어느 정도 찾기 쉬움
    하지만 컴파일되고 동작하는데 일부 경계 조건에서 잘못되거나, 보안 취약점이 있거나, 기술 부채와 의심스러운 아키텍처 결정을 끌고 오면 찾기 훨씬 어려우며 리뷰 부담은 전혀 줄지 않음
    오히려 그럴듯한 코드는 명백히 나쁜 코드보다 리뷰할 때 정신적으로 더 부담됨

    • LLM에게 테스트 주도 개발을 시킬 수는 있음
      여러 테스트를 먼저 작성하게 하고 코드가 거기에 맞는지 확인하며, 에이전트가 코드를 올바르게 조직하도록 시키면 됨
    • LLM의 좋은 용도가 있다는 건 알고 있음
      하지만 지금은 위에서 내려오는 열기가 너무 커서 어디든 광범위하게 적용하라는 분위기고, 거기에 반대하면 너무 낙담스럽고 커리어에도 제약이 생겨 정신이 닳아감
      명백한 문제를 지적하면 그만큼 많은 우회책이 나오고, 그 우회책에는 곧 또 다른 문제가 드러나며 끝없이 새 해결책을 낳음
      어느 순간 이 모든 일이 기계 자체를 위한 작업처럼 느껴짐
      많은 회사에서 진짜 목표가 흐려지고 남은 것은 LLM 자체뿐인 것 같음
      회사의 미래를 걸고 그 비전을 구현하는 사람들은 결과를 피할 부드러운 출구를 보장받는 건지, 아니면 합리성이 통째로 버려지는 건지 모르겠음
      건전한 엔지니어링 원칙으로 문제를 완화할 수는 있겠지만, 인지 부하·개발자 시간·돈·유한한 자원 관점에서 실제로 어떤 효율이 생기는지 의문임
    • “위험을 감수하기 전에 이미 작동이 검증된 해결책을 원한다”는 말은 여전히 맞고, 경계가 발견되는 지점도 거기일 것임

  • “하루 200줄에서 2,000줄을 만들 수 있게 되면 무엇이 깨지는가”라는 문장에서, 엔지니어링 산출의 척도로 코드 줄 수를 쓰는 건 부끄러운 일임

    • 여기서 코드 줄 수가 유용한 건 산출량 지표라서가 아니라 이해 가능성의 지표라서임
      200줄을 리뷰하는 것과 2,000줄을 리뷰하는 건 완전히 다른 작업량임
    • 바이브 코딩을 실험하면서 코드를 직접 보지 않았더니 리팩터링 후에도 약 1만 줄이 나왔음
      같은 프로그램을 내 머리로 다시 만들고 ChatGPT는 검색과 자동완성처럼만 썼더니 1,500줄로 같은 결과가 나옴
      노력 차이도 솔직히 아주 크지는 않았지만, 손으로 짠 접근은 먼저 바이브 코딩한 버전 덕분에 만들고 싶은 것을 이미 생각해 둔 이점이 있었을 수 있음
    • 글의 핵심은 코드 작성 산출 속도가 사람이 리뷰할 수 있는 속도를 넘어섰다는 것임
      소프트웨어 리뷰의 입력값으로 코드 줄 수를 쓰는 건 말이 됨
      말 그대로 각 줄을 읽어야 하기 때문임
    • 코드 줄 수는 엔지니어링 산출의 지표로는 충분히 괜찮음
      다만 개발자 생산성의 단독 척도로는 형편없고, 그렇게 쓰려 할 때 문제가 생김
      그래도 여러 회사·팀·언어·애플리케이션 맥락에서 즉시 직관적으로 이해되고 비교 가능한 거의 유일한 지표라 유용함
      같은 팀이 같은 제품에서 작업해도 1,000줄 변경은 금방 끝날 수 있고, 1줄 버그 수정은 며칠 디버깅이 필요할 수 있음
      그래서 PR, 기능, 스토리 포인트를 맥락 밖에서 비교하기는 어렵고, 업계 표준 개발자 생산성 지표가 가능했다면 모두가 썼겠지만 본질적으로 어렵다 봄
      이런 비교를 할 때는 맥락이 같다고 가정하면 도움이 됨
      예를 들어 특정 회사의 특정 제품을 특정 기술 스택과 품질 프로세스로 만들던 팀이 어제는 N1줄, 오늘은 AI로 N2줄을 만들었다면 시간이 지나며 N1과 N2의 차이가 실제 영향을 근사함
      엄밀한 AI 보조 개발 생산성 연구들도 대체로 같은 집단을 대상으로 AI 사용 전후 PR을 비교하는 A/B 테스트식 측정을 해 왔음
    • 코드 줄 수는 엔지니어링 산출에 최악의 지표임. 다른 모든 지표를 제외하면

  • 내 기준에서 차이는 파이프라인의 품질과 엄격함임
    바이브 코딩은 한 번 또는 몇 번 시도하고, 결과를 간단히 확인한 뒤 깨질 때까지 쓰는 방식임
    가벼운 개념증명이나 위험이 낮은 개인·가족·소규모 팀 앱에 적합함
    에이전트식 엔지니어링은 기능적 정확성, 성능, 인프라, 복원력/가용성, 확장성, 유지보수성 같은 더 넓은 관심사를 신경 씀
    작업 흐름을 관리하는 다단계 파이프라인이 있고, 프로젝트 접수·선정·명세·에픽 분해·스토리 분해·코딩·문서화·배포 같은 단계가 있을 수 있음
    각 단계에는 테스트 통과나 성능 기준 같은 결정적 품질 관문과, 사업 가치·명세 완전성·코드 우아함·유비쿼터스 언어의 엄격함과 단순성 같은 적대적 리뷰가 섞임
    이것도 슬라이더임
    어떤 때는 기능 하나를 배포하려고 인터뷰하고 토큰을 태우며 세 차례 적대적 리뷰와 가치 추정, 상세 명세까지 하고 싶지 않아 그냥 티켓을 시스템에 던짐

    • 슬라이더가 바이브 코딩과 에이전트식 엔지니어링 사이만 있다면, 사람이 더 깊이 개입하는 넓은 엔지니어링 영역을 놓치고 있음
      Opus, GPT-5.5, 더 작은 모델들을 매일 쓰지만 전체 작업을 맡기지는 않음
      명세를 정의하고 다듬는 데 꽤 공을 들여도, 인간 PR 리뷰라면 통과시키지 않을 멍청한 일을 여전히 많이 함
      산출물을 믿거나 큰 에이전트 파이프라인을 만들어 거짓 안정감을 얻었다면 코드베이스에 그냥 흘러 들어가게 두기 쉬웠을 것임
      10년 뒤에는 나아질 수 있겠지만, 지금의 바이브 코딩과 에이전트식 엔지니어링 파이프라인은 모두 LLM에 통째로 위임하는 같은 주제의 변주처럼 보임
      오늘 아침에도 단일 파일에서 Opus on Max에게 변경을 맡길 수 있겠다 싶었지만, 거의 매 턴마다 실수하거나 놓치는 부분이 있어 고쳐야 했음
      제안한 코드는 대체로 동작했겠지만 너무 복잡했고, 내가 이미 손으로 단순화해 둔 부분을 다시 퇴행시켰음
      이런 일이 수천 개의 에이전트 커밋에 곱해지면 코드베이스는 빠르게 나빠짐
    • 바이브 코딩에는 각 단계의 품질 관문이 없고, 에이전트식 엔지니어링에는 있음
      개발팀은 설계·테스트·리뷰라는 올바른 프로세스 없이 만들려 할 때 곤란해짐
      에이전트 코딩 이전에도 그랬지만 지금은 특히 더 그렇고, 이 프로세스에서 에이전트를 활용하는 법을 이해한 팀이 가장 성공할 것임

  • 코딩 에이전트가 첫 시도에서 해법에 아주 가까이 가지만, 마지막 10%나 5% 를 맞추는 데 엄청난 작업이 필요하다는 걸 느끼지 않았나
    문제 접근 방식을 바꾸면 에이전트가 그 간극을 메울 수 있음
    10년 전에는 10~15분마다 코딩을 멈추고 리팩터링·테스트·분석을 하며 완벽한지 확인했음
    버그가 이후 코드 전체를 오염시키기 때문임
    코딩 에이전트는 그렇게 하지도 못하고, 버그나 잘못된 아키텍처를 그대로 안고 계속 감
    본능적으로는 에이전트를 중간중간 멈추게 하고 싶지만 여러 이유로 불가능함
    대신 비용이 매우 싸니 에이전트가 처음 실수한 지점을 찾아 프롬프트를 고치고, 코드를 수정하는 대신 전부 지운 뒤 처음부터 다시 돌려야 함
    프롬프트가 완벽한 코드를 낼 때까지 이 반복을 계속하면 됨
    인간이 할 일이 많다는 반론이 나오겠지만, 바로 그게 핵심임
    인간은 여전히 필요하고, 이런 식으로 도구를 쓰면 코드 작성 속도는 10배 빨라짐

    • 수동으로 코드를 짤 때도 자주 그랬음
      “동작하는 무언가”는 꽤 빨리 만들 수 있지만, 다른 선택지를 평가하고 다듬고 테스트해서 확신을 쌓는 데 오래 걸림
      요지는 맞지만 경계가 어디인지는 아무도 모름
      앞으로 1년 정도는 모두가 그걸 찾아가는 시기가 될 것이고, 그래서 “GitHub를 재발명해야 한다”는 말도 많이 들리는 것임
    • 인생 전반의 문제는 마지막 5~10%가 항상 가장 어렵다는 것임
      많은 경우 그 마지막 부분까지 기계화하려 투자하는 건 경제적으로 맞지 않음
      LLM 제공자들은 처음부터 잘못된 접근을 택했다고 봄
      노동을 대체하는 데 집중할 게 아니라 노동을 보완하는 데 초점을 뒀어야 했고, 비싼 교훈을 얻은 듯함
    • 나는 일단 동작하게 만든 뒤 리팩터링으로 빠져나오는 편이고, 코딩 에이전트로도 가능하지만 시간이 걸림
      처음부터 다시 시작하는 게 나았을 수도 있지만, 시작할 때는 원하는 아키텍처가 어떤 모습인지 몰랐음
    • 코드베이스에 이미 많은 코드가 커밋된 뒤에는 그렇게 깔끔하게 되지 않음
      LLM이 기존 아키텍처에 기능을 맞추는 데 애먹는다고 해서, 동작 중인 전체 코드베이스를 날리고 다시 시작할 수는 없음

  • 똑똑하고 겸손하며 계속 배우는 사람이 쓴 훌륭한 글임
    마음에 든 문장은 “컴퓨터가 자기 코드를 쓸 수 있게 됐다고 해서 소프트웨어 엔지니어 커리어가 끝났다고 두렵지 않은 이유는 많다. 부분적으로는 이런 것들이 기존 경험의 증폭기이기 때문이다. 뭘 하는지 안다면 훨씬 더 빨리 달릴 수 있다”는 대목임
    또 “이 도구들을 쓰며 우리가 하는 일이 얼마나 어려운지 계속 상기된다. 소프트웨어를 만드는 일은 맹렬하게 어렵다. 세상의 모든 AI 도구를 줘도 우리가 여기서 이루려는 일은 여전히 정말 어렵다”는 부분도 좋았음

  • 업스트림 작업도 함께 바뀐다는 지적이 정확함
    디자인 쪽 도구가 특히 빠르게 진화하고 있어서, 더 이상 Figma 쪽에 머무르는 번역 비용을 감수할 가치가 없어 보임

  • 무서운 부분은 코드베이스에 AI 복잡성의 층이 쌓이고, 사람이 더는 코드를 이해하지 못해 최신 모델이 해독하고 변경하는 데 큰 비용이 들게 된다는 점임
    머지않아 코드 재사용은 사라지고, 바퀴를 계속 다시 발명하느라 돈을 태우게 될 수 있음

    • 이건 예전 Java나 IDE 의존이 강했던 Java/C# 같은 언어와 조금 비슷하지 않나
      초기 Android 앱을 만들 때는 IDE를 반드시 써야 했고, 버튼 클릭 후 “Hello World” 알림을 띄우기 위해 말도 안 되는 양의 상용구 코드를 작성해야 해서 영혼이 빠지는 느낌이었음

  • 따라 말해보자: 대부분의 소프트웨어는 수명 대부분을 유지보수 단계에서 보냄
    따라서 소프트웨어가 버는 돈 대부분도 유지보수 단계에서 발생함
    업계는 거의 100년이 지나도록 아직도 이걸 이해하지 못함
    Alan Kay가 컴퓨터 혁명은 아직 일어나지 않았다고 한 말은 100% 맞음
    현재의 모든 발전에도 도구들은 대체로 석기시대 수준임
    내 큰 희망은 AI가 기존 패러다임을 회복 불가능할 정도로 완전히 깨뜨리는 지점까지 우리를 가속해, 마침내 새롭고 다르고 더 나은 무언가를 할 수 있게 되는 것임
    그러니 지금은 AI로 소프트웨어 개발 생명주기에 제트팩을 달고 마음껏 해보자
    빠르게 움직이고, 진짜로 깨뜨려보자

  • 시의적절한 관찰이고 나에게도 맞게 느껴짐
    비교적 단순한 일괄 다운로드 → 변환 → API 엔드포인트를 세워야 했고, 꽤 상세한 프롬프트를 썼지만 데이터 소스 같은 구현 세부사항은 많이 비워뒀음
    Opus 4.7은 내가 했을 방식과 90% 정도 같게 만들었고, 편의 메서드와 단계별 검증은 훨씬 많이 넣었음
    아주 좋았고, 더 어려운 문제를 생각할 여유를 줬음

    • 내 경험도 비슷함
      주로 Python 개발자지만, Rust나 Go처럼 익숙하되 같은 수준은 아닌 다른 백엔드 언어를 꾸준히 쓰고 있음
      한 언어에 크게 치우친 약 13년 경험과 다른 언어에 대한 형식적 학습이 있으니 LLM을 지휘하기가 훨씬 쉬움
      문법, 기본 구성요소, 패키지 관리자, 테스트 등을 배우는 부담은 예전 프로그래밍 방식에 비하면 크지 않음
      얼마 전 Claude cowork/code로 리포팅 자동화를 하던 비개발자 동료를 도왔음
      그 동료는 비즈니스 인텔리전스 쪽은 잘 이해했지만, RDP를 띄우고 공급업체 DB 위의 MS Access 추상화에 값을 채우는 pyautogui 래퍼를 바이브 코딩하기 위한 기본 표현에서 어려움을 겪고 있었음
      직업으로서 개발자는 앞으로 5~10년은 괜찮을 것 같음
답변달기