데모 피드백, 서로 상처 안 나게 주고받는 법

데모를 주고받다가 관계가 어색해지는 지점은 대개 비슷합니다. 한쪽이 "음… 뭔가 좀 아쉬운데요"라고 말하고, 받은 쪽은 무엇을 고쳐야 할지 모른 채 며칠을 보냅니다. 다시 보낸 버전에 또 비슷한 반응이 돌아오면 그때부터는 곡이 아니라 사람에 대한 피로가 쌓입니다.

피드백이 어려운 이유는 냉정해서가 아니라 모호해서입니다. 반대로 아무리 날카로운 지적이라도 어느 구간의 무엇을 어떻게 하자는 것인지 분명하면 받는 쪽은 기분이 상하기보다 일이 진행된다고 느낍니다. 이 글은 온라인 협업에서 흔히 쓰이는 방식을 정리한 것으로, 정답이라기보다 처음 팀을 꾸릴 때 참고할 기준에 가깝습니다.

좋은 피드백에는 세 가지가 들어갑니다. 어디인지(시간), 무엇이 그런지(현상), 어떻게 해 봤으면 하는지(제안)입니다. "1분 12초 후렴 들어가는 부분에서 보컬이 반주에 묻혀요. 기타를 조금 줄이거나 보컬을 올려 보면 어떨까요"처럼 적으면 상대는 바로 손댈 수 있습니다.

현상과 제안을 구분해서 적는 것도 중요합니다. 현상은 듣는 사람 대부분이 동의할 수 있는 사실에 가깝고, 제안은 취향이 섞인 의견입니다. 둘을 섞어 "기타를 줄여야 해요"라고만 말하면 상대는 취향 강요로 받아들이기 쉽습니다. "후렴에서 보컬이 안 들린다"는 현상에는 대개 동의가 되고, 그걸 어떻게 풀지는 함께 정하면 됩니다.

칭찬을 먼저 하라는 말은 종종 형식적인 포장으로 오해됩니다. 하지만 협업에서 "이 부분이 좋다"는 말은 예의보다 정보에 가깝습니다. 상대는 그 말을 듣고 어떤 방향을 지켜야 하는지 압니다. 좋았던 구간을 말해 주지 않으면, 수정하다가 정작 제일 좋았던 부분을 갈아엎는 일이 생깁니다.

특히 원격으로 작업할 때는 표정이나 말투가 전달되지 않습니다. 같은 문장도 글로 보면 더 차갑게 읽히니, 무엇이 마음에 들었는지 한 줄 적어 두는 것만으로도 오해가 줄어듭니다.

피드백이 계속 도는 이유 중 하나는 끝나는 지점을 정하지 않았기 때문입니다. 작업을 시작할 때 "믹스는 두 번까지 수정하고, 세 번째부터는 일정을 다시 잡자"처럼 정해 두면 서로 마음이 편합니다. 수정 횟수를 정하면 피드백도 자연스럽게 모아서 한 번에 전달하게 됩니다.

범위도 함께 정해 두세요. 밸런스나 톤 조정은 믹스 단계에서 얼마든지 가능하지만, 곡 구성이나 코드 진행을 바꾸는 것은 편곡을 다시 하는 일에 가깝습니다. 같은 "수정"이라는 말 안에 전혀 다른 크기의 작업이 섞여 있으니, 큰 변경이 필요하면 새 작업으로 보고 일정을 다시 합의하는 편이 낫습니다.

피드백을 받으면 바로 손대기 전에 한 번 정리해 보세요. 여러 사람이 같은 구간을 지적했다면 그건 취향이 아니라 실제 문제일 가능성이 큽니다. 반대로 한 사람만 말한 것이라면 곡의 방향과 견줘 판단하면 됩니다. 전부 반영하려고 하면 곡이 아무 색도 없이 밋밋해집니다.

반영하지 않기로 한 의견도 답을 주는 게 좋습니다. "말씀하신 신스는 일부러 비워 둔 자리라 그대로 가려고 합니다"처럼 이유를 한 줄 적으면 무시당했다는 느낌이 남지 않습니다. 협업이 오래 가는 팀은 대개 이런 짧은 답장을 잘 합니다.

피드백은 파일을 주고받는 속도보다 대화가 이어지는 속도에 좌우됩니다. 메일로 주고받으면 한 번 왕복에 하루가 걸리지만, 팀 채팅에 파일을 올리고 그 자리에서 시간과 함께 적으면 그날 안에 방향이 정해집니다. IGNITE에서는 팀을 만들면 팀 채팅이 함께 열리고, 오디오 파일을 그대로 올릴 수 있습니다.

정리된 피드백은 나중에 크레딧을 정리할 때도 근거가 됩니다. 누가 어떤 제안을 했고 무엇이 반영됐는지가 채팅에 남아 있으면, 기여도를 두고 기억이 엇갈릴 일이 줄어듭니다.