개발자 커뮤니티 60건을 세어보니 댓글이 거의 0이었다

개발자 커뮤니티 게시판을 오랜만에 열었다. 뽐뿌 개발자포럼인데 하루에 글이 두세 개 올라오는 정도다. 눈에 걸린 건 특정 글이 아니라 목록의 생김새였다. 제목 대부분이 "이런 걸 만들었습니다"였고, 그 옆의 댓글 칸이 거의 다 비어 있었다.

숫자를 세어보기로 했다. 목록 페이지 두 장, 7월 18일부터 8월 16일까지 60건. 조회수와 댓글 수가 한 테이블에 서버에서 그려져 나오니 세는 건 어렵지 않았다.

세고 나서 알게 된 건, 사람들이 만든 것 자체가 아니라 만들었다는 사실에 고무돼 있다는 쪽이었다. 그리고 만드는 건 이제 정말 딸깍 한 번이다. 문제는 그다음인데, 그 다음이 있는 글이 목록에 거의 없었다.

60건이 어떻게 생겼는지

먼저 센 값이다. 개별 게시글 페이지는 댓글 영역이 자주 안 잡힌다. 같은 글을 개별 페이지에서 열면 댓글이 2개인데 목록에서 보면 32개다. 그래서 목록 페이지 값을 기준으로 했다.

1위가 개발자 연봉 수준으로 조회수 20,112 에 댓글 51개, 7월 29일 글이다. 2위가 홈페이지 제작 견적으로 5,610 에 32개, 8월 7일이다. 3위부터 성격이 바뀐다. 개인 프로젝트 소개 글이 조회수 1,750 에 댓글 1개, 4위인 클로드 코드와 일자리 불안 글이 1,258 에 3개다.

1위가 20,112회, 3위가 1,750회다. 11.5배 차이다. 그리고 1위와 2위는 둘 다 돈 얘기다. 하나는 내가 받는 돈, 하나는 내가 내는 돈.

댓글 쪽은 더 선명하다. 최근 30건 중 댓글이 5개 이하인 글이 26건이다. 5개를 넘긴 건 네 건뿐이고 그중 하나가 32개짜리 견적 글이다.

그러니까 목록의 모양은 이렇다. 만든 것을 소개하는 글이 계속 올라오고, 조회수는 300~900회쯤 나오고, 댓글은 0이다. 그러다 한 달에 한두 번 돈 얘기가 올라오면 조회수가 스무 배로 뛴다.

만드는 사람은 많고, 그걸 보는 사람은 적다.

300만 줄의 내역

만든다는 게 지금 무슨 뜻인지부터 봐야 한다.

AI 에이전트 2,000개를 동시에 돌려 일주일 만에 브라우저를 300만 줄 만들었다는 얘기가 돌았다. 렌더링 엔진은 Rust로 밑바닥부터, 커스텀 JS VM까지.

트윗으로는 그게 어떤 300만 줄인지 알 수 없다. 기사도 대체로 그 트윗을 옮긴 것이었다. 그래서 레포를 클론해서 셌다.

300만 줄은 진짜였다. git ls-files '*.rs' | xargs wc -l이 3,162,904를 돌려줬고 라이브러리는 릴리스 프로파일로 1분 35초 만에 빌드됐다.

내역이 다른 얘기를 했다.

전체 Rust 줄 수가 3,162,904 인데 그중 vendor/ 가 112만 줄을 넘는다. vendor/ecma-rs 하나만 1,082,164 줄이다. Cargo.lock 에 걸린 크레이트는 760개다.

vendor/가 전체의 3분의 1을 넘는다. 안에 든 taffy는 Dioxus 팀의 레이아웃 엔진이고 selectors는 Servo의 CSS 셀렉터 매칭 크레이트다. 남이 쓴 코드를 레포 안으로 복사해 넣은 것이다. HTML 파싱은 html5ever를 쓴다. 그것도 Servo다.

그리고 cargo test는 테스트에 실패한 게 아니라 테스트 빌드가 컴파일되지 않았다. 에러 하나는 한 파일 안에 mod tests가 두 번 선언돼 있다는 것이었다. 241번째 줄에 하나, 965번째 줄에 하나.

