> ## Content Index
> Fetch the complete content index at: https://blog.heimdex.co/llms.txt
> Use this file to discover other available public pages before exploring further.

# [heimdex people] 300번 반복되는 화면을 설계한다는 것 - 하임덱스가 라벨링 툴을 직접 만든 이유｜AI & Design
- URL: https://blog.heimdex.co/ko/heimdex-labeling-tool-ai-ux-design/
- Published: 2026-08-31T08:44:11.000Z
- Updated: 2026-08-31T08:44:11.000Z
- Description: 하루 300번 반복하는 작업 화면에서 손과 눈과 귀가 흔들리지 않으려면 어떤 설계가 필요할까요. 하임덱스가 시중 라벨링 툴 대신 직접 화면을 만든 이유를 AI 엔지니어와 프로덕트 디자이너의 인터뷰로 담았습니다.
- Author: Heimdex
- Tags: #ko, Insights

안녕하세요, 양디 입니다.

하임덱스는 영상을 자연어로 검색하는 AI 플랫폼을 만듭니다. "두 가지 제품을 양손에 들고 비교하는 장면"이라고 입력하면 수백 시간짜리 영상 아카이브에서 그 구간만 콕 집어 찾아내죠. 뿐만 아니라 화면을 장면 단위로 나누고 분석하는 기능, 핵심 구간을 골라 숏폼을 자동으로 만드는 기능, 화면 속 모자이크를 입히는 컴플라이언스 블러링까지 모두 한 AI 엔진 위에서 돌아갑니다.

이런 기술을 구현하려면 먼저 "영상을 어떤 기준으로 자를 것인가"에 대한 기준이 필요했습니다. 하임덱스는 이 기준을 직접 정의하고, 요리 방송부터 뉴스 대담, 홈쇼핑 라이브까지 6개 분야의 영상을 다 파헤치며 한국어 영상 평가용 정답 집합(평가셋)을 만들었습니다.

정답 집합이 필요했던 이유는 간단합니다. **정답(기준)이 없으면 AI의 어디를 고쳐야 하는지, 고친 결과가 실제로 좋아졌는지 판단할 수 없기 때문입니다.** AI의 음성 인식 정확도나 검색 성능을 측정하려면 사람이 직접 판정한 기준 데이터가 필수적이었습니다.

이 정답 데이터를 모으기 위해 하임덱스 전용 라벨링 툴을 AI 엔지니어 이재희 님과 프로덕트 디자이너 김준수 님이 함께 구축했는데요. 제품의 성패를 가른 라벨링 툴 개발 비하인드와 치열했던 고민의 과정을 두 분의 인터뷰로 담았습니다.

---

### **Q1\. 저는 마케터라 감이 잘 안 오는데요. 라벨링 툴이라고 하면 그냥 글자 입력하고 버튼 누르는 단순한 화면 아닌가요? 어떤 점이 어려웠나요?**

**준수:** 프로덕트 디자이너인 저도 처음엔 똑같이 생각했어요. 입력창 몇 개 있고 아래에 \[저장\] 버튼 하나 있는 쉬운 화면인 줄 알았죠.

그런데 제가 직접 라벨링 작업을 해보고 생각이 완전히 바뀌었습니다. 이 화면은 작업자의 **귀·눈·손이 동시에 따로 움직이는 고난도 작업 환경**이더라고요. 귀로는 계속 흘러나오는 영상 오디오를 듣고, 눈으로는 화면의 텍스트를 읽고, 손으로는 타이핑을 쳐야 합니다. 게다가 오디오가 흘러가는 속도, 타이핑 치는 속도, 눈으로 읽는 속도가 전부 제각각이에요.

**재희:** 또 하나 중요한 건, 이 화면은 작업자 한 명이 **하루에 수백 번씩 반복해서 쓰는 화면**이라는 점입니다.

