디깅 뮤직 위키 자동화 설계기

음악 위키 자동화를 만들기까지

디깅 뮤직은 음악에 대한 번역, 해설, 리뷰, 비평을 함께 담아내는 위키 기반 음악 플랫폼이다. 이 위키를 채우는 일은 단순히 가사를 번역하는 일이 아니다. 문화적 맥락을 이해하고, 레퍼런스를 해석하고, 은유를 설명하고, 위키에 맞는 일관된 문체로 정리하는 작업이다.

이 작업량을 줄이기 위해 LLM을 활용한 자동화 시스템을 점진적으로 설계했다. 시스템은 단순 번역, 구조화된 생성, 문맥 공유, 그리고 각 출력이 이전 출력 위에 쌓이는 컨트롤 가능한 파이프라인으로 발전했다.

이 글은 그 자동화 설계 과정에서 배운 점을 정리한 개발 회고다.

버전 1: 단순 번역 자동화

첫 번째 버전은 매우 단순했다.

당시에는 가사 DB 구조가 비효율적인 상태였다. 가사 한 줄마다 별도의 엔티티가 필요했기 때문에, 한 곡을 저장하려면 수십 개의 객체를 생성해야 했다. 그만큼 시간, 저장 공간, 서버 자원도 많이 들었다.

자동화 자체도 이미 존재하는 영어 가사를 한 줄씩 번역하는 수준이었다. 곡 전체를 이해하는 구조는 아니었고, 출력도 사람이 다듬기 어려운 형태였다. 필요한 출력 포맷이 복잡했기 때문에 LLM이 그 구조를 안정적으로 따르게 만드는 것도 쉽지 않았다.

이 버전은 자동화가 가능하다는 점을 확인하게 해줬지만, 좋은 시스템은 아니었다. 실제 편집 파이프라인이라기보다는 반복 작업을 조금 줄여주는 스크립트에 가까웠다.

버전 2: DB 리팩토링 이후의 구조화 생성

DB 구조를 정비한 뒤 자동화는 본격적으로 빨라졌다.

Genius에서 가사와 주석을 크롤링하고, 이를 구조화된 형태로 저장한 뒤, 번역, 설명, 소개글, 여담 생성까지 자동으로 처리하는 흐름을 만들었다. 더 이상 가사 한 줄마다 별도의 객체를 만들 필요가 없었기 때문에, 더 적은 리소스로 더 많은 데이터를 처리할 수 있었다.

하지만 이 버전에는 큰 문제가 있었다. 각 출력이 서로 독립적으로 생성됐다는 점이다.

번역, 해설, 소개, 여담은 각각 다른 프롬프트와 다른 입력으로 생성됐다. 번역은 번역에 필요한 정보만 받았고, 소개는 소개에 필요한 배경 정보만 받았다. 해설도 별도의 입력을 기반으로 생성됐다.

이러다 보니 의미적 충돌이 생겼다.

예를 들어 어떤 곡이 반어나 은유를 사용하면, 번역은 너무 직역하고, 소개는 정반대 방향으로 해석하고, 해설은 완전히 다른 주제를 중심으로 전개되는 일이 있었다. 어떤 출력에서는 슬픈 노래라고 하고, 다른 출력에서는 감미로운 사랑 노래라고 말하는 식이었다.

문제는 모델의 문장력이 아니라, 각 생성 단계가 공유하는 문맥이 없다는 점이었다.

버전 2는 효율은 개선했지만 일관성은 해결하지 못했다.

버전 2.5: additional_info를 통한 문맥 공유

이 문제를 해결하기 위해 additional_info라는 입력 항목을 추가했다.

사람이 곡의 주제, 핵심 키워드, 해석 방향을 미리 파악한 뒤 LLM에게 힌트로 제공하는 방식이었다. LLM에게 공통된 기준점을 주자 번역, 해설, 소개, 여담이 같은 방향을 바라보기 시작했다.

이전처럼 출력들이 따로 노는 문제는 줄어들었다.

하지만 아직 완전한 자동화는 아니었다. 내가 먼저 곡을 이해하고, 추가 정보를 수동으로 작성해야 했다. 즉, 시스템은 내가 충분한 배경지식을 가지고 방향을 제시할 때만 잘 작동했다.

