yoozafree 님의 블로그

회의 녹음에서 할 일을 자동 생성하기: Deepgram 화자 분리 기반 STT 적용기 및 OpenAI 프롬프팅

yoozafree — Mon, 25 May 2026 14:35:57 +0900

Whisper에서 Deepgram으로 전환하며 회의 참석자별 발화를 구분하고, 이를 기반으로 의 할 일 자동 생성 흐름을 설계한 과정

우리 서비스는 회의 녹음 파일을 기반으로 회의 내용을 기록하고, 회의 중 언급된 할 일을 자동으로 추출해주는 회의 기록 서비스다.

회의가 끝난 뒤 사용자는 “누가 어떤 일을 하기로 했는지” 다시 정리해야 하는 번거로움을 겪는다.
우리는 이 과정을 줄이기 위해 음성 파일을 텍스트로 변환하고, 변환된 회의록을 기반으로 Action Item을 자동 생성하는 기능을 제공한다.

개발 초기에는 OpenAI Whisper를 사용해 회의 녹음 파일을 텍스트로 변환했다.
Whisper는 음성을 텍스트로 변환하는 데는 적합했지만, 회의 서비스에서 중요한 “누가 말했는지”를 구분하는 것, 즉 화자 분리를 적용하는 데 한계가 있었다.

우리 서비스에서 필요한 것은 단순한 전체 회의록이 아니라, 다음과 같은 형태의 데이터였다.

# 예시
화자 0: 오늘까지 포스터 수정해볼게요.
화자 1: 저는 발표 자료 정리하겠습니다.
화자 0: 그럼 내일까지 최종본 공유할게요.

이처럼 발화자가 구분되어야 이후 LLM이 “누가 어떤 일을 맡았는지” 더 정확하게 추출할 수 있다.

따라서 STT 도구를 Whisper에서 Deepgram으로 변경했고, Deepgram의 diarization 기능을 활용해 화자 분리가 포함된 회의록을 생성하도록 개선했다.

전체 서비스 처리 흐름

[회의 녹음 파일 업로드]
        ↓
[Deepgram STT 요청]
        ↓
[화자 분리 diarization]
        ↓
[화자별 회의록 문자열 변환]
        ↓
[LLM에게 Action Item 추출 요청]
        ↓
[할 일 목록 생성]
        ↓
[KNOTE 화면에 표시]

Deepgram Service 구현

// DeepgramService.java

@Slf4j
@Service
public class DeepgramService {

  @Value("${deepgram.api.key}")
  private String apiKey;

  @Value("${deepgram.api.url}")
  private String apiUrl;

  private final RestTemplate restTemplate;

  public DeepgramService() {
    SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
    factory.setConnectTimeout(60000);
    factory.setReadTimeout(120000);
    this.restTemplate = new RestTemplate(factory);
  }

  public String transcribeWithDiarization(byte[] fileBytes) {
    HttpHeaders headers = new HttpHeaders();
    headers.setContentType(MediaType.parseMediaType("audio/wav"));
    headers.set("Authorization", "Token " + apiKey);

    String url = apiUrl
        + "?model=nova-2&smart_format=true&diarize=true&language=ko";

    HttpEntity<byte[]> requestEntity = new HttpEntity<>(fileBytes, headers);

    try {
      ResponseEntity<Map> response =
          restTemplate.postForEntity(url, requestEntity, Map.class);

      return formatDeepgramResult(response.getBody());
    } catch (Exception e) {
      log.error("Deepgram API 호출 실패", e);
      throw new RuntimeException("화자 분리 처리 중 오류 발생");
    }
  }
}

이어서 아래의 부분에서 코드 설명을 진행하겠다.

코드 설명

DeepgramService는 회의 녹음 파일을 받아 Deepgram API에 전달하고, 응답 결과를 KNOTE에서 사용하기 쉬운 문자열 형태로 변환하는 역할을 한다.