보통 우리가 쓰는 일반적인 앱(예: 배달 앱이나 쇼핑 앱)에서는 버튼을 '클릭 한 번 더' 한다고 해서 사용자가 큰 불편을 느끼지는 않죠. 하지만 하루에 똑같은 작업을 300번씩 반복해야 하는 라벨링 툴에서는 다릅니다. 클릭 한 번을 쓸데없이 늘리면, 작업자에겐 그게 곧 하루 300번의 손가락 고통과 피로로 쌓이게 됩니다.

그래서 버튼 하나, 화면 구조 하나를 짤 때 느껴지는 책임감과 설계의 무게감이 일반 서비스와는 완전히 달랐습니다.

### **Q2\. 시중에 이미 라벨링 툴이 많은데, 화면을 굳이 새로 만드신 이유가 있나요?**

**재희:** 가장 먼저 발목을 잡은 건 **'동영상 장면 구간'을 다루는 작업**이었습니다. 시중에 있는 툴들은 대부분 멈춰 있는 사진 속 자동차에 네모 상자를 그리거나 테두리를 따라 선을 따는 '정적인 작업'에 맞춰져 있거든요.

하지만 저희에게 필요한 건 정지 화면이 아니라 **계속 흘러가는 동영상**이었습니다. 소리를 들으면서 "1분 20초부터 1분 45초까지가 요리하는 장면이다"라는 것을 실시간으로 찾아내고 구간을 잘라주는 작업이 필요했는데, 이를 제대로 지원하는 기존 툴이 아예 없었습니다.

기존 툴들의 설정만 살짝 바꿔서 써보려고도 검토해 봤지만, 단순한 옵션 조립만으로는 저희가 원하는 화면을 만들 수 없다는 결론이 났어요. 기존 범용 툴들은 입력 칸을 어떻게 배치할지 정해주는 도구일 뿐인데, 저희에게 정작 중요했던 건 칸의 위치가 아니라 작업자가 판단을 내리는 '순서'였기 때문입니다.

**준수:** 게다가 기존 툴들은 저희가 원하는 판단 로직과 편리한 동작을 전혀 구현할 수 없었습니다.

저희는 `Enter` 키 한 번으로 `다음 칸 이동 → 다음 문장 선택 → 자동 재생`까지 단번에 실행되는연계 동작이 필요했는데, 기존 툴은 이미 정해진 키의 위치만 바꿀 수 있을 뿐 새로운 연속 동작을 만들어내진 못했거든요.

또한, "이전 구간과 라벨 이름은 같아도 실제 대상이 바뀌었다면 메모 입력 없이 저장 불가"처럼 바로 앞 작업 내용과 비교하는 복잡한 규칙을 세우는 것도 불가능했습니다. 영상의 '경계 등급'처럼 여러 항목을 비교해 시스템이 자동으로 계산해 줘야 하는 값을 작업자가 직접 고르도록 열어둘 수도 없는 노릇이었죠. 결국 라벨러가 "보고 듣는다 → 판단한다 → 기록한다"로 이어지는 흐름을 화면이 자연스럽게 이끌어줘야 했는데, 단순히 입력 칸만 조립하는 기존 툴로는 이 핵심 흐름 자체를 설계할 수 없었습니다.

### **Q3\. 디자이너가 라벨링 규칙(스키마) 설계 회의까지 계속 들어간 이유도 같은 맥락인가요?**

**준수:** 맞습니다. 화면 구성 자체가 작업자의 실수를 유도하고 있었기 때문이에요. 작업 도중 발생하는 오류를 조사해 보니, 작업자의 부주의보다는 화면 유도 방식의 문제가 훨씬 컸습니다.

예를 들어 뉴스 스튜디오에서 앵커가 말하다가, 화면 뒤 대형 모니터로 "야외 기자회견 영상"을 틀어주는 장면이 있다고 해볼게요.

- **실제 정답:** 뉴스 스튜디오 안에서 기자회견 영상을 '상영(재생)'하고 있는 상태 (장소: 스튜디오)
- **작업자의 오답:** 눈에 보이는 대로 '야외 기자회견'이라고 적어버림 (장소: 야외)

