받아쓰기 그 너머: 말만으로 소프트웨어 만들기

발행: 3시간 전 (2026년 2월 24일 오전 10:40 GMT+9)

19 분 소요

Source: Dev.to

TL;DR: Kiro Steering Studio는 받아쓰기 가 아니라 자연스러운 대화를 통해 구조화된 Kiro steering 파일을 생성하는 음성 기반 도구입니다 — 음성만으로 파일을 만들 수 있게 해줍니다. Amazon Nova 2 Sonic의 양방향 스트리밍을 기반으로 하여, 사용자가 말한 내용을 올바른 파일에 라우팅하고, 열린 질문을 추적하며, 작업 공간을 위한 AI‑최적화 마크다운 컨텍스트를 제공합니다. 이 글에서는 어떻게 구축했는지, 기존에 사용하고 있는 음성‑AI 도구와 어떻게 다른지, 그리고 진행 과정에서 배운 점을 다룹니다.

음성은 개발자 도구에서 1급 인터페이스가 되고 있다

음성‑텍스트 분야는 2026년에 급격히 성장했으며, 여러 제품이 타이핑을 없애는 데 경쟁하고 있다. 일부는 텍스트 입력을 더 빠르게 하는 방법으로, 다른 일부는 구조화된, 에이전시 워크플로를 구동하는 데 사용한다.

2026년 1분기 개발자를 위한 Voice AI 현황

OpenAI – Codex
음성은 지원되는 기능이지만, 범위는 의도적으로 좁다.
공식 Codex macOS 앱(2026년 2월 출시)에는 개발자가 프롬프트를 에이전트 인터페이스에 직접 말할 수 있는 음성 명령이 포함되어 있다. VS Code 확장 역시 명령 입력을 위한 음성‑텍스트 받아쓰기를 지원한다. 두 경우 모두 음성은 프롬프트 전달 메커니즘이다: 작업을 말하면 Codex가 격리된 샌드박스에서 실행하고 PR을 제안한다. 음성 인터페이스는 상호작용 모델을 바꾸지는 않으며, 단지 키보드를 루프에서 제거한다.
Anthropic – Claude
Anthropic은 일반 Claude 앱(모바일 및 웹)용 공식 Voice Mode를 도입했다. Claude Code에 대한 음성 기능은 주로 커뮤니티가 만든 서드‑파티 통합에 기반한다.
Cursor
Cursor 2.0은 공식 음성 지원을 추가했다. Voice Mode를 통해 “app.ts 파일 열기”, “함수 추출”, “async/await 사용으로 리팩터링” 등과 같은 구두 명령으로 편집기와 AI 기능을 제어할 수 있다. AI가 그에 대한 패치를 초안으로 만든다. 이는 순수 받아쓰기 이상의 의미 있는 단계이며, 구두 명령이 다단계 편집을 트리거할 수 있다.
SuperWhisper & WisprFlow
이들은 스펙트럼의 반대쪽에 위치한 일반 목적의 받아쓰기 도구로, 개발자들이 프롬프트 작성부터 문서 초안까지 모든 작업에 채택한다. WisprFlow는 자동 편집을 통한 매끄러운 “플로우”로 자연스러운 받아쓰기를 제공한다. 두 도구 모두 키보드 단축키로 통합되며 전사에 뛰어나다.

이 모든 도구는 동일한 통찰을 검증한다: 음성은 타이핑보다 빠르고 자연스럽다. 그러나 이들은 모두 입력 메커니즘에 불과하다.

이 도구들을 사용해 소프트웨어를 구축할 때도 여전히 다음과 같은 인지 작업을 수행한다:

정보를 올바른 형식으로 구조화하기
용어와 컨벤션의 일관성 유지하기
내용을 논리적인 섹션으로 조직하기

말하는 속도가 타이핑보다 빠를 수는 있지만, 여전히 마크다운 파일을 수동으로 작성하고 있다.

Source: https://kiro.dev/docs/steering/

Kiro 스티어링 파일이 실제로 하는 일

Kiro Steering Studio가 어떻게 작동하는지 설명하기 전에, 스티어링 파일이 무엇이며 왜 중요한지 이해하는 것이 좋습니다. 근본적으로 스티어링은 마크다운 파일을 통해 Kiro에게 작업 공간에 대한 지속적인 지식을 제공합니다. 매 채팅마다 규칙을 설명하는 대신, 스티어링 파일은 Kiro가 여러분이 정해 둔 패턴, 라이브러리, 표준을 일관되게 따르도록 보장합니다.

Kiro 스티어링 파일

프로젝트 컨텍스트를 포착하는 세 가지 핵심 파일

파일	목적
`product.md`	무엇을 만들고 있는지 정의합니다: 한 줄 요약, 대상 사용자, MVP 여정 및 기능, 비목표, 성공 지표, 도메인 용어집.
`tech.md`	어떻게 구축할지를 정의합니다: 프론트엔드 스택, 백엔드 접근 방식, 인증, 데이터 저장, IaC, 관측성, 스타일 가이드.
`structure.md`	프로젝트 조직을 정의합니다: 레포지토리 레이아웃, 명명 규칙, import 패턴, 아키텍처 패턴, 테스트 접근 방식.