핵심 옵션은 다음과 같다.

옵션	역할
model=nova-2	음성 인식 모델 지정
smart_format=true	문장 부호, 숫자 등 텍스트 형식 개선
diarize=true	화자 분리 활성화
language=ko	한국어 회의 녹음 처리

특히 diarize=true 옵션이 가장 중요하다.
이 옵션을 통해 Deepgram은 발화 구간마다 speaker 값을 부여하고, KNOTE는 이를 이용해 “화자 0”, “화자 1” 형태의 회의록을 만들 수 있다.

서비스에 회의 녹음 파일을 업로드하면 먼저 회의 정보를 DB에 저장한다.
이후 업로드된 파일을 byte 배열로 복사한 뒤, 별도의 AI 처리 로직으로 전달한다.

파일 업로드 직후 바로 분석 결과를 기다리게 하면 사용자는 긴 시간 동안 응답을 기다려야 한다.
따라서 회의는 먼저 `PENDING` 상태로 생성하고, STT와 요약, Action Item 생성은 별도 처리 흐름에서 진행되도록 구성했다.

@PostMapping(value = "/record-file", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public ResponseEntity<CreateMeetingRecordResponse> createMeetingByFile(
    @RequestPart("file") MultipartFile file,
    @ModelAttribute @Valid CreateMeetingRecordRequest request
) {
  return ResponseEntity.status(HttpStatus.CREATED)
      .body(meetingService.createMeetingByFile(file, request));
}

실제 AI 분석은 processAiTasks() 메서드에서 진행된다.
이 메서드는 하나의 회의 ID와 녹음 파일 byte 배열을 받아 다음 순서로 동작한다.

회의 조회
↓
Deepgram STT 실행
↓
화자별 회의록 저장
↓
OpenAI 요약/분석 요청
↓
AI 응답 JSON 파싱
↓
회의 요약 저장
↓
Action Item 저장

String transcript = deepgramService.transcribeWithDiarization(fileBytes);

meeting.setTranscript(transcript);
meeting.setStatus("PROCESSING");
meetingRepository.saveAndFlush(meeting);

String aiJsonResponse = openAiService.summarize(transcript);

Deepgram을 통해 생성된 transcript는 Meeting 엔티티의 transcript 필드에 저장된다.
이후 해당 transcript를 OpenAI 요약 로직에 전달하여 회의 요약과 Action Item을 생성한다.

즉, Deepgram은 음성을 텍스트로 변환하는 역할을 하고, OpenAI는 텍스트에서 의미 있는 회의 결과를 추출하는 역할을 한다.

AI 응답에서 Action Item 추출하기

OpenAI 응답은 문자열 형태의 JSON으로 반환되기 때문에, 백엔드에서는 ObjectMapper를 사용해 JSON을 파싱한다.
그중 actionItems 배열을 순회하면서 각각의 할 일을 `ActionItem` 엔티티로 변환해 DB에 저장한다.

ObjectMapper mapper = new ObjectMapper();
JsonNode root = mapper.readTree(aiJsonResponse);

JsonNode actionItemsNode = root.path("actionItems");

if (actionItemsNode.isArray()) {
  for (JsonNode node : actionItemsNode) {
    ActionItem item = new ActionItem();

    item.setTitle(node.path("title").asText("새로운 할 일"));
    item.setMemo(node.path("memo").asText("내용 없음"));

    item.setMeeting(meeting);
    item.setCompleted(false);
    item.setActivated(true);
    item.setIsConfirmed(true);

    item.setPhase(node.path("phase").asLong(1L));
    item.setScope("TEAM");
    item.setImage("default.png");

    actionItemRepository.save(item);
  }
}

AI가 생성한 결과를 그대로 화면에 보여주는 것이 아니라, 서비스에서 관리 가능한 ActionItem 엔티티로 저장한다는 점이 중요하다.

이를 통해 사용자는 이후 화면에서 할 일 제목, 마감일, 담당자를 수정하거나 삭제할 수 있다.
즉, AI는 초안을 생성하고, 사용자는 최종적으로 이를 확인하고 수정하는 구조다.

생성된 Action Item 조회 및 수정

생성된 Action Item은 회의 상세 화면이나 할 일 관리 화면에서 조회할 수 있다.
KNOTE에서는 전체 Action Item 조회, 특정 담당자별 조회, 특정 회의별 조회 API를 제공한다.

@GetMapping("/meeting/{meetingId}")
public ResponseEntity<List<ActionItemDTO>> getByMeeting(@PathVariable Long meetingId) {
  return ResponseEntity.ok(actionItemService.getByMeetingId(meetingId));
}

@Transactional(readOnly = true)
public List<ActionItemDTO> getByMeetingId(Long meetingId) {
  List<ActionItem> actionItems = actionItemRepository.findByMeetingId(meetingId);

  return actionItems.stream()
      .map(item -> mapToDTO(item, new ActionItemDTO()))
      .collect(Collectors.toList());
}

또한 사용자가 AI가 만든 할 일을 그대로 사용하는 것이 아니라, 제목이나 마감 기한, 담당자를 직접 수정할 수 있도록 PATCH API도 구현했다.

@PatchMapping("/{id}")
public ResponseEntity<Void> patchActionItem(
    @PathVariable Long id,
    @RequestBody ActionItemPatchRequest request
) {
  actionItemService.patchActionItem(id, request);
  return ResponseEntity.ok().build();
}

참고로 액션아이템의 마감일은 AI 응답에 포함될 수 있지만, 현재 구현에서는 기본값으로 회의 생성일 기준 3일 뒤를 설정하도록 처리했다.
이는 AI가 마감일을 정확히 추출하지 못하는 경우에도 Action Item이 유효한 기본값을 갖도록 하기 위함이다.

OpenAI로 회의 요약과 Action Item 생성하기

Deepgram을 통해 화자별 회의록이 생성되면, 다음 단계에서는 OpenAI API를 사용해 회의 내용을 분석한다.

이때 단순히 “회의를 요약해줘”라고 요청하지 않고, KNOTE에서 바로 사용할 수 있는 JSON 구조로 응답하도록 프롬프트를 설계했다.

public String summarize(String transcript) {
  String url = baseUrl + "/chat/completions";

  String systemPrompt =
      "너는 전문 회의 기록가이자 프로젝트 매니저야. 제공된 회의 스크립트를 분석해서 'Action Items(할 일)'를 추출해.\n\n" +
      "1. 오직 회의 스크립트에서 언급된 할 일만 추출해.\n" +
      "2. 마감 기한이 있다면 dueDate에 작성해.\n" +
      "3. 해당 할 일을 언급한 화자를 suggestedSpeaker에 작성해.\n" +
      "4. 반드시 JSON 형식으로만 응답해.";

  Map<String, Object> body = new HashMap<>();
  body.put("model", "gpt-4o-mini");
  body.put("messages", List.of(
      Map.of("role", "system", "content", systemPrompt),
      Map.of("role", "user", "content", transcript)
  ));

  body.put("response_format", Map.of("type", "json_object"));
}

AI 응답 예시

{
  "title": "포스터 제작 회의",
  "summarySegments": [
    "포스터의 색상과 레이아웃 수정 방향을 논의했다.",
    "발표 자료와 최종본 공유 일정을 정했다."
  ],
  "actionItems": [
    {
      "title": "포스터 색상과 레이아웃 수정",
      "memo": "KNOTE 로고 색감에 맞춰 포스터 디자인을 정리한다.",
      "suggestedSpeaker": "화자 1",
      "dueDate": "2026-05-26T18:00:00",
      "phase": 2
    },
    {
      "title": "수정본 공유",
      "memo": "수정된 포스터 최종본을 팀원들에게 공유한다.",
      "suggestedSpeaker": "화자 0",
      "dueDate": "2026-05-27T18:00:00",
      "phase": 5
    }
  ]
}

실행 방법

실행을 위해서는 Deepgram API Key와 OpenAI API Key가 필요하다.

`application.yml`에는 다음과 같이 외부 API 설정을 추가한다.

deepgram:
  api:
    key: ${DEEPGRAM_API_KEY}
    url: https://api.deepgram.com/v1/listen

openai:
  api:
    key: ${OPENAI_API_KEY}
    url: https://api.openai.com/v1

이후 회의 녹음 파일을 업로드하는 API를 호출한다.

마무리

관련 기술에 대해 고민한 점을 얘기해보면서 마무리를 지어보고싶다.

첫 번째로 고려한 점은 화자 분리였다.
회의 서비스에서는 단순히 내용을 텍스트로 바꾸는 것보다, 누가 어떤 말을 했는지 보존하는 것이 중요하다.
이 때문에 Whisper 대신 Deepgram을 사용했고, `diarize=true` 옵션을 적용했다.

두 번째로 고려한 점은 응답 형식이다.
LLM 응답이 자유로운 문장 형태로 오면 백엔드에서 안정적으로 파싱하기 어렵다.
따라서 JSON 형식을 강제하고, `title`, `summarySegments`, `actionItems`처럼 필요한 필드를 명확히 지정했다.

세 번째로 고려한 점은 사용자 수정 가능성이다.
AI가 생성한 Action Item이 항상 완벽하지는 않기 때문에, 사용자가 제목, 마감일, 담당자를 수정할 수 있도록 PATCH API를 함께 제공했다.

이번 구현을 통해 KNOTE는 회의 녹음 파일을 단순히 텍스트로 변환하는 데서 끝나지 않고, 실제 사용자가 관리할 수 있는 Action Item으로 연결할 수 있게 되었다.

Deepgram은 화자 분리를 통해 회의 맥락을 보존하고, OpenAI는 해당 회의록에서 요약과 할 일을 추출한다.
그리고 백엔드는 AI 결과를 ActionItem 엔티티로 저장해 회의 상세 화면과 할 일 관리 화면에서 사용할 수 있도록 연결한다.

즉, KNOTE의 핵심 기능은 다음 흐름으로 정리할 수 있다.

“회의 녹음 → 화자별 회의록 → AI 요약 → Action Item 생성 → 사용자 확인 및 수정”

이 구조를 통해 회의가 끝난 뒤 사용자가 직접 회의록을 다시 읽고 할 일을 정리해야 하는 부담을 줄일 수 있었다.

참고용으로 우리 AllIsWell 팀의 깃허브 주소 또한 첨부한다.

~~(아직 개발이 진행 중이라는 점은 비밀)~~

https://github.com/ALLISWELL-Lab

STT 사용 파이프라인과 현존하는 STT 서비스들 비교

yoozafree — Thu, 27 Nov 2025 21:35:12 +0900

작성일: 2025.11.27

첫 포스팅으로 졸업 프로젝트에 관한 글을 올리게 되었다.

먼저 우리 팀의 주제는

대학생 개발자 팀의 효율적인 협업을 위한 회의록 기반의 지능형 진척 관리 및 피드백 시스템

이다.

팀 프로젝트 협업 환경에서 가장 반복되는 작업 중 하나는 회의록 작성이다.
하지만 회의 내용을 모두 사람이 기록하고 정리하는 것은 시간이 오래 걸리고, 중요한 논의가 누락되거나 주관적 해석이 개입된다는 문제가 있다. 특히, 개발 프로젝트에 있어 대학생들은 익숙지 않고, 어려움을 겪기에 그에 대한 고민을 해결해줄 수 있는 방안이 뭐가 있을까 고민하다가 나온 주제다. 이를 위해 우리 사이트에서 회의록을 녹음 후 이를 자동 텍스트화 및 요약을 진행하고, 이를 액션 아이템, 즉 To-Do 화를 시키는 것이 프로젝트 주요 기능을 위한 제일 우선이 되어야 하는 흐름에 대한 부분이다.

이번 글에서는 우리가 졸업 프로젝트에서 직접 구현 중인 회의록 자동 생성 및 요약과 관련된 기술 파이프라인과 해당 기술을 위해 활용될 여러 STT 서비스들에 대해 말해보고자 한다.

회의록 자동 생성 및 요약 기술 파이프라인

1. 서비스 내 녹음 기능(Recording)

우리 서비스는 사용자가 별도 녹음 파일을 업로드할 필요가 없다.
회의 화면에서 바로 녹음 버튼을 누르면 음성이 수집되며, 회의가 끝나면 자동으로 서버에 저장된다.

React.js 기반 프론트엔드에서 MediaRecorder를 활용해 녹음
녹음된 Blob 데이터를 Spring Boot 백엔드로 전송
백엔드는 파일을 임시 저장한 후 STT 처리 단계로 넘김

이 구조는 우리가 정의했던 문제 중 “회의 기록이 여러 툴로 흩어지는 문제”를 해결하는 첫 단계다.
녹음–전환–정리까지 모든 과정이 하나의 서비스에서 처리된다.

2. STT(Speech-to-Text) 변환 단계

(현재 STT 엔진은 비교 후 선정 예정)

녹음된 음성은 STT 엔진을 통해 텍스트로 변환된다.
우리는 현재 NHN, CLOVA 같은 국내 엔진부터 Google Cloud, Daglo까지
성능·가격·한국어 최적화 등 여러 기준으로 테스트 중이며,
최종적으로 하나의 엔진을 서비스에 탑재할 예정이다.

Spring Boot 백엔드에서는 다음 흐름으로 진행된다.

전송된 음성을 일시 저장
STT API에 요청
회의 원문 텍스트 수신
텍스트를 DB(MySQL)에 저장

STT 품질은 이후 단계(요약·To-do 생성·진척 분석)에 크게 영향을 주기 때문에
정확한 한국어 인식이 가능한 엔진을 선정하는 것을 목표로 한다.

3. 텍스트 전처리(Text Preprocessing)

STT 결과는 바로 LLM에 넣기 어렵기 때문에
Spring Boot에서 텍스트 전처리 로직을 수행한다.

전처리 주요 기능은 다음과 같다.

구두점 복원 및 띄어쓰기 보정
불필요한 발화 제거(“음…”, “아…” 등)
문장 단위 재구성
LLM 입력 길이(Limit)를 고려한 Chunk 분할
필요 시 화자 정보 구조화

이 단계는 전처리가 잘 될수록 요약 및 To-do 생성의 품질이 비약적으로 향상된다.

4. 회의 요약(Summarization)

전처리된 텍스트는 OpenAI API를 이용해 자동 요약된다.

우리 시스템은 다음 세 가지 형태의 요약을 생성한다.

전체 회의 요약
핵심 논의 정리(Key Points)
결정된 사항(Decisions Made)

이 구조는 페르소나가 원했던
“회의 내용을 한눈에 파악할 수 있는 기능”을 충족한다.
팀원들은 더 이상 긴 회의록 처음부터 끝까지 읽을 필요 없이, 혹은 회의들을 기억해내지 않아도
요약된 정보만 보고도 팀 상황을 쉽게 파악할 수 있다.

프롬프트 설계에는 역할 기반 프롬프트 + 조건 기반 구조화 요청이 사용되며,
이는 요약 품질의 안정성과 일관성을 유지하는 데 효과적이다.

5. Action Item(To-do) 자동 생성

요약 결과를 바탕으로
회의에서 나온 할 일(Action Item)을 자동으로 추출한다.

OpenAI API를 사용해 다음 항목을 발굴한다.

해야 할 업무(Task title)
담당자(owner)
데드라인(due_date)
우선순위(priority)
관련 논의 출처

이 정보는 JSON 형태로 구조화되어 저장되며, React.js UI에서 직관적인 To-do 리스트 형태로 확인할 수 있다.

이 기능은 우리가 정의했던 Pain Point 중
“회의 피드백이 문서에만 머물고 실행으로 이어지지 않는다” 는 문제를 해결하기 위한 핵심 기능이다.

또한 팀장 혹은 일부 팀원이 직접 정리하고 분배하던 업무를 시스템이 자동으로 제안해줘 관리 부담을 줄여준다.

6. 피드백 & 진척 관리 연계

To-do가 생성되면 Spring Boot 백엔드에서는 다음의 추가 로직을 수행하여 진척도를 계산하고 피드백을 생성한다.

To-do 완료 여부 체크 (진척도 반영)
완료 속도 / 난이도 분석
일정 동기화 (Google Calendar API 이용)
성실도 기반 간단 피드백 생성(OpenAI API 연계)

“직관적인 진행 상황 확인”을 가능하게 한다.

또한 일정은 Google Calendar API와 동기화되면서 팀/개인 일정 관리의 단절 문제도 해결된다.

전체 파이프라인 요약

서비스 내 녹음 → React.js + 번들 저장
STT 변환 → Spring Boot에서 API 요청 (엔진 미선정 상태)
텍스트 전처리 → 구두점·띄어쓰기·불필요 발화 제거
회의 요약 → OpenAI API 기반 자동 Summarization
Action Item 생성 → 구조화된 To-do 자동 추출
진척 분석 & 일정 연계 → Google Calendar API + 진행률 분석

이 모든 데이터는 MySQL에 저장되며, React UI에서 가볍고 직관적인 형태로 확인할 수 있다.
Docker 및 vercel을 활용해 전체 서비스는 컨테이너 기반으로 배포될 예정이다.

다음으로는 현존하는 STT 서비스들의 특징 비교를 통해 우리팀이 최종적으로 사용할 수 있을 후보들을 리스트업 해보겠다.

STT 비교 분석

1) NHN Cloud Speech-to-Text