이게 지금 "만들었다"의 실체에 가깝다. 새로 쓴 게 아니라 이미 있던 것들을 빠르게 모아 붙인 것이고, 붙는 것까지는 되는데 검증 경로는 아직 안 열려 있다. 300만이라는 숫자가 큰 게 아니라, 그 숫자가 무엇으로 채워졌는지를 아무도 안 세고 있었다.

딸깍이면 남도 딸깍이다

여기서부터가 4월에 이미 적어둔 얘기다. 아래 인용은 전부 내가 운영하는 다른 블로그 apple-io.com에서 발췌한 것이고, 내가 쓴 글이다.

진입장벽이 낮아졌다는 건 나한테만 낮아진 게 아니다. 경쟁자한테도 똑같이 낮아졌다. 내가 AI로 3일 만에 만든 걸, 다른 누군가도 AI로 3일 만에 복사할 수 있다.

AI가 구현했다는 말은, 같은 말 하면 누구든 똑같은 게 나온다는 뜻이다. 아이디어가 아무리 좋아도 구현이 AI라면 그 아이디어를 본 사람이 하루 만에 복제할 수 있다.

— apple-io.com, 딸깍으로 만든 제품은 딸깍으로 복사된다 (2026-04-23) 및 바이브 코딩 강의 결제하기 전에 이 글을 읽어라 (2026-04-12) 에서 발췌

이 얘기를 4월에 하면 대체로 두 가지 반응이 왔다. "결국 코딩 잘하면 되는 거 아니냐"와 "그렇게까지 안 해도 돌아간다". 두 번째가 더 흔했다.

지금 게시판에 올라오는 앱 소개 글들이 정확히 그 위치에 있다. 만든 건 사실이다. 다만 그게 그 사람의 것인가는 다른 질문이다. 같은 문장을 넣으면 같은 게 나오는 결과물에는 그걸 만든 사람의 몫이 얼마나 들어 있나. 조회수 345회에 댓글 0개인 글들이 그 답을 이미 알고 있는 것처럼 보인다.

그런데 복제 가능하다는 건 이 얘기의 절반이다. 나머지 절반이 더 중요하다.

고치라고 시키면 다른 데가 깨진다

만드는 것과 고치는 것은 다른 일이다. 그리고 딸깍은 만드는 쪽에만 작동한다.

학습 관리 시스템 하나를 열어놓고 "코드 재설계 해줘" 한 줄로 리팩토링을 시작한 적이 있다. 그 기록에서 그대로 옮긴다.

초반 80%까지는 진짜 빨랐다. 요구사항 몇 줄에 그럴듯한 코드가 나오고, 빌드가 통과하고, 화면이 떴다. 남은 20%에 들어서면서 이렇게 됐다.

이슈가 하나 뜬다. 프롬프트를 바꿔서 다시 시킨다. 안 풀린다. AI는 원인을 하나 지목하는데, 그 지목이 틀렸다. 틀렸는데 문장은 아주 단호하다. 나는 그 단호함에 한 번 끌려간다. 시킨 대로 고친다. 그러면 다른 데가 깨진다. 깨진 데를 고치라고 하면 처음 고쳤던 데가 다시 돌아온다.

틀린 지목에는 특징이 있었다. 원인을 하나 짚어주는데, 근거를 물으면 근거를 대는 대신 다른 원인을 짚는다. 그러면서 앞의 지목을 취소한다는 말은 안 한다. 두 번째 지목도 첫 번째만큼 단호하다. 나중에 셋을 나란히 놓고 보면 서로 양립할 수 없는 진단인데, 대화 흐름 안에서는 그게 안 보인다. 각각이 그 순간의 질문에는 잘 맞는 답이었기 때문이다.

이 루프에서 제일 지치는 건 진전이 없다는 게 아니었다. 진전이 있는지 없는지 판단할 기준이 나한테 없다는 쪽이었다. 코드가 늘어나는 건 보이는데, 그게 원래 그리려던 구조에 가까워지는 중인지 멀어지는 중인지 말할 수가 없었다.

