목록으로
생활 속 AI 활용
카카오톡에 쌓이기만 하던 링크·사진·PDF·파일들을 정리하기 위해 AI로 무한 캔버스 앱 LinkScape를 직접 개발한 사례
AI로 카톡방에 쌓이는 링크·PDF·문서 파일들을 무한 캔버스에 저장하고 분류하는 웹 서비스,브라우저 확장앱, 데스크톱 앱 LinkScape를 만들었습니다.
🤖 활용 AI 도구
Claude
1. 어떤 상황에서 AI를 활용했나요?
저는 원하는 자료를 잠시 저장하거나 누군가에게 보낼 링크를 둘 공간으로 카카오톡의 나와의 채팅방을 사용했습니다. 하지만 사진, 링크, PDF 등을 포함한 문서 파일들을 나와의 채팅방에 던져두듯이 하는 습관이 있었습니다. 즉, 기사 링크, 참고할 웹페이지, 업무용 PDF, 대학교에서 받은 한글 파일까지 전부 그 대화방에 들어갔습니다. 문제는 점차 쌓이기 시작했다는 것입니다. 쌓이다 보니 양도 많아지고, 정작 원하는 것을 찾으려고 할 때는 위로 무한정 스크롤을 해야 하는 불편함이 있었습니다. 한 달만 지나면 스크롤을 아무리 올려도 그때 그 자료를 찾을 수 없었고, 결국 같은 자료를 다시 검색하는 일이 반복됐습니다. 브라우저 북마크도 마찬가지였습니다. 폴더를 먼저 만들고 이름을 정해야 저장이 되는데, 그것도 귀찮을 뿐더러 북마크 폴더도 많이 쌓이기 때문에 내가 찾고자 하는 것이 어느 폴더에 있는지 찾기 어려울 때도 있었습니다.
기존 도구를 안 써본 것은 아닙니다. 기존에 있는 FigJam은 무한 캔버스라는 방향은 맞았지만 워드나 한글 문서를 올려도 내용을 볼 수 없었고, 협업 화이트보드로 만들어진 도구라 개인 자료를 쌓아두는 용도로 쓰기엔 실행 자체가 무거웠습니다. 노션은 파일을 넣을 수는 있었지만 문서 안에 목록으로 쌓이는 구조라 자료가 늘어날수록 스크롤을 계속 내려야 했고, 무엇이 어디에 있는지 한눈에 파악되지 않았습니다. 두 도구 모두 켜는 데 노트북으로는 시간이 걸린다는 점이 결정적이었습니다. 자료를 담아놔도 정작 키는 데 시간이 걸리면 많이 안 쓰게 된다고 느꼈습니다.
그래서 '위치 자체가 분류가 되는', '한눈에 다 보이는' 도구를 직접 만들고 싶었습니다. 저는 개발 전공자는 아니지만 웹사이트 코딩을 따로 공부한 적이 있어서, HTML·CSS·자바스크립트,React 등으로 짜인 코드를 읽고 대략 무슨 뜻인지 이해하는 정도는 할 수 있었습니다. 문제는 그 이상이었습니다. 여러 사용자의 데이터가 서로 보이지 않도록 막는 데이터베이스 보안 설정, 브라우저 확장 프로그램의 규격, 윈도우 데스크톱 앱을 만드는 Rust 언어는 이름만 아는 수준이었습니다. 혼자였다면 아이디어 단계에서 멈췄을 것이고, 이 지점에서 AI를 사용하기로 했습니다.
2. 어떤 AI를 어떻게 활용했나요?
Anthropic의 Claude Code를 사용했습니다. 채팅창에 코드를 물어보고 복사해 붙여넣는 방식이 아니라, 제 PC의 폴더에 직접 접근해서 파일을 읽고, 수정하고, 명령어를 실행하고, 브라우저를 띄워 결과를 확인하는 AI 코딩 에이전트입니다. 저는 한국어로 원하는 것을 설명하고, AI가 실제 작업을 수행하는 구조로 진행했습니다.
AI가 담당한 범위는 다음과 같습니다. 웹은 Next.js와 React Flow로 무한 캔버스를 구현했고, 백엔드는 Supabase의 데이터베이스·로그인·파일 저장소·실시간 동기화를 붙였습니다. 여기에 웨일과 크롬에서 쓰는 브라우저 확장 프로그램을 별도로 만들었고, 추후에 배포할 예정인 안드로이드 앱은 Capacitor로, 윈도우 데스크톱 앱은 Rust 기반의 Tauri로 만들었습니다. 데이터베이스 보안 정책(Row Level Security)과 비공개 저장소 서명 URL 같은, 제가 혼자였으면 손도 못 댔을 부분도 AI가 설계하고 저에게 왜 그렇게 해야 하는지 설명해 주었습니다.
다만 중요한 것은 '그냥 만들어달라고 시키지는 않았다'는 점입니다. 저는 네 가지 방식으로 AI를 다뤘습니다.
첫째, 구현 전에 반드시 기획서를 먼저 쓰게 했습니다. 곧바로 "만들어줘"라고 하면 AI는 빠진 정보를 자기 마음대로 해석해서 만들어버리고, 저는 결과물이 다 나온 뒤에야 방향이 다르다는 것을 알게 됩니다. 그래서 새로운 기능을 시작할 때마다 코드는 한 줄도 만들지 말고 `plan.md`라는 기획 문서부터 쓰게 했습니다. 이 문서에는 해결하려는 문제와 배경, 이번에 만들 것과 만들지 않을 것, 기능별 상세 동작, 기술 선택의 이유와 대안, 폴더 구조, 데이터 설계, 화면 흐름, 구현 순서, 보안 처리, 배포 절차, 예상되는 난관까지 담기게 했습니다. 특히 중요한 항목이 맨 마지막의 '확인 필요 사항'이었습니다. AI가 모르는 부분을 임의로 정해버리지 말고 질문으로 남기게 한 것인데, 저는 그 질문에 답하는 방식으로 방향을 잡았습니다. 이 단계에서 설계를 여러 번 갈아엎었지만 아직 코드가 없는 상태라 손해가 없었습니다. 기획이 확정된 뒤에야 구현에 들어갔습니다.
둘째, 대화가 바뀌어도 맥락이 이어지도록 인수인계 문서를 남겼습니다. AI와의 대화는 한 채팅방에서 주고받는 양이 한계에 다다르면 앞부분을 잊거나 일을 효과적으로 수행하지 못합니다. 그래서 하나의 작업이 끝날 때마다 AI에게 현재 구조와 진행 상황을 `HANDOVER.md`로 정리시켰고, 다음 새 채팅을 시작할 때 그 문서부터 읽게 했습니다. 이 문서에서 가장 쓸모 있었던 부분은 '해결한 주요 문제' 표입니다. 한 번 고생해서 해결한 문제와 그 원인을 전부 기록해 두었습니다. 예를 들어 한글 파일 뷰어 라이브러리가 빌드 최적화 과정에서만 깨져 개발 중에는 멀쩡하다가 배포하면 실패했던 문제, 문서 미리보기 창 안을 클릭하면 브라우저 보안 정책 때문에 ESC 키가 부모 창에 아예 전달되지 않던 문제 같은 것들입니다. 여기에 더해 '반드시 유지할 조건' 항목에는 데이터 저장은 정해진 한 경로로만 한다, 데이터베이스에 직접 쓰지 않는다, 카드 색은 배경이 아니라 테두리로만 표시한다 같은 원칙이 쌓였습니다. 제가 처음부터 규칙집을 써둔 것이 아니라, 작업하면서 정해진 원칙을 AI가 문서에 계속 축적하게 만든 것입니다.
셋째, 이 두 가지를 매번 길게 설명하는 대신 아예 명령어로 만들었습니다. Claude Code는 사용자가 직접 슬래시 명령어(스킬)를 만들어 쓸 수 있는데, 저는 `/plan`과 `/handover` 두 개를 직접 작성했습니다. `/plan` 안에는 기획서에 들어갈 12개 항목의 목차뿐 아니라 "이번 턴에서는 코드 파일을 절대 만들지 않는다", "추측으로 사실을 지어내지 않고 확인되지 않은 것은 물음표 표시로 남긴다", "구현 1단계는 항상 가장 작게 동작하는 것부터 잡는다" 같은 규칙을 명시해 두었습니다. `/handover` 안에는 "기존 문서를 지우고 새로 쓰지 말고 이어받아 갱신한다", "해결된 문제는 남은 오류 목록에서 빼서 해결한 문제로 옮긴다", "API 키 같은 비밀값은 값 자체를 절대 적지 말고 변수명과 용도만 적는다" 같은 조건을 넣었습니다. 이렇게 만들어 두니 매번 "이런 형식으로 계획서를 써줘"를 길게 반복 설명할 필요 없이 `/plan` 한 줄이면 됐고, 결과물의 형식과 품질이 매번 일정하게 유지됐습니다. AI를 쓰는 데서 한 걸음 나아가, AI를 쓰는 방식 자체를 도구로 만든 셈입니다. 나중에는 크롬 웹스토어 등록 서류를 작성하는 명령어도 같은 방식으로 만들어 썼습니다.
넷째, 되돌릴 수 있는 상태를 계속 유지하면서 검증했습니다. AI는 한 번에 여러 파일을 동시에 고치기 때문에, 뭔가 잘못됐을 때 어디서부터 틀어졌는지 알기 어렵습니다. 그래서 의미 있는 작업 단위가 끝날 때마다 GitHub에 커밋하고 푸시하도록 했고, 13일 동안 56번의 커밋이 쌓였습니다. 덕분에 잘못된 방향으로 갔을 때 직전 커밋으로 되돌릴 수 있었고, AI에게 "이 커밋 이후로 이 기능이 안 된다"처럼 범위를 좁혀 말할 수도 있었습니다. 커밋하기 전에는 타입 검사, 문법 검사, 빌드, 그리고 헤드리스 브라우저 자동 테스트까지 4가지를 반드시 통과하도록 규칙을 정했습니다. 특히 마지막 자동 테스트는 AI가 실제로 브라우저를 띄워 로그인하고, 링크를 담고, 데이터베이스에 정말 저장됐는지 조회해서 확인하는 스크립트입니다. AI가 만든 것을 AI가 직접 확인하게 만든 셈입니다. 웹은 GitHub에 푸시하면 Vercel이 자동으로 배포하도록 연결해 두어서, 검증을 통과한 커밋이 곧바로 실제 서비스에 반영됐습니다.
3. 활용 결과 어떤 변화가 있었나요?
먼저 결과물의 규모입니다. 2026년 7월 13일에 시작해 7월 25일까지 13일에 걸쳐 진행했고, 실제로 작업한 날은 8일이었습니다. 그마저도 하루를 통째로 비워서 매달린 것이 아니라 일과 사이에 남는 자투리 시간에 조금씩 한 것입니다. 그렇게 총 56회를 GitHub에 커밋했고, 웹 애플리케이션 7,405줄(53개 파일), 브라우저 확장 프로그램 2,320줄, 윈도우 데스크톱 앱 105줄, 데이터베이스 설계 273줄로 약 1만 줄 규모의 서비스가 만들어졌습니다. 현재 웹은 Vercel에 배포되어 실제로 동작 중이고, 브라우저 확장·안드로이드 앱·윈도우 데스크톱 앱까지 4개 플랫폼이 하나의 캔버스를 공유합니다. 혼자였다면 몇 달을 잡아도 첫 번째 화면조차 못 만들었을 범위입니다.
기술적으로 확인된 수치도 있습니다. 윈도우 데스크톱 앱은 실행 파일 3.43MB, 설치 파일 1.26MB입니다. 같은 기능을 흔히 쓰는 Electron으로 만들면 150MB가 넘습니다. 또한 창을 닫으면 브라우저 엔진을 통째로 해제하도록 설계해서, 트레이에 상주할 때 메모리 사용량이 513MB에서 42MB로 92% 줄어드는 것을 실측했습니다.
실제 사용 습관은 이렇게 바뀌었습니다. 자료를 만나면 그 자리에서 우클릭 한 번으로 담습니다. 혹은 확장앱을 켜 '현재 탭 담기' 버튼을 누르거나, 파일 탐색기에서 확장앱의 드래그 드롭존으로 끌어다 바로 넣을 수도 있습니다. 링크, 이미지, 드래그한 텍스트, 현재 페이지 전체를 각각 담을 수 있고, 아무 페이지에서나 파일을 끌기 시작하면 화면 오른쪽 아래에 받는 영역이 나타납니다. 담는 순간 이미 열려 있는 캔버스에 새로고침 없이 카드가 나타납니다. 정리는 나중에 캔버스에서 카드를 옮기는 것으로 끝납니다. 폴더 이름을 정할 필요도, 태그를 입력할 필요도 없습니다.
찾는 방식도 달라졌습니다. PDF는 브라우저에서 본문 텍스트를 추출해 두기 때문에, 제목이 기억나지 않아도 문서 안에 있던 단어로 검색하면 나옵니다. 한글 파일은 프로그램을 켜지 않고 브라우저 안에서 바로 열립니다. Ctrl+K를 누르거나 메뉴바에서 검색을 이용해 파일을 찾아볼 수도 있습니다. 무엇보다 "그 자료 어디 뒀더라"가 "화면 왼쪽 위 그 근처에 뒀지"로 바뀌었습니다. 위치는 사람이 잘 기억하는 정보입니다.
4. 나만의 방식 또는 개선 포인트는 무엇인가요?
크게 서비스 자체의 차별점과 AI를 다루는 방식의 차별점으로 나눌 수 있습니다.
먼저 서비스 쪽입니다. 링크와 파일을 올릴 수 있는 도구는 이미 여럿 있지만, 각각 명확한 한계가 있었고 그 지점을 겨냥했습니다.
FigJam이나 Miro 같은 화이트보드 도구는 무한 캔버스라는 형태는 같습니다. 그러나 워드나 한글 문서를 올려도 파일 조각으로만 남아 내용을 볼 수 없고, 여러 명이 동시에 편집하는 협업 도구로 설계되어 있어 혼자 자료를 모아두는 용도로는 실행 자체가 무겁습니다. 노션은 파일 첨부는 되지만 결국 문서 안의 목록 구조여서, 자료가 쌓일수록 한눈에 들어오지 않고 스크롤에 의존하게 됩니다. 두 도구 모두 켜는 데 걸리는 시간이 길다는 점이 실사용에서는 치명적이었습니다. 담는 행위에 마찰이 생기면 사람은 담지 않습니다. 브라우저 기본 북마크는 폴더 계층을 먼저 정해야 저장이 되고, 국내에 나온 유사 앱들은 모바일 앱 중심이라 정작 자료를 가장 많이 만나는 PC 브라우징 중에는 담을 방법이 없습니다.
LinkScape가 다르게 택한 지점은 네 가지입니다.
첫째, 담는 지점을 브라우저 안에 두었습니다. 링크와 자료를 실제로 만나는 장소는 PC 브라우저입니다. 그래서 웹 서비스와 함께 브라우저 확장 프로그램을 같이 만들었고, 우클릭 메뉴 4종·확장앱 팝업 화면에 붙여넣기·페이지 안에서 드래그로 우측 하단의 드롭 영역에 넣기 등 세 가지 경로로 어디서든 즉시 담기게 했습니다. 모바일 앱만 있는 서비스로는 대체할 수 없는 부분입니다.
둘째, 한국 문서 환경을 정면으로 다뤘습니다. 한글(.hwp) 파일을 별도 프로그램 없이 브라우저 안에서 직접 렌더링합니다. 처음에는 웨일 브라우저 내장 뷰어에 의존하는 방식이었는데 크롬과 엣지에서는 빈 화면이 떠서, 한글 파일을 자바스크립트로 직접 해석하는 라이브러리를 서비스에 포함시켜 브라우저 종류와 무관하게 열리도록 바꿨습니다. 워드·엑셀·파워포인트도 앱 안에서 바로 보이고, PDF는 본문 텍스트까지 검색됩니다.
셋째, 가볍게 유지했습니다. 서버에서 도는 기능은 링크 미리보기 정보를 가져오는 것 하나뿐이고, PDF 해석·썸네일 생성·손글씨 처리는 전부 사용자 브라우저에서 처리합니다. 서버 부담이 없으니 빠르고 비용도 들지 않습니다. 데스크톱 앱도 Electron 대신 Tauri를 골라 3.43MB로 만들었습니다.
넷째, 정리를 강요하지 않습니다. 개발 중에 태그 입력 기능을 만들었다가 일부러 제거했습니다. 입력해야 할 것이 하나라도 있으면 담는 속도가 느려지기 때문입니다. 분류는 캔버스 위 위치와 카드 테두리 색만으로 합니다. 카드를 그룹 영역 안으로 끌어넣으면 그룹이 자동으로 늘어나고, 빼면 다시 줄어들어서 무엇이 어디에 속하는지 눈으로 바로 보입니다.
다음은 AI를 다루는 방식입니다. 이 부분이 실질적인 개선 포인트라고 생각합니다.
가장 큰 차이는 '만들기 전에 기획을 끝낸다'였습니다. AI에게 바로 "만들어줘"라고 하면 결과물이 빨리 나오기 때문에 잘 되고 있다고 착각하기 쉽습니다. 그런데 그렇게 만든 것은 제가 머릿속에 그린 것과 조금씩 어긋나 있고, 어긋난 채로 그 위에 기능이 계속 쌓입니다. 그래서 저는 항상 기획 문서를 먼저 쓰게 하고, 그 문서를 읽으면서 AI가 임의로 가정한 부분과 저에게 물어야 할 부분을 확인한 다음에야 구현을 허락했습니다. 코드가 없는 상태에서 방향을 바꾸는 것은 공짜지만, 만들고 나서 바꾸는 것은 비쌉니다.
두 번째는 반복되는 지시를 명령어로 만든 것입니다. 처음에는 기획서를 요청할 때마다 "이런 항목을 넣고, 확인 필요한 건 따로 표시하고, 코드는 아직 만들지 말고"를 매번 길게 설명했습니다. 이게 반복되니 어떤 날은 설명을 빠뜨려서 AI가 곧바로 코드를 만들어버리는 일도 생겼습니다. 그래서 그 지시 내용을 통째로 `/plan`이라는 명령어로 만들어 저장했습니다. 인수인계 문서를 남기는 `/handover`도 같은 이유로 만들었습니다. 이렇게 하니 제 지시의 품질이 그날의 기억력에 좌우되지 않게 됐습니다. AI 활용에서 흔히 놓치는 부분이 여기라고 생각합니다. 좋은 프롬프트를 한 번 찾아내는 것보다, 그것을 매번 똑같이 재사용할 수 있는 형태로 만들어 두는 것이 결과를 훨씬 크게 바꿨습니다.
세 번째는 AI의 말을 믿지 않고 실행 결과를 믿게 만든 것입니다. AI는 틀린 답을 확신에 찬 말투로 합니다. 그래서 "됐습니다"라는 말 대신, 브라우저를 실제로 띄워 로그인하고 클릭하고 데이터베이스를 조회해서 확인하는 자동 테스트를 매 작업마다 만들게 했습니다. 이 과정에서 겉보기엔 멀쩡한데 실제로는 동작하지 않던 문제를 여러 번 잡았습니다. 문서 미리보기를 열어둔 상태에서 Delete 키를 누르면 뒤에 선택돼 있던 카드가 조용히 삭제되던 문제가 대표적인데, 눈으로만 확인했다면 한참 뒤에나 발견했을 문제입니다. 여기에 GitHub 커밋을 작업 단위마다 남긴 것이 더해져서, 문제가 생겨도 항상 되돌아갈 지점이 있었습니다.
5. 다른 사람도 따라 할 수 있나요?
가능합니다. 필요한 것은 PC 한 대, AI 코딩 도구, 그리고 무료로 시작할 수 있는 GitHub·Supabase·Vercel 계정뿐입니다. 저는 지금까지 서버 비용을 한 푼도 내지 않았습니다. 전공 수준의 지식도 필요하지 않았습니다. 다만 솔직히 말하면, 코드를 직접 짜지는 못해도 읽고 대략 이해할 수 있는 정도는 도움이 됐습니다. AI가 엉뚱한 방향으로 갈 때 알아채는 속도가 달라지기 때문입니다. 그 정도는 무료 강의로도 충분히 닿는 수준이고, 없어도 시작은 할 수 있습니다. 대신 몇 가지 순서를 지키는 것이 중요했습니다.
첫째, 남이 쓸 것 같은 아이디어가 아니라 내가 매일 겪는 불편을 고르는 것입니다. 저는 카톡에 쌓인 링크를 못 찾는 것이 실제로 매주 겪는 일이었기 때문에, 무엇이 불편한지 AI에게 정확히 설명할 수 있었고 만든 것이 쓸 만한지도 바로 판단할 수 있었습니다. 관심 없는 주제를 골랐다면 중간에 멈췄을 것입니다.
둘째, 바로 만들어달라고 하지 말고 기획서부터 쓰게 하는 것입니다. "코드는 아직 만들지 말고, 무엇을 어떻게 만들 것인지 계획 문서부터 써줘. 네가 임의로 가정한 부분과 나에게 물어봐야 할 부분을 따로 표시해줘"라고 요청하면 됩니다. 그 문서를 읽고 방향을 잡은 다음에 구현을 시작하면, 만들고 나서 갈아엎는 일이 크게 줄어듭니다.
셋째, 첫 목표는 가장 작게 잡는 것입니다. 저의 첫 목표는 '링크를 붙여넣으면 화면에 카드가 하나 생긴다'였습니다. 처음부터 완성형을 설명하면 AI가 만든 것이 맞는지 판단할 수 없습니다. 작게 시작해서 되는 것을 확인하고 그 위에 쌓아야 합니다.
넷째, 작업 단위마다 GitHub에 커밋하는 것입니다. AI는 한 번에 여러 파일을 고치기 때문에, 되돌릴 지점이 없으면 문제가 생겼을 때 손을 쓸 수가 없습니다. 명령어를 몰라도 "지금까지 작업한 것을 커밋하고 푸시해줘"라고 하면 AI가 대신 해줍니다.
다섯째, 사람이 눈으로 확인하는 대신 확인 절차를 AI에게 만들게 하는 것입니다. "이 기능이 정말 동작하는지 브라우저를 띄워서 확인하는 스크립트를 만들고 실행해 줘"라고 요구하면 됩니다. 처음에는 번거롭지만, 이것 없이는 무엇이 언제부터 망가졌는지 나중에 절대 찾지 못합니다.
여섯째, 하루가 끝날 때 혹은 새 채팅으로 넘어가야 할 때, 현재 채팅방에서 AI에게 지금까지 한 일과 다음에 할 일을 문서로 정리시키는 것입니다. 다음에 그 문서부터 읽히면 대화가 끊겨도 이어서 작업할 수 있습니다.
마지막으로, 위의 요청들 중 반복되는 것은 명령어로 만들어 두기를 권합니다. 저는 기획서 작성과 인수인계 문서 작성을 각각 `/plan`과 `/handover`라는 명령어로 만들어 두고 13일 내내 그것만 입력했습니다. 만드는 방법도 어렵지 않습니다. 평소에 AI에게 길게 설명하던 지시 내용을 그대로 텍스트 파일로 저장하면 됩니다. 이것만 해도 매번 같은 설명을 반복하는 시간이 사라지고, 무엇보다 지시를 빠뜨려서 생기는 실수가 없어집니다.
주의할 점도 있습니다. AI는 확신에 찬 말투로 틀립니다. 특히 "완료했습니다", "정상 동작합니다"라는 답변은 실제 실행 결과가 아니라 예상인 경우가 있습니다. 반드시 실행해서 확인하고 넘어가야 하고, 이 습관 하나가 있고 없고에 따라 결과물이 완전히 달라집니다. 저도 처음에는 AI 말을 그대로 믿고 넘어갔다가, 배포하고 나서야 특정 브라우저에서 한글 파일이 안 열린다는 것을 알게 된 적이 있습니다.
저는 원하는 자료를 잠시 저장하거나 누군가에게 보낼 링크를 둘 공간으로 카카오톡의 나와의 채팅방을 사용했습니다. 하지만 사진, 링크, PDF 등을 포함한 문서 파일들을 나와의 채팅방에 던져두듯이 하는 습관이 있었습니다. 즉, 기사 링크, 참고할 웹페이지, 업무용 PDF, 대학교에서 받은 한글 파일까지 전부 그 대화방에 들어갔습니다. 문제는 점차 쌓이기 시작했다는 것입니다. 쌓이다 보니 양도 많아지고, 정작 원하는 것을 찾으려고 할 때는 위로 무한정 스크롤을 해야 하는 불편함이 있었습니다. 한 달만 지나면 스크롤을 아무리 올려도 그때 그 자료를 찾을 수 없었고, 결국 같은 자료를 다시 검색하는 일이 반복됐습니다. 브라우저 북마크도 마찬가지였습니다. 폴더를 먼저 만들고 이름을 정해야 저장이 되는데, 그것도 귀찮을 뿐더러 북마크 폴더도 많이 쌓이기 때문에 내가 찾고자 하는 것이 어느 폴더에 있는지 찾기 어려울 때도 있었습니다.
기존 도구를 안 써본 것은 아닙니다. 기존에 있는 FigJam은 무한 캔버스라는 방향은 맞았지만 워드나 한글 문서를 올려도 내용을 볼 수 없었고, 협업 화이트보드로 만들어진 도구라 개인 자료를 쌓아두는 용도로 쓰기엔 실행 자체가 무거웠습니다. 노션은 파일을 넣을 수는 있었지만 문서 안에 목록으로 쌓이는 구조라 자료가 늘어날수록 스크롤을 계속 내려야 했고, 무엇이 어디에 있는지 한눈에 파악되지 않았습니다. 두 도구 모두 켜는 데 노트북으로는 시간이 걸린다는 점이 결정적이었습니다. 자료를 담아놔도 정작 키는 데 시간이 걸리면 많이 안 쓰게 된다고 느꼈습니다.
그래서 '위치 자체가 분류가 되는', '한눈에 다 보이는' 도구를 직접 만들고 싶었습니다. 저는 개발 전공자는 아니지만 웹사이트 코딩을 따로 공부한 적이 있어서, HTML·CSS·자바스크립트,React 등으로 짜인 코드를 읽고 대략 무슨 뜻인지 이해하는 정도는 할 수 있었습니다. 문제는 그 이상이었습니다. 여러 사용자의 데이터가 서로 보이지 않도록 막는 데이터베이스 보안 설정, 브라우저 확장 프로그램의 규격, 윈도우 데스크톱 앱을 만드는 Rust 언어는 이름만 아는 수준이었습니다. 혼자였다면 아이디어 단계에서 멈췄을 것이고, 이 지점에서 AI를 사용하기로 했습니다.
2. 어떤 AI를 어떻게 활용했나요?
Anthropic의 Claude Code를 사용했습니다. 채팅창에 코드를 물어보고 복사해 붙여넣는 방식이 아니라, 제 PC의 폴더에 직접 접근해서 파일을 읽고, 수정하고, 명령어를 실행하고, 브라우저를 띄워 결과를 확인하는 AI 코딩 에이전트입니다. 저는 한국어로 원하는 것을 설명하고, AI가 실제 작업을 수행하는 구조로 진행했습니다.
AI가 담당한 범위는 다음과 같습니다. 웹은 Next.js와 React Flow로 무한 캔버스를 구현했고, 백엔드는 Supabase의 데이터베이스·로그인·파일 저장소·실시간 동기화를 붙였습니다. 여기에 웨일과 크롬에서 쓰는 브라우저 확장 프로그램을 별도로 만들었고, 추후에 배포할 예정인 안드로이드 앱은 Capacitor로, 윈도우 데스크톱 앱은 Rust 기반의 Tauri로 만들었습니다. 데이터베이스 보안 정책(Row Level Security)과 비공개 저장소 서명 URL 같은, 제가 혼자였으면 손도 못 댔을 부분도 AI가 설계하고 저에게 왜 그렇게 해야 하는지 설명해 주었습니다.
다만 중요한 것은 '그냥 만들어달라고 시키지는 않았다'는 점입니다. 저는 네 가지 방식으로 AI를 다뤘습니다.
첫째, 구현 전에 반드시 기획서를 먼저 쓰게 했습니다. 곧바로 "만들어줘"라고 하면 AI는 빠진 정보를 자기 마음대로 해석해서 만들어버리고, 저는 결과물이 다 나온 뒤에야 방향이 다르다는 것을 알게 됩니다. 그래서 새로운 기능을 시작할 때마다 코드는 한 줄도 만들지 말고 `plan.md`라는 기획 문서부터 쓰게 했습니다. 이 문서에는 해결하려는 문제와 배경, 이번에 만들 것과 만들지 않을 것, 기능별 상세 동작, 기술 선택의 이유와 대안, 폴더 구조, 데이터 설계, 화면 흐름, 구현 순서, 보안 처리, 배포 절차, 예상되는 난관까지 담기게 했습니다. 특히 중요한 항목이 맨 마지막의 '확인 필요 사항'이었습니다. AI가 모르는 부분을 임의로 정해버리지 말고 질문으로 남기게 한 것인데, 저는 그 질문에 답하는 방식으로 방향을 잡았습니다. 이 단계에서 설계를 여러 번 갈아엎었지만 아직 코드가 없는 상태라 손해가 없었습니다. 기획이 확정된 뒤에야 구현에 들어갔습니다.
둘째, 대화가 바뀌어도 맥락이 이어지도록 인수인계 문서를 남겼습니다. AI와의 대화는 한 채팅방에서 주고받는 양이 한계에 다다르면 앞부분을 잊거나 일을 효과적으로 수행하지 못합니다. 그래서 하나의 작업이 끝날 때마다 AI에게 현재 구조와 진행 상황을 `HANDOVER.md`로 정리시켰고, 다음 새 채팅을 시작할 때 그 문서부터 읽게 했습니다. 이 문서에서 가장 쓸모 있었던 부분은 '해결한 주요 문제' 표입니다. 한 번 고생해서 해결한 문제와 그 원인을 전부 기록해 두었습니다. 예를 들어 한글 파일 뷰어 라이브러리가 빌드 최적화 과정에서만 깨져 개발 중에는 멀쩡하다가 배포하면 실패했던 문제, 문서 미리보기 창 안을 클릭하면 브라우저 보안 정책 때문에 ESC 키가 부모 창에 아예 전달되지 않던 문제 같은 것들입니다. 여기에 더해 '반드시 유지할 조건' 항목에는 데이터 저장은 정해진 한 경로로만 한다, 데이터베이스에 직접 쓰지 않는다, 카드 색은 배경이 아니라 테두리로만 표시한다 같은 원칙이 쌓였습니다. 제가 처음부터 규칙집을 써둔 것이 아니라, 작업하면서 정해진 원칙을 AI가 문서에 계속 축적하게 만든 것입니다.
셋째, 이 두 가지를 매번 길게 설명하는 대신 아예 명령어로 만들었습니다. Claude Code는 사용자가 직접 슬래시 명령어(스킬)를 만들어 쓸 수 있는데, 저는 `/plan`과 `/handover` 두 개를 직접 작성했습니다. `/plan` 안에는 기획서에 들어갈 12개 항목의 목차뿐 아니라 "이번 턴에서는 코드 파일을 절대 만들지 않는다", "추측으로 사실을 지어내지 않고 확인되지 않은 것은 물음표 표시로 남긴다", "구현 1단계는 항상 가장 작게 동작하는 것부터 잡는다" 같은 규칙을 명시해 두었습니다. `/handover` 안에는 "기존 문서를 지우고 새로 쓰지 말고 이어받아 갱신한다", "해결된 문제는 남은 오류 목록에서 빼서 해결한 문제로 옮긴다", "API 키 같은 비밀값은 값 자체를 절대 적지 말고 변수명과 용도만 적는다" 같은 조건을 넣었습니다. 이렇게 만들어 두니 매번 "이런 형식으로 계획서를 써줘"를 길게 반복 설명할 필요 없이 `/plan` 한 줄이면 됐고, 결과물의 형식과 품질이 매번 일정하게 유지됐습니다. AI를 쓰는 데서 한 걸음 나아가, AI를 쓰는 방식 자체를 도구로 만든 셈입니다. 나중에는 크롬 웹스토어 등록 서류를 작성하는 명령어도 같은 방식으로 만들어 썼습니다.
넷째, 되돌릴 수 있는 상태를 계속 유지하면서 검증했습니다. AI는 한 번에 여러 파일을 동시에 고치기 때문에, 뭔가 잘못됐을 때 어디서부터 틀어졌는지 알기 어렵습니다. 그래서 의미 있는 작업 단위가 끝날 때마다 GitHub에 커밋하고 푸시하도록 했고, 13일 동안 56번의 커밋이 쌓였습니다. 덕분에 잘못된 방향으로 갔을 때 직전 커밋으로 되돌릴 수 있었고, AI에게 "이 커밋 이후로 이 기능이 안 된다"처럼 범위를 좁혀 말할 수도 있었습니다. 커밋하기 전에는 타입 검사, 문법 검사, 빌드, 그리고 헤드리스 브라우저 자동 테스트까지 4가지를 반드시 통과하도록 규칙을 정했습니다. 특히 마지막 자동 테스트는 AI가 실제로 브라우저를 띄워 로그인하고, 링크를 담고, 데이터베이스에 정말 저장됐는지 조회해서 확인하는 스크립트입니다. AI가 만든 것을 AI가 직접 확인하게 만든 셈입니다. 웹은 GitHub에 푸시하면 Vercel이 자동으로 배포하도록 연결해 두어서, 검증을 통과한 커밋이 곧바로 실제 서비스에 반영됐습니다.
3. 활용 결과 어떤 변화가 있었나요?
먼저 결과물의 규모입니다. 2026년 7월 13일에 시작해 7월 25일까지 13일에 걸쳐 진행했고, 실제로 작업한 날은 8일이었습니다. 그마저도 하루를 통째로 비워서 매달린 것이 아니라 일과 사이에 남는 자투리 시간에 조금씩 한 것입니다. 그렇게 총 56회를 GitHub에 커밋했고, 웹 애플리케이션 7,405줄(53개 파일), 브라우저 확장 프로그램 2,320줄, 윈도우 데스크톱 앱 105줄, 데이터베이스 설계 273줄로 약 1만 줄 규모의 서비스가 만들어졌습니다. 현재 웹은 Vercel에 배포되어 실제로 동작 중이고, 브라우저 확장·안드로이드 앱·윈도우 데스크톱 앱까지 4개 플랫폼이 하나의 캔버스를 공유합니다. 혼자였다면 몇 달을 잡아도 첫 번째 화면조차 못 만들었을 범위입니다.
기술적으로 확인된 수치도 있습니다. 윈도우 데스크톱 앱은 실행 파일 3.43MB, 설치 파일 1.26MB입니다. 같은 기능을 흔히 쓰는 Electron으로 만들면 150MB가 넘습니다. 또한 창을 닫으면 브라우저 엔진을 통째로 해제하도록 설계해서, 트레이에 상주할 때 메모리 사용량이 513MB에서 42MB로 92% 줄어드는 것을 실측했습니다.
실제 사용 습관은 이렇게 바뀌었습니다. 자료를 만나면 그 자리에서 우클릭 한 번으로 담습니다. 혹은 확장앱을 켜 '현재 탭 담기' 버튼을 누르거나, 파일 탐색기에서 확장앱의 드래그 드롭존으로 끌어다 바로 넣을 수도 있습니다. 링크, 이미지, 드래그한 텍스트, 현재 페이지 전체를 각각 담을 수 있고, 아무 페이지에서나 파일을 끌기 시작하면 화면 오른쪽 아래에 받는 영역이 나타납니다. 담는 순간 이미 열려 있는 캔버스에 새로고침 없이 카드가 나타납니다. 정리는 나중에 캔버스에서 카드를 옮기는 것으로 끝납니다. 폴더 이름을 정할 필요도, 태그를 입력할 필요도 없습니다.
찾는 방식도 달라졌습니다. PDF는 브라우저에서 본문 텍스트를 추출해 두기 때문에, 제목이 기억나지 않아도 문서 안에 있던 단어로 검색하면 나옵니다. 한글 파일은 프로그램을 켜지 않고 브라우저 안에서 바로 열립니다. Ctrl+K를 누르거나 메뉴바에서 검색을 이용해 파일을 찾아볼 수도 있습니다. 무엇보다 "그 자료 어디 뒀더라"가 "화면 왼쪽 위 그 근처에 뒀지"로 바뀌었습니다. 위치는 사람이 잘 기억하는 정보입니다.
4. 나만의 방식 또는 개선 포인트는 무엇인가요?
크게 서비스 자체의 차별점과 AI를 다루는 방식의 차별점으로 나눌 수 있습니다.
먼저 서비스 쪽입니다. 링크와 파일을 올릴 수 있는 도구는 이미 여럿 있지만, 각각 명확한 한계가 있었고 그 지점을 겨냥했습니다.
FigJam이나 Miro 같은 화이트보드 도구는 무한 캔버스라는 형태는 같습니다. 그러나 워드나 한글 문서를 올려도 파일 조각으로만 남아 내용을 볼 수 없고, 여러 명이 동시에 편집하는 협업 도구로 설계되어 있어 혼자 자료를 모아두는 용도로는 실행 자체가 무겁습니다. 노션은 파일 첨부는 되지만 결국 문서 안의 목록 구조여서, 자료가 쌓일수록 한눈에 들어오지 않고 스크롤에 의존하게 됩니다. 두 도구 모두 켜는 데 걸리는 시간이 길다는 점이 실사용에서는 치명적이었습니다. 담는 행위에 마찰이 생기면 사람은 담지 않습니다. 브라우저 기본 북마크는 폴더 계층을 먼저 정해야 저장이 되고, 국내에 나온 유사 앱들은 모바일 앱 중심이라 정작 자료를 가장 많이 만나는 PC 브라우징 중에는 담을 방법이 없습니다.
LinkScape가 다르게 택한 지점은 네 가지입니다.
첫째, 담는 지점을 브라우저 안에 두었습니다. 링크와 자료를 실제로 만나는 장소는 PC 브라우저입니다. 그래서 웹 서비스와 함께 브라우저 확장 프로그램을 같이 만들었고, 우클릭 메뉴 4종·확장앱 팝업 화면에 붙여넣기·페이지 안에서 드래그로 우측 하단의 드롭 영역에 넣기 등 세 가지 경로로 어디서든 즉시 담기게 했습니다. 모바일 앱만 있는 서비스로는 대체할 수 없는 부분입니다.
둘째, 한국 문서 환경을 정면으로 다뤘습니다. 한글(.hwp) 파일을 별도 프로그램 없이 브라우저 안에서 직접 렌더링합니다. 처음에는 웨일 브라우저 내장 뷰어에 의존하는 방식이었는데 크롬과 엣지에서는 빈 화면이 떠서, 한글 파일을 자바스크립트로 직접 해석하는 라이브러리를 서비스에 포함시켜 브라우저 종류와 무관하게 열리도록 바꿨습니다. 워드·엑셀·파워포인트도 앱 안에서 바로 보이고, PDF는 본문 텍스트까지 검색됩니다.
셋째, 가볍게 유지했습니다. 서버에서 도는 기능은 링크 미리보기 정보를 가져오는 것 하나뿐이고, PDF 해석·썸네일 생성·손글씨 처리는 전부 사용자 브라우저에서 처리합니다. 서버 부담이 없으니 빠르고 비용도 들지 않습니다. 데스크톱 앱도 Electron 대신 Tauri를 골라 3.43MB로 만들었습니다.
넷째, 정리를 강요하지 않습니다. 개발 중에 태그 입력 기능을 만들었다가 일부러 제거했습니다. 입력해야 할 것이 하나라도 있으면 담는 속도가 느려지기 때문입니다. 분류는 캔버스 위 위치와 카드 테두리 색만으로 합니다. 카드를 그룹 영역 안으로 끌어넣으면 그룹이 자동으로 늘어나고, 빼면 다시 줄어들어서 무엇이 어디에 속하는지 눈으로 바로 보입니다.
다음은 AI를 다루는 방식입니다. 이 부분이 실질적인 개선 포인트라고 생각합니다.
가장 큰 차이는 '만들기 전에 기획을 끝낸다'였습니다. AI에게 바로 "만들어줘"라고 하면 결과물이 빨리 나오기 때문에 잘 되고 있다고 착각하기 쉽습니다. 그런데 그렇게 만든 것은 제가 머릿속에 그린 것과 조금씩 어긋나 있고, 어긋난 채로 그 위에 기능이 계속 쌓입니다. 그래서 저는 항상 기획 문서를 먼저 쓰게 하고, 그 문서를 읽으면서 AI가 임의로 가정한 부분과 저에게 물어야 할 부분을 확인한 다음에야 구현을 허락했습니다. 코드가 없는 상태에서 방향을 바꾸는 것은 공짜지만, 만들고 나서 바꾸는 것은 비쌉니다.
두 번째는 반복되는 지시를 명령어로 만든 것입니다. 처음에는 기획서를 요청할 때마다 "이런 항목을 넣고, 확인 필요한 건 따로 표시하고, 코드는 아직 만들지 말고"를 매번 길게 설명했습니다. 이게 반복되니 어떤 날은 설명을 빠뜨려서 AI가 곧바로 코드를 만들어버리는 일도 생겼습니다. 그래서 그 지시 내용을 통째로 `/plan`이라는 명령어로 만들어 저장했습니다. 인수인계 문서를 남기는 `/handover`도 같은 이유로 만들었습니다. 이렇게 하니 제 지시의 품질이 그날의 기억력에 좌우되지 않게 됐습니다. AI 활용에서 흔히 놓치는 부분이 여기라고 생각합니다. 좋은 프롬프트를 한 번 찾아내는 것보다, 그것을 매번 똑같이 재사용할 수 있는 형태로 만들어 두는 것이 결과를 훨씬 크게 바꿨습니다.
세 번째는 AI의 말을 믿지 않고 실행 결과를 믿게 만든 것입니다. AI는 틀린 답을 확신에 찬 말투로 합니다. 그래서 "됐습니다"라는 말 대신, 브라우저를 실제로 띄워 로그인하고 클릭하고 데이터베이스를 조회해서 확인하는 자동 테스트를 매 작업마다 만들게 했습니다. 이 과정에서 겉보기엔 멀쩡한데 실제로는 동작하지 않던 문제를 여러 번 잡았습니다. 문서 미리보기를 열어둔 상태에서 Delete 키를 누르면 뒤에 선택돼 있던 카드가 조용히 삭제되던 문제가 대표적인데, 눈으로만 확인했다면 한참 뒤에나 발견했을 문제입니다. 여기에 GitHub 커밋을 작업 단위마다 남긴 것이 더해져서, 문제가 생겨도 항상 되돌아갈 지점이 있었습니다.
5. 다른 사람도 따라 할 수 있나요?
가능합니다. 필요한 것은 PC 한 대, AI 코딩 도구, 그리고 무료로 시작할 수 있는 GitHub·Supabase·Vercel 계정뿐입니다. 저는 지금까지 서버 비용을 한 푼도 내지 않았습니다. 전공 수준의 지식도 필요하지 않았습니다. 다만 솔직히 말하면, 코드를 직접 짜지는 못해도 읽고 대략 이해할 수 있는 정도는 도움이 됐습니다. AI가 엉뚱한 방향으로 갈 때 알아채는 속도가 달라지기 때문입니다. 그 정도는 무료 강의로도 충분히 닿는 수준이고, 없어도 시작은 할 수 있습니다. 대신 몇 가지 순서를 지키는 것이 중요했습니다.
첫째, 남이 쓸 것 같은 아이디어가 아니라 내가 매일 겪는 불편을 고르는 것입니다. 저는 카톡에 쌓인 링크를 못 찾는 것이 실제로 매주 겪는 일이었기 때문에, 무엇이 불편한지 AI에게 정확히 설명할 수 있었고 만든 것이 쓸 만한지도 바로 판단할 수 있었습니다. 관심 없는 주제를 골랐다면 중간에 멈췄을 것입니다.
둘째, 바로 만들어달라고 하지 말고 기획서부터 쓰게 하는 것입니다. "코드는 아직 만들지 말고, 무엇을 어떻게 만들 것인지 계획 문서부터 써줘. 네가 임의로 가정한 부분과 나에게 물어봐야 할 부분을 따로 표시해줘"라고 요청하면 됩니다. 그 문서를 읽고 방향을 잡은 다음에 구현을 시작하면, 만들고 나서 갈아엎는 일이 크게 줄어듭니다.
셋째, 첫 목표는 가장 작게 잡는 것입니다. 저의 첫 목표는 '링크를 붙여넣으면 화면에 카드가 하나 생긴다'였습니다. 처음부터 완성형을 설명하면 AI가 만든 것이 맞는지 판단할 수 없습니다. 작게 시작해서 되는 것을 확인하고 그 위에 쌓아야 합니다.
넷째, 작업 단위마다 GitHub에 커밋하는 것입니다. AI는 한 번에 여러 파일을 고치기 때문에, 되돌릴 지점이 없으면 문제가 생겼을 때 손을 쓸 수가 없습니다. 명령어를 몰라도 "지금까지 작업한 것을 커밋하고 푸시해줘"라고 하면 AI가 대신 해줍니다.
다섯째, 사람이 눈으로 확인하는 대신 확인 절차를 AI에게 만들게 하는 것입니다. "이 기능이 정말 동작하는지 브라우저를 띄워서 확인하는 스크립트를 만들고 실행해 줘"라고 요구하면 됩니다. 처음에는 번거롭지만, 이것 없이는 무엇이 언제부터 망가졌는지 나중에 절대 찾지 못합니다.
여섯째, 하루가 끝날 때 혹은 새 채팅으로 넘어가야 할 때, 현재 채팅방에서 AI에게 지금까지 한 일과 다음에 할 일을 문서로 정리시키는 것입니다. 다음에 그 문서부터 읽히면 대화가 끊겨도 이어서 작업할 수 있습니다.
마지막으로, 위의 요청들 중 반복되는 것은 명령어로 만들어 두기를 권합니다. 저는 기획서 작성과 인수인계 문서 작성을 각각 `/plan`과 `/handover`라는 명령어로 만들어 두고 13일 내내 그것만 입력했습니다. 만드는 방법도 어렵지 않습니다. 평소에 AI에게 길게 설명하던 지시 내용을 그대로 텍스트 파일로 저장하면 됩니다. 이것만 해도 매번 같은 설명을 반복하는 시간이 사라지고, 무엇보다 지시를 빠뜨려서 생기는 실수가 없어집니다.
주의할 점도 있습니다. AI는 확신에 찬 말투로 틀립니다. 특히 "완료했습니다", "정상 동작합니다"라는 답변은 실제 실행 결과가 아니라 예상인 경우가 있습니다. 반드시 실행해서 확인하고 넘어가야 하고, 이 습관 하나가 있고 없고에 따라 결과물이 완전히 달라집니다. 저도 처음에는 AI 말을 그대로 믿고 넘어갔다가, 배포하고 나서야 특정 브라우저에서 한글 파일이 안 열린다는 것을 알게 된 적이 있습니다.
