클로드 코드 코덱스 도입 후 꼭 해야 할 모델 매핑 | 토큰 아끼는 방법

안녕하세요. 퇴근길 AI 망구입니다. 방글라데시에서 잘 살아서 보겠습니다. 오늘은 모델과 업무 테스크를 매핑하는 것에 대해서 이야기해 보려고 합니다. 여기 있는 그림 보이시나요? 제가 강의 때 자주 쓰는 건데 AI 모델을 사람 연봉에 비유한 겁니다.

신입 5년차 실무자, 10년차 전문가, 그리고 분야 최고 전문가 이렇게 나눠 놨는데요. 제가 그리고 이전 에피소드에서 이런 말을 했었어요. 연봉 2억짜리한테 3천만 원짜리 일을 시키지 마세요. 반은 맞고 반은 틀렸습니다. 뭐가 틀렸냐면 연봉 얘기만 하고 일 얘기를 제가 그때 안 했었거든요.

그러니까 모델을 나누는 기준이 연봉만 되면 안 된다. 업무의 복잡도가 필요하다라는 겁니다. 그래서 오늘은 저희가 실제로 회사에서 어떻게 나누고 있는지 그대로 말씀드릴게요. 저희는 업무를 세 단계로 봅니다. 액션, 테스크, 그리고 워크플로우요. 하나씩 가볼까요? [울음] 첫 번째는 액션입니다.

행동 하나예요. 이메일을 한 통 보낸다. 우리 사내 메신저에 올린다. 파일을 분류한다. 뭐 이런 것들이 다 액션이라고 할 수 있죠. 이 정도는 하위 모델들도 상당히 잘합니다. 이렇게 나 >> 네. 저희 집 고양이인데 시끄러워서 한번 출연시켜 봤습니다. 인사하세요. 두 번째는 테스크입니다.

행동이 몇 개 이어진 건데요. 고객사 요구 사항 정리라는 업무가 있습니다. 고객사가 보낸 메일을 열어서 읽고 우리 양식에 맞게 정리하고 그거를 관련된 팀원들한테 메신저로 공유를 해야 되는 겁니다. 그러면 메일을 열고 내용을 읽고 양식 맞게 정리하고 메신저를 보내고 네 단계죠. 이미 순서가 정해져 있고 뭘 해야 되는지 스킬화만 되어 있으면 하위의 모델도 정말 잘합니다.

세 번째는 워크플로우 단위인데요. 이건 좀 다릅니다. 예를 들어 고객 요구 사항에 맞게 제안서 작성한다라는 것은 리서치라고 하는 테스크, 기존 제안 분석하기라는 테스크, 제안서 서식을 만들고 편집하는 테스크. 그래서 여러 단계의 조건들이 필요하기 때문에 상당히 복잡하고 어려워요. 그리고 이게 순서가 막 정해져 있게끔 할 수 있는게 아니고 제 사고가 들어가야 되고 많은 이전의 문서들을 읽고 새로운 맥락들을 캐치해야 돼요.

그래서 저는 이런 활동일 때는 상위 모델을 사용합니다. 자, 하위 모델과 상위 모델의 기준은 저는 소네트와 오퍼스를 나누는데요. 소네트는 테스크 단위를 처리하는 것. 그리고 오퍼스 이상부터는 이런 일들을 같이 한다고 보시면 됩니다.

자, 그럼 경계가 어디냐? 저는 이걸로 봐요. 정해진 일이냐, 정해지지 않은 일이냐? 정해진 일은 순서가 있어요. 뭘 할지 이미 아는 거예요. 그럼 충분히 하위 모델로도 가능한데 정해지지 않는 일들, 뭘 해야 할지 처음부터 고민해야 하는 것들은 좀 상위 모델이 필요합니다. 아까 테스크랑 워크플로우 차이가 이거였죠.

단계의 수보다는 순서와 맥락이 충분히 있냐 보시면 될 거 같습니다. 고객 요구사항 정리는 네 단계 정도 순서가 이미 정해져 있었지만 제안서 작성은 한 덩어리라서 순서가 좀 없었죠. 그래서 이런 지점들을 저희 팀에서는 찾아내고 분리하려고 노력하고 있습니다. 우리가 무작정 너무 좋은 모델만 써도 안 되지만 너무 싼 모델만 사용해도 안 됩니다.

