머릿속에 있던 로그 정의 기준을 모두의 AI 스킬로 만들기

토스 앱에서 사용자가 어떤 화면을 보고 무엇을 눌렀는지는 앱로그로 남아요.

토스는 이렇게 쌓이는 로그를 서비스 품질을 높이는 목적으로 사용해요. 그래서 로그를 처음부터 정확하고 일관되게 정의해야 분석 결과도 믿을 수 있어요. 이를 위해 로그를 전담해 설계하고 관리하는 DataOps Manager와 로그 명세를 한곳에서 관리하는 플랫폼인 로그센터가 있어요.

DataOps Manager는 앱로그의 규칙과 맥락을 지키며 담당 도메인의 로그 명세를 정의하고 관리해요. 이번 글에서는 비개발자인 DataOps Manager들이 모여 로그센터에서 수동으로 진행하던 로그 정의 업무를 AI 스킬로 개선한 과정을 소개하려고 해요.

1. 로그 정의할 때 중요한 것들

앱 화면은 끊임없이 새로 생기고 바뀌어요. 그때마다 DataOps Manager(DOM)는 사용자의 행동을 어떤 로그로 기록할지, 그 로그에 어떤 파라미터를 함께 남길지 새로 정해야 해요.

로그를 정의할 때에는 다음 네 가지를 챙겨야 해요.

로그 규칙은 '앱로그 백과사전'에 정리되어 있었어요. 하지만 로그를 정의할 때는 규칙뿐 아니라 도메인의 맥락과 히스토리도 중요해요. 기존 로그 명세를 직접 검색해 참고할 수는 있었지만, 도메인의 맥락은 담당 DOM의 머릿속에 남아 있는 경우가 많았어요. 그래서 각자가 가진 맥락과 경험에 의존해 로그센터에서 수동으로 로그를 정의하고 관리했어요.

한 사람이 정확하게 정의하기도, 모두가 일관되게 정의하기도 어려웠던 부분을 저희는 AI 스킬로 로그를 정의하는 방식과 과정 모두를 개선하고자 했어요.

2. 로그 정의 과정을 AI 스킬로 옮기기

로그를 정의할 때마다 앞에서 본 네 가지 규칙을 찾아보고 도메인의 맥락까지 기억하는 건 쉽지 않은 일이었어요. 그래서 한 DOM이 자신이 알고 있던 규칙과 경험을 살려, 로그 정의를 돕는 작은 스킬을 만들어 쓰기 시작했어요. 하지만 이 스킬은 만든 사람의 도메인과 경험에 묶여 있어서, 만든 사람은 편했지만 다른 사람이나 다른 도메인에서는 그대로 쓰기 어려웠어요.

그래서 저희는 이 스킬을 누가 어떤 도메인에서 작업하든 함께 쓸 수 있도록 제대로 풀어보기로 했어요. 로그를 정의할 때 거치는 판단과 순서를 개인의 머릿속이 아니라 스킬 안에 담으면, 매번 규칙을 외우지 않아도 되고 모든 도메인에서 같은 기준으로 정의할 수 있으니까요.

그렇게 만든 '로그 정의 스킬'은 로그 명세를 대신 찍어내는 생성기는 아니에요.

새 로그를 만들기 전에 '앱로그 백과사전'의 표준을 확인하고 도메인의 기존 로그 명세를 끝까지 조회해 재사용할 수 있는지 먼저 살피고, 실제 반영은 사람이 확정한 뒤에만 실행해요. (이 스킬은 사용자의 로그를 읽거나 처리하지 않아요.)

화면 하나의 로그를 정의해달라고 하면 로그 정의 스킬은 다음의 순서로 움직여요.

이 과정에서 스킬, 로그센터의 CLI(Command Line Interface)인 lctl, 로그센터는 역할을 나눠 맡아요.

스킬은 맥락에 따른 판단을 안내하고, 확신할 수 없는 부분은 사람에게 물어요. 로그 이름 형식처럼 기계가 판정할 수 있는 규칙은 lctl이 저장 전에 검사하고, 로그센터는 규칙에 맞지 않는 명세의 발행을 거절해요. 형식 규칙은 스킬에 적어두지 않고 실행할 때마다 lctl에 묻기 때문에, 규칙이 바뀌어도 스킬은 늘 최신 기준을 따를 수 있어요.

