술에 취해 회상한 나의 과거에서 문득 첫째의 미래가 떠올랐다

1992년에 방에 컴퓨터가 놓였다. 삼보 286AT였다. 컬러 그래픽카드가 붙어 있었고 화면은 640x480이 나왔다. 하드는 40메가였던 걸로 기억한다. 모뎀도 달려 있었다. 그해 전교 8등을 했다. 전국모의고사에서는 103등이 나왔다. 지금 다시 봐도 그 정도면 잘한 성적이다. 어머니가 그걸 보고 사줬다. 원래 내 물건이 아니었다. 컴퓨터 가게 사장이 어느 회사에 납품하려고 발주한 모델이었는데 그게 나한테 팔렸다. 1992년이면 386DX가 한창이던 때다. 어떻게 보면 아무것도 몰랐던 때라 반쯤 사기 당했던 물건일 수도 있다. 대신 화면이 좀 이상한 조합이었다. 640x480은 VGA 규격이다. CGA는 320x200이고 EGA는 640x350이니까, 본체는 재고인데 그래픽카드만 비싼 게 붙어 있었던 셈이다. 납품용으로 잡아둔 물건이라 그랬을 것이다. VGA가 얼마나 비쌌는지는 나중에 알았다. 어머니가 그때 무슨 생각으로 사줬는지는 지금도 모른다. 첫 선생은 컴퓨터 가게 사장이었다 컴퓨터를 켤 줄을 몰랐다. 그래서 판 사람이 가르쳐주기로 했다. 매일 한 시간씩 일주일을 가게에 갔다. 배운 건 도스 명령어와 디스켓 다루는 법이었다. dir을 치면 목록이 나오고 cd로 디렉터리를 옮기고, 디스켓을 넣고 a: 를 치면 그쪽으로 넘어간다는 것. 그 정도가 일주일이었다. 그다음이 게임이었다. 사장이 게임을 복사해줬다. 지금 와서 보면 그 사람은 게임을 복제해서 팔기도 했다. 좋게 포장할 생각은 없다. 그때 게임이 그렇게 돌았고 나는 그 경로의 한복판에 있었다. 얼마 지나지 않아 내가 가게를 봐주게 됐다. 사장이 자리를 비우면 내가 앉아서 손님을 받았다. 애들이 게임을 복사하러 오면 내가 복사해줬다. 그러면서 나도 몇 개씩 챙겨왔다. 용돈이 생기면 용산에 갔다. 5.25인치 디스켓을 샀다. 한 장에 1.2메가짜리를 박스로 사다가 다 채웠다. 게임 하나가 디스켓 여러 장에 나눠 들어가던 시절이라 금방 없어졌다. 학교에서 인기가 좋아졌다. 게임을 ...

Buzz 워크플로우는 액션이 일곱 개인데 셋은 로그만 남기고 성공한다

이미지
리뷰 영상 네 편을 봤습니다. 네 편 다 설치부터 시연까지 보여주고, 네 편 다 된다고 말합니다. 그런데도 코드를 열었습니다. 굳이 연 이유는 네 편의 순서가 전부 똑같았기 때문입니다. "된다"를 보여주고 나서 "그런데 이건 아직"을 덧붙이는데, 그 "이건 아직"이 네 편 모두 같은 기능에 걸려 있었습니다. 한 편이 걸리면 그 사람 환경 문제입니다. 네 편이 같은 자리에서 걸리면 화면 문제가 아니라 그 아래 문제입니다. 리뷰 영상은 되는 걸 보여주려고 만듭니다. 안 되면 다시 찍거나 그 대목을 잘라냅니다. 그 편향을 뚫고 네 편에 다 남아 있다면, 다시 찍어도 안 되고 잘라내면 흐름이 끊기는 자리라는 뜻입니다. crates/buzz-workflow/src/executor.rs 532번째 줄에 이렇게 적혀 있었습니다. /// For MVP, most actions log their intent and return a success output. /// Real event emission is wired in WF-07/08 (relay integration). 대부분의 액션이 무엇을 하려 했는지를 로그로 남기고 성공 출력을 반환한다 고, 코드가 자기 입으로 적어놓았습니다. 한 줄로 설명이 안 되는 물건입니다 Buzz 는 Block 이 공개한 오픈소스입니다. Apache 2.0 이라 가져다 고쳐 써도 됩니다. 그런데 이게 뭘 하는 물건인지가 한 줄로 안 잡힙니다. 채팅앱이라고 하기엔 git 저장소를 품고 있고, 개발 도구라고 하기엔 채널과 DM 이 있습니다. 공식 설명은 사람과 에이전트가 같이 일하는 작업 공간이라고 되어 있습니다. 구조는 세 덩어리로 보면 정리가 됩니다. relay 와 agent 와 community 입니다. relay 는 Rust 로 짠 서버인데, 메시지든 반응이든 git 이벤트든 전부 여기 하나의 로그로 쌓입니다. 사람도 에이전트도 각자 키를 가지고, 남기는 흔적마...

