掘金2026년 9월 21일 10:12중국어 → 한국어

하모니OS 7 비전 AI, 시스템级 장면 컨트롤로 온디바이스 접근

글은 명함 스캔과 자동 입력 기능을 예로 들어 모델 선택부터 온디바이스 배포까지 통합 과정의 어려움을 소개한다.

중국어 원문을 AI로 번역했습니다. 고유명사와 수치는 원문 표기를 우선하며, 중요한 판단에는 아래 출처 원문을 함께 확인하세요.

본 글은 HarmonyOS 7(API 26) 공식 《신규 기능 일람》, Vision Kit(시나리오 기반 비전 서비스)와 Core Vision Kit(기초 비전 서비스)의 공식 문서를 바탕으로 정리한 것이다. 본문 중 라이브니스 검출과 이미지 초해상도의 인터페이스 이름, 시작 버전은 모두 공식 API 레퍼런스에서 발췌하여 출처를 표기했다. 공개된 API 이름이 확인되지 않은 부분은 능력과 접근 방식만 설명했으며, 예시 코드에는 모두 "인터페이스 이름은 공식 SDK 문서를 기준으로 한다"고 명시했다. 실기기 실측은 하지 않았으므로, 인식 정확도 등의 성능은 모두 실기기 실측을 기준으로 한다.

서문: 당신에게 부족한 건 모델이 아니라 통합이다

V군이 실제 있었던 일을 하나 이야기하자. 얼마 전 비즈니스 소셜 앱을 만드는 친구가 V군에게 하소연했다. 제품 매니저가 명함 스캔 페이지에 "촬영으로 명함 인식, 자동 채우기" 기능을 추가하라고 했는데, 팀이 한 차례 검토해 보니 모델 선정, 데이터 확보, 포맷 변환, 온디바이스 배포, 메모리 최적화, 여기에 프라이버시 컴플라이언스 심사까지 더해 일정이 석 달은 기본이었다. 친구가 V군에게 물었다. 고정된 판형의 명함 한 장을 인식하기 위해서 이게 가치가 있느냐고?

V군의 답은 가치가 없다는 것이었고, 방향 자체가 틀렸다. 비전 AI의 진입장벽은 애초에 모델에 있는 게 아니라 통합에 있다. 신분증 인식, 문서 스캔, 배경 제거, 텍스트 추출 같은 일은 알고리즘 자체가 이미 오래전부터 "규격 부품"이었다. 어려운 것은 규격 부품을 당신의 앱에 집어넣는 일이다. 모델 변환, 추론 프레임워크, 기종 적응, 메모리·전력, 데이터 컴플라이언스 —每一项 모두 함정이고,每一项 모두 당신의 비즈니스 가치와는 무관하다.

HarmonyOS 7(API 26)은 바로 이痛点을 겨냥해 나왔다. 공식 《신규 기능 일람》의 "비전 AI 능력"에 대한 원문 표현은 다음과 같다.

비전 AI의 기초 능력과 시나리오 기반 컨트롤을 제공하여, 개발자가 낮은 진입장벽으로 효율적이고 안전하게 온디바이스 비전 AI 처리 능력을 구축하도록 돕는다.

이 서른 몇 글자 안에 세 개의 키워드가 숨어 있다. 낮은 진입장벽(시나리오 기반 컨트롤을 개봉 즉시 사용), 효율(추론 체인을 직접 구축할 필요 없음), 안전(추론이 온디바이스에서 완료되어 데이터가 기기를 벗어나지 않음). 이번 회차에 V군은 이 두 공식 Kit의 기능 지도, 실제 접근 방식, 그리고 "언제 시스템 컨트롤을 써야 하고 언제 반드시 직접 모델을 올려야 하는가"의 판단 기준을 한 번에 명확히 파헤친다.

1. 기능 지도: 두 개의 Kit, 하나는 블록을 팔고 하나는 완제품을 판다

HarmonyOS의 온디바이스 비전 능력은 두 개의 Kit으로 나뉘며, 분업이 매우 명확하다(공식 AI 능력 일람, Vision Kit 공식 페이지).

V군이 비유하자면, Core Vision Kit은 밀가루와 오븐을 주는 것이고 Vision Kit은 바로 갓 나온 빵을 주는 것이다. 대부분의 앱이 원하는 것은 사실 빵 한 조각이다. 신분증 인식은 신분증만 인식하면 되고, 문서 스캔은 문서만 스캔하면 되니, 굳이 직접 빵집을 열 필요가 없다.

