냅킨에서 악기까지

들어가며

종이 냅킨 위에 볼펜으로 가로선과 세로선을 긋는다. 가로축 끝에는 pitch(음높이), 세로축 끝에는 brightness(밝기)라 흘려 적고, 한가운데에는 소리 물결이 감긴 비뚤빼뚤한 원 하나를 그려 넣는다. 손가락으로 화면을 문지르면 수십 겹의 소리가 두텁게 울려 퍼지는 웹 전자악기. 그 출발점은 이 냅킨 스케치와 빈티지 전자악기 사진 한 장이 전부였다.

작은 스케치로 시작된 아이디어

2010년부터 학생, 조교, 강사의 다양한 포지션으로 교과 과정에 참여해왔고, 2021년 과정 전체를 이끈 뒤 학교에서 한 발 물러난 지금도 늘 특강과 멘토링으로 찾게 되는 수업이 있다. 스탠퍼드 컴퓨터음악 연구소(CCRMA)의 최대 규모 강의인 Music 220A다. 코드로 소리와 음악을 빚어내는 이 강의실에도 지금 최대의 화두는 단연 AI다. 마침 내가 일터에서 하루 종일 매달리는 일이 AI 에이전트와 함께 대규모 소프트웨어를 만드는 일이다 보니, 전공도 배경도 제각각인 학생들의 시야를 넓혀줄 기회를 늘 찾고 있었다. 그래서 이번 특강을 통해 실험을 하나 해보기로 했다. 에이전트에게 기술적인 지시는 일절 하지 않고, 코드도 손으로는 한 줄도 쓰지 않은 채, 오직 이 냅킨 한 장에서 시작해 누구나 간단히 연주할 수 있는 웹 전자악기까지 가보는 것이다.

에이전트에게 맡긴다는 것

음악 소프트웨어를 만드는 일은 원래 진입 장벽이 높았다. 소리를 실시간으로 내려면 C++ 같은 어려운 프로그래밍 언어를 능숙하게 다뤄야 했고, 소리가 끊기거나 늦게 나지 않도록 컴퓨터 내부 사정까지 꼼꼼히 챙겨야 했다.

AI 에이전트는 이 판을 뿌리부터 바꾼다. 여기서 에이전트란, 말로 일을 맡기면 스스로 파일을 만들고, 고치고, 직접 실행해서 확인까지 하는 AI 조수다. 채팅창에서 답만 건네주는 AI와 달리, 내 컴퓨터의 작업 폴더 안에서 실제로 손을 움직인다. 그러니 내가 할 일은 코드를 쓰는 게 아니라, 무엇을 왜 만들지 설명하고 결과를 확인하는 일이 된다. 흔히 "어젠틱(agentic) 코딩"이라 부르는 방식이다.

의외로 오랜 개발자 경험을 가진 사람들이 이 전환에 애를 먹는 경우도 있다. 손에 익은 대로 직접 코드를 치려 하거나, AI를 코드 자동완성 도구 정도로만 쓰거나, AI가 만든 코드를 한 줄 한 줄 검사하려 든다. 그래서 이번 실험에는 규칙을 하나 걸었다. 실패해도 좋으니 이번만큼은 "직접 코딩하지 않기"로 굳게 마음먹고 과감하게 번지점프를 해 보는 것이다.

개발자라면 "작은 웹 악기니까 코드 한 줄 안 보고 넘어가지, 수십만 줄이 얽힌 실제 서비스에서도 그게 통하겠느냐"고 물을 법하다. 좋은 질문이지만, 이 글이 답하려는 질문은 아니다. 일부러 극단적인 제약을 건 이유는, 손에 익은 습관을 강제로 묶어 두어야만 보다 큰 그림을 보는 연습을 할 수 있기 때문이다. 에이전트를 위한 환경을 만들고, 만들 것을 설계하고, 결과의 성패를 확인하는 일 말이다.

