에이전트가 SSH로 접속하는 BBS가 다시 등장한 이유

사람과 에이전트가 같은 게시판을 쓰는 방법

최근 읽은 BBS 서비스 소개에 SSH 명령 한 줄로 접속하는 장면이 나왔어요. SSH는 멀리 있는 컴퓨터에 암호화된 연결로 접속하는 방식이에요. 웹 브라우저에서 로그인 버튼을 누르는 대신 터미널에서 접속해 글자 메뉴를 사용하는 거죠.

BBS는 사람들이 글을 남기고 파일을 주고받던 전자게시판이에요. 이 오래된 형식을 사람뿐 아니라 AI 에이전트도 참여할 수 있는 공간으로 만드는 프로젝트들이 나오고 있어요.

제가 눈여겨본 건 복고풍 화면이 아니라 SSH 명령 한 줄로 들어가는 그 접속 방식이었어요. 사람이 쓰기 편한 화면을 에이전트에게 해석하게 할 수도 있고, 에이전트가 필요한 기능을 직접 호출하도록 만들 수도 있어요. 제품을 운영하는 입장에서는 둘의 구축 비용과 운영 부담을 비교할 필요가 있어요.

웹 화면과 SSH·MCP를 함께 제공해요

깃허브에 공개된 ruvnet/AgentBBS가 구체적인 예예요. 프로젝트 설명에 따르면 사람은 웹 앱을, 에이전트는 SSH나 MCP를 통해 같은 게시판과 마켓, 게임·평가 공간을 이용하도록 설계돼 있어요.

MCP는 AI 애플리케이션이 외부 도구와 데이터에 연결되는 방식을 정한 규격이에요. 게시글을 읽거나 작성하는 기능을 MCP 도구로 제공하면 에이전트가 웹 화면의 버튼 위치를 찾지 않고도 그 기능을 호출할 수 있어요.

이 프로젝트에서 눈여겨볼 구성은 공유하는 데이터는 같고, 접근하는 방법은 여러 가지라는 점이에요. 사람이 웹에서 읽은 게시글을 에이전트도 다른 접속 방식으로 읽는 거죠. 사람에게 터미널을 강요하거나 에이전트에게 웹 화면만 제공할 필요가 없어요.

함께 작업하는 공간과 접속 규격도 구분해서 봐야 해요. MCP 자체가 게시판은 아니지만, 여러 사용자가 공유하는 게시판 기능을 MCP로 제공할 수는 있어요. AgentBBS도 그렇게 둘을 결합해요. “MCP는 한 에이전트만 쓰고 BBS는 여럿이 쓴다”는 식으로 나누면 구조를 잘못 이해하게 돼요.

공개 프로젝트의 설계만으로 서비스의 성공을 판단할 수는 없어요. 다만 이미 있는 기능을 사람과 에이전트에게 각각 어떤 방식으로 제공할지 생각해보는 사례로는 흥미로워요.

화면을 읽는 방식에는 매 단계의 비용이 있어요

컴퓨터 사용 에이전트는 화면을 보고 버튼 위치를 찾은 다음 클릭하거나 입력할 수 있어요. 별도 API가 없는 프로그램도 다룰 수 있다는 장점이 있어요. 이미 쓰던 소프트웨어를 바꾸기 어려운 환경에서는 중요한 선택지죠.

그 과정에는 비용이 들어요. 화면을 캡처하고, 모델이 상태를 해석하고, 행동을 실행한 뒤 결과를 확인해야 해요. 목표한 화면이 나오지 않으면 다시 읽거나 다른 경로를 시도하고요. 업무가 길어질수록 이런 단계가 누적될 수 있어요.

사람에게도 화면을 읽는 시간과 인지 부담이 있어요. 에이전트 쪽에서는 그 부담이 모델 호출 비용과 실행 지연으로도 나타나는 거예요. 이미지 처리 비용만 보면 전체 비용을 놓칠 수 있어요. 잘못 누른 뒤 복구하는 데 걸린 시간, 사람이 개입한 횟수도 함께 봐야 해요.

반대로 API나 명령줄 도구가 필요한 정보를 정해진 형식으로 반환하면 버튼을 찾는 과정을 줄일 수 있어요. 예를 들어 주문 상태를 조회할 때 화면 여러 개를 거쳐 읽는 대신 주문 번호와 상태를 바로 받을 수 있는 거죠.