이 파일들을 손수 작성하는 것은 번거롭습니다. Kiro는 이미 잘 정립된 코드베이스가 있는 경우 자동으로 파일을 생성해 주는 “원클릭” 기능을 제공하지만, 새 애플리케이션을 처음부터 구축할 때는 해당되지 않습니다.

Steering Studio는 어떻게 다른가

Kiro Steering Studio는 음성을 단순 전사가 아니라 구조화된 지식 생성 인터페이스로 취급합니다. 스티어링 파일을 직접 작성하는 대신 프로젝트에 대해 이야기하면 됩니다. AI는 명확히 하는 질문을 하고, 놓쳤을 수 있는 세부 사항을 탐색하며, 실시간으로 적절히 구조화된 스티어링 파일을 생성합니다. 대화가 곧 문서가 됩니다.

대화형 추출

미리 구조화된 내용을 받아쓰기 하는 것이 아니라 자연스러운 대화를 나눕니다. 예시:

“내부 엔지니어링 팀을 위한 작업 관리 앱을 React와 TypeScript, Node.js를 사용해 만들고 있어요.”

AI는 그대로 받아쓰기만 하는 것이 아니라, 여러분이 생각하지 못했을 수도 있는 명확한 질문을 합니다:

“상태 관리 방식은 무엇인가요 — Redux, React Query, 아니면 Context API 중 어느 것을 사용하시나요?”
“인증은 어떻게 처리하시나요?”
“테스트는 어떤 접근 방식을 사용하시나요?”
“인증에 OAuth를 사용할지, 매직 링크를 사용할지 결정하셨나요?”

각 답변은 대화가 진행될수록 완전성을 검증하며 해당 스티어링 파일을 업데이트합니다.

지능형 라우팅

AI는 정보가 어디에 들어가야 하는지 이해합니다:

“React with TypeScript”라고 언급하면 자동으로 tech.md의 frontend 섹션이 업데이트됩니다.
사용자 여정을 설명하면 product.md가 채워집니다.
디렉터리 구조를 설명하면 structure.md가 업데이트됩니다.

능동적 결함 감지

AI는 누락된 부분을 추적합니다. 프론트엔드 스택이나 네이밍 규칙을 아직 지정하지 않았다면, 열려 있는 질문을 기록하고 해결을 촉구합니다. 여러분이 answ … (원본 내용은 여기서 끝납니다; 문장을 의도적으로 미완성 상태로 남겨 원본 자료를 보존했습니다).

Source:

How It’s Built

아키텍처는 네 가지 관점으로 나뉩니다: 스트리밍, 세션 관리, 스티어링 상태, 그리고 툴 처리.

NovaSonicClient: 양방향 오디오 스트리밍

우리 앱의 중심은 Amazon Bedrock과 실시간 양방향 스트리밍을 구현하는 것입니다. 특히 Nova 2 Sonic—아마존의 음성‑합성 기반 모델을 사용합니다.

요청‑응답 흐름처럼 음성을 녹음하고, 하나의 요청으로 전송하고, 응답을 기다린 뒤에 툴 호출을 일괄 처리하는 방식과 달리, Nova 2 Sonic은 말하는 동안 오디오를 처리하고 대화 중에 툴 실행을 끼워 넣습니다.

전통적인 음성‑AI 흐름

모든 음성 녹음
전체 오디오 전송
응답 대기
툴 호출 실행
결과 전송
최종 응답 대기

양방향 스트리밍 흐름

오디오가 지속적으로 스트리밍 – 음성이 끝날 때까지 기다릴 필요 없음
모델이 당신이 아직 말하고 있을 때도 응답
툴 호출이 대화 중간에 발생, 이후가 아님
결과가 즉시 반환; 모델은 계속해서 말함

오디오 버퍼는 최대 220개의 청크까지 큐에 쌓이며, 스트림 과부하를 방지하기 위해 청크 5개씩 배치로 처리합니다. 압력이 높아 큐가 가득 차면 오래된 청크를 버려 실시간 응답성을 유지합니다.

클라이언트는 세션 수명 주기—시작, 오디오 콘텐츠, 프롬프트, 툴 결과, 그리고 정상 종료—를 상태 머신을 통해 관리하며 어떤 이벤트가 전송됐는지 추적합니다.

툴 시스템: 동기식 실행, 음성과 교차

툴 호출은 사용자가 말을 마칠 때까지 기다리지 않습니다. 모델이 프로젝트를 설명하던 중에 스티어링을 업데이트해야 함을 깨닫고 toolUse 이벤트를 발생시킨 뒤, 결과를 받아 다시 말하기를 이어갑니다. 이는 toolResult 이벤트 핸들러를 통해 이루어집니다:

session.onEvent('toolEnd', async (d: unknown) => {
  const toolData = d as ToolEndData;
  const result = runTool(store, toolData.toolName, toolData.toolUseContent); // Synchronous
  await sonic.sendToolResult(socket.id, toolData.toolUseId, result);          // Send back to model
});

사용 가능한 툴

