토스 앱에서 사용자가 어떤 화면을 보고 무엇을 눌렀는지는 앱로그로 남아요.
토스는 이렇게 쌓이는 로그를 서비스 품질을 높이는 목적으로 사용해요. 그래서 로그를 처음부터 정확하고 일관되게 정의해야 분석 결과도 믿을 수 있어요. 이를 위해 로그를 전담해 설계하고 관리하는 DataOps Manager와 로그 명세를 한곳에서 관리하는 플랫폼인 로그센터가 있어요.
DataOps Manager는 앱로그의 규칙과 맥락을 지키며 담당 도메인의 로그 명세를 정의하고 관리해요. 이번 글에서는 비개발자인 DataOps Manager들이 모여 로그센터에서 수동으로 진행하던 로그 정의 업무를 AI 스킬로 개선한 과정을 소개하려고 해요.
1. 로그 정의할 때 중요한 것들
앱 화면은 끊임없이 새로 생기고 바뀌어요. 그때마다 DataOps Manager(DOM)는 사용자의 행동을 어떤 로그로 기록할지, 그 로그에 어떤 파라미터를 함께 남길지 새로 정해야 해요.
로그를 정의할 때에는 다음 네 가지를 챙겨야 해요.
로그를 정의할 때에는 로그를 정해진 형식에 따라서, 도메인 안의 맥락을 이어서, 분석에 필요한 것만 남기면서, 정책과 안전을 지켜서 정의해야 해요.
로그 규칙은 '앱로그 백과사전'에 정리되어 있었어요. 하지만 로그를 정의할 때는 규칙뿐 아니라 도메인의 맥락과 히스토리도 중요해요. 기존 로그 명세를 직접 검색해 참고할 수는 있었지만, 도메인의 맥락은 담당 DOM의 머릿속에 남아 있는 경우가 많았어요. 그래서 각자가 가진 맥락과 경험에 의존해 로그센터에서 수동으로 로그를 정의하고 관리했어요.
한 사람이 정확하게 정의하기도, 모두가 일관되게 정의하기도 어려웠던 부분을 저희는 AI 스킬로 로그를 정의하는 방식과 과정 모두를 개선하고자 했어요.
2. 로그 정의 과정을 AI 스킬로 옮기기
로그를 정의할 때마다 앞에서 본 네 가지 규칙을 찾아보고 도메인의 맥락까지 기억하는 건 쉽지 않은 일이었어요. 그래서 한 DOM이 자신이 알고 있던 규칙과 경험을 살려, 로그 정의를 돕는 작은 스킬을 만들어 쓰기 시작했어요. 하지만 이 스킬은 만든 사람의 도메인과 경험에 묶여 있어서, 만든 사람은 편했지만 다른 사람이나 다른 도메인에서는 그대로 쓰기 어려웠어요.
그래서 저희는 이 스킬을 누가 어떤 도메인에서 작업하든 함께 쓸 수 있도록 제대로 풀어보기로 했어요. 로그를 정의할 때 거치는 판단과 순서를 개인의 머릿속이 아니라 스킬 안에 담으면, 매번 규칙을 외우지 않아도 되고 모든 도메인에서 같은 기준으로 정의할 수 있으니까요.
그렇게 만든 '로그 정의 스킬'은 로그 명세를 대신 찍어내는 생성기는 아니에요.
새 로그를 만들기 전에 '앱로그 백과사전'의 표준을 확인하고 도메인의 기존 로그 명세를 끝까지 조회해 재사용할 수 있는지 먼저 살피고, 실제 반영은 사람이 확정한 뒤에만 실행해요. (이 스킬은 사용자의 로그를 읽거나 처리하지 않아요.)
화면 하나의 로그를 정의해달라고 하면 로그 정의 스킬은 다음의 순서로 움직여요.
스킬은 화면 디자인을 살펴보고, 적절한 로그 명세 규칙을 확인한 뒤 재사용할 수 있는 부분을 검토해 로그 명세를 제안해요. DOM이 제안된 명세를 검토해 최종 확정하면, 스킬이 이를 시스템에 반영해요.
이 과정에서 스킬, 로그센터의 CLI(Command Line Interface)인 lctl, 로그센터는 역할을 나눠 맡아요.
스킬은 맥락에 따른 판단을 안내하고, 확신할 수 없는 부분은 사람에게 물어요. 로그 이름 형식처럼 기계가 판정할 수 있는 규칙은 lctl이 저장 전에 검사하고, 로그센터는 규칙에 맞지 않는 명세의 발행을 거절해요. 형식 규칙은 스킬에 적어두지 않고 실행할 때마다 lctl에 묻기 때문에, 규칙이 바뀌어도 스킬은 늘 최신 기준을 따를 수 있어요.
로그 정의 스킬이 판단하고 조율하면, 로그센터 CLI가 저장 전에 미리 걸러내고, 로그센터가 저장하며 최종 판정해요.
3. 개인 도구에서 팀 표준으로
로그 정의 스킬을 함께 쓰려니 개인이 사용할 때보다 고려해야 할 게 많았어요. 한 사람의 업무에 맞춰져 있던 안내를 여러 DOM이 활용할 수 있도록 다듬고, 이후에 보완한 내용도 함께 관리할 방법이 필요했죠. 마침 로그센터와 lctl을 개발 및 관리하는 로그 프로덕트팀에서 스킬을 lctl에 포함해 함께 배포하자는 제안을 해주셨어요.
협업 과정에서는 문서 구조도 개선했어요. 처음엔 한 문서에 규칙과 절차를 다 담았는데, 길어질수록 AI가 중요한 규칙을 놓쳤거든요. 로그 프로덕트팀의 프론트엔드(FE, Frontend) 개발자분께 기술 검토를 받아, 한 문서에 모여 있던 규칙과 절차를 작업별로 나누고, 스킬에는 각 문서를 찾아가는 안내를 남겼어요. AI가 매번 긴 문서를 읽지 않고, 해당 작업에 필요한 내용만 찾아 읽을 수 있게 된 거예요.
이번 기회로 일하는 방식도 달라졌어요. 기존에는 업무 도구를 개선할 때, 실사용자로서 필요한 기능과 업무 맥락을 기획 과정에 전달했어요. 하지만 이번에는 그 맥락을 가장 잘 아는 저희가 AI를 활용해 필요한 도구를 직접 만들었어요. 그리고 플랫폼 조직인 로그 프로덕트팀은 저희가 만든 스킬을 검토한 후 lctl에 통합해 배포하는 일을 맡아주셨어요.
기존에는 현업에서 문제를 발견하면 로그 프로덕트팀에 수정을 요청하고, 작업이 끝날 때까지 기다린 뒤 해결 여부를 확인했어요. 지금은 현업에서 발굴한 개선점을 DOM이 AI 스킬로 직접 개발하고, 로그 프로덕트팀과 협업해 로그센터 CLI에 통합 배포했어요.
업무를 아는 사람이 직접 만든 해결 방법에 플랫폼 조직의 기술과 운영 경험이 더해지면서, 동료들도 함께 쓰는 도구로 발전시킬 수 있었어요.
4. 더 수월하게, 더 일관되게 로그 정의하기
스킬을 함께 쓰기 시작하면서, DOM이 로그를 정의하는 과정과 시간을 쓰는 곳도 달라졌어요.
예전에는 디자인이 나오면 DOM이 화면을 보며 필요한 로그를 설계했어요. 기존 로그 명세를 재사용할 수 있는지 찾아보고, 새로 만들어야 한다면 이름과 구조를 정했죠. 스크린샷을 준비하고, 정리한 명세를 로그센터에 하나씩 입력하는 일도 직접 했어요.
지금은 디자인과 필요한 맥락을 전달하면 스킬이 기존 로그 명세와 파라미터를 조회하고, 재사용 후보와 새로운 명세를 제안해요. DOM이 검토해 확정하면 lctl로 로그센터에 반영하죠.
기존에는 DOM이 디자인 확인부터 명세 수기 입력까지 각 단계를 하나씩 직접 처리했어요. 지금은 DOM이 화면과 맥락을 전달하면 스킬이 기존 정의를 조회해 명세 초안을 쓰고, DOM은 분석 목적과 전체 구조를 검토해 명세를 확정해요.
- 로그의 목적과 전체 구조에 더 집중해요. 로그를 하나씩 찾아 작성하고 옮겨 적는 일이 줄면서, 사용자 흐름 전체를 살피는 데 더 시간을 쓸 수 있게 됐어요. 스킬이 제안한 명세와 추가 정보를 바탕으로, 서비스 품질을 높이는 데 필요한 정보가 빠짐없이 정의됐는지 검토해요.
- 기존 로그와의 연결성을 지키기 쉬워졌어요. 예전에는 기존 정의를 직접 찾아 대조하다 보니, 이미
card_company로 남기던 정보를 놓치고 issuer처럼 다른 이름으로 정의할 위험이 있었어요. 지금은 스킬이 기존 로그 명세와 파라미터를 먼저 조회해 재사용 후보를 제안해요. 담당자가 의미와 사용 맥락을 확인한 뒤 재사용하면서, 같은 정보를 일관된 이름과 구조로 남기고 기존 로그와 연결해 분석하기 쉬워졌어요.
- 각자 챙기던 규칙과 절차를 함께 관리해요. 예전에는 로그 이름과 이벤트 타입의 규칙, 명세를 반영하는 절차를 각자 찾아보고 적용했어요. 이제는 같은 스킬을 사용해 담당자가 달라도 공통된 기준과 순서에 따라 작업할 수 있어요. 사용하면서 보완한 내용도 스킬에 반영하면 다음 작업부터 동료들이 함께 활용할 수 있고요.
로그 정의 스킬을 직접 사용한 동료들은 이렇게 이야기해주셨어요.
“화면에서 새로 정의할 퍼널을 짚어 주기만 했는데 로그가 알맞게 정의돼서 정말 편했어요! 신규 파라미터나 ENUM을 지정하려면 원래 여러 단계를 차례로 거쳐야 하는데, 이제는 요청을 입력하기만 하면 바로 처리되어서 로그 정의 과정이 아주 쾌적해졌어요!”
“제가 생각한 가치는 로그를 대신 만들어주는 것보다, 로그 스키마 생성 정책을 실제 작업 흐름에 내재화했다는 점이었어요. 기존 로그, 파라미터, ENUM을 참조하고 토스의 로깅 정책 기반으로 판단하는 등 DOM의 로그 정의에 근거를 제공해주고 있어요. 동일 의미의 파라미터나 스키마의 중복 발행을 막아주는 등, 여러 인원이 로그를 운영하고 유지보수함에 있어 발생할 수 있는 문제를 방지할 수 있었어요. 앞으로는 발생한 예외 케이스와 정책상의 변경점을 공통화하고 표준화할 수 있을 것으로도 기대합니다!”
“새 로그부터 만들기보다 기존에 쓰던 로그를 먼저 찾아서 재사용하도록 로그 정의 스킬이 도와줬어요. 덕분에 거의 대부분 재사용하고, 정말 새로 만든 건 1개뿐이었어요. 재사용하려던 파라미터가 알고 보니 다른 기능 전용이었던 걸 짚어줘서, 섞여버릴 뻔한 걸 미리 막기도 했어요. 무엇보다 뭔가 바꾸기 전에 '이렇게 바뀔 거예요'를 먼저 보여주고 확인받은 다음에만 적용해서, 안심하고 진행할 수 있었어요.”
5. 로그 규칙에서 도메인 맥락까지
규칙 확인은 이제 lctl과 스킬이 맡게 됐어요. 여기까지 오는 동안 저희는 각자 맡은 도메인에서 이미 정의된 로그 명세를 정답지로 두고, 같은 화면을 로그 정의 스킬로 다시 정의해 비교하는 평가를 거치면서 개선했어요.
평가를 거듭할수록 분명해진 건, 정의의 품질을 좌우하는 게 규칙보다 도메인의 맥락이라는 점이었어요.
평가에서 드러난 세 가지 문제와 각 문제를 해결하기 위해 스킬에 반영한 방법이에요. 기존 로그 탐색, 도메인 간 이름 불일치, 도메인 지식 관리 문제를 각각 분류 추론, 유사 이름 확인, 도메인 표준 입력 방식 등 맥락을 더하는 방법으로 풀었어요.
앞으로는 도메인 맥락을 지식 베이스로 축적해 로그 정의 스킬이 직접 참고하도록 하려고 해요.
도메인별 로그 이름과 파라미터의 의미, 그렇게 정한 이유를 정리해 두고, 스킬이 로그를 정의하기 전에 이를 먼저 읽게 하려고 해요. 이를 통해 도메인에 특화된 로그는 물론, 복잡한 유저 플로우의 로그도 더 정확하고 일관성 있게 정의하고 활용할 수 있을 것으로 기대해요.
적용해보기
1️⃣ 규칙으로 정할 수 있는 것과 사람의 판단이 필요한 것을 먼저 나눠보세요.
로그 이름이 형식에 맞는지처럼 기계가 판정할 수 있는 부분은 도구가 검사해요. 반면 새 화면이 기존 화면과 같은 화면인지처럼 제품 맥락이 필요한 판단은 사람이 맡아요. 이처럼 작업을 기계가 판정할 수 있는 부분과 사람이 판단해야 하는 부분으로 먼저 나눠보세요.
2️⃣ 판단에 필요한 맥락을 머릿속에서 꺼내 문서로 남겨보세요.
로그 정의 스킬은 로그를 정의하기 전에 해당 도메인의 기존 로그 명세와 파라미터를 조회해 맥락을 파악해요. 일부만 살펴보면 이미 있는 정보를 놓치기 쉽거든요. 이처럼 스킬이 참고해야 할 맥락이나 지식이 있다면, 어떤 형태로든 문서로 남기는 것을 시작해보세요. 이런 문서가 쌓이면 스킬이 내 의도에 맞게 더 잘 동작하도록 도울 수 있어요.
3️⃣ AI가 문서를 읽고 판단하게 하고, 확신할 수 없는 건 사람에게 묻게 해보세요.
로그 정의 스킬은 앱로그 백과사전과 상황별 참고 문서 중 이번 작업에 필요한 문서만 읽고, 그 기준에 따라 판단해요. 대신 화면을 재사용해도 되는지처럼 제품 맥락이 필요한 판단이나 확실하지 않은 값은 추측하지 않고 사람에게 물어요.
