AI로 Android 연락처 만들기: 중복 확인, 승인, 저장 검증까지

중복 없이 연락처 하나 만들기

AI로 Android 연락처 만들기 중복 확인을 제대로 하려면, “저장해 줘”라는 한마디를 바로 주소록 쓰기로 연결하지 않고 다섯 단계로 나눠야 합니다. 먼저 원본을 고릅니다. 문자, 이메일 서명, 회의 메모, 명함 사진, 통화 후 메모처럼 사용자가 보관하려는 정보가 출발점입니다. 다음으로 이름, 전화번호, 이메일, 회사, 직함, 메모, 저장 계정을 후보 필드로 정리합니다. 그다음 기존 연락처에서 정확한 일치와 가능한 일치를 찾고, 사용자가 후보를 검토한 뒤 생성·수정·취소 중 하나를 승인합니다. 마지막으로 실제 주소록에서 저장 결과를 검색해 확인합니다.

FoneClaw에서 우리는 이 흐름을 Android 휴대폰 작업으로 다룹니다. 현재 FoneClaw는 승인된 연락처 생성을 지원하며, 저장 전에 중복 연락처를 확인하는 과정을 포함합니다. 사용자가 볼 수 있는 후보를 만들고, 중복 가능성을 보여 주고, 저장 작업을 승인한 뒤, 결과를 다시 확인하는 것이 핵심입니다. 이는 빠르게 연락처를 늘리는 기능이 아니라, 나중에 찾기 쉬운 주소록을 만드는 작업입니다.

예를 들어 문자에 “박민서, 라움치과, 010-1234-5678, minseo@example.com”이 들어왔다고 해 보겠습니다. FoneClaw에 “이 정보를 연락처 후보로 정리하고 중복이 있는지 확인해 줘”라고 요청하면 이름과 조직, 전화번호, 이메일을 분리해 검토할 수 있습니다. 이미 같은 이메일이 있으면 새 연락처가 아니라 기존 기록 업데이트 후보가 됩니다. 같은 이름만 있고 번호가 다르면 가능한 일치로 보고 사용자가 선택합니다. 승인 경계는 여기서 분명해집니다. 중복 확인은 판단을 돕고, 실제 저장은 사용자가 검토한 뒤 진행합니다.

메시지 서명과 메모를 연락처 필드로 바꾸기

연락처 생성의 품질은 원본 문장을 얼마나 정확하게 구조화하느냐에서 갈립니다. Android의 Contacts Provider 안내는 연락처가 집계된 Contact, 계정별 RawContact, 이름·전화번호·이메일 같은 Data 행으로 구성된다고 설명합니다. 사용자는 화면에서 한 사람의 연락처로 보지만, 내부적으로는 계정과 필드가 나뉘어 저장됩니다. 그래서 AI는 “박 팀장 010...” 같은 메모를 그대로 붙여 넣는 대신, 각 값을 알맞은 필드로 분리해야 합니다.

실제 후보에는 최소한 이름과 연락 방법이 필요합니다. 이름은 표시 이름과 성·이름 분리 여부를 확인하고, 전화번호는 국가번호와 지역 형식을 살핍니다. 이메일은 오타가 많은 필드이므로 점, 하이픈, 도메인을 그대로 확인해야 합니다. 회사와 직함은 검색에 도움이 되지만, 이름이나 전화번호만큼 강한 식별자는 아닙니다. 메모 필드는 “첫 상담 문의”, “8월 전시회에서 만남”, “카카오톡으로 연락 선호”처럼 나중에 기억할 맥락을 짧게 남기는 데 적합합니다.

우리가 FoneClaw에서 중요하게 보는 것은 제공된 사실과 추정을 구분하는 일입니다. 메시지에 “라움 박민서”라고만 있으면 라움이 회사인지 매장인지 부서인지 확정할 수 없습니다. 전화번호 앞자리가 지역을 암시해도 사용자가 말하지 않은 국가번호를 마음대로 바꾸면 안 됩니다. “김대표”라는 표현은 이름이 아니라 호칭일 수 있습니다. 좋은 후보는 “확인 필요” 항목을 남기고, 사용자가 승인 화면에서 고칠 수 있어야 합니다.

