SubHub
오프라인 우선 설계 + OCR 자동 입력 기반 구독 관리 앱 (Google Play 출시)
97%
토큰 절감률
9→4개
입력 필드 축소
90%+
인식 정확도
100%
오프라인 동작
AI 개발 도구 활용 방식 — 워크플로우 문서
Kiro IDE를 활용한 개발 워크플로우와 AI 생성 코드 검증 과정
Problem
→ AI 코딩 도구 도입으로 보일러플레이트 작성 시간을 단축하되, 핵심 로직은 직접 검증하는 워크플로우가 필요했습니다.
AI 코딩 도구를 쓰기 전에는 OCR 파이프라인, UI 컴포넌트, 상태 관리 로직을 모두 처음부터 직접 작성했습니다. 반복적인 보일러플레이트 코드에 시간이 많이 소요되었고, 초기 구현 속도를 높이기 위해 AI 코딩 도구 도입을 검토했습니다. Cursor, GitHub Copilot, Claude Code 등을 비교한 결과, Kiro IDE의 Specs 기능(요구사항 → 설계 → 구현 태스크를 구조화하여 AI와 협업)이 프로젝트 초기 구현에 가장 적합하다고 판단했습니다.
- ▸보일러플레이트 코드(API 호출, 폼 컴포넌트, 상태 관리) 작성에 시간 과다 소요
- ▸OCR 파이프라인 초기 구현 시 프롬프트 설계 → API 호출 → JSON 파싱 → 폼 채움 전체 흐름을 처음부터 작성해야 함
- ▸AI 생성 코드의 품질을 검증하지 않으면 오프라인 미처리, 불필요한 API 호출 등 버그가 잔존
- ▸도메인 맥락(구독 관리 앱의 비즈니스 로직)을 AI가 이해하지 못해 설계 결정은 직접 해야 함
Trade-off
→ Kiro의 Specs 기능이 요구사항 → 설계 → 구현을 구조화하여 AI 협업에 가장 적합했습니다.
장점
- 인라인 자동완성으로 코딩 속도 향상
- VS Code 통합이 자연스러움
- 광범위한 언어·프레임워크 지원
단점
- 파일 단위 컨텍스트 — 프로젝트 전체 구조를 이해하지 못함
- 요구사항 → 설계 → 구현의 구조화된 워크플로우 부재
- 생성 코드의 일관성이 프로젝트 컨벤션과 맞지 않는 경우 빈번
장점
- 프로젝트 전체 컨텍스트를 참조하는 AI 채팅
- 코드베이스 검색 + AI 응답 결합
- 멀티 파일 편집 지원
단점
- 구조화된 Spec 기반 워크플로우 부재
- AI가 생성한 코드의 변경 범위가 넓어 리뷰 부담 증가
- 프로젝트 초기 구현보다 기존 코드 수정에 더 적합
장점
- Specs 기능: 요구사항 → 설계 → 구현 태스크를 구조화하여 AI와 단계별 협업
- 태스크 단위로 AI가 코드를 생성하여 변경 범위가 명확하고 리뷰 용이
- Steering 파일로 프로젝트 컨벤션을 AI에게 지속 전달
- 유지보수 시 오류 재현 → 원인 분석 → 수정 → 검증 에이전틱 워크플로우 지원
단점
- Specs 작성에 초기 시간 투자 필요
- AI 생성 코드의 핵심 로직은 여전히 직접 검증 필수
의사결정
Kiro IDE의 Specs 기능이 OCR 파이프라인처럼 여러 단계로 구성된 기능을 요구사항 → 설계 → 구현 태스크로 분해하여 AI와 협업하기에 가장 적합했습니다. GitHub Copilot은 인라인 자동완성에 강하지만 프로젝트 전체 구조를 이해하지 못하고, Cursor는 기존 코드 수정에 더 적합하여 초기 구현 단계에서는 Kiro를 선택했습니다.
Architecture
→ Kiro Specs로 OCR 파이프라인 초기 구현을 생성하고, 핵심 비즈니스 로직은 라인 단위로 검증했습니다.
Kiro Specs에 OCR 파이프라인의 요구사항(영수증 촬영 → API 호출 → JSON 파싱 → 폼 자동 채움)을 정의하고, AI가 태스크별로 코드를 생성했습니다. UI 컴포넌트 보일러플레이트(구독 등록 폼, 목록 카드, 설정 화면)도 AI로 초안을 생성한 뒤 디자인을 조정했습니다. 핵심 비즈니스 로직(OCR 결과 파싱, 오프라인 상태 처리, AsyncStorage 저장)은 AI 생성 코드를 라인 단위로 검토하여 버그를 사전에 발견했습니다.
구현 흐름
- 1Kiro Specs 작성: OCR 파이프라인 요구사항(촬영 → API 호출 → 파싱 → 폼 채움) 정의
- 2AI가 태스크별 코드 생성: 카메라 모듈, API 호출 함수, JSON 파서, 폼 자동 채움 로직
- 3UI 보일러플레이트 생성: 구독 등록 폼, 목록 카드, 설정 화면 초안을 AI로 생성 후 디자인 조정
- 4핵심 로직 라인 단위 검증: OCR 결과 파싱 로직에서 오프라인 상태 미처리 버그 발견 → 네트워크 상태 체크 로직 추가
- 5불필요한 API 호출 발견: AI가 매 렌더링마다 환율 API를 호출하는 코드 생성 → 캐싱 로직으로 수정
- 6유지보수 시 Kiro 에이전틱 워크플로우 활용: 오류 재현 → 원인 분석 → 수정 → 검증 자동화
Verification
→ AI 생성 코드에서 오프라인 미처리, 불필요한 API 호출 등 2건의 버그를 사전에 발견·수정했습니다.
AI가 생성한 코드를 핵심 비즈니스 로직 중심으로 라인 단위 검토하여, 프로덕션 배포 전에 버그를 사전에 발견했습니다. AI는 보일러플레이트 생성에서 개발 속도를 크게 향상시켰지만, 도메인 맥락이 필요한 설계 결정과 엣지 케이스 처리는 직접 판단해야 했습니다.
2건
AI 생성 코드 버그 발견
오프라인 상태 미처리 1건 + 불필요한 API 호출 1건
체감 2~3배 향상
보일러플레이트 생성 속도
UI 컴포넌트, API 호출 함수, 폼 로직 초안 생성 시간 단축
OCR 파이프라인 전체
Specs 기반 태스크 완료
촬영 → API 호출 → 파싱 → 폼 채움 4단계를 Specs로 구조화하여 구현
- 버그 1 — 오프라인 미처리: AI가 생성한 OCR 호출 코드에 네트워크 상태 체크가 없어, 오프라인에서 API 호출 시 앱이 무한 로딩 → 네트워크 상태 확인 후 오프라인이면 수동 입력 폴백 안내로 수정
- 버그 2 — 불필요한 API 호출: AI가 환율 조회를 컴포넌트 렌더링마다 호출하는 코드 생성 → 24시간 캐싱 로직을 추가하여 불필요한 API 호출 제거
- AI가 잘한 부분: 보일러플레이트(폼 컴포넌트, API 호출 래퍼, 타입 정의) 생성에서 반복 작업 시간 대폭 단축
- AI가 못한 부분: '오프라인에서 OCR 실패 시 어떻게 할 것인가'라는 도메인 맥락 기반 설계 결정은 직접 판단 필요
Retrospective
→ AI 생성 코드를 그대로 신뢰하면 안 되며, 핵심 로직은 반드시 직접 검증해야 합니다.
한계점
AI는 도메인 맥락(구독 관리 앱의 오프라인 우선 정책, 사용자 결제 데이터의 민감성)을 이해하지 못합니다. 보일러플레이트는 빠르게 생성하지만, 엣지 케이스(오프라인 상태, 네트워크 전환, 데이터 유실 방지)는 직접 설계하고 검증해야 합니다.
보완 방향
AI 생성 코드를 그대로 사용하지 않고, 핵심 비즈니스 로직은 라인 단위로 검토하는 워크플로우를 정립했습니다. Kiro Steering 파일에 프로젝트 컨벤션과 오프라인 우선 정책을 명시하여 AI가 생성하는 코드의 품질을 사전에 유도합니다.
한계점
AI가 생성한 코드의 성능 최적화가 부족합니다. 불필요한 리렌더링, 과도한 API 호출 등 성능 이슈를 AI가 스스로 감지하지 못합니다.
보완 방향
AI 생성 코드 리뷰 시 성능 관련 체크리스트(불필요한 API 호출, 리렌더링 최적화, 캐싱 적용 여부)를 적용하여 성능 이슈를 사전에 검출합니다.