여러 AI 모델 함께 쓰는 법: 실제로 통하는 네 가지 방식

모델 하나로는 부족한 이유

여러 AI 모델을 쓰라는 흔한 논거는 각자 잘하는 게 다르니 작업마다 최적의 모델을 고르라는 것입니다. 맞는 말이지만, 가장 재미없는 이유이기도 합니다.

더 나은 이유는 모델이 자기 사각지대를 볼 수 없다는 점입니다. 모델에게 자기 작업을 검토하라고 하면 대체로 잘 됐다고 확인해 줍니다. 오류를 만들어낸 그 가중치가 확신도 함께 만들어냈기 때문입니다. 다른 데이터로 다르게 학습되어 실패하는 방식도 다른 모델에게 물으면, 첫 번째 모델이 볼 수 없던 것을 짚어냅니다. 무슨 요령이 아니라, 고객에게 메일을 보내기 전에 동료에게 읽어봐 달라고 하는 것과 똑같은 이치입니다.

두 번째 이유는 현실적입니다. 선두는 계속 바뀝니다. 이번 분기에 코딩을 가장 잘하는 모델이 다음 분기에도 그럴 거라는 보장은 없습니다. 한 회사에 기대어 만든 업무 흐름은 순위가 흔들릴 때마다 다시 짜야 합니다. 모델을 갈아탄다는 전제 위에 세운 업무 흐름에는 그런 문제가 없습니다.

이제 네 가지 방식을 들이는 노력 대비 효과가 큰 순서로 소개합니다. 넷 다 필요하지는 않습니다. 대부분은 앞의 두 가지에서 거의 전부를 얻습니다.

방식 1: 초안은 한 모델, 비평은 다른 모델

효과가 가장 큰 방식이자, 거의 아무도 쓰지 않는 방식입니다. 한 모델로 쓰고, 다른 모델로 검토하세요.

이게 통하는 이유는 만드는 일과 평가하는 일이 서로 다른 일이기 때문입니다. 글을 만들어내는 모델은 앞뒤가 매끄럽게 이어지는 쪽으로 최적화합니다. 자기가 쓰지 않은 글을 평가하는 모델은 그 논지에 걸린 게 없어서, 세 번째 문단이 앞과 이어지지 않는다고 덮지 않고 그대로 말합니다.

여기서는 프롬프트가 엄청나게 중요합니다. 이거 어떻게 생각해라고 물으면 칭찬이 돌아옵니다. 대신 이렇게 요청하세요.

아래 글은 당신이 쓴 것이 아니고, 당신에게는 아무 이해관계도 없습니다. 회의적인 편집자로서 검토해 주세요. 다음 순서로 정리해 주세요. 1) 틀렸거나 근거가 없거나 지나치게 단정적인 사실 주장, 2) 논리가 실제로는 이어지지 않는 지점, 3) 가장 약한 문단 하나와 그 이유. 아무것도 고쳐 쓰지 마세요. 잘된 점은 말하지 마세요.

실제 일을 하는 건 마지막의 지시 세 개입니다. 고쳐 쓰지 말라는 지시는 모델이 제 목소리로 새 버전을 뽑아내는 것을 막습니다. 그건 요청한 게 아니니까요. 잘된 점은 말하지 말라는 지시는 대부분의 AI 피드백을 부풀리는 반사적인 칭찬을 걷어냅니다. 당신이 쓴 글이 아니라는 설정은 의외로 효과가 큰데, 모델이 자기 것이라 여기는 선택을 방어하려 드는 걸 막아주기 때문입니다.

그다음 동의하는 부분만 골라 첫 번째 모델에 다시 가져가세요. 어떤 지적을 받아들일지 정하는 편집자는 당신이고, 그게 딱 알맞은 역할 분담입니다.

2분을 더 들일 값어치가 있는 경우는 이렇습니다. 고객에게 나가는 것, 공개되는 것, 틀렸을 때 대가가 큰 것. 그럴 필요가 없는 경우는 이렇습니다. 사내 메신저 한 줄, 초벌 개요, 장보기 목록.

방식 2: 불일치 점검

전부를 손으로 검증하지 않으면서 환각을 잡아내는 방법 중, 믿을 만한 탐지기에 가장 가까운 것입니다.

같은 사실 질문을 같은 프롬프트로 서로 다른 두 모델에 따로따로 던지세요. 그리고 비교하세요. 두 답이 일치하는 곳은 대체로 괜찮습니다. 답이 갈리는 곳이 바로 확인해야 할 지점입니다.

