한 번 연결한 MCP, 다른 환경에서도 그대로 쓸 수 있을까? Liner Actions 일주일 사용기

*이 글은 라이너와 함께 요즘IT 브랜디드 콘텐츠로 제작했습니다.

MCP를 잘 붙여 두면 일이 확 줄어듭니다. 분기마다 성과를 정리할 때면 Jira 티켓과 Confluence 문서, 공유 드라이브의 지표 문서를 하나씩 열어 양식에 옮기느라 2~3시간이 갔는데, Atlassian MCP를 붙인 뒤로는 기준만 주면 에이전트가 맥락을 모아 초안을 만들어 줘서 10분이면 끝났습니다.

문제는 늘 붙이는 과정이었습니다. Datadog MCP는 사내 보안 정책 때문에 프로젝트 범위로 설정하고 API 키를 따로 넣었지만 인증 실패가 계속 나서 끝내 포기했어요. 요즘은 에이전트에게 “이 MCP 붙여 줘”라고 하면 설정까지 해 주니 처음 붙이는 일은 많이 쉬워졌습니다. 그런데 같은 연결을 되풀이하는 품은 그대로 남았습니다. 새 프로젝트를 열면 서비스마다 다시 붙이고, 다른 컴퓨터로 가면 로그인과 키 설정을 또 하고, 웹이나 폰, 다른 에이전트에서는 아예 처음부터 해야 했죠.

그러다 라이너의 의뢰로 Liner Actions를 일주일 넘게 써 볼 기회가 생겼습니다. MCP 서버 하나를 등록하고 서비스 연결을 라이너 계정에 한 번 해 두면, 다른 환경과 에이전트에서도 그 연결을 그대로 쓸 수 있다는 도구입니다. 정말 그런지 평소 쓰는 GitHub·Notion·Sender·Mixpanel을 연결해 두고 맥북의 Claude Code, Claude Code on the web, 폰의 Claude 앱, Codex를 오가며 확인해 봤습니다.

이 글에서는 먼저 직접 MCP를 하나하나 붙일 때와 Liner Actions를 사용할 때 무엇이 다른지, 다른 환경과 에이전트로 옮길 때 다시 해야 하는 일이 실제로 얼마나 줄었는지를 비교합니다. 이어서 Liner Actions를 붙여 두는 동안 컨텍스트를 얼마나 차지하는지, 일주일 동안 실제 업무에 써 보니 어땠는지, 에이전트에게 쓰기 작업을 맡길 때 무엇을 확인해야 하는지를 차례로 다룹니다. 마지막에는 Liner Actions가 잘 맞는 사람은 어떤 사람인지도 정리했습니다. 여러 서비스를 연결해 두고 프로젝트나 컴퓨터, 에이전트를 오가며 일하는 분이라면 참고해 보셔도 좋겠습니다.

Liner Actions는 어떤 도구인가

Liner Actions는 MCP 서버 주소 하나를 등록하고 라이너 계정으로 로그인해 두면, 에이전트가 천 개 넘는 서비스에서 필요한 액션을 찾아 제 계정으로 실행할 수 있게 해 주는 도구입니다. 에이전트에게 보이는 도구는 액션 검색·실행·계정 연결·연결 확인 네 개뿐이고, 서비스 인증 정보는 라이너가 보관해 에이전트에는 넘기지 않습니다. 연결도 라이너 계정에 남아서 다른 에이전트에서 그대로 쓸 수 있다는 게 공식 설명입니다.

제가 평소 업무에 주로 붙여 쓰는 MCP는 GitHub·Notion·Sender(이메일 마케팅)·Mixpanel(제품 분석) 네 가지인데요. 이 넷을 Liner Actions로 연결해 썼고, 쓰는 중에 Google Search Console을 하나 더 붙였습니다. 맥북 터미널의 Claude Code와 Claude Code on the web, 폰의 Claude 앱, Codex를 오가며 썼습니다.

