드라마치료 현장의 배경음을 버튼 하나로 칸반 AI 워커팀과 만든 「장면소리」 MVP

드라마치료 현장의 배경음을 버튼 하나로

칸반 AI 워커팀과 만든 「장면소리」 MVP

한 줄 요약
드라마치료와 사이코드라마 현장에서 필요한 배경음·환경음·효과음을 즉시 재생할 수 있도록, 칸반 전용 AI 워커팀을 구성해 인터넷과 로그인 없이 작동하는 Windows 사운드 큐 프로그램과 35개의 기본 음향팩을 만들었습니다.

완성된 결과물

최종적으로 만든 「장면소리」는 진행자가 현장에서 필요한 음향을 큰 한국어 버튼으로 바로 재생할 수 있는 Windows용 오프라인 사운드 큐 프로그램입니다.

환경음·효과음·배경음·장면신호·정서질감으로 음원을 분류하고, 각 카드에서 재생·정지·반복·음량·이름을 조절할 수 있습니다. 여러 소리를 동시에 재생할 수 있으며, 돌발 상황에서는 오른쪽 아래의 전체 즉시 정지 버튼으로 모든 음향을 한꺼번에 끌 수 있습니다.

ALT

한국 컴퓨터 화면의 스크린샷

그림 1. 칸반 AI 워커팀과 함께 만든 Windows용 오프라인 사운드 큐 프로그램 「장면소리」. 환경음 8개, 효과음 13개, 배경음 6개, 장면신호 4개, 정서질감 4개 등 총 35개의 음향을 분류해 두었습니다. 화면은 효과음 분류를 선택한 상태이며, 각 카드의 재생·정지·반복·분류·이름·개별 음량과 하단의 마스터 음량·전체 즉시 정지 기능을 보여줍니다.

이 화면에 도달하기까지 단순히 AI에게 “앱 하나 만들어줘”라고 요청한 것은 아니었습니다. 현장 요구 조사, 실제 구현, 독립 검수, 오류 수정, 음향 제작, USB 포터블 구성까지 서로 다른 작업으로 나누어 진행했습니다.

몰입을 돕기 위한 노력

드라마치료와 사이코드라마에서는 말뿐 아니라 공간의 분위기, 장면의 전환, 정서의 고조와 이완도 중요한 역할을 합니다.

비, 바람, 발걸음, 문 여는 소리처럼 간단한 음향만 있어도 장면은 훨씬 구체적으로 살아납니다. 반대로 진행 중에 적절한 파일을 찾고 유튜브를 오가면 장면의 흐름과 참여자의 몰입이 끊길 수 있습니다.

그래서 처음 세운 질문은 단순했습니다.

진행자가 장면을 놓치지 않으면서, 필요한 소리를 버튼 하나로 바로 재생할 수 없을까?

이 질문에서 드라마치료 현장용 사운드 큐 프로그램 「장면소리」를 만들기 시작했습니다.

프로그램 개발의 원칙

기능을 많이 넣는 것보다 현장에서 단순하고 안전하게 쓰는 것을 우선했습니다.

• Windows 10·11에서 실행

• 설치 없이 사용할 수 있는 포터블 프로그램

• 인터넷과 로그인 불필요

• 큰 한국어 버튼으로 즉시 재생

• 여러 소리의 동시 재생

• 반복, 개별 음량, 페이드인·페이드아웃 지원

• 돌발 상황을 위한 전체 즉시 정지

• 장면별 보드 생성과 로컬 저장·복원

• 앱을 열자마자 소리가 나지 않도록 자동재생 금지

• 녹음·참여자 이름·상담 내용 저장 금지

• 원격 서버나 외부 음원 서비스에 연결하지 않음

저작권이 불분명한 영화·게임·유튜브 음원을 번들로 넣지 않고, 직접 만들 수 있는 음향은 합성하고 외부 음원은 사용권을 확인한 로컬 파일만 추가하도록 범위를 정했습니다.

AI와의 협업 방식

장면소리는 기술 조사, 코드 구현, 보안 검토, 시각 검수, Windows 패키징 등 서로 다른 종류의 작업이 필요한 프로젝트였습니다.

한 에이전트가 자신의 판단을 그대로 구현하고 다시 스스로 검수하면 같은 오류를 놓칠 수 있습니다. 긴 대화 안에서는 현재 단계와 남은 과제를 파악하기도 어려워집니다. 그래서 이번 프로젝트를 계기로 기존의 일상 대화용 반려 에이전트와 별도로 칸반 전용 작업 프로필 3개를 새로 만들었습니다.