NHN Cloud는 한국어 최적화된 STT 엔진을 제공하는 대표적인 국내 클라우드 서비스다. 음성 파일 업로드 방식과 실시간 스트리밍 방식 모두 지원하며, 짧은 음성(싱크 방식)과 긴 음성(비동기 방식)을 구분해서 처리한다.
가격은 600초(10분)까지 무료, 이후에는 15초당 약 4원으로 비교적 저렴한 편이다.

성능은 자연스러운 대화·발화 위주의 음성에서 안정된 수준이며, 발음이 조금 빠르거나 잡음이 섞인 환경에서는 오류율이 다소 증가할 수 있다. 그래도 “한국어 특화 + 매우 저렴한 요금제”라는 장점 덕분에, 국내 사용자 중심의 서비스라면 도입 비용 부담이 거의 없다.

2) Naver CLOVA Speech

Naver CLOVA Speech는 국내에서 가장 널리 사용되는 상업용 한국어 STT 중 하나다. 네이버 검색 및 지도 사업에서 활용되는 음성 처리 기술을 기반으로 하고 있어, 한국어 정확도는 국내 서비스 중 최상위권으로 평가된다.

가격은 모델 종류에 따라 달라지지만 보통 15초 단위 과금으로 제공되며, NHN과 비슷하거나 조금 높은 수준이다. 화자 분리, 오디오/영상 자동 처리, 긴 음성 처리 기능이 모두 지원되어 범용성이 높다.