MCP 서버를 직접 연결할 때와 무엇이 다른가

먼저 Liner Actions로 붙이는 것과 직접 붙이는 것이 어떻게 다른지 알아보려고, 새 저장소에서 같은 네 서비스를 직접 붙여 봤습니다. 직접 붙일 때는 서비스마다 MCP 서버를 하나씩 추가해야 하는데요. Claude Code에게 “project scope로 Notion MCP 연결해 줘”처럼 맡기니 공식 서버를 찾아 프로젝트 설정에 넣어 줬고, 네 서비스라 서버도 네 개가 들어갔습니다. 그다음 서비스마다 따로 로그인해 승인했고, 네 개를 다 붙이는 데 10분 남짓 걸렸습니다.

하지만 Liner Actions는 Liner Actions 서버 하나만 등록해 두면 됩니다. 채팅으로 “Liner Actions로 Notion 연결해 줘”라고 하면 링크가 오고, 열어서 승인 버튼을 두 번 누르면 끝입니다. 넷 중 셋은 직접 붙일 때도 OAuth라, 승인 버튼을 누르는 단계만 놓고 보면 두 방식이 비슷했죠.

차이는 이 방식에서 벗어나는 서비스에서 났습니다. GitHub는 Datadog 때처럼 키를 넣어야 하는 토큰 방식이라, 토큰을 새로 발급하는 대신 gh CLI의 토큰을 환경 변수로 넣어 우회했습니다. Sender는 Claude Code가 공식 서버를 바로 찾지 못해 제가 다시 짚어줘야 했고요.

반면 Liner Actions에서는 이 두 서비스도 다른 서비스와 똑같이 링크와 승인 버튼으로 끝났습니다. Mixpanel만 처음에 실패했는데, 이는 2026년 8월 이전에 만든 계정은 조직 설정에서 MCP 접근이 기본으로 꺼져 있어서였죠. 이건 직접 연결에서도 똑같이 켜야 하는 단계입니다.

Google Search Console을 붙일 때가 가장 인상적이었어요. 제가 운영하는 뉴스레터의 검색 유입을 보려고 직접 붙이려다가, 구글 클라우드 프로젝트를 만들어 API를 켜고 인증 키와 속성 권한까지 준비해야 해서 미뤄 둔 연동이었거든요. Liner Actions에서는 “연결해 줘” 한마디 뒤에 브라우저에서 몇 번 클릭하니 붙었죠. 동의 화면에서 권한 체크를 하나 빠뜨려 한 번 다시 했는데도 몇 분이면 됐습니다. 미뤄 뒀던 일이 이렇게 끝나니 편하면서도 신기했습니다.

Claude Code 웹·폰·Codex에서도 MCP 연결을 그대로 쓸 수 있을까

두 방식의 차이가 가장 크게 느껴진 건, 이미 해 둔 연결을 다른 곳에서 다시 쓸 때였습니다.

터미널의 Claude Code에서 MCP를 프로젝트 범위로 붙여 쓰면, 새 프로젝트를 열 때마다 서버 네 개를 다시 추가해야 합니다. 하지만 Liner Actions는 서버 하나를 추가하고 라이너 인증 버튼을 한 번 누르니 네 서비스가 바로 보였습니다. 라이너 계정에 해 둔 연결이 그대로 쓰여서 3분 안에 끝났어요.

Claude Code on the web에서는 제 컴퓨터에만 설정해 둔 MCP가 하나도 따라오지 않았습니다. 웹에서는 claude.ai 커넥터로 어느 정도 해결할 수 있죠. 커넥터 목록에 GitHub·Notion·Mixpanel은 있어서, 이 셋은 서비스마다 커넥터를 따로 연결하면 됩니다. 다만 Sender는 커넥터가 없었습니다. 그리고 이 연결은 Claude 밖으로 따라가지 않아서, Codex 같은 다른 에이전트로 가면 처음부터 다시 붙여야 합니다.

