제 251호 (2026.11.09.)

함께 들을 음악을 고르는 일

AI는 재즈 밴드의 대화에 낄 수 있을까?

나를 두 번 울린 연주

얼마 전 유튜브에서 재즈 영상 하나를 봤습니다. 피아니스트 에멧 코헨(Emmet Cohen)과 보컬리스트 시릴 에메(Cyrille Aimée)가 함께한 〈After You've Gone〉입니다. 피아노, 베이스, 드럼, 그리고 보컬. 8분 남짓한 연주입니다.  

처음에는 감탄만 했습니다. 가사 대신 '두비두바' 같은 소리로 악기처럼 즉흥 선율을 부르는 보컬의 스캣(scat)이 믿기지 않을 만큼 대단했습니다. 밴드는 박자를 두 배로 몰아치는 더블타임(double time)으로 넘어갔다가 다시 돌아오기를 몇 번이나 반복했습니다. 그 강렬함에 눈물이 났습니다.

두 번째로 들을 때는 다른 소리가 들렸습니다. 보컬이 한 소절을 마치고 숨을 쉬는 짧은 순간이 있습니다. 그 빈자리에 피아노가 짧은 악구를 채워 넣었습니다. 재즈에서는 이것을 필(fill)이라고 부릅니다. 그런데 단순히 빈 곳을 채우는 게 아니었습니다. 다음 소절이 자연스럽게 이어지도록 분위기를 바꾸고 길을 열어 주었습니다. 보컬이 다시 노래를 시작하자 피아노는 조용히 뒤로 물러났습니다.

저는 그 순간에 한 번 더 울었습니다. 영상 댓글에도 "듣다가 세 번 울었다"는 사람이 있더군요(위 영상의 시청자 댓글 "I cried like 3 times listening to this").

재즈: 무대 위의 대화

재즈에는 정해진 곡이 있습니다. 멜로디와 코드 진행은 같습니다. 그런데 무대 위의 연주는 매번 다릅니다. 누가 연주하는지, 그 순간 연주자들이 서로 무엇을 주고받는지에 따라 같은 곡이 다른 음악이 됩니다.

즉흥 연주라고 하면 각자 하고 싶은 대로 한다고 생각하기 쉽습니다. 실제로는 반대에 가깝습니다. 연주자들은 서로의 소리를 듣고, 표정을 살피고, 그 자리에서 판단해 자기 소리로 답합니다. 한 사람이 던지면 다른 사람이 받고, 받은 것을 다시 다음 사람에게 넘깁니다. 한 사람의 악구에 다른 사람이 악구로 답하는 콜 앤 리스폰스(call and response), 솔로를 네 마디씩 번갈아 주고받는 트레이딩(trading fours)이 이런 대화의 대표적인 형식입니다. 피아노가 솔로이스트 뒤에서 화음을 툭툭 끊어 넣으며 받쳐 주는 컴핑(comping)도 악보대로 치는 것이 아니라 솔로를 들으며 그때그때 넣는 반주입니다.

그래서 저는 재즈를 연주자들의 대화라고 부르고 싶습니다. 대화에 끼려면 지금 오가는 말을 알아들어야 하듯, 연주자도 동료가 무엇을 하는지 따라가야 응답할 수 있습니다. 재즈에서 연주한다는 것은 혼자 말하는 것이 아니라, 그 대화에 참여하는 일에 가까운 것 같습니다.

제가 두 번째로 울었던 이유도 아마 이 대화였던 것 같습니다.

"AI로 재즈 반주를 만들 수 있을까요?"

이 연주를 보기 하루 전, 학부모 교육에서 한 수강생께 질문을 받았습니다. 아이가 플루트로 재즈 곡을 연주하려는데, 선생님이 재즈 반주까지 맞춰 주기는 어렵다는 것이었습니다. 악보는 있으니 AI로 반주 음원을 만들 수 있지 않겠냐는 질문이었습니다.

아이에게 필요한 건 재즈 뮤지션 수준의 반주가 아니었습니다. 연습하고 발표할 때 함께 흘러가 줄 적당한 반주면 충분합니다. 그 정도라면 AI로도 충분히 만들 수 있을 겁니다. 코드만 넣으면 피아노·베이스·드럼 반주를 만들어 주는 앱도 이미 있습니다.

다만 제 경험상 '딸깍' 한 번으로 되지는 않았습니다. 악보에서 음을 읽어 멜로디를 소리로 만드는 데까지는 해 봤습니다. 하지만 그 소리를 반주로 쓸 만하게 다듬으려면 손이 꽤 많이 갈 것 같았습니다. Suno 같은 음악 생성 서비스는 기존 곡을 요청하면 저작권 문제로 거절했습니다. Suno 는 유명 아티스트 이름이나 저작권 관련 표현이 들어간 요청은 생성되지 않을 수 있다고 안내하고 있습니다(출처: Suno Help Center, "Does Suno moderate songs?").