자동화가 사람의 사전 해석에 너무 많이 의존하고 있었다.

버전 3: 문맥 기반 해설과 컨트롤 가능한 파이프라인

버전 3부터 진짜 자동화의 가능성이 보이기 시작했다.

문서를 직접 여러 번 완성하다 보니, 나의 수동 작업 방식에도 안정적인 절차가 생겼다. 더 이상 번역, 해설, 소개, 여담 사이를 무작위로 오가는 것이 아니라, 자연스러운 순서가 만들어졌다.

흐름은 다음과 같았다.

1. 크롤링한 데이터와 가사를 바탕으로 곡 소개를 만든다.
2. 그 소개를 문맥으로 사용해 전체 가사 번역을 만든다.
3. 같은 소개를 바탕으로 가사 해설을 만든다.
4. 소개와 외부 데이터를 조합해 여담을 만든다.

이 패턴이 명확해지자, 이를 선형 파이프라인으로 바꿀 수 있었다.

generate_intro → generate_translation → generate_annotation → generate_behind

핵심은 자동화가 엉켜 있는 인간의 작업에서 바로 시작하면 안 된다는 점이다. 먼저 사람이 직접 반복하면서 안정적인 루틴을 찾아야 한다. 그다음에야 그 루틴을 함수로 바꿀 수 있다.

이 구조 위에 약간의 프롬프트 엔지니어링과 파인튜닝을 적용하자, 문체도 위키에 맞게 안정적으로 나오기 시작했고 BBCode 문법도 자동으로 포함되었다.

이 버전은 단순 반복 처리가 아니라, 선형으로 정리된 사고 흐름을 모사하는 자동화에 가까웠다.

버전 4: 비가시적 정보의 생성

다음 버전은 아직 구현 예정 단계다.

지금까지의 시스템은 주로 외부 데이터를 요약하거나 재조합하는 방식이었다. 버전 4에서는 크롤링된 소스에 직접 존재하지 않는 설명까지 생성하는 것을 목표로 한다.

예를 들어 특정 가사의 문화적 연관성, 시대적 해석, 숨겨진 아이러니, 해석이 갈리는 문장에 대한 복수의 관점 같은 것들이다. 즉, 이미 어딘가에 명시적으로 존재하는 텍스트를 가져오는 것이 아니라, LLM이 위키에 새로운 해설 가치를 만들어내는 방향이다.

이를 잘하기 위해서는 단순 문맥 공유만으로는 부족하다. 문장 단위 유사도 분석, 개체명 기반 정렬, 가사와 주석의 정밀한 매칭이 필요하다. 다음 단계에서는 string matching 알고리즘이 중요한 기술 요소가 될 가능성이 높다.

다만 그 전에 버전 3의 전체 흐름을 더 안정화해야 한다. 품질과 일관성이 먼저다.

Supervised Fine-tuning과 DPO

처음에는 번역 품질을 올리기 위해 supervised fine-tuning을 시도했다.

Supervised fine-tuning은 user → assistant 형태의 예시를 학습시켜 모델이 특정 문체, 형식, 말투를 따르도록 만드는 방식이다.

하지만 내 작업에서는 기대만큼 효과가 크지 않았다.

가장 큰 문제는 데이터 품질이었다. 내 서버 구조에서는 사람이 LLM 결과물을 수정했을 때, 수정된 부분만 명확한 교정으로 볼 수 있다. 예를 들어 LLM이 만든 결과의 80%는 괜찮고 20%만 고쳤다면, 실제 학습 신호는 그 20%에 있다. 그런데 supervised fine-tuning은 깔끔한 입력-출력 쌍을 요구한다.

내가 가진 데이터는 검수되지 않은 출력, 괜찮아 보여서 넘어간 출력, 명확히 틀려서 사람이 고친 출력이 섞여 있었다. 처음부터 이들을 구분하는 태깅 구조를 DB에 만들어두지도 않았다.

또한 많은 오류는 정답과 오답의 문제가 아니었다. 둘 다 말은 되지만, 하나가 더 자연스럽거나 더 정확하거나 해석 방향에 더 잘 맞는 경우가 많았다.