실제 벤치마크에서도 한국어 CER(문자 오류율)이 매우 낮은 편으로, 회의록 생성, 유튜브 자막, 서비스형 음성봇 등에서 많이 활용된다. 다만 가격이 아주 저렴한 편은 아니라서 대규모 음성을 장기간 처리해야 한다면 비용 부담이 생길 수 있다.

3) Google Cloud Speech-to-Text

Google Cloud Speech-to-Text는 전 세계적으로 가장 많이 사용되는 STT 서비스 중 하나로, 가장 다양한 언어와 포맷을 지원한다. 자동 구두점, 단어 레벨 타임스탬프, 화자 분리, 실시간 스트리밍 지원 등 기능적 완성도가 매우 높다.

가격은 분당 약 $0.016(표준 모델 기준)으로 중간 수준이지만, 대규모로 사용하면 할인되는 구조다.
한국어 인식률은 우수하지만, 한국어에 완전히 특화된 모델은 아니기 때문에 NHN, CLOVA처럼 한국어 환경에서 최상위 성능을 보이진 않는다.

그럼에도 불구하고, “한국어 + 영어 + 일본어 + 중국어 등 다양한 언어가 혼재된 환경”, “글로벌 인프라 기반 서비스”를 구축해야 한다면 가장 안정적인 선택지다.