문자나 알림에서 연락처 후보를 만들 때는 원본 맥락도 중요합니다. 기간별 SMS를 정리하고 답장해야 할 메시지를 찾는 흐름은 Android 문자 AI 요약: 기간별 SMS 정리와 답장 필요 메시지 찾기에서 이어서 볼 수 있습니다. 연락처 생성은 그 다음 단계입니다. 먼저 어떤 메시지가 저장할 가치가 있는지 고르고, 그 안의 값만 구조화해 주소록 후보로 넘기는 방식이 가장 깔끔합니다.

저장 전 정확한 일치와 가능한 일치 확인

저장 전 중복 확인은 “같은 이름이 있으면 멈춤”보다 정교해야 합니다. 가장 강한 신호는 정규화한 전화번호와 이메일의 정확한 일치입니다. 하이픈, 공백, 괄호 같은 표시 방식은 달라도 실제 번호가 같으면 같은 연락처일 가능성이 높습니다. 이메일도 대소문자나 불필요한 공백을 정리한 뒤 비교해야 합니다. 이 단계에서 정확히 맞는 기존 기록이 있으면 새 연락처 생성보다 기존 연락처에 누락된 필드를 추가하는 선택지가 먼저 떠야 합니다.

가능한 일치는 더 조심스럽게 다룹니다. 이름이 같고 회사도 비슷하지만 번호가 다를 수 있습니다. 같은 병원 대표번호를 여러 직원이 공유할 수도 있고, 가족 구성원이 집 전화번호를 함께 쓸 수도 있습니다. 반대로 이름이 다르지만 같은 이메일 별칭을 쓰는 경우도 있습니다. 우리는 FoneClaw에서 이런 후보를 “이미 같은 사람”으로 확정하기보다 사용자가 비교할 수 있는 항목으로 보여 주는 방향을 택합니다.

Android의 RawContacts API 문서는 이름, 조직, 전화, 이메일, 닉네임 변경이 연락처 재집계를 유발할 수 있음을 설명합니다. 이는 시스템이 관련 기록을 묶을 수 있다는 뜻이지만, 사람의 실제 동일성까지 완벽하게 증명하지는 않습니다. Google Contacts의 중복 연락처 병합 도움말도 사용자가 제안을 검토하고 병합하는 흐름을 제공합니다. 다른 Google 계정에 저장된 연락처는 그 병합 흐름에서 합쳐지지 않을 수 있다는 점도 계정 선택을 중요하게 만듭니다.

중복 확인의 목표는 사용자를 멈추게 하는 것이 아니라, 올바른 선택지를 제공하는 것입니다. 새 연락처 생성, 기존 연락처 업데이트, 계정 변경, 후보 취소가 한 화면에서 이해되어야 합니다. 이때 승인 화면에는 후보 필드와 일치 근거가 함께 보여야 합니다. 사용자가 왜 중복으로 의심되는지 알 수 있어야 빠르게 판단할 수 있습니다.

저장 계정, 필드, 작업을 승인 전에 검토하기

연락처는 이름과 번호만의 문제가 아닙니다. 어느 계정에 저장되는지가 나중의 검색, 동기화, 공유, 회사 기기 관리에 영향을 줍니다. 개인 Google 계정, 회사 계정, 기기 로컬 주소록, 제조사 주소록이 함께 있는 Android 휴대폰에서는 같은 사람을 어디에 저장하느냐가 실무적으로 중요합니다. 업무 연락처를 개인 계정에 저장하면 회사 기기에서는 보이지 않을 수 있고, 개인 연락처를 업무 계정에 넣으면 관리 정책의 영향을 받을 수 있습니다.

승인 전 검토 화면에는 네 가지가 필요합니다. 첫째, 저장 계정입니다. 둘째, 생성할 필드와 비어 있는 필드입니다. 셋째, 정확한 일치와 가능한 일치 목록입니다. 넷째, 이번에 수행할 작업입니다. 새 연락처를 만드는지, 기존 연락처에 이메일만 추가하는지, 후보를 취소하는지 사용자가 같은 화면에서 판단할 수 있어야 합니다. 중복 확인 결과가 나왔다고 해서 저장 작업이 자동으로 허가되는 것은 아닙니다.

