ian.lab (이안.랩)

2년쯤 전에 유행한 강의가 있었습니다. 무료 루프로 음악을 만들고 배경 한 장을 움직이게 만들어서 몇 시간짜리 영상으로 올리는 방식이었습니다. 로열티 프리 소스라 저작권 걱정이 없고, 촬영이 없고, 한 번 올리면 쌓인다고 했습니다. 지금 그 강의를 파는 사람은 없습니다. 대신 도구가 바뀐 같은 문장이 팔립니다. 여섯 편의 원문을 붙여놓고 읽어봤습니다. 자동 생성 자막이라 오타가 많지만 화자가 무슨 값을 제시했는지는 다 남아 있습니다. 무인 채널 강의 한 편, 시니어 정보채널 강의 한 편, 해외 사업가의 다섯 가지 모델을 요약한 재가공 영상 한 편, 홈페이지 제작 부업 한 편, 쇼폼 제작 한 편과 쇼폼 대행 한 편입니다. 세어보니 실패 사례는 여섯 편에 한 건이었습니다. 고객 쪽 전환 사례도 한 건이었습니다. 계약 갱신 데이터는 0건이었습니다. 그리고 데모에 기술적 거짓은 한 건도 없었습니다. 이게 이 글에서 제일 걸리는 부분입니다. 여섯 편 모두 상품이 영상 밖에 있습니다 여섯 편 전부 끝이 같습니다. 고정 댓글 링크, 특정 날짜의 무료 강의, 전자책, 프롬프트 자료 묶음. 숨기지도 않습니다. 무인 채널 편의 화자는 평생교육시설 허가가 나는 자리로 사무실을 옮겼다고 말하고, 자기 이름을 건 채널로 1년 반째 사람들을 가르치고 있으며 함께하는 크리에이터가 400명이라고 말합니다. 교육이 주력이라는 걸 영상에서 자기 입으로 밝힙니다. 그러니까 이 영상들은 콘텐츠 자리에 놓인 광고입니다. 화면의 수익 스크린샷은 상품 설명이 아니고 광고 소재입니다. 이건 그 자체로 문제는 아닙니다. 문제는 스크린샷이 증명하는 성과와 판매되는 방법론이 서로 다른 사업이라는 점입니다. 무인 채널 편에서 검증 가능한 성과로 보여준 건 전부 커머스입니다. 자전거 리뷰 영상 27만 뷰, 124만 9천 원짜리 상품, 수수료 25퍼센트, 스쿠터 신청서 56건. 화면에 실제로 떠 있고 성립할 수 있는 숫자입니다. 그런데 파는 방법론은 얼굴도 목소리도 나오지 않는 무인 채널입니다...

산출물 21건이 나간 저장소 하나를 열어서 규격과 대조해봤습니다. 규격은 문서에 적혀 있습니다. 산출물 한 건의 분량은 10000자에서 12000자 사이. 21건 전부 이 규격을 받은 상태에서 만들어졌고, 만들 때마다 규격을 지켰다는 보고가 같이 왔습니다. 21건 중 규격 위반으로 반려된 건은 없습니다. 머리말을 잘라내고 공백을 뺀 글자 수를 세니 21건 중 18건이 밴드 밖에 있었습니다. 대부분 아래쪽이었고 7000자대가 여럿이었습니다. 세는 방법을 바꿔서 공백을 포함하고 다시 세니 이번엔 7건이 밖이었습니다. 규격에는 공백을 세라는 말도, 빼라는 말도 없었습니다. 세는 방법 하나 때문에 답이 갈린 걸 보고 나머지도 대조해보기로 했습니다. 배포 코드를 열고, 라이브 페이지를 받아보고, 커밋 메시지를 훑고, 플랫폼 정책 문구를 띄워놓고 21건을 다시 읽었습니다. 반나절 걸렸습니다. 이 글은 그 반나절 동안 나온 것들을 순서대로 적은 겁니다. 다섯 가지가 나왔고 공통점이 하나 있습니다. 전부 에러가 없습니다. 실패한 명령이 없고, 빨간 줄이 없고, 돌아온 보고는 매번 완료였습니다. 그리고 다섯 가지를 찾는 데 쓴 수단이 전부 명령줄이었습니다. 숫자만 적힌 규격 세는 방법만 바꿔서 두 번 돌렸는데 공백을 빼면 21건 중 18건이 밴드 밖이고 공백을 넣으면 7건입니다. 같은 파일 21개, 같은 규격, 다른 답입니다. 한글 산문에서 공백은 전체의 20퍼센트 안팎을 차지합니다. 9000자짜리 본문이 세는 방법 하나로 7200자도 되고 9000자도 됩니다. 밴드 하한이 10000자니까 이 차이가 통과와 미달을 가릅니다. 어느 쪽이 맞느냐를 정하는 문장이 문서에 없으니 둘 다 맞습니다. 그리고 이 상태에서 만드는 쪽이 무엇을 할 수 있는지가 마음에 걸립니다. 두 방법 중 자기 산출물이 통과하는 쪽으로 세면 됩니다. 속이려는 의도가 없어도 그렇게 됩니다. 세는 절차가 비어 있으면 그 자리를 만드는 쪽이 채우고, 무엇으로 채웠는지는 아무 데도 안 남습니다. ...

