토스의 DataOps 매니저는 앱의 화면과 행동을 어떤 로그 명세로 남길지 정한다. 새 화면이 생길 때 이름을 짓는 일만으로 작업이 끝나지 않는다. 같은 의미를 기록하던 기존 정의가 있는지 살피고, 해당 도메인에서 그 이름을 어떤 뜻으로 썼는지 확인해야 한다. 토스가 공개한 AI 스킬은 이 판단을 개인의 기억에 두지 않고 공통 작업 순서로 옮기려는 시도다.
연구 제안을 다루는 Ai2의 릿피벗도 이미 있는 자료와 새 문장의 관계에서 출발한다. 제안의 방향을 바꾸면 비교할 선행 연구도 달라진다. 두 도구는 서로 다른 일을 다루지만 초안을 먼저 완성해 두고 나중에 근거를 덧붙이는 방식을 피하려 한다. 기존 정의의 재사용 여부나 새 기여를 설명할 논문을 작성 과정 안에서 직접 선택하게 설계했다.
로그 이름은 도구가 검사하고 의미는 사람이 읽는다
토스의 스킬은 화면을 살핀 뒤 규칙과 도메인의 기존 로그 명세를 조회해 재사용 후보와 새 명세를 제안한다. 담당자가 검토해 확정하면 로그센터 CLI인 lctl로 반영한다. 사용자의 행동 로그를 직접 읽거나 처리하는 도구가 아니라는 점을 분명히 한다. 이름이 형식에 맞는지 같은 기계적 규칙은 저장 전에 lctl이 검사하고 로그센터도 발행 단계에서 판정한다.
기존에 카드사를 card_company로 기록했다면 새 이름 issuer를 만들기 전에 같은 의미인지 살필 수 있다. 반대로 비슷한 이름이어도 다른 기능 전용이라면 섞어 쓰지 않아야 한다. 토스는 형식 규칙을 스킬 문서에 고정하지 않고 실행할 때 도구에 묻도록 했다고 설명한다. 바뀌는 규칙의 관리와 맥락에 따른 재사용 판단을 서로 다른 위치에 배치했다.
문단을 고르면 비교할 논문도 바뀐다
릿피벗에서는 짧은 연구 제안을 문제·기여·평가 계획으로 나눈다. 사용자가 한 부분을 고르면 옆 패널이 그 관점에 맞춰 관련 논문을 묶고 순서를 조정한다. 사용자는 평가에 쓸 논문을 고른 뒤 수정을 요청하고, 비평과 근거 발췌를 제안된 문장과 함께 확인한다. 수정한 방향에 맞춰 문헌의 순위도 다시 정렬된다.
기여를 바꾸면 평가 계획도 어긋날 수 있어 관련 문장을 다시 보도록 표시한다. 연구자는 제안을 수용하거나 편집하고 거절할 수 있으며 다른 논문을 요청할 수도 있다. 선택 대상은 생성된 문장뿐 아니라 그 문장을 평가할 근거로 확장된다. 고정된 논문 묶음에 초안을 반복해서 맞추는 방식과 달리, 글과 자료의 범위를 함께 움직이는 인터페이스를 제공한다.
팀의 실제 운영과 실험실의 평가를 구분한다
토스는 이미 정의된 로그 명세를 기준으로 같은 화면을 스킬로 다시 정의해 비교하며 도구를 개선했다고 밝혔다. 처음에는 한 문서에 모았던 안내를 작업별로 나누고, 스킬에는 필요한 문서를 찾아가는 길을 남겼다. 이후 도메인별 이름의 의미와 그렇게 정한 이유를 지식 베이스로 축적하려는 계획도 소개했다. 현재 배포 절차와 앞으로 쌓을 자료의 성격을 구분해 읽어야 한다.
릿피벗 연구에서는 17명이 같은 논문 모음을 사용하며 도구와 비교 조건에서 제안을 각각 발전시켰다. 2명의 전문가는 어느 도구로 작성했는지 모르는 상태에서 문헌에 얼마나 근거를 두었는지 평가했다. 더 높은 평가 결과와 참가자가 보고한 새로움이나 유용성은 구별해 해석해야 한다. 이 결과를 토스의 업무 시간 절감이나 모든 분야 연구의 독창성 향상으로 일반화할 수는 없다.
형식이 맞는 문장과 의미가 맞는 선택
토스의 로그 이름은 형식 검사에 통과해도 기존 정의와 같은 뜻인지 별도로 확인해야 한다. LitPivot의 문장도 인용할 논문이 붙었다고 그 논문이 새 기여를 충분히 지지하는지 저절로 결정되지 않는다. 도구가 판정하는 형식과 사람이 읽어야 할 의미를 나누는 지점이 두 작업을 연결한다.
두 사례에서 재사용도 다른 대상에 적용된다. 로그 명세는 같은 행동을 일관되게 기록하려고 재사용하고, 선행 논문은 새 주장과의 차이를 설명하거나 이미 검증한 방법을 이어 쓰려고 선택한다. 같은 자료 조회라는 기능 뒤에 어떤 관계를 만들려는지가 다르므로, 검색 결과를 많이 보여주는 것만으로 두 업무의 완성도를 비교하기는 어렵다.
| 작업 | 재사용하려는 대상 | 남는 판단 |
|---|---|---|
| 로그 정의 | 기존 이름과 파라미터 | 같은 의미와 사용 맥락인가 |
| 연구 제안 | 선행 연구와 평가 방법 | 새 기여를 구별하거나 뒷받침하는가 |
두 도구의 공통점은 생성 작업을 조회와 확정 단계 사이에 위치시켰다는 데 있다. 토스는 도메인 규칙 조회를 앞단에 두고 lctl과 담당자 검토를 뒷단에 배치했다. 릿피벗은 문헌 탐색과 문단 선택을 앞단에 두고 연구자의 수용과 기각을 마지막에 두었다. 이로 인해 작업자는 도구가 만든 초안 자체보다 그 초안이 가리키는 근거 자료의 타당성을 먼저 검토하게 된다.
ARCH.B 의견
문서를 단순히 대량 연결하는 방식만으로는 AI 작업의 신뢰도를 확보하기 어렵다. 토스에서는 기존 매개변수를 재사용할지 결정한 이유가 중요하고, 릿피벗에서는 어떤 논문을 비교 대상으로 골랐는지가 수정 방향을 좌우한다. 단순히 같은 이름이나 인용이 포함되었다는 사실만으로 적절한 연결이 성립하지 않는다. 사용자가 그 연결을 살피고 수정할 수 있는 자리가 인터페이스와 절차에 반드시 마련되어야 한다.
두 시도의 차이점 역시 작업의 성격에서 비롯된다. 로그 명세는 운영 시스템에 직접 반영되므로 엄격한 기계적 형식 검사와 최종 확정의 문턱이 필수적이다. 반면 연구 제안은 근거를 바꾸며 탐색하는 과정이 핵심이므로 글과 문헌 사이의 유연한 왕복이 중심이 된다. AI 도구를 일괄적인 생성 기능으로 취급하기보다 무엇을 확정해야 하는 작업인지 먼저 정의해야 한다.
이러한 작업 설계 방식을 다른 업무 영역으로 확장하려면 도메인 규칙이 기계적으로 검사 가능한 영역인지, 주관적 탐색이 필요한 영역인지 명확히 분류해야 한다. 축적된 기존 데이터가 부족하거나 맥락 정보가 없는 환경에서는 스킬이 올바른 참조 대상을 제시하지 못할 한계가 존재한다. 생성된 초안의 분량보다 검토 대상과 선택의 이유가 뚜렷하게 드러날 때 사용자는 실질적인 수정을 지속할 수 있다.
