「메모는 나중에 쓸 수 있도록 제대로 정리해서 써라」. AI 시대에 들어서며 이 조언은 오히려 더 강해진 느낌이다. 태그를 달아라, 제목을 붙여라, 나중에 AI가 읽기 쉬운 형태로 정돈해 두어라—— 그런 목소리가 지난 1년간 확실히 늘었다. 하지만 반년 정도 개인 개발로 메모 앱을 만들어 오면서, 나는 이 통설의 정반대 편에 서게 되었다. 정리해서 쓸수록, 메모는 오히려 포착되지 못하고 놓쳐버린다. 오늘은 그 결론에 도달한 이유를, 실제로 내린 구현 판단과 함께 차례대로 나열해 보고자 한다. 우선은 「정리」라는 작업 그 자체를 의심하는 것부터 시작하겠다.

메모를 정리해서 쓰라는 발상에는 생각보다 긴 역사가 있다. 1960년대에 사회학자 니클라스 루만(Niklas Luhmann)이 연마한 제텔카스텐(Zettelkasten)은 카드 한 장에 고유 번호를 부여하고, 관련 카드에 링크를 수동으로 걸어가는 방식이었다. 9만 장에 달했다고 알려진 그 카드 뭉치는 번호라는 구조가 있었기에 나중에 추적할 수 있었다. 1980년대 이후 확산된 GTD(Getting Things Done)도 비슷하다. Inbox에 던져 넣은 내용물을 먼저 「다음에 취할 행동」으로 분류한 뒤에 손을 대라고 설파했다. 1990년대 이후의 PC 폴더 문화, 그 후의 태그 문화도 모두 같은 계보 위에 있다. 정리를 촉구하는 사상은 형태를 바꾸며 60년 이상 줄곧 「먼저 분류하라」고 말해왔다. 모두 공통적으로, 쓴 직후에 분류라는 비용을 지불할 것을 요구한다.

이 방식은 당시에는 완전히 합리적이었다. 이유는 단 하나, 나중에 「찾는 것」의 비용이 매우 높았기 때문이다. 종이 카드는 전체 검색(Full-text search)을 할 수 없다. 올바른 선반에 꽂지 않은 카드 한 장은 물리적으로 두 번 다시 찾을 수 없다. 9만 장 중 한 장을 내용으로 역추적하는 방법 따위는 존재하지 않았다. 따라서 미리 정리에 들이는 노력은 미래의 검색 비용에 대한 선불로서 충분히 본전을 뽑을 수 있었다. 정리란 빈약한 검색 능력을 보완하기 위한 잘 만들어진 보험이었던 셈이다.

문제는 그 전제가 2026년에는 더 이상 성립하지 않는다는 점에 있다. 보험은 사고 확률이 낮아지면 그저 버리는 돈이 된다.

거창하게 쓰고 있지만, 반년 전의 나는 완전히 정리하는 쪽의 사람이었다. Notion에 정교한 데이터베이스를 구축하고, 메모마다 프로퍼티(Property)를 채우며, 중첩된 폴더를 성실하게 키워나갔다. 정돈되어 가는 화면은 보는 것만으로도 기분이 좋았다. 하지만 어느 날 깨닫고 말았다. 프로퍼티를 채우는 것이 귀찮아서, 애초에 메모를 열지 않게 되었다는 것을. 정리를 위해 만든 시스템이 포착(Capture) 그 자체를 조용히 막고 있었다.

결정적이었던 것은, 구축에 몇 시간이나 들인 데이터베이스를 내가 거의 검색용으로밖에 사용하지 않았다는 사실이다. 공들여 만든 뷰(View)도, 정성껏 달아둔 태그도, 돌이켜보면 거의 보지 않았다. 찾을 때는 결국 언제나 키워드로 전체 검색을 하고 있었다. 그렇게 많이 선불로 지불했던 구조의 대부분이 죽어 있었다. 그렇다면 처음부터 포착에만 집중하고, 찾는 것은 검색에 맡기면 된다. 지금 만들고 있는 앱의 설계 사상은 그 반성을 통째로 뒤집은 데서 탄생했다. 그러므로 이것은 타인에 대한 설교가 아니라, 반년 전의 나 자신에 대한 반론이기도 하다.