작업자는 눈앞에 보이는 영상만 보고 직관적으로 입력하게 됩니다. 화면이 "지금 보이는 게 실제 장소인가요, 아니면 스튜디오에서 틀어주는 영상인가요?"를 먼저 확인하도록 순서(단계)를 짚어주지 않으면, 백이면 백 눈에 보이는 '야외'를 찍게 됩니다. 가이드 문서에 아무리 "뉴스 속 영상은 스튜디오로 적으세요"라고 써놔도 소용없는 거죠.

결국 규칙이 잘못된 게 아니라, 화면 구성이 작업자에게 실수를 유도하고 있었던 겁니다. "작업자가 어떤 생각 순서로 판단을 내리는가"를 깊이 이해해야만 오류를 막는 화면을 설계할 수 있었기 때문에, 디자이너인 저도 규칙 설계 회의에 매번 참석해야 했습니다.

### **Q4\. 그렇다면 화면 구조는 어떻게 잡으셨나요?**

**준수:** 원칙은 "작업자의 시선이 한 방향으로만 흐르게 한다"였습니다.

화면을 좌우로 나누어 왼쪽에는 판단의 재료(소리 파형 플레이어, 받아쓴 문장)를, 오른쪽에는 판단의 결과(음성 정보, 구간 등록 칸)를 뒀습니다. 작업자의 "듣고 → 판단하고 → 기록한다"라는 흐름이 화면 왼쪽에서 오른쪽으로 자연스럽게 흐르도록 설계한 거죠.

상단에는 3개 작업 트랙(검색어-장면 연결, 화면 설명, 음성 텍스트화)의 진행률을 상시 노출했습니다. 탭으로 껐다 켰다 하게 만들면 자기가 전체 중 어디쯤 와 있는지 길을 잃기 쉽거든요. 남은 작업 양을 모르는 상태는 반복 작업에서 그 자체로 큰 피로 요인입니다.

