dog paw / development

개발자는 사라지지 않는다 — 이 말이 점점 변명처럼 들리는 이유가 있다.반대편의 문장이 더 자극적이기 때문이다.“AI가 코드를 다 짜준다.”“주니어는 끝났다.”“몇 년 안에 개발자는 없어질 직업이다.”이건 단순한 공포 마케팅이 아니다. 실제로 맞는 부분이 있다. CRUD, 보일러플레이트, 반복적인 API 연동 — 이런 건 이미 상당 부분 AI가 가져갔다. 직접 써본 사람은 안다. 예전 같으면 30분 걸리던 작업이 3분 만에 끝난다.그래서 사람들은 자연스럽게 다음 단계로 넘어간다.코드도 짜고 → 구조도 잡고 → 설계도 하고 →그럼 결국 개발자 필요 없지 않나?여기서 한 단계가 빠진다.그 빠진 한 단계 때문에 결론이 틀어진다.AI가 도메인을 이해한다는 말, 어디까지 맞는가주식 거래 앱을 만들어달라고 하면, ..

AI가 알아서 다 만들어준다는 말은 듣기 좋다. 너무 좋다.도메인도 이해하고, 코드도 짜고, 테스트도 하고, 나중엔 책임까지 대신 져줄 것처럼 말한다. SNS만 열어도 비슷한 문장이 끝없이 나온다. “혼자서 앱 만들기”, “AI 에이전트가 개발자를 대체한다”, “바이브 코딩으로 MVP를 3일 만에 완성했다.” 썸네일은 더 세다. 지금 안 타면 뒤처질 것처럼 보이게 만든다. 그런데 직접 오래 돌려본 사람은 안다.이 얘기가 왜 이상하게 들리는지. 자리를 비우고 돌아오면 멈춰 있다. 승인을 기다리다가.조금 길게 태워보면 또 다른 이유로 끊긴다. 컨텍스트가 불어나서 느려지거나, 요청 제한에 걸리거나, 토큰을 너무 많이 써서 더는 밀어붙이지 못한다. “알아서 다 해준다”는 말과 실제 사용 경험 사이에 아주 두꺼운..

며칠 전 Anthropic 쪽에서 소스맵 노출 사고 얘기가 돌았을 때, 사고 내용 자체보다 더 눈에 남은 건 그 직후 커뮤니티에 제일 먼저 올라온 질문이었다. “이거 사람 실수야, AI 실수야?” 누가 배포 설정을 잘못 만진 건지, AI 에이전트가 파일을 건드리다 놓친 건지, 진짜 원인은 바깥에서는 알 수 없다. 그건 내부에서나 확인할 일이다. 근데 내겐 그보다 이 질문이 먼저 튀어나왔다는 사실이 더 흥미로웠다. 이게 지금 풍경이다.사고가 나면 원인을 사람인지 AI인지부터 가르고 싶어지는 시대. 그리고 그 질문 뒤에는 거의 자동으로 다음 질문이 붙는다. “그래서 누가 책임지는데?” 요즘 진로 고민하는 학생들이나 취업 앞둔 컴공과 4학년, 주니어들이 반복해서 꺼내는 불안도 결국 이 자리로 모인다. AI가 ..

AI 때문에 개발자가 사라질 거라는 말을 요즘 정말 자주 듣는다. 재미있는 건 이 말을 개발을 잘 모르는 사람이 아니라, 오히려 AI를 매일 쓰는 개발자들이 더 많이 한다는 점이다. 매일 눈앞에서 AI가 자기 대신 코드를 뽑아내는 걸 보고 있으면 흔들릴 수밖에 없다. 예전에는 “주니어 업무부터 줄어들겠지” 정도였는데, 이제는 시니어도 안전하지 않다는 식으로 얘기가 확장됐다. 얼마 전 지인 한 명이 진지하게 커리어 전환을 고민한다고 했다. 30년 넘게 코딩한 사람인데, 요즘은 자기가 일주일 붙들 일도 AI가 몇 시간 안에 대충 형태를 만들어내는 걸 보면서 묻더라. “내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?” 반대로 다른 한 명은 AI를 거의 안 쓰는 팀원들을 보면서 완전히 다른 불안을 말한다..

이 시리즈를 쓰면서 제일 이상했던 숫자가 하나 있었다. Terminal Bench 2.0에서 Claude Opus 4.6이 Claude Code 안에서는 33위였는데, 다른 하네스에 올리면 5위권까지 올라간다는 얘기. 처음 봤을 때는 그냥 흥미로운 관찰 정도로 넘겼다. “벤치마크마다 다를 수도 있지”, “환경 차이겠지” 하고 지나가기 쉬운 숫자였다. 근데 이걸 계속 붙들고 있다 보니, 오히려 이 숫자가 시리즈 전체에서 제일 실전적인 힌트였다는 생각이 들었다. 보통 우리는 이렇게 생각한다.좋은 모델이 있고, 좋은 하네스가 있고, 둘을 합치면 더 좋은 결과가 나온다고. 그런데 실제로는 꼭 그렇지 않다. 가끔은 모델이 문제가 아니라,그 모델이 너무 익숙해진 기본 설정이 문제다. 심지어 더 노골적으로 말하면,당..

여기까지 읽고 나면 자연스럽게 이런 생각이 든다. “알겠어. 개념도 알겠고, Anthropic이 어떻게 굴렸는지도 봤어. 그런데 내 프로젝트에서는 뭘 해야 하는데?” 사실 이 질문이 제일 중요하다.개념은 멋있고, 사례는 인상적이다. 그런데 내 저장소에 붙는 순간부터는 얘기가 완전히 달라진다. 거기에는 오래된 코드가 있고, 반쯤 깨진 테스트가 있고, 이름만 남은 문서가 있고, 사람도 자주 안 지키는 규칙이 있다. 그런 현실 위에 AI 코딩 에이전트를 올리면 어떤 일이 생기냐면… 모델이 멍청해서가 아니라 환경이 엉망이라서 계속 삐끗한다. 나는 하네스 엔지니어링을 거창한 멀티 에이전트 설계로 보기보다, “에이전트가 계속 같은 데서 미끄러질 때 바닥에 미끄럼방지 테이프를 붙이는 일”에 더 가깝다고 본다. 이 비..

지난 글에서는 하네스 엔지니어링이라는 말을 조금 추상적으로 다뤘다. 모델 바깥에 제약을 두고, 도구 실행을 통제하고, 상태를 넘겨주는 구조가 중요하다는 이야기였다. 그런데 그런 설명만으로는 좀 안 와닿는다. 나도 그랬다. “그래서 실제로는 뭘 어떻게 묶었다는 건데?”라는 질문이 계속 남았다. Anthropic이 공개한 에이전트 설계와 OpenAI Codex 팀의 실험 기록을 같이 보면 그 질문에 답이 생긴다. 둘이 접근 방식은 조금 다르지만, 읽다 보면 결국 같은 결론으로 수렴한다. 좋은 결과를 내는 건 모델의 ‘지능’ 자체가 아니라, 모델이 실수하지 않도록 둘러싸는 바깥 구조라는 점이다. 이걸 이해하는 가장 쉬운 출발점은 거창한 다이어그램이 아니라 그냥 하나의 루프다. 에이전트는 결국 while(tru..