이제 손안의 메모는 전체 검색이 가능하다. 수천 건의 파편 속에서도 단어 하나로 좁힐 수 있고, 의미의 유사성으로 찾을 수도 있다. 모호한 기억 속에서도 「분명 그 가게 이름이었는데」라며 검색될 수 있다. 긴 글을 통째로 던져 넣으면 나중에 다시 정리하는 것도 순식간이다. 즉 「정리」라는 작업의 가격이 지난 몇 년 사이 극적으로 낮아졌다. 나중에 얼마든지 다듬을 수 있는 것을 굳이 쓰는 순간에 정리해 둘 이유는 이제 거의 남아 있지 않다.

반대로 가격이 전혀 내려가지 않은 것이 있다. 바로 포착이다. 무언가 떠오른 순간부터 그것이 손에 남기까지의 그 짧은 몇 초. 이 부분만큼은 AI가 아무리 똑똑해져도 대신해 줄 수 없다. 머릿속의 소재는 우리가 기록하기 전까지는 애초에 이 세상에 존재하지 않기 때문이다. 검색이란 「이미 존재하는 정보」를 찾는 기술이지, 「아직 쓰이지 않은 생각」은 검색의 대상조차 되지 않는다. 포착에 실패한 메모는 아무리 고성능 모델을 사용하더라도 세상 어디에서도 나오지 않는다. 처음부터 없는 것은 찾을 수 없다. 이것은 기술이 진보해도 변하지 않는 거의 유일한 제약이다.

그래서 질문을 다시 던지고 싶다. AI 시대의 메모에서 진정으로 지켜야 할 것은 나중의 정리 용이성인가, 아니면 포착의 속도와 놓치는 것이 없는 상태인가. 나의 답은 망설임 없이 후자다.

떠오른 생각의 수명은 스스로 생각하는 것보다 훨씬 짧다. 전철 승강장에서 떠오른 한 문장은 개찰구를 나갈 때쯤이면 윤곽이 흐릿해지고, 계단을 다 올라가면 이미 사라져 버린다. 무엇을 생각했는지는 기억나는데, 그 날카로움만 빠져나간다. 이 "사라지기 전에 닿을 수 있는가"가 메모 앱의 진정한 전장이다. Day4에서 앱 실행 속도를 0.3초까지 줄인 이야기를 썼지만, 그 숫자 또한 끝까지 파고들면 모두 포착(Capture)을 위한 것이었다. 실제로 내가 나중에 가장 유용하게 쓴 메모의 대부분은 책상에 앉아 쓴 것이 아니라, 걷는 도중이나 잠들기 직전, 거의 반사적으로 던져 넣은 파편들이었다. 날카로운 생각일수록 우리의 사정을 기다려주지 않는다. 사람이 "의식적으로 기다려졌다"라고 느끼는 임계값은 대략 0.5초 부근에 있다. 실행에 1초라도 기다리게 되는 시점에서, 제때 기록하지 못해 죽어버리는 메모가 확실히 발생한다.

포착을 최우선으로 두면, 데이터를 다루는 방식 자체가 바뀐다. 정리(Organization)를 위한 필드를 쓰는 순간에는 단 하나도 두지 않는 것이 오히려 정답이 된다.