그 과정에서 "AI가 음악을 만든다"는 말에 여러 단계가 섞여 있다는 걸 알게 됐습니다. 악보를 그대로 재생하는 것, 재즈풍의 새 음악을 만드는 것, 주어진 코드 위에 반주를 만드는 것, 그리고 연주자와 실시간으로 주고받으며 함께 연주하는 것입니다. 앞의 세 단계는 품이 들더라도 지금 도구로 할 수 있습니다. 마지막 단계는 조금 다른 문제처럼 보였습니다.

그리고 다음 날 그 영상을 보면서, 그 생각이 더 커졌습니다. 재즈를 재즈로 만드는 것은 반주 음원의 품질보다 연주자들이 주고받는 대화에 있는 것 같았기 때문입니다.

어떤 대화를 나누고 싶은가?

이렇게 쓰면 "역시 AI는 사람을 못 따라온다"는 글로 읽힐까 조심스럽습니다. 저는 매일 AI를 사용합니다. 이 글의 첫 생각도 AI와 음성으로 대화하며 정리했고, 그 대화에서 사람에게서도 듣기 어려운 통찰을 얻었습니다. 많은 사람들이 AI에게 대체될지 모른다는 불안 속에서, AI가 아직 못 하는 일에서 인간의 가치를 찾곤 합니다. 하지만 그 경계는 해마다 조금씩 움직이는 것 같습니다. 그 경계선에만 기대면 계속 뒤로 물러서야 할지도 모르겠습니다.

다시 그 영상으로 돌아갑니다. 두 번째 눈물은 기량 때문만은 아니었던 것 같습니다. 보컬의 숨에 피아노가 답하는 순간, 누군가의 소리를 받아 자기 소리로 이어 주는 그 소통 때문이었습니다. 앞의 MIT 무대에 섰던 연주자들은 다음 연주자들에게 "불확실성에 더 기대 보라"고 권했다고 합니다. 저는 그 말이 AI와의 연주에만 해당하는 이야기 같지 않습니다.

기술이 무엇을 할 수 있는지는 계속 바뀌어 갈 것입니다. 당신은 무엇에 감동하나요? 그리고 사람과, 또 기계와 어떤 대화를 나누고 싶은가요?

덧붙여, 저와 더배러 필진 구요한 님이 재즈 합창단 하이진재즈블렌드의 단원으로 무대에 섭니다. 12월 18일(금) 저녁 7시 30분 팝티스트홀, 제2회 정기연주회 〈함께 호흡하는 재즈의 숨결〉입니다. 서로의 숨을 맞추는 음악이 궁금하신 분들은 찾아 주시면 감사하겠습니다(공연 안내).

💬 이번 주 더배러 톡방 하이라이트

🌱 “일단 해보세요” 다음에 필요한 질문

이지/집필/지식관리,집필님이 AI와 개발을 어디서부터 시작할지 묻자, bellpush/연구/자기개발님은 먼저 사용 목적을 물었고 하피/1인기업/AI님은 직접 만들며 배우는 경험을 강조했습니다. ASap / AI님은 기초 개념을 알아야 질문과 유지보수에 도움이 된다는 다른 시각을 보탰습니다. 대화가 대규모 서비스 개발까지 넓어지자, 질문자는 초보자에게는 너무 먼 이야기라고 다시 말을 걸었습니다. 이후 목표는 웹소설 집필을 돕는 AI 활용으로 좁혀졌습니다. 방법론을 많이 건네는 것만큼, 지금 그 사람이 하고 싶은 일과 막힌 지점을 듣는 일이 필요했던 대화였습니다.

📖 집필 질문이 작품과 오디오북으로 이어지다

11월 6일 앤드류 | 지식노동자님은 앞서 나온 장르 소설 이야기를 계기로 시도한 작업을 공유하면서, 글은 더 다듬어야 한다고 했습니다. 책쓰는듀공 / 제육우동먹기님은 그 소설을 오디오북으로 감상할 수 있는 페이지로 공유했고, 배경음악의 볼륨도 조정하겠다고 했습니다. 러브님은 등장인물·장소·시간선을 살펴보는 도구 활용을 제안했고, KEY님은 연재 시작을 응원했습니다. AI로 글을 쓸 수 있을까라는 질문이 실제 원고와 독자의 반응, 다른 사람이 보탠 감상 방식으로 이어졌습니다.

공유된 소설 감상 페이지: https://kingspledu.github.io/travel-war-episode-01/