페르소나를 안 지정해도, 단계를 안 나눠도, 출력 형식을 안 정해도 결과가 같다. 그러면 프롬프트 기법은 다 걷어내도 되는 걸까. 처음 AI로 일하기 시작했을 때 제일 열심히 공부한 게 프롬프트였다. 페르소나를 지정해라, 목적을 명시해라, 단계를 나눠서 시켜라, 예시를 두세 개 붙여라, 출력 형식을 먼저 정해라. 강의든 글이든 대체로 같은 목록을 줬고 나는 그걸 틀로 만들어 썼다. 그러다 모델이 몇 번 바뀌는 동안 그 틀을 하나씩 걷어냈다. 페르소나를 빼도 결과가 같았고, 단계를 안 나눠도 알아서 나눴고, 출력 형식을 안 정해도 읽을 만하게 왔다. 지금은 대체로 한두 문장으로 묻는다. 입력이 짧아졌으니 매 턴 들어가는 토큰도 같이 줄었고, 돌아오는 결과는 나빠지지 않았다. 이번 달에 로블록스 게임 두 개를 만들면서 맵이 어이없게 작게 나온 걸 봤다. 원인을 찾다가 기획서를 열었더니 맵 크기가 한 줄도 안 적혀 있었다. 크기를 정한 문장이 딱 하나 있었는데 그게 "작게"였다. 그 자리를 보고 있다가, 이 모양을 어디서 봤다는 생각이 들었다. 이번 달 초에 초등학교 5학년인 아들이 AI랑 대화해서 게임을 만드는 걸 옆에서 봤을 때다. 아들도 한 항목을 두 글자로 답하고 넘어갔었다. 층은 세 번 올라갔다 프롬프트를 다듬는 게 전부이던 시기가 실제로 있었다. 지금은 무게중심이 옮겨간 게 문서로도 남아 있다. Anthropic 은 2025년 9월 29일에 올린 컨텍스트 엔지니어링 글 에서 이렇게 적었다. "At Anthropic, we view context engineering as the natural progression of prompt engineering." 프롬프트 엔지니어링은 지시문을 어떻게 쓰느냐의 문제이고, 컨텍스트 엔지니어링은 추론이 도는 동안 모델의 창 안에 무엇을 남기고 무엇을 뺄지 고르는 문제라는 구분이다. 같은 글에 이런 문장도 있다. "We're already seeing tha...