여기가 게시판의 "만들었습니다" 글이 절대 도달하지 않는 지점이다. 만들 때는 기준이 필요 없다. 화면이 뜨면 성공이니까. 고칠 때는 화면이 뜨는 게 성공의 증거가 안 된다. 다른 데가 조용히 깨져 있을 수 있기 때문이다.

이 루프 자체는 4월에 이미 적어뒀다.

뭔가 만들다 보면 반드시 에러가 난다. 개발자는 에러 메시지를 읽고 어디가 문제인지 파악한다. 비개발자는 빨간 글씨를 보고 AI한테 붙여넣는다. AI가 고쳐준다. 또 에러. 이 루프가 끝없이 반복되다가 어느 순간 "처음부터 다시 만드는 게 빠르겠다"가 된다. 영상에서 이 장면은 나오지 않는다.

AI는 모르면 "모르겠습니다"라고 안 한다. 그럴듯한 답을 만들어서 확신 있게 내놓는다.

— apple-io.com, 바이브 코딩 강의 결제하기 전에 이 글을 읽어라 (2026-04-12) 에서 발췌

10년 넘게 코드를 만진 사람이 같은 루프에 들어갔다. 차이는 빠져나올 때 생긴다. 에러 메시지를 읽을 수 있으면 AI의 단호한 오진을 세 번째쯤에는 알아본다. 못 읽으면 그 단호함을 계속 따라간다. 게시판의 앱 소개 글이 완성 시점에서 끊기는 이유가 여기 있을 것이다. 그다음이 없는 게 아니라, 그다음이 캡처할 수 있는 모양이 아니다.

문서를 만들었다고 설계한 게 아니었다

두 번째 시도에서는 문서부터 만들었다. docs/를 파고 아키텍처 개요와 모듈 설명과 데이터 흐름을 정리했다. 기준이 있으니 다르겠지 싶었다.

버그를 하나 물고 들어가자마자 이상해졌다. 버그마다 AI가 큰 구조 변경을 제안했다. 서비스 레이어를 하나 더 두자, 이 훅을 분리하자, 상태 관리 방식을 바꾸자. 제안 하나하나는 나쁘지 않았다. 문제는 그게 매번 다른 방향이었다는 것이다. 어제는 A로 쪼개자고 했다가 오늘은 B로 합치자고 한다. 둘 다 문서에는 위배되지 않는다. 문서에 그 층위의 얘기가 아예 없었으니까.

유틸과 훅도 계속 중복됐다. 같은 일을 하는 함수가 두 군데 생기고, 며칠 뒤에 세 번째가 생겼다.

원인은 문서에 있었다. "이 모듈이 무엇을 하는가"는 적혀 있었는데 "이 모듈이 무엇을 하지 않는가"가 없었다. 책임의 바깥 경계가 비어 있으면 AI는 그 빈자리를 자기 판단으로 채운다. 그리고 채울 때마다 다르게 채운다.

이게 구멍이 생기는 메커니즘이다. AI가 실수해서 구멍이 나는 게 아니다. 정해지지 않은 자리를 매번 성실하게, 매번 다르게 메우는 것이다. 한 번 시킬 때는 그게 보이지 않는다. 열 번 시키면 열 개의 다른 판단이 코드에 남는다.

세 번째 시도는 모델을 여러 개 붙였다. 답이 갈리는 자리가 설계의 빈틈이라는 걸 그때 알았고, 결제 흐름까지 포함해 실제로 동작하는 기능을 완성했다. 그런데 이걸 다른 사람에게 넘기려는 순간 걸렸다. 같은 문서, 같은 모델 조합, 같은 프롬프트를 줘도 같은 결과가 안 나왔다. 모델 셋이 다른 답을 냈을 때 어느 쪽이 이 도메인에서 말이 되는지 고르는 판단이 전부 내 머릿속에 있었기 때문이다.

재현이 안 되면 그건 방법이 아니라 재주다.