3. 개인 도구에서 팀 표준으로

로그 정의 스킬을 함께 쓰려니 개인이 사용할 때보다 고려해야 할 게 많았어요. 한 사람의 업무에 맞춰져 있던 안내를 여러 DOM이 활용할 수 있도록 다듬고, 이후에 보완한 내용도 함께 관리할 방법이 필요했죠. 마침 로그센터와 lctl을 개발 및 관리하는 로그 프로덕트팀에서 스킬을 lctl에 포함해 함께 배포하자는 제안을 해주셨어요.

협업 과정에서는 문서 구조도 개선했어요. 처음엔 한 문서에 규칙과 절차를 다 담았는데, 길어질수록 AI가 중요한 규칙을 놓쳤거든요. 로그 프로덕트팀의 프론트엔드(FE, Frontend) 개발자분께 기술 검토를 받아, 한 문서에 모여 있던 규칙과 절차를 작업별로 나누고, 스킬에는 각 문서를 찾아가는 안내를 남겼어요. AI가 매번 긴 문서를 읽지 않고, 해당 작업에 필요한 내용만 찾아 읽을 수 있게 된 거예요.

이번 기회로 일하는 방식도 달라졌어요. 기존에는 업무 도구를 개선할 때, 실사용자로서 필요한 기능과 업무 맥락을 기획 과정에 전달했어요. 하지만 이번에는 그 맥락을 가장 잘 아는 저희가 AI를 활용해 필요한 도구를 직접 만들었어요. 그리고 플랫폼 조직인 로그 프로덕트팀은 저희가 만든 스킬을 검토한 후 lctl에 통합해 배포하는 일을 맡아주셨어요.

업무를 아는 사람이 직접 만든 해결 방법에 플랫폼 조직의 기술과 운영 경험이 더해지면서, 동료들도 함께 쓰는 도구로 발전시킬 수 있었어요.

4. 더 수월하게, 더 일관되게 로그 정의하기

스킬을 함께 쓰기 시작하면서, DOM이 로그를 정의하는 과정과 시간을 쓰는 곳도 달라졌어요.

예전에는 디자인이 나오면 DOM이 화면을 보며 필요한 로그를 설계했어요. 기존 로그 명세를 재사용할 수 있는지 찾아보고, 새로 만들어야 한다면 이름과 구조를 정했죠. 스크린샷을 준비하고, 정리한 명세를 로그센터에 하나씩 입력하는 일도 직접 했어요.

지금은 디자인과 필요한 맥락을 전달하면 스킬이 기존 로그 명세와 파라미터를 조회하고, 재사용 후보와 새로운 명세를 제안해요. DOM이 검토해 확정하면 lctl로 로그센터에 반영하죠.

로그 정의 스킬을 직접 사용한 동료들은 이렇게 이야기해주셨어요.

5. 로그 규칙에서 도메인 맥락까지

규칙 확인은 이제 lctl과 스킬이 맡게 됐어요. 여기까지 오는 동안 저희는 각자 맡은 도메인에서 이미 정의된 로그 명세를 정답지로 두고, 같은 화면을 로그 정의 스킬로 다시 정의해 비교하는 평가를 거치면서 개선했어요.

평가를 거듭할수록 분명해진 건, 정의의 품질을 좌우하는 게 규칙보다 도메인의 맥락이라는 점이었어요.

앞으로는 도메인 맥락을 지식 베이스로 축적해 로그 정의 스킬이 직접 참고하도록 하려고 해요.

도메인별 로그 이름과 파라미터의 의미, 그렇게 정한 이유를 정리해 두고, 스킬이 로그를 정의하기 전에 이를 먼저 읽게 하려고 해요. 이를 통해 도메인에 특화된 로그는 물론, 복잡한 유저 플로우의 로그도 더 정확하고 일관성 있게 정의하고 활용할 수 있을 것으로 기대해요.