하루가 끝나갈 무렵 릴리스가 나갑니다. 지원 팀은 크래치 신고, 로그인 실패, 혹은 갑자기 멈춘 체크아웃 플로우로 인해 새벽에 깨어납니다. 엔지니어링 팀이 가장 먼저 묻는 당연한 질문: 무엇이 바뀌었나요? 그리고 회의실은 조용해집니다.
한 명은 Git 커밋을 확인하고, 다른 한 명은 CI 로그를 살펴봅니다. 프로덕트 팀은 '버그 수정 및 개선'이라고만 적힌 App Store 릴리스 노트를 봅니다. Slack에서 누군가가 마지막 순간에 한 설정 변경을 떠올리지만, 그것이 스토어 빌드, live update 번들, 혹은 둘 다에 포함되었는지 확신할 수 없습니다. 바로 이 순간, 팀은 체인지로그와 앱 버전 히스토리가 같은 것이 아님을 깨닫습니다.
모바일 팀이 스토어를 통해 배포하면서 스토어 리뷰 경로 밖으로 code를 푸시하는 경우, 버전 히스토리를 시스템이 아닌 단순 메모 습관으로 취급한다면 운영 리스크는 두 배가 됩니다. 리뷰 지연, 제출 거부, 불분명한 릴리스 출처의 고통을 이미 겪어본 팀이라면 이 패턴을 알아볼 것입니다. App Store 거절 사후 분석. 교훈은 단순합니다. 릴리스 상태가 모호하면, 속도가 가장 중요한 순간에 사고 대응이 느려집니다.
목차
- 버전 히스토리의 중요성을 깨닫는 결정적 순간
- 앱 버전 히스토리란 정확히 무엇인가
- 지금 바로 앱에 버전 히스토리가 필요한 4가지 이유
- App Store 히스토리 vs Live Update 히스토리
- 버전 히스토리 데이터 모델 설계하기
- Capgo로 실전 적용하기
- 단순 기록을 넘어 릴리스 제어로
버전 히스토리의 중요성을 깨닫는 결정적 순간
실패의 원인은 보통 버그 자체가 아닙니다. 문제는 버그를 발견한 뒤, 그 버그를 일으킨 정확한 릴리스를 찾아내기까지의 지연입니다.
모바일 팀은 결함이 있어도 버틸 수 있습니다. 진짜 시간을 낭비하게 만드는 건 불확실성입니다. 어떤 바이너리가 승인되었는지, 어떤 번들이 배포되었는지, 어떤 채널에 전달되었는지, 누가 변경을 트리거했는지 답할 수 없다면 모든 순간이 고고학 작업이 됩니다. 엔지니어는 커밋 메시지를 뒤지고, 지원팀은 스크린샷을 전달하며, 프로덕트 팀은 이슈가 전체인지 특정 세그먼트인지 묻습니다. 누구도 단일 운영 기록을 갖고 있지 않습니다.
운영 공백은 압박을 받을 때 드러난다
스토어 릴리스 이력은 공개 마일스톤을 제공합니다. 버전이 존재했다는 사실은 알려주지만, 그 버전을 만들어낸 내부 이벤트의 순서에 대해서는 보통 충분히 알려주지 않습니다. 최신 모바일 배포 환경에서는 이게 심각한 공백입니다. 사용자가 실행하는 앱은 종종 native binary, web bundle, assets, feature flags, configuration 등 여러 계층이 합쳐진 결과물이기 때문입니다.
공개 릴리스 노트는 고객에게 도움이 되지만, 장애 대응 중인 담당자에게는 거의 도움이 되지 않습니다.
이걸 잘 처리하는 팀은 기억이나 흩어진 도구에 의존하지 않습니다. 이들은 모든 배포 가능한 아티팩트를 타임스탬프, 출처, 대상 채널에 연결하는 버전 원장을 유지합니다. 장애가 터지면 과거를 재구성하는 게 아니라, 이미 기록된 내용을 읽을 뿐입니다.
히스토리가 부실하면 무엇이 깨질까
허술한 앱 버전 이력 시스템은 피할 수 있는 문제를 연쇄적으로 일으킵니다:
- 롤백 지연: 팀이 어떤 버전이 마지막 정상 버전인지 두고 논쟁합니다.
- 지원 정확도 저하: 상담원은 제보가 오래된 스토어 빌드인지 최신 라이브 패치인지 구분하지 못합니다.
- 포스트모템이 모호해짐: 회귀가 있었다는 건 알지만, 정확한 릴리스 순서를 입증할 수는 없습니다.
- 내부 신뢰가 무너집니다: 제품, 지원, 엔지니어링 팀이 '현재 버전'을 두고 서로 다른 말을 하기 시작합니다.
이것은 단순한 관리 작업이 아니라, 프로덕션 제어의 문제입니다.
앱 버전 히스토리란 정확히 무엇인가
앱 버전 히스토리란 배포된 애플리케이션 전체의 Git 히스토리이며,저장소만이 아닙니다. code이나 에셋 중 무엇이 변경되었는지, 언제 변경되었는지, 누가 릴리스를 시작했는지, 그리고 그 릴리스가 어디로 배포되었는지 알려주어야 합니다. 스토어 제출 없이도 앱을 변경할 수 있다면, 히스토리 역시 Native Build만큼 엄격하게 해당 변경 사항을 기록해야 합니다.
많은 팀이 여전히 버전 히스토리를 마케팅 산출물로만 취급합니다. 이는 너무 좁은 시각입니다. 제대로 된 시스템이라면 바이너리, JavaScript bundle, 에셋, 설정 변경, 롤아웃 채널, 릴리스 메타데이터를 하나의 감사 가능한 기록으로 남겨야 합니다. 배포 모델을 비교 중이라면, 이 차이가 바로 전통적인 버전 관리와 Capacitor의 OTA 업데이트 사이의 핵심적인 차이입니다..
체인지로그는 사용자를 위한 것이고, 히스토리 시스템은 운영자를 위한 것입니다
사용자용 릴리스 노트가 “새로운 기능이 무엇인가요?”에 답한다면, 운영 히스토리는 “정확히 무엇이, 언제, 누구에 의해 배포되었으며, 어떻게 롤백할 수 있는가?”에 답합니다.
이 둘은 하는 일이 다릅니다. changelog는 간결하고 선택적일 수 있지만, 내부 이력 시스템은 완전하고 지속 가능해야 합니다. 전문 소프트웨어 개발 및 live update 파이프라인에서 상세한 앱 버전 이력을 유지하려면 다음을 기록해야 합니다. 무엇을, 할 때, 그리고 누가 모든 리비전마다 책임 소재, 오류 복구, 신속한 롤백을 가능하게 하도록, 이 ITU Online의 버전 이력 정의에 설명된 대로..
모든 팀이 반드시 갖춰야 할 최소한의 기록
릴리스가 사용자에게 전달될 수 있다면, 반드시 히스토리 항목이 필요합니다. 최소한 해당 항목에는 다음이 포함되어야 합니다:
- 무엇이 바뀌었나: 스냅샷, 아티팩트 참조, 해시 또는 diff 가능한 bundle ID.
- 배포 시점: 모호한 출시일이 아닌, 정확한 배포 타임스탬프.
- 트리거 주체: 특정 개발자, 서비스 계정 또는 CI 작업.
- 배포 대상: Production, beta, staging 또는 특정 고객 채널.
- 롤백 방법: 이전 안정 리비전과 롤백 경로.
실무 원칙: 팀이 배포할 수 있다면, 세 개의 시스템을 뒤지지 않고도 배포 내역을 식별하고 되돌릴 수 있어야 합니다.
성숙한 앱 버전 히스토리에는 불변성(immutability)이 필요합니다. 팀이 노트를 추가할 수는 있어야 하지만, 릴리스 기록 자체를 고쳐 써서는 안 됩니다. 히스토리가 아무렇게나 수정 가능해지는 순간, 장애 대응이나 감사에서 더 이상 쓸모가 없어집니다.
지금 바로 앱에 버전 히스토리가 필요한 4가지 이유
앱 버전 히스토리가 필요한 이유는 추상적이지 않습니다. 이는 서포트 큐, 장애 대응 회의, 컴플라이언스 검토, 로드맵 결정 과정에서 분명히 드러납니다. 이를 건너뛰는 팀은 결국 협업 속도 저하라는 비용을 치르게 됩니다.
장애 대응 속도가 빨라집니다
릴리스에 문제가 생기면 가장 먼저 할 운영 작업은 버전 격리입니다. 정확히 어떤 빌드나 번들이 문제를 일으켰나요? 어떤 사용자 그룹이 받았나요? 문제가 없던 이전 상태는 무엇이었나요?
히스토리가 없으면 롤백은 논의에 그치지만, 히스토리가 있으면 결정이 됩니다. 엔지니어는 최근 릴리스 몇 개를 검토하고 타임스탬프를 비교해 문제가 의심되는 업데이트를 찾아낸 뒤, 트래픽이나 사용자를 안정적인 리비전으로 되돌릴 수 있습니다.
모바일에서는 스토어 수정에 시간이 걸릴 수 있어 이런 속도가 더욱 중요합니다. 앱에서 Live Updates도 사용한다면, 내부 히스토리가 잘못된 패치가 퍼지는 것을 막는 가장 빠른 방법이 됩니다.
감사 추적이 더 이상 혼란스럽지 않습니다
규제를 받는 팀은 이미 이 고충을 잘 압니다. 운영 환경에서 무엇이 바뀌었는지, 누가 승인했는지, 언제 배포됐는지 증거를 요구받죠. 릴리스 데이터가 Slack, Git 태그, CI 아티팩트, App Store 노트에 흩어져 있으면 답을 찾는 데 너무 오래 걸리고, 답을 내도 불완전하게 느껴집니다.
제대로 된 히스토리 시스템은 그 혼란을 쿼리 하나로 바꿔줍니다. 날짜 범위, 릴리스 채널, 기능 롤아웃별로 리비전 이력을 뽑아 일관된 기록을 보여줄 수 있습니다. 거버넌스의 필요성을 없애지는 않지만, 거버넌스가 검토할 구체적인 근거를 제공합니다.
지원팀이 버전별 이슈에 대응할 수 있습니다
지원팀에 필요한 것은 가공되지 않은 커밋 로그가 아닙니다. 사용자 보고를 릴리스 상태와 연결할 수 있는 신뢰할 수 있는 방법이 필요합니다.
보통 다음과 같은 실무 질문에 답하는 걸 뜻합니다:
- 이 고객은 현재 스토어 버전을 사용 중인가?
- 최신 라이브 번들을 받았는가?
- 이 이슈는 이후 리비전에서 이미 수정됐나?
- 지원팀이 사용자에게 앱 재실행, 업데이트, 단계적 롤아웃 대기를 안내해야 하는가?
지원팀과 엔지니어링 팀이 같은 앱 버전 히스토리를 조회하면 에스컬레이션이 더 짧고 덜 감정적으로 진행됩니다. 대화가 “우리 생각엔”에서 “이 기기는 이 리비전을 사용 중입니다”로 바뀝니다.
릴리스 메커니즘과 모바일 업데이트 제어의 중요성을 다룬 유용한 참고 자료는 아래 임베드된 워크스루에서 확인할 수 있습니다:
제품 및 엔지니어링 팀의 롤아웃 가시성 확보
버전 히스토리는 비상시에만 쓰는 게 아닙니다. 팀이 근거를 바탕으로 릴리스 결정을 내리는 데도 도움이 됩니다.
Android는 버전 파악이 왜 중요한지 보여주는 좋은 예입니다. Android의 공개 버전 히스토리는 다음 날짜에 출시된 베타부터 시작됩니다: 2007년 11월 5일, 첫 상용 버전 Android 1.0 은 2008년 9월 23일에 출시되었고, 이 플랫폼은 전 세계 30억 대 이상의 활성 기기로 성장했습니다. 최신 주요 릴리스인 Android 15 가 2024년에 출시되었으며, Android 14 도달 2024년 중반까지 미국 내 채택률 35%, 반면 Android 11 인도에서 가장 많이 사용되었으며 채택률은 28%였습니다. 또한 Android는 보통 연간 한 번의 주요 업데이트를 Android 버전 히스토리 참조에 따라 제공합니다.
제품 및 엔지니어링 측면에서 이러한 파편화는 롤아웃 결정을 추측에만 의존할 수 없음을 의미합니다. 어떤 앱 리비전이 어떤 OS 환경, 채널, 고객 코호트에 매핑되는지 파악할 수 있는 가시성이 필요합니다. 이를 통해 팀은 호환성 code를 언제 중단할지, 롤아웃 속도를 언제 늦출지, 그리고 이전 경로를 언제 유지할지를 결정할 수 있습니다.
App Store 히스토리 vs Live Update 히스토리
스토어 히스토리와 live update 히스토리는 서로 다른 문제를 해결합니다. 팀이 하나가 다른 하나를 대체할 수 있다고 가정하면 문제가 생깁니다.
스토어는 주요 바이너리 릴리스에 대한 공개 기록을 제공합니다. 이는 중요합니다. iOS의 버전 히스토리는 최초의 iPhone OS와 함께 시작되었습니다. 시작일은 2007년 6월 29일 이며, 이후 다음과 같이 발전해 왔습니다. 2024년 9월 기준, iPhone OS 1부터 iOS 18까지 18개의 메이저 버전. App Store 자체도 함께 출시되었습니다 2008년 7월 11일, iOS 2, 그리고 2013년 9월 18일, iOS 7 은 디자인의 큰 전환점이 되었습니다. 이 플랫폼은 전 세계 15억 대 이상의 활성 기기를 지원하며, 그리고 iOS 16 은 2025년 초 기준 미국 내 활성 iOS 기기 중 약 32%의 점유율을 기록했습니다, 이 자료에 따르면 iOS 버전 히스토리 참고. 이러한 연간 주기는 네이티브 릴리스 계획에 유용한 맥락입니다.
하지만 운영상 스토어는 여전히 대략적인 타임라인일 뿐입니다.
스토어 히스토리가 유용한 점
스토어 출시 히스토리는 다음과 같은 용도로 적합합니다:
| 항목 | App Store / Play Store | Live Update 플랫폼 (예: Capgo) |
|---|---|---|
| 대상 | 공개 및 파트너 대상 | 내부 엔지니어링, 지원 및 운영 |
| 릴리스 단위 | 네이티브 바이너리 | Bundle, assets, config, 타겟 패치 |
| 주기 | 제출 및 심사 플로우에 종속 | 배포 파이프라인이 허용하는 만큼 빠르게 |
| 메타데이터 상세도 | 릴리스 중심의 제한된 컨텍스트 | 잘 설계하면 상세한 운영 메타데이터 |
| 롤백 경로 | 보통 스토어 측 추가 조치가 필요합니다 | 이전 리비전으로 바로 되돌릴 수 있습니다 |
| 포렌식 | 마일스톤 추적에 적합 | 인시던트 단위 조사에 더 적합 |
스토어는 플랫폼이 배포하는 바이너리, 승인, 공개 릴리스 노트를 관리하기에 적합한 곳입니다. 프로덕트 매니저와 외부 이해관계자는 종종 그 기록이 필요합니다. 이 기록은 가시성이 높고 안정적이며 플랫폼 정책과도 일치합니다.
live update 히스토리가 판을 바꾸는 지점
팀에서 스토어 심사 경로를 거치지 않고 JavaScript, 에셋, 카피 또는 설정 변경을 배포한다면, 공개 릴리스 노트보다 내부 버전 히스토리가 더 중요해집니다. 오늘날 많은 모바일 파이프라인은 바로 이렇게 운영됩니다.
핵심 한계는 API의 깊이입니다. App Store Connect 같은 공개 API는 버전 히스토리를 노출할 수 있지만, 다음과 같은 히스토리 결과 50개 제한이있습니다. 이 제한은 완전한 장기 분석을 막고, 다음의 App Store Connect 히스토리 제한에 대한 논의에서 언급된 것처럼 컴플라이언스나 포렌식 작업을 더 어렵게 만듭니다. 이러한 제한은 팀이 전체 리비전 히스토리를 저장하고 채널 기반 롤아웃을 지원하는 내부 버전 트래킹을 구축하거나 도입하는 이유 중 하나입니다.
인시던트 타임라인이 히스토리가 얕은 공개 API에 의존한다면, 인시던트 타임라인은 없는 것입니다. 불완전한 기억만 있을 뿐입니다.
Live update 히스토리는 비공개여야 하고, 검색 가능해야 하며, 세분화되어야 합니다. 차등 업데이트, 채널 타겟팅, 배포 출처, 설치 상태, 롤백 관계를 보여줘야 합니다. 스토어가 잘 답하지 못하는 운영상 질문에도 답할 수 있어야 합니다: 어떤 프로덕션 핫픽스가 베타 대상에게만 먼저 전송됐나요? 마지막 네이티브 릴리스 이후 어떤 에셋 전용 변경 사항이 배포됐나요? 지원팀은 어떤 리비전을 마지막 안정 번들로 간주해야 하나요?
배포 모델을 평가하는 팀에게 이 구분은 철학적이 아니라 실용적인 문제입니다. 이 앱 스토어 업데이트와 직접 업데이트 비교 는 버전 히스토리 요구사항을 형성하는 거버넌스와 속도 간 트레이드오프를 강조하므로 검토할 가치가 있습니다.
버전 히스토리 데이터 모델 설계하기
유용한 앱 버전 히스토리는 데이터 모델에서 시작됩니다. 스키마가 얕으면 히스토리도 얕아집니다. 팀은 보통 버전 번호와 빌드 번호 정도를 추적합니다. 채널, 패치, 롤백을 추가하면 그것만으로는 충분하지 않습니다.
처음부터 저장할 만한 필드
모델은 일반적인 운영 질문을 쉽게 답할 수 있도록 만들어야 합니다. 다음 필드가 대부분을 담당합니다:
- versionId 변하지 않는 고유한 내부 식별자로 사용합니다.
- semanticVersion 사람이 읽을 수 있는 릴레이스 라벨로 사용합니다.
- buildNumber 네이티브 플랫폼 빌드 순서 지정용.
- 채널로 이동 프로덕션, 스테이징, 베타, 고객별 롤아웃 스트림용.
- timestamp 정확한 배포 시각 기록용.
- author 릴리스를 트리거한 개발자, 서비스 계정 또는 CI pipeline용.
- commitHash 소스 컨트롤까지 추적 가능하도록.
- releaseNotes 공개 마케팅 문구가 아닌 내부 컨텍스트용.
- artifactUrl 바이너리 또는 bundle 위치에 사용합니다.
- supersedesVersionId 빠른 롤백 판단에 사용합니다.
- status draft, active, rolled back, retired, failed 상태 중 하나입니다.
하이브리드 앱의 네이밍과 릴리스 식별자 작업을 하고 있다면, 이 가이드에서 Capacitor 앱의 버전 태깅을 다룹니다 데이터 모델 자체를 보완하는 데 유용합니다.
실무에 바로 쓰는 JSON 예시
대부분의 모바일 릴리스 작업을 커버하는 간단한 구조는 다음과 같습니다:
{
"versionId": "ver_2025_02_18_prod_001",
"semanticVersion": "2.5.1",
"buildNumber": "42",
"platform": "ios",
"channel": "production",
"timestamp": "2025-02-18T14:22:00Z",
"author": "ci-release-bot",
"commitHash": "a1b2c3d4",
"releaseNotes": "Fixes login redirect loop and updates remote config defaults",
"artifactType": "live-bundle",
"artifactUrl": "bundle://releases/2.5.1",
"supersedesVersionId": "ver_2025_02_11_prod_004",
"status": "active",
"rollbackTarget": "ver_2025_02_11_prod_004",
"metadata": {
"storeBuild": "2.5.0",
"featureFlags": ["new-auth-flow"],
"audience": "all-users"
}
}지원, 보안, 엔지니어링 팀이 모두 같은 날 이 기록을 필요로 할 수 있다고 가정하고 릴리스 기록을 저장하세요. 결국 그렇게 됩니다.
핵심은 일관성입니다. Xcode Cloud, GitHub Actions, Bitrise, Fastlane 또는 커스텀 스크립트에서 오든 모든 릴리스 경로는 동일한 핵심 메타데이터를 내보내야 합니다. 한 경로에서 작성자 정보를 건너뛰고 다른 경로에서 채널 정보를 건너뛰면 히스토리를 신뢰하기 어려워집니다.
Capgo로 실전 적용하기
버전 히스토리를 가장 빠르게 이해하는 방법은 핫픽스 워크플로우를 살펴보는 것입니다.
릴리스 후 버그 리포트가 접수됩니다. 이 문제는 프로덕션 플로우에 영향을 주지만, 최근 웹 번들을 받은 기기에서만 발생합니다. 엔지니어링 팀은 우선 전체 회의를 할 필요가 없습니다. 필요한 것은 필터링된 리비전, 채널, 타임스탬프 목록입니다.
설명 가능한 핫픽스 워크플로우
live update 환경에서는 개발자가 수정 사항을 만들고, CI가 새 번들을 빌드하며, 시스템이 번들 식별자, 배포 시간, 원본 job, 대상 채널을 기록합니다. 그러면 팀은 변경 사항이 마지막 네이티브 제출에 포함됐는지 아니면 이후 패치였는지 추측하는 대신 채널별로 히스토리를 조회할 수 있습니다.
바로 이럴 때 다음과 같은 도구가 Capgo 맞습니다. Capacitor 앱의 번들 히스토리를 제공하고, 채널별 업데이트를 추적하며, 스토어 심사 없이 배포하는 팀을 위한 롤백 중심 워크플로를 지원합니다. 이 개요는 Capgo가 버전 관리와 롤백을 처리하는 방식은 모바일 팀이 잦은 업데이트를 배포하기 시작하면 보통 필요로 하는 운영 모델이 어떤 것인지 보여줍니다.
대응 담당자는 raw 로그에서 릴리스 상태를 재구성할 시간이 없기 때문에 대시보드 뷰가 중요합니다.
추측 없는 롤백
좋은 롤백 흐름은 “어떤 버전을 시도할까?”에서 시작하지 않습니다. 이전 안정 릴리스가 한눈에 보이는 리비전 체인에서 시작합니다.
이는 장애 대응의 질을 몇 가지 구체적인 방식으로 바꿉니다:
- 엔지니어링 팀은 확신을 얻습니다: 팀은 정확한 핫픽스 후보와 그 이전 버전을 식별할 수 있습니다.
- 지원 팀은 대응 스크립트를 얻습니다: 상담원은 영향받은 사용자가 앱을 재실행해야 하는지, 아니면 단계적 수정을 기다려야 하는지 설명할 수 있습니다.
- 프로덕트 팀은 문제를 격리할 수 있습니다: 이해관계자는 문제가 특정 채널이나 릴리스 웨이브에만 국한되는지 확인할 수 있습니다.
이는 포스트모템도 개선합니다. 팀이 패치가 문제를 일으켰다고 “생각한다”고 말하는 대신, Native Build 승인, 라이브 번들 배포, 에러 보고, 롤백 트리거, 안정 번들 복원으로 이어지는 시퀀스를 짚을 수 있습니다. 이러한 수준의 추적 가능성이 앱 버전 히스토리를 단순한 기록에서 릴리스 컨트롤로 바꿔줍니다.
단순 기록을 넘어 릴리스 제어로
앱 버전 히스토리는 흔히 문서로 여겨집니다. 성숙한 팀은 이를 운영 제어 수단으로 다룹니다.
이러한 관점의 변화가 중요한 이유는 모바일 배포가 이제 두 개의 시계에 따라 움직이기 때문입니다. 첫 번째는 네이티브 바이너리, 공개 출시, 심사 기반의 주기를 관리하는 스토어 시계입니다. 두 번째는 빠른 수정, 타겟 롤아웃, 롤백 속도를 관리하는 live update 시계입니다. 첫 번째 시계만 추적한다면, 가장 빠르게 움직이는 순간에 아무것도 보지 못하는 셈입니다.
강력한 히스토리 시스템은 지원 팀에는 신뢰할 수 있는 답변을, 제품 팀에는 실제 롤아웃 현황을, 엔지니어링 팀에는 검증된 상태로 돌아갈 수 있는 안전한 경로를 제공합니다. 또한 사용자가 정확히 무엇을 실행 중인지 모르는 데서 오는 흔한 배포 불안 요인도 없애 줍니다.
현재의 릴리스 파이프라인을 다음 질문 하나로 점검해 보세요. 만약 다음 한 시간 내에 프로덕션에 문제가 발생한다면, 팀이 여러 도구를 뒤지지 않고도 문제가 된 리비전을 찾아내고 되돌릴 수 있습니까? 답이 '아니오'라면 버전 히스토리를 개선해야 합니다.
Capgo는 Capacitor 팀이 버전 히스토리를 단순한 릴리스 노트가 아닌 릴리스 운영의 일부로 다룰 수 있도록 돕습니다. 채널 기반 Live Updates, 번들 히스토리, 롤백 지원을 같은 워크플로우에서 원한다면 다음을 확인해 보세요. Capgo.