그래서 나는 정답보다 선호도의 문제로 보기 시작했다.

DPO는 이 상황에 더 잘 맞는다. 하나의 이상적인 정답만 학습하는 것이 아니라, 두 출력 중 어떤 쪽이 더 나은지를 학습한다. 음악 번역과 해설처럼 문체, 뉘앙스, 해석이 중요한 작업에서는 실제 평가 방식에 더 가깝다.

배운 점 1: 자동화는 마지막에 해야 한다

자동화는 가장 먼저 할 일이 아니라, 오히려 마지막에 가까운 일이다.

자동화는 이미 확립된 흐름을 반복시키는 일이지, 불안정한 흐름을 알아서 정리해주는 기능이 아니다. 작업 흐름 자체가 불명확한 상태에서 자동화를 시도하면 혼란이 더 디버깅하기 어려운 형태로 굳어진다.

자동화는 편해지기 위해 바로 도입하는 것이 아니다. 사람이 같은 작업을 여러 번 수행하고, 그 안에서 반복되는 루틴을 발견했을 때 적용하는 효율화 도구에 가깝다.

내 경험상 자동화란 사람의 작업을 해체하고, 그 일부를 LLM이나 시스템에 조금씩 위임하는 과정이다. 어떤 부분은 여전히 사람이 해야 한다. 어색한 번역은 사람이 고쳐야 하고, 잘못 붙은 주석은 사람이 골라내야 한다. 다만 시간이 지날수록 검수 비율을 줄일 수 있다.

자동화는 스위치가 아니다. 검수 시간을 조금씩 줄이는 흐름이다.

배운 점 2: 선형 구조는 직접 작업하면서 나온다

현실의 많은 작업은 비선형적이다.

사람은 작업하면서 앞뒤를 오간다. 뒤에서 알게 된 정보 때문에 앞에서 내린 판단을 바꾸기도 한다. 가사를 번역하다가 처음 해석이 틀렸다는 것을 깨닫고, 해설을 쓰다가 소개글을 다시 고치게 되는 일도 많다.

인간에게는 자연스러운 일이지만, 자동화하기에는 어렵다.

LLM 파이프라인은 되돌아가는 구조를 명시적으로 설계하지 않는 한 자유롭게 과거 단계로 돌아갈 수 없다. 그래서 자동화 전에 인간의 작업을 선형 절차로 바꿔야 한다.

그 선형 절차는 이론만으로 나오지 않는다. 직접 반복하면서 얻어진다.

디깅 뮤직에서는 여러 번의 수동 작업을 통해 소개를 먼저 만드는 것이 좋다는 걸 알게 됐다. 소개가 곡의 해석 프레임을 제공하기 때문이다. 그 프레임이 생기면 번역과 해설이 훨씬 쉬워지고, 여담은 소개와 외부 데이터를 조합해 만들 수 있다.

파이프라인은 설계실에서 발명된 것이 아니라, 생산 라인에서 추출된 것이다.

배운 점 3: LLM은 줄 번호를 잘 못 센다

의외로 실용적인 교훈은 LLM이 줄 번호를 잘 못 센다는 점이었다.

LLM은 “가사의 14번째 줄” 같은 개념을 안정적으로 갖고 있지 않다. 그래서 특정 해설이 몇 번째 가사 줄에 해당하는지 연결하라고 하면 자주 틀렸다.

해결 방법은 단순했다. 입력 가사 앞에 명시적으로 번호를 붙이는 것이다.

[1] 여전히 밤이 되면 외로워
[2] 넓어지고 많아진 거 빼곤 다 그대로
[3] 매일 쏟아지는 새로운

이렇게 줄 번호를 직접 넣어주자 모델이 올바른 line index를 훨씬 잘 참조하기 시작했다.

여기서 더 넓은 교훈도 얻었다. LLM에게 항상 더 높은 지능이 필요한 것은 아니다. 때로는 문제를 더 잘 보게 해주는 인터페이스가 필요하다.

배운 점 4: 피드백 루프는 나중에 설계해야 한다

피드백 루프는 필요하지만 너무 일찍 설계하면 안 된다.