![image (9).png](https://storage.ghost.io/c/1b/90/1b90bca5-caef-43b3-90d6-4b197d90c045/content/images/2026/08/-------------------------.png)

### **Q5\. 세 트랙 중 하나만 예시로 들어주신다면요? '쿼리-씬 매핑' 작업 화면은 어떻게 개선했나요?**

**준수:** 원래는 한 화면에 여러 장면을 그리드 형태로 보여주고, 하나를 클릭하면 우측 창에서 평가하는 방식이었습니다. 하지만 이 구조는 시선이 화면 전체와 우측 창을 계속 왕복하면서 "방금 뭘 봤지?", "지금 뭘 평가하고 있지?" 하고 흐름이 자꾸 끊겼습니다.

그래서 **장면 하나에만 집중하는 뷰**로 바꿨습니다. 한 번에 장면 하나만 크게 띄우고, `1`·`2`·`3` 숫자키만 누르면 자동으로 다음 장면으로 넘어가게 했어요. 판단 대상을 한 번에 하나만 보여주면 비교 대상이 사라지니까, 판정이 흔들릴 여지도 줄어듭니다.

### **Q6\. 반복 작업 화면에서 특별히 다르게 접근한 부분이 있다면요?**

**준수:** "작업자의 손이 키보드를 떠나는 횟수"를 세는 것부터 시작했습니다. 단순히 속도를 높이려는 게 아닙니다. 저희 작업은 멈춰 있는 사진에 상자를 그리는 단순 작업보다 판단 자체가 훨씬 복잡하고 오래 걸립니다. 이런 작업일수록 피로가 누적되면 판정 기준이 미묘하게 흔들리기 쉽죠. 그래서 목표를 "빠르게"가 아니라 "장시간 작업해도 기준이 흔들리지 않게"로 잡았습니다. 그러려면 손이 키보드에서 떨어지지 않게 만드는 게 핵심이었어요.

**재희:** 초기 버전은 문장 하나를 처리하는 데 `재생 클릭 → 입력 칸 클릭 → 타이핑 → 다음 칸 클릭 → 타이핑 → 다음 문장 클릭 → 재생 클릭`으로 마우스 왕복만 4번이 필요했습니다. 문장이 24개면 마우스 이동만 96번이죠. 지금은 `Enter` 키 하나만 누르면 `들리는 대로 입력 → 정돈하여 입력 → 다음 문장 이동 및 자동 재생`까지 연쇄로 동작합니다. 마우스에 손을 안 대고 한 작업 단위를 끝낼 수 있어요.

단축키 위치도 도움말 창에 숨겨두면 아무도 안 봅니다. 그래서 플레이어 바로 아래와 텍스트 섹션 상단에 문구(`Space: 재생/일시정지`, `1~5: 속도 설정` 등)로 노출해 눈에 바로 걸리게 했습니다. 재생 속도 역시 조작하기 까다로운 슬라이더 형태 대신 `0.5x`, `0.7x`, `1x`, `1.25x`, `1.5x` 버튼으로 노출해 언제든 "아까 그 속도"로 정확히 돌아올 수 있게 만들었습니다.

![](https://storage.ghost.io/c/1b/90/1b90bca5-caef-43b3-90d6-4b197d90c045/content/images/2026/08/--------------------------3-.png)

### **Q7\. 내부 피드백 중 가장 뼈아팠던 지적은 무엇이었나요?**

**재희:** "사용자가 해야 할 액션이 너무 많다"였습니다. 문장 하나에 마우스 왕복 4번이라는 숫자를 확인한 순간, 이건 300번 반복되면 데이터 품질을 망치는 핵심 원인이라는 게 명확해졌어요. 앞서 말씀드린 `Enter` 연쇄 단축키가 여기서 탄생했습니다.

![](https://storage.ghost.io/c/1b/90/1b90bca5-caef-43b3-90d6-4b197d90c045/content/images/2026/08/image--7-_2--1-.png)

**준수:** 두 번째는 "오른쪽 여백이 너무 커요. 이미지를 더 크게 키워주세요"라는 지적이었습니다. 화면 속 이미지를 판별하는 게 핵심인 작업인데, 여백을 예쁘게 주느라 정작 정답을 찾아야 할 대상을 작게 뒀던 것이죠. 확대 기능이 있으니 괜찮을 줄 알았지만, 확대 버튼을 하루 300번 누르는 사람에겐 그 자체가 벌칙이었습니다.

랜딩 페이지에서는 여백이 신뢰감을 주지만, 작업 화면에서의 여백은 판별할 대상이 작아졌다는 뜻임을 배웠습니다. 재생 버튼 역시 작아서 클릭 실수가 자주 난다는 피드백을 받고 크기를 대폭 키웠습니다. 하루 300번 누르는 버튼과 한 달에 한 번 누르는 버튼은 크기가 같을 수 없습니다.

### **Q8\. 입력 폼이나 캡셔닝 작업 시 작업자마다 답이 흔들리지 않게 하려고 어떤 노력을 하셨나요?**

**재희:** 라벨러가 자유롭게 서술하면 사람마다 표현이 다 달라져 추후 데이터를 모았을 때 대부분 버려집니다. 그래서 모든 항목을 고정 선택지로 바꿨습니다. 소리 품질은 `잘 들림 / 보통 / 안 들림`, 말하는 사람 수는 `0 / 1 / 2 / 3 / 4+`처럼요.

선택지가 숨겨지는 드롭다운 메뉴 대신 화면에 전체 선택지가 노출되는 **세그먼트 버튼**을 써서 클릭 한 번에 끝나게 했습니다. 항목 이름 옆에는 `Verbatim(말 더듬·감탄사 포함)`, `Normalized(숫자·외래어 정돈)`처럼 **짧은 가이드를 바로 옆에 노출**했습니다. 라벨링 가이드 문서를 따로 열어보게 만들면 안 됩니다. 기준은 판단을 내리는 바로 그 자리에 있어야 해요.

가장 까다로운 '영상 분위기(무드)' 표현도 완전 자유 입력 대신, 좌측에서 대분류를 고르면 우측에서 세부 항목을 좁혀 들어가는 2단계 선택 방식을 도입해 주관적인 표현도 비슷한 범주로 모을 수 있었습니다.

### **Q9\. 작업자의 실수를 막거나 피로를 줄이기 위한 UI 장치도 있나요?**

**준수:** 오류 메시지를 보여주는 것보다 **오류가 발생할 수 없는 구조**를 만드는 데 집중했습니다.

대표적으로 타임코드(시간 시점)가 그렇습니다. 초기에는 시간을 숫자(예: 01:23)로 직접 타이핑하게 했는데 형식이 틀리면 뒤쪽 데이터 계산이 통째로 깨졌어요. 지금은 버튼 클릭 한 번으로 **'현재 영상 재생 위치'를 그대로 가져오게** 바꿔 실수를 원천 차단했습니다.

저장 방식도 바꾸었습니다. 기존의 \[저장\] 버튼 하나만 있으면, 작업자는 애매한 상황에서 '대충 찍고 제출'하거나 '그냥 넘기기'를 강요받습니다. 그래서 `임시저장 / 검토 요청 / 제출`로 분리하고, 애매한 구간은 

`들리지 않음`이나 `소리 겹침`으로 등록할 수 있는 경로를 만들었습니다. "잘 모르겠다"를 화면에 표현할 수 있어야 오답 대신 유의미한 데이터가 되니까요.

![](https://storage.ghost.io/c/1b/90/1b90bca5-caef-43b3-90d6-4b197d90c045/content/images/2026/08/--------------------------2-.png)

또한 40개 작업을 통째로 주는 대신 10개씩 작업 단위(Chunk)로 쪼개어 카운트(`1/12`, `1/5`)로 보여줍니다. "하나 끝냈다"는 성취감이 자주 들어야 마지막까지 집중력과 데이터 품질이 유지되거든요.

### **Q10\. 이렇게 정성 들여 만든 라벨링 툴이 실제 제품 성능에는 어떤 차이를 만들어냈나요?**

**재희:** 라벨링 툴은 고객이 보는 화면도 아니고 데모에 나오지도 않습니다. 하지만 **AI 검색 품질의 상한선은 데이터 라벨링 품질에서 결정**됩니다. 장면 경계가 애매하게 찍히면 AI가 엉뚱한 구간을 찾아내고, 음성 받아쓰기가 흔들리면 검색도 무너집니다. AI 모델을 아무리 고쳐도 데이터 품질이 정한 한계를 넘을 수 없어요.  
저희가 만든 정답 데이터는 평가에 그치지 않고, 실제 **하임덱스 음성인식 AI 모델을 학습(파인튜닝)시키는 핵심 원료**로 쓰였어요, 800 건의 장면 매핑과, 1500건의 화면 설명을 통해 저의 연구를 CER 기준 2.39% 개선, 영상 검색 정확도 (Fusion - 영상+음성): 상위 검색 결과 정확도(nDCG@10) +25% 개선하는 큰 도움이 되었습니다.

---

돌아보면 이 작업은 결국 하나의 질문으로 요약됩니다. **"화면이 작업자를 어디로 이끄는가."**

장면 하나에 집중하는 뷰, 손이 키보드를 떠나지 않는 단축키, 재생 위치를 그대로 가져오는 타임코드 모두 "판단하는 그 자리에서 작업자가 흔들리지 않게 만든다"는 단 하나의 원칙에서 나왔습니다.

공개된 AI 데이터셋에서 성능이 잘 나오는 것과 실제 고객사의 영상 아카이브에서 잘 나오는 것은 완전히 다른 문제입니다. 저희가 다루는 실전 영상은 여러 사람이 동시에 말하고, 자막이 화면을 덮으며, 홈쇼핑 진행자가 1시간 동안 같은 제품을 서른 번 다르게 설명합니다.

이런 까다로운 데이터 환경에서 진짜 AI 성능을 올려보고 싶은 분이라면, 언제든 하임덱스의 문을 두드려 주세요!

- **채용 문의:** \[[채용 공고 링크](https://heimdex-dev.notion.site/?pvs=74&ref=blog.heimdex.co)\] / [heimdex@heimdex.co](mailto:heimdex@heimdex.co)