그런데 Liner Actions는 claude.ai 커넥터에 서버 주소 하나를 등록하는 것으로 끝났고, 웹 세션에서 따로 설정할 것도 없었어요. 같은 커넥터가 데스크톱 앱과 폰의 Claude 앱에도 떠서, 이동 중에는 폰으로도 썼습니다.

평소 함께 쓰는 Codex에서도 같은 연결이 그대로 쓰이는지 해 봤습니다. 네 서비스가 하나도 없던 Codex에 Liner Actions 서버를 추가하고 OAuth를 한 번 하자, 3분이 채 안 돼 네 서비스를 모두 쓸 수 있었어요. Codex의 자체 플러그인에도 셋은 있지만, Sender는 거기에도 없었습니다.

다른 컴퓨터로 옮기는 경우도 따져 봤어요. 어떤 서버를 쓰는지는 프로젝트 설정에 남아 따라오지만, 서비스마다 하는 로그인과 키 설정은 컴퓨터마다 다시 해야 합니다. 같은 컴퓨터에서도 새 터미널을 열었더니 직접 붙인 GitHub가 인증 오류로 동작하지 않았습니다. 키를 넣어 둔 설정이 그 터미널에는 없었던 탓으로 보입니다. 그러나 Liner Actions는 서비스마다 챙길 키가 없어서, 새 프로젝트나 Codex에서처럼 라이너 인증 한 번이면 됩니다.

환경별로 다시 해야 했던 일을 다음과 같이 표로 정리했습니다.

MCP를 연결해 두면 컨텍스트는 얼마나 쓸까

MCP를 많이 붙여 두면 그만큼 기본 컨텍스트를 차지해서, 저는 평소에도 안 쓰는 MCP는 꺼 두는 편입니다. 그래서 여러 서비스를 Liner Actions 하나로 연결해 쓰면 컨텍스트를 아끼면서 쓸 수 있지 않을까 궁금했습니다. 에이전트에게 보이는 도구가 네 개뿐이니 아껴 줄 거라 기대하고 직접 연결과 비교해 봤는데, 결과는 달랐어요.

비교는 이렇게 했습니다. 같은 프로젝트에 네 서비스를 직접 연결한 쪽과 Liner Actions로 연결한 쪽을 두고, 각각 새 세션에서 네 서비스를 차례로 조회하는 같은 요청을 보낸 뒤 /context로 컨텍스트 사용량을 봤어요. 환경은 터미널 Claude Code(v2.1.285, 1M 컨텍스트 모델)였고, 도구 검색은 기본값(켜짐) 그대로 뒀습니다.

붙여 두기만 했을 때는 Liner Actions 쪽이 1.8k 토큰 많았습니다. 네 서비스를 한 번 조회한 뒤에는 56k 대 67k처럼, 두 번 재서 모두 11~13k 차이가 났어요. 같은 조회를 값만 바꿔 한 번 더 하자, 이번에는 액션을 다시 검색하지 않고 바로 실행했습니다.

Claude Code에는 붙여 둔 도구의 정의를 처음부터 다 싣지 않고, 필요할 때 찾아서 불러오는 도구 검색 기능이 있습니다. 기본으로 켜져 있어서 직접 연결한 도구는 쓰기 전까지 컨텍스트를 거의 차지하지 않아요. 그런데 Liner Actions의 검색·실행 도구는 처음부터 실려 있었고, 붙여 두기만 했을 때 1.8k 토큰 차이가 난 건 그 때문입니다.

조회한 뒤의 차이는 동작 방식에서 왔습니다. 도구 정의 자체는 Liner Actions 쪽이 적었지만(2.3k 대 5k), 서비스마다 액션을 먼저 검색하고 나서 실행하다 보니 네 번의 검색 결과(약 4.9만 자)가 대화에 그대로 남았습니다. 라이너는 검색 결과의 상위 후보에만 입력 스키마를 붙이고, 이미 검색한 액션은 다시 검색하지 않는다고 설명합니다. 두 번째 조회에서 검색 없이 바로 실행한 것도 그래서죠. 처음 검색한 만큼은 남지만, 반복할수록 그 비중이 줄어드는 셈입니다.