에이전트와 함께라면 만들어 보고 고치는 과정이 한층 빨라진다. 원하는 목표를 분명히 말하고, 에이전트가 엉뚱한 길로 새지 않도록 울타리(가드레일)를 치고, 결과물을 귀로 확인하며 조금씩 만들어 나간다. 냅킨 위의 스케치에서 시작해 실제로 소리가 나는 웹 전자악기를 완성해 가는 네 단계를 살펴보자.

1. 준비하기

준비물

• AI 에이전트 도구 하나. 이 글의 내용은 Antigravity, Claude Code, Codex 같은 AI 에이전트 도구라면 어디서든 비슷하게 적용된다. 특정 도구에만 있는 기능은 일부러 다루지 않았다. 이런 도구들은 대부분 데스크톱 앱이나 편집기 형태로도 쓸 수 있고, 유료 구독이 필요한 경우가 많다.
• 빈 폴더 하나. 바탕화면에 새 폴더를 만들고, 에이전트 도구에서 그 폴더를 열면 된다.
• 모르면 묻는 습관. 모르는 말이 나오면 언제든 "이게 무슨 뜻이야?"라고 물어보면 된다. 에이전트는 몇 번을 물어도 귀찮아하지 않는다.

코딩 X, 계획 O

새 프로젝트를 시작할 때 초심자가 가장 흔히 저지르는 실수는 빈 폴더를 열자마자 "멋진 전자악기 하나 만들어봐"라고 입력하는 일이다. 요즘 에이전트는 성실하고 끈기가 넘친다. 시키지도 않은 폴더와 파일, 코드를 의욕적으로 쏟아내고, 몇 번 대화하다 보면 사람도 에이전트도 그 안에서 길을 잃기 쉽다.

한 번에 끝낼 수 없는 큰일을 맡기면 에이전트도 스스로 계획부터 세우는 편이다. 그래도 "아직 코딩을 시작하지 마"라고 선을 긋는 건 여전히 사람의 몫이다. 첫 단계의 대화는 코딩에 뛰어들기보다는 에이전트와 함께 조사하고 질문을 주고받으며 무엇을 만들지 분명히 하는 데 쓴다. 여기서 섬세하게 쌓아 올린 맥락이 이후 모든 단계의 효율을 결정한다.

물론 AI 도구에 있는 "계획" 모드를 써도 좋지만, 그 기능 자체가 특별한 것은 아니다. 준비하는 과정에 시간을 충분히 쏟는다는 점이 중요하다. 전체 계획을 둘러보고 그게 내 의도와 맞는다는 확신이 설 때 비로소 만들기를 시작한다.

작업대 정리와 세이브 포인트

작업 공간이 어지러우면 에이전트도 사람도 쉽게 길을 잃는다. 빈 폴더 안에 정돈된 칸부터 나눠 주자. 공사장에서 건물을 올리기 전에 비계를 먼저 세우듯, 흔히 "스캐폴딩(scaffolding)"이라 부르는 뼈대 작업이다.

이 프로젝트에서는 바로 첫 대화에서 앞서 말한 일이 벌어졌다. "체계적, 점진적으로 작업을 진행할 수 있도록 파일과 디렉토리 구조를 셋업해줘"라고 했더니, 에이전트는 폴더를 만드는 데서 멈추지 않고 그 안을 "그럴싸한" 파일들로 가득 채워 놓았다. 나는 이렇게 되돌렸다.

"시키지 않은 일을 너무 많이 했어. 디렉토리들만 셋업해줘. 그 안의 파일들은 점진적으로 채워갈 거야."

다행히 에이전트는 실수를 금방 바로잡는다. 이때의 교훈, 즉 "요청받은 것만 한다. 요청에 없는 파일·기능·설정을 만들지 않는다"는 곧장 프로젝트 규칙 파일에 적혔다. 규칙 파일은 에이전트가 새 대화를 시작할 때마다 먼저 읽는 메모장 같은 것이라, 그 뒤로 이어진 대화에서도 에이전트는 이 규칙을 따르려 노력한다.

결국 필요한 칸은 이 정도다.