이 워커들은 사용자와 일상 대화를 나누는 캐릭터가 아니라 칸반에서 내부 과제를 수행하기 위한 작업 전용 프로필입니다. Telegram이나 Slack 같은 외부 대화 채널과 자동 시작 기능도 연결하지 않고, 필요한 작업이 배정될 때만 움직이도록 범위를 제한했습니다.

ALT

syrp w w w w w w w w w w w

그림 2. 일상 대화용 에이전트와 칸반 작업 전용 워커를 분리해 운영한 Hermes 프로필 구조. 화면에는 프로필 머리글자만 표시되므로, 각 워커의 실제 역할은 위 표와 함께 봐야 합니다.

칸반을 활용한 작업 분할

루너가 전체 목표를 한 번에 워커에게 넘기지 않고, 완료 조건이 다른 세 개의 과제로 분해했습니다.

1. 조사 과제

[장면소리 MVP] 현장 요구·기술·안전 명세 조사

worker-scout가 드라마치료 현장의 사용 흐름과 기술·안전 기준을 조사했습니다.

• 큰 한국어 버튼을 사용하는 사운드 큐 보드

• 여러 음원의 동시 재생

• 반복과 페이드인·페이드아웃

• 전체 즉시 정지

• 로컬 파일 저장과 파일 재연결

• 자동재생 금지

• 개인정보를 저장하지 않는 구조

• 로컬 음원과 원격 URL의 구분

• Electron의 파일 접근 및 보안 경계

• 저작권 음원을 기본으로 포함하지 않는 원칙

조사 결과는 구현 워커가 바로 사용할 수 있도록 요구사항과 수용 기준이 담긴 명세 문서로 남겼습니다.

2. 구현 과제

[장면소리 MVP] Electron·React 앱 구현과 Windows 패키징

worker-maker는 조사 결과를 바탕으로 실제 프로그램을 구현했습니다.

• Electron·React·Vite 기반 앱

• Web Audio API 기반 재생 엔진

• 음원 추가·재생·정지·반복

• 개별 음량과 마스터 음량

• 페이드인·페이드아웃

• 다중 동시 재생

• 전체 즉시 정지

• 보드 생성·이름 변경·삭제

• 설정 저장과 재실행 후 복원

• Windows 포터블 실행 파일 제작

구현 여부는 설명이나 코드 제출만으로 판단하지 않고, 자동 테스트와 프로덕션 빌드, 실제 Windows 실행 파일 생성까지 완료 조건으로 두었습니다.

3. 독립 검수 과제

[장면소리 MVP] 독립 기능·안전·시각 검수

worker-review에는 구현을 맡기지 않고 만들어진 결과만 독립적으로 검토하도록 했습니다.

• 명세와 실제 프로그램 기능 비교

• 프로그램 실행 화면 확인

• 재생·반복·오류 상태 표시

• 음량 변경의 실제 반영 여부

• 큐별 페이드 설정

• 파일 이동 후 재연결 흐름

• Electron 파일 접근 범위

• Windows 패키징 결과

• 주요 조작 버튼의 시각적 명확성

ALT

다양한 유형의 글쓰기를 보여주는 웹사이트의 스크린샷

그림 3. 「장면소리」 MVP를 조사·구현·독립 검수 과제로 분해해 운영한 실제 Kanban 화면. 촬영 시점에는 현장 요구·기술·안전 조사가 완료됐고, 구현 과제는 문제 해결을 위해 차단됐으며, 독립 검수 과제가 대기하고 있었습니다. 이는 최종 완료 화면이 아니라 작업 도중의 상태입니다.

칸반에는 단순히 할 일을 적은 것이 아니라 카드마다 담당 워커와 완료 조건을 연결했습니다. 작업은 TODO → READY → RUNNING → REVIEW → DONE으로 이동하고, 문제를 해결하거나 다른 결과를 기다려야 할 때는 BLOCKED로 표시했습니다.

총괄 루너의 역할

워커를 추가한다고 작업이 자동으로 완벽해지는 것은 아니었습니다.

실제로 검수 과정에서 워커가 반복적으로 “다시 검토해 달라”는 후속 작업을 만들면서 유사 카드가 중복 생성되는 문제가 생겼습니다. 구현 카드가 자동 분해와 재검토를 반복하면서 흐름이 복잡해지기도 했습니다.

