안녕하세요, AI 엔지니어 @noprogllama입니다.

AI (인공지능, Artificial Intelligence) Agent Skill은 AI 에이전트에게 전달할 재사용 가능한 절차서입니다.

예를 들어, 매일 밤 "오늘 볼 기사를 골라주고, 남은 태스크도 확인해서, 내일로 미룰 것을 결정해줘"라고 AI에게 부탁한다고 가정해 봅시다. 매번 그것을 말로 설명하는 것은 번거로우므로, 미리 절차서로 정리해 둡니다. 이것이 Skill입니다.

절차서는 수정하면 좋아지는 경우가 있습니다.

하지만, 수정했다고 생각했는데 다른 부분이 망가지는 경우도 있습니다. 흔히 있는 일이죠.

그래서 이번에는 AI용 문제집을 만들었습니다.

수행한 내용은 다음과 같습니다.

• AI에게 줄 문제를 만든다
• AI에게 답을 하게 한다
• 정답을 확인한다
• 수정 전과 수정 후를 비교한다

이 기사에서 사용하고 있는 eval (평가, evaluation)은 거의 "문제집과 정답 확인"이라는 의미입니다.

전체적인 모습은 다음과 같습니다.

이번에는 Microsoft Waza 스타일의 파일 구성을 사용했습니다.

단, Waza 본체를 Codex 대응으로 개조했다는 이야기는 아닙니다. Waza 스타일의 문제집을 읽고, Codex CLI가 문제를 풀게 하는 작은 runner를 만들었다는 이야기입니다.

이번에 테스트한 것

주제로 삼은 것은 제가 밤에 사용하고 있는 브리핑용 Skill입니다.

이 Skill은 추천 기사, '좋아요'를 누른 기사, 남은 태스크를 보고 오늘 읽을 것과 내일로 미룰 것을 정리합니다.

밤 브리핑을 주제로 삼은 이유는, 좋은 답과 나쁜 답을 결정하기 쉬웠기 때문입니다.

예를 들어, 다음과 같은 조건이 있습니다.

• 반드시 출력해주길 바라는 헤드라인이 있다
• 기사 제목이나 링크를 마음대로 만들어서는 안 된다
• '좋아요' 기사가 비어 있다면, 비어 있다고 써주길 바란다
• 취득에 실패했을 때, 긴 에러나 비밀 정보를 출력하지 않았으면 한다
• 아침 날씨만 물어봤을 때, 밤 브리핑으로서 동작하지 않았으면 한다

이러한 조건들은 문제집으로 만들기 쉽습니다.

이번에는 4문제만 준비했습니다.

작은 문제집이지만, 처음에는 이것으로 충분합니다.

갑자기 큰 시험을 만드는 것보다, 우선 4문제로 어떻게 망가지는지를 보는 편이 다루기 쉽기 때문입니다.

처음에는 잘 되지 않았다

먼저, Codex에게 풀게 하기 전에, waza check로 문제집 자체를 확인했습니다.

여기서 보고 싶은 것은 AI의 똑똑함이 아닙니다.

문제문, 입력 데이터, 정답 확인 규칙이 제대로 연결되어 있는지 여부입니다.

첫 번째 결과는 다음과 같았습니다.

4문제 중 2문제밖에 통과하지 못했습니다.

특히 실패했을 때와 데이터가 비어 있을 때 통과하지 못했습니다.

즉, 평소의 입력이라면 어느 정도 동작하지만, 상황이 조금만 벗어나면 무너진다는 뜻입니다.

실제 운용에서는 이 부분을 확인하는 것이 중요하다고 생각합니다.

데이터를 가져올 수 없는 날도 있고, 대상이 비어 있는 날도 있습니다.

AI가 마음대로 그럴싸한 기사를 만들어 버리면, 나중에 사람이 곤란해지니까요.

수정한 내용

수정한 것은 두 가지입니다.

첫 번째는 Skill 본문입니다.

"무엇을 하는 Skill인지"와 "무엇을 하지 않는 Skill인지"를 명확하게 썼습니다.

예를 들어, 밤 브리핑에는 사용한다. 아침 날씨 확인에는 사용하지 않는다. 이런 경계를 명시했습니다.

두 번째는 문제집 측면입니다.

실패했을 때나 데이터가 비어 있을 때에도, 어떤 헤드라인을 출력해주길 바라는지를 적었습니다.

이 부분이 모호하면 AI는 악의 없이 다른 형태로 답합니다. 뭐, 사람도 문제문이 모호하면 답이 흔들리곤 하니까요.

수정 후에는 다음과 같이 되었습니다.

여기서 알 수 있었던 것은, Skill 자체뿐만 아니라 문제집을 쓰는 방식도 중요하다는 점입니다.

Skill을 수정하고 있다고 생각해도, 실제로는 문제문이 부족한 경우가 있습니다.

Codex로도 시도했다

다음으로, Codex CLI로 실제로 문제를 풀게 했습니다.

이를 위해 waza-codex-runner라는 작은 도구를 만들었습니다.

이 runner는 GitHub에도 올려두었습니다.

이것은 Waza 본체의 fork가 아닙니다.