AI 부업 강의 여섯 편이 "리스크가 제로죠"라고 말했다

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

규격 “10000~12000자”를 두 가지로 세면 18건과 7건이 나옵니다

이미지
규격이 지켜지고 있는지 한 번도 세본 적이 없다는 걸 3주가 지나서 알았습니다. 저장소 하나에 산출물 21건이 쌓여 있었습니다. 만들 때마다 규격을 지켰다는 보고가 같이 왔고, 규격 위반으로 반려된 건은 없었습니다. 그런데 반려가 없었던 게 규격을 지켜서인지 아무도 안 세봐서인지, 그걸 구분할 근거가 저한테 없었습니다. 그래서 세봤습니다. 머리말을 잘라내고 공백을 뺀 글자 수로는 대부분이 밴드 아래쪽이었고 7000자대가 여럿이었습니다. 세는 방법을 바꿔 공백을 포함하고 다시 세니 통과하는 쪽으로 우르르 옮겨갔습니다. 21건 중 밴드 밖이 18건이었다가 7건이 됩니다. 같은 파일, 같은 규격, 다른 답입니다. 규격에는 공백을 세라는 말도, 빼라는 말도 없었습니다. 여기서 마음에 걸린 건 어느 쪽이 맞느냐가 아니었습니다. 둘 다 맞다 는 것이었습니다. 그 말은 지금까지 어느 쪽으로 세어 왔는지를 제가 모른다는 뜻이고, 앞으로도 모르리라는 뜻입니다. 세는 방법이 안 적힌 규격 한글 산문에서 공백은 전체의 5분의 1쯤 됩니다. 9000자짜리 본문이 세는 방법 하나로 7200자도 되고 9000자도 됩니다. 밴드 하한이 10000자니까 이 차이가 통과와 미달을 가릅니다. 어느 쪽이 맞느냐를 정하는 문장이 문서에 없으니 둘 다 맞습니다. 그리고 이 상태에서 만드는 쪽이 무엇을 할 수 있는지가 마음에 걸립니다. 두 방법 중 자기 산출물이 통과하는 쪽으로 세면 됩니다. 속이려는 의도가 없어도 그렇게 됩니다. 세는 절차가 비어 있으면 그 자리를 만드는 쪽이 채우고, 무엇으로 채웠는지는 아무 데도 안 남습니다. 세는 방법이 갈리는 자리는 공백 말고도 있었습니다. 산출물 안에 코드 블록이 들어 있으면 그걸 분량에 넣느냐, 이미지 설명 문구는 본문이냐, 인용한 남의 문장은 내가 쓴 분량이냐. 코드가 본문의 상당 부분을 차지하는 건이 하나 있었는데, 이 건은 세는 방법을 어떻게 조합하느냐에 따라 밴드 안에 들어오기도 하고 안 들어오기도 합니다. 이 상태가 3주 갔던 ...

AI 산출물은 한 건씩 보지 말고 스무 개를 한 줄로 세워라