FoneClaw에서 우리는 연락처 쓰기를 사용자가 이해할 수 있는 승인 작업으로 설계합니다. 이름, 번호, 이메일, 회사, 메모가 어떻게 해석됐는지 보여 주고, Android 권한이 필요한 경우 그 이유와 다음 단계를 안내합니다. 연락처 생성은 작아 보이지만 실제 주소록과 동기화 계정에 남는 쓰기 작업입니다. 그래서 작업 이유와 확인 흐름은 단순한 UX 장식이 아니라 데이터 품질을 지키는 장치입니다.

민감한 쓰기 작업에서 어떤 근거와 확인을 보여 줘야 하는지 더 깊게 보고 싶다면 AI 에이전트 승인 UX: 신뢰도, 작업 이유, 확인과 복구를 설계하는 법이 도움이 됩니다. 연락처 생성에서도 같은 원칙이 적용됩니다. 사용자는 AI가 뽑은 후보뿐 아니라, 왜 그 후보가 저장 대상인지와 어떤 결과가 남는지를 봐야 합니다.

FoneClaw로 승인된 연락처 직접 만들기

FoneClaw contacts 흐름은 다른 앱을 열어 수동 입력을 반복하는 시간을 줄이는 데 초점을 둡니다. 사용자가 원본 정보를 제공하면 FoneClaw는 연락처 후보를 구조화하고, 기존 연락처와 비교하고, 승인된 경우 Android 연락처를 직접 생성할 수 있습니다. 이 작업은 Android 권한과 사용자 확인 안에서 진행되며, 저장 후에는 실제 기록을 다시 확인하는 단계로 이어집니다.

실제 요청은 짧아도 됩니다. “이 문자에 있는 박민서 치과 상담 담당자를 연락처 후보로 만들고 중복 확인해 줘”처럼 말하면 충분합니다. FoneClaw는 문자에서 이름, 조직, 번호, 이메일, 메모 후보를 분리합니다. 기존 주소록에서 같은 번호나 이메일이 있는지 먼저 보고, 이름이나 회사가 비슷한 후보를 함께 제시합니다. 사용자는 후보를 보고 저장 계정과 필드를 고친 뒤 생성이나 취소를 결정합니다.

현재 FoneClaw는 100+ 내장 도구와 함께 연락처, 문자, 메모, 화면 맥락, 정보 확인 작업을 연결합니다. 연락처 후보의 원본이 현재 화면이나 SMS, 메모에서 왔다면 그 맥락을 유지한 채 작업을 이어 갈 수 있습니다. 지원되는 도구 범위는 변할 수 있으므로 실제 사용 전에는 FoneClaw 기능 페이지에서 현재 제공되는 Android 작업군을 확인하는 것이 좋습니다.

우리가 직접 생성 흐름을 만든 이유는 명확합니다. 연락처 앱을 열고 필드를 하나씩 입력하는 과정은 느리고, 메신저·메일·통화 기록을 오가다 보면 오타가 생기기 쉽습니다. FoneClaw는 원본 맥락을 후보 필드로 바꾸고, 중복 확인을 거쳐, 사용자가 승인한 쓰기만 수행하는 방향으로 시간을 줄입니다. 제품은 앞으로도 더 많은 전화·메시지·업무 맥락에서 “저장할 값”, “중복 가능성”, “사용자 승인”, “저장 결과”가 끊기지 않게 이어지는 쪽으로 발전하고 있습니다.

공용 번호, 국제번호, 계정이 다른 연락처 처리

중복 연락처 확인에서 가장 흔한 실수는 반복된 값이 모두 오류라고 보는 것입니다. 같은 휴대폰 번호가 두 사람에게 동시에 쓰이는 경우는 드물지만, 대표번호나 가족 번호, 매장 번호는 여러 연락처에 들어갈 수 있습니다. 병원, 학교, 부동산, 고객센터처럼 개인 이름과 공용 번호가 함께 있는 경우에는 같은 번호가 나오더라도 저장 목적을 먼저 봐야 합니다. “라움치과 박민서”와 “라움치과 접수”는 같은 번호를 공유해도 별도 연락처가 더 편할 수 있습니다.