오해하기 쉬운 점 하나를 명확히 하자. 시나리오 기반 컨트롤이 7.0에만 생긴 것은 아니다. Vision Kit의 라이브니스 검출 등의 능력은 시작 버전이 API 12(5.0.0)에서 이미 개방되었다(공식 API 레퍼런스 표기). 7.0이 한 일은 이 제품 라인을 전반적으로 업그레이드하고 시스템 레벨 개방 능력으로 명확히 규정한 것이며, 동시에 Core Vision Kit 쪽에는 이미지 초해상과 텍스트 검색 이미지라는 26.0.0 시작의 신규 API 두 개를 추가했다. 따라서 정확한 표현은 이렇다. HarmonyOS 7 시대에는 "시스템 레벨 비전 AI"가 이미 앱 쪽에서 안심하고 의존할 수 있는 일등 시민 능력이 되었으며, 단지 특정 버전의 산발적 인터페이스가 아니다.

또 하나의 단단한 경계가 있다. Core Vision Kit의 이미지 초해상 등의 인터페이스는 Stage 모델만 지원한다(공식 API 레퍼런스 원문). FA 모델 프로젝트는 먼저 마이그레이션부터 하고 나서 이야기하자. 또한 7.0 관련 능력은 HarmonyOS 7로 업그레이드해야 하며 실제 지원 기종을 기준으로 한다.

2. 시나리오 기반 컨트롤 네 종 세트: 각각이 한 가지 비즈니스 유형을 겨냥한다

Vision Kit 공식 페이지는 네 가지 능력의 서비스 시나리오를 매우 직설적으로 적어 놓았다(Vision Kit). V군이 비즈니스 관점으로 번역해 본다.

① 얼굴 라이브니스 검출(interactiveLiveness): 사용자가 실제 살아 있는 사람인지 검증하여 사진, 영상 등의 공격을 방어한다. 사용자 실명 인증, 금융 리스크 관리, 출퇴근 체크인에 대응한다 — "화면 건너편이 살아 있는 사람인지 확인해야 하는" 모든 시나리오다.

② 카드·신분증 인식(CardRecognition): 주민등록증, 차량등록증, 운전면허증, 여권, 은행카드의 구조화 인식. 사용자의 카드번호 입력, 실명 등록, 차량 정보 등록에 대응한다 — "사용자가 신분증을 보며 타자를 치는 것"을 "사용자가 신분증을 향해 사진을 찍는 것"으로 바꾼다.

③ 문서 스캔(DocumentScanner): 문서를 촬영하여 고화질 스캔본으로 변환하고, 표도 인식해 양식 문서를 생성한다. 교육·사무, 영수증·전표 아카이빙 시나리오를 겨냥한다.

④ AI 이미지 인식 컨트롤(visionImageAnalyzer): 시나리오 기반 텍스트 인식, 주체 분할, 이미지 인식 검색. 앨범에서 길게 눌러 텍스트 추출, 원클릭 배경 제거 같은 "이미지 활용성" 시나리오를 겨냥한다.

이 네 가지의 공통점에 주목하자. 바로 컨트롤 형태라는 점이다. 즉 시스템이 인식 능력만 주는 것이 아니라 촬영, 가이드, 자르기, 결과 반환까지의 UI 흐름까지 모두 캡슐화해 준다. 당신이 하는 일은 "적절한 시점에 그것을 호출하고, 그다음 결과를 받는 것"뿐이다. 이것이 "낮은 진입장벽"이라는 세 글자의 구체적 의미다 — API가 좀 더 단순한 게 아니라, 전체 인터랙션 체인이 시스템에 의해 인계되는 것이다.

3. 실전: 스무 줄로 얼굴 라이브니스 검출 연동하기

V군이 공식 Codelab 방식(Vision Kit Codelab)으로 라이브니스 검출의 전체 연동 과정을 한 번 따라가 본다. 먼저 카메라 권한을 선언하고, 그다음 검출 파라미터를 설정하고, 컨트롤을 호출하고, 결과를 받는다.

// LivenessDemo.ets —— 얼굴 라이브니스 검출 최소 연동 예시 import { interactiveLiveness } from '@kit.VisionKit' ; import { abilityAccessCtrl, common, Permissions } from '@kit.AbilityKit' ; import { BusinessError } from '@kit.BasicServicesKit' ;

const CAMERA_PERMISSIONS : Permissions [] = [ 'ohos.permission.CAMERA' ];

