명함관리 CardSync — CRM의 시작은 "데이터를 밖에 주지 않는 것"이었다
명함을 찍으면 AI가 알아서 이름·회사·직책·연락처를 정리해 줍니다. 흔한 기능처럼 보이지만, 우리는 한 가지를 양보하지 않기로 했습니다 — 명함에 적힌 타인의 개인정보를 외부 서버로 보내지 않는다. 그 결정 하나가 기술 선택 전체를 바꿨습니다. 이 글은 “AI를 붙이는 가장 쉬운 길(클라우드 API)“을 일부러 포기하고, 더 어려운 길(온디바이스)을 택한 이유와, 그 길에서 무엇을 얻고 무엇을 감수했는지의 기록입니다.
1. CRM은 “사람을 아는 것”에서 시작한다
섹션 제목: “1. CRM은 “사람을 아는 것”에서 시작한다”영업의 출발점은 결국 사람입니다. 누구를 만났고, 어느 회사 소속이고, 어떻게 연락하는가 — 이 정보가 쌓여야 CRM이 됩니다. 그 정보의 입구가 바로 명함입니다.
명함첩에 카드를 쌓아 두면 검색도, 백업도, 공유도 안 됩니다. 그래서 명함을 사진 한 장으로 디지털화하는 CardSync를 CRM의 첫 단추로 삼았습니다. 찍으면 끝 — 이름, 회사, 직책, 휴대폰, 이메일이 칸칸이 정리되는 것이 목표였습니다.
2. 단순 OCR로는 왜 부족한가
섹션 제목: “2. 단순 OCR로는 왜 부족한가”명함을 글자로 읽는 것(OCR)까지는 쉽습니다. 문제는 그 다음입니다. 읽어낸 글자 덩어리에서 **“이건 이름, 이건 부서, 이건 휴대폰, 이건 회사 대표번호”**를 가려내는 건 단순 인식이 아니라 판단입니다.
- OCR이 읽은 결과:
"홍길동 / SL파워 / 책임연구원 / 010-0000-0000 / 02-000-0000 / hong@..." - 그런데 010과 02 중 어느 게 휴대폰인가? “책임연구원”은 직책인가 부서인가? 회사명은 로고 옆 영문인가 한글인가?
- 이 구분에는 맥락 이해가 필요합니다 — 단순 규칙(정규식)만으로는 명함 디자인이 조금만 달라도 틀립니다.
그래서 처음엔 클라우드 LLM(언어 모델)을 호출하는 게 자연스러워 보였습니다. 정확하고, 빠르고, 붙이기 쉬우니까요.
3. 멈칫한 순간 — “이건 내 데이터가 아니다”
섹션 제목: “3. 멈칫한 순간 — “이건 내 데이터가 아니다””코드를 짜려다 멈췄습니다. 명함에 적힌 정보는 내 데이터가 아니라 상대방의 개인정보입니다. 내가 받은 명함이라도, 거기 적힌 이름·전화·이메일의 주인은 그 사람입니다. 그걸 외부 LLM 서버로 보내는 게 과연 옳은가?
2026년 5월, CEO 결정으로 클라우드 LLM(Gemini/외부 API)을 전면 제거하기로 했습니다. 비용·네트워크 의존도 함께 떨쳐냈습니다. 대신 더 어려운 길을 택했습니다.
이 결정은 단순한 취향이 아니라 가치의 우선순위 문제였습니다. 명함 OCR에서 우리가 지킬 수 있는 가치는 네 가지였습니다 — 정확도, 비용, 오프라인 동작, 그리고 프라이버시. 클라우드는 앞의 정확도 하나를 가장 잘 주지만, 뒤의 셋(특히 프라이버시)을 내줍니다. 우리가 다루는 게 남의 개인정보인 이상, 우선순위의 맨 앞은 프라이버시여야 했습니다. “가장 정확한 길”과 “가치 순위에 맞는 길”이 갈릴 때, 우리는 후자를 택했습니다. 정확도는 나중에 모델을 키우거나 바꿔 끌어올릴 수 있지만, 한번 외부로 흘러간 개인정보는 되돌릴 수 없기 때문입니다.
4. 처방: 온디바이스 LLM 단일 트랙
섹션 제목: “4. 처방: 온디바이스 LLM 단일 트랙”대안은 온디바이스 LLM이었습니다. 클라우드가 아니라 모바일 기기 안에서 작은 LLM이 직접 명함을 구조화합니다. 데이터가 기기 밖으로 한 발짝도 나가지 않습니다.
구조는 2단계(2-tier)로 잡았습니다. 핵심은 “AI가 없어도 동작한다”는 안전장치를 깔아 둔 것입니다.
모델 파일은 앱에 끼워 넣지 않고 필요할 때 런타임에 내려받습니다(첫 다운로드 전까지는 OCR만으로 동작). 앱 용량을 무겁게 하지 않으면서, 모델을 나중에 갱신할 여지도 남긴 선택입니다.
그래서 같은 앱이라도 기기 상황에 따라 “동작 수준”이 달라집니다. 중요한 건, 어느 상황에서도 완전히 멈추지는 않는다는 점입니다.
| 기기 상황 | 동작 수준 | 결과 |
|---|---|---|
| 모델 다운로드 전 | 1단계만(OCR+정규식) | 기본 필드는 잡힘 — 쓸 수 있음 |
| 모델 있음 + 성능 충분 | 1+2단계(OCR→LLM) | 필드 구조화 정확도 향상 |
| 기기 성능 부족 | 1단계로 폴백 | 느려지지 않고 OCR 결과 유지 |
“AI가 켜지면 더 좋아지고, 안 켜져도 기본은 한다.” 이 단계적 열화(graceful degradation)가 온디바이스 AI의 불확실성을 제품의 불안정성으로 번지지 않게 막아 줍니다.
5. 무엇을 얻고 무엇을 감수했나
섹션 제목: “5. 무엇을 얻고 무엇을 감수했나”모든 결정에는 대가가 있습니다. 온디바이스를 택하며 얻은 것과 내준 것을 솔직히 정리하면 이렇습니다.
| 항목 | 클라우드 방식 | 온디바이스 방식 (택함) |
|---|---|---|
| 데이터 흐름 | 외부 서버로 전송 | 기기 밖으로 안 나감 |
| 호출 비용 | 발생 | 0 |
| 네트워크 | 끊기면 못 씀 | 오프라인에서도 동작 |
| 정확도·속도 | 빠르고 정확 | 기기·모델에 종속 |
| 가치 | 클라우드 | 온디바이스 |
|---|---|---|
| 프라이버시(데이터 주권) | 약함 — 외부 전송 | 강함 — 기기 안에서 끝 |
| 비용 | 호출마다 과금 | 0 |
| 네트워크 의존 | 필수 | 불필요(오프라인 가능) |
| 정확도/속도 | 높음 | 기기·모델 크기에 종속 |
명함이라는 특정 작업에서는, 작은 온디바이스 모델로도 “쓸 만한” 수준을 얻을 수 있었습니다. 여기엔 작업의 성격도 한몫했습니다. 명함은 정보의 형태가 비교적 정형화돼 있습니다 — 이름·회사·직책·전화·이메일이라는 칸이 정해져 있습니다. 자유로운 글을 이해하는 것보다, “이 글자 덩어리를 정해진 칸에 배치하라”가 작은 모델에게 훨씬 만만한 일입니다. 작업이 좁고 분명할수록 작은 모델로도 충분하다는 것 — 이건 온디바이스 AI를 검토할 때 일반적으로 적용되는 경험칙입니다.
그리고 그 트레이드오프는 우리 가치(데이터 주권)와 정확히 맞아떨어졌습니다. 이 결정으로 클라우드 방향의 후속 작업(Phase 2)은 전부 취소하고, 온디바이스를 메인 트랙으로 확정했습니다. “두 길을 다 열어 두자”는 유혹도 있었지만, 트랙을 둘로 가져가면 둘 다 어중간해집니다. 하나로 좁히는 결정이 오히려 그 하나를 제대로 만들게 했습니다.
이 글은 SL.AIMS를 만들며 겪은 현장 회고 중 하나입니다. 전체 그림은 〈사례연구: SL.AIMS〉에 있습니다.