국제번호도 조심해야 합니다. 010으로 시작하는 한국 번호와 +82 형식은 같은 번호를 다르게 표시한 것일 수 있습니다. 반대로 국가번호가 빠진 해외 번호는 사용자의 지역 설정만으로 확정하기 어렵습니다. AI는 표시 형식을 정리할 수 있지만, 실제 의도한 국가와 번호를 바꾸는 순간 연락 실패가 생깁니다. 후보 화면에는 원본 번호와 정규화한 번호를 함께 보여 주는 편이 안전합니다.

계정이 다른 연락처도 중요한 경계입니다. Google Contacts 도움말처럼 서로 다른 Google 계정에 저장된 연락처는 같은 병합 흐름에서 합쳐지지 않을 수 있습니다. 회사 계정에 이미 있는 사람을 개인 계정에 새로 저장하면 휴대폰 검색에서는 둘 다 보일 수 있지만, 웹 주소록이나 회사 기기에서는 다르게 나타날 수 있습니다. 사용자는 “업무 연락처로 저장”, “개인 연락처로 저장”, “기기 안에만 보관” 중 어떤 목적이 맞는지 결정해야 합니다.

Android 권한과 계정 경계를 더 넓게 이해하려면 AI 에이전트 샌드박스와 폰 권한: 안전한 에이전트에도 경계가 필요한 이유에서 연락처 읽기와 쓰기가 어떤 권한 구조 안에서 다뤄지는지 확인할 수 있습니다. FoneClaw는 이러한 Android 권한 흐름 안에서 작업을 진행하며, 사용자가 선택한 계정과 필드가 실제 저장 결과에 반영되는지 확인하는 방향을 유지합니다.

저장 결과 확인과 안전한 복구

연락처 생성의 마지막 단계는 성공 메시지가 아니라 실제 저장 기록입니다. 저장 후에는 정규화한 전화번호나 이메일로 주소록을 검색하고, 방금 만든 기록을 열어 이름, 번호, 이메일, 회사, 메모, 저장 계정을 확인합니다. 기존 연락처에 필드를 추가한 경우에는 새 항목이 생긴 것이 아니라 원래 연락처에 값이 들어갔는지 봐야 합니다. 같은 이름이 여러 개라면 표시 이름만 보지 말고 번호와 계정을 함께 확인합니다.

결과가 불확실할 때는 같은 요청을 바로 반복하지 않는 편이 좋습니다. 네트워크 동기화가 늦거나 주소록 앱 표시가 갱신되지 않았을 수 있고, 다른 계정에 저장됐을 수도 있습니다. 먼저 연락처 목록을 새로고침하고, 전화번호·이메일·회사명으로 각각 검색합니다. 그래도 보이지 않으면 FoneClaw의 작업 상태와 권한 안내를 확인한 뒤 다시 실행할지 결정합니다. blind retry는 같은 연락처를 두 번 만들 가능성을 높입니다.

필드가 잘못 저장됐다면 새 연락처를 하나 더 만들기보다 기존 기록을 수정하는 것이 보통 더 깨끗합니다. 번호가 틀렸다면 해당 번호만 수정하고, 회사명이 모호하면 메모에 원본 맥락을 남깁니다. 완전히 잘못된 계정에 저장했다면 삭제나 이동 가능 여부를 주소록 앱에서 확인한 뒤 처리합니다. 권한이 막혀 저장이 실패한 경우에는 AI Android 휴대폰 상태 점검: 배터리, 권한, 알림 문제 진단 런북을 참고해 연락처 접근 권한과 기기 상태를 점검할 수 있습니다.

우리가 FoneClaw에서 지향하는 연락처 생성은 빠른 입력 이상의 경험입니다. 원본에서 구조화하고, 중복 가능성을 검토하고, 계정과 필드를 승인하고, 저장 결과를 확인하는 하나의 작은 파이프라인입니다. 이 흐름이 지켜지면 AI는 주소록을 어지럽히는 자동 입력기가 아니라, 사용자가 신뢰할 수 있는 Android 연락처 작업 도우미가 됩니다.