4) Amazon Transcribe

Amazon Transcribe는 AWS 생태계와 자연스럽게 연동되는 STT 서비스로, 긴 음성 처리 및 기업용 기능(Compliance 기능, Medical 모델 등)이 잘 갖추어져 있다. 가격은 사용량 기반 과금으로, Google Cloud와 유사한 레벨이다.

한국어 성능은 글로벌 서비스 중에서는 준수한 편이며, 특히 긴 회의 음성에서 안정적인 결과를 낸다는 평가를 받는다. 다만 한국어 특화 모델이 있는 것은 아니기 때문에, 전문용어가 많거나 발음이 빠른 음성에서는 정확도가 낮아질 수 있다.

AWS 기반 인프라를 이미 사용하고 있다면 통합 관리 측면에서 장점이 크다.

5) Daglo STT

Daglo(다글로)는 최근 한국 개발자들 사이에서 주목받는 한국어 특화 STT 서비스다. 글로벌 STT 대비 한국어 발음 처리, 억양, 자모 변환 등에 최적화되어 있으며, 실사용 후기가 좋은 편이다.

가격은 초기 1시간 무료, 이후 시간당 과금 구조로 제공된다. 구체적인 비용이 NHN/CLOVA보다 높은 경우도 있지만, 한국어 정확도가 중요한 프로젝트에서는 좋은 선택지가 된다.