async function startLiveness ( context: common.UIAbilityContext ): Promise < void > { // ① 라이브니스 검출은 카메라에 의존하므로, 먼저 표준 권한 신청 절차를 거친다 const atManager = abilityAccessCtrl. createAtManager (); const result = await atManager. requestPermissionsFromUser (context, CAMERA_PERMISSIONS ); if (!result. authResults . every ( status => status === 0 )) { return ; // 사용자가 권한 부여를 거부하면, 안내 문구로 유도하고 강요하지 않는다 }

// ② 검출 파라미터 설정: 동작 라이브니스 모드, 무작위 3개 동작, 완료 후 원래 페이지로 복귀 const config : interactiveLiveness. InteractiveLivenessConfig = { isSilentMode : interactiveLiveness. DetectionMode . INTERACTIVE_MODE , // 동작 라이브니스 검출 actionsNum : interactiveLiveness. ActionsNumber . THREE_ACTION , // 무작위 3개 동작(눈 깜빡임/고개 끄덕임/입 벌리기 등) routeMode : interactiveLiveness. RouteRedirectionMode . BACK_MODE // 검출 완료 시 router.back으로 원래 페이지 복귀 };

// ③ 시스템 라이브니스 검출 컨트롤 호출: 촬영, 동작 가이드, 판정 모두 시스템 페이지에서 완료 await interactiveLiveness. startLivenessDetection (config);

// ④ 돌아온 뒤 결과 가져오기: livenessType으로 통과 여부를 표시하고, 가장 라이브니스 특징이 강한 사진을 첨부 interactiveLiveness. getInteractiveLivenessResult () . then ( ( data: interactiveLiveness.InteractiveLivenessResult ) => { console . info ( `liveness result type: ${data.livenessType} ` ); // V군 팁: 이걸로 실제 라이브니스를 판정하고, 딴 꾀를 부리지 말 것 }) . catch ( ( err: BusinessError ) => { console . error ( `failed, code: ${err.code} , message: ${err.message} ` ); }); }

V군이 세어 보니 비즈니스 코드는 스무 줄이 안 된다. 3년 전에 직접 라이브니스 검출을 연동하던 목록과 비교해 보자 — 알고리즘 선정, SDK 통합, .camera 스트림 관리, 동작 가이드 UI, 적대적 샘플 테스트…… 이제 이 모든 것이 시스템 컨트롤 내부의 일이 되었다. 당신의 앱은 두 가지만 담당한다. 권한 신청, 결과 수신.

V군이 먼저 짚어 두는 쉽게 빠지는 세 가지 지점:

- 라이브니스 검출은 시뮬레이터와 프리뷰어를 지원하지 않는다. 반드시 실기기로 디버깅해야 한다 — 시뮬레이터에서 반나절을 씨름하며 연동이 깨졌다고 착각하지 말 것.

- actionsNum은 현재 3개 또는 4개 동작을 지원하며, 동작 시퀀스는 시스템이 무작위로 생성하고 규칙은 내장되어 있다(예: 눈 깜빡임과 응시는 인접하지 않음). 이는 공격 방어 설계의 일부이므로 개입하려 하지 말 것.

- 이 능력은 금융 등급 인증을 통과했지만, 공식은 여전히 고위험 결제 시나리오에 추가 보안 조치를 겹쳐 둘 것을 권장한다 — 시스템 컨트롤은 토대이지, 면죄부가 아니다.

4. 7.0 신규: 이미지 초해상, 오래된 사진과 저화질 이미지에 생명을 불어넣다

Core Vision Kit이 이번에 API 26에서 새로 추가한 두 가지 능력 중 V군이 가장 기대하는 것은 이미지 초해상이다(개발 가이드, API 레퍼런스). 공식 포지셔닝: 입력된 저해상도 이미지에 대해 초해상도 재구성을 수행하여, 이미지 품질 향상, 오래된 사진 복원 등의 시나리오에 적용되며, 시작 버전 26.0.0, Phone / PC·2in1 / Tablet 모두 지원.

연동 방식은 표준 "분석기" 모드다. 인스턴스 생성, 처리, 소멸. V군이 공식 가이드에 따라 작성한 골격은 다음과 같다.

// ImageSRDemo.ets —— 이미지 초해상도 최소 골격(공식 개발 가이드를 바탕으로 개작) import { imageSuperResolution } from '@kit.CoreVisionKit' ; import { image } from '@kit.ImageKit' ; @Component struct ImageSRPage { // 분석기 인스턴스: 컴포넌트 생명주기에 따라 생성 및 해제하여 상주로 메모리를 차지하는 것을 방지 private analyzer : imageSuperResolution. ImageSRAnalyzer | null = null ; async aboutToAppear (): Promise < void > { // V형님 주의: create는 비동기이므로, 페이지가 완전히 준비되기 전에 성급하게 process를 호출하지 말 것 this . analyzer = await imageSuperResolution. ImageSRAnalyzer . create (); } async aboutToDisappear (): Promise < void > { // 다 쓰면 바로 소멸——초해상도는 무거운 추론이므로, 인스턴스를 붙잡아 두는 것은 순전한 낭비 await this . analyzer ?. destroy (); this . analyzer = null ; } // 저화질 PixelMap이 들어가고, 고화질 PixelMap이 나온다: 공식 설명대로 픽셀이 동기적으로 4배 확대된다 private async enhanceLowResImage ( src : image. PixelMap ): Promise <image. PixelMap | null > { if (! this . analyzer ) { return null ; } // process의 구체적인 입력 파라미터 구조는 공식 SDK 문서를 기준으로 하며, 여기서는 호출 의도만 표현한다 const response : imageSuperResolution. ISPResponse = await this . analyzer . process (src); return response. pixelMap ; } }

이미지 초해상도와 함께 새로 추가된 또 하나는 텍스트로 이미지 검색하기 다: 단말 측에서 텍스트 의미를 기반으로 이미지 인덱스 구축과 검색을 완료하며, 공식이 제시한 응용 방향은 이미지 검색, 앨범 관리, 콘텐츠 추천이다. V형님은 그 구체적인 인터페이스 이름으로 코드를 작성하지 않았다——이 항목의 API 세부 사항은 공식 SDK 문서를 기준으로 하지만, 접목 아이디어는 언급할 만하다: 인덱스 구축이 단말 측에서 완료되고 검색도 단말 측에서 완료된다 , 앨범류 애플리케이션은 더 이상 사용자 이미지를 클라우드에 업로드해 벡터화할 필요가 없다.

이 두 가지 능력을 합쳐 보면 매우 흥미롭다: 초해상도는 "이미지를 더 좋게 만들기"를, 텍스트로 이미지 검색은 "이미지를 찾아내기"를 담당하고, 기존의 문자 인식, 주체 분할까지 더하면 Core Vision Kit는 "인식"에서 "강화"와 "검색"으로 확장되고 있다——기초 시각 능력의 판도가 채워진 것이다.

5. V형님의 판단: 언제 시스템 컨트롤을 쓰고, 언제 반드시 직접 모델을 단말에 얹어야 하는가

여기까지 쓰다 보면, 가장 날카로운 질문에 답해야 한다: 시스템 컨트롤이 이렇게 좋은데, 자체 개발 모델이 여전히 필요한가? V형님이 세 가지 질문 판단법을 제시한다:

첫 번째 질문: 시나리오가 "표준적인" 것인가, "당신의" 것인가? 신분증, 문서, 얼굴, 범용 물체——이들은 모든 애플리케이션이 공유하는 표준 시나리오이며, 시스템 컨트롤은 알고리즘 팀의 전체 수준으로 당신을 대신해 뒷받침해 주고, 정확도, 적대적 견고성, 기종 커버리지 모두 시스템 차원의 투자이므로 당신이 자체 개발해도 대체로 이기지 못한다. 그러나 당신 제품의 차별점이 바로 시각이라면——예를 들어 산업 품질 검사에서 특정 부품 결함을 식별하거나, 의료 영상에서 특정 병변을 판독하는 경우——이런 "롱테일 영역"에는 기성 모델이 없으므로, 차별점은 반드시 자신의 손에 쥐고 있어야 한다 . V형님 한마디로 정리: 범용 능력은 바퀴를 재발명하지 말고, 제품 차별점은 아웃소싱하지 말라 .

두 번째 질문: 데이터 컴플라이언스의 셈은 어떻게 하는가? 시스템 컨트롤은 모두 단말 측에서 추론하므로, 신분증 사진, 얼굴 데이터가 기기를 벗어나지 않아 컴플라이언스 서사가 매우 깔끔하다. 자체 모델도 마찬가지로 단말 측 배포가 가능하지만, 공정 규모와 책임 경계가 전혀 다르다——모델 품질, 안전 방호 모두 당신의 것이다. 둘 다 "데이터가 단말을 벗어나지 않는다"지만, 하나는 시스템이 당신을 대신해 보증하는 것이고, 다른 하나는 당신이 직접 보증하는 것이다.

세 번째 질문: 상호작용 경로를 시스템이 인계해야 하는가? 카드/신분증 인식의 시나리오화 컨트롤은 촬영 가이드, 엣지 검출, 크롭 프레임까지 다 만들어져 있다; 자체 모델을 얹으면 UI 흐름까지 직접 구축해야 한다는 뜻이다. 상호작용 자체가 당신의 제품(예컨대 카메라 애플리케이션)이 아니라면, 공짜로 주어지는 시스템 경로를 거절할 이유가 없다.

세 가지 질문이 끝나면 결정은 거의 나온다: 표준 시나리오 + 특수 상호작용 없음 → 시스템 컨트롤; 표준 시나리오 + 맞춤 상호작용 → Core Vision Kit 기초 API로 직접 경로 구성; 롱테일 차별 시나리오 → 자체 모델, 그리고 그럴 가치가 있다. 대부분의 팀은 "자체 개발해야 하나"에서 공회전하는데, 사실 진짜로 자체 개발해야 하는 것은 언제나 세 번째뿐이다.

6. 마무리: 단말 측은 시각 AI의 종착 형태다

전체 맥락을 되돌아보면: 시각 AI라는 일은 업계가 이른 시기에 걸었던 노선이 "클라우드 인식"이었다——이미지 업로드, 클라우드 추론, 결과 회신. 그것은 쓰기 편했지만 두 가지 셈을 피할 수 없었다: 지연(약한 네트워크에서는 PPT처럼 버벅임)과 프라이버시(신분증 사진이 남의 서버에 누워 있음).

HarmonyOS 7은 기초 능력과 시나리오화 컨트롤을 애플리케이션에 직접 개방했는데, 본질적으로 이 두 가지 셈을 한 번에 청산한 것이다: 추론은 단말 측에서, 지연은 칩 연산 능력을 따라가고, 데이터는 기기 위에서 생겨 기기 위에서 사라진다. 공식의 그 "낮은 문턱, 효율, 안전"이라는 말에서 V형님은 무게중심이 "안전"에 있다고 본다—— 시각 능력의 기본 형태가 단말 측일 때, "데이터가 단말을 벗어나지 않는다"는 더 이상 애플리케이션의 비용이 아니라 시스템의 기본값이 된다 .

이제 막 시작하려는 동학들에게 세 가지 실행 조언: 먼저 공식 페이지에서 두 Kit의 능력 목록과 제한 조건을 한 번 읽어라(각 능력이 지원하는 언어, 기종, 모드에 모두 명확한 경계가 있다); Codelab으로 컨트롤 하나를 끝까지 돌려본 뒤 일정을 평가하라——V형님의 경험상, 끝까지 돌려보는 비용은 당신의 심리적 예상보다 훨씬 낮다; 능력 성능(인식 정확도, 초해상도 효과)은 일괄적으로 자신의 업무 이미지로 실기기에서 실측한 것을 기준으로 하라, 공식은 범용 수치를 약속하지 않았고 V형님도 그것을 대신 지어내지 않을 것이다.

참고 및 출처

본문에서 다룬 공식 표현, 능력 목록과 인터페이스 정보는 모두 다음 페이지에서 온 것이다:

- HarmonyOS 7 신규 능력 한눈에 보기(화웨이 개발자 연맹) ——"시각 AI 능력" 공식 원문

- HarmonyOS AI 능력과 서비스 한눈에 보기 ——Core Vision Kit / Vision Kit의 위치와 능력 목록

- Vision Kit(시나리오화 시각 서비스) 공식 페이지 ——네 가지 컨트롤과 서비스 시나리오

- Vision Kit Codelab(화웨이 개발자 공식 사이트) ——활체 검출 접목 흐름과 제한

- 이미지 초해상도 개발 가이드(Core Vision Kit)

- imageSuperResolution API 레퍼런스

마지막 한마디 : 시각 AI의 하반기는 누가 모델을 잘 훈련하느냐가 아니라, 누가 시스템이 손에 쥐여준 능력을 빠르게 접목하고 안정적으로 쓰느냐의 싸움이다——단말 측 연산 능력은 이미 거기 있으니, 부족한 것은 당신이 import하는 그 한 줄뿐이다.

웨이거(威哥) 프로그래밍 사랑

AI 풀스택, 위챗 공식계정: 웨이거 프로그래밍 사랑

388

글

315k

읽음

556

팬

출처 원문