다만 글자로 보인다고 모두 같은 인터페이스는 아니에요. 커서 위치와 화면 갱신을 따라가야 하는 터미널 메뉴도 있고, 요청에 대한 결과를 JSON처럼 정해진 구조로 반환하는 도구도 있어요. 단순히 “이미지 대신 텍스트”라고 분류하기보다 에이전트가 상태와 결과를 얼마나 쉽게 해석할 수 있는지 봐야 해요.

벤치마크는 접속 방식의 우열을 바로 알려주지 않아요

화면을 사용하는 에이전트의 발전은 OSWorld 같은 평가에서 확인할 수 있어요. 다만 서로 다른 버전과 과제를 같은 시험처럼 비교해서는 안 돼요.

OSWorld 2.0은 긴 업무 108개를 평가해요. 사람이 한 시간 넘게 걸리는 과제가 다수 포함돼 있고, 여러 프로그램에 흩어진 정보를 이어서 처리해야 해요. 완료한 과제의 비율과 과제 안에서 충족한 요구사항의 부분 점수를 따로 보여줘요.

예를 들어 공개 표의 클로드 오퍼스 4.8 행은 500단계 한도와 도구 호출을 묶어 처리하는 설정에서 완료율 20.6%, 부분 점수 54.8%를 기록해요. 일부 요구사항을 충족해도 최종 결과까지 완성하지 못한 과제가 많았다는 뜻이에요. 이 조건 하나의 결과를 두고 실무 작업이 다섯 번 중 한 번만 성공한다고 일반화할 수는 없어요.

터미널 환경을 평가하는 Terminal-Bench 2.0도 같은 주의가 필요해요. 2026년 공개 리더보드에는 80%를 넘는 결과가 있어서, 터미널 방식에 특정 상한을 미리 정해둘 수는 없어요.

같은 클로드 오퍼스 4.6을 사용해도 클로드 코드 조합은 58.0%, Meta-Harness 조합은 76.4%로 보고돼 있어요. 에이전트가 도구를 쓰고 작업을 이어가는 실행 구성이 결과에 영향을 준다는 예예요. 두 결과의 차이를 모델 성능이나 입력 형식 하나로 설명하기는 어려워요.

OSWorld와 Terminal-Bench는 과제와 실행 환경이 달라서, 두 점수를 나란히 놓고 화면과 터미널 중 무엇이 더 낫다고 판정할 수는 없어요. 결국 제품의 실제 업무를 두 방식으로 수행해 같은 완료 기준과 비용으로 비교해야 해요.

기존 기능을 열어줄 때도 개발과 운영은 필요해요

제가 이 사례에서 주목하는 비용은 접속 기능을 처음부터 만드는 비용이에요. 이미 API나 명령줄 도구가 있다면 이를 에이전트에 연결하는 편이 화면 조작을 새로 구현하는 것보다 간단할 수 있어요. 개발자가 익숙한 규격과 도구를 재사용할 수도 있고요.

하지만 기존 규격을 쓴다고 제품 쪽 작업이 사라지지는 않아요. 누가 접속했는지 확인하고, 읽기와 쓰기 권한을 나누고, 잘못된 요청에 오류를 반환해야 해요. 같은 요청을 다시 보냈을 때 결제나 발송이 중복되지 않도록 처리하는 일도 필요해요.

SSH 키를 이용하는 서비스라면 키를 만들고 보관하고 교체하는 절차가 있어요. MCP라면 사용할 도구의 입력과 출력을 정의하고 접근 권한을 설정해야 해요. 사용자의 환경에 필요한 클라이언트가 갖춰져 있는지도 확인해야 하고요. 모두가 이미 설치해서 쓴다고 가정하면 도입 과정을 잘못 계산하게 돼요.

그래서 저는 “몇 주면 연동된다”는 일반적인 기간보다, 현재 제품에 무엇이 준비돼 있는지 먼저 확인하는 편이 낫다고 봐요. 잘 정리된 API가 있는 제품과 모든 처리가 화면 안에 얽혀 있는 제품은 필요한 작업이 다를 테니까요.

비교할 항목	화면 조작을 사용할 때	API·명령줄·MCP 기능을 제공할 때
시작할 조건	에이전트가 필요한 화면과 기능에 접근 가능해야 해요	제품이 호출할 기능과 반환할 결과를 정의해야 해요
실행 과정	화면 해석과 조작 결과 확인이 필요해요	요청·응답과 상태 변경을 확인해야 해요
변경 대응	화면 배치와 흐름 변경의 영향을 받아요	입력·출력 규격과 버전 변경을 관리해야 해요
권한 관리	화면에서 허용된 행동과 데이터 범위를 통제해요	호출할 기능과 데이터 범위를 통제해요
비용 판단	호출·지연·재시도·사람 개입을 측정해요	구축·유지보수와 실행·복구 비용을 함께 측정해요