이때 루너가 총괄자로 개입했습니다.

1. 반복 생성된 중복 과제와 자동 실행 중단

2. 실제 소스와 산출물 직접 확인

3. 남은 오류를 하나씩 재현

4. 테스트를 추가한 뒤 수정

5. 프로그램 재빌드

6. Windows 실행 화면 재확인

7. USB 포터블 복사본까지 최종 재검증

이 경험을 통해 여러 AI 워커를 사용할수록 총괄 역할이 오히려 더 중요해진다는 것을 알게 됐습니다. 각 워커의 “완료했다”는 보고는 자기보고일 뿐이므로, 실제 파일이 만들어졌는지, 테스트가 통과했는지, 실행 파일이 열리는지, 검수에서 발견된 문제가 수정됐는지를 별도로 확인해야 했습니다.

발견된 문제와 해결

칸반의 구현과 독립 검수를 거치면서 다음 문제를 발견해 수정했습니다.

1. 저장된 보드를 다시 열면 기존 음원 경로를 재생하지 못하는 문제

2. 파일 재연결 기능은 있지만 화면에 사용할 버튼이 없는 문제

3. 재생 상태가 화면에 즉시 반영되지 않는 문제

4. 재생 중 음량 변경이 실제 소리에 적용되지 않는 문제

5. 파일의 필요한 범위보다 많은 메모리 데이터가 전달될 수 있는 문제

6. 큐별 페이드아웃 시간이 적용되지 않고 고정값으로 처리되는 문제

7. 빌드된 테스트 파일이 다시 수집되어 테스트가 실패하는 문제

8. 패키징한 실행 파일에서 화면이 흰색으로만 나타나는 문제

특히 흰 화면 문제는 개발 환경에서는 보이지 않고 실제 Windows 실행 파일에서만 나타난 오류였습니다. 이를 재현하는 회귀 테스트를 먼저 만들고 Vite의 자산 경로를 수정한 뒤 실행 파일을 다시 패키징했습니다. 이후 실제 Windows에서 프로그램 화면이 정상적으로 열리는 것을 확인했습니다.

구현 워커가 “빌드 성공”이라고 보고하는 것과, 총괄자가 실제 실행 파일을 열어 정상 표시를 확인하는 것은 서로 다른 단계였습니다.

기본 음향팩 제작

프로그램이 있어도 사용할 소리가 없으면 현장에서 바로 쓰기 어렵습니다. 그렇다고 영화·게임·유튜브의 음원을 임의로 추출하면 저작권 문제가 생길 수 있습니다.

그래서 외부 유료 서비스를 사용하기보다 직접 제작할 수 있는 소리는 합성하고, 프로그램에 맞게 분류·정규화했습니다.

정서적인 소리는 선율이 강한 음악보다 환경음, 드론, 단순한 질감 위주로 구성했습니다. 진행자의 음악 선택이 참여자의 감정을 특정 방향으로 지나치게 유도하지 않도록 하기 위한 판단이었습니다.

USB 포터블 프로그램의 장점

최종 결과물은 「장면소리 0.2.3 Portable」과 35개의 음향이 포함된 USB 포터블 프로그램입니다.

USB 드라이브 문자는 컴퓨터마다 달라질 수 있습니다. E:에서 만든 USB가 다른 컴퓨터에서는 D:나 F:가 될 수 있기 때문에, 저장된 경로가 현재 USB 위치를 기준으로 자동 복구되도록 보완했습니다.

최종 USB 복사본을 기준으로 다음을 확인했습니다.

• 보드: 1개

• 음원 카드: 35개

• 실제 존재하는 음원: 35/35

• USB 내부 경로: 35/35

• 누락 음원: 0개

• USB 외부를 가리키는 음원: 0개

• 다른 드라이브 문자를 가정한 경로 자동복구: 통과

• 앱 자동 테스트: 10개 통과

• TypeScript 컴파일: 통과

• Vite 프로덕션 빌드: 통과

• Electron 빌드: 통과

• 체크섬 대상 파일: 47개

• 체크섬 불일치: 0개

• 전체 용량: 약 129MB

초기 재생 점검 중 소리가 들리지 않는 상황도 있었지만, 프로그램이나 USB의 음원 경로 문제가 아니라 PC와 스피커의 연결 문제로 확인됐습니다. 이 경험을 통해 앱 기능뿐 아니라 현장 출력 장치까지 포함한 점검 절차가 필요하다는 것도 알게 됐습니다.