CTO 와 마주 앉으면 깨진 유리창 얘기가 자주 나온다. 유리창 하나를 그대로 두면 나머지도 깨진다, 그러니 작은 것부터 방치하지 말자. 들을 때마다 공감은 된다. 린트 경고를 무시하기 시작한 저장소가 어떻게 되는지는 다들 봤으니까. 매번 뭔가 하나가 걸렸다. 그래서 원문을 찾아 읽었다. 1982년 3월 《애틀랜틱 먼슬리》에 실린 제임스 Q. 윌슨과 조지 켈링의 글이다. 유리창 비유는 거기서 나온 게 맞다. 읽어보니 이 글의 출발점은 주민의 마음가짐이 아니었다. 이 글에서 내가 한 건 1982년 3월 《애틀랜틱 먼슬리》 원문을 찾아 끝까지 읽고 평소 듣던 요약과 대조한 것까지다. 이후 인용하는 후속 연구와 실험은 논문과 공개 자료로 확인했고 내가 재현한 게 아니다. 원문에는 순찰 인력이 배치돼 있었다 윌슨과 켈링의 글은 1970년대 뉴저지에서 있었던 도보순찰 실험에서 나왔다. 주가 28개 도시를 대상으로 지역사회 개선 프로그램을 돌리면서 예산으로 경찰 도보순찰을 지원했고, 켈링이 그 결과를 평가했다. 결과는 이랬다. 도보순찰은 기록된 범죄를 줄이지 못했다. 그런데 그 동네 주민들은 더 안전하다고 느꼈다. 두 저자는 이 어긋남을 설명하려고 했고, 도보순찰 경관이 한 일은 범죄와 싸운 게 아니라 질서를 유지한 것이라고 봤다. 시끄러운 무리를 옮기고, 주민들이 중요하게 여기는 비공식 규칙을 집행하는 일. 그러니까 이 이야기의 앞에는 처음부터 배치된 사람 이 있다. 주민들이 마음을 다잡아서 동네가 나아진 게 아니라, 예산이 붙고 인력이 걸어 다니기 시작한 뒤에 체감이 바뀐 것이다. 유리창은 그 상태를 설명하기 위해 나온 비유고, 원인이 아니라 지표에 가깝다. 이 절반이 인용될 때 대체로 빠진다. 남는 건 "작은 것을 방치하지 마라"라는 규범 한 줄이다. 규범만 떼어놓고 보면 마음가짐 얘기가 되지만, 원문 맥락에서 이건 예산 얘기다. 하나 더 적어둘 게 있다. 1982년 글은 논증이지 실증이 아니다. 두 사람은 무질서가 범죄를 유발...

제미나이 스파크가 이 계보의 몇 번째인지 날짜만 늘어놓고 세어봤다. 네 번째였다. 유튜브에서 소개 영상을 봤다. 잠자는 동안에도 내 일을 대신 해주는 개인 에이전트라는 설명이었고, 영상의 톤은 여기서부터 뭔가 새로 시작된다는 쪽이었다. 그 톤이 좀 걸려서 표를 만들었다. 표를 다 채우고 나니 층이 하나씩 올라갈 때마다 실제로 늘어난 건 성능이 아니었다. 스파크는 처음이 아니다 이 글에서 내가 겪은 건 도입부까지다. 아래는 전부 공개된 기록과 만든 회사들의 공식 문서로 확인한 것이고, 내가 직접 돌려본 게 아니다. 그래서 시간순으로만 먼저 놓는다. 2025년 11월 24일에 Warelay 라는 이름으로 GitHub 에 공개됐고 첫 24시간에 스타 약 9,000개가 붙었다. 2026년 1월 2일에 Clawdbot 으로 개명했는데, 1월 12일에 Anthropic 이 코드 없이 쓰는 에이전트 작업 공간인 Claude Cowork 를 공개했다. 1월 27일 Anthropic 의 상표 이의 제기로 Moltbot 으로 다시 이름을 바꿨고, 1월 30일에 최종적으로 OpenClaw 가 됐다. 2월에 GitHub 스타 100,000 을 넘겼다. 창시자 Peter Steinberger 는 2월 15일 OpenAI 에 합류했고 프로젝트는 독립 재단으로 넘어갔다. 3월에 스타 250,000 을 돌파했는데 같은 달 중국이 국유기업과 정부기관 업무용 PC 에서 OpenClaw 계열 앱 구동을 제한했다. 3월 18일에는 Anthropic 이 Claude Dispatch 를 리서치 프리뷰로 열었다. 폰에서 지시하면 내 데스크톱의 Claude 가 실행하는 물건이다. 5월 19일 Google I/O 2026 에서 Gemini Spark 가 나왔고, 7월 7일에 Claude Cowork 가 모바일과 웹으로 확장됐다. Gizmodo 와 Decrypt 는 스파크 기사 제목에 아예 OpenClaw 를 넣었다. 구글이 OpenClaw 를 잡으러 왔다는 프레이밍이었다. 이 계보에서 누...