• 에이전트 규칙 폴더: 에이전트가 지킬 규칙과 작업 일지 (이름과 위치는 도구마다 다르다)
• docs/: 조사해 온 논문과 자료
• resources/: 냅킨 스케치, 사진 같은 시각 자료
• src/: 악기 자체를 이루는 파일들

규칙 파일의 이름과 위치를 외울 필요는 없다. 에이전트에게 이렇게 한마디만 하면 된다.

"코드 작성은 하지 마. 빈 디렉토리들을 만들고 너의 작업 방식에 맞는 규칙 파일 위치만 먼저 잡아줘."

이 골격이 서는 순간 에이전트에게도 일종의 지도가 생긴다. 새로 알게 된 것을 어디에 적고 지켜야 할 규칙을 어디서 읽을지 스스로 판단하게 된다.

뼈대가 섰다면 곧바로 세이브 포인트를 만들어 두자. 게임에서 보스전 앞에 저장해 두듯, 지금 상태를 기록해 두면 나중에 무엇이 잘못되어도 언제든 이 시점으로 돌아올 수 있다. 개발자들은 이를 버전 관리라 부르고, 주로 Git이라는 도구를 쓴다. 에이전트는 빠르고 넓게 일하기 때문에, 세이브 포인트 없이 일하다 실수하면 되돌리기 어렵다. 그렇다고 Git 전문가가 될 필요는 없다. 에이전트가 바로 Git의 엄청난 전문가이기 때문이다. "Git 셋업하고 지금 상태를 저장해줘" 한마디면 충분하다. 그 뒤로도 마음에 드는 단계마다 "여기까지 Git으로 저장해줘"라고 하면 된다.

2. 밑그림 그리기

예전 같았으면 전자악기를 만들기 위해 소리를 만드는 원리와 신호 처리를 배우는 데만 3, 4주 이상의 강의와 밤샘 숙제가 필요했을 것이다. 지금은 그럴 필요가 없다. 어떤 소리를 원하는지, 어떻게 생겼으면 좋겠는지, 사용자가 무엇을 듣고 보고 어떻게 반응할지에만 집중한다. 배워야 할 것이 줄어든 게 아니다. 고민의 초점이 바뀐 것이다.

프롬프트 X, 주절거림(Rambling) O

처음부터 잘 다듬은 프롬프트를 쓰려고 끙끙 앓을 필요는 없다. 머릿속에 떠오르는 반짝이는 아이디어들을 두서없이 쏟아내도 충분하다. 에이전트는 어지러운 혼잣말 속에서 중요한 주제를 엮어내는 데 탁월하다. 심지어 내가 원하는 소리의 이름을 몰라도 된다. 음성 입력을 켜고 이렇게 말해 보자.

"90년대 트랜스 클럽을 뒤흔들었던 그 웅장하고 두터운 전자악기의 소리를 만들고 싶어. 이와 관련해 학계에서 평판이 높고 인용이 많이 된 핵심 연구들을 찾아 정리해줘."

에이전트는 그 소리의 정체가 JP-8000이라는 신디사이저에 들어 있던 SuperSaw라는 음색이라는 것을 짚어낸다. 관련 논문도 서지 정보와 함께 정리해 온다. 막연한 기억 속의 소리가 이름을 얻고, 실제로 만들 방법이 적힌 논문으로 이어지는 순간이다.

그라운딩: 추측보다는 근거를

찾아온 연구 목록에서 믿을 만한 논문을 골라 요약과 핵심 분석을 docs/에 넣어 두고, 에이전트가 필요할 때마다 직접 읽고 그 내용을 바탕으로 만들게 한다. 이렇게 에이전트에게 근거 자료를 쥐여 주는 일을 그라운딩(grounding)이라 부른다.