한 작업을 한두 번 잰 결과라 일반화하지는 않으려 합니다. 1M 컨텍스트에서는 체감할 차이도 아니었고요.

일주일 실무에 써 보니: GitHub·Notion·Sender·Mixpanel

Liner Actions를 연결해 둔 상태로 일주일 넘게 평소 업무를 하면서, 필요한 데이터와 자료를 그 자리에서 가져와 일할 수 있는지를 봤습니다.

저는 여러 프로젝트의 할 일과 우선순위를 GitHub 이슈로 관리합니다. 폰에서 한 프로젝트의 열린 이슈를 보여 주고 다음 할 일을 제안해 달라고 하자, 이슈마다 남은 일과 막힌 지점을 정리하고 다음에 할 일을 이유와 함께 골라 줬습니다. 제가 직접 할 일과 AI에게 맡길 일을 나눠 둔 목록을 언제 어디서든 들여다볼 수 있으니, 일이 훨씬 생산적으로 돌아간다는 느낌을 받았습니다.

뉴스레터 성과는 그동안 눈대중이나 플랫폼 기본 통계로만 봤는데, 이동 중에 폰에서 Search Console을 불러오니 글마다 노출과 클릭, 클릭률, 평균 순위와 어떤 검색어로 들어왔는지가 한 표로 정리됐습니다. 미뤄 뒀던 연동을 붙이자마자 바로 일에 썼고, 다음 글은 이 검색어를 보고 써야겠다는 생각까지 들었습니다.

Sender로 돌리는 자동 메일 흐름의 성과도 폰으로 점검했습니다. Sender는 구독자에게 보내는 안내 메일과 자동 메일 흐름을 돌리는 이메일 마케팅 도구인데요.Claude 앱에서 “Liner Actions로 Sender 자동화 목록 보여 줘”라고 하자 15초쯤 뒤 자동화 세 개가 표로 나왔고, 강의 안내 자동화의 단계별 오픈율·클릭률에서 가장 약한 단계를 찾아 달라고 하니 1분쯤 뒤 단계별 표와 개선안 다섯 개가 왔어요. 메일과 단계의 대응은 발송 순서로 추정했다는 한계도 에이전트가 먼저 밝혔습니다. 요청 두 번, 3분이었어요. Claude 기본 커넥터에는 Sender가 없는데도, 폰에서 따로 연결하는 단계 없이 바로 썼어요.

확인만 한 게 아니라, 쌓아 둔 자료를 꺼내 쓰는 데도 썼습니다. 예전 강의 교안과 자료는 노트·문서 도구인 Notion에 쌓아 뒀는데, 아직 주로 일하는 저장소로 옮기지 못한 게 많습니다. 그래서 필요할 때마다 그 맥락을 옮겨 오는 일이 늘 번거로웠습니다. 전에 다른 방법으로 연결해 클라우드 세션에서 Notion을 불렀을 때는 호출이 몇 번 실패해서, 그 뒤로는 아예 손을 놓고 있었죠. 이번엔 Liner Actions로 교안 열한 페이지를 읽어 특강용 커리큘럼을 짜 달라고 했더니, 원문과 기존 구성안을 대조해 고칠 점 세 가지까지 짚은 문서를 저장소에 남겨 줬습니다. 그 문서를 바탕으로 슬라이드까지 짧은 시간에 끝냈고, 커리큘럼 검수는 돌아다니면서 했습니다. 실질적으로 도움이 가장 컸던 게 이 교안 작업이었습니다.

