더하자는 말은 쉽고, 빼자는 말은 어렵습니다

회의에서 "이 기능을 더하면 어떨까요"는 쉽게 나옵니다. "이 기능을 빼면 어떨까요"는 좀처럼 나오지 않습니다. 보고서의 항목도, 규정집의 조항도, 체크리스트의 줄도 늘어나는 쪽으로만 움직입니다. AI로 만드는 일이 쉬워진 뒤로 이 기울기는 더 심해졌습니다. 더하는 쪽은 빨라졌고, 빼는 쪽은 그대로이기 때문입니다. 이 글은 빼자는 말이 왜 안 나오는지, 그리고 그 말이 나올 자리를 어떻게 만들지를 적습니다.

빼자는 말이 안 나오는 이유는 보통 사람에게서 찾습니다. 자기가 만든 것을 못 놓는다, 남이 만든 것을 빼자고 할 용기가 없다, 일을 줄이자는 말은 열심히 안 하겠다는 말로 들린다. 전부 맞는 말입니다. 그런데 이 설명대로라면 용기 있는 사람이 들어와야 빼기가 시작됩니다. 저는 다른 쪽을 먼저 보고 싶습니다. 빼기를 떠올릴 자리가 일 안에 있는가.

다섯 역할 중 하나가 지우는 역할입니다

Claude Code를 만든 보리스 체르니는 2026년 6월에 자기 팀에서 보이는 일의 모양을 다섯으로 나눠 적었습니다. 새 아이디어를 쏟아내는 사람(Prototyper), 그것을 실제로 쓸 수 있는 제품으로 만드는 사람(Builder), 화면을 정리하고 코드를 단순하게 하고 기능을 내리는 사람(Sweeper), 만들어진 제품을 고쳐가며 시장에 맞추는 사람(Grower), 커진 시스템을 안전하고 빠르게 지키는 사람(Maintainer)입니다. 직함이 아니라 하는 일의 모양으로 나눈 것입니다.

제 눈에 들어온 것은 셋째였습니다. 둘은 만들고, 하나는 키우고, 하나는 지킵니다. 남은 하나가 통째로 지우는 일입니다. 만드는 사람이 틈날 때 하는 정리가 아니라, 다섯 가운데 한 자리를 차지하는 일로 세운 것입니다.

왜 그 자리가 따로 서야 할까요. 만든 사람이 자기가 만든 것을 지우면 되지 않을까요. 그게 잘 안 된다는 것을, 연구 하나와 이 사이트의 기록이 같은 방향으로 말해줍니다.

사람은 더하기부터 떠올립니다

2021년 네이처에 실린 People systematically overlook subtractive changes는 여덟 번의 실험으로 사람이 무엇을 고칠 때 어느 쪽부터 떠올리는지 봤습니다. 레고 구조물을 안정시키라고 하면 대부분이 블록을 더 얹었습니다. 가운데 블록 하나를 빼면 되는 구조였는데도요. 연구진은 사람이 개선안을 찾을 때 더하는 쪽을 기본값으로 탐색하고, 그래서 빼는 쪽을 체계적으로 놓친다고 썼습니다. 빼는 쪽을 생각해보라는 단서가 없을 때, 한 번만 보고 넘어갈 때, 머리가 다른 일로 바쁠 때 더 그랬습니다.

이 세 조건을 회사에 가져오면 전부 맞습니다. 회의는 "무엇을 더할까"로 열리고, 안건은 한 번 보고 넘어가며, 모두가 바쁩니다. 빼자는 말이 안 나오는 것은 누가 소심해서가 아닙니다. 빼기를 떠올릴 조건이 없는 자리에서 사람은 더하기만 떠올립니다.

여기에 회사의 셈법이 겹칩니다. AX 기업을 만들어가는 순서에서 지우는 일은 성과로 세어지지 않고 되돌려진 일은 미숙함으로 평가된다고 적었습니다. 떠올리기도 어려운 일이 셈에서도 빠져 있으니, 빼자는 말은 두 번 걸러집니다. 한 번은 머릿속에서, 한 번은 평가표에서.

만드는 비용이 떨어지면 무엇이 쌓이나

실행비용이 저렴해질수록 목표가 비싸집니다에서 만드는 일이 쉬워지면 무엇을 만들지 정하는 일의 값이 오른다고 적었습니다. 같은 이유로 또 하나의 값이 오릅니다. 만든 것을 거두는 일입니다.