// 구조를 갖지 않는다. 1메모 = 1행. 분류를 위한 칸은 마련하지 않는다.
struct Capture {
let id = UUID()
...

이 모델에는 쓰는 이에게 분류를 강요하는 부분이 단 한 곳도 없다. 폴더를 선택하는 화면도 나오지 않고, 태그 후보도 제시하지 않는다. 저장 위치를 묻는 다이얼로그도 띄우지 않는다. Day8에서 Inbox 하나로 구성된 메모 앱과 폴더를 전제로 하는 메모 앱의 차이를 썼을 때, 마지막에 맞닥뜨린 문제도 바로 이 지점이었다. 쓰기 전에 "이건 어디에 넣을까"를 아주 잠깐이라도 생각하게 만드는 순간, 포착은 늦어진다. 실제로 측정해 보면, 저장 위치를 한 번 선택하게 하는 것만으로도 쓰기 시작하기까지 2~3초의 지연이 발생한다. 그 몇 초 사이에 방금 전의 날카로운 문장은 달아나 버린다. 분류는 사고(Thinking)와는 별개의 뇌 활동이다. 포착 도중에 끼어들게 하면, 정작 중요한 내용이 부실해진다. 생각은 나중에 해도 된다. 대부분의 경우, 생각하지 않아도 된다.

여기서 반드시 돌아오는 반론이 있다. 정리하지 않고 쌓아두기만 하면, 나중에 다시 볼 수 없는 쓰레기 더미가 될 뿐이라는 것이다. 절반은 맞다. 하지만 비교 대상을 근본적으로 틀리고 있다.

비교해야 할 대상은 "정리된 메모의 더미"와 "엉망인 메모의 더미"가 아니다. "엉망으로라도 포착된 메모"와 "정리가 귀찮아서 결국 쓰지 못한 메모"다. 후자는 애초에 존재하지 않는다. 존재하지 않는 완벽한 메모는, 존재하는 엉망인 메모에게 영원히 패배한다. 정리 비용을 쓰는 순간에 부과하면, 부과받은 사람은 점점 쓰지 않게 된다. 이는 타인의 이야기가 아니라, 나 자신이 몇 번이고 관측한 사실이다. 시험 삼아 입력창에 태그 선택 단계를 딱 한 단계만 추가해 본 주가 있었다. 고작 한 단계였다. 그럼에도 그 주의 메모 건수는 전주보다 3할 정도 떨어졌다. 기능을 추가했는데 행동은 줄어들었다. 마찰(Friction)은 우리가 생각하는 것보다 훨씬 정직하게 행동을 깎아먹는다.

반대의 경험도 있다. 아무런 정리 없이 던져 넣은 한 줄의 메모가, 반년 뒤 검색을 통해 불쑥 튀어나와 멈춰 있던 업무를 움직이게 한 적이 몇 번이나 있었다. 그 한 줄은 만약 쓸 때 태그 지정이나 분류를 요구받았다면 아마 쓰이지 않았을 것이다. 포착할 수 있었기에 나중에 효과를 발휘했다. 순서는 언제나 포착이 먼저이고, 정리가 그다음이다.

게다가 정리는 나중에, 필요한 만큼만 지연시켜서 추가할 수 있다. 수백 건 중 나중에 다시 볼 가치가 정말로 있는 것은 기껏해야 몇 건뿐이다. 나머지 대부분은 다시 열리지 않은 채 흘러간다. 그래도 괜찮다. 그렇다면 그 몇 건에 대해서만, 발견한 시점에 구조를 부여하면 된다. 모든 건에 대해 미리 구조를 선불로 지불하는 것은, 평생 쓰지 않을 보험에 계속 돈을 내는 것과 비슷하다. 검색이 유효한 시대에 그런 보험은 더 이상 수지가 맞지 않는다.

또 하나, 매우 AI 시대다운 반론이 있다. 어차피 나중에 AI에게 학습시킬 거라면, 구조화된 형태로 써두는 편이 출력(Output)의 정밀도를 높이지 않겠느냐는 것이다. 그럴듯하다. 하지만 실제로 시도해 보면 종종 반대의 일이 일어난다.

지금의 언어 모델(Language Model)은 가공되지 않은 날것의 문장을 읽는 데 원래 능숙하다. 오히려 개인이 독자적으로 정한 태그 체계나 헤더(Heading) 표기법은 모델 측의 지식 프레임워크와 맞지 않아 해석을 방해하기까지 한다. 예를 들어 내가 "#나중에", "#중요"라고 분류해 온 태그는 내 안에서는 의미를 갖지만, 모델에게는 문맥이 희박한 기호일 뿐이다. "#나중에"가 마감 전인지, 언젠가 한가할 때인지 모델은 판별할 수 없다. 오히려 그 사적인 기호를 성실하게 해석하려다 요약이 왜곡되는 일조차 있다. AI에게 정말로 효과적인 것은 우리가 멋대로 정한 계층이 아니라, 사고가 끊기지 않고 끝까지 쓰였는지—즉, 포착의 완전성(Completeness)이다.

그래서 결론은 다시 같은 곳으로 돌아온다. AI에게 전달할 것을 전제로 하더라도, 우선시해야 할 것은 구조가 아니라, 놓치지 않고 전부 포착하는 것이다. 구조가 필요하다면, 전달하기 직전에 AI 스스로 구성하게 하면 된다. 실제로 나는 요약을 만들 때, 직접 붙인 태그를 오히려 지우고 전달할 때조차 있다. 가공되지 않은 문장(Raw text)일수록 모델은 더 잘 읽는다. 선불 방식을 그만두고, 주문 시 결제 방식으로 전환한다. 그런 이행이 지금 조용히 일어나고 있다.

포착 우선(Capture-first)을 진지하게 파고들다 보면, 마지막에 "애초에 손을 쓸 수 없는 상황"이 남는다. 요리 중, 걷고 있을 때, 아이를 안고 있을 때. 키보드를 칠 수 없는 상황에서는 아무리 기동(Booting)이 빨라도 포착 경로가 거기서 끊겨버린다. 이 마지막 구멍을 메우는 입력 수단으로서, v3.0에서 음성 입력을 추가했다. 마이크를 한 번 탭하고 말하면 그 자리에서 문자가 되고, 커서 위치에 그대로 삽입된다.

구현에서 가장 고민했던 것은, 음성 인식(Transcription)을 어디에서 실행할 것인가 하는 단 한 가지 점이었다. 선택지는 크게 두 가지. 클라우드의 음성 인식 API로 보내는 방식과, 단말기 내부에서 완결시키는 방식이다. 클라우드로 보내면 인식 정밀도는 높다. 하지만 요청마다 종량제 과금이 발생하고, 무엇보다 말한 목소리 자체가 단말기 밖으로 나간다. 메모라는, 가장 개인적인 것을 다루는 소재에서 후자는 하고 싶지 않았다. 비용 면에서도 까다로워서, 말한 만큼 과금된다면 길게 말할수록 무의식적인 망설임이 생긴다. 포착을 위한 도구가 사용할 때마다 지갑 사정을 걱정하게 만든다면 본말전도다.

최종적으로 Apple이 iOS 26에서 내놓은 SpeechAnalyzer / SpeechTranscriber, 즉 단말기 내부에서 동작하는 음성 인식을 택했다. 음성 인식은 단말기 내에서 완결되며, 목소리도 텍스트도 외부로 보내지 않는다. 종량제 외부 API를 일절 호출하지 않으므로, 아무리 많이 말해도 추가 비용은 제로다. 용량에 대해서도 설계가 효과적으로 작용하고 있다. 인식용 언어 모델은 앱 본체와 분리된 시스템 공유 에셋(System shared asset)으로서 단말기 측에 배치된다. 따라서 앱 자체의 용량은 늘어나지 않는다. 도입되지 않은 언어만 첫 실행 시 한 번 다운로드되는 구조다.

확정된 텍스트를 어떻게 본문으로 흘려보낼 것인가. 이 부분은 허탈할 정도로 솔직하게 작성할 수 있다.

// 확정된 음성 인식 텍스트를 현재 커서 위치에 그대로 삽입한다.
// 녹음 중에도 키보드를 내리지 않는다. 목소리와 손가락을 동시에 사용할 수 있게 한다.
func insert(_ transcript: String, into textView: UITextView) {
...

목소리로 대략적인 내용을 뱉어내고, 고유명사나 숫자만 손가락으로 수정한다. 녹음 중에도 키보드를 내리지 않기 때문에 이 병용이 가능하다. 화면에서는 파형이 목소리의 크기에 따라 움직이며, "지금 들리고 있다", "한 번 더 누르면 멈춘다"라는 것을 글자 없이도 전달한다. 전송하면 녹음은 자동으로 멈추고 본문은 클리어된다. 포착 경로가 하나 늘어났을 뿐, 쓰기 $\rightarrow$ 보내기 $\rightarrow$ 사라지기라는 앱의 문법 자체는 아무것도 바꾸지 않았다.

솔직한 트레이드오프(Trade-off)도 여기에 적어둔다. 이것은 iOS 26 이후의 대응 단말기에서만 동작한다. 조건을 만족하지 않는 단말기에서는 마이크 아이콘 자체가 표시되지 않는다. 새로운 OS와 단말기를 전제로 두었다는 것이, 단말기 내 처리(On-device processing)로 몰아붙인 대가다. 정밀도 면에서도 거대한 클라우드 모델에는 아직 미치지 못하는 장면이 있다. 말이 빠를 때의 고유명사나 전문 용어는 놓칠 때가 있다. 그럼에도 포착을 위한 입력 수단으로서는 '외부로 나가지 않는다', '과금되지 않는다', '용량이 늘어나지 않는다'라는 이 세 가지 점을 정밀도의 미세한 차이보다 상위에 두었다. 버리는 기준이 일관되어 있다면 망설임은 적다.

여기까지 읽으면 포착 우선 방식이 좋은 점만 가득해 보일지도 모른다. 아니다. 이것은 명확한 "버리기"의 선택이다. 트레이드오프를 적지 않고 이점만 나열하는 것은 공정하지 않다.

버린 것은 세 가지다. 첫째, 작성 직후의 정리 용이성. Inbox 하나뿐이므로 작성하는 순간 "이것은 업무, 이것은 개인 용도"라고 분류하는 그 작은 성취감은 없다. 둘째, 폴더라는 안심감. 정돈되어 있다, 관리되고 있다는 감각을 사용자로부터 직접 빼앗아 가고 있다. 내용물이 비어 있더라도 정연하게 나열된 빈 폴더에는 묘한 안심감이 있다. 그것을 내놓지 않기로 결정했다. 셋째, 구조 그 자체를 셀링 포인트로 삼는 길. 태그나 링크, 계층을 기능으로서 전면에 내세우는 다른 메모 앱들과 같은 운동장에서 싸우지 않기로 결정했다. 비교표의 기능란은 이쪽이 확실히 짧아질 것이다. 짧다는 것을 약점이 아닌 주장으로 만들었다. 기능의 많음으로 안심시키기보다, 기능의 적음으로 속도를 약속하는 쪽을 택했다는 뜻이다.

그 대신에, 모든 것을 「나중에 찾아낼 수 있음」에 걸고 있다. 포착만큼은 절대 놓치지 않는다, 정리는 찾아보는 쪽(검색하는 쪽)에 맡긴다, 라는 도박이다. 도박인 이상, 빗나가는 사람도 있다. 구조를 자신의 손으로 구축하는, 그 행위 자체가 사고가 되는 사람에게 이 앱은 확실히 부족할 것이다. Zettelkasten (제텔카스텐)에서 카드를 연결하는 행위 자체가 쾌감인 사람도 있다. 그것을 부정하지는 않는다. 다만, 그런 사람을 위해 앱을 정돈하는 순간, 포착의 속도는 다시 느려진다. 무언가를 날카롭게 만든다는 것은, 다른 무언가를 명확히 포기하는 것이다. 포기하지 않는 도구는 대개 아무것도 날카롭지 않다.

이 설계에도 명확히 패배하는 장면이 있다. 자신의 주장을 지키기 위해서라도 그 부분은 솔직하게 써두고 싶다. 포착 우선주의가 성립하기 위한 대전제는, 「나중에 찾아본다」는 습관이 찾아보는 쪽에 있다는 것이다. 한 번도 검색을 하지 않고, 되돌아보지도 않는 사람에게 잡다하게 쌓인 더미는 그저 무덤이 될 뿐이다. 포착만 하고 찾아보지 않는다면, 정리하지 않는 만큼 정말로 쓰레기만 늘어날 뿐이다. 이 경우에 한해서는 최초의 반론이 더 옳다.

또 하나, 구조가 내용과 불가분한 영역에서는 이 전제가 무너진다. 예를 들어 소스 코드나, 장(章) 구성 자체가 의미를 갖는 계약서는 포착한 이후의 정형화가 아니라, 쓰는 시점의 구조 그 자체가 가치다. 그런 것은 전용 도구를 사용하여 구조째로 써야 한다. 메모 앱이 맡는 것은 어디까지나 「구조를 뒤로 미룰 수 있는 종류의 사고」 —— 아이디어, 메모, 말하려던 것, 감정의 파편이다. 그 경계를 모호하게 하면, 포착 우선주의는 그저 어질러진 창고로 전락한다. 나의 경우, 코드는 에디터(Editor)로, 긴 설계 검토는 문서 도구로, 처음부터 목적지를 나누어 두었다. 메모 앱에 흘려보내는 것은 목적지가 결정되기 전의, 아직 형태를 갖추지 못한 사고뿐이다.

그래서 나는 메모 앱에 「전부」를 맡기지 않는다. 찾아보는 습관과 영역의 경계. 이 두 가지가 있어야 비로소 포착 우선주의는 기능한다. 만능이라고 말하는 순간, 이 설계는 거짓이 된다. 날카로운 도구는 효력이 미치는 범위가 좁다. 그것을 인정하는 것이 아마 가장 페어(Fair)한 판매 방식일 것이다.

생각을 바꾸기 위해 앱을 갈아탈 필요는 없다. 지금 손에 있는 도구 그대로 두 가지만 시도해 볼 수 있다.

• 일주일 동안, 떠오른 메모를 분류하지 않고 모아본다. 태그(Tag)도 제목도 붙이지 않고, 한 줄로 던져 넣기만 한다. 주말에 건수가 늘어났는지 아닌지만 확인한다.
• 정리는 나중에 다시 본 몇 건에 대해서만 수행한다. 처음부터 모든 건을 정리하려 하지 않는다. 나머지는 검색에 맡긴다.

포착을 늘리면 처음에는 잡다한 더미가 자라나 불안해진다. 정리되어 있지 않다는 불안함이 있다. 하지만 검색을 한 번 해보면, 그 더미가 생각보다 훨씬 쓸모 있다는 것을 아마 깨닫게 될 것이다. 깔끔하게 정리해서 쓴 메모보다, 잡다하게라도 잡아두었던 메모가 결국 더 잘 남는다 —— 반년 동안 만들어오며 내가 가장 깔끔하게 배신당하며 얻은 결론이 이것이었다. 정리는 미래의 자신을 향한 배려라고 생각했지만, 사실은 현재의 내 손을 멈추게 하고 있었다. AI 시대의 메모에서 가장 먼저 물어야 할 것은 어떻게 정리할 것인가가 아니라, 어디까지 놓치지 않고 포착할 수 있는가 하는 점이다. 정리는 그 한참 뒤에 해도 괜찮다. 제때 하지 못한 생각은 두 번 다시 정리의 대상조차 되지 않으니까.

• Apple — Speech framework (SpeechAnalyzer / SpeechTranscriber 공식 문서): https://developer.apple.com/documentation/speech - 자신의 앱에서 채택한 음성 입력 동작 사양 (온디바이스 처리와 iOS 26 요구사항 정리): https://simplememofast.com/voice-input/
• 관련 과거 기사: Day8 Inbox 한 권과 폴더 전제의 차이 ／ Day4 구동 속도 0.3초를 줄인 이야기

Obsidian 연동 심플 메모

Swift와 Apple 순정 프레임워크만으로 만들었다. 외부 라이브러리는 넣지 않았다. 구동 속도 0.3초, 포착에만 몰두한 메모 앱.

App Store: https://apps.apple.com/jp/app/captio%E5%BC%8F%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%83%A1%E3%83%A2/id6749649498