기법은 이게 전부이고, 강력한 이유는 환각이 대개 공유되지 않기 때문입니다. 모델이 통계나 판례 이름, 함수 시그니처, 날짜를 지어낼 때 다르게 학습된 다른 모델이 똑같은 것을 지어내는 일은 드뭅니다. 일치는 정확하다는 약한 증거일 뿐입니다. 불일치는 뭔가 잘못됐다는 강한 증거이고, 어디가 문제인지 곧장 가리킵니다.

주장이 여러 개 섞인 답변이라면, 비교 자체를 모델에게 시키세요.

아래는 같은 질문에 대한 두 개의 답변이고 각각 A와 B로 표시했습니다. 문체와 길이는 무시하세요. 두 답이 실질적으로 어긋나는 지점을 전부 나열해 주세요. 숫자, 날짜, 이름의 차이와 주장의 강도 차이까지 포함하세요. 각 불일치마다 어느 쪽이 맞을 가능성이 높은지, 그리고 어떤 출처 하나면 결론이 나는지 말해 주세요.

그러면 사실 확인할 긴 문서 대신 확인할 항목의 짧은 목록이 남고, 그 목록은 문제가 어디 있는지 대체로 정확히 짚습니다.

주의할 점 두 가지가 있습니다. 첫째, 인터넷에 흔한 오류라면 두 모델이 같은 실수를 공유할 수 있습니다. 즉 이 방법은 널리 퍼진 잘못된 정보보다는 지어낸 내용을 잡아냅니다. 둘째, 두 모델이 같은 답을 했다고 검증을 건너뛰지 마세요. 이건 확인할 범위를 좁혀줄 뿐, 확인할 필요 자체를 없애지는 않습니다.

쓸 곳은 이렇습니다. 통계, 법률과 의료 관련 주장, 역사적 사실, API 세부 사항, 나중에 인용될 만한 모든 것. 건너뛸 곳은 이렇습니다. 의견, 창작물, 그리고 대충 맞아도 괜찮은 모든 것.

방식 3: 작업별로 나눠 보내기

뻔한 방식이지만 제대로 할 값어치가 있습니다. 마침 열려 있는 창에 전부 던져 넣지 말고, 각 종류의 일을 그 일을 가장 잘하는 모델에 보내세요.

작업	집을 모델	이유
글의 첫 초안	글쓰기가 가장 강한 모델	손보는 시간을 돈으로 미리 사는 셈
그 초안의 검토	다른 모델	새로운 눈, 다른 실패 방식
이번 주 일에 관한 질문	실시간 검색이 되는 모델	학습 데이터는 언제나 뒤처짐
아주 긴 문서나 코드베이스	컨텍스트가 큰 모델	이해하려면 일단 들어가야 함
어려운 논리, 수학, 까다로운 버그	확장 사고가 되는 추론 모델	느리지만 여러 단계 문제에서 훨씬 정확
양 많은 반복 작업	값싸고 빠른 모델	분류와 태깅에 최고급 성능은 낭비
민감한 내용	회사 데이터 규정에 맞는 모델	성능이 의무를 이기지는 못함

들일 만한 습관은 하나입니다. 기본값으로 흘러가지 마세요. 대부분은 구독으로 받은 모델 하나에 모든 일을 던지고, 그 모델이 약한 작업까지 맡긴 뒤 AI는 그런 걸 못한다고 결론 내립니다. 어떤 모델이 맞을지 10초만 생각하는 것이 프롬프트를 한 시간 다듬는 것보다 결과를 크게 바꿉니다.

이 판단의 더 자세한 버전은 AI 모델 고르는 법에 있고, 긴 문서 항목이 왜 따로 있는지는 컨텍스트 윈도우란 무엇인가에서 확인하세요.

방식 4: 인수인계 문서를 쓰고 이어달리기

여러 단계에 걸친 작업에서 무너지는 지점은 단계와 단계 사이의 틈입니다. 한 모델에게 프로젝트를 설명해 쓸 만한 데까지 갔다가, 다른 모델로 옮기면서 지난 대화를 통째로 붙여넣거나 처음부터 어설프게 다시 설명하게 됩니다.

바꾸기 전에 인수인계를 명시적으로 요청해서 해결하세요.