예전에는 기능 하나를 더하는 데 사람 몇 주가 들었습니다. 그 비용이 더하기를 걸러주는 문턱이었습니다. 지금은 오후 한 번에 초안이 나옵니다. 문턱이 낮아지면 더해지는 것이 늘고, 늘어난 것은 저절로 줄지 않습니다. 더하는 속도만 바뀌고 빼는 속도는 그대로라면, 시간이 갈수록 제품도 규정도 보고서도 무거워지는 쪽으로만 갑니다. 체르니가 지우는 일을 다섯 중 하나로 따로 세운 이유도 여기에 있다고 봅니다. 만드는 비용이 떨어진 팀에서 지우는 일은 누가 맡아야 하는 일이 됩니다.

이 사이트에서 뺀 것들

이 사이트의 커밋 기록을 훑어보니 열에 하나쯤은 무엇을 뺐다는 기록이었습니다. 그 가운데 셋을 적습니다.

글 끝에 제가 만든 서비스 카드를 세웠던 적이 있습니다. 글에서 그 서비스를 말했으니 아래에 보여주면 좋겠다는 생각이었습니다. 그런데 글 끝에 자기 서비스 카드가 서자 글이 그 서비스의 광고로 읽혔습니다. 카드를 지웠습니다. 그리고 화면에서만 지우지 않고 그 카드를 그리던 데이터 칸까지 지웠습니다. 보이지 않는 칸을 남겨두면 언젠가 누군가 그 칸을 보고 다시 화면을 만들기 때문입니다. 반쯤 지운 것은 지운 것이 아니었습니다.

푸터에 오늘 방문자 수를 띄웠던 적도 있습니다. 사람이 오는 사이트라는 증거로 삼으려 했는데, 한 자리 수인 날이 많았습니다. 작은 숫자는 증거가 아니라 반대 증거였습니다. 숫자를 내리고, 그 숫자를 세던 코드도 같이 지웠습니다.

대문 첫 화면에 보라색 버튼을 하루 세운 적이 있습니다. 누르면 바로 아래 절로 스크롤만 하는 버튼이었습니다. 다음 날 뺐습니다.

셋의 공통점이 하나 있습니다. 뺄 때마다 왜 뺐는지를 프로젝트 문서에 적어뒀습니다. 지운 것은 화면에서 사라지지만, 지운 이유는 남아 있어야 합니다. 그래야 몇 달 뒤에 같은 것을 다시 더하자는 말이 나올 때 "그때 이래서 뺐다"가 나옵니다. 이유 없이 사라진 것은 돌아옵니다.

빼자는 말이 나올 자리를 만듭니다

연구가 준 단서는 하나입니다. 빼는 쪽을 생각해보라는 신호가 있으면 사람은 빼는 답도 찾습니다. 그러니 빼는 사람이 나타나길 기다리기보다, 빼기를 떠올릴 자리를 일 안에 넣어두는 쪽이 빠릅니다.

1. 더하자는 안건에 한 줄을 붙입니다. "이것을 더하면 무엇을 뺄 수 있는가." 답이 없어도 됩니다. 묻는 것만으로 탐색의 방향이 하나 늘어납니다.
2. 뺀 것을 더한 것과 같은 자리에 적습니다. 변경 기록이든 주간 보고든, 더한 것만 적는 칸 옆에 뺀 것을 적는 줄을 둡니다. 적히는 일은 세어지는 일이 됩니다.
3. 반쯤 지우지 않습니다. 화면에서 내리면 그것을 만들던 것도 같이 내립니다. 남겨둔 절반이 다시 전체를 부릅니다.
4. 뺀 이유를 뺀 것 옆에 남깁니다. 한 줄이면 됩니다. 그 줄이 같은 것을 다시 더하려는 다음 사람을 멈추게 합니다.

검토는 만드는 것보다 어렵습니다에서 틀린 것을 알아보려면 맞는 것을 알아야 한다고 적었습니다. 빼는 일도 같습니다. 무엇을 빼도 되는지 알려면 그것이 왜 있는지를 알아야 하고, 그걸 아는 사람은 대개 만들어본 사람입니다. 만드는 일이 쉬워졌다고 그 지식까지 쉬워진 것은 아닙니다. 그래서 빼는 일은 더하는 일보다 어려운 일이고, 그만큼 값이 오르는 일입니다.

더하자는 말은 앞으로도 쉽게 나올 것입니다. 빼자는 말이 나오는지가 그 팀이 자기가 만든 것을 감당하고 있는지를 알려줍니다.

이번에 더한 것으로, 무엇을 뺐습니까.