7장. 도구와 연결하라
이제부터 ChatGPT는 말만 잘하는 동료가 아니라, 실제로 일의 현장에 들어가는 동료가 된다.
앞 장들에서 우리는 일을 자르고, 리서치를 맡기고, 실행 가능한 초안을 받는 법을 살펴봤다. 그런데 여기서 많은 사람이 한 번 더 멈춘다. 초안을 잘 받았는데도, 여전히 메일은 내가 열고, 일정은 내가 확인하고, 문서는 내가 찾아 붙여 넣고, 코드 저장소도 내가 돌아다닌다. 그러면 ChatGPT는 여전히 채팅창 안에 갇힌 조력자일 뿐이다.
진짜 변화는 그 다음에 일어난다. 메일, 캘린더, 문서, 코드 저장소 같은 도구와 연결될 때다. 그 순간 ChatGPT는 '대답하는 기계'에서 '업무 흐름에 참여하는 사람'으로 성격이 바뀐다.
쉽게 말해 보자. 지금까지의 ChatGPT가 회의실 안에서 아이디어만 내는 동료였다면, 연결된 ChatGPT는 회의록을 읽고, 관련 문서를 찾고, 다음 회의 시간을 확인하고, 답장 초안까지 준비하는 동료다. 같은 모델이어도 체감 성능이 달라지는 이유가 여기에 있다.
채팅창에만 있으면 아직 반쪽짜리다
사람들이 ChatGPT를 오래 써도 생산성이 기대만큼 안 오르는 이유는 대개 비슷하다. AI에게 생각은 맡기지만, 맥락은 계속 손으로 옮기기 때문이다.
예를 들어 이런 장면을 떠올려 보자. 내일 중요한 고객 미팅이 있다. 당신은 먼저 메일함에서 최근 대화를 찾고, 드라이브에서 제안서 최신본을 열고, 캘린더에서 회의 시간을 확인하고, 지난주 회의록에서 미해결 이슈를 복사한 뒤, 그제서야 ChatGPT에게 '내일 미팅 준비 도와줘'라고 말한다.
이건 AI를 쓴 것이 맞다. 하지만 일을 맡긴 것은 아니다. 아직도 당신이 택배 기사처럼 맥락을 실어 나르고 있다.
OpenAI가 내놓은 앱 연결 방식의 핵심은 바로 이 지점을 바꾸는 데 있다. ChatGPT는 외부 앱 안에서 워크플로우를 실행하고, CRM·코드베이스·문서·분석 도구의 최신 정보를 끌어와 답변할 수 있게 설계되고 있다.1 다시 말해, 당신이 맥락을 옮겨 담는 수고를 줄여 주는 것이 연결의 본질이다.
그래서 연결은 '기능 추가'가 아니다. 업무 동선에서 불필요한 왕복을 없애는 일이다. 탭을 열었다 닫았다 하는 횟수가 줄어들고, 복사해서 붙여 넣는 손동작이 줄어들고, 같은 맥락을 여러 번 설명하는 피로가 줄어든다. 그때 비로소 AI는 체감상 똑똑해진다.
진짜 강력한 연결은 내 도구를 읽을 때 생긴다
많은 사람이 연결이라고 하면 유명한 외부 앱 몇 개를 떠올린다. 물론 그것만으로도 충분히 유용하다. 하지만 더 중요한 건 '내가 실제로 일하는 시스템'을 ChatGPT가 이해하게 만드는 일이다.
OpenAI의 앱 생태계와 Apps SDK는 MCP(Model Context Protocol)라는 개방형 표준을 바탕으로 확장되고 있다.2 이 말이 어려워 보이면 이렇게 이해하면 된다. 앞으로 중요한 것은 어떤 AI가 제일 말을 예쁘게 하느냐보다, 어떤 AI가 내 도구와 내 데이터에 자연스럽게 붙을 수 있느냐다.
즉, 진짜 생산성은 범용 지능에서만 오지 않는다. 사내 문서함, 고객 기록, 이슈 트래커, 코드 저장소, 팀 메일함처럼 실제 업무 맥락이 모여 있는 곳과 연결될 때 나온다.
여기서 흔한 오해가 하나 있다. 많이 연결할수록 좋다고 생각하는 것이다. 그렇지 않다. 많이 연결하는 것보다, 자주 쓰는 흐름 하나를 제대로 연결하는 편이 훨씬 강하다.
예를 들어 당신이 영업을 한다면, Gmail과 캘린더와 제안서 폴더만 잘 연결해도 하루가 달라질 수 있다. 개발자라면 GitHub와 문서 저장소만 붙어도 회의 준비와 코드 맥락 파악 속도가 확 올라간다. 마케터라면 문서함과 메일, 분석 리포트가 먼저다. 핵심은 화려한 연결 개수가 아니라, 가장 자주 반복되는 병목을 먼저 없애는 것이다.
먼저 구분하라: 읽는 연결과 행동하는 연결
도구 연결을 이야기할 때 가장 먼저 해야 할 구분이 있다. 읽는 연결과 행동하는 연결이다.
읽는 연결은 ChatGPT가 메일을 검색하고, 문서를 찾아 읽고, 일정을 확인하고, 저장소 안의 변경 사항을 파악하는 식이다. 아직은 당신 대신 세상에 무언가를 쓰거나 보내지 않는다. 요약, 검색, 정리, 초안 작성이 중심이다.
행동하는 연결은 한 걸음 더 나간다. 메일 초안을 실제 도구 안에 만들고, 문서를 생성하고, 회의를 잡고, 특정 시스템에 기록을 남기는 식이다. 이 단계부터는 편리함이 커지는 만큼 실수의 비용도 커진다.
그래서 이런 기능은 기본적으로 보수적으로 다루는 편이 맞다. 실제로 ChatGPT Business의 쓰기 액션은 기본 비활성화 상태로 제공되고, 관리자가 앱별·동작별로 따로 켜야 한다.3 이 설계는 귀찮아서가 아니라, 신뢰를 단계적으로 쌓기 위해서다.
실무 감각으로 바꾸어 말하면 이렇다. 처음부터 '알아서 처리해'라고 하지 말고, 먼저 '찾아줘', '정리해줘', '초안 만들어줘'부터 시작하라. 그리고 충분히 검증된 흐름에서만 '기록해줘', '만들어줘', '예약해줘'로 넘어가라.
당신이 새 직원에게 첫날부터 법인카드와 서버 접근권한을 한꺼번에 주지 않는 것과 같은 이치다.
메일을 연결할 때는 답장이 아니라 맥락부터 맡겨라
메일 연결은 체감 효율이 가장 빨리 오는 분야다. 대부분의 지식 노동자는 하루에도 몇 번씩 메일함을 들락날락한다. 그런데 메일 업무의 상당수는 사실 '쓰기'보다 '읽고 판단하기'에 시간이 더 많이 든다.
ChatGPT가 메일함을 읽을 수 있게 되면 가장 먼저 좋아지는 것은 우선순위 정리다. 누가 답장을 기다리는지, 어떤 스레드가 오늘 처리 대상인지, 어떤 메일이 단순 참고인지, 어디에 액션 아이템이 숨어 있는지를 빠르게 뽑아낼 수 있다. 답장을 바로 보내는 것보다 이 단계의 가치가 더 크다.
메일 연결의 좋은 출발점은 보통 다음과 같다.
읽지 않은 메일을 긴급도별로 나누기
특정 고객이나 프로젝트 관련 스레드만 모아 흐름 요약하기
긴 대화에서 결정 사항과 미결정 사항만 추출하기
회신이 필요한 메일에 대해 초안 답장 만들기
이 순서가 중요한 이유는, 메일은 텍스트 같아 보여도 사실 관계와 맥락의 덩어리이기 때문이다. 회신 초안을 잘 쓰는 것보다, 어떤 메일에 지금 답해야 하는지를 잘 가려내는 편이 훨씬 실무적이다.
또 하나 중요한 점은 메일 계정의 경계를 나누는 것이다. 개인 메일함 전체를 무턱대고 연결하기보다, 업무용 계정이나 공유 메일함부터 시작하는 편이 안전하다. 특히 Outlook 계열 도구는 공유 메일함과 위임된 메일함·캘린더를 별도 액션과 권한 범위로 다룰 수 있다.4 이 말은 곧, '내 모든 개인 메일'이 아니라 '이 팀 업무에 필요한 범위'만 나눠 줄 수 있다는 뜻이다.
메일 연결에서 가장 흔한 실수는 자동 답장을 꿈꾸는 것이다. 하지만 초반에는 자동 발송보다 자동 분류와 초안 생성이 훨씬 낫다. 메일은 문장보다 타이밍이 중요하고, 타이밍보다 관계가 중요하다. 특히 사과, 거절, 가격 조정, 일정 변경 같은 메일은 마지막 인간 검토가 반드시 있어야 한다.
캘린더를 연결할 때는 시간을 읽게 하라
캘린더 연결은 생각보다 과소평가된다. 사람들은 일정 확인 정도로만 생각하지만, 실제로는 업무 맥락의 지도 역할을 하기 때문이다.
좋은 동료는 시간을 안다. 오늘 오후에 중요한 회의가 있다는 사실, 내일은 이동 시간이 길다는 사실, 이번 주에 비슷한 주제의 회의가 이미 두 번 있었다는 사실을 안다. 이 정보를 모르고 일하는 AI는 늘 맥락이 반쯤 비어 있다.
캘린더가 연결되면 ChatGPT는 단순히 '일정 확인기'가 아니라 준비 비서처럼 움직일 수 있다. 예를 들어 내일 회의가 있다면 관련 문서를 찾고, 최근 메일 스레드를 읽고, 지난 회의 액션 아이템을 정리해 회의 준비 브리프로 바꿔 줄 수 있다. 또는 이번 주 빈 시간을 찾아 깊은 작업 블록을 제안하게 할 수도 있다.
여기서 중요한 원칙은 하나다. 시간을 읽게 하되, 함부로 약속하게 하지는 마라.
회의 시간 추천, 충돌 일정 탐지, 준비 체크리스트 작성까지는 AI가 아주 잘한다. 하지만 외부인과의 확정 약속 생성, 민감한 일정 변경, 참석자 조정이 얽힌 회의 예약은 사람 승인 단계를 남겨 두는 편이 낫다. 일정 하나 잘못 잡히면 문장 실수보다 복구 비용이 더 크기 때문이다.
캘린더에는 또 다른 함정이 있다. 일정 설명란에는 종종 외부인이 쓴 문장, 링크, 임시 메모, 과장된 요청이 그대로 들어 있다. 즉, 캘린더도 신뢰된 명령 체계가 아니라 외부 입력이 섞인 데이터다. 이 감각을 놓치면 AI가 일정 설명을 너무 곧이곧대로 받아들일 수 있다.
문서 연결은 '복붙 지옥'에서 빠져나오는 가장 쉬운 길이다
문서 연결의 가치는 놀라울 만큼 단순하다. 같은 문서를 여러 번 설명하지 않아도 된다.
많은 사람이 ChatGPT를 쓰면서 가장 자주 하는 일이 무엇일까. 문서를 열고, 필요한 부분을 복사하고, 채팅창에 붙여 넣고, 다시 설명을 붙이는 일이다. 이것은 아주 익숙하지만, 동시에 가장 비싼 낭비다. 시간이 들 뿐 아니라, 최신본이 아닌 문서를 잘못 붙여 넣거나, 앞뒤 문맥을 빼먹거나, 표와 숫자를 누락하기 쉽다.
문서 연결이 잘 되면 ChatGPT는 '붙여 준 일부'가 아니라 '실제 문서'를 읽는다. 이 차이는 크다. 일부만 본 AI는 늘 추측을 섞게 되지만, 실제 문서를 읽는 AI는 적어도 같은 출발선에서 생각할 수 있다.
문서 연결에서 중요한 것은 두 가지다. 첫째, 어디가 기준 문서인지 정해 두는 것이다. 둘째, 항상 원문으로 돌아갈 수 있게 만드는 것이다.
예를 들어 회사 소개서, 제안서 템플릿, 브랜드 가이드, 제품 FAQ, 회의록 폴더 같은 기준 문서가 있다면 그것이 '진실의 원본'이어야 한다. ChatGPT에게는 그 원본을 읽게 하고, 당신은 결과물을 받을 때 항상 어떤 문서를 바탕으로 했는지 함께 확인해야 한다.
문서 연결을 잘 쓰는 사람은 대개 이런 식으로 시킨다.
'드라이브의 최신 제안서와 지난 두 번의 고객 피드백 문서를 읽고, 이번 미팅에서 수정해야 할 포인트만 5개로 요약해줘.'
이 요청의 좋은 점은 단순히 요약을 요청한 것이 아니라, 어떤 문서를 근거로 판단해야 하는지를 명확히 했다는 데 있다. 문서 연결은 마법이 아니다. 여전히 기준 문서를 지정하는 사람은 당신이다.
코드 저장소 연결은 개발자만의 기능이 아니다
코드 저장소 연결을 보면 많은 비개발자가 바로 겁을 먹는다. '저건 엔지니어들 이야기 아닌가요?' 그런데 실제로는 그렇지 않다. 코드 저장소는 단지 코드가 있는 곳이 아니라, 제품의 변경 기록과 작업 맥락이 모이는 곳이기 때문이다.
GitHub 같은 저장소가 ChatGPT와 연결되면 할 수 있는 일이 생각보다 많다. 어떤 기능이 어디에서 처리되는지 찾기, 특정 이슈와 관련된 변경 내역을 훑기, 풀 리퀘스트를 요약하기, 새로 합류한 사람에게 코드 흐름을 설명하기, 기술 문서 초안을 만들기 같은 일은 개발자뿐 아니라 기획자와 PM에게도 직접 도움이 된다. OpenAI는 워크스페이스 설정에서 ChatGPT GitHub Connector를 켜고 Codex 기능을 사용할 수 있는 관리 경로를 별도로 안내하고 있다.5
이 영역에서 가장 좋은 출발은 역시 읽기다. '이 코드를 고쳐'보다 '이 변경이 무엇을 바꿨는지 설명해줘', '업로드 처리가 어디에서 일어나는지 찾아줘', '이 PR의 위험 지점을 요약해줘'부터 시작하는 편이 훨씬 안전하다.
조금 더 나아가면 자동화도 가능하다. 예를 들어 GitHub Actions 안에서 PR이 열릴 때 AI가 변경 파일이나 패치를 읽고 코드 리뷰 댓글을 다는 흐름을 만들 수 있다. 실제 GitHub Marketplace의 예시 액션도 OpenAI API 키를 시크릿으로 저장하고, PR 이벤트를 트리거로 받아 리뷰를 남기는 방식을 제시한다.6
하지만 바로 여기서 권한 감각이 중요해진다. GitHub Actions는 permissions 키로 contents, issues, pull-requests 같은 범위를 읽기·쓰기·없음으로 세밀하게 제한할 수 있고, 지정하지 않은 범위는 none으로 처리된다.7 쉽게 말해, PR에 댓글만 달면 되는 자동화에 저장소 전체 쓰기 권한까지 줄 이유는 없다.
코드 저장소 연결에서 기억할 원칙은 단순하다. 코드 이해는 넓게, 코드 변경은 좁게. 읽는 권한은 비교적 넓게 줄 수 있어도, 쓰는 권한은 아주 구체적인 작업에만 제한적으로 주는 편이 맞다.
여러 도구를 잇는 순간, 비로소 워크플로우가 된다
하나의 앱만 연결해도 편해진다. 하지만 두세 개가 이어지는 순간부터는 '편리함'이 아니라 '업무 방식'이 바뀐다.
실전에서는 거창한 자동화보다 다음 네 단계를 의식하는 것이 좋다.
트리거: 무슨 일이 시작점인가. 새 메일, 내일 일정, 새 PR, 회의록 업로드 같은 것.
컨텍스트 수집: 어떤 도구에서 어떤 정보를 읽어와야 하는가.
변환: 읽어 온 정보를 요약, 분류, 초안 작성, 체크리스트 생성 같은 형태로 바꾼다.
승인과 실행: 사람이 확인한 뒤 발송, 저장, 등록, 예약 같은 실제 행동으로 넘긴다.
이 구조로 보면 연결은 더 이상 기술 얘기가 아니다. 그냥 일을 설계하는 이야기다.
예를 들어 이런 흐름을 만들 수 있다.
내일 캘린더에 고객 미팅이 잡혀 있다. ChatGPT가 캘린더에서 회의를 확인하고, 메일에서 최근 스레드를 읽고, 드라이브에서 최신 제안서를 찾고, 지난 회의록에서 미해결 항목을 꺼내 와서 '10분 회의 준비 브리프'를 만든다. 당신은 그걸 보고 회의에 들어간다.
혹은 새 PR이 올라오면 ChatGPT가 저장소 변경 내용을 요약하고, 문서 저장소의 개발 가이드를 기준으로 잠재적 위험 포인트를 정리해 리뷰 초안을 남긴다. 팀원은 그 초안을 참고해 실제 검토를 더 빠르게 끝낸다.
이런 순간에 ChatGPT는 더 이상 채팅 상대가 아니다. 앞단에서 맥락을 모으고, 중간에서 정리하고, 뒷단에서 다음 행동을 준비하는 워크플로우의 일부가 된다.
권한과 보안은 귀찮은 부록이 아니라 설계의 중심이다
도구를 연결하는 순간, 대부분의 사용자는 두 극단으로 흔들린다. 하나는 '무서우니까 아무것도 연결하지 말자'이고, 다른 하나는 '편하려면 다 열어 주자'다. 둘 다 좋지 않다.
현실적인 답은 작게 열고, 자주 검토하고, 되돌릴 수 있게 만드는 것이다.
보안 관점에서 특히 중요한 원칙은 다음과 같다.
최소 권한만 준다. 읽기만 필요한데 쓰기 권한까지 주지 않는다.8
처음에는 읽기 연결부터 시작한다. 쓰기 액션은 검증된 흐름에만 붙인다.3
개인 계정과 업무 계정을 분리한다. 가능하면 공유 메일함, 팀 캘린더, 프로젝트 저장소처럼 범위가 분명한 자원부터 연결한다.4
민감 정보는 아예 분리한다. 인사, 재무, 법무, 생산 시스템처럼 실수 비용이 큰 영역은 별도 정책 없이는 연결하지 않는다.8
로그와 감사 흔적을 남긴다. 누가 어떤 연결을 썼고, 어떤 액션이 실행됐는지 나중에 볼 수 있어야 한다.8
언제든 끊을 수 있어야 한다. 연결 해제, 권한 철회, 시크릿 교체가 쉬운 구조가 필요하다.6
이 원칙들이 중요한 이유는, 연결된 AI의 위험은 보통 '모델이 멍청해서'가 아니라 '권한이 넓어서' 커지기 때문이다.
보안 연구자들이 반복해서 지적하는 문제도 이 부분이다. 에이전트형 AI는 사용자의 권한을 그대로 이어받아 행동하기 쉽고, 간접 프롬프트 인젝션 같은 공격에 흔들릴 수 있으며, 시스템 로그에서 사람의 행동과 AI의 행동을 구분하기 어려워질 수 있다.9 어려운 말 같지만 실무적으로 번역하면 이렇다.
메일 본문, 문서, 일정 설명, 외부 웹페이지에 적힌 내용까지 모두 '신뢰된 명령'처럼 받아들이면 안 된다. 그것들은 어디까지나 입력 데이터다. 그리고 입력 데이터는 언제든 틀릴 수 있고, 악의적일 수도 있다.
그러니 중요한 액션 앞에는 항상 사람 확인 단계를 두는 편이 낫다. 특히 외부 발송, 삭제, 금전 관련 처리, 고객 정보 변경, 프로덕션 환경 변경 같은 일은 더욱 그렇다.
어디까지 줄 것인가에 대한 현실적 기준
그렇다면 실제로 어디까지 권한을 줘야 할까. 이 질문에는 멋진 정답보다 지루한 현실 기준이 더 도움이 된다.
먼저, 실수해도 되돌릴 수 있는가를 보라. 되돌릴 수 있다면 연결과 자동화를 시도해 볼 여지가 있다. 초안 작성, 문서 분류, 태그 정리, 회의 준비 메모 생성 같은 일은 보통 이 범주다.
다음으로, 틀렸을 때 누가 바로 잡을 수 있는가를 보라. 팀 리더나 담당자가 짧게 검토하면 충분한가, 아니면 전문 판단이 필요한가. 후자라면 자동화를 늦추는 편이 맞다.
마지막으로, 외부 세계에 흔적이 남는가를 보라. 고객에게 메일이 나가고, 캘린더 초대가 발송되고, 저장소에 댓글이 남고, 문서가 공식 기록으로 저장되는 순간부터는 '편의성'보다 '책임'이 더 중요해진다.
그래서 현실적인 순서는 대개 이렇다.
읽기 연결 → 요약과 초안 → 사람 검토 → 제한적 쓰기 액션 → 좁은 범위의 자동화.
이 순서를 건너뛰고 처음부터 완전자동을 노리면, 성과보다 불신이 먼저 쌓인다. 반대로 이 순서대로 가면 팀 안에서 자연스럽게 신뢰가 생긴다. 사람들은 AI를 믿어서 쓰는 것이 아니라, 통제 가능하다고 느껴서 쓰게 된다.
잘 연결한 사람은 더 적게 복붙하고 더 많이 판단한다
도구 연결의 진짜 효과는 시간을 줄이는 데만 있지 않다. 사람의 역할을 바꾸는 데 있다.
메일과 문서를 찾아다니며 복사하고 붙이는 시간, 회의 준비를 위해 여기저기 흩어진 맥락을 주워 담는 시간, 저장소와 이슈 트래커를 오가며 변경 사항을 읽는 시간은 대부분 고된 노동이다. 연결이 잘 되면 이 시간이 줄어든다.
그러면 남는 일은 무엇일까. 우선순위를 정하는 일, 예외를 판단하는 일, 관계를 고려하는 일, 최종 책임을 지는 일이다. 다시 말해 사람이 더 사람다운 쪽으로 밀려난다.
이 변화는 꽤 중요하다. ChatGPT를 채팅창에만 두면 당신은 여전히 손발로 일한다. 하지만 도구와 연결하면 손발의 일부를 넘기고, 판단과 설계 쪽으로 이동할 수 있다. 바로 이 지점에서 '도구'가 '동료'로 바뀐다.
결국 연결은 더 많은 기능이 아니라 더 적은 전환이다
많은 기능을 아는 사람보다, 전환 비용을 줄이는 사람이 AI를 잘 쓴다.
메일에서 문서로, 문서에서 캘린더로, 캘린더에서 저장소로, 다시 채팅창으로 계속 뛰어다니는 구조에서는 아무리 좋은 모델을 써도 피곤하다. 반대로 필요한 맥락이 제때 모이고, 요약되고, 다음 행동으로 이어지는 구조가 있으면 같은 모델로도 훨씬 큰 결과를 낼 수 있다.
그래서 7장의 핵심은 화려한 연결 목록이 아니다. 단 하나다.
ChatGPT는 연결될수록 똑똑해지는 것이 아니라, 연결될수록 덜 추측하게 된다.
그리고 AI가 덜 추측할수록, 당신은 덜 설명하고 더 많이 결정할 수 있다.
이 장의 핵심
도구 연결의 목적은 채팅을 편하게 만드는 것이 아니라, 업무 흐름 안으로 ChatGPT를 들여보내는 데 있다. 메일, 캘린더, 문서, 코드 저장소와 연결될 때 AI는 비로소 실제 일을 준비하는 동료처럼 움직이기 시작한다.
처음부터 모든 권한을 줄 필요는 없다. 읽기 연결로 시작하고, 요약과 초안을 맡기고, 사람 검토를 거친 뒤, 검증된 흐름에만 제한적으로 쓰기 액션을 붙이는 편이 가장 현실적이다.
잘 연결하는 사람은 앱을 많이 붙이는 사람이 아니다. 자주 반복되는 병목 하나를 골라, 필요한 맥락만 읽게 하고, 중요한 액션 앞에는 멈춤 지점을 남겨 두는 사람이다. 챗봇으로 끝내지 않고 워크플로우에 연결하는 순간, ChatGPT는 비로소 '써 보는 도구'가 아니라 '같이 일하는 동료'가 된다.
참고
2Introducing apps in ChatGPT and the new Apps SDK - OpenAI
3ChatGPT can now act inside Outlook, Google Docs, and your calendar
4Outlook Email and Calendar app for ChatGPT - OpenAI Help Center
5Admin Setup - Codex | OpenAI Developers
6ChatGPT GitHub Actions · Actions · GitHub Marketplace · GitHub
7GitHub - Understanding Workflow Permissions
8Security, Privacy & Permissions in ChatGPT Apps — Risk Factors & Best Practices
9OpenAI chatgpt agent: a ciso's guide to the security implications and how to mitigate them
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.