마지막으로 이렇게 따로 쓰던 네 서비스를 한 흐름으로 이어 봤어요. 제품 분석 도구인 Mixpanel로는 랜딩페이지 지표를 보는데, 불러오니 SNS 유입부터 실제 강의 구매까지 퍼널 전체가 한눈에 펼쳐졌고, SNS 쪽에서 무엇을 고쳐야 할지도 바로 보였습니다. 분석하다 나온 할 일은 그 자리에서 GitHub 이슈로 남겼고요.

이어 Notion에 쌓아 둔 자료를 가져와 Sender 캠페인을 만들자, 그럴듯한 캠페인 아이디어와 초안이 금세 나왔습니다. 평소라면 세그먼트를 나누고 지표를 보는 데만 품이 꽤 드는데, 프롬프트 몇 번으로 대상 세그먼트를 뽑아 발송 준비까지 마쳤죠. 이 흐름 내내 호출이 실패하거나 연결이 끊긴 적은 한 번도 없었습니다.

아쉬운 점도 있었습니다. Sender는 제가 써 본 범위에서 캠페인을 만들 수는 있어도 지울 수는 없었고, 발신 주소나 제목을 바꾸려 하자 캠페인을 새로 만들어야 했어요. 그리고 처음엔 쓰기가 걱정돼 Claude 커넥터 설정에서 Liner의 실행 도구를 “승인 필요”로 두었는데, 그러자 읽기만 하는 작업에도 실행할 때마다 허용을 눌러야 해서 위 자동화 점검 한 번에 다섯 번을 눌렀습니다. “허용”으로 바꾼 뒤로는 묻지 않고 매끄럽게 돌아갔지만 그만큼 쓰기도 함께 열리는데요, 이건 다음 섹션에서 이어서 볼게요.

에이전트에게 MCP 쓰기 권한 을 맡겨도 될까

MCP로 붙인 서비스는 제 계정의 실제 서비스와 연결된 상태라, 쓰기 권한은 늘 신경 쓰는 부분입니다. 읽기는 권한을 크게 따지지 않아도 되지만, 쓰기는 한 번 잘못되면 되돌릴 수 없는 결과가 날 수 있으니까요. Liner Actions는 수많은 서비스를 한곳에 연결해 쓰는 만큼, 권한이 어떻게 돼 있는지도 살펴봤습니다.

실행 도구 설명에는 허용된 액션은 읽기·쓰기·삭제를 가리지 않고 바로 실행되니 사용자가 요청했는지 에이전트가 확인하라고 적혀 있어요. 라이너는 액션마다 위험 수준을 붙여 주고, 개발자용 API 문서에서는 쓰기 작업마다 사람의 승인을 받으라고 권합니다. 확인은 에이전트와 클라이언트의 몫인 거죠. 자동화를 점검할 때도 에이전트는 메일 본문 수정이 쓰기 작업이니 요청하면 진행하겠다고 먼저 말했어요.

앞에서 말한 허용 설정이 읽기와 쓰기에 한꺼번에 걸리는 건, 클라이언트에 보이는 실행 도구가 하나뿐이어서입니다. Claude 앱의 허용 팝업에는 실행할 액션과 인자가 그대로 보였지만, 허용 여부는 도구 단위로만 정할 수 있어 읽기와 쓰기를 따로 둘 수 없었죠. 개인 작업엔 괜찮았는데, 회사 문서처럼 중요한 자료라면 신중해야겠다고 생각했습니다. 연결 권한도 넓어서 Notion은 개인 스페이스 전체, GitHub는 비공개 저장소까지 열렸습니다. 다만 직접 연결에 쓴 gh CLI도 기본 로그인 토큰이 repo 범위라, 비공개 저장소까지 열리는 건 마찬가지였습니다.

