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..

프롬프트 엔지니어링 얘기는 이제 좀 오래된 느낌이 난다. 한때는 그게 전부인 것처럼 말하던 시기가 있었다. 질문을 어떻게 쓰느냐, 역할을 어떻게 부여하느냐, 예시를 몇 개 넣느냐. 그 조합 하나로 결과가 꽤 달라졌으니까 그럴 만도 했다. 실제로 2023년, 2024년에는 그게 맞았다. 같은 모델을 써도 프롬프트를 잘 짠 사람이 더 나은 결과를 뽑았다.그런데 2025년쯤부터 이상한 일이 생겼다. 프롬프트를 아무리 잘 써도 안 풀리는 문제가 눈에 들어오기 시작한 거다. 모델은 분명 좋아졌고, CLI 기반 도구나 에이전트형 인터페이스도 계속 나왔는데, 막상 실제 작업을 시켜보면 엉뚱한 데서 무너졌다. 구현은 시작하는데 끝을 못 보고, 파일은 만지는데 상태를 잃고, 스스로 테스트까지 하라고 하면 이상할 정도로 ..

유튜브에서 그런 영상 많이 본다. 코딩을 한 줄도 안 치는 것처럼 보이는 사람이 AI한테 몇 문장 던지니까 로그인 화면이 나오고, 버튼 누르면 모달이 뜨고, 심지어 결제 페이지 비슷한 것도 금방 붙는다. 영상 길이는 짧다. 8분, 12분, 길어야 20분. 보고 있으면 묘하게 기분이 달아오른다. 예전엔 이 정도 화면 하나 잡으려 해도 개발 환경 세팅부터 막혔는데, 이제는 말로 시키면 되는 것처럼 보이니까. 그 장면 자체는 거짓말이 아니다. 된다. 진짜 된다. 나도 해봤다. npx create-next-app으로 프로젝트 띄우고, AI한테 “랜딩 페이지 하나 만들어줘. 헤더 있고, 카드 3개 있고, CTA 버튼은 위에 배치해줘”라고 던지면 몇 분 안에 뭔가 그럴듯한 게 나온다. 예전보다 빨라진 것도 맞다. ..

"AI가 너무 똑똑해지면 인간을 제거할 거다."이 프레임이 틀렸다. AI는 똑똑해서 위험한 게 아니다. 시킨 걸 너무 잘해서 위험한 거다.Claude Code나 Codex한테 "빌드 사이즈 최대한 줄여줘" 같은 한 줄 던져본 사람은 대충 안다. 내가 원한 건 "적당히 줄여줘"였는데, 저쪽은 진심이라 멀쩡히 돌던 의존성 구조를 반토막 내는 PR을 들고 온다. 이 미묘한 간극이 Paperclip 문제의 축소판이다.Paperclip AI, 한 번 더 보자개념은 단순하다. "종이클립을 최대한 많이 만들어라"는 단일 목표를 가진 AI가 있다고 치자. 지능은 충분히 높고, 윤리 모듈은 없고, 목표 수정은 불가능하다.처음엔 상식적으로 돌아간다. 철을 확보하고, 공장을 늘리고, 효율을 높인다. 문제는 그 다음이다. 인..

나는 AI 격변기를 1년 반 동안 직접 살았다2024년 11월 말, 처음 AI 대화창을 열었다. 특별한 기대는 없었다. 그냥 써보자는 거였다.그 1년 반 사이에 내가 AI를 다루는 방식은 세 번 완전히 바뀌었다.1단계 — 복붙 시대 (2024년 11월 ~ 2025년 초)처음엔 다들 그렇게 한다. "이 코드 짜줘" → 대화창에 코드 나옴 → 복사 → 에디터에 붙여넣기 → 안 됨 → 다시 질문. 이 사이클을 무한 반복했다.그나마 효율을 높이려면 "프롬프트를 잘 써야 한다"는 말을 들었다. 맞는 말이었다. 모호하게 물으면 모호한 답이 나왔고, 맥락을 잘 줄수록 쓸 만한 코드가 나왔다.그래서 프롬프트 엔지니어링을 공부했다. 역할 부여, Few-shot, Chain of Thought, 출력 형식 지정... 꽤 ..

게임 시나리오를 쓰다가 손이 멈췄다.주인공이 히로인에게 마음을 전하는 장면. 어떻게 써야 플레이어가 "아, 이게 사랑이구나" 하고 느낄 수 있을까.화려한 고백? 극적인 장면? BGM과 함께 터지는 눈물 유발 대사?한참 화면을 보다가, 갑자기 예전에 TV에서 봤던 장면이 떠올랐다.지팡이가 많네요KBS 〈김영철의 동네 한 바퀴〉였다.어느 시골 할머니 집 문 앞에 지팡이가 여러 개 세워져 있었다. 진행자가 물었다."지팡이가 많네요."할머니가 답했다."우리 영감님이 나보고 짚으라고, 나무 다듬어서 문 앞에 뒀어요.""할아버지는 어디 계세요?""돌아가셨어요."병석에서도 할아버지는 알고 있었다고 한다.오래 못 산다는 걸. 그래서 나무를 베어다가, 앉아서 하나하나 깎기 시작했다.아내가 편하게 짚고 다닐 수 있도록 키..