네 번째는 크로스플랫폼 데스크톱 애플리케이션이었다. 범위를 크게 잡았고, 적용을 중단했다.

원인은 AI의 한계가 아니라 내가 인지한 설계 깊이였다.

처음부터 비어 있는 자리

고치다 생기는 구멍만 있는 게 아니다. 딸깍으로 만든 순간부터 비어 있는 자리가 따로 있다.

"쇼핑몰 만들어줘"라고 하면 로그인, 상품 목록, 장바구니가 나온다. 이건 만들어준다. 아래는 물어보지 않으면 안 만들어준다. 4월에 적어둔 목록이다.

• 인증 토큰 만료 처리 → 로그인이 영원히 유지됨. 해커가 토큰 탈취하면 끝
• 비밀번호 해싱 → 평문 저장. DB 털리면 비밀번호 그대로 노출
• SQL 인젝션 방어 → 입력창에 특수문자 넣으면 DB 날아감
• Rate Limiting → 로그인 시도 무제한. 브루트포스 공격 무방비
• 에러 메시지 처리 → 서버 내부 구조가 에러에 그대로 노출
• CORS 설정 → 아무 사이트에서나 API 호출 가능

이것들이 빠진 상태로 "앱 완성됐다"고 올라온다. 사용자 없을 때는 문제없다. 사용자가 생기는 순간 시한폭탄이 돌아간다.

— apple-io.com, 바이브 코딩 강의 결제하기 전에 이 글을 읽어라 (2026-04-12) 에서 발췌

이 목록의 공통점은 안 만들어도 화면이 똑같이 뜬다는 것이다. 그래서 캡처에는 안 나오고, 자랑글에도 안 나오고, 만든 사람도 모른다. 앞에서 브라우저 레포의 cargo test가 컴파일조차 안 됐던 것과 같은 종류다. 돌아가는 것과 검증된 것은 다른 상태인데, 딸깍은 앞의 것만 보장한다.

그리고 이 자리들은 나중에 "고쳐줘"로 채우기가 제일 어려운 자리다. 인증 만료 처리를 뒤늦게 넣으라고 시키면 세션을 만지게 되고, 세션을 만지면 로그인 흐름이 흔들리고, 그걸 고치면 또 다른 데가 깨진다. 앞 절의 루프가 여기서 다시 돈다.

순서를 붙이니 fix가 51개에서 3개로 줄었다

같은 문제를 다른 저장소에서 숫자로 봤다. 유니티로 만들던 모바일 게임인데 3월 말에 시작해서 7월 말이 마지막 커밋, 넉 달에 커밋 219개다. 커밋 타입을 세봤다.

fix가 51개, 전체의 23%였다. 문제는 개수가 아니라 분포였다. 51개가 4월 첫 주에 몰려 있다.

04-06 fix: StageSelectController long→int 캐스트 오류 + deprecated ScaleMode 수정
04-06 fix(assets): 프리팹을 Resources/로 이동하여 런타임 로드 복구 + 목업 코드 정리
04-05 fix(sprites): HeroManager heroId 양방향 폴백 + 전투 HUD 이미지 로드 수정
04-05 fix(sprites): heroId 접두사 불일치 수정 — 영웅 이미지 로드 복구

4월 19일에 설계서 17개를 쓰고 소스를 통째로 지웠다. 5월에는 작업에 Step 1~53으로 번호를 붙였다. 그 달 fix는 3개였다.

같은 AI, 같은 사람, 같은 게임이다. 바뀐 건 지시의 순서뿐이다.

딸깍의 청구서는 이렇게 온다. 첫 주에는 오히려 빠르다. 건너뛴 분량이 나중에 fix 51개 형태로 돌아온다. 게시판의 "만들었습니다" 글 상당수가 아직 그 첫 주에 있고, 거기서 멈추면 51개를 볼 일이 없다. 프로젝트가 넉 달을 안 가기 때문이다.

그래서 자리가 옮겨간다

여기까지가 "코딩만 잘하면 되는 것 아니냐"에 대한 답이다.