대신 Actions Console에서는 액션마다 스위치를 끌 수 있었습니다. Notion의 페이지 생성을 꺼 두고 빈 페이지를 만들어 달라고 하자, 에이전트는 “You have turned this capability off” 오류를 받고 멈췄습니다. 폴더나 데이터베이스처럼 요청과 다른 것을 만드는 기능으로 돌아가지도 않았습니다. 그래서 커넥터는 “허용”으로 두고 걱정되는 쓰기 액션만 콘솔에서 꺼 두면, 읽기에는 묻지 않으면서 그 쓰기는 막을 수 있죠. 다만 쓰기만 한꺼번에 끄는 버튼은 없고 목록에 읽기·쓰기 표시도 없어서, 막고 싶은 액션을 이름을 보고 하나씩 꺼야 합니다.

사실 Sender 캠페인 발송은 처음엔 없던 기능입니다. 사용을 시작할 때 Sender 캠페인 액션은 캠페인 초안을 만드는 데까지라 발송을 문의했더니, 쓰던 중에 라이너가 공식 Sender MCP에 없는 발송을 API로 따로 구현해 넣어 줬습니다. 라이너 쪽의 빠른 피드백과 업데이트가 인상 깊었습니다. 이 발송 액션에는 되돌릴 수 없으니 호출 전에 캠페인과 수신 대상을 사용자에게 확인하라는 설명이 붙어 있는데, 위험 수준 표시는 쓰기(write)였습니다.

앞 섹션에서 만든 캠페인은 강의를 들은 분들에게 보내는 후속 메일이었고, 내용을 확인한 뒤 실제 발송까지 Liner Actions로 했습니다. 발송은 매끄럽게 됐지만, 되돌릴 수 없는 작업인데도 발송을 요청하자 에이전트는 다시 묻지 않고 바로 실행했습니다. 커넥터를 “허용”으로 둔 상태라 클라이언트 팝업도 뜨지 않았습니다. 캠페인이 아니어도 자동화를 켜는 쓰기 액션으로 실제 메일이 나갈 수 있다는 점도 알아 둘 만합니다.

그래서 발송을 맡길 때는 프롬프트로 대상과 범위를 분명히 지시하고, 번거롭더라도 보내기 전에 내용을 한 번 더 확인하는 게 좋겠다고 느꼈습니다. 아주 중요한 캠페인이라면 초안까지만 맡기고 발송은 직접 누르는 편이 안전하겠다는 생각이 들었습니다.

Liner Actions는 누구에게 맞을까

써 보니 Liner Actions는 처음 붙일 때보다 같은 연결을 다시 할 때 품을 더 많이 덜어 줬습니다. 그래서 서비스를 여러 개 쓰면서 프로젝트와 컴퓨터, 에이전트를 오가는 사람, 폰에서도 일하는 사람에게 잘 맞아요. 서비스 하나를 한 컴퓨터에서만 쓴다면 지금처럼 에이전트에게 직접 붙여 달라고 하는 것으로 충분합니다. 읽기와 쓰기 권한을 서비스별로 나눠 관리해야 하는 업무 환경이라면 앞에서 본 허용 단위를 먼저 확인해 보는 게 좋겠습니다.

저는 앞으로도 계속 쓸 생각입니다. 도구를 워낙 매끄럽게 쓸 수 있어서, 쓰는 내내 AI에 팔다리가 붙은 느낌이었죠. 가장 좋았던 건 클라우드 환경에서도 잘 동작한다는 걸 확인한 점입니다. 아이디어가 떠오를 때마다 언제 어디서든 폰으로 일을 맡길 수 있어서, 그만큼 생산성이 올라갔습니다. Claude Code와 Codex를 함께 쓰는데, Codex에 일을 시킬 때도 별다른 설정 없이 MCP가 다 붙어 있는 상태로 쓸 수 있어 편했어요. 지원하는 서비스가 천 개를 넘어서, 쓰다가 새 서비스가 필요해지면 Search Console 때처럼 그 자리에서 붙여 쓸 수 있다는 점도 계속 쓰려는 이유입니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.