비개발자들이 대부분의 개발자도 생각지 못한 방식으로 Claude Code를 사용하는 방법

인사팀의 Karen은 영어로 세 줄을 입력하여 40개의 계약서에 대한 보고서를 생성했습니다. 그녀는 "PDF 파싱 (parsing a PDF)"이 무엇을 의미하는지 모릅니다. 그녀는 상관하지 않습니다. 그녀는 브라우저에서 열리는 HTML 보고서를 얻었고, 반나절의 수동 작업을 아꼈습니다. 그녀에게 필요한 것은 그것뿐이었습니다.

현재 Claude Code에서 일어나고 있는 일은 기묘합니다.

요약 (TLDR): 대부분의 Claude Code 콘텐츠는 개발자가 개발자를 위해 작성되었습니다. 반면, 비기술직 종사자들은 단 한 문장으로 설명 가능한 매우 단순한 요령을 사용하여, 대부분의 개발자보다 조용히 더 많은 성과를 얻고 있습니다. 이것은 가장 먼저 이를 알아낸 3가지 유형의 사람들과 그들이 사용한 정확한 지침에 관한 이야기입니다.

아무도 명확하게 설명하지 않는 차이점: Claude Chat은 사용자가 모든 컨텍스트 (context)를 창으로 가져오면 창 안에서 응답하며, 외부로 나오는 것은 없습니다. Claude Code는 사용자의 컴퓨터에 상주합니다. 그것은 파일을 직접 읽습니다. 그리고 오늘 아침까지만 해도 존재하지 않았던 보고서, 정리된 폴더, 대시보드와 같이 데스크톱에 실질적인 결과물을 만들어냅니다. 그 결과에 도달하기 위해 작성되는 코드는 보이지 않는 엔진입니다. 비개발자는 다음과 같이 인식합니다: "엉망이었던 폴더가 이제 사용 가능한 파일로 바뀌었네."

그것이 요령의 전부입니다.

아무도 설명하지 않는 차이점

Claude Chat vs Code: 출력 결과의 차이 설명

Claude Code에 관한 대부분의 기사는 터미널 (terminal) 스크린샷과 여러분이 한 번도 입력해 본 적 없는 명령어로 시작합니다. 그다음 또 다른 명령어가 나옵니다. 그리고 아무도 설명하지 않는 플래그 (flag)가 등장합니다. 비개발자는 두 번째 문단쯤에서 탭을 닫아버립니다. 전형적인 다크 소울 (Dark Souls)의 순간과 같습니다. 체크포인트 없이 죽어버린 것이죠. 단지 송장 몇 개를 정리하고 싶었을 뿐인데 말입니다. 기사 자체가 애초에 그들을 위한 것이 아니었기에, 아무도 사후 분석 (post-mortem) 글을 쓰지 않습니다.

Claude Chat과 Claude Code의 차이는 기술적 숙련도에 관한 것이 아닙니다. 그것은 작업이 어디에서 일어나는지, 그리고 결과물로 무엇이 나오는가에 관한 것입니다.

Claude chat는 대화창입니다. 텍스트를 붙여넣고, 컨텍스트 (context)를 붙여넣고, 질문을 던집니다. 답변은 채팅창 안에 머뭅니다. 탭을 닫으면 사라집니다. 사용자가 수동으로 어딘가에 복사하지 않는 한, 컴퓨터에는 아무것도 남지 않습니다. 유용하지만, 갇혀 있는 구조입니다. 모든 입력과 출력이 모두 동일한 상자 안에서 이루어집니다.

Claude Code는 중요한 측면에서 다릅니다. 이것은 사용자의 머신 (machine)에서 실행됩니다. 데스크톱의 폴더를 열고 그 안의 모든 파일을 읽을 수 있습니다. 새로운 파일을 생성하고, 기존 파일의 이름을 바꾸며, 보고서를 생성하여 사용자가 지정한 위치에 저장할 수 있습니다. 출력물은 실재합니다. 이전에는 없었던 하드 드라이브 (hard drive) 상의 파일, 브라우저에서 열리는 HTML 페이지, 3,000개의 무작위 파일이 실제 구조를 갖춘 상태로 변한 폴더 같은 것들 말입니다. Claude Code가 작업을 완료하면, 작업이 실제로 수행되었음을 증명하는 무언가가 사용자의 컴퓨터에 남습니다. 채팅에서는 불가능한 일입니다.

