3_포스트_원고
목차
1화. AI 에이전트를 써보고 난 뒤의 생각
"요즘 AI가 대세라는데 너도 한번 써봐."
다들 AI, AI 하니까 나도 반신반의하는 마음으로 두드려봤다. 솔직히 말해서 '대단해 봤자 얼마나 가겠냐' 하는 비개발자 특유의 삐딱한 마음이 컸다. 영화 전공인 내가 기술을 깊이 알아봐야 얼마나 알겠나 싶었고.
그런데 웬걸, AI랑 밤낮으로 씨름한 지 두 달 만에 학원에 필요한 인트라넷 시스템을 내 손으로 직접 뚝딱 만들어버렸다. 이름은 거창하게 '우디캠퍼스 2.0'이라고 붙였다.
가입 대기 인원 승인부터 학습일지, 특강, 업무 관리 기능까지 구겨 넣은, 내가 봐도 제법 그럴싸한 물건이 나왔다.
물론 그 과정이 온전히 '뚝딱'은 아니었다. 버그 잡는다고 매달리고, 끝없는 질문 던지느라 정신이 나갈 것 같았던 지옥의 2개월이었다. 하지만 그 러닝커브를 한 번 뚫고 나니 시각이 완전히 달라졌다. 내 눈앞에 완전히 새로운 기회의 세계가 열린 기분이었다.
"글 쓰는 데도 쓸 수 있겠는데?"
코드가 가득 찬 복잡한 개발 문서를 AI가 척척 읽고 써내려가는 걸 보다가 문득 한 생각이 스쳤다.
'코드를 이렇게까지 다룬다면, 책 같은 복잡한 기획이나 원고 집필도 AI랑 같이 할 수 있지 않을까?'
마침 영화과 입시생들을 가르치면서 오래전부터 굴려왔던 책 기획이 있었다. 매번 짧은 수업 시간 때문에 전달하지 못했던 내용들을 한 권의 교재로 엮어내고 싶었다.
내용은 SF의 하위 장르들—아포칼립스, 하드 스페이스 오페라, 사이버펑크 등—을 대표 명작 영화들과 비교하며 분석하는 다소 마이너한 연출 분석서였다.
타겟이 너무 좁아서 세상 어떤 출판사도 선뜻 내주지 않을 책이었지만, 영화 연출을 전공하려는 소수의 입시생들에겐 정말 꼭 필요한 책이었다.
개발할 때 쓰던 에디터인 '커서(Cursor)'를 그대로 켜고 AI와 분석서 집필에 들어갔다. 결과물은 솔직히 충격 그 자체였다. 단 일주일 만에 100페이지에 달하는 고품질 원고가 정교한 뼈대를 갖춘 채 쏟아져 나왔다.
단순한 타이핑 보조가 아니라, 내 의도와 연출 맥락을 완벽하게 이해하고 씬을 직조해 주는 집필 파트너를 만난 느낌이었다.
"그 '커서'가 마우스 커서인가요?"
이 어마어마한 경험을 혼자만 알고 있기 너무 아까웠다. 그래서 주변에 있는 기획자, 디자이너, 마케터 등 비개발자 창작자 친구들에게 호기롭게 커서를 영업하기 시작했다.
"이거 꼭 써봐. AI한테 내 문맥 전부 던져놓고 같이 씬 분석하고 다듬으면 작업 효율이 미쳐 날뛰어."
하지만 돌아온 반응들은 대개 이런 식이었다.
"커서요? 마우스 커서 말씀하시는 건가요?"
"아니, 그 Cursor라고... 아주 훌륭한 에디터(IDE)가 있어..."
이 말을 건네는 순간 친구들의 동공이 격하게 흔들렸다. 시꺼먼 에디터 창에 정체 모를 코드와 영어 텍스트가 빽빽하게 박혀 있는 첫 화면을 마주하는 것만으로도, 그들은 깊은 거부감과 두려움을 느꼈다.
노션(Notion)조차도 기능이 너무 많아서 배우기 지친다는 바쁜 현대인들에게, 개발 전용 도구는 감히 넘볼 수 없는 철옹성이었던 거다.
사람들이 게으르거나 멍청해서가 결코 아니다. 다들 자기 본업에 쫓겨 눈코 뜰 새 없이 바쁘고, 그 낯설고 불친절한 개발 도구의 진입장벽을 뚫어낼 에너지와 시간이 없을 뿐이다.
슥슥 - 내 옆의 가장 단순한 동료를 향해
사실 AI 에이전트의 핵심 본질은 심플한 것 같았다
"AI가 내 문서를 완벽히 이해한 채로 읽고, 쓰고, 나와 상호작용하며 문제를 해결해 나간다."
이 직관적인 개념을 복잡한 껍데기(IDE, 개발용 터미널 등) 없이 전달할 수만 있다면 어떨까. 수많은 기획자와 창작자들이 맞이할 기회와 잠재력은 말 그대로 무궁무진할 텐데. 왜 개발자들만 이 사기적인 혜택을 온전히 누려야 하는지 억울한 생각마저 들었다.
그래서 직접 만들기를 결심했다.
'그 무지막지한 기술적 진입장벽을 완전히 제로(0)로 깎아버리자. 백지 위에 생각을 슥슥 쏟아내기만 하면, 에이전트가 알아서 구조를 잡고 일하게 만들자.'
이것이 바로 내가 '슥슥(sskssk)'의 개발을 시작한 진짜 이유이자 필요의 발견이다.
복잡한 개발 환경 세팅도, 어두컴컴한 터미널도 필요 없다.
그저 하얀 도화지 위에 하고 싶은 말을 슥슥 적어 내려가면, 에이전트가 나와 발맞추어 그 다음을 그려낼 것이다.
내 옆의 묵묵한 빈자리를 채워줄 가장 단순하고 영리한 에이전트.
슥슥—
이제 빌드를 시작한다.
02_2화. 문서베이스 vs 코드베이스: 켜지지 않는 불씨를 살리는 법
코드를 만질 때는 세상이 참 명료해 보였다. 모든 것이 제자리에 있고, 모든 연결이 논리적 인과관계로 설명되기 때문이다. 하지만 다시 문서의 세계로 돌아왔을 때, 나는 거대한 안개 속에 갇힌 듯 막막했다. 이 둘의 격차는 대체 어디서 오는 걸까. 내가 겪은 거대한 혼란을 해결하기 위해서는 문서베이스 작업과 코드베이스 작업의 근본적인 차이부터 파악해야만 했다.
코드베이스의 질서: 명확한 이정표들
코드베이스는 고도로 규격화된 논리의 성벽이다.
예를 들어, "학생들이 과제 제출을 어떻게 처리하지?"라는 전혀 낯선 시스템 구조를 마주했을 때도 개발 도구는 주저하지 않는다. 프로젝트 전체를 대상으로 grep을 실행해 과제 제출의 시작점인 submitAssignment라는 핵심 함수를 단번에 찾아낸다.
그 실마리를 잡은 순간부터는 징검다리를 건너듯 자연스럽다. 파일 상단에 빽빽하게 적힌 import 구문들이 정교한 이정표가 되어주기 때문이다.
import { verifyStudent } from '../auth'를 보며 학생의 신원을 검증하는 첫 단계를 파악하고, 곧바로 이어서 import { uploadToS3 } from '../utils/s3'를 보고 제출된 파일이 어디에 어떻게 업로드되는지 읽어낸다. 마지막으로 데이터베이스에 어떻게 기록되는지까지, 코드에 적힌 import 이정표들을 타고 내려가며 단숨에 전체 시스템의 지도를 그려낼 수 있다.
문서베이스의 혼돈: 본질과 그림자
하지만 문서는 성격이 전혀 다르다. 문서와 문서 사이의 연결고리는 이정표 역할을 하는 import 구문처럼 명확히 규정되어 있지 않다. 그리고 그렇게 박제되어서도 안 된다.
내가 문서베이스 위에서 만들고 싶은 것은 단순한 '텍스트 덩어리'가 아니라 유기적인 '생각' 그 자체이기 때문이다.
글이란 우리의 머릿속 본질(이데아)을 조금 더 해상도가 낮은 어떤 흔적(그림자)으로 투영해 둔 것에 불과하다. 그러니 에이전트가 글을 쓰고 생각을 돕는다는 것은, 단순히 텍스트를 기계적으로 저장하는 것을 넘어 머릿속에 흐릿하게 흩어진 생각의 해상도를 더 높여주는 도구가 되어야 했다.
만약 문서 간의 연결을 단지 기계적인 수학적 '관련도'나 키워드 일치율로만 엮어낸다면, 그것은 사용자에게 지극히 기계적이고 논리적인 연결만을 강요하는 셈이 된다. 하지만 인간의 삶과 창작은 결코 단 선형적인 논리만으로 작동하지 않는다. 그것은 진짜 에이전트의 지향점이 될 수 없었다.
출처: ko.wikipedia.org
발화점: 식기 전에 옮겨 붙어야 하는 불씨
뇌과학자들은 인간의 사고가 뉴런들의 동시다발적인 전기적 점화와 네트워크 형성으로 일어난다고 말한다. 하나의 개념이 머릿속에 번뜩이면, 그것과 전혀 상관없어 보이던 먼 기억의 파편이 순식간에 시냅스로 연결되며 거대한 아이디어의 그물을 형성한다. 플라톤의 동굴 벽에 비친 희미한 그림자들이 서로 겹치고 흔들리며 새로운 입체적 형상을 만들어내듯이 말이다.
우리가 화면 위에 적어내려가는 거친 메모와 생각의 파편들은 완결된 정적 텍스트가 아니다. 그것은 더 큰 통찰을 낳기 위해 대기하는 역동적인 세포들과 같다.
생각이 일어나는 순간은 일종의 '발화점'이다. 인간의 생각은 작은 불씨와 같아서, 불씨가 살아 있을 때만 옆으로 조용히 옮겨 붙는다. 만약 그 불씨가 한순간이라도 꺼져버리면 주변의 마른 장작들이 아무리 많아도 결코 불길을 이어가지 못한다. 우리의 아이디어도 마찬가지다. 한 줄의 단서, 반짝인 생각의 꼬리를 제때 살려두지 않으면 그 뒤로 이어질 수많은 뉴런의 연결망은 영영 굳어버리고 만다.
슥슥(sskssk)의 영토: 상호작용의 시각화
슥슥(sskssk)이 해야 할 일은 바로 이 희미한 불씨를 어떻게든 꺼뜨리지 않고 살려내는 것이었다.
사용자가 거친 문장이든 단 한 줄의 낙서든 작은 생각의 발화를 툭 던지면, 슥슥은 즉시 그것을 눈에 보이는 시각적 형태(컬러 칩, 다이어그램, 혹은 레이아웃)로 구현해 내밀며 불씨를 살린다. 눈앞에 구체적으로 펼쳐진 이미지를 마주한 순간 사용자의 뇌는 비로소 '아, 내가 하고 싶었던 말이 저거였구나' 혹은 '그렇다면 여기서 저쪽으로 연결하면 어떨까?'라며 새로운 뉴런들을 달라붙게 만든다.
우리가 날것의 텍스트를 던지면 슥슥이 즉각 시각화로 받아치고, 우리는 그것을 디딤돌 삼아 또 한 걸음의 생각을 이어가는 상호작용. 작은 불씨 하나가 메마른 뉴런들 사이를 전도체 삼아 타고 번지며, 순식간에 뇌 전체의 전기 자극을 활성화하고 거대한 영감으로 번져가는 그림. 그것이 슥슥이 추구하는 생각의 구체화 방식이었다.
출처: youtube.com
그렇다면 에이전트의 인터페이스는 어떻게 설계되어야 할까. 코드베이스처럼 엄격한 import와 export로 파일들을 가두는 것은 인간의 자유로운 연상을 방해한다. 반대로 아무 맥락도 없이 그저 키워드 검색 결과나 임베딩 유사도 순으로 문서를 기계적으로 나열하는 것은 파편화된 그림자만 흩뿌려놓을 뿐이다.
필요한 것은 생각의 파편들이 유기적으로 모이고, 겹치고, 충돌할 수 있는 '공간'이었다. 파일을 열어 하나씩 따로 읽는 대신, 한 폴더 안의 글들이 하나의 거대한 합본처럼 아래로 자연스럽게 이어져 보이는 뷰. 문서를 물리적인 파일 경계에 가두지 않고, 단락과 블록 단위로 쪼개어 언제든 조립하고 연결할 수 있는 유기적인 흐름.
이것이 내가 고민한 문서베이스 작업의 본질이자, 슥슥(sskssk)의 비주얼 인터페이스가 지향해야 할 첫 번째 단서였다. 코드가 가보지 못한 생각의 영토를, 우리는 전혀 다른 질서로 정복해야 했다.