🔍 검증을 반복해도, 기준이 흔들리면 끝나지 않는다

러브님은 OCR 작업이 12시간 동안 반복된 경험을 전했습니다. 뒤이어 공유한 원인 설명에 따르면, 검수기가 PDF 파일 크기로 표본을 정해 수정할 때마다 검사할 페이지가 바뀌었고, 고친 결과를 확인하는 대신 다른 저품질 페이지를 계속 찾고 있었습니다. 종료 조건 자체가 없었던 것은 아니어서, 반복 횟수보다 무엇을 비교하고 있는지가 중요한 사례였습니다. 별도의 대화에서 이제현|R&D|재미님은 AI에 넣는 사람의 글에도 편향과 오류가 있을 수 있다며, 글이 다루는 오류와 그 글 자체가 범할 수 있는 오류를 짚는 ‘데이터 인위성 지도’를 공유했습니다. 출력만 다시 읽는 데서 더 나아가 입력 자료와 검사 방식도 살펴보자는 질문이 남았습니다.

공유된 글 점검 도구: https://app.jehyunlee.dev/dataartifact/

🧩 기능을 더하는 일과, 사용자가 쓰게 하는 일

푸른양/사무직/지식관리님은 업무에서 느꼈던 불편을 해결하려다 등록·출력·증빙 기능을 계속 붙인 경험을 이야기했습니다. 하피/1인기업/AI님은 고객이 주문 내용을 사이트에 옮겨 고객을 찾는 단계부터 번거로워해, 카카오톡 내용을 복사하면 화면이 뜨고 엔터로 처리하게 바꾼 사례를 들었습니다. 한쪽에서는 완성도를 먼저 확보하고 기능 추가를 제한하자는 생각이, 다른 쪽에서는 실제 고객의 타당한 요청을 빠르게 반영하자는 생각이 나왔습니다. 만드는 사람이 필요하다고 여기는 기능과 사용자가 감수할 수 있는 절차 사이의 거리가 구체적으로 드러났습니다.

🎛️ 모델 순위보다, 내 작업에서 비교할 기준

셀모님이 모델과 추론 수준을 어떻게 골라야 할지 묻자, 이도형/사무/엑셀님은 같은 내용을 새 세션에서 비교하고 기존 설정도 점검해 보자고 했습니다. ACH_안창현님은 복잡한 설계, 준비된 스킬 실행, 단순 편집을 나눠 모델을 고르는 자신의 기준을 설명했습니다. 루테넌트(김민석)|개발님은 설계와 실행을 서로 다른 모델에 맡기는 방식을, 러브님은 가벼운 모델로 먼저 해보고 필요할 때 바꾸는 방식을 나눴습니다. 선호는 서로 달랐지만, 결과와 사용량을 함께 보며 자신의 작업에 맞는 기준을 세우는 일이 화두였습니다.

📱 작업실을 고르는 기준에 모바일이 들어왔다

브라이언 - 브레인 트리니티님은 주초부터 Herdr가 가볍다는 사용 경험을 나누면서, 모바일 사용과 초기 버전의 부족한 기능도 함께 이야기했습니다. 주말에는 루테넌트(김민석)|개발님이 Paseo로 옮긴 뒤 모바일 접근성이 좋았다는 경험을 나눴습니다. 러브님은 모바일 사용의 편리함과 별개로 원격 작업에서는 Orca를 함께 쓰고 있다고 했고, 네루님은 Herdr의 가벼움을 장점으로 꼽았습니다. 누군가에게 잘 맞는 도구가 모두에게 같은 답은 아니었고, 메모리 부담과 원격 접속, 휴대폰에서의 사용 경험이 선택 기준으로 모였습니다.

⏱️ 일이 빨라졌는데, 왜 더 바쁠까

이제현|R&D|재미님은 강연에서 받은 “업무는 빨라졌는데 생산성이 늘지 않았다”는 질문과 자신의 답을 공유했습니다. 필요하지 않은 보고서를 더 빨리 만들거나 분량만 늘린다면, 작성자의 속도가 다른 사람의 부담으로 옮겨갈 수 있다는 지적이었습니다. 자동화로 귀찮은 일을 덜어도 비효율적인 업무방식 자체는 남아 개선 대상에서 잊힐 수 있다는 고민도 덧붙였습니다. 최은우/연구원/이직지망생님은 일이 빨라지면서 더 많아지는 경우도 있다고 보탰습니다. 처리량이 늘었는지에 앞서, 어떤 일이 줄고 어떤 결과가 좋아졌는지 돌아보게 하는 대화였습니다.

  

📅 더배러 활동 소식

오늘의 뉴스레터 어떠셨나요?