자동화 시스템이 결과를 내기 시작하면, 사람은 그 결과를 확인하고 평가하고 수정해야 한다. 나중에는 그 수정 데이터를 파인튜닝이나 선호 학습에 활용할 수도 있다.

하지만 자동화 자체가 안정적인 출력을 만들기 전부터 피드백 구조까지 모두 설계하려고 하면 일이 꼬인다. 자동화도 못 하고, 검수도 못 하고, 쓸 만한 데이터도 모으지 못하게 된다.

디깅 뮤직의 피드백 구조도 나중에 생겼다. 지금은 AI가 생성한 결과에 ai 태그를 달고, 입력값, 출력값, 사람이 검토했는지 여부를 DB에 저장하고 있다. 이 구조는 DPO나 추후 학습 데이터 수집에 유용하다.

하지만 이 구조를 처음부터 완벽하게 설계한 것은 아니다. 자동화 결과가 쌓이고, 사람이 반복적으로 수정하다 보니 필요가 구체화되면서 생긴 구조다.

피드백 시스템은 필요가 추상적일 때가 아니라 구체적일 때 만들어야 한다.

비선형적 사고 흐름은 자동화될 수 있을까?

가장 어려운 질문은 인간의 비선형적 사고 흐름을 자동화할 수 있느냐는 것이다.

많은 작업은 단순한 순서가 아니다. 나중에 얻은 정보가 앞선 판단을 수정한다. 작업이 중간에 멈추고, 이전 단계로 돌아가고, 다시 진행되어야 하는 경우가 많다.

어렵지만 어느 정도 근접할 수는 있다고 생각한다.

한 가지 접근은 Function Calling이다. 작업을 명확한 입력과 출력을 가진 외부 함수로 분리하는 방식이다. 또 다른 접근은 라우터 기반 시스템이다. 메타 레벨의 모델이 상황에 따라 어떤 전문 모듈을 사용할지 결정하는 구조다.

개념적으로는 조정자-대리인 구조에 가깝다.

• 메타 레벨 AI가 전체 흐름을 관리한다.
• 번역, 해설, 검토, 포맷팅 같은 세부 작업은 전문 모델이나 함수가 처리한다.
• 메타 AI는 결과를 평가하고, 계속 진행할지, 다시 시도할지, 이전 단계로 돌아갈지를 판단한다.

이는 MoE나 router-based LLM이 지향하는 구조와도 닿아 있다. 제조업의 문제와도 비슷하다. 포드식 컨베이어 벨트는 선형 생산에는 최적화되어 있지만, 맞춤형 제품에는 조건부 분기와 되돌아가기, 상태 관리가 필요하다.

예를 들어 모듈러 주택을 만든다고 해보자. 고객이 내부 자재를 고르다가 기존 구조 설계를 바꾸는 편이 더 낫다는 결론에 도달할 수도 있다. 이때 시스템이 이전 설계 단계로 돌아가지 못하면 완전한 자동화는 어렵다.

비선형 흐름을 자동화하려면 상태 기반 흐름 관리, 조건부 분기, 롤백 가능한 구조, 메타 레벨 판단이 필요하다.

현재 실용적인 방향은 명확하다. 선형화할 수 있는 것은 선형화하고, 모듈화할 수 있는 것은 모듈화하고, 불확실성에 도달했을 때만 사람이 개입하게 만드는 것이다.

결론

디깅 뮤직의 위키 자동화를 설계하면서 가장 크게 배운 것은, 자동화가 단순한 기술적 가속이 아니라는 점이다.

자동화는 일을 이해하는 과정이다.

어떤 작업이 자동화되려면, 먼저 사람이 그 일을 직접 해보고, 분해하고, 순서를 만들고, 안정화해야 한다. LLM은 처음부터 사고를 대체하는 존재가 아니다. 사람이 이미 구조화한 흐름의 일부를 조금씩 넘겨받는 존재에 가깝다.

목표는 사람을 바로 제거하는 것이 아니다. 검수 시간을 줄이고, 출력의 일관성을 높이고, 결국 인간의 판단이 가장 중요한 곳에만 쓰이게 만드는 것이다.