AI가 코드를 얼마나 잘 쓰느냐와 무관하게, 개발자가 서 있는 자리가 코드 안에서 코드 바깥으로 옮겨가고 있다. 만드는 일이 딸깍이 됐기 때문에 남는 일이 바뀐 것이다.

설계자 자리는 무엇을 하지 않을지까지 미리 정해서 AI 가 채울 빈자리를 없애는 일이다. 이게 없으면 매번 다르게 메워지고 유틸이 세 벌 생긴다. 관찰자 자리는 나온 것이 주장한 것과 같은지 직접 세는 일이다. 이게 없으면 300만 줄과 vendor 112만 줄을 구분 못 한다. 관리자 자리는 쓰는 자원의 총량과 분포를 아는 일이고, 없으면 절감률과 비용을 감으로 말하게 된다. 책임자 자리는 틀렸을 때 이름이 적히는 것을 받는 일이다. 없으면 아무도 안 보는 자리가 사고 날 때까지 남는다.

관리자 쪽은 숫자로 겪었다. 어떤 작업 뒤에 "토큰이 13~20% 줄었다"고 적었는데, 며칠 뒤 그 문장이 걸렸다. 13~20%는 분자다. 분모가 없었다. 넉 달치를 집계하니 6억 4,619만 토큰이었고 그중 96.72%가 캐시 읽기였다. 세기 전 짐작은 1억 대였다. 자릿수가 틀렸다.

책임자 쪽은 남의 사고에서 봤다. 2022년 판교 데이터센터 화재 때 어떤 회사는 서버를 점검하다 두 달 전에 이미 일어난 침해를 발견했다. 침입 경로는 보안 업데이트를 장기간 안 한 노후 서버였다. 대응을 총괄한 CISO는 그 기간에 간경화 진단을 받았고 2024년 3월 사망했다. 회사는 근로복지공단에 해킹이 없었다고 답했다. 따로 정리했다. 만드는 속도가 빨라지면 운영해야 할 것도 그만큼 빨리 늘어나는데, 책임지는 속도는 그대로다.

넷 다 코드를 쓰지 않는다. 그런데 넷 다 코드를 못 읽으면 할 수 없다. 그래서 "코딩이 필요 없어진다"도 틀리고 "코딩만 잘하면 된다"도 틀린다. 코딩은 자격 요건이 됐지 결과물이 아니게 됐다.

조직에서는 이게 사람으로 갈린다. 초안이 싸게 나오니 검토 요청이 는다. 초안 생산은 자동화됐는데 검토는 자동화가 안 돼서 검토할 수 있는 사람 앞에 줄이 선다. 초안을 만들 수 있는 사람은 늘고 그 초안이 맞는지 판단할 수 있는 사람은 안 는다. 게시판에서 "초중급이 위험하다"고 말하는 건 이 갈림의 한쪽 면이고, 다른 면은 판정하는 자리가 늘었는데 거기 설 사람이 부족하다는 것이다.

딸깍 한 방에 고무되는 지점

게시판의 조회수 1위가 아직 연봉인 건, 이 네 자리가 아직 값으로 안 매겨졌기 때문이다. 설계자, 관찰자, 관리자, 책임자. 넷 다 채용 공고의 항목이 아니다. 환산이 안 되니 계속 코딩 실력으로 묻는다.

"만들었습니다" 글에 사람들이 고무되는 건 만드는 장면이 보이기 때문이다. 화면이 뜨는 건 캡처가 되고, 고치다 다른 데가 깨지는 건 캡처가 안 된다. 그래서 목록에는 완성 시점만 쌓이고, 그 뒤에 뭐가 있는지는 각자 혼자 만난다.

AI는 코드를 쓴다. 무엇을 하지 않을지 정하지 않고, 자기가 만든 것을 세지 않고, 자기가 쓴 자원을 모르고, 틀렸을 때 이름을 적지 않는다.

딸깍으로 만든 건 딸깍으로 복사된다. 그런데 딸깍으로 고쳐지지는 않는다.

4개월 뒤에 그 게시판에 뭐가 올라오는지 다시 세어볼 생각이다.