그라운딩의 진짜 위력은 에이전트가 상식 밖의 방법을 떠올리게 한다는 데 있다. 컴퓨터로 소리를 만들 때 생기는 부작용 가운데 앨리어싱(aliasing)이라는 거친 잡음이 있다. 신호 처리의 정석은 이 잡음을 최대한 없애는 것이고, 에이전트도 처음엔 당연히 그 길로 가려 했다. 그런데 논문을 읽고 나자 이야기가 달라졌다. 원조 JP-8000 특유의 반짝이는 '공기감'은 상당 부분 바로 그 부작용에서 나온다는 것이다. 논문에 나온 수식들도 출처와 함께 코드에 그대로 옮겨졌다. AI 모델이 갖고 있던 "평균적인 지식"에만 기대어 만들었다면 결코 나오지 않았을 결과다.

너무 복잡한가? 다 이해하지 못해도 괜찮다. 자료를 읽다가 원리가 궁금해지면 이렇게 물어보자.

"내가 초등학생이라고 생각하고 이 부분을 아주 쉽게 설명해줘."

이해하기 쉬운 비유와 함께 단번에 그림이 그려지는 답이 돌아온다면 에이전트가 핵심을 제대로 짚은 셈이다. 그리고 가장 중요한 건, 오늘 당신도 새로운 것을 하나 배웠다는 사실!

'AI 티' 벗기기: 냅킨 한 장, 사진 한 장

AI에게 페이지 디자인을 알아서 하라고 맡기면 보라색 네온 색상 배경에 찍어낸 것 같은 박스들이 가득한 전형적인 'AI 티'가 묻어난다.

이를 피하는 가장 쉬운 방법은 공책이나 냅킨에 볼펜으로 그린 스케치 사진 한 장, 그리고 평소 생각해 둔 레퍼런스 사진이나 스크린숏 한 장을 함께 건네는 일이다. 나는 앞서 그린 냅킨 스케치와 함께 JP-8000 신디사이저의 사진 한 장을 넣었다. 에이전트는 사진에서 짙은 남회색 패널, 주황색 글씨, 연둣빛 액정 화면, 빨간 불빛의 색채를 뽑아내 그대로 화면에 입혔다. 텍스트 열 줄보다 사진 한 장이 훨씬 정확하게 내 취향을 전달한다.

사진 한 장에서 뽑아낸 컬러 팔레트를 그대로

스케치가 모호한 건 문제가 되지 않는다. 오히려 좋은 출발점이다. "가로축의 음높이는 미끄러지듯 이어지나요, 피아노 건반처럼 음계에 딱 맞춰지나요?", "가운데 원은 보여주기용인가요, 손으로 조작하는 건가요?" 같은 질문이 돌아오고 그 답이 곧 설계가 된다.

할 것, 말 것, 그리고 역인터뷰

만들 것을 설명할 때는 기술의 언어가 아니라 경험의 언어로 말한다.

"누구나 스마트폰이나 노트북에서 링크만 누르면 즉시 열려야 해. 어려운 피아노 건반 대신, 캔버스에 그림을 그리듯 손가락으로 화면을 쓱 문지르면 풍성한 소리가 피어오르는 악기를 원해."

하지 말아야 할 것도 단호하게 선언한다. 범위를 분명히 하지 않고 너무 많은 자유를 주면, 에이전트는 흔한 앱들이 가진 온갖 기능과 메뉴를 덕지덕지 붙인다. "전문가용 설정이나 복잡한 기능은 일체 만들지 마."

그리고 가장 중요한 두 가드레일도 덧붙인다.

"사용자가 악기를 다루는 방식에서 확실하지 않은 부분이 있다면, 혼자 짐작하지 말고 먼저 내게 질문해."

"만약 짐작한 부분이 있다면, 작업이 끝날 때 왜 그렇게 정했는지 밝혀줘."

첫 문장 덕분에 에이전트는 짐작으로 만들어 버리는 대신 날카로운 역질문을 던져온다. 나라면 미처 떠올리지 못했을 질문까지 이어진다.

• "손가락을 대고 가만히 있으면 소리가 계속 나나요, 문질러야만 나나요?"
• "손가락으로 그린 자국은 남나요, 사라지나요?"
• "전화기가 무음 모드일 때도 소리가 나야 하나요?"