하는 일은 Waza 스타일의 문제집을 읽고, Codex CLI에 전달하여 정답을 확인하는 것뿐입니다.

구체적인 사용법이나 커맨드는 GitHub의 README에 작성했습니다.

공개용 리포지토리에는 runner 본체, README(이용 설명 파일, Read Me), 라이선스, 설정 파일, 샘플, 테스트만을 넣었습니다. 실험 결과 파일이나 기사용 소재는 넣지 않았습니다.

README에도 적어두었지만, 이 runner는 Microsoft Waza 및 OpenAI와는 무관합니다.

그대로의 문제로는 차이가 나지 않았다

처음에 Codex로 시도했을 때는, 수정 전이나 수정 후나 4문제 중 4문제를 모두 통과했습니다.

언뜻 보기에는 수정한 의미가 없어 보입니다.

하지만 자세히 살펴보니 이유가 있었습니다.

문제문 안에 정답의 형태가 상당히 많이 적혀 있었던 것입니다.

예를 들어, 출력해주길 바라는 헤드라인(見出し) 이름을 문제문에 적어두면, Skill 본문이 조금 약하더라도 AI는 정답을 맞힐 수 있습니다.

테스트로 비유하자면, 문제문에 정답의 힌트가 너무 많은 상태입니다.

그래서 또 다른 문제집을 하나 더 만들었습니다.

이번에는 문제문에서 정답의 힌트를 줄였습니다. Skill 본문만을 보고 기대한 형태로 답할 수 있는지 확인합니다.

결과는 다음과 같았습니다.

드디어 차이가 나타났습니다.

수정 전 버전에서 탈락한 주요 이유는 오래된 출력 형식을 사용했기 때문입니다.

수정 후 버전에서는 다음 조건을 만족할 수 있었습니다.

• 필요한 헤드라인을 출력함
• 주어진 기사 제목, 링크, 요약만을 사용함
• 취득할 수 없을 때, 가공의 기사를 만들지 않음
• 추천 기사가 비어 있다면, 비어 있다고 작성함
• 날씨만 요청했을 때는, 밤 브리핑(night briefing)을 시작하지 않음

이것은 "Codex가 대단해졌다"는 이야기가 아닙니다.

Skill 측에 원하는 형태와 예외 발생 시의 처리 방법을 적었기 때문에, 문제문이 도와주지 않아도 기대한 형태에 가까워졌다는 이야기입니다.

다른 Skill에도 가볍게 적용해 보았다

같은 사고방식을 다른 Skill에도 가볍게 적용해 보았습니다.

이 결과만으로 모든 품질을 보증할 수는 없습니다.

하지만 "어디가 고장 났는지"를 확인하는 데에는 충분히 유용했습니다.

해보면서 알게 된 점

가장 좋았던 점은 수정해야 할 부분을 분리할 수 있었다는 것입니다.

waza check

에서 탈락한다면 문제문이나 정답 확인 규칙을 살펴봅니다.

waza check

은 통과하는데 Codex로 풀게 했을 때 탈락한다면 Skill 본문을 살펴봅니다.

waza check

도 Codex 실행도 모두 통과한다면 다음으로는 문제 수를 늘립니다.

이렇게 분류할 수 있게 되면 Skill의 개선이 상당히 수월해집니다.

지금까지는 Skill을 수정한 뒤에 "아마 좋아졌을 것이다"라고 생각할 수밖에 없었습니다.

지금은 적어도 "이 4문제에서는 탈락하지 않는다"라고 말할 수 있습니다.

이 차이는 작아 보이지만, 매일 사용하는 도구에서는 상당히 큽니다.

주의점

이번 결과에 대해서는 4문제뿐이므로, 이것만으로 완전히 안전하다고는 할 수 없습니다.

또한, mock이라고 불리는 가상의 실행에서 100%가 된다고 해도, 실제 AI가 항상 좋은 문장을 쓴다는 보장은 없습니다.

이번에 측정할 수 있었던 것은 주로 최소한의 약속입니다.

• 필요한 헤드라인이 있는가
• 만들어서는 안 되는 정보를 만들고 있지는 않은가
• 빈 데이터나 취득 실패를 처리할 수 있는가
• 관련 없는 요청에서 동작을 시작하지 않는가

문장의 가독성이나 제안의 센스까지 측정하려면 별도의 채점이 필요합니다.

다음에 한다면 날짜가 다르거나, 기사 수가 많거나, 요약이 누락된 경우 등 문제를 조금 더 늘려 나가야 할 것입니다.

마치며

이번에 한 일은 화려한 모델 비교가 아닙니다.

AI의 절차서에 작은 문제집을 붙였을 뿐입니다.

하지만 이것이 있으면 수정하기가 쉬워집니다.

Skill은 사용하다 보면 조금씩 비대해집니다. 깎아내면 이번에는 망가지지 않았을까 불안해집니다.

그래서 미리 문제집을 놓아두는 것입니다.

애플리케이션 개발처럼, Skill 개발에 테스트를 마련하고 그것을 토대로 개발할 수 있게 된 느낌입니다.

AI의 절차서를 키워나간다면 이것은 상당히 사용하기 편한 발판이 될 것이라고 생각했습니다.

Discussion