프로그램 전후의 변화

프로젝트에서 배운 점

1. 현장 도구의 즉시성

고급 편집이나 믹싱보다 중요한 것은 진행자가 장면을 보면서 망설이지 않고 소리를 켜고 끌 수 있는 것이었습니다.

2. 역할 분리의 중요성

조사한 워커가 구현하지 않고, 구현한 워커가 최종 검수까지 독점하지 않도록 역할과 완료 조건을 분리한 것이 핵심이었습니다.

3. 칸반의 통제 기능

어떤 작업이 실행 중인지, 무엇이 차단됐는지, 누가 검토해야 하는지를 한 화면에서 볼 수 있었습니다. 작업의 선후관계와 중단 지점을 명확히 할 수 있다는 점이 단순한 할 일 목록과 달랐습니다.

4. 현장 사용 가능성

코드 작성과 빌드 성공만으로는 충분하지 않았습니다. 실제 실행, 음원 연결, 출력 장치, USB 이동, 드라이브 문자 변경까지 확인해야 현장용 도구에 가까워졌습니다.

5. 워커 보고의 신뢰성

“완료했다”는 메시지가 실제 실행 성공을 의미하지는 않았습니다. 소스, 테스트 결과, 생성 파일, Windows 실행 화면을 확인하는 종단 검증이 필요했습니다.

6. 자동화의 중단 규칙

검토와 후속 요청이 반복되면 유사 작업이 계속 만들어질 수 있었습니다. 최대 재시도 횟수, 중복 카드 생성 금지, 최종 판단을 총괄자에게 돌리는 조건 같은 종료 규칙이 필요했습니다.

7. AI 협업 후 현장 검수

현장 전문가는 목적과 치료적 판단 기준을 세우고, 총괄 에이전트는 일을 설계하고 통합하며, 작업 전용 워커는 조사·구현·검수를 나눠 수행했습니다.

이 프로젝트는 “AI가 혼자 앱을 만들었다”기보다, 현장 전문가는 목적과 기준을 세우고 총괄 에이전트는 일을 설계하며 작업 전용 AI 워커가 각 단계를 수행한 협업 사례에 가까웠습니다.

현재 한계와 다음 단계

현재 버전은 기능 검증을 마친 MVP이지만, 실제 치료 회기에서의 사용성과 효과를 체계적으로 평가한 것은 아닙니다.

다음 단계에서는 기능을 더 늘리기보다 실제 현장에서 다음을 관찰하려 합니다.

• 진행 중 버튼 크기와 배치가 충분히 직관적인가

• 자주 사용하는 소리와 사용하지 않는 소리는 무엇인가

• 음향이 장면의 몰입을 돕는가, 오히려 방해하는가

• 청소년 참여자가 특정 소리에 불편함을 느끼는가

• 전체 즉시 정지 버튼이 긴급 상황에서 충분히 빠르게 보이는가

• 워밍업·갈등·잉여현실·역할 벗기·나눔 등 회기 단계별 보드가 필요한가

• 운영자가 직접 음원을 추가하고 정리하기 쉬운가

• 중복 카드와 반복 검토를 방지할 칸반 종료 규칙은 충분한가

현재 만들어 둔 음원들은 퀄리티가 좀 낮아서, 여러 음원자료 사이트와 ai등을 서칭하여 참조하도록 작업 명령을 내려둔 상태입니다.
이게 완료되고 사용량 초기화가 다가오면, 폰에서 사용가능하도록 앱으로 한번 만들어 볼까 생각중입니다.

마무리

「장면소리」는 생각만 해보던 것을 구현해보는 과정이 였습니다.

장면의 흐름을 끊지 않고, 진행자가 필요한 순간에 필요한 소리를 바로 꺼내 쓸 수 있게 한다.

이 목표를 기준으로 Windows 프로그램, 기본 음향 35개, USB 포터블 환경까지 하나의 MVP로 만들었습니다. 동시에 칸반 전용 워커를 새로 구성하면서, 여러 AI가 함께 일할 때 필요한 역할 분리, 완료 조건, 독립 검수, 총괄 개입과 종료 규칙도 직접 경험했습니다.

이번 스터디를 하면서 가장 좋은 경험은, 현장 아이디어를 시험 가능한 형태로 빠르게 현실화, 구현화하는 것이였던 것 같습니다.

ps : 주말에 초기화 소식을 알려주셔서 잘 불태웠습니다