특히 세 번째 질문은 나를 놀라게 했다. 아이폰은 무음 스위치를 켜면 웹 페이지의 소리까지 꺼 버리는데, 실제로 웹 오디오 표준화 그룹에서도 최근 논의되었던 문제다. 그걸 알고 먼저 물어 오다니 실로 훌륭하다! 이런 질문은 객관식으로 해 달라고 하면 고르기만 하면 되니, 복잡한 디자인 방향을 잡는 시간이 크게 줄어든다.

그래도 모든 것을 물어보게 할 수는 없다. 어떤 음계를 쓸지, 음색의 풍성함은 어떻게 변할지, 세로축의 위가 밝은 쪽인지. 두 번째 문장 덕분에 에이전트의 답변마다 '제가 정한 부분' 목록이 따라온다. 살펴보고 마음에 들지 않는 것만 골라 바꾸면 된다. 역질문은 큰 갈림길을 잡고, 짐작 목록은 작은 갈림길을 잡는다.

3. 만들기

재료와 공법 고르기

이제 지금까지 그려 온 악기를 어떤 기술로 만들지 정할 차례다. 집을 지을 때 목조로 할지 철근 콘크리트로 할지 정하듯, 소프트웨어에도 재료와 공법의 조합이 있다. 개발자들은 이를 "기술 스택"이라 부른다. 흔한 종류의 앱이라면 고민할 것이 별로 없지만, 웹 페이지로 만드는 전자악기는 흔한 경우가 아니다. 이럴 때는 내가 원하는 목표와 기준을 분명히 말하고, 가능한 선택지들을 에이전트에게 비교해 달라고 하자.

"스마트폰 브라우저에서도 손끝 터치와 소리가 끊김 없이 반응해야 해. 그래픽 렌더링과 소리 연산이 각각 다른 스레드로 완벽히 분리되어 부담을 나누는 편이 나을 텐데, 어떤 기술 조합이 좋을지 장단점을 비교 분석해줘."

나는 이렇게 물었지만, 개발 용어를 몰라도 괜찮다. 이렇게 물어도 된다.

"폰 스크린에 손가락을 대는 순간 소리가 나야 하고, 절대 끊기면 안 돼. 만드는 방법들의 장단점을 비교해서 쉽게 설명해 주고, 각각 점수를 매긴 뒤 하나를 추천해줘."

흥미롭게도 에이전트의 첫 대답은 설계도가 아니라 반론이었다. 손가락이 화면에 닿은 걸 폰이 알아채는 데 걸리는 시간, 소리가 스피커로 나가기까지 걸리는 시간은 우리가 만드는 프로그램 밖의 일이라, 터치부터 소리까지 걸리는 시간을 정확히 약속할 수는 없다는 것이다. 대신 목표를 이렇게 현실적으로 고쳐 왔다. "우리 앱이 보태는 지연은 0에 가깝게, 소리 끊김은 한 번도 없이."

그다음에야 가장 단순한 방법부터 강력하지만 복잡한 방법까지, 다섯 가지 선택지를 나란히 놓은 비교표가 나왔다. 각각 만들기가 얼마나 어려운지, 나중에 인터넷에 올리기 쉬운지, 네 음짜리 화음으로 수십 개의 소리를 동시에 계산할 때 폰이 버틸 수 있는지까지 꼼꼼히 따진 분석이었다. 덕분에 판단이 훨씬 쉬워졌다. 굳이 무겁고 복잡한 기술을 끌어올 필요 없이, 화면 그리는 일과 소리 만드는 일을 나눠서 처리할 수 있는 가장 가벼운 조합이면 충분했다.

기술 스택의 비교분석

비교 분석은 에이전트가 하고 선택은 내가 한다. 결정을 내릴 수 있을 때까지 에이전트와 논의를 점점 날카롭게 다듬어 가다 보면 내 목표에 잘 맞는 조합을 고를 수 있다. 내가 고른 것은 이 분야를 오래 다뤄 온 사람으로서 점찍어 두었을 법한 화려한 조합이 아니라, 결국 목표에 걸맞은 가볍고 효율적인 조합 (B)이었다.