화면으로만 확인할 수 있는 시각적 결과물도 있고, 데이터 조회처럼 직접 호출이 잘 맞는 기능도 있어요. 한 제품 안에서 두 방식을 함께 쓰는 편이 합리적일 수 있어요.

오스왈드의 시선

노션 한국 커뮤니티를 만들던 시절에 제가 배운 게 있어요. 기능을 얼마나 잘 만들었는지만큼 사람들이 이미 쓰는 도구 안에서 그 기능을 쓸 수 있는지가 중요했어요. 같은 기능이라도 익숙한 도구 안에 들어가면 쓰였고, 별도 프로그램을 새로 열게 만들면 잘 쓰이지 않는 경우가 있었어요.

GTM 전략을 짜면서도 저는 이 패턴을 반복해서 봤어요. 새로운 인터페이스를 알리는 데 힘을 쓰기보다 고객이 이미 일하는 곳에서 기능을 쓰게 만드는 편이 도입에 유리했죠. 기능 자체의 품질과 별개로, 새로 배워야 할 과정과 일하는 방식을 바꿀 부담이 있었기 때문이라고 생각해요.

에이전트 연동에서도 비슷한 질문을 할 수 있어요. 지금 사용하는 에이전트가 이미 다룰 수 있는 도구는 무엇인지, 제품의 기존 기능을 그 방식으로 제공할 수 있는지 보는 거예요. 반드시 오래된 규격을 고를 필요는 없지만, 새 연결 방식을 만들기 전에 재사용할 수 있는 것을 확인할 필요는 있어요.

컨설팅 자리에서 이런 이야기를 하면 시각적인 경험이 핵심인 제품이라는 반박을 듣기도 해요. 그 말도 맞아요. 디자인 결과를 보고 판단하는 일처럼 화면이 중요한 기능이 있죠. 다만 같은 제품에도 검색, 상태 조회, 내보내기처럼 화면 없이 처리할 수 있는 기능이 있을 수 있어요. 이들을 따로 골라볼 수 있다는 이야기예요.

저는 이번 사례를 BBS 자체의 부활이 모든 제품의 해답이라는 뜻으로 보지는 않아요. 익숙한 접속 방식을 재사용하고, 사람과 에이전트가 같은 데이터에 접근하게 한 설계에 관심이 있어요. 작은 프로젝트 두 곳의 등장만으로 시장 전체가 그 방향을 택했다고 말할 수는 없지만, 검토해볼 선택지는 보여주니까요.

제품을 만들고 있다면 반복해서 쓰는 기능 하나부터 비교해보면 좋겠어요. 같은 조회나 내보내기를 화면으로 할 때와 직접 호출할 때 완료율, 걸린 시간, 재시도와 사람 개입을 기록하는 거예요. 연동 개발과 유지보수 비용까지 더하면 우리 제품에 어느 방식이 맞는지 판단하기 쉬워질 거예요.

기존 기능을 어떤 경로로 제공할지 결정하는 것도 GTM의 일부라고 생각해요. 고객과 에이전트가 실제로 쓰기까지 넘어야 할 단계를 줄이는 일이니까요.

💬 제품에서 화면 없이도 처리할 수 있는 기능은 무엇인가요? 에이전트에게 먼저 열어준다면 어떤 기능을 고르시겠어요?

참고자료

• ruvnet/AgentBBS: 웹·SSH·MCP로 같은 공간에 접근하는 프로젝트 설계
• MCP 공식 아키텍처 설명: 애플리케이션과 서버, 도구·데이터 연결 구조
• Snorkel AI, OSWorld 2.0: 긴 작업의 완료율·부분 점수와 실행 조건
• Terminal-Bench 2.0: 모델과 에이전트 구성별 평가 결과

필자 안광섭 (오스왈드)은 세종대학교 겸임교수, INLEVEL9 전략 컨설턴트입니다. 경력, 연구, 저서와 최신 활동은 저자 소개에서 계속 갱신합니다. 최근 소식 · 2026년 8월: 2026 세종도서 교양부문 우수도서 선정.