Gena Labeling Tool 개발기 : 기획부터 PoC 까지
안녕하세요, 저는 Gena Co. 인턴 김현진(Andrew) 입니다.
Gena에서 text2sql GenaSQL의 자연어(NL) - SQL query 변환 간 AI 학습을 위한 고품질의 데이터 셋을 만들기 위해, 기존 데이터 셋의 주석과 오류 점검에 참여하면서, CSV 파일로 수동으로 진행하던 애로사항을 발견했습니다. 이러한 문제를 해결할 수 있을 만한 Gena Labeling Tool 기획을 할 수 있는 기회를 얻게 되어 PoC(Proof of Concept) 수준으로 개발하게 되어 그 개발기를 소개시켜드리려고 합니다.
데이터 분석가 니즈 파악 : 비효율적인 라벨링
데이터 분석가 분과 얘기를 통해 진행하면서, 분석가의 페인포인트를 확인할 수 있었습니다. 첫번째로 해결하기 위해서, 활용할 수 있는 오픈 소스를 찾아보았지만, 기존의 오픈소스인 Doccan, Labeling Studio 툴의 공동 작업 외에 "라벨링 기능" 에만 국한되어 있는 것을 넘어서, 아래의 내용을 해결할 수 있어야 했습니다.
- text2sql AI 학습 데이터를 위한 사전 제작된 데이터의 수작업 수정 및 오류 수정 과정에서 수작업으로 대용량의 큰 CSV 파일에서 이루어지고 있어, 길어지는 작업 시간과 많은 리소스가 낭비
- 미래에는 크라우드 소싱을 통해 라벨링 및 데이터 관리 작업을 위임하여 작업을 더 빠르게 진행할 수 있도록 도움을 줄 수 있는 툴이 필요
- 데이터 분석가 분이 사용할 수 있는 내부 툴로 활용을 할 수 있어야
정리한 내용을 가지고 좀더 구체화하여 데이터 분석가분을 User로 설정하여, Gena Labeling Tool을 기획하게 되었습니다.
Gena Tool 의 Key Feature 설정하기
툴 사용자 Persona 설정과 유저 스토리
- Admin: 데이터 관리, 사용자 역할, 로깅, 보고서 및 접근 제어 관리. 데이터 라벨링, 수정, 검토 처리 등
- Reviewer(일반유저): 데이터 라벨링, 수정, 검토 담당 등
툴을 직접적으로 사용할 두명의 페르소나를 개발자 입장에서 데이터 분석가 분과 협의하면서 중요 스토리들을 작성하면서 주요 기능을 구체화 할 수 있었습니다. Admin은 기본적인 라벨링과 업데이트를 할 데이터를 관리할 수 있고, Reviewrer는 일종의 Assgin(분담)을 Admin 에게 받아 툴을 활용한다는 가정하에 작성했습니다.
주요 페르소나들의 툴 사용 시나리오를 기반으로 필수 기능, 구현 난이도, 중요성, 그리고 AI 팀과의 협업 여부를 회의를 통해 정리하였습니다. 인턴십 기간이 제한적이며, 모든 팀원이 항상 이 프로젝트에 참여할 수 없는 현실적인 제약이 존재하기 때문에, 우선순위를 설정하여 가장 중요한 기능부터 개발하는 방향으로 결정하였습니다. 이에 따라, PoC 수준의 개발을 진행하며 핵심 기능을 구현하고, 이후 필요에 따라 확장할 수 있도록 먼저 계획하였습니다.
그렇게 Gena Labeling Tool의 PoC 로서는 우선순위 Hight의 Admin과 Reviewer(Labeler)의 핵심 기능을 중심으로 중심기능 (Key Feature) 정리할 수 있었습니다.
주요 기능 Key Feature
따라서 위와 같이 주요 기능은 데이터를 파일로 업로드 및 다운로드하여 관리할 수 있고,관리자는 업로드 된 데이터를 토대로, 그룹을 생성해서 리뷰어에게 할당하여 여러 사용자가 동시에 라벨링과 수정 작업을 수행할 수 있도록 기능을 주요 기능으로 설정했습니다.
업데이트 데이터 다루기 : Event Sourcing 패턴
AI 팀과 제품팀의 협업 회의에서 Gena Labeling Tool은 최종적으로 Event Sourcing 패턴을 채택하기로 결정하게 되었습니다. Gena Labeling Tool은 데이터셋을 여러 리뷰어가 자연어(NL)와 SQL 쿼리 데이터에 대해 라벨링/정보 업데이트를 할 수 있습니다. 또한, Admin은 Reviewer들의 업데이트 사항을 확인하고 승인하는 과정이 필요했기 때문에, 여러 개의 기존의 데이터 덮어쓰기 방식인 CRUD 방식이 아닌, 모든 업데이트 버전을 추적하고 관리할 수 있는 Event Sourcing 패턴 방식을 적용하기 위함이었습니다. 이를 통해 유형별(자연어 질문, SQL 쿼리, 라벨, 삭제 여부 등) 데이터 변경 이력을 명확히 기록하고, 잘못된 업데이트나 실수를 특정 시점으로 복원할 수 있는 유연성을 확보하고자 했습니다.
업데이트 데이터 버저닝 적용
위는 간략하게 Gena Labeling Tool이 버저닝과 함께 업데이트가 작동하는 패턴 방식입니다. CSV 파일을 통해 업로드된 데이터셋을 기준으로 User A와 User B가 하나의 샘플 데이터를 업데이트를 서로 요청하고, Admin이 특정 User의 최신 데이터를 기반으로 승인하는 과정입니다.
Gena Labeling Tool은 여러 컬럼(sql_query, natural_question) 또는 샘플에 할당된 라벨을 업데이트할 때, 각 컬럼별(Attribution별)로 이벤트를 분리하여 저장하는 방식입니다. 예를 들어, sql_query와 natural_question 업데이트는 각각 b와 c 이벤트로 저장됩니다.
Event Sourcing 패턴에서는 읽기를 위한 개별 테이블이 존재하지만, PoC 단계에서는 최소한의 관계(Relation) 테이블만 생성하여 하나의 테이블에서 작업이 되도록 개발이 진행되었습니다. Admin의 데이터 Fetch는 Java 애플리케이션의 서비스 로직에서 처리되며, Admin은 각 사용자가 업데이트한 컬럼의 최신 값을 조회할 수 있습니다. 각 이벤트는 APPROVED 상태로 채택되고, 최신 값들만 반영하여 UPDATED 상태로 저장됩니다.
반려된(REJECTED) 이벤트 역시 삭제되지 않기 때문에, 해당 버전별 이벤트를 사용자가 조회하여 해당 데이터를 새로운 버전으로 업데이트할 수 있도록 했습니다.
MVP에서는 ROLE을 활용 : JWT 적용
위의 간단한 예제 코드 처럼 PoC에서는 요청 정보를 받아 서비스 로직을 거쳐 응답하는 REST API 구현하는 데 집중했지만, 역할별로 기능을 분리하는 작업은 진행하지 않았습니다. 따라서 MVP를 제작하게 된다면, Java 애플리케이션에서 역할(Role)별 권한을 부여하는 방식으로 MVP에 적용할 필요가 있다고 생각합니다. 예를 들면, 모든 Reviewer의 업데이트 요청 사항을 Admin만 볼 수 있도록 해야할 것입니다.
위의 그래프와 같이, 사용자가 로그인할 때 발급된 JWT에 역할 정보가 포함되어, Gena Labeling Tool Server와의 요청/응답 시 이 JWT를 사용하여 Spring Security 필터로 JWT 검증을 비롯해 권한별 엔드포인트를 조절로 MVP를 구현할 수 있을 것입니다.
마치며
짧은 인턴십 기간 동안 팀과 협업하고 회의를 통해 기획하며 개발을 할 수 있었던 훌륭한 기회였습니다. PoC로 시작한 프로젝트가 실제 제품의 MVP로 발전했으면 좋았겠지만, 시간과 리소스 부족으로 아쉬움이 남습니다. 그럼에도 불구하고, 오픈소스로 충분히 활용 가능한 툴이 될 수 있도록 첫 마일스톤을 달성한 것도 큰 도움이 되었던 Gena 에서의 경험이었습니다.