이 모든 것을 수행하기 위해 Claude가 내부적으로 작성하는 코드 (code)는? 보이지 않습니다. 사용자는 결코 그것을 볼 수 없습니다. 개발자에게 이것은 약간 불안한 일일 수 있습니다 (인정하세요, Claude가 무엇을 썼는지 읽고 싶어질 겁니다). 하지만 비개발자에게는 완전히 괜찮은 일입니다. 그들은 엔진이 어떻게 작동하는지 이해할 필요가 없습니다. 그들에게 필요한 것은 데스크톱에 나타날 결과물입니다.

비개발자들은 보이지 않는 코드를 참아주고 있는 것이 아닙니다. 그들은 그것을 적극적으로 무시하고 있습니다. 이것은 차이가 있습니다. 그리고 결과적으로 그것이 이 도구에 가장 적합한 태도임이 밝혀졌습니다.

인사팀의 Karen: 5년 치 계약서, 보고서 1개

인사팀의 Karen은 40명의 계약을 관리합니다. 모든 것은 폴더 안에 들어 있습니다. PDF, Word 파일, 3개의 서로 다른 시스템에서 추출한 Excel 파일들, 그리고 "contract_FINAL_v3_revised_USE_THIS_ONE.pdf"와 같은 이름의 파일들이 뒤섞여 있습니다. 그녀는 그 모든 것이 어딘가에 있다는 것은 알지만, 정확히 어디에 있는지는 모릅니다.

6개월마다 그녀의 매니저는 요약 보고를 요청합니다. 누가 계약 만료 예정인지, 누가 서명을 누락했는지, 갱신 날짜는 언제인지 말이죠. Karen은 반나절 동안 파일을 하나씩 열고, 데이터를 스프레드시트(spreadsheet)에 복사하고, 스프레드시트를 보기 좋게 서식화하는 데 시간을 보냅니다. 이 과정을 6개월마다 반복합니다. 누구의 잘못도 아닙니다. 그저 프로세스(process)일 뿐입니다.

그녀는 Claude Code를 해당 폴더로 지정하고 다음과 같이 입력했습니다:

이 폴더에 있는 모든 계약서를 읽어줘. 각 계약서에서 다음 항목을 추출해줘: 직원 이름, 계약 시작일, 만료일, 그리고 서명 여부. 정렬 가능한 테이블이 포함된 HTML 보고서를 생성해줘. 다음 사항은 주황색으로 강조해줘
...

20분 후, 그녀의 데스크톱에는 HTML 파일이 생성되어 있었습니다. 파일은 Chrome에서 열렸습니다. 그녀는 만료일별로 정렬할 수 있었습니다. 서명이 누락된 3개의 계약서는 주황색으로 강조되어 있었습니다.

그녀는 코드(code)를 단 한 줄도 작성하지 않았고, Claude가 내부적으로 무엇을 생성했는지도 전혀 보지 못했습니다. 보고서는 그녀의 데스크톱에 있었습니다.

주목해야 할 점은 그녀가 지시 사항을 구성(frame)한 방식입니다. 그녀는 자신이 무엇을 가지고 있는지(폴더, 파일 유형), 무엇을 추출하고 싶은지(명시적으로 명명된 5가지 특정 필드), 그리고 원하는 출력 형식(HTML, 예외 사항에 대한 특정 시각적 동작 포함)을 설명했습니다. 입력값, 필요한 필드, 그리고 출력 형식입니다. 이러한 구조는 개발자식 사고(dev thinking)가 아닙니다. 이는 유능한 비서에게 업무를 지시하는 방식과 같습니다. 무엇이 있는지, 무엇이 필요한지, 그리고 결과물을 어떻게 전달받고 싶은지를 말하는 것이죠. 비개발자들은 커리어 내내 사람들에게 업무를 지시해 왔기 때문에 이를 직관적으로 이해합니다.

비개발자 창업자: 누구도 채용하지 않고 만드는 대시보드 (Dashboard)

그는 6개월 동안 자신의 도구를 운영해 왔습니다. 유료 고객도 있고, 실제 사용 사례와 실제 문제들도 존재했습니다. 그의 데이터는 4개의 서로 다른 곳에 흩어져 있었습니다. 결제 내역 내보내기(payment exports) 파일, 양식 결과 시트, 첫 달부터 수동으로 복사하여 붙여넣어 온 Google Sheet, 그리고 언젠가 처리해야지 하며 텍스트 파일로 저장해 둔 가공되지 않은 피드백 이메일 폴더였습니다. 그의 월요일 의식은 이 4개의 탭을 모두 열고, 일치하지 않는 숫자들을 맞추기 위해 20분을 허비하다가, 결국 포기하고 그냥 매출(revenue) 열만 확인하는 것이었습니다. (스피드러너들은 이를 "any%"라고 부릅니다. 다른 모든 것을 건너뛰고 목표를 최대한 빨리 달성하는 방식이죠. 그는 월요일 대시보드 운영을 any% 방식으로 하고 있었던 것입니다.)

