안 만드는 것도 개발이다.
이 말 자체는 별로 새롭지 않다. 기능을 덜 만들고, 코드를 덜 고치고, 불필요한 추상화를 피하는 게 중요하다는 말은 예전부터 있었다. 그런데 AI가 코드를 너무 쉽게 쌓아주는 시대가 되니까, 이 오래된 말이 조금 다르게 보이기 시작했다.
요즘 AI를 둘러싼 말은 대체로 더 많이 쓰는 쪽으로 흐른다. 더 긴 컨텍스트, 더 많은 토큰, 더 오래 도는 에이전트. 계속 돌리면 더 좋은 답이 나오고, 더 많은 코드를 만들 수 있고, 더 많은 일을 자동으로 처리할 수 있을 것처럼 말한다.
물론 그런 방식이 필요한 작업도 있다. 긴 조사나 넓은 코드베이스 분석처럼, 실제로 유용하게 쓰이는 일도 있다.
근데 매일 코드를 만지는 입장에서는 이 말들은 조금 의심스럽다.
그 많은 실행은 정말 내 코드베이스를 위한 걸까?
AI 회사와 GPU 회사가 계속 팔아야 하기 때문인건 아닐까?
토큰을 쓰는 게 목적이 되면 이상해진다
개발자가 봐야 하는 건 토큰 사용량이 아니다.
이 기능은 누굴 위해 만드는지, 누굴 위해 이렇게 설계했는지, 실제로 누구의 문제를 얼마나 푸는지다. 그 질문이 빠진 채로 “AI를 더 오래 돌렸다”, “토큰을 더 많이 썼다”, “에이전트가 계속 작업했다”만 남으면 좀 이상해진다.
그건 개발이라기보다 가짜 성과에 가깝다.
AI가 코드를 많이 만드는 일은 분명 편하다. 나도 그 편함을 좋아한다. 한참 걸릴 정리를 금방 해주고, 귀찮은 반복 작업도 잘 해준다. 다만 많이 만들었다는 사실이 곧 잘 만들었다는 뜻은 아니다.
이건 AI가 없던 시절에도 똑같다. “안 만드는 것도 개발이다” 라는 말은 AI 존재전부터 있었던 말이다. 개발자가 하는 일은 단지 코드만 짜는 일이 아니라, ‘이건 정말 만들어야 하는지’, ‘꼭 지금 고쳐야 되는지’, ‘이 변경이 정말 사용자의 문제를 푸는지’ 이런걸 보는 일도 개발이다.
한 줄만 고쳐달라고 했는데
AI에게 알잘딱깔센(알아서 잘 딱 깔끔하고 센스있게)을 기대한다.
한 줄만 고쳐달라고 하면 그 한 줄만 고치고, 주변에 위험한 부분이 있으면 알려주되, 내가 시키지 않은 작업은 건드리지 않으면 좋겠다. 실제로 써보면 알아서는 꽤 잘한다. 문제는 잘딱깔센이 자주 안 맞는다는 점이다.
예를 들어 특정 함수에서 값 하나만 바꾸고 싶었다.
가중치를 0.8에서 0.9로 바꿔줘.그런데 AI는 주변 코드까지 같이 본다.
오래된 문법이 보이면 최신 문법으로 바꾸고 싶어하고, 암묵적으로 작동하는 코드를 명시적으로 수정하고, 원하지 않았던 예외처리까지 챙긴다. 사실 이렇게만 들으면 좋은 행동이고, 좋은 의도다.
문제는 그 순간 이 작업의 성격이 바뀐다는 점이다.
처음에는 작은 수정이었는데, 어느새 동작 계약이 바뀌고, 리뷰해야 할 범위가 늘어난다. “이 변경도 필요한가?”를 설명해야 하는 일도 생긴다. 또 한 번 들어간 코드는 바로 사라지지 않는다. 애매한 추상화, 과한 일반화, 불필요한 테스트, 괜히 늘어난 파일 구조는 다음 변경의 비용이 된다.
AI가 쌓은 것도 복리로 앉는다.
그래서 어느 순간부터 AI가 더 가고 싶어 하는 지점에서 멈추게 만들 필요가 있다고 느꼈다.
그래서 멈추게 했다
그래서 아예 멈춤 규칙을 넣었다.
작업이 아래 조건 중 하나라도 만족하면, 다음 구현으로 넘어가지 말고 먼저 상태를 보고한다.
* 계획에 없던 파일을 새로 수정해야 하는 경우
* 계약 변경이 처음 계획보다 커진 경우
* 원인 해결이 아니라 증상 완화로 흐르기 시작한 경우
* 설명이 흐려지거나 가정이 많아진 경우
* 검증 없이 구현만 누적되는 경우실제로 쓰는 규칙은 조금 더 길지만, 핵심은 이거였다.
“더 잘해”가 아니라 “이럴 땐 멈춰”
AI가 알아서 좋은 판단을 하길 기대하는 대신, 판단이 필요한 지점에서 대화를 만들도록 한 것이다.
같은 작업을 룰이 있는 경우와 없는 경우로 Eval 테스트로 몇 번 돌려봤다. 룰이 없을 때는 시킨 것 외의 변경이 자주 섞였고, 룰이 있을 때는 본문 변경과 제안이 분리됐다. 정밀한 검증이라고 말하긴 어렵다. 일부러 AI가 손대고 싶어 할 만한 편향적인 코드를 준 것도 맞다. 다만 내가 겪던 문제에는 꽤 좋은 효과를 보였다.
AI랑 진정한 협업을 하고 있다고 느꼈다.
멈춘다고 끝은 아니다
멈춤 규칙을 넣으면 AI가 이런 식으로 묻는다.
이 부분은 같이 정리하는 게 좋을 것 같습니다. 진행할까요?여기서 내가 그냥 “네”라고 하면 어떻게 될까?
겉으로는 내가 승인한 것처럼 보인다.
AI도 물어봤고, 나도 답했으니까. 근데 사실은 별로 판단하지 않은 상태일 때가 많았다. 왜 같이 정리해야 하는지, 지금 해도 되는 일인지, 다른 방법은 없는지 확인하지 않은 채로 그냥 “네”라고 한 거니까. AI가 알아서 하지 못하게 막아놓고, 멈춘 다음에는 다시 “알아서 잘 하겠지” 하고 넘긴 셈이다. 여기서 조금 웃겼다.
나는 AI를 멈추게 만들어놓고, 정작 멈춘 자리에서는 다시 알잘딱깔센을 기대하고 있었다.
“네”는 판단이 아닐 수 있다
AI가 추론을 못 한다는 뜻은 아니다.
Claude Opus 4.5 막 나온 시절에는 나는 거의 “ㅇㅇ” 프롬프트(?)만 사용했다. 클로드가 알아서 정말 잘했다. 나 대신 생각을 했고 심지어 잘했다. AI 들은 삘 타면 꽤 그럴듯한 방향으로 나아간다. 다만 이 AI의 추론이라는 것은 본질적으로는 비결정적인 확률적 요소이기 때문에 운에 맞겨 처리하게 둘 순 없다.
나는 이것을 주로 ‘슬롯머신’에 비유한다.
잘 나오면 좋도, 이상하면 다시 뽑고, 또 이상하면 짜증나는 식으로 개발하고 싶지는 않았다.
그래서 요즘에는 AI가 멈춘 순간에, 이 정도는 한 번 더 물어보려고 한다.
이건 왜 이렇게 처리해야해?
다른 대안/방안은 없어?
이걸 꼭 지금 처리해야만 할까?대단한 질문이 아니다. 그냥 내가 생각하기 위한 질문이다. AI가 멈췄다는 건, 거기서 내가 다시 생각할 기회가 생겼다는 뜻일 수 있다. 그 기회에 우리는 본질적인 고민을 해볼 수 있다.
내가 지금 쓰는 방식
지금은 대충 이렇게 쓴다:
요청한 작업 범위 줄이기
범위를 벗어나면 멈추라고 하기
멈춘 이유를 짧게 설명하게 만들기
승인하기 전에 이유와 대안을 물어보기
이번에 할 일과 나중에 할 일을 구분하기
말로 쓰면 복잡해 보이는데, 실제로는 이 정도다.
요청한 것만 최소 변경으로 처리해줘.
계획에 없는 파일 수정, 계약 변경, 리팩터링이 필요하면 먼저 멈추고 보고해줘.
멈췄다면 바로 진행하지 말고,
왜 필요한지 / 다른 방법은 없는지 / 이번 PR에서 해도 되는지 알려줘.이 정도만 해도 AI의 작업 방식이 조금 달라진다.
AI가 더 못 하게 되는 게 아니라, 인간이 판단하고 개입할 지점이 생긴다.
멈추라고 말할 권리
AI에게 알잘딱을 기대하는 건 자연스럽다.
나도 여전히 기대한다. 매번 모든 걸 하나하나 설명하고 싶지는 않다. 잘 맡기고 싶은 일도 많고, 실제로 맡기면 잘하는 일도 많다. 다만 AI를 잘 쓴다는 말이 토큰을 더 태우고, 에이전트를 더 오래 돌리고, 더 많은 산출물을 만드는 쪽으로만 흐르는 건 싫다.
개발자가 해야 하는 본질적인 질문은 이런거라고 본다.
이 기능은 누굴 위해 만드나
누굴 위해 이렇게 설계했나
누구의 문제를 얼마나 푸나
지금 만드는 게 맞나
안 만드는 게 더 나은 건 아닌가
예전에는 내가 이런걸 잘 못했다. 그냥 시키면 만들었다. 왜냐면 내가 만들 수 있었으니까. 역설적으로 모두가 만들 수 있는 지금에서야 이런걸 깨달았다. 왜 멈춰야 하는지, 어떻게 만들어야 하는지. 내가 잘하던 코딩은 이제 이 녀석이 더 잘하고, 나는 무엇에 더 집중해야 하는가 고민하게 만들었다.
AI가 코드를 빨리 만들수록, AI에게 멈추라고 말할 수 있어야 한다. 코드는 생성되면 끝이 아니다. 앞으로 이 코드를 유지보수 해야 할 동료들이 존재하며, 이것을 관리하는 건 여전히 사람이다. 이 코드가 진정한 가치가 있는 것은지 고민하는 것이 지금은 가장 중요하다고 생각한다.
그리고 AI가 멈출 때 나도 같이 멈출 수 있어야 한다.
나도 아직 잘 안 된다.
지금도 “ㅇㅇ”라고 답하려다가 멈췄다.
웃기지만 그래서 이 글이 필요하다고 생각했다.