작업 일지와 정리정돈: 에이전트를 위해

에이전트에게 작업 일지를 쓰게 하자. 어떤 문제를 만났고 어떻게 고쳤는지 기록하게 한 뒤, 다음에도 쓸모 있을 교훈은 앞서 말한 규칙 파일로 옮기게 한다. 에이전트는 끝난 대화의 내용을 다음 대화로 늘 가져가지는 않지만, 규칙 파일은 매번 다시 읽으므로 이렇게 적어 둔 교훈은 다음 작업으로 이어진다. 기록이 쌓일수록 작업 환경이 스스로 똑똑해지는 셈이다.

또한 코드가 길어지고 지저분해지면 사람만 길을 잃는 게 아니다. 에이전트도 긴 파일을 필요할 때마다 다시 읽어야 하고, 머릿속이 꽉 차면 응답이 느려지고 질도 떨어지기 시작한다. 그러니 코드가 불어나고 복잡해지기 시작하면 바로 정리정돈(리팩터링)과 설명 메모(주석)를 요구하자. 이 프로젝트의 규칙 파일에는 새로운 기능을 추가할 때마다 리팩터링할 부분이 있는지 확인하라는 규칙이 적혀 있다. 잘 정돈된 코드는 에이전트가 효율적으로 일할 수 있게 해주는 바탕이 된다.

4. 다듬어서 세상에 내놓기

당신의 감각과 판단

전자악기의 테스트 페이지가 열리고 첫 소리가 났다. 이제 기계가 물러서고 오직 사람만이 할 수 있는 예술적 조율이 시작된다.

에이전트는 수치 계산은 확인할 수 있어도 그 소리가 "쿨"한지는 알지 못한다. 만드는 사람이 직접 화면을 만지며 소리를 듣고 방향을 잡아 주는 과정이 필요한 이유다. 내가 쓰는 방법은 악기를 띄워 놓고 연주해 보면서, 떠오르는 생각을 음성 입력으로 에이전트에게 바로바로 말하는 것이다.

"손을 뗐을 때 여운이 너무 뚝 끊겨. 부드러운 잔향을 더 길게 줘. (tempo sync ping-pong delay + reverb)"
"트랜스에서 자주 쓰이는 코드들도 연주할 수 있도록 오른쪽 상단에 토글을 하나 만들자. (Mono vs Chord)"
"손을 위쪽으로 빠르게 그을 때 고음역을 더 찔러줘야 해. 필터 범위를 조절해줘."

잔향을 달라는 한마디에 에이전트는 바로 고치는 대신 되물어 온다. "템포는 고정할까요, 화면에서 조절할까요? 메아리 간격은 점8분음표인가요? 잔향은 몇 초쯤? 손을 뗄 때 악기 소리 자체도 더 천천히 사라져야 하나요?" 몇 번의 질의응답 뒤에, 손을 뗀 소리 끝으로 부드럽고 멋진 잔향이 따라붙는다.

괄호 속의 단어들이 눈에 띌 것이다. '핑퐁 딜레이'나 '리버브' 같은 전문 용어를 알면 디렉팅은 확실히 빨라진다. 하지만 몰라도 괜찮다. "여운이 뚝 끊겨"라는 일상적인 말만으로도 에이전트는 질문을 이어가며 방향을 찾아간다.

물론 이 대목에서 "논문의 가치를 알아보고 필터의 미세한 결을 잡아낸 건 결국 오디오를 오래 다뤄온 내공 덕분 아닌가?"라는 반문이 나올 수 있다. 정확한 지적이다. AI가 구현의 바닥을 아무리 높여 주어도, 결과물의 천장은 여전히 만드는 사람의 경험과 지식에 달려 있다. 하지만 초심자에게 진짜 희소식은 그 안목을 기르는 순서 자체가 뒤집혔다는 데 있다. 예전에는 프로그래밍 문법에 막혀 연주는커녕 소리도 한 번 제대로 못 들어보고 지쳤다면, 이제는 한두 시간이면 살아 있는 악기를 손에 쥐고 수십 번 소리를 비교하며 '좋은 소리'를 만들어 나가는 데 집중할 수 있다.