이 대화를 보지 못한 다른 비서를 위해 인수인계 브리프를 써 주세요. 다음을 포함하세요. 우리가 만들려는 것, 이미 내린 결정과 그 이유, 제약 조건과 피해야 할 것, 시도했다가 접은 것, 그리고 내가 다음으로 필요한 것. 나에게 아무것도 되묻지 않고 이어갈 수 있을 만큼 구체적으로 써 주세요.

이건 모델을 바꾸지 않을 때도 쓸모가 있습니다. 느려지고 흐릿해진 긴 대화에서 빠져나오는 가장 깔끔한 방법입니다. 알맹이는 챙기고 쌓인 잡음은 버리기 때문입니다. 이 브리프를 새 대화에 붙여넣으면 대개 품질이 곧바로 올라갑니다.

현실적인 이어달리기는 이런 모습입니다. 200쪽짜리 보고서를 컨텍스트가 큰 모델에 주고 중요한 열 대목을 인용까지 붙인 구조적 요약으로 받으세요. 그것을 글쓰기가 강한 모델로 가져가 고객용 안내문을 만드세요. 그다음 세 번째 모델로 방식 1의 비평 단계를 돌리세요. 다 합쳐 15분쯤이고, 각 단계마다 그 일에 맞는 도구를 썼습니다.

굳이 하지 않아도 되는 때

멀티 모델 업무 흐름에는 부대비용이 있습니다. 그걸 못 본 척하면 두 줄짜리 이메일을 쓰는 데 거창한 절차를 세우게 됩니다.

모델 하나만 쓸 때는 이렇습니다. 일이 작을 때, 틀려도 손해가 적을 때, 만들기보다 탐색하는 중일 때, 빠르게 반복하는 중이라 걸리적거리면 흐름이 끊길 때, 그리고 정말 창작에 가까운 일이라 두 번째 의견이 내 목소리를 흐리기만 할 때.

둘 이상을 쓸 때는 이렇습니다. 결과물이 남에게 갈 때, 사실 정확성이 중요할 때, 서로 다른 강점이 필요한 단계로 일이 나뉠 때, 막혀서 정말 다른 각도가 필요할 때, 그리고 모델이 알려준 내용을 근거로 결정을 내리려 할 때.

쓸 만한 기준이 하나 있습니다. 동료에게 한번 봐달라고 할 만한 일이면, 두 번째 모델에게도 물어보세요. 그럴 일이 아니면 하지 않아도 됩니다.

실제로 굴러가게 만들기

여기까지는 원리로 보면 간단하지만, 모델마다 구독이 따로 있으면 실제로는 성가십니다. 걸리는 게 진짜 있습니다. 탭이 따로 있고, 기록이 따로 쌓이고, 맥락을 옮겨 붙여야 하고, 서식이 깨지고, 그 작은 저항 때문에 정작 가장 필요한 날에 비평 단계를 건너뛰게 됩니다.

위의 방식들이 잘 안 쓰이는 이유가 정확히 그 저항입니다. 어려워서가 아니라, 바쁠 때 건너뛰기 딱 좋을 만큼 번거로워서입니다.

멀티 모델 작업 공간은 바로 이걸 위해 있습니다. Whizi에서는 모델들이 하나의 대화 안에 있어서, 비평 단계가 다른 제품을 열고 초안을 붙여넣는 일이 아니라 모델을 바꾸고 물어보는 일이 됩니다. 기록도 하나, 지금까지 물어본 전부를 훑는 검색도 하나, 청구서도 하나입니다. 이 두 단계가 실제로 어떻게 작동하는지는 대화 중간에 모델 바꾸기와 모델 나란히 비교하기에서 볼 수 있습니다.

따로 구독을 모아 직접 꾸리는 쪽이 낫다면, 이 방식들은 거기서도 그대로 통하니 계속 쓰세요. 달라지는 건 얼마나 자주 실행에 옮기게 되느냐뿐입니다. 이걸 하려고 이미 요금제를 두세 개 결제하고 있다면 절약 계산기부터 돌려보세요. 같은 결과를 얻는 방법치고는 대개 그쪽이 더 비쌉니다.

방식 1부터 시작하세요. 남이 읽게 될 다음 글을 쓸 때, 비평 프롬프트를 다른 모델에 돌려보고 무엇이 나오는지 확인하세요. 그 습관 하나가 이 글의 나머지 전부보다 값어치 있습니다.