얼마 전에 개발자 커뮤니티 게시판의 목록을 한 달치 세어본 적이 있다. AI로 뭘 만들었다는 글이 실제로 얼마나 되는지 궁금해서였다. 그 뒤로 가끔 들여다보는데, 이번엔 목록이 아니라 글 하나가 눈에 걸렸다. "초중급 개발자는 진짜 망한거 맞죠?" 코딩을 한 번도 해본 적 없는 사람이 월 30만 원짜리 구독을 결제하고 쇼핑몰과 앱과 서버 관리와 사업 시스템을 만들었다는 내용이었다. 사장은 코딩 언어를 전혀 알 필요가 없었고, 그건 컴퓨터를 모르는 사장이 컴공 전공 직원에게 지시하는 것과 완전히 똑같다고 했다. 조회수가 만 명을 넘겼고 댓글이 46개 붙었다. 전부 읽었다. 20년차라고 밝힌 사람, AI 개발자라고 밝힌 사람, 코딩을 하나도 모르는데 커서를 결제해서 잘 쓰고 있다는 사람까지 골고루 있었다. 양쪽 논거가 다 나왔고, 읽고 나니 각 진영이 무엇을 근거로 삼는지도 정리가 됐다. 그런데 정리가 되고 나서 오히려 새로 걸린 게 있었다. 이 논쟁은 끝날 수가 없는 구조였다. 46건이 같은 축 위에 서 있었다 첫 댓글이 스레드 전체의 프레임을 정했다. 20년차라는 사람이 이렇게 썼다. 전혀 모르는 다른 영역 개발 같은 거 진짜 코드 한 줄 안 짜고 바이브로만 만들어 서빙하고 합니다. 백점 만점에 92점 정도짜리는 매우 쉽게 만들어줌. 하지만 프러덕션용 98점 이상짜리는 말로만은 쉽지 않음. 이 92점과 98점이 이후 스레드를 지배했다. 어떤 사람은 "90점까진 누구나 쉽게 갑니다. 문제는 거기서부턴 1점 올리는 데 엄청난 노력과 자본이 든다"고 받았고, 어떤 사람은 "비개발자들이 쉽게 느끼는 이유는 92점짜리가 100점짜리처럼 보이기 때문"이라고 받았다. 실제로 사내 전산 프로그램을 3주 만에 만들어 20명이 쓰고 있다는 사람도 회고해보니 "딱 90점"이라고 썼다. 정작 원글이 던진 프레임(사장이 직원 부리듯 AI를 부린다)은 아무도 이어받지 않았다. 스레드의 실제 주제...

개발자 커뮤니티 게시판을 오랜만에 열었다. 뽐뿌 개발자포럼인데 하루에 글이 두세 개 올라오는 정도다. 눈에 걸린 건 특정 글이 아니라 목록의 생김새였다. 제목 대부분이 "이런 걸 만들었습니다"였고, 그 옆의 댓글 칸이 거의 다 비어 있었다. 숫자를 세어보기로 했다. 목록 페이지 두 장, 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만 줄의 내역 만든다는 게 지금 무슨 뜻인지부터 봐야 한다. A...