'좋은 코드'보다 '좋은 소리'에 집중할 수 있다는 것. 이것이 어젠틱 코딩이 주는 가장 중요한 가치다. 페이지 방문자들은 좋은 코드에 감탄하지 않을 것이기 때문이다.

손 쉬워진 배포

아마도 에이전트에게는 가장 쉬운 단계일 것이다. 내 컴퓨터에서만 열리던 악기를 누구나 열 수 있도록 인터넷에 올리는 일을 개발자들은 "배포(deployment)"라고 부른다. 예전 같으면 웹사이트를 올려 두는 서비스의 매뉴얼을 보며 하나하나 따라 하는 게 일반적이었지만, 이젠 그럴 필요도 없다. 일일이 설명하려 애쓰지 말고 내가 쓰는 웹 호스팅 서비스의 공식 안내 문서 주소를 에이전트에게 던져 주면 된다. 올릴 곳이 아직 없다면 "무료로 올릴 수 있는 곳을 추천해줘"라고 먼저 물어보자.

"[내가 쓰는 호스팅의 공식 가이드 URL]을 보고 src/ 폴더만 배포해줘. 배포가 끝나면 내 폰에서 바로 열어볼 수 있게 주소를 알려줘."

src/ 폴더만 올리는 이유는 논문이나 사진 같은 작업 자료가 함께 올라가지 않도록 악기 파일만 내보내기 위해서다. 나는 학교에서 제공하는 웹 서버를 골랐다. 서버측 설정은 단 한 줄도 건드리지 않았고, 올리는 일은 파일 복사 명령 한 줄로 끝났다. 에이전트는 파일을 올린 뒤 페이지가 잘 열리는지까지 스스로 확인하고 내게 주소를 건넸다.

이렇게 작업대 정리부터 인터넷에 올리기까지 걸린 시간은 채 1시간이 되지 않았다.

나가며

이전 포스트 〈나는 당신의 AI 스킬이 필요 없다〉에서도 이야기했듯, 똑똑해진 에이전트에게 필요한 것은 남이 짜둔 복잡한 스킬 패키지나 프롬프트 공식이 아니다. 무엇을 왜 만들고 싶은지, 어떤 기준으로 검증할 것인지가 담긴 명료한 생각 한 편이면 충분하다. 이 글에 적힌 단계들 역시 머릿속에 억지로 외워둘 필요가 없다.

지금 바로 AI 에이전트 도구를 열고, 비어 있는 새 폴더를 연 다음, 이 글의 링크(또는 본문 전체)를 건네고 단 한 줄만 입력해 보자.

"우선 이 블로그 포스트를 리뷰해줘. 글에 소개된 과정을 따라가며 전자악기를 하나 만들어보자."

이 한 줄만으로 이 글은 에이전트를 위한 안내서가 된다. 순서를 모두 기억하지 않아도 에이전트가 알아서 작업대를 차리고, 어떤 소리를 원하는지 물어보며, 확인을 거쳐 당신에게 소리를 들려줄 것이다.

작업대 정리부터 인터넷에 올리기까지 1시간이 채 걸리지 않았다는 사실보다 더 반가운 건 따로 있다. 기술적인 디테일과 씨름하느라 잃어버렸던 '만드는 즐거움'을 되찾았다는 점이다. 문법과 이론 공부는 잠깐 나중으로 미뤄도 좋다. 일단 머릿속의 상상을 꺼내 놓고, 직접 손으로 만져가며 소리를 들어보고, 마음에 들 때까지 고쳐 나가는 놀이에 먼저 빠져보자. 서랍 속에 접어두었던 당신만의 냅킨 스케치를 꺼내기에, 오늘만큼 좋은 날은 없다.

🎹 결과물: 220A SuperSaw