이미지
오전에 저장소 하나를 열어서 산출물 열여덟 개의 제목만 뽑아 세로로 늘어놨다. A가 아니라 B였다 A했고 B였다 기대한 것과 결과가 어긋났다 열여덟 개 중 열다섯 개가 이 셋 중 하나였다. 종결 어미까지 세어보니 열일곱 개가 같은 형태였다. 질문형도 명사구도 인용도 없었다. 한 건씩 볼 때는 아무 문제가 없었다. 각각은 검사를 통과했고, 통과 기록도 남아 있다. 검사기가 제목을 안 읽고 있었을 뿐이다. 이 글은 그날 하루 동안 같은 저장소에서 연달아 나온 여섯 가지를 순서대로 적은 것이다. 여섯 개가 다 다른 사고처럼 보이는데, 다시 보면 전부 한 자리에서 나왔다. 설계와 구현과 검증을 다 맡기고 나서 사람이 무엇을 안 봤는가 하는 자리다. 검사기는 본문만 읽고 있었다 이 저장소에는 산출물 문체를 훑는 검사기가 있다. 금지 표현 목록이 열 개 항목으로 나뉘어 있고, 각 항목마다 걸러낼 패턴이 나열돼 있다. 그중 일곱 번째 항목이 이렇게 적혀 있다. AI 결론형 정형구 : 가 아니라 ~다 · 데 있다 · 한 셈이다 · 결국 ~것이다 → 사실만 쓰고 결론 라벨을 떼면 대개 좋아진다. 그러니까 가 아니라 ~다 는 명시적으로 금지된 문형이다. 문서에 적혀 있고, 이유도 적혀 있고, 대안도 적혀 있다. 발행된 제목 중 셋이 정확히 그 문형이었다. AX 는 도구를 사는 일이 아니라 권한을 자르는 일이다 깨진 유리창 이론은 마음가짐이 아니라 순찰 인력에서 시작했다 네 번째 리팩토링에서 AI가 아니라 내가 문제였다 검사기가 고장 난 게 아니다. 검사기는 본문 파일을 훑는다. 제목은 파일 맨 위 메타데이터에 있고, 그 영역은 훑는 범위 밖이었다. 규칙은 있었고 실행도 됐는데 산출물의 한 조각이 검사 밖에 있었다. 검사기를 만들 때는 본문이 산출물의 전부처럼 보였을 것이다. 제목은 나중에 붙는 짧은 문자열이니까 검사할 게 없어 보인다. 실제로는 제목이 열여덟 개 중 열여덟 개에 붙고, 목록 화면에서는 제목만 보인다. 읽는 사람이 제일 먼저...

프롬프트 기법을 다 걷어내도 되나?

이미지
페르소나를 안 지정해도, 단계를 안 나눠도, 출력 형식을 안 정해도 결과가 같다. 그러면 프롬프트 기법은 다 걷어내도 되는 걸까. 처음 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...

Orca 로 worktree 세 개에 에이전트를 나눠 띄웠다

이미지
worktree 는 파일을 갈라준다. .git 은 안 갈라준다. 그 한 층 차이에서 다른 브랜치의 변경이 충돌도 없이 내 작업 트리에 얹혔다. 터미널을 세 개 열어놓고 쓰다 보면 10분쯤 지나서 어느 창이 무슨 작업이었는지 헷갈린다. 한쪽에서 로그인 버그를 잡고, 다른 쪽에서 테스트를 만들고, 나머지 창에서 리팩터링을 시키는데, 셋이 같은 폴더를 보고 있으니 결국 같은 파일을 건드리기 시작한다. 그래서 Orca 를 깔았다. 저장소를 붙이고 worktree 를 세 개 만들어 Claude Code 와 Codex 를 서로 다른 폴더에 띄웠다. 파일은 정말 안 섞였다. diff 세 개가 나란히 쌓이고 마음에 드는 것만 골라 PR 로 올릴 수 있었다. 한쪽 에이전트에게 "작업 중인 변경 잠깐 치워두고 확인해봐"를 시켰더니 git stash 를 썼고, 그게 다른 폴더에서 그대로 보였다. 거기서 꺼내니 다른 브랜치의 작업 트리에 얹혔다. 충돌조차 나지 않았다. 이름에 IDE 가 붙었지만 편집기는 아니다 제작사는 Orca 를 ADE 라고 부른다. Agent Development Environment 의 약자로, 코딩 에이전트를 여러 개 띄워놓고 작업별로 챙기는 공간이라는 뜻이다. GitHub 저장소 설명 도 "병렬 에이전트 함대를 다루는 ADE" 라고 적혀 있다. Cursor 나 VS Code 에도 AI 기능이 있는데 굳이 하나를 더 깔아야 하냐는 질문이 먼저 나온다. 역할이 다르다. Cursor 에서는 편집기 안에서 AI 와 코드를 함께 쓴다. Orca 에서는 코드를 직접 쓰지 않고, 여러 에이전트의 진행 상황을 보고 결과를 비교해 어느 변경을 가져올지 고른다. 편집기 자리에 앉아 있는 게 아니라 감독 자리에 앉는 도구다. 별도 AI 모델을 새로 결제하는 방식도 아니다. 컴퓨터에 이미 깔려 있는 CLI 와 로그인 정보를 불러와 실행한다. 그래서 목록에 에이전트가 안 뜨면 앱을 다시 깔기 전에 CLI 설치와 로그인, PAT...