설계는 내가 했지만 결과물은 AI가 만들었습니다
개발자 게시판을 넘기다가 홍보글 네 개를 연달아 봤습니다. 오목 게임 앱이 하나, 테슬라 충전소 위치를 검색해 주는 웹앱이 하나, 캐릭터 관련 페이지가 하나, 그리고 CMS 구축 서비스가 하나였습니다.
넘기고 나서 피곤했습니다. 그런데 왜 피곤한지를 한동안 정확히 못 짚었습니다.
만든 것 자체는 아무 문제가 없습니다
먼저 정리해야 할 게 있습니다. 저 넷 중에 만들어서는 안 될 것은 하나도 없습니다.
오목 앱을 만들었으면 좋은 겁니다. 15×15 보드에 난이도 열 단계를 붙이고 친구 초대 코드까지 넣었으면 실제로 손이 갔습니다. 충전소 검색 웹앱도 마찬가지입니다. 그건 아마 만든 사람이 실제로 불편했던 데서 출발했을 겁니다. 충전소마다 사업자가 다르고 앱이 따로 놀아서, 한 화면에서 보고 싶었을 겁니다. 그 불편이 진짜였으니까 만들었을 거고요.
AI를 써서 만들었다는 것도 문제가 아닙니다. 저도 씁니다. 지금 이 블로그가 그렇게 돌아갑니다.
그러니까 피로의 원인은 "AI로 만들었다"가 아닙니다. 그건 아무 문제가 아닙니다.
걸린 건 문장 하나였습니다. CMS 쪽 글에 이런 문장이 있었습니다.
10년도 이상 웹개발로 쌓은 AI 기술로 웹사이트를 현대화시켰습니다
이 문장을 몇 번 다시 읽었습니다. 읽을 때마다 어딘가 미끄러졌습니다.
이 문장이 하는 일
이 한 문장 안에 서로 다른 두 개가 들어 있습니다. 앞쪽은 10년의 경력이고, 뒤쪽은 그 결과로 나온 산출물입니다. 그리고 문장은 이 둘을 접착제 없이 그냥 붙여 놓습니다. 10년이 있었으니 이 결과물이 나왔다는 인상을 만듭니다.
그런데 뒤쪽은 앞쪽이 없어도 나옵니다. 이게 핵심입니다.
CMS 관리자 화면, 에디터, 템플릿 몇 벌, 반응형 레이아웃, 다크 모드, 로그인, 권한 드롭다운. 이 목록은 10년 경력이 있어야 나오는 게 아닙니다. 요구사항을 몇 문장으로 정리해서 넣으면 나옵니다. 경력 3개월인 사람이 넣어도 비슷하게 나옵니다.
그러니까 저 문장은 두 개를 붙였는데, 붙일 근거가 실제로는 없습니다. 앞쪽 경력은 검증할 수 없고, 뒤쪽 산출물은 경력을 증명하지 못합니다. 그런데 둘을 나란히 놓으면 읽는 사람 머릿속에서는 인과가 생깁니다.
여기가 미끄러지던 자리였습니다.
AI로 만들었으면 복제가 더 쉽습니다
그리고 여기서 한 겹 더 들어가면, 좀 이상한 사실이 나옵니다.
보통은 이렇게 생각합니다. AI로 만들었으니까 빨리 만들었고, 빨리 만들었으니까 남들도 빨리 만들 수 있다. 맞는 말이긴 한데, 이유가 속도에만 있는 게 아닙니다.
손으로 만든 코드에는 그 사람만의 이상한 결정이 쌓입니다. 여기서는 이 라이브러리를 안 쓰기로 했고, 저기서는 성능 때문에 캐시를 한 겹 더 넣었고, 이 함수는 예전 데이터 때문에 분기가 세 개고. 이런 결정들은 그 사람이 겪은 사정에서 나옵니다. 그래서 같은 걸 다시 만들려는 사람은 그 사정을 모릅니다. 겉을 따라 만들어도 안쪽이 다르게 나옵니다. 복제가 어려운 이유가 여기 있습니다.
AI가 만든 코드는 반대입니다. 가장 표준적인 답으로 수렴합니다. 그게 잘 만드는 방식이기도 하고요. 같은 요구를 넣으면 비슷한 구조가 나오고, 비슷한 폴더 배치가 나오고, 비슷한 네이밍이 나옵니다. 특이한 결정이 없습니다. 특이한 사정을 안 겪었으니까요.
그래서 AI로 만들었다는 사실 자체가 복제 난이도를 낮춥니다. 남이 베끼기 쉬운 상태로 만들어 놓은 겁니다.
이게 왜 중요하냐면, "AI로 만들었습니다"와 "이건 제 아이디어입니다"가 사실은 서로 밀어내는 문장이기 때문입니다. 앞 문장이 참일수록 뒤 문장은 약해집니다. 그런데 홍보 문구는 둘을 같이 씁니다. 그것도 붙여서 씁니다. AI를 썼다는 걸 능력의 증거로 내밀면서, 동시에 그 결과물을 자기 고유의 것으로 놓습니다.
솔직하게 말하면, 게시판에서 본 그런 사이트들은 하루면 초안이 나옵니다. 일주일이면 클론이 됩니다. 이건 깎아내리려고 하는 말이 아니라 그냥 소요 시간입니다. 그리고 그 시간이 짧은 이유가 바로 AI로 만들었기 때문입니다.
한 가지 더 붙이면, 복제가 쉽다는 게 만든 사람 잘못도 아닙니다. AI한테 잘 만들어 달라고 하면 표준적으로 만들어 줍니다. 그게 좋은 코드의 정의니까요. 이상하게 만들어 달라고 할 이유가 없습니다. 그러니 복제 가능한 결과물이 나오는 건 도구를 잘 쓴 결과에 가깝습니다.
문제는 그 결과물을 들고 나올 때 뭐라고 부르느냐입니다. "AI로 이런 걸 만들어 봤습니다"와 "제가 이런 걸 만들었습니다"는 같은 파일을 가리키면서 전혀 다른 말을 합니다. 앞엣것은 확인 가능한 사실이고, 뒤엣것은 확인할 수 없는 주장입니다.
그리고 이 구분은 읽는 사람한테도 편합니다. 앞엣것으로 적혀 있으면 그냥 결과물을 보면 됩니다. 쓸 만한지 아닌지만 판단하면 되니까요. 뒤엣것으로 적혀 있으면 결과물 말고 사람까지 같이 판단해야 합니다. 그게 피곤합니다. 판단할 근거가 글 안에 없는데 판단을 요구받는 셈이라서요.
게시판을 넘기면서 피곤했던 게 결국 이거였던 것 같습니다. 결과물이 나빠서가 아니라, 결과물만 보고 넘어가면 될 자리에서 자꾸 사람을 같이 평가하게 만들어서요. 그것도 평가할 재료는 하나도 주지 않은 채로요.
하필 CMS인 게 우연이 아닙니다
네 개 중에 CMS 건이 제일 걸렸는데, 생각해 보니 우연이 아니었습니다.
CMS는 이미 답이 나와 있는 문제입니다. 20년 넘게 사람들이 만들어 왔고, 관리자 화면이 어떻게 생겨야 하는지, 글과 카테고리와 태그가 어떤 관계여야 하는지, 미디어 라이브러리가 어디 붙어야 하는지가 사실상 표준화돼 있습니다.
그리고 AI는 답이 이미 있는 문제에서 가장 강합니다. 학습할 게 많았던 자리니까요. 그래서 CMS를 만들어 달라고 하면 놀랄 만큼 그럴듯한 게 나옵니다. 화면만 놓고 보면 상용 제품과 구분이 안 됩니다.
정리하면 이렇게 됩니다. 결과물이 가장 그럴듯하게 나오는 분야가, 고유성은 가장 적은 분야입니다. 답이 이미 있어서 잘 나오는 거니까요.
그런데 홍보 문구는 정확히 반대로 말합니다. "현대화시켰습니다"라고 씁니다. 이미 있던 답을 다시 생성한 걸 혁신으로 부르는 자리입니다.
CMS의 진짜 난이도는 화면에 없습니다
한 가지 더 있습니다. CMS가 실제로 어려운 지점은 만들 때가 아니라 굴릴 때 나옵니다.
권한 모델이 그렇습니다. 편집자와 작성자와 관리자를 나누는 것까지는 드롭다운 하나면 되는데, "이 사람은 자기가 쓴 글만 수정할 수 있고, 발행은 못 하고, 남의 초안은 볼 수 있는데 카테고리는 못 만든다" 같은 조합이 실제 조직에서 나옵니다. 그리고 그 조합이 계속 늘어납니다.
동시 편집 충돌도 그렇습니다. 두 사람이 같은 글을 열어 놓고 한 명이 저장하면 뭐가 어떻게 돼야 하는지. 나중에 저장한 쪽이 이기게 두면 앞사람 작업이 사라지고, 막아 놓으면 브라우저를 닫고 간 사람 때문에 글이 잠깁니다.
마이그레이션도 있습니다. 스키마를 바꿔야 하는데 이미 글이 4,000개 쌓여 있고, 그중 일부는 예전 에디터로 쓴 거라 형식이 다릅니다.
캐시 무효화도 있습니다. 글을 고쳤는데 목록 화면에는 옛날 제목이 남아 있는 상황. 어디를 언제 비워야 하는지가 화면에는 안 보입니다.
첨부 파일 수명도 있습니다. 글을 지우면 이미지도 지워야 하는지, 다른 글에서 같은 이미지를 쓰고 있으면 어떻게 하는지, 3년 전 첨부는 계속 들고 있어야 하는지.
이것들은 전부 겉면에 없습니다. 데모에서는 하나도 안 나옵니다. 데모는 글 하나 쓰고, 이미지 하나 올리고, 발행 눌러 보는 걸로 끝나니까요. 그런데 실제 비용은 저기서 다 나옵니다.
그러니까 CMS는 데모와 제품 사이 거리가 특히 먼 분야입니다. 그래서 딸깍의 성과가 가장 커 보이는 자리이기도 합니다. 화면은 완성돼 보이는데 위 목록은 하나도 안 건드려져 있으니까요.
누가 이런 글을 쓰는가
이 대목이 좀 조심스러운데, 관찰한 대로 쓰겠습니다.
이런 종류의 홍보 문장은 그 영역을 오래 한 사람 쪽에서는 잘 안 나옵니다. 여러 번 만들어 본 사람은 자기 결과물을 봐도 별로 안 놀랍니다. 비슷한 걸 이미 여러 번 봤으니까요. 관리자 화면이 그럴듯하게 나왔다고 해서 그게 뭔가를 증명한다고 생각하지 않습니다. 그게 원래 그렇게 나오는 걸 아니까요.
반대로 그 영역을 처음 만들어 본 사람에게는 자기 결과물이 유일해 보입니다. 비교할 대상이 없기 때문입니다. 화면이 돌아가고 로그인이 되고 글이 저장되는 걸 처음 봤으면, 그게 대단한 일로 보이는 게 자연스럽습니다. 실제로 그 순간의 감정은 진짜일 겁니다.
그러니까 이건 사람의 등급 문제가 아니라 비교 대상이 있느냐 없느냐의 문제에 가깝습니다. 도덕 문제라기보다 정보 문제입니다.
다만 정보 문제라고 해서 결과가 없는 건 아닙니다. 그 글을 읽는 쪽에서는 피로가 쌓입니다. 그리고 그 피로는 정직하게 만든 사람한테도 똑같이 갑니다. 충전소 검색 앱을 진짜 불편해서 만든 사람도, 홍보글 무더기 사이에 끼면 구별이 안 됩니다. 이게 제일 아까운 부분입니다.
그럼 나는 어떤가
여기까지 쓰고 나면 스스로한테 같은 질문을 해야 합니다. 안 그러면 이 글도 게시판의 그 글들과 같은 종류가 됩니다.
이 블로그는 자동화 하네스 위에서 돌아갑니다. 역할이 나뉜 에이전트가 여섯 개 있고, 단계별 스킬이 스무 개 있고, 세션 시작과 종료와 커밋 직전에 걸리는 훅이 세 개 있습니다. 주제를 정하고, 조사하고, 쓰고, 다듬고, 문체를 점검하고, Blogger API로 올리는 것까지 이어집니다. 커밋 직전에는 시크릿이 섞여 들어갔는지 스캔합니다.
문장으로 적어 놓으면 그럴듯합니다. 그런데 저는 이걸 어디에도 자랑하지 않습니다.
이유가 두 개인데, 첫 번째는 방금까지 쓴 것과 같습니다. 이것도 복제됩니다. 같은 걸 하려는 사람이 같은 도구로 시작하면 며칠 만에 비슷한 게 나옵니다. 폴더 구조가 다르고 이름이 다르겠지만, 하는 일은 거의 같을 겁니다. 에이전트를 역할별로 쪼개고, 단계마다 파일로 넘기고, 발행을 스크립트로 빼는 건 이 문제를 풀려는 사람이면 대체로 도달하는 답입니다. 제가 발명한 배치가 아닙니다.
게시판에서 본 그 결과물들은 이것보다도 더 빨리 나옵니다. 그런데 이걸 "내 게 더 어렵다"는 뜻으로 쓰면 안 됩니다. 제 말은 반대쪽입니다. 제 것도 이미 자랑거리 아래에 있는데, 그보다 더 빨리 나오는 걸 자랑하고 있으니 피로가 온다는 겁니다. 기준선이 낮은 게 아니라, 기준선 자체가 사라진 자리라는 뜻입니다.
자랑은 항상 산출물을 가리킵니다
두 번째 이유가 더 중요합니다.
설계는 제가 했습니다. 어떤 단계로 나눌지, 무엇을 게이트로 둘지, 어디서 사람이 개입할지는 제가 정했습니다. 그런데 결과물은 AI가 만들었습니다. 파일도, 문서도, 스크립트도 그렇습니다.
그리고 자랑이라는 건 거의 항상 산출물을 가리킵니다. 스크린샷을 올리고, 파일 개수를 세고, 며칠 만에 나왔다고 씁니다. 그런데 그 산출물이 정확히 제가 안 한 부분입니다.
제가 한 부분은 설계와 판단인데, 그건 보여주기가 어렵습니다. 화면이 없습니다. 스크린샷이 안 됩니다. "이 단계를 빼기로 했습니다" 같은 문장은 시각적으로 아무것도 아닙니다. 그래서 아무도 그걸 안 내놓고 결과물 화면을 올립니다. 올릴 게 그것밖에 없어서가 아니라, 그게 제일 잘 보여서입니다.
여기에 하나 더 붙습니다. 산출물의 부피는 이제 비용이 아닙니다. 문서 스무 장이든 파일 백 개든 며칠이면 나옵니다. 그러니 부피를 근거로 삼는 순간, 근거가 사라진 셈입니다. 예전에는 부피가 시간의 영수증이었는데 지금은 아닙니다.
그러면 뭐가 남는가
제가 한 부분 중에 그나마 복제가 안 되는 걸 찾아보면, 전부 틀렸다고 판명된 것들입니다.
한 번은 발행 스크립트에 문체 검사 게이트를 넣었습니다. AI 티가 나는 글을 자동으로 막으려고요. 검사 결과 파일에 "판정: 합격"이라는 문자열이 있으면 통과시키고, 없으면 발행을 중단하게 했습니다. 코드로 강제했으니 안전하다고 생각했습니다.
한참 뒤에 알았는데, 그 문자열을 검사받는 에이전트가 직접 쓰고 있었습니다. 검문소와 통행증 발급처가 같았던 겁니다. 게이트가 있는 동안 한 번도 막힌 적이 없었는데, 글이 다 좋아서가 아니라 구조가 그렇게 생겨서였습니다. 그래서 게이트를 뺐습니다. 지금은 문체를 판정 라벨로 처리하지 않고 줄 단위 수정 내역만 남깁니다.
또 한 번은 글을 대량으로 지웠습니다. 4월과 5월에 나흘 동안 35편을 몰아서 올린 적이 있습니다. 나중에 실제 발행 시각을 뽑아 보니 열 편이 5분 만에 올라간 날도 있었습니다. 그 35편의 길이 중앙값이 3,600자였고, 이미지가 0장이었고, 내부 링크가 0개였습니다. 애드센스는 "가치가 별로 없는 콘텐츠"라고 했습니다.
7월 31일에 그중 32편을 내렸습니다. 라이브 글이 53편에서 21편이 됐고, 길이 중앙값이 4,728자에서 10,881자로 올랐습니다. 넉 달치 작업을 지운 셈인데, 지우고 나서 숫자가 좋아졌습니다.
이런 것들은 복제가 안 됩니다. 남의 실패는 복사해도 자기 것이 되지 않기 때문입니다. 게이트가 자기 자신을 검사하고 있었다는 걸 알려면 그 게이트를 실제로 몇 달 굴려 봐야 합니다. AI한테 물어봐도 안 나옵니다. 물어볼 질문 자체가 굴려 보기 전에는 안 떠오르니까요.
그런데 이것도 자랑거리는 아닙니다. 자랑이라기보다 그냥 기록입니다. 틀린 걸 틀렸다고 적어 두는 것에 가깝습니다. 사이드 프로젝트 네 개를 AI와 넉 달 굴렸을 때도 네 번 다 같은 자리에서 발이 멈췄고, 그 자리는 제가 AI에 안 적어 준 제약이 쌓인 지점이었습니다. 그때도 남은 건 만든 목록이 아니라 막힌 지점의 목록이었습니다.
클론이라고 적어 놓은 프로젝트
개인적으로 굴리는 게임 프로젝트가 하나 더 있습니다. 방치형 전략 RPG인데, 규모만 놓고 보면 이 블로그 하네스보다 훨씬 큽니다. 에이전트가 스물한 개, 스킬이 일흔두 개, 훅이 열두 개 붙어 있습니다. 기획서가 서른두 개고 커밋은 이백 개를 넘겼습니다. 전투 엔진과 가챠와 시즌패스와 출석 보상이 각각 폴더로 나뉘어 있고 화면만 스물세 개입니다.
문장으로 적으니 또 그럴듯합니다. 앞에서 CMS 홍보 문구를 두고 했던 말이 그대로 저한테 돌아옵니다.
그런데 이 프로젝트 README 첫 줄에 제가 뭐라고 적어 놨냐면 이렇습니다.
탑히어로즈 클론 프로젝트
숨기지 않고 첫 줄에 적었습니다. 이건 겸손해 보이려고 쓴 문장이 아니라, 그게 사실이라서 쓴 문장입니다. 방치형 RPG의 구조는 이미 정해져 있습니다. 영웅을 모으고, 장비를 붙이고, 자동 전투를 돌리고, 출석과 일일 퀘스트로 붙잡아 두는 흐름이 그 장르의 문법입니다. 제가 발명한 게 아닙니다. 잘 만들어진 게임을 보고 구조를 따라간 겁니다.
그러니 저 스물한 개와 일흔두 개는 자랑할 숫자가 아닙니다. 오히려 반대입니다. 답이 이미 나와 있는 장르라서 저만큼 빨리 쌓인 겁니다. 답이 없는 걸 만들려고 했으면 저 속도가 안 나옵니다.
여기서 제가 실제로 한 일을 다시 세어 보면, 장르를 고른 것과 어떤 시스템을 먼저 넣고 어떤 걸 뒤로 미룰지 정한 것 정도입니다. 전투와 메타와 라이브옵스를 어떻게 끊을지, 세이브를 어디에 둘지, 서버를 언제 붙일지 같은 순서 결정입니다. 그 순서는 제가 정했습니다. 그런데 그 순서의 결과로 나온 파일들은 제가 쓰지 않았습니다.
앞에서 쓴 것과 같은 구조입니다. 설계는 제가 했고 결과물은 AI가 만들었습니다. 그리고 남한테 보여줄 수 있는 건 결과물 쪽뿐입니다.
주변에서도 다들 알고 있습니다
이게 저 혼자 하는 생각은 아닙니다.
회사에서도, 주변 개발자들 사이에서도 이 얘기는 이미 나와 있습니다. 요즘은 AI로 웬만한 건 쉽게 만들 수 있다는 걸 다들 압니다. 그래서 누가 뭘 만들었다고 하면 예전만큼 놀라지 않습니다. 놀라움이 사라진 자리에 대신 들어온 게 고민입니다.
남들과 다른 특별함을 가진 걸 어떻게 만들어야 하나.
이게 진짜 문제입니다. 게시판 홍보글에 짜증이 나는 건 사실 표면이고, 그 밑에는 이 질문이 깔려 있습니다. 만들 수 있다는 게 더 이상 아무것도 구별해 주지 않으면, 무엇으로 구별되는가.
비개발자들이 만드는 걸 보면 대부분 이미 누군가 만들어 놓은 서비스입니다. 할 일 관리 앱, 가계부, 예약 페이지, 커뮤니티, CMS. 이건 상상력이 부족해서가 아닙니다. AI에게 물어보면 잘 나오는 게 정확히 그런 것들이기 때문입니다. 이미 세상에 많이 있어서 잘 나오는 거고, 잘 나오니까 그걸 만들게 됩니다. 도구가 답이 있는 쪽으로 사람을 데려갑니다.
그런데 이건 비개발자만의 문제가 아닙니다. 저도 방치형 RPG의 문법을 따라갔습니다. 잘 나오는 쪽으로 갔다는 점에서는 같습니다. 정도의 차이는 있어도 방향은 같습니다.
아직 답을 못 찾은 부분
그래서 특별함이 어디서 나오느냐를 요즘 계속 생각하고 있는데, 아직 정리가 안 됐습니다. 지금 보고 있는 건 이 정도입니다.
하나는 문제 쪽에 있는 것 같다는 겁니다. 만드는 건 흔해졌는데 무엇을 만들지 고르는 건 아직 안 흔합니다. 충전소 검색 앱을 만든 사람이 그걸 만든 이유가 실제 불편이었다면, 그 불편을 알아챈 것까지가 그 사람 몫입니다. 만든 건 AI가 했어도요. 문제를 고르는 자리는 아직 자동화가 안 됐습니다. 잘 나오는 쪽으로 끌려가지만 않는다면요.
또 하나는 운영 시간에 있는 것 같다는 겁니다. 앞에서 쓴 게이트 사례나 서른두 편을 내린 일이 그렇습니다. 만들 때는 안 나오고 굴려야 나오는 것들입니다. 그런데 이건 시간이 필요해서, 만든 다음 날 자랑할 수 있는 종류가 아닙니다. 아마 그래서 아무도 이걸 안 들고 나옵니다.
세 번째는 잘 모르겠습니다. 어쩌면 특별함이라는 걸 결과물에서 찾는 것 자체가 이미 틀린 자리일 수도 있습니다. 만드는 비용이 0에 가까워지면 만든 물건으로 구별되기를 기대하는 게 무리일 수도 있으니까요. 그런데 그러면 뭐가 남는지는 아직 답이 안 나옵니다.
이 부분은 조금 더 봐야 할 것 같습니다.
진입장벽이 낮아질수록 포장이 두꺼워집니다
마지막으로 이상한 구조가 하나 보입니다.
만들기가 쉬워졌으면 자랑이 줄어야 자연스러운데, 실제로는 늘었습니다. 이유는 아마 이럴 겁니다. 쉬워진 만큼 결과물이 흔해졌고, 흔해진 만큼 차별화 압력이 올라갔습니다. 그래서 결과물로는 구별이 안 되니까 문장으로 구별하려고 합니다. "10년 경력"이나 "철저한 QA 프로세스" 같은 말이 그 자리에 들어갑니다.
즉 포장이 두꺼워지는 건 만든 사람이 특별히 부정직해서가 아니라, 결과물이 더 이상 아무 말도 안 해 주기 때문입니다. 말이 없어진 자리를 말로 채우는 겁니다.
이게 유튜브가 약관에서 단어 하나를 바꾼 일과도 겹칩니다. 플랫폼이 AI 양산 콘텐츠를 막으려고 할 때 실제로 판별하려던 것도 도구가 아니라 의도였습니다. 도구는 판별할 수 없고, 판별할 필요도 없습니다.
그리고 제 쪽 노출도를 세어 보면 제 커밋의 92%가 남의 데이터센터 위에 있습니다. 그러니 저는 이 문제 바깥에 서 있는 사람이 아닙니다. 안에 있는 채로 쓰는 글입니다.
정리하자면 자랑을 안 하기로 한 게 결심 같은 건 아닙니다. 그냥 확인에 가깝습니다. 만든 걸 세어 보면 자랑할 게 없고, 자랑할 만한 부분은 아직 안 생겼습니다.
게임 프로젝트 README 첫 줄에 클론이라고 적어 놓은 것도 같은 이유입니다. 그렇게 적어 두면 적어도 제가 뭘 한 건지 헷갈리지 않습니다. 특별함은 아직 못 찾았지만, 없는 걸 있다고 적지 않는 것 정도는 지금 할 수 있는 일입니다.
그다음은 조금 더 굴려 봐야 알 것 같습니다.
댓글
댓글 쓰기