어 앤트로픽에서 공식적으로 나온 가이드인데 가장 복잡한 업무일수록 가장 비싼 모델을 사용해라. 그 모델을 사용하는 것이 싼 모델로 다섯 번 여섯 번 돌려서 디버깅을 하고 틀린 점을 지적하고 다시 읽게 만드는 것보다 좋은 모델로 좋은 방법을 빠르게 찾는 것이 시간적으로나 토큰 비용적으로 더 쌀 수 있다라고 합니다.

그럼 실무에서 어떻게 하냐? 정해지지 않는 일은 일단 좋은 모델로 먼저 틀을 잡습니다. 무슨 일인지, 순서가 뭔지, 뭘 놓고 뭘 빼야 되는지 그걸 먼저 정의합니다. 그리고 정의가 되면 하위 모델로 내려보내요. 이게 그냥 내려서 하위 모델로 보내는 건 아니고 우리가 스킬이라고 하는 걸 활용해서 하위 모델도 잘 일을 할 수 있는 메뉴얼을 만들어서 보내 주는 겁니다. 즉 이렇습니다.

좋은 모델로 정의를 하고 하위 모델로 스킬을 활용한다. 그러니까 모델 매핑이라는 것이 처음부터 어떤 표를 만드는 거보다 일을 하면서 하나씩 내려보는 거라고 보시면 되겠습니다. 자, 여기까지 간단하게 모델과 업무 테스크에 대한 이야기를 좀 해 봤는데요. 사실은 이거 진짜 어려운 문제긴 합니다. 왜냐하면 현장의 실무자는 그냥 제일 좋은 모델로 빨리 끝내고 싶어 하거든요.

당연하죠. 내 돈이 아니고 결과가 제일 좋고 빨리 일이 끝나면 집에도 빨리 가니까 저도 사실 그런 경향이 많습니다. 그러니까 업무랑 모델을 명확하게 매핑하지 않으면 조직에서 이걸 컨트롤할 방법이 없어요. 싼 거 쓰세요라고 말만 해서는 안 지켜집니다. 그리고 오히려 싼 거만 쓰다가 오히려 일이 복잡해지는게 아까 말씀드렸던 정해지지 않는 일에다가도 적용하기 때문입니다.

그래서 사용량의 기준이나 한도 아니면 효율적으로 잘 쓴 사람에 대해서 인정해 주는 그런 방식들이 조직 간의 그라운드룰로 있어야 행동으로 옮길 수 있을 것 같아요. 자, 이것도 뭐 정답인지는 모르겠습니다. 너무 쪼이면 일이 안 되고 너무 좀 안 쪼이면 또 청구서가 날라오니까요.

비싼 청구서가 날라오죠. 어려운 문제입니다. 이 퇴근길 AI 구독자 여러분들은 어떻게 사용하고 계십니까? 가장 높은 단계에 있는 오퍼스 모델을 바로 쓰시나요? 아마 개인적으로 섀도우 AI로 몰래 쓰신 분들은 그렇겠지만 우리 조직의 엔터프라이즈로 사용하신 분들은 다를 겁니다.

아마 토큰과 크레딧 비용에 대한 직격탄을 맞고 있을 테니까요. 여러분들은 모델과 업무를 어떻게 매핑해야 좋을 거라고 생각이 드시나요? 여러분들만의 기준과 사용법을 나눠 주세요. 그러면 저희도 같이 배우겠습니다. 오늘은 제가 재택근무를 하는 날이었습니다. 그래서 집에서 인사를 드리게 되었고요. 보시면은 목소리가 갈라지는 거 느끼셨겠지만 네글데시 복기 외 독감인지 코로나인지 모르겠지만 세게 걸렸습니다.

AI 보다 건강, AI 실력은 체력입니다. 여러분들 우리나라의 물이 상당히 깨끗하고 마음껏 마시고 씻을 수 있다는게 굉장한 행복이었습니다. 감사합니다. 대한민국.