쓰다보니 꼬였네요. 자정 가까운 시각에 오픈 채팅방에 내가 적은 문장이다. 밤 10시쯤 질문이 하나 올라왔다. 회사에서 AI 개발팀을 새로 만들었고 자기가 그 팀 팀장을 맡게 됐는데, 그동안 보안 업무만 해서 개발 프로세스를 팀에 적용하려니 노하우가 없다는 얘기였다. 표준화나 절차 같은 걸 어디서부터 잡아야 하냐고 물었다. 나는 답을 길게 쓸 생각이 없었고, 내가 이런 걸 알아볼 때 AI에게 던지는 지시문 형식을 그대로 복사해서 붙여줬다. 대화는 잘 붙었다. 다른 사람이 끼어들어 AI 조직은 사내 이해관계 충돌이 제일 많은 자리라 피곤할 거라고 거들었고, 나는 프로세스 4단계 얘기까지 이어갔고, 자정을 넘겨 고맙다는 답이 왔다. ADR 얘기를 꺼내려다 표준화 얘기로 새서 스스로 끊은 거였다. 그날 밤엔 그냥 문장이 엉킨 줄 알았다. 다음 날 다른 이유로 게임 저장소를 열었다가, 왜 꼬였는지 알았다. 내가 붙여준 건 지시문이 아니라 마지막 한 줄이었다 붙여준 형식은 이랬다. 너는 다년간 아키텍처 설계 및 코딩을 해온 시니어야. 나는 보안쪽 업무를 다년간 해왔어. 이번에 개발팀에 팀장역할을 맡게 되었어. 너의 역할은 심층검색과 분석을 통해 나에게 개발 프로세스 및 표준화 절차 가이드를 제공하는거야. 문서의 양식은 마크다운과 html 두 가지 양식으로 제공 받길 원해. --- 이런 형식으로 지시하려해 부족한 부분이 있어? 역할 목적 결과 또 뭐가 필요하지? 앞의 네 줄은 흔한 구성이다. 상대 역할, 내 배경, 시켜야 할 일, 받고 싶은 형식. 프롬프트 작성법 글 아무거나 읽으면 나온다. 내가 실제로 값을 보는 건 구분선 아래 두 줄이다. 지시를 실행시키기 전에, 지시문 자체를 같은 상대에게 먼저 검사받는 턴. 이걸 붙이면 첫 답이 문서가 아니라 되물음으로 온다. 회사 규모가 몇 명인지, 지금 팀이 쓰는 이슈 트래커가 뭔지, 기존 문서가 어디까지 있는지. 그 되물음에 답하고 나서 지시를 다시 던지면, 같은 모델이 완전히 다른 밀도의 결과를 낸다....

네 번째 프로젝트에서 적용을 중단했다. 원인은 AI의 한계가 아니라 내가 인지한 설계 깊이였다. 시작은 단순한 궁금증이었다. 리팩토링을 AI에게 맡기면 얼마나 빨라지는지 보고 싶었다. 학습 관리 시스템 하나를 열어놓고 "코드 재설계 해줘" 한 줄로 시작했다. 초반 80%까지는 진짜 빨랐다. 요구사항 몇 줄에 그럴듯한 코드가 나오고, 빌드가 통과하고, 화면이 떴다. 남은 20%에 들어서자 확신이 한쪽으로만 몰렸다. AI는 원인을 지목하면서 점점 확신이 세졌고, 나는 내가 뭘 시켰는지에 대한 확신을 잃었다. 이 글에 나오는 프로젝트 중 뒤쪽 두 개는 회사 일이라 이름과 도메인 필드, 내부 명령어를 전부 뺐다. 구조가 어떤 층으로 쌓여 있었고 어디서 무너졌는지만 쓴다. 남은 20%에서 확신이 한쪽으로만 몰렸다 수정 단계에 들어가고 나서는 같은 자리를 계속 돌았다. 이슈가 하나 뜬다. 프롬프트를 바꿔서 다시 시킨다. 안 풀린다. AI는 원인을 하나 지목하는데, 그 지목이 틀렸다. 틀렸는데 문장은 아주 단호하다. 나는 그 단호함에 한 번 끌려간다. 시킨 대로 고친다. 그러면 다른 데가 깨진다. 깨진 데를 고치라고 하면 처음 고쳤던 데가 다시 돌아온다. 틀린 지목에는 특징이 있었다. 원인을 하나 짚어주는데, 근거를 물으면 근거를 대는 대신 다른 원인을 짚는다. 그러면서 앞의 지목을 취소한다는 말은 안 한다. 두 번째 지목도 첫 번째만큼 단호하다. 나중에 셋을 나란히 놓고 보면 서로 양립할 수 없는 진단인데, 대화 흐름 안에서는 그게 안 보인다. 각각이 그 순간의 질문에는 잘 맞는 답이었기 때문이다. 이 루프에서 제일 지치는 건 진전이 없다는 게 아니라 진전이 있는지 없는지 판단할 기준이 나한테 없다 는 쪽이었다. 코드가 늘어나는 건 보이는데, 그 코드가 원래 내가 그리려던 구조에 가까워지는 중인지 멀어지는 중인지 말할 수가 없었다. 비슷한 유틸 함수가 두 군데 세 군데 생겨나는데도 그게 문제인지 아닌지 판단할 근거가 없었다. 그냥 ...