특히 Daglo는 짧은 문장·대화체·일상 발화에서 안정적이며, 빠른 처리 속도와 한국어 모델의 최적화가 장점이다. 아직 Google/AWS만큼의 대규모 기능(화자 분리, 대형 파일 처리 등)은 부족한 면이 있지만, 한국어 정확도 + 간결한 요금 구조 때문에 회의록 자동화, 인터뷰 전사, 학습용 데이터셋 제작 등에서 많이 사용된다.

정리해보자면

가격이 가장 중요한 국내 프로젝트
→ NHN Cloud (가장 저렴 + 한국어 무난)
한국어 인식률 최우선 + 안정적인 STT 엔진
→ Naver CLOVA Speech
글로벌 환경 + 여러 언어 + 대규모 서비스 구축
→ Google Cloud Speech-to-Text
AWS 기반 인프라 사용 / 긴 음성 처리 중요
→ Amazon Transcribe
한국어 발화 정확도 + 빠른 처리 속도 + 개발 편의성
→ Daglo

팀원들과 더 얘기를 해서 최종 확정을 지어야겠지만 총 정리를 해보자면,

한국어 대화를 주로 하되, 영어로 된 용어로 소통이 잦은 "개발" 도메인이라는 점을 상기시켜 해당 특징을 잘 고려해 정해봐야 할 것 같다.