ChatGPT에서 말하는 “루프”는 대개 정해진 시각에 작업을 다시 실행하는 Scheduled Tasks를 뜻합니다. 저장소를 고치고 테스트하는 반복 작업은 Codex 자동화로 분리해서 생각하면 쉽습니다.
<ChatGPT Scheduled Tasks의 반복 실행 흐름 1.1>
1. GPT 루프 기능의 개요
Scheduled Tasks는 일회성 또는 반복 프롬프트를 백그라운드에서 실행하고, 결과를 알림으로 알려주는 기능입니다. 매일 브리핑, 주간 리포트, 특정 변화 모니터링에 적합합니다. 자세한 지원 범위는 ChatGPT Scheduled Tasks 공식 안내에서 확인할 수 있습니다.
목적
적합한 기능
알림·브리핑·변화 감시
ChatGPT Scheduled Tasks
저장소 수정·테스트·검증
Codex Automations 또는 장기 작업
2. 데스크톱 프로그램에서 사용법
ChatGPT 데스크톱 앱에서 왼쪽 위 ChatGPT 메뉴 → Scheduled를 엽니다. 새 작업을 만들고 “매주 월요일 오전 9시에 지난주 AI 뉴스를 세 줄로 요약해줘”처럼 내용과 주기를 입력한 뒤 확인 카드를 저장하면 됩니다. 같은 화면에서 다음 실행 시각을 확인하고 일시정지·재개·수정·삭제할 수 있습니다. 알림은 Settings → Notifications에서 관리합니다.
로컬 프로젝트를 대상으로 예약할 때는 프로젝트가 디스크에 남아 있고 앱과 컴퓨터가 실행 중이어야 합니다. 웹에서 만든 작업은 로컬 폴더를 직접 유지하지 않습니다.
3. Codex에서의 사용법
Codex에는 ChatGPT의 Scheduled 관리 메뉴가 없습니다. 대신 Codex Automations 또는 장기 작업에 다음 네 가지를 명시합니다.
대상 저장소와 작업 범위
실행 주기 또는 시작 조건
성공 판정과 결과물 형식
중단 조건과 사람의 승인 지점
예를 들어 “매일 오전 9시에 이 저장소의 테스트를 실행하고 실패 항목만 요약해. 같은 오류는 세 번까지만 재시도하고 파일 수정은 승인 후 진행해”처럼 요청합니다. Codex의 Automations 안내와 사용 사례를 함께 보면 저장소 작업을 더 구체화할 수 있습니다.
<Codex 작업을 안전하게 반복하는 검증 루프 1.2>
4. 사용 시 팁과 주의점
먼저 일반 대화에서 프롬프트를 시험하고 첫 몇 회의 결과를 확인하세요. 작업은 최소 권한과 좁은 폴더 범위로 시작하고, Codex가 파일을 바꿀 때는 별도 worktree와 테스트를 사용하면 복구가 쉽습니다. Scheduled Tasks는 한 시간보다 자주 실행할 수 없고 플랜별 활성 작업 수 제한이 있으며, 장기간 방치하면 일시정지될 수 있습니다. 음성 대화와 GPTs는 Tasks에서 지원되지 않습니다.
클로드 산업 자동화를 이야기할 때 가장 먼저 바뀌는 것은 모델의 성능표가 아니라 자동화의 시작점입니다. 과거에는 사람이 어느 화면을 열고 어떤 버튼을 누를지 먼저 설계한 뒤, RPA나 API 워크플로우를 연결했습니다. 이제는 “이 문서들을 읽고 판단 기준에 맞는 보고서를 만들어 공유해 달라”는 결과 중심의 지시에서 자동화가 시작될 수 있습니다.
Anthropic은 Claude Code를 코드베이스를 읽고, 파일을 수정하고, 명령을 실행하고, 개발 도구와 연결하는 에이전트 도구로 설명합니다. 최근의 Claude Cowork는 같은 에이전트 구조를 터미널 밖의 지식 업무로 가져와 정리된 문서, 파일 정리, 리서치 결과, 스프레드시트와 프레젠테이션 같은 결과물을 만들도록 확장합니다. 이 글은 그 변화를 바탕으로 Claude가 어떤 자동화 제품과 겹치는지, 실제로 어떤 업무가 바뀌는지를 살펴봅니다.
이 글에서 말하는 “위협”은 기존 제품이 곧 사라진다는 뜻이 아닙니다. Claude가 비정형 입력을 읽고 계획을 세워 여러 도구를 호출하는 범위를 넓히면서, 기존 자동화 제품의 구축 방식·가격·차별화 지점이 압박받는다는 의미입니다. 글의 90%·95% 수치는 공개 벤치마크가 아니라 조건이 맞을 때의 필자 전망입니다.
자동화의 단위가 플로우에서 에이전트로 이동하다
Claude Code에서 Claude Cowork로
Claude Code의 핵심은 답변을 출력하는 채팅이 아니라 작업을 끝내는 루프입니다. 코드를 읽고, 여러 파일을 수정하고, 명령을 실행하고, 오류를 확인한 뒤 다음 행동을 정하는 과정이 하나의 세션에서 이어집니다. Claude Code 공식 문서는 MCP를 통해 Google Drive·Jira·Slack 같은 외부 도구와 자체 도구를 연결하고, 반복 작업을 예약할 수 있다고 설명합니다.
<Claude Code 작업 현황 화면 1.1>
Claude Cowork는 이 구조를 비개발자에게 노출하는 제품입니다. 터미널 명령을 배워야 하는 대신 원하는 결과를 자연어로 설명하면, Claude가 파일과 커넥터를 읽고 여러 단계의 작업을 진행한 뒤 문서·스프레드시트·프레젠테이션 형태로 결과를 남깁니다. Cowork 안내에 따르면 Cowork는 Claude Code의 에이전트 구조를 코딩 밖의 지식 업무로 확장하고, 예약 작업과 프로젝트 단위의 파일·지침·기억을 제공합니다.
<Claude Cowork 시작 화면 1.2>
이 변화의 의미는 개발자가 자동화를 만든다는 전제가 약해진다는 데 있습니다. 개발자는 여전히 권한, 데이터 구조, 예외 처리, 배포를 설계해야 하지만, 업무 담당자는 “무엇을 언제 어떤 기준으로 처리할지”를 설명하는 것만으로 첫 번째 AI 워크플로우를 만들 수 있습니다.
<클로드 에이전트 자동화 루프 1.3>
두 방향의 도구 호출 루프
자동화는 한 방향으로만 흐르지 않습니다. 문서를 읽고 도구를 호출할 수도 있고, 도구에서 먼저 자료를 가져온 다음 문서를 만들 수도 있습니다.
문서에서 시작하는 루프: PDF·Word·스프레드시트·메일을 읽고, 내용을 요약·분류·정리한 뒤, Google Drive에 새 문서로 저장하거나 담당자에게 메일 초안을 만들고, 업무 시스템에 결과를 기록합니다.
도구에서 시작하는 루프: CRM·캘린더·Drive·Slack·내부 API에서 데이터를 가져오고, 여러 결과를 비교·요약한 뒤, 보고서·회의자료·후속 작업 목록을 만들거나 다시 다른 도구로 전달합니다.
Anthropic의 Google Workspace 커넥터 안내는 Gmail·Calendar·Drive를 연결해 검색하고, 문서를 만들고, 생성한 파일을 Drive에 저장하는 흐름을 설명합니다. 커넥터가 없을 때는 Cowork의 컴퓨터 사용 기능이 브라우저나 화면을 직접 조작할 수 있지만, 현재 연구 미리보기이며 커넥터보다 느리고 오류 가능성이 높습니다.
기존 RPA의 핀셋영역은 “컴퓨터의 어느 위치에서 어떤 데이터를 읽고, 어떤 도구에 어떤 형식으로 전송하거나 저장할 것인가”였습니다. 화면 좌표, 셀 위치, 파일명, 로그인 계정, 예외 화면을 모두 미리 정의해야 했기 때문입니다. LLM 에이전트는 이 중 일부를 문맥을 읽고 계획하는 문제로 바꾸지만, 반복성이 높은 업무와 엄격한 감사가 필요한 업무에서는 RPA와 API가 여전히 더 적합합니다.
클로드가 압박하는 자동화 제품 지도
Claude가 기존 제품을 모두 대체하는 것은 아닙니다. 다만 자동화의 첫 설계 단계에서 자연어로 목표를 설명하고, 비정형 문서를 읽고, 필요한 도구를 선택하는 일이 가능해지면서 아래 제품군과 겹치는 면적이 빠르게 커지고 있습니다.
영역
겹쳐지는 제품군
Claude와 겹치는 지점
기존 제품이 여전히 강한 지점
화면·RPA 자동화
UiPath Platform, Power Automate Desktop, Automation Anywhere, Blue Prism
Microsoft 365 Copilot·Workflows, Google Workspace·Gemini, Notion 계열
파일 요약, 회의자료·보고서 생성, 팀 지식 검색과 후속 작업
테넌트 보안, 계정·공유 권한, 조직 내 저장소와 기본 통합
제품 관점에서 가장 먼저 압박받는 것은 “간단한 자동화를 만들어 주는 구축 서비스”입니다. 과거에는 작은 팀이 이메일 수신, 파일 분류, 요약, 알림 전송을 연결하려면 iPaaS 화면에서 트리거와 액션을 하나씩 골라야 했습니다. 이제는 Claude가 목표와 데이터 위치를 이해하고 첫 설계를 만들 수 있으므로, 단순 연결의 가치가 낮아집니다.
반대로 기존 자동화 플랫폼은 Claude를 적으로만 보지 않습니다. UiPath는 에이전트·로봇·도구·사람을 하나의 제어 영역에서 묶는 방향으로 가고 있고, Microsoft는 에이전트가 판단하고 워크플로가 구조와 감사 기록을 맡는 결합을 설명합니다. 즉, 기존 제품의 다음 경쟁력은 “버튼을 대신 누르는 로봇”이 아니라 다양한 모델과 에이전트를 안전하게 배치하고 관찰하는 운영 체계가 됩니다.
<RPA·API·LLM 에이전트의 역할 경계 2.1>
이런 관점에서 보면 Claude는 RPA 자동화 제품 하나와 경쟁하는 것이 아니라 자동화 시장의 상단을 넓히는 촉매에 가깝습니다. RPA가 정해진 화면 작업을 담당하고, API가 시스템 사이의 안정적인 통로를 제공하며, LLM 에이전트가 비정형 입력을 해석하고 다음 행동을 계획하는 조합이 현실적인 구조입니다.
비개발자 업무의 90%가 자동화되는 조건
클라우드 저장소와 파일 형식이 업무의 기반이 된다
에이전트 자동화의 성패는 모델 하나보다 도구의 역할에 달려 있습니다.
Google Drive·SharePoint·Dropbox 같은 클라우드 저장소는 파일을 공동으로 보관하고 공유하는 기준점이 됩니다.
동기화 폴더와 데스크톱 커넥터는 LLM이 로컬 파일에 접근해야 할 때 수동 업로드를 줄여 줍니다.
Word·Excel·PowerPoint·PDF·TXT·Markdown 같은 문서 도구와 파서는 파일을 열고 구조를 읽는 입구입니다. HWP처럼 특정 지역에서 많이 쓰는 형식은 연결 도구가 실제 파싱을 지원하는지 별도로 확인해야 합니다.
API·MCP·셸 스크립트는 결과를 다른 시스템으로 전송하거나 신규 파일을 생산하는 출구가 됩니다.
Claude는 이미 파일을 읽는 데서 멈추지 않고, 파일 생성·편집 기능을 통해 Excel·PowerPoint·Word·PDF 같은 결과물을 만들 수 있다고 안내합니다. 파일을 읽고 요약하는 모델과 파일을 생산·전송하는 도구가 하나의 대화 안에서 연결되면, 업무 담당자는 각 제품의 메뉴보다 처리할 목적과 승인 기준에 집중하게 됩니다.
마케팅 플랜과 정형 분석은 빠르게 자동화된다
마케팅 플랜을 예로 들면 시장 자료 수집, 경쟁사 목록화, 고객군 분류, 캠페인 가설 작성, 일정표와 예산 초안, 보고서와 발표자료 생성까지 이어지는 흐름이 있습니다. 사람이 해야 하는 것은 무엇을 조사할지와 어떤 제약을 지킬지를 정하는 일이고, 자료를 읽고 초안을 조립하는 대부분의 단계는 에이전트가 처리할 수 있습니다.
필자는 조건이 잘 정의된 마케팅 플랜의 문서 작성과 결과물 생성 과정은 약 90%까지 자동화될 수 있다고 봅니다. 다만 시장 수치가 최신인지, 경쟁사 정보가 사실인지, 예산과 법적 표현에 문제가 없는지는 사람이 확인해야 하므로 “캠페인 전체가 90% 자동 집행된다”는 뜻은 아닙니다.
정해진 포맷의 분석·요약·플랜·결과물 생산은 더 높은 자동화율을 기대할 수 있습니다. 입력 문서가 충분하고, 출력 형식이 정해져 있으며, 외부 시스템에 쓰기 전 승인 단계가 있다면 필자는 이 부분의 95% 이상을 자동화할 수 있다고 예상합니다. 이 수치는 회사·문서·권한 설계에 따라 크게 달라지는 조건부 추정입니다.
Claude Cowork의 예약 작업은 매일 메일·Slack·캘린더를 요약하거나, 매주 Drive 자료를 모아 보고서를 만드는 반복 업무를 제품 기능으로 끌어옵니다. 자동화의 단위가 “버튼을 누르는 일”에서 “매주 결과물을 납품하는 일”로 바뀌는 지점입니다.
산업의 다음 경쟁은 보안·거버넌스·판단이다
공공·법무·세무·부동산에서 일어날 변화
공공기관, 법무법인, 세무·회계, 부동산 컨설팅처럼 텍스트와 고급 정보를 많이 다루는 업종은 LLM의 이점을 크게 받을 수 있습니다. 과거 기록을 검색하고, 문서의 맥락을 비교하고, 신규 정책이나 의견서의 초안을 만들고, 정해진 양식으로 보고하는 업무가 많기 때문입니다. Microsoft AI Builder의 문서 처리 구조도 문서 수신·정보 추출·검토·결과 통보를 하나의 흐름으로 묶되, 예외는 사람이 확인하는 구조를 전제로 합니다.
다만 이런 조직은 외부 LLM을 바로 도입하기 어렵습니다. 개인정보·비공개 기록·법률상 비밀·국가 중요 정보가 포함될 수 있고, 누가 어떤 문서를 읽고 어떤 결정을 했는지 감사할 수 있어야 합니다. Cowork의 안전 가이드도 읽기 도구와 쓰기 도구의 위험이 다르고, 예약 작업·브라우저·커넥터가 서로 다른 서비스로 데이터를 전달할 수 있으므로 권한과 사람 검토를 맞춰야 한다고 설명합니다.
필자는 이 보안·법규제·감사 문제가 해결되는 조직에서는 현재 담당자가 수행하는 잡무의 상당 부분이 자동화될 것으로 봅니다. “담당자의 95%가 필요 없어진다”는 의미가 아니라, 현재 업무 시간의 95%를 차지하는 복사·검색·정리·문서화 중심의 반복 작업에서 해방되어 판단과 설계에 더 많은 시간을 쓰게 된다는 뜻입니다.
아이디어를 내는 사람과 문서를 만드는 사람의 역할이 갈라진다
과거 정책을 입안하거나 사업계획을 만들 때 담당자는 기록을 찾아 읽고, 여러 아이디어를 문서로 정리하고, 시안을 만들고, 보고서를 작성하느라 밤을 새우기도 했습니다. 앞으로는 과거 기록의 맥락을 찾아 비교하고, 여러 방향의 아이디어와 시안·보고서 초안을 만드는 일은 자동화될 가능성이 높습니다.
사람의 역할은 더 나은 방향성을 판단하고, 현실적인 제약을 반영하고, 결과물이 실제 현장에서 작동할지 검토하는 쪽으로 이동합니다. 즉, 아이디어가 없는 사람이 문서를 잘 만드는 능력보다, 많은 후보 중 어떤 방향을 선택할지 판단하고 빠르게 프로토타입을 검증하는 능력이 중요해집니다.
여기서 기존 RPA와 API가 사라지는 것은 아닙니다. 오히려 에이전트가 판단한 결과를 실제 시스템에 안전하게 반영하려면 API, 업무 규칙, 승인선, 감사 로그가 더 중요해집니다. 자동화 시장은 “LLM 하나로 끝내기”가 아니라 에이전트의 추론과 기존 시스템의 통제력을 결합하는 시장으로 재편될 가능성이 큽니다.
에이전트가 문서를 읽고 도구를 호출할 수 있다는 사실이 곧 업무를 무감독으로 맡겨도 된다는 뜻은 아닙니다. 문서 안의 악성 지시, 잘못된 권한, 오래된 데이터, API 오류, 환각이 실제 전송·삭제·정책 판단으로 이어질 수 있습니다. 민감한 업무는 읽기와 쓰기 권한을 나누고, 외부 전송과 최종 보고 전에 사람 승인 단계를 남겨야 합니다.
마무리
클로드가 산업지형을 바꾸는 핵심은 더 좋은 답변을 만드는 데 있지 않습니다.
Claude Code가 개발자의 파일·명령·도구 작업을 에이전트 루프로 묶었습니다.
Claude Cowork가 그 구조를 비개발자의 문서·파일·클라우드 업무로 확장했습니다.
RPA·API·문서 처리·협업 제품은 사라지기보다 에이전트를 안전하게 운영하는 오케스트레이션 계층으로 이동하고 있습니다.
정형 업무의 자동화율은 높아지지만, 방향성 판단·책임·보안·최종 승인까지 자동화되는 것은 아닙니다.
이미 발 빠른 회사들은 도구를 하나씩 추가하는 대신 업무 흐름 자체를 AI 중심으로 다시 설계하고 있습니다. 여러분의 회사는 지금 어떤 업무를 사람이 직접 복사하고, 검색하고, 정리하고, 보고서로 옮기고 있습니까? 그 작업의 목적과 권한을 먼저 정의할 수 있다면, 자동화는 생각보다 가까이 와 있을 수 있습니다.
다음에는 클로드를 이용해 이런 실무적인 자동화 기법을 어떻게 사용하는지 알아보겠습니다. 궁금한 분들은 기대해 주세요.
이 글은 맥 파인더 사용법을 처음 찾는 맥 파일 초보자를 위한 안내서입니다. Finder를 중심으로 한 맥 파일 관리의 기본 구조와 설정부터 차근차근 살펴보겠습니다.
Finder의 메뉴 위치와 폴더 역할은 공식 안내를 기준으로 설명하고, “어떤 설정이 더 편한가”에 대한 평가는 필자의 사용 경험을 바탕으로 합니다.
Finder는 맥의 파일 탐색기입니다
맥을 처음 켜고 파일을 찾으려면 가장 먼저 만나게 되는 앱이 Finder입니다. Finder는 문서, 사진, 다운로드한 파일, 설치된 앱, 외장 디스크처럼 맥 안의 거의 모든 항목을 보고 정리하는 기본 파일 관리자입니다. 윈도우의 파일 탐색기와 비슷한 역할을 한다고 생각하면 출발하기 쉽습니다.
다만 맥은 창 안에 프로그램 메뉴가 붙어 있지 않습니다. 현재 사용 중인 프로그램의 메뉴가 화면 최상단 메뉴 막대에 나타나는 방식입니다. Finder 창을 열어 놓고도 메뉴는 창의 위쪽이 아니라 화면의 가장 위에서 찾는다는 점을 먼저 기억해 두면 좋습니다.
저는 윈도우보다 맥의 사용성이 낫다고 느끼는 부분 중 하나로 Finder를 꼽습니다. 폴더를 열고, 현재 위치를 확인하고, 여러 작업을 탭으로 묶는 흐름이 제 작업 방식에는 자연스럽게 맞았습니다. 다만 이것은 객관적인 운영체제 우열이라기보다 오랫동안 사용하며 생긴 개인적인 사용성 의견입니다.
Dock에서 파란색 웃는 얼굴 모양의 Finder 아이콘을 클릭하면 Finder 창이 열립니다. Apple도 Finder를 맥에서 문서와 폴더를 정리하고 접근하는 기본 공간으로 설명합니다. Finder의 기본 역할과 화면 구성은 Apple 공식 안내에서도 확인할 수 있습니다.
먼저 맞춰 둘 Finder 기본 설정
처음부터 모든 설정을 바꿀 필요는 없습니다. 저는 파일의 위치와 현재 상태를 놓치지 않는 데 도움이 되는 항목만 먼저 켜고, 사이드바와 태그는 자주 쓰는 것만 남겨 두는 편입니다.
보기 메뉴에서 세 가지 막대 보이기
Finder 창을 활성화한 뒤 화면 최상단 메뉴 막대에서 보기를 엽니다. 여기서 다음 세 항목을 켭니다.
도구 막대 보기
경로 막대 보기
상태 막대 보기
도구 막대는 뒤로 가기, 보기 방식 변경, 공유와 같은 조작 버튼이 모이는 영역입니다. 경로 막대는 현재 폴더가 어떤 상위 폴더 안에 있는지 보여 주고, 상태 막대는 현재 폴더의 항목 수와 저장 공간 상태를 보여 줍니다. Finder 도구 막대는 Apple 공식 안내처럼 필요한 버튼을 추가하거나 순서를 바꿀 수도 있습니다.
세 막대를 모두 켜 두면 “지금 어디에 있는 파일인지”, “현재 폴더에 무엇이 얼마나 있는지”, “어떤 조작을 할 수 있는지”를 한 화면에서 확인하기 쉬워집니다. 화면이 좁아 보인다면 나중에 도구 막대만 정리하면 됩니다.
<Finder 보기 메뉴의 표시 항목 2.1>
Finder 설정에서 일반·사이드바·태그 정리
Finder를 클릭해 활성화한 상태에서 화면 위쪽의 Finder > 설정을 엽니다. 설정 화면은 macOS 버전에 따라 표현이 조금 다를 수 있지만, 다음 세 곳을 먼저 보면 됩니다.
<Finder 설정 메뉴 진입 2.2>
일반에서는 새 Finder 창을 열었을 때 처음 표시할 위치를 정할 수 있습니다. Finder를 열 때마다 최근 항목보다 홈, 문서, 다운로드처럼 자신이 자주 쓰는 위치가 먼저 보이는 편이 편하다면 이곳에서 바꿔 보세요.
사이드바에서는 Finder 왼쪽에 표시할 항목을 정합니다. 응용 프로그램, 데스크탑, 문서, 다운로드, 홈, 내장 디스크처럼 실제로 자주 쓰는 항목만 남기면 왼쪽 목록이 덜 복잡해집니다. Finder 설정의 사이드바 항목은 Apple 공식 문서에서도 확인할 수 있습니다.
<Finder 사이드바 설정 2.3>
태그에서는 파일이나 폴더에 붙일 색상 태그와 사이드바에 보일 태그를 정합니다. 모든 색상을 한꺼번에 노출하면 오히려 목록이 복잡해질 수 있으니, 처음에는 빨강·주황처럼 한두 가지 색상만 남겨 두는 것을 권합니다. 태그는 폴더를 대신하는 저장 장소가 아니라, 서로 다른 폴더에 있는 파일을 가로로 묶어 찾는 보조 분류입니다.
<Finder 태그 설정 2.4>
데스크탑·문서 폴더 동기화는 iCloud에서 설정
데스크탑과 문서 폴더를 다른 Apple 기기에서도 사용하고 싶다면 Apple 메뉴 > 시스템 설정 > [사용자 이름] > iCloud > Drive(iCloud Drive) > 이 Mac 동기화 > 데스크탑 및 문서 폴더에서 설정합니다. macOS 버전에 따라 iCloud Drive가 Drive로 표시될 수 있습니다.
이 기능을 켜면 데스크탑과 문서 폴더가 iCloud Drive에 저장되고, 같은 Apple 계정으로 로그인한 다른 기기에서도 접근할 수 있습니다. 반대로 한 기기에서 파일을 삭제하면 다른 기기에서도 삭제될 수 있으므로 iCloud 동기화를 백업과 같은 것으로 생각하면 안 됩니다.
또한 iCloud Drive의 저장 공간을 사용합니다. 저장 공간이 부족하거나 여러 클라우드 서비스가 동시에 데스크탑·문서 폴더를 관리하면 예상하지 못한 동기화 문제가 생길 수 있으므로, 처음에는 한 가지 동기화 방식을 선택하는 편이 안전합니다. 데스크탑과 문서 폴더를 iCloud Drive에 추가하는 방법은 Apple 안내를 참고할 수 있습니다.
iCloud 동기화는 백업이 아닙니다. 중요한 파일은 별도의 백업을 준비하고, 동기화를 켜기 전에 iCloud 저장 공간과 다른 클라우드 앱의 동기화 설정을 확인하세요.
Finder 창의 화면 구성과 탭 사용법
폴더를 한눈에 보는 열 보기
Finder 창 오른쪽 위에는 파일과 폴더를 표시하는 방식이 있습니다. 대표적으로 아이콘 보기, 목록 보기, 열 보기, 갤러리 보기를 사용할 수 있습니다. 저는 폴더 구조를 확인할 때 열 보기(Column View)를 기본으로 사용합니다.
<Finder 보기 방식 버튼 3.1>
열 보기에서는 왼쪽에서 상위 폴더를 선택하면 오른쪽 열에 그 안의 하위 폴더가 이어집니다. 다시 하위 폴더를 선택하면 그 안쪽이 한 칸 더 오른쪽에 나타납니다. 그래서 지금 보고 있는 파일이 어떤 폴더 안에 있는지, 상위에 어떤 폴더가 있는지를 한눈에 확인할 수 있습니다.
<Finder 열 보기와 경로 막대 3.2>
각 폴더의 보기 방식은 보기 > 보기 옵션 보기 또는 Command-J에서 조절할 수 있습니다. 아이콘 크기, 정렬 방식, 표시할 정보 등을 바꿀 수 있지만, 이번 편에서는 네 가지 보기의 차이와 열 보기의 장점만 익혀도 충분합니다. Finder 보기 방식과 보기 옵션은 Apple 공식 안내에 정리되어 있습니다.
새 창과 새 탭 사용하기
Finder의 기본 동작은 새 창으로 여는 방식입니다. 특정 폴더를 지정하지 않은 새 Finder 창은 Command-N으로 열 수 있습니다.
폴더와 문서를 새 탭으로 열고 싶다면 시스템 설정 > 데스크탑 및 Dock > 윈도우 > 문서를 열 때 탭 사용 > 항상으로 설정합니다. 이 옵션을 켜면 폴더를 열 때 창이 계속 늘어나는 대신 기존 Finder 창 안의 새 탭으로 열리는 흐름을 사용할 수 있습니다.
탭은 + 버튼이나 Command-T로 추가할 수 있습니다. 여러 탭을 한 창에 모아 두면 업무, 개인, 자료처럼 작업 영역을 나누어 오갈 때 편합니다. 반대로 한 탭을 별도 창으로 보고 싶다면 탭을 잡고 창 밖으로 끌어내면 됩니다. 폴더를 탭이나 새 창으로 여는 방식은 Apple 공식 안내에서도 확인할 수 있습니다.
왼쪽 사이드바의 기본 영역
Finder 왼쪽에는 자주 사용하는 위치가 모여 있습니다. 이 목록을 폴더 그 자체라고 생각하기보다, 해당 위치로 빠르게 이동하는 바로가기 목록이라고 생각하면 이해하기 쉽습니다.
응용 프로그램: 맥에 설치된 앱이 모여 있는 기본 위치입니다. Dock에서 앱 아이콘을 빼는 것과 응용 프로그램을 삭제하는 것은 다릅니다.
데스크탑: 화면에 보이는 바탕화면 파일과 연결되는 위치입니다. 데스크탑·문서 동기화를 켜면 iCloud Drive 안의 데스크탑과 연결될 수 있습니다.
문서: 홈 폴더 안에 macOS가 기본으로 마련해 둔 문서 위치입니다. iCloud 동기화를 켜면 iCloud Drive에 보관될 수 있습니다.
다운로드: 웹 브라우저나 파일 공유 앱이 받은 파일을 저장하는 기본 위치로 자주 사용됩니다. Chrome처럼 앱의 설정에서 저장 위치를 바꿀 수 있으므로 모든 파일이 항상 이곳에 저장되는 것은 아닙니다.
홈: 로그인한 사용자 개인의 파일과 기본 폴더가 모여 있는 위치입니다.
내장 디스크: 맥의 시작 디스크와 시스템의 최상위 위치를 확인하는 곳입니다.
자주 쓰는 폴더는 Finder 창에서 사이드바의 즐겨찾기 영역으로 직접 드래그해 바로가기로 추가할 수 있습니다. 이때 폴더가 이동하는 것이 아니라 원래 위치에 그대로 남고, 사이드바에는 빠르게 열 수 있는 연결 항목만 생깁니다. 필요 없어지면 사이드바 밖으로 끌어내어 제거할 수 있습니다.
폴더·경로·위치의 기본 개념
폴더는 다단계 바구니이자 주소 체계
비전문가라면 폴더를 파일을 관리하기 위한 “다단계 바구니”라고 생각해도 좋습니다. 큰 바구니 안에 작은 바구니를 넣을 수 있듯이, 폴더 안에는 하위 폴더와 파일을 넣을 수 있습니다.
예를 들어 프로젝트 폴더 안에 문서, 사진, 백업 폴더를 만들고, 그 안에 각각의 파일을 넣을 수 있습니다. 폴더를 잘 나누면 파일을 찾을 때 파일 이름만 기억하는 것이 아니라 “어느 바구니 안에 넣었는가”를 기준으로 찾을 수 있습니다.
이때 경로는 파일을 찾아가는 주소입니다. Macintosh HD > 사용자(Users) > 내 계정(홈 폴더) > 문서 > 프로젝트처럼 왼쪽에서 오른쪽으로 이동하면 더 깊은 폴더로 들어갑니다. Finder의 경로 막대를 켜 두면 지금 보고 있는 위치를 확인하고, 상위 폴더로 바로 이동할 수 있습니다. 경로 막대의 폴더를 Control-클릭하면 해당 위치의 경로를 복사할 수도 있습니다. 파일·폴더·디스크 정보와 경로 막대는 Apple 안내를 참고하세요.
Macintosh HD·사용자·홈 폴더
Finder의 내장 디스크 아래에서 보이는 Macintosh HD는 맥의 시작 디스크 이름입니다. 터미널에서 사용하는 최상위 경로인 루트(/)를 설명할 때 이 위치와 연결해 이해하면 쉽습니다.
그 안의 사용자(Users) 폴더에는 이 맥을 사용하는 사람들의 홈 폴더가 있습니다. 사용자(Users) > 내 계정 이름으로 들어가면 로그인한 사용자의 홈 폴더가 나오고, 그 안에 데스크탑, 문서, 다운로드, 사진, 음악, 동영상 같은 개인 파일 위치가 있습니다.
System과 Library 같은 폴더는 macOS와 앱이 사용하는 영역입니다. 이름을 바꾸거나 다른 곳으로 옮기면 운영체제나 앱이 정상적으로 동작하지 않을 수 있으므로, 초보자라면 개인 파일을 홈 폴더 안에서 관리하는 편이 안전합니다. Apple도 맥에 기본으로 제공되는 폴더 중 일부는 이름을 바꾸거나 이동하지 않는 것이 좋다고 안내합니다. macOS 기본 폴더의 역할은 Apple 공식 문서에서 확인할 수 있습니다.
파일이 실제로 저장되는 방식
폴더 트리는 단순히 사람이 보기 좋은 그림만은 아닙니다. macOS의 파일 시스템은 파일명, 폴더, 권한, 메타데이터를 디렉터리 구조로 관리하고, 파일 내용은 저장 장치의 영역과 연결합니다. 따라서 Finder에 보이는 폴더 구조는 파일 시스템이 관리하는 실제 논리 구조입니다.
다만 화면에서 보이는 폴더 구조와 파일 내용이 디스크에 저장되는 물리적인 위치가 언제나 일대일로 같은 것은 아닙니다. 파일 내용은 저장 장치의 여러 영역에 나뉘어 보관될 수 있지만, 운영체제가 파일 시스템의 정보를 이용해 하나의 파일처럼 보여 줍니다.
초보자에게는 “폴더는 파일 이름과 위치를 기록한 주소 체계이고, 실제 파일 내용은 저장 장치에 보관된다”고 설명하면 충분합니다. APFS의 세부 자료구조까지 이해해야 Finder를 사용할 수 있는 것은 아닙니다.
AirDrop은 폴더가 아니라 전송 화면
Finder 사이드바에 있는 AirDrop은 폴더가 아닙니다. 맥, 아이폰, 아이패드처럼 가까이에 있는 Apple 기기를 찾아 파일을 보내고 받는 무선 전송 화면입니다.
AirDrop 창에 상대방 기기가 나타나면 파일을 그 기기 위로 끌어 보내고, 받은 사람은 수락 여부를 선택합니다. 받은 파일은 파일의 종류와 수신 동작에 따라 다운로드 폴더 등에 저장될 수 있으므로, AirDrop 자체에 파일이 계속 쌓인다고 생각하면 안 됩니다. AirDrop의 전송 방식은 Apple 공식 안내에서 확인할 수 있습니다.
Wi-Fi와 Bluetooth가 켜져 있어야 하고, 기기 사이의 거리와 수신 허용 범위도 영향을 줍니다. AirDrop은 다음 편에서 실제 파일을 보내고 받는 순서와 수신 설정을 따로 다루겠습니다.
마무리
이번 편에서 기억할 내용은 네 가지입니다.
Finder는 맥의 파일 탐색기이며, 메뉴는 창 안이 아니라 화면 최상단에 있습니다.
도구 막대, 경로 막대, 상태 막대를 켜면 파일을 조작하고 현재 위치와 상태를 확인하기 쉬워집니다.
열 보기, 탭, 사이드바 바로가기를 조합하면 폴더 구조를 한눈에 보고 자주 쓰는 위치로 빠르게 이동할 수 있습니다.
iCloud는 동기화 기능이고 AirDrop은 전송 화면이며, 둘 다 일반 폴더와는 다른 개념입니다.
다음 편에서는 Finder에서 파일 확장자를 확인하는 방법, Quick Look으로 파일을 빠르게 미리 보는 방법, 압축 파일과 앱 삭제, 스크린샷 저장 위치를 이어서 살펴보겠습니다.
AI 모델을 고를 때 7B, 14B, 70B 같은 숫자를 자주 봅니다. 이 숫자는 모델이 학습한 파라미터(parameter)의 개수입니다. 숫자가 크면 보통 더 많은 패턴과 지식을 표현할 여지가 있지만, 답변 품질·속도·메모리가 숫자 하나로 결정되지는 않습니다. AI 서버의 GPU 병목과 GPU 클라우드 비용을 함께 보면 이 숫자가 왜 인프라 비용으로 이어지는지도 이해하기 쉽습니다.
파라미터와 가중치는 무엇인가
신경망은 입력을 다음 층으로 전달하면서 수많은 곱셈과 덧셈을 합니다. 이때 학습으로 조정되는 숫자가 파라미터입니다. 가중치(weight)는 연결마다 곱해지는 핵심 파라미터를 가리키는 말이고, 편향·임베딩·정규화 값 등도 넓은 의미의 파라미터에 포함됩니다. 일상적인 설명에서는 두 단어를 거의 같은 뜻으로 쓰지만 완전히 같은 개념은 아닙니다.
모델의 “크기”는 대개 파라미터 수로 말합니다. 하지만 실행에 필요한 메모리는 파라미터 수 × 숫자 정밀도로 먼저 계산해야 합니다.
저장 형식
파라미터 1개에 필요한 대략적인 메모리
70B 가중치만 계산한 값
FP16/BF16
2바이트
약 140GB
INT8
1바이트
약 70GB
4비트 양자화
0.5바이트
약 35GB
실제 VRAM에는 가중치 외에도 KV 캐시(긴 대화 기억), 실행 버퍼, 프레임워크 오버헤드와 여유 공간이 필요합니다. 그래서 “70B가 4비트면 35GB”는 하한선이지 35GB GPU에서 항상 쾌적하다는 뜻이 아닙니다. 컨텍스트 길이와 동시 사용자 수가 늘면 필요한 메모리도 커집니다.
필자의 부족한 지식으로 예를 들자면 파라미터는 인간의 뇌의 용량(연결된 뉴런의 갯수라고 표현해야 할까요?), 가중치는 학습시 우선시 학습하는 카테고리 정도로 이해하면 편할 듯합니다.
<NVIDIA H100 공식 이미지. H100 제품 사양은 80GB HBM3 메모리와 94GB H100 NVL을 구분해 제시합니다. 출처: NVIDIA>
파라미터 크기별 현실적인 실행선
아래 표는 “모델을 띄울 수 있느냐”를 가중치 메모리와 일반적인 추론 여유 공간을 기준으로 보수적으로 나눈 것입니다. 양자화 방식, 컨텍스트, CUDA·Metal 커널, 모델 구조에 따라 결과가 달라지므로 절대적인 컷오프가 아닙니다.
하드웨어
실사용을 기대할 수 있는 범위
해석
RTX 5090 32GB
7B14B는 편안함, 20B27B는 4비트 중심
30B 이상은 저컨텍스트·오프로딩 없이는 부담
H100 80GB 1장
30B 전후 BF16, 70B 4비트
40B BF16은 가중치만 약 80GB라 실사용 여유가 없음
H100 80GB 4장
70B BF16은 충분, 100B~120B는 배치·컨텍스트에 따라 가능
150B 이상은 설계와 메모리 분할을 따져야 함
H100 80GB 4장, 300B급
일반적인 Dense BF16은 불가
300B는 BF16 가중치만 약 600GB. MoE도 전체 가중치는 저장해야 함
NVIDIA도 H100 NVL을 Llama 2 70B용으로 소개하며 188GB HBM 구성을 제시합니다. 이 자료는 “70B는 80GB 한 장에 BF16으로 넉넉히 들어간다”는 식의 주장을 반박하는 실제 제품 사례입니다. 70B 4비트는 한 장에서 가능할 수 있지만, BF16 70B는 H100 NVL처럼 메모리를 합친 구성이 더 자연스럽습니다.
RTX 5090은 32GB GDDR7이라 개인용 양자화 모델의 현실적인 상한을 넓혀줍니다. 다만 14B와 30B의 체감 속도 차이는 모델 파일 크기뿐 아니라 메모리 대역폭과 커널 최적화에도 좌우됩니다. 서버에서는 GPU 여러 장의 VRAM을 단순히 더하는 것만으로 끝나지 않고, NVLink·PCIe 통신과 텐서 병렬화 비용이 생깁니다.
M4 맥북에서 돌려볼 만한 오픈 웨이트 모델
필자가 사용하는 M4 맥북 프로 48GB 통합 메모리에서는 운영체제와 앱이 메모리를 함께 사용합니다. 따라서 48GB 전부를 모델에 할당할 수 없습니다.
20B~32B 4비트: 실행은 가능할 수 있지만 긴 컨텍스트와 빠른 응답을 동시에 기대하기 어렵습니다. 코딩·추론용은 같은 크기라도 양자화 품질을 확인해야 합니다.
70B 4비트: 48GB 맥북에서는 파일 크기와 런타임 여유를 생각하면 일반적인 추천이 아닙니다. 128GB 통합 메모리 상위 맥이라도 노트북다운 속도와 안정성을 보장하지 않습니다.
설치 방법은 Ollama, LM Studio, MLX가 진입장벽이 낮습니다. 맥북 로컬 AI의 장점은 최고 성능보다 개인 문서가 외부 서버로 나가지 않는 통제력과 낮은 진입비용에 있습니다. M4 세대의 통합 메모리 구성은 Apple의 MacBook Pro 사양에서 확인할 수 있습니다.
<MacBook Pro M4 공식 제품 이미지. 통합 메모리는 CPU와 GPU가 공유하므로 모델에 전부 사용할 수 없습니다. 출처: Apple>
GPU 가격은 왜 체감이 다른가
2026년 8월 초 확인 가능한 공개 자료를 보면 소비자 GPU와 데이터센터 GPU의 가격 체계가 완전히 다릅니다.
파라미터 수는 모델의 잠재적인 표현 용량을 보여주지만, 실제 사용성은 정밀도·양자화·컨텍스트·메모리 대역폭·소프트웨어 최적화까지 합쳐서 결정됩니다. 지금은 M4 48GB에서 8B~14B 모델 정도가 한계로 보입니다. 그래도 이정도로 집에서 돌려볼 수 있게된 현실게 감사할 따름이죠. H100 1장은 70B 양자화, H100 4장은 70B BF16부터 현실성이 높아집니다. 뭐 그래도 일반인들이 집에서 돌리기에는 무리가 있죠.
나의 한줄은 이렇습니다. 어서 빨리 내 집 컴퓨터에 개인용 모델을 설치하고, 나만 사용하는 AI 에이전트를 쓰고 싶다. 아마 미래는 모델이 더 작아지고 지능형 그래픽카드가 더 좋아지는 방향으로 발전할 것입니다. 이미 그런시대가 코앞에 와있을지 모를 일이죠. AI의 발전을 보고 있으면 매일매일을 기대하게 됩니다.