그는 모든 것을 하나의 폴더에 집어넣고 Claude Code에게 이를 파악해 달라고 요청했습니다:

이 폴더에 4개의 CSV 파일과 몇 개의 텍스트 파일이 있어. 모두 읽어줘.
다음 내용을 보여주는 HTML 대시보드를 생성해줘: 선 그래프(line chart)로 표시된 주간 총 매출, 막대 그래프(bar chart)로 표시된 상위 10개 오류 유형, 불렛 리스트(bullet list)로 표시된 고객 피드백 테마.
...

이것이 명령의 전부였습니다. 코드도, API도, 프리랜서에게 보낼 인보이스(invoice)도 필요 없었습니다.

결과는 다음과 같았습니다: 약 45분간의 대화(back-and-forth) 끝에 기능적인 내부 대시보드가 완성되었습니다. 주간 총 매출, 고객 피드백 테마, 오류 급증(error spikes) 등이 포함되었습니다. 브라우저에서 바로 열리고, 팀원들과 공유할 수 있으며, 설치할 소프트웨어도 없습니다.

솔직한 주의 사항을 말씀드리자면, 이 부분은 명시적으로 언급할 가치가 있습니다: 이 방식은 데이터가 어느 정도 깨끗할 때 잘 작동합니다. 만약 CSV 파일의 열 이름(column names)이 일관되지 않거나, 날짜 형식이 맞지 않거나, 행(row)이 절반쯤 비어 있다면, Claude가 이를 처리하려고 시도하겠지만 가정이 쌓이면서 오류가 발생할 수 있습니다. 입력 데이터가 너무 지저분해서 매번 수정을 할 때마다 새로운 예외 상황(edge case)이 발생하는 세션들을 저는 목격해 왔습니다. 일반적인 비즈니스 내보내기 데이터의 80% 정도는 괜찮습니다. 나머지 경우에는 데이터를 먼저 정리하거나, Claude가 시작하기 전에 어떤 형식을 기대해야 하는지 정확히 알려주어야 합니다.

더 멀리 나아가고 싶은 창업자를 위해, 프롬프트 계약(prompt contracts)이 Claude에게 전달하는 내용을 어떻게 구조화하여 매번 복권 당첨 같은 결과 대신 일관된 출력을 얻게 하는지 알아보세요.

콘텐츠 크리에이터: 3,000개의 파일, 1개의 깔끔한 시스템

혼란은 서서히 쌓여갑니다. 2021년의 팟캐스트 전사 데이터(transcripts), 400개의 파일이 들어있는 "notes"라는 이름의 폴더, 출시되지 못한 강의를 위한 조사 자료, 그해에 유행했던 앱에 따라 제각각인 3가지의 서로 다른 명명 규칙(naming conventions), 그리고 그 어딘가에 아마도 중요할 것 같은 "ideas_GOOD_version_final.docx"라는 문서가 존재합니다. 아무도 이를 의도적으로 만들지 않습니다. 그냥 쌓이는 것입니다. 마치 340개의 게임을 보유하고 있지만 그중 12개만 플레이한 Steam 라이브러리처럼 말이죠. 나머지도 플레이할 의도는 있지만, 결국 하지 않게 됩니다.

Claude Code는 이러한 종류의 문제를 잘 처리합니다. 왜냐하면 이 작업의 본질이 파일을 읽고, 콘텐츠를 분류하며, 구조화된 출력(structured output)을 생성하는 것이기 때문입니다:

이 폴더의 모든 파일을 읽으세요.
중복 항목(내용은 같으나 파일명이 다른 경우)을 식별하고 목록을 만드세요.
모든 파일의 이름을 다음 형식을 사용하여 변경하세요: YYYY-MM_주제_짧은-제목.
...

결과물은 구조화된 폴더와 지난 5년간 축적된 콘텐츠에 대한 조감도(bird's-eye view)입니다.

이와 유사한 작업을 수행했던 한 크리에이터는 자신이 완전히 잊고 있었던 2022년의 미완성 전자책 초안을 발견했습니다. 18,000단어 분량이었습니다. 그녀는 단 3번의 세션 후에 프로젝트를 포기했다고 생각했습니다. 하지만 그 초안은 그저 "misc"라는 폴더 안에서 3년 동안 조용히 기다리며 놓여 있었을 뿐입니다. 이것은 사실 Claude Code에 대한 이야기가 아닙니다. 그저 당신이 실제로 무엇을 만들어왔는지 마침내 확인했을 때 일어나는 일입니다.

또 다른 크리에이터는 180개의 팟캐스트 전사 데이터 (transcripts)를 가지고 Claude Code에게 모든 데이터에서 가장 자주 반복되는 주제 20개를 추출하고, 각 주제별로 가장 관련 있는 에피소드 제목 3개를 포함하여 1문단 분량의 종합 요약 (synthesis)을 작성해 달라고 요청했습니다. 이 작업은 수동으로 읽는다면 일주일은 걸렸을 일입니다. 그녀는 이를 밤새 실행했습니다. 전사 데이터가 얼마나 대화체인지, 그리고 주제들이 실제로 얼마나 뚜렷한지에 따라 품질은 달라질 수 있겠지만, 지난 5년간 당신이 무엇을 만들어왔는지 이해하기 위한 첫 번째 시도로서, 이는 180개의 파일이 들어있는 폴더를 가지고 있는 것보다 훨씬 낫습니다.

그들이 모두 동일하게 수행하는 유일한 방식

창업자이자 콘텐츠 크리에이터인 Karen. 서로 다른 문제, 서로 다른 파일, 서로 다른 산업군을 다룹니다.

하지만 반응은 동일합니다. 전용 폴더를 만들고, 관련 파일을 그 안에 넣고, 원하는 내용을 평이한 언어로 설명한 뒤, HTML로 만들어 달라고 요청합니다.

HTML을 요청하는 부분은 명확해 보이지 않을 수 있지만 매우 중요합니다. HTML은 아무것도 설치하지 않고도 모든 브라우저에서 열 수 있습니다. 표, 차트, 색상, 대화형 정렬 (interactive sorting) 기능을 포함할 수 있습니다. 별도의 도구 구독 없이도 공유가 가능합니다. 그리고 Claude는 광범위한 작업에 걸쳐 HTML을 안정적으로 생성합니다. 다른 형식들도 작동하지만, 사람이 읽어야 하거나 팀원들에게 전달해야 하는 모든 작업에 있어 HTML은 저항이 가장 적은 경로 (path of least resistance)입니다.

그들 중 누구도 Claude가 작성한 코드를 읽지 않습니다. 스크립트를 확인하거나 로직을 검사 (audit)하지 않습니다. 그들은 원하는 것을 설명하고, 결과물을 확인하며, 무언가 잘못되었다면 무엇이 잘못되었는지 말합니다. 그런데 공교롭게도, 이것은 현재 많은 개발자들이 Claude Code를 사용하는 방식과 정확히 일치합니다. 차이점은 개발자들은 이에 대해 약간의 죄책감을 느끼는 반면, 비개발자들은 그런 부담을 전혀 느끼지 않는다는 것입니다. 죄책감은 도움이 되지 않습니다. 결과물은 동일하니까요.

비기술직 사람들이 Claude Code를 사용하는 것을 지켜보며 눈에 띄는 점은, 그들이 도구 사용에 있어 마찰 (friction)을 거의 일으키지 않는다는 것입니다. 그들은 내부적으로 어떤 일이 일어나고 있는지 이해하려고 애쓰지 않습니다. 이것이 아키텍처 (architecturally) 측면에서 올바른 접근 방식인지 의구심을 갖지도 않습니다. 그들은 파일과 원하는 결과물을 가지고 있으며, 이를 빠르고 불평하지 않는 동료에게 업무 지시를 내리는 것처럼 다룹니다. 그들이 작성하는 지침은 때로는 이상할 정도로 정밀하고, 때로는 순전히 느낌 (vibes)에 의존하기도 하지만, Claude는 소프트웨어 엔지니어링 (software engineering) 배경을 가진 사람이 예상하는 것보다 두 가지 방식 모두를 더 잘 처리합니다. 잘못된 추상화 (abstractions)로 인한 흉터도 없고, 블랙박스 (black box) 내부에서 무슨 일이 일어나는지 궁금해하는 본능도 없습니다. 그들은 그저 원하는 것을 설명하고 파일이 나오기를 기다릴 뿐입니다.

이러한 세션에서 Claude가 내부적으로 실제로 무엇을 하고 있는지 이해하고 싶다면, 왜 파일 액세스 작업에는 MCP보다 CLI가 더 나은지에서 그 트레이드오프 (tradeoffs)를 설명합니다.

현재 Claude Code의 가장 뛰어난 사용자들은 아마도 코딩을 할 줄 모르는 사람들일 것입니다.