Tool	Purpose
`set_product_steering`	앱 설명, 사용자 여정, MVP 기능, 성공 지표
`set_tech_steering`	프론트엔드/백엔드 스택, 인증, 데이터, 인프라, 제약 조건
`set_structure_steering`	레포 레이아웃, 네이밍 규칙, 아키텍처 패턴
`add_open_question`	해결이 필요한 결정 사항 기록
`resolve_open_question`	문서화된 결정으로 질문 종료
`get_steering_summary`	누락된 항목 확인
`checkpoint_steering_files`	디스크에 영구 저장

각 툴 설명은 AI가 LLM‑친화적인 불릿, 정확한 버전, 안티‑패턴, 파일 목적 등에 최적화된 콘텐츠를 생성하도록 유도합니다. 이 설명이 바로 비밀 소스입니다:

const techDescription = `Write in terse bullet-point format. For each field include:
- Exact versions (e.g., "Next.js 14.2" not "Next.js")
- Key conventions to follow
- What NOT to do (anti-patterns)
- Relevant CLI commands where applicable`;

SteeringStore: In‑Memory State with Atomic Writes

스토어는 스티어링 상태를 메모리에 유지하고 디스크에 원자적으로 기록합니다. merge mode (merge vs. replace)는 업데이트가 기존 콘텐츠를 확장할지 덮어쓸지를 제어합니다. 세션 상태는 복구를 위해 JSON 파일에 지속됩니다:

{
  "version": 1,
  "updatedAt": "2025-01-26T18:30:00.000Z",
  "product": {
    "appOneLiner": "A task management app for remote teams",
    "targetUsers": "Distributed engineering teams"
  },
  "tech": {
    "frontend": "React with TypeScript",
    "backend": "Node.js with Express"
  }
}

서버를 재시작하면 대화가 중단된 지점부터 이어집니다.

Source:

디자인 결정

제가 이 프로젝트를 만들면서 배운 몇 가지 사항:

대화 상태 관리가 생각보다 어렵다

첫 번째 큰 과제는 대화 상태를 유지하는 것이었습니다—다루어진 주제, 남은 과제, 그리고 나중에 다시 물어볼 질문들을 추적하는 것이죠. 해결책은 상태 파일 관리 시스템에 Zod‑검증 도구 호출을 결합한 것이었습니다. 이를 통해 AI는 대화 중에 스티어링 파일을 원자적으로 업데이트하면서 state.json 파일에 세션 컨텍스트를 지속시켜 중단 후에도 복구할 수 있습니다. 스키마는 구조를 검증하고, 상태 파일은 연속성을 포착합니다.

인간은 (길게) 생각한 뒤 답한다

인간의 의사결정은 종종 아키텍처와 기술 스택 선택에 대해 고민하는 일시적인 멈춤을 포함합니다. 이러한 멈춤은 스트리밍 세션을 타임아웃시킬 수 있습니다. 우리는 keep‑alive 타이머를 세션 매니저에 도입하여, 장시간 생각하는 동안에도 Bedrock 연결을 유지하기 위해 주기적으로 신호를 보내고, 활성 대화를 조기에 종료하지 않도록 했습니다.

도구 설명이 스키마보다 중요하다

초기 버전에서는 상세한 JSON 스키마만 제공하고 도구 설명은 최소화했습니다. AI는 도구를 올바르게 호출했지만, 생성된 내용은 일반적이었습니다. 해결책은 도구 설명을 프롬프트로 취급하는 것이었습니다: 구체적인 포맷 가이드, 좋은 출력 예시, 명시적인 안티패턴을 제공했습니다. 스키마는 여전히 구조를 검증하지만, 설명이 품질을 좌우합니다. 요컨대, 좋은 프롬프트 엔지니어링이 모든 차이를 만든다고 할 수 있습니다!

도구 실행은 빨라야 한다

우리 도구는 동기식으로 실행되고 음성 출력과 교차되기 때문에, 느린 도구는 들리는 지연을 초래합니다. 일곱 개의 스티어링 도구는 모두 서브밀리초 실행을 목표로 설계되었습니다: 메모리 내 상태 업데이트만 수행하고 차단 I/O가 없습니다. 파일 영속성은 checkpoint_steering_files()를 통해 이루어지며, 모델은 자연스러운 대화 중단 시점에 이를 호출합니다. 커스텀 도구를 추가한다면 빠르게 동작하도록 하거나, 즉시 응답을 반환하는 비동기 방식으로 구현하세요.

음성 기반 서비스를 구축하고 있다면, 아래에 댓글을 남겨 주세요!

Kiro Steering Studio를 직접 사용해 보고 싶으신가요? 코드는 우리의 GitHub 저장소에서 확인할 수 있습니다:

https://github.com/aws-samples/sample-kiro-steering-studio?sc_channel=sm&sc_publisher=YOUTUBE&sc_country=global&sc_geo=GLOBAL&sc_outcome=awareness&trkCampaign=78b97721-98e7-4499-a2db-d7f66c04e460&sc_content=2026_developer_campaigns_kiro_NAMER&sc_category=Amazon%20Nova&trk=78b97721-98e7-4499-a2db-d7f66c04e460&linkId=909040901