DEV Community: tauchi 한국어

osFoundry 커스텀 앱 기능 정리, 사내 도구를 만들고 바로 배포하는 법

tauchiii — Fri, 06 Nov 2026 13:02:37 +0000

월요일 오전, 스타트업 백엔드 개발자 민준 님에게 CS팀에서 메시지가 옵니다. "환불 요청 목록을 엑셀 말고 어드민 화면으로 볼 수 있을까요?" 화면 하나 만드는 건 AI한테 맡기면 금방입니다. 문제는 그다음입니다. 어디에 띄울지, DB는 뭘 쓸지, 결제 API 키는 어디에 넣을지, 매일 밤 정리 작업은 누가 돌릴지. 사내 도구가 "다음 스프린트에"로 밀리는 이유는 대부분 이 인프라 쪽입니다.

커스텀 앱이 하는 일

osFoundry 데스크톱 앱에는 작은 앱을 직접 만들고 운영하는 기능이 사이드바의 CUSTOM APP 카테고리에 모여 있습니다. 화면은 다섯 개입니다.

Room: 앱을 탭으로 띄워 놓고 팀이 함께 쓰는 공간
App Code: 앱 뒤에 있는 저장소(코드, 버전, 릴리스, 배포)
Deployed Apps: 워크스페이스 전체에서 지금 배포된 앱 목록
Snippets: 저장소 없이 돌아가는 아주 작은 앱 모음
Domains: 앱을 서비스하는 도메인 관리

Retool 같은 어드민 빌더와 Vercel 같은 호스팅을 한 앱 안에 합쳐 놓았다고 보면 이해가 빠릅니다. 다만 드래그 앤 드롭 빌더와 달리 결과물은 평범한 웹 앱 코드라서, AI가 작성한 코드를 그대로 이어서 키워 갈 수 있습니다. 내부 앱 기능 페이지에 정리된 대로, 앱마다 전용 데이터베이스, 시크릿, 예약 작업, 서브도메인이 붙습니다.

화면 구성 살펴보기

위 화면은 데스크톱 앱의 Websites에서 새 사이트를 만들기 시작한 모습입니다(예시 프로젝트 "Hearth Bakery"). Room의 "Describe the app you want(원하는 앱을 설명하세요)" 입력란과 같은 "설명하면 AI가 만든다" 흐름이라, 전체 구조를 파악하기에 좋습니다.

왼쪽 Pages: 지금 있는 페이지 목록입니다. 아래 Add page로 추가합니다.
가운데 미리보기: 만들고 있는 결과가 바로 보입니다. 위쪽 아이콘으로 데스크톱, 태블릿, 모바일 폭을 바꿀 수 있고, "On this computer"라고 표시되는 동안은 아직 아무 데도 공개되지 않은 상태입니다.
설명 입력란: 무엇을 하는 곳인지, 누구를 위한 것인지, 분위기는 어떤지 적고 Build my site를 누르면 AI 어시스턴트 Maestro가 파일 전체를 작성합니다.
오른쪽 Maestro 패널: 앱을 만들고 고치는 대화가 모두 여기서 이뤄집니다. Use a folder로 내 자료 폴더를 넘기면 AI가 추측으로 채우지 않습니다.
위쪽 Publish needs credits: 만들기와 미리보기는 내 컴퓨터 안에서 끝나고, 호스팅 단계에서 워크스페이스 크레딧을 씁니다.

Room 안에서도 구조는 비슷합니다. 위에는 앱 탭, 가운데에는 선택한 앱, 오른쪽에는 Maestro와 Details 두 탭이 있는 패널이 놓입니다.

활용 1: 개발자가 사이드 프로젝트 수준의 툴에 제대로 된 백엔드 붙이기

누가: CS팀용 환불 관리 툴을 혼자 만든 백엔드 개발자.

상황: 처음에는 노트북에서 SQLite로 돌렸습니다. 그런데 세 팀이 쓰기 시작했고, 결제 API 키가 필요해졌고, 매일 밤 정리 작업도 돌려야 합니다.

osFoundry에서 하는 일:

아직 로컬에서 돌아가는 단계라면 IDE에서 프로젝트를 열고 Database 탭을 누릅니다. .db, .sqlite 파일을 찾아서 테이블을 읽기 전용으로, 한 페이지에 200행씩 보여 줍니다(위는 예시 데이터). 옮기기 전에 앱이 실제로 뭘 저장하고 있는지 먼저 확인할 수 있습니다.
앱을 팀 Room으로 옮깁니다. Move to cloud 다이얼로그에서 Cloud room을 고르면 Room에 있는 모두가 앱을 쓸 수 있게 되고, 어떤 테이블이 복사됐고 어떤 테이블이 기기에 남았는지 알려 줍니다. 원래 앱과 데이터도 이 기기에 그대로 남습니다.
앱의 탭 설정에서 Secrets를 엽니다. App Runtime Secrets에 앱이 선언한 키가 나오고, Add a custom secret으로 새 값을 등록하고 Rotate로 값을 교체합니다. 바꾼 뒤에는 "Secrets updated. Redeploy to apply changes."라는 안내가 나오니 재배포로 반영합니다.
야간 작업은 앱 매니페스트의 container.cron에 적어 두고 Scheduled jobs에서 Sync from manifest를 누릅니다. 작업마다 일시정지와 재개가 가능하고, Run now로 한 번만 실행할 수도 있습니다.

결과: 앱 전용 Postgres를 가진 사내 도구가 됩니다. osFoundry의 Room App에는 각각 Postgres가 하나씩 붙고, pgvector와 TimescaleDB가 설치되어 있으며, 연결 문자열은 런타임에 시크릿으로 주입됩니다(앱별 Postgres). 데이터베이스 브라우저에서는 필터를 걸고 행을 편집할 수 있고 SQL 뷰는 SELECT만 허용합니다. Database snapshots에서 New snapshot, 복원, 다운로드도 됩니다. 코드는 App Code에서 version/2.4 같은 버전을 따서 main을 건드리지 않고 작업하고, Manifest(엔트리 포인트, 공개 범위, 필요한 커넥터)와 Versions 트리를 확인한 뒤 릴리스합니다.

활용 2: 팀이 릴리스 체크리스트를 작업 옆에 두기

누가: 릴리스 매니저와 팀원 세 명.

상황: 컷오버 절차, 런북, 릴리스 트래커가 세 군데 도구에 흩어져 있고, 릴리스 당일에는 아무도 스프레드시트를 믿지 않습니다.

osFoundry에서 하는 일:

New Room으로 "Launch Ops" 같은 Room을 만들고 릴리스 트래커와 런칭 파일을 탭으로 추가합니다.
탭 줄의 + 버튼을 누릅니다. New Tab 피커에 설치된 앱과 카탈로그(Incident log, Retro board, On-call rota, Changelog builder)가 나오고, All / Forked / Snippets로 거를 수 있습니다.
설명란에서 Build a snippet instead를 고르고 "항목마다 담당자가 붙는 컷오버 체크리스트"를 요청합니다. 스니펫은 파일 몇 개로 된 실행 가능한 미니 앱으로, 저장소도 버전도 배포도 없이 그 탭 안에서 바로 돌아갑니다.
체크리스트를 띄운 채로 오른쪽 Maestro에 계속 요청할 수 있고, Details 탭에서 Room의 개요와 지금까지의 활동을 봅니다.

결과: 체크리스트(데모 예시: Freeze the 2.4 branch, Run the order-index migration, Smoke-test the order desk, Post the release note)가 런북, 트래커와 같은 Room에 나란히 놓입니다. 나중에 Snippets 화면을 열면 모든 Room의 스니펫이 한눈에 보이고, 다른 워크스페이스로 옮길 때는 Export(JSON), 규모가 커지면 Promote로 정식 저장소로 승격합니다. 대충 만든 도구가 나중에 다시 짜야 하는 코드가 되지 않는다는 점이 실무에서는 꽤 큽니다.

활용 3: 개발을 모르는 사장님이 가게 페이지 운영하기

누가: 작은 빵집을 운영하고 코드는 쓰지 않는 사람.

상황: 메뉴와 영업시간이 있는 간단한 사이트를, 가능하면 가게 도메인으로 갖고 싶습니다. 유지 비용이 얼마나 드는지도 알고 싶습니다.

osFoundry에서 하는 일:

Websites에서 New Website를 누르고 가게를 설명한 뒤 Build my site를 누릅니다. 첫 버전(위 예시)은 문구가 임시이고, Maestro도 그렇다고 분명히 말합니다.
Use a folder로 실제 메뉴와 사진이 든 폴더를 고릅니다. 그다음은 "헤드라인을 더 크게"처럼 평소 말로 요청하면 됩니다.
마음에 들면 공개합니다. 호스팅에는 워크스페이스 크레딧을 씁니다. Who can open it에서 Workspace members only, Anyone with the link, 앱 자체 로그인 중에 고를 수 있고, 가게 사이트라면 Anyone with the link를 고릅니다.
Domains에서 도메인을 새로 등록하거나 이미 가진 도메인을 추가하고 DNS 레코드를 편집합니다. Events에는 누가 어떤 레코드를 바꿨는지 기록이 남고, Settings에서 갱신, 개인정보 보호, 이전용 코드를 관리합니다.

결과: 내 문구와 사진으로 만든 사이트가 내 도메인으로 공개됩니다. 공개 뒤에는 Deployed Apps가 "지금 뭐가 떠 있고, 뭐가 바뀌었고, 얼마 드는지"에 답해 줍니다. Apps에서 배포 위치, Activity에서 변경 이력, Usage에서 앱별 빌드 비용과 스토리지 비용, Previews에서 아직 돌고 있는 프리뷰 버전을 확인합니다.

다른 기능과의 연결

커스텀 앱은 혼자 쓰기보다 다른 기능과 오가며 쓰게 됩니다. Maestro는 모든 Room의 오른쪽 패널과 빌드 화면에 있으면서 코드를 같이 쓰고 고칩니다. 내 컴퓨터의 폴더에서 시작한 앱이라면 IDE의 Database 탭, 소스 컨트롤, 에디터를 그대로 씁니다. "앱"이라고 했지만 실은 공개 사이트만 필요하다면 Websites에서 시작하는 편이 빠릅니다. Snippets와 App Code는 Promote로만 이어지기 때문에, 일회용으로 만든 도구도 다시 짜지 않고 저장소로 옮길 수 있습니다. 앱 안에서 주기적으로 돌리는 작업은 앱 cron 작업 페이지에 정리되어 있습니다.

자주 묻는 질문

Room은 채팅방인가요?
아닙니다. Room의 중심은 앱 탭입니다. Maestro 채팅은 오른쪽 보조 패널에 있고, Room의 Details와 나란히 놓여 있습니다.

앱과 스니펫 중 무엇으로 만들어야 하나요?
파일 몇 개면 되고 한 Room 안에서만 돌면 되는 것(날짜 포맷터, 웹훅 확인 등)은 스니펫으로 충분합니다. 스니펫은 저장해도 아무것도 설치되거나 배포되지 않습니다. 나중에 버전 관리, 시크릿, 데이터베이스가 필요해지면 Promote로 저장소로 옮깁니다.

여러 앱이 데이터베이스 하나를 같이 쓸 수 있나요?
앱마다 전용 Postgres를 씁니다. 공유가 필요하면 명시적인 권한을 쓰는데, Room의 Database 탭에서 Incoming Requests, Active Grants, Outgoing Access를 보고 요청마다 승인하거나 거절합니다.

써 보기만 해도 비용이 드나요?
내 컴퓨터에서 만들고 미리보기만 할 때는 크레딧이 필요 없습니다. 공개, 배포, 도메인 등록에는 워크스페이스 크레딧을 씁니다. 데스크톱 앱은 osfoundry.io/ko/download에서 받을 수 있습니다.

osFoundry Code·IDE 기능 정리, AI 에이전트 병렬 작업을 머지 전에 확인하는 법

tauchiii — Fri, 06 Nov 2026 12:57:05 +0000

혼자 운영하는 쇼핑몰 프로젝트에서, 점심 이후로 AI 에이전트 세 개에게 각각 다른 작업을 맡겨 두었습니다. 장바구니 합계 반올림 수정, 체크아웃 할인 코드 추가, 가격 포맷 함수 테스트 작성입니다. 오후 4시, 셋 다 "완료"라고 합니다. 이제 main에 넣기 전에 확인할 것은 두 가지입니다. 두 에이전트가 같은 함수를 고치지는 않았는지, 그리고 세 변경을 합쳐도 테스트가 통과하는지입니다.

코드 작업을 위한 세 화면

osFoundry는 채팅, 에이전트, 파일, 각종 도구를 한 창에 모은 데스크톱 앱입니다. 코드 작업에는 역할이 다른 세 화면이 있습니다.

Code: 하나의 저장소에서 여러 AI 에이전트에게 작업을 병렬로 맡기는 화면입니다. 실행마다 전용 Git 브랜치와 작업 폴더(worktree)가 따로 만들어지고, diff 확인, 테스트, 통합 병합 미리 보기를 거친 뒤에 병합 여부를 직접 결정합니다. 자동으로 병합되는 일은 없습니다.
IDE: 로컬 폴더를 열고 직접 코드를 작성하는 에디터입니다. 탐색기, 소스 제어, 터미널, 문제, 테스트 패널이 있고, 오른쪽에는 지금 열려 있는 파일을 보고 답하는 어시스턴트가 붙어 있습니다.
Wiki: 내 컴퓨터에 있는 저장소를 읽어서 path:line 출처가 달린 문서 페이지를 작성합니다. 인용한 코드가 바뀌면 해당 페이지에 표시가 붙습니다.

Code와 Wiki는 Maestro, Model chat, Multi chat, Research와 같은 탭 줄에 있고, IDE는 사이드바에 별도 항목이 있습니다. 비유하자면 IDE는 Git 패널이 붙은 VS Code, Code는 작성자가 모두 AI 에이전트인 PR 목록에 가깝습니다. 차이점은 그 브랜치들이 아직 내 노트북 밖으로 나가지 않았다는 것입니다.

Code 화면 둘러보기

화면에서 볼 수 있는 부분은 다음과 같습니다(실행 내용은 예시입니다).

레일 위쪽 배너: diff를 하나도 열기 전에, 완료된 에이전트들이 어떤 파일에서 엇갈리는지 알려 줍니다. 여기서는 src/cart.js입니다. 옆의 함께 검토(Review together) 버튼으로 바로 비교를 시작합니다.
실행 레일: 작업 이름, 추가·삭제된 줄 수, 작업 시간, 브랜치가 한 줄씩 보입니다. 검토 대기, 확인 필요, 접혀 있는 기록처럼 내가 해야 할 일 기준으로 묶여 있습니다.
가운데 대화: 실행을 클릭하면 에이전트에게 무엇을 요청했고, 작업 중에 무슨 말을 했는지 읽을 수 있습니다.
오른쪽 패널: 변경 사항, 파일, 커밋, 검토, PR 탭에서 실행별 실제 diff를 봅니다. 커밋 전 작업이 먼저, 브랜치에 커밋한 내용이 그다음에 나옵니다.
오른쪽 아래 병합 영역: 완료된 실행을 선택하면 여기서 테스트하고 함께 병합했을 때를 미리 봅니다.

활용 1. 1인 개발자가 에이전트 세 개를 동시에 돌릴 때

앞에서 나온 1인 개발 상황입니다. Code에서 새 실행을 누르고 작업을 한 줄로 적은 뒤 에이전트를 고르면, 실행마다 전용 브랜치와 폴더가 만들어집니다. 한 폴더에서 여러 에이전트를 돌리면 파일이 서로 덮어써지기 쉬운데, 여기서는 처음부터 작업 공간이 나뉘어 있어서 충돌 없이 병렬로 진행됩니다. 내가 작업하던 폴더도 건드리지 않습니다.

배너에 엇갈림이 표시되면 세 실행을 체크하고 함께 검토를 누릅니다. 병합 영역에는 "충돌은 아직 확인 안 됨", "아직 테스트 안 됨"이라고 나옵니다. 초록불 대신 "아직 모른다"고 솔직하게 알려 주는 셈입니다. 그 아래 src/cart.js에는 경합 중 표시가 붙고, 브랜치별 변경 블록(hunk)이 나란히 보입니다. 반올림 수정과 할인 코드가 둘 다 total()을 고쳤다는 걸 여기서 알 수 있습니다.

다음으로 실행마다 테스트를 누릅니다. 테스트는 그 실행 전용 worktree 안에서 돌기 때문에 내 체크아웃에는 영향이 없습니다. 기본 설정은 "브랜치를 병합하려면 먼저 테스트를 통과해야 합니다"이고, 설정에서 바꿀 수 있습니다. 셋 다 통과했지만, 각각 통과했다고 합쳐서도 동작한다는 보장은 없습니다. 그래서 통합 병합 미리 보기(Preview combined merge)를 누르면, 버려도 되는 복사본에서 먼저 병합해 보고 결과를 알려 줍니다. 두 개는 충돌 없이 병합되고, 하나는 충돌입니다.

충돌 없는 두 브랜치를 병합하는 순간에야 내 브랜치가 바뀝니다. 충돌한 할인 코드 브랜치는 그대로 남아 있으니, 에이전트에게 반올림 수정 위에서 다시 작업하게 하면 됩니다. 브랜치 전체가 아니라 각 에이전트 결과에서 좋은 부분만 골라 쓰고 싶다면, 브랜치로 합치기에서 변경 블록을 하나씩 골라 새 브랜치를 만들 수도 있습니다.

실무에서는 이런 점도 은근히 중요합니다. 실행 도중 앱이 멈추면, 그 실행은 "실행 중"으로 남지 않고 중단됨으로 돌아오며 브랜치는 유지된다고 표시됩니다.

활용 2. 신규 입사자 온보딩 문서를 코드에서 만들 때

두 번째는 코드를 고치기보다 이해해야 하는 사람을 위한 Wiki입니다. 새로 합류한 개발자나 처음 보는 서비스를 맡은 기술 리드가, 낯선 저장소의 전체 구조를 빠르게 파악해야 하는 상황을 생각해 보면 됩니다. 문서가 코드를 따라가지 못하고 금방 낡는 건 어느 팀이나 겪는 문제인데, Wiki는 코드에서 출발해 페이지를 쓰기 때문에 이 부분을 직접 다룹니다.

Wiki에서 폴더 열기나 공개 저장소 복제(https:// 또는 git@ URL)를 선택하면, 앱이 내 컴퓨터에서 프로젝트 구조를 읽어 들입니다. 프로젝트에 무언가를 쓰기 전에는 반드시 확인 창이 뜨고, 만들 폴더의 경로가 그대로 보입니다. 나중에를 누르면 아무것도 쓰이지 않습니다.

동의한 뒤에는 페이지 생성으로 한꺼번에 만들거나, 페이지 작성으로 주제 하나를 지정해 쓰게 합니다. 설정에서는 페이지 하나에 소스를 얼마나 넘길지(깊이: 빠르게, 표준, 깊게)와 내용을 얼마나 검증할지(검증: 끔, 샘플, 전체)를 고릅니다. 전체로 하면 비용이 대략 두 배가 됩니다. 페이지를 쓰기 전에 비용이 먼저 표시되니, 확인하고 진행하면 됩니다.

각 페이지에는 path:line 출처가 달려 있고, 클릭하면 IDE에서 그 줄이 열립니다. 한 달 뒤 레일의 페이지에 "이 페이지가 인용한 파일이 작성 이후 변경되었습니다" 표시가 붙어 있다면, 다시 생성한 뒤에 읽으라는 신호입니다. 간단한 질문은 페이지 옆 채팅에서 하면 되고, 답변에도 그 프로젝트의 path:line이 붙습니다. "재시도 정책 페이지를 써 줘"처럼 평소 말투로 페이지를 요청할 수도 있습니다. 페이지는 저장소 안의 마크다운 파일이라서, 코드와 같은 PR에서 함께 리뷰할 수 있습니다.

활용 3. 팀에서 AI가 고친 코드를 리뷰 전에 확인할 때

세 번째는 팀 단위로 IDE를 쓰는 경우입니다. 사이드바의 IDE에서 프로젝트 폴더를 열면 왼쪽에 탐색기와 소스 제어, 가운데에 탭, 아래에 터미널·출력·문제·테스트, 오른쪽에 어시스턴트가 놓입니다. 어시스턴트는 모든 기기에서 이어지는 새 동기화 채팅이나, 이 기기에만 남는 새 로컬 채팅으로 시작할 수 있습니다.

공통 함수 formatPrice의 동작을 바꿔야 한다면, 함수를 우클릭하고 코드 그래프 표시(Show Code Graph)를 고릅니다. 호출자와 호출 대상이 목록으로 나옵니다. 채워진 점은 코드에서 직접 읽은 호출이고, 빈 점은 추론한 것이라 직접 확인해 보는 게 안전합니다. 변경 영향은 호출자의 호출자까지 따라가며, 이 예시에서는 "15 symbols · 14 files · 3 tests"로 나옵니다. 행을 클릭하면 해당 줄로 이동하고, 채팅으로 보내기를 누르면 그래프 전체를 어시스턴트에게 컨텍스트로 넘깁니다.

AI가 고친 파일을 확인하는 흐름도 있습니다. 소스 제어에서 수정된 파일을 열면, 마지막으로 AI가 작성한 파일에는 작은 로봇 표시가 붙고 아래 상태 줄에 모델 이름과 변경 이유가 나옵니다. 검토를 누르면 그 쓰기 직전에 저장된 사본과 나란히 비교한 diff가 열려서, 딱 그 변경만 볼 수 있습니다. 예시에서는 타임아웃이 30초에서 3초로 줄어 있었는데, 바로 위 주석에는 큰 사진 업로드는 20초 이상 걸린다고 적혀 있습니다. 커밋 전에 잡아내느냐에 따라 이후 수고가 크게 달라집니다.

내가 저장하지 않은 편집이 있는 파일에 에이전트가 쓴 경우에는, 어느 쪽을 몰래 고르지 않고 내 버전 유지와 디스크 버전 사용 중에서 선택하게 합니다.

다른 기능과의 연결

세 화면은 서로 오갈 수 있습니다. Wiki의 출처를 클릭하면 IDE의 해당 줄로, IDE의 이 폴더의 위키 버튼으로 다시 Wiki로 갑니다. IDE의 어시스턴트와 Wiki 페이지 옆 채팅은 Maestro를 기반으로 해서, 다른 Maestro 채팅과 같은 방식으로 질문하면 됩니다. 정확한 단어가 아니라 의미로 코드를 찾고 싶다면 인덱스 화면에서 로컬 검색 인덱스를 만들어 두면 Maestro가 그것을 활용합니다. Code의 실행을 팀에 공유할 준비가 되면 PR 열기로 그 브랜치의 PR을 엽니다.

각 화면은 제품 페이지의 데모에서 직접 눌러 볼 수 있습니다. Code와 IDE 페이지를 참고하세요.

자주 묻는 질문

데스크톱 앱이 꼭 필요한가요?
네. Code, IDE, Wiki는 로컬 폴더, Git worktree, 셸, 언어 서버를 사용하기 때문에 osFoundry 데스크톱 앱에서 동작합니다.

에이전트가 내 브랜치에 알아서 병합하기도 하나요?
아니요. 실행은 각자 전용 브랜치와 폴더에서 돌고, 내 브랜치는 병합 버튼을 눌렀을 때만 바뀝니다. 기본 설정에서는 테스트를 통과한 브랜치만 병합할 수 있습니다.

Wiki는 Notion 같은 팀 위키인가요?
아닙니다. 코드 저장소를 바탕으로 파일과 줄 번호 출처가 달린 문서를 쓰고, 코드가 바뀐 페이지에 표시를 붙이는 기능입니다. 아키텍처 개요나 온보딩 문서 같은 코드베이스 문서에 맞습니다.

충돌한 브랜치는 어떻게 되나요?
그대로 남습니다. 충돌 없는 브랜치만 먼저 병합하고, 충돌한 브랜치는 에이전트에게 그 위에서 다시 작업하게 하거나, 브랜치로 합치기에서 변경 블록을 골라 가져오면 됩니다.

데스크톱 앱은 osfoundry.io/ko/download에서 무료로 받을 수 있습니다.

osFoundry 로컬 모델 기능 정리, 오픈 모델을 내 PC에서 돌리고 다듬는 법

tauchiii — Fri, 06 Nov 2026 12:51:33 +0000

월요일 오전, 사내 위키 문서를 요약하는 스크립트를 짜던 백엔드 개발자가 손을 멈춥니다. 외부 API에 사내 문서를 보내도 되는지 보안팀 답변은 아직 없고, 팀원 노트북은 대부분 16GB라서 어떤 오픈 모델이 올라갈지도 감이 오지 않습니다. Ollama 설치부터 GGUF 파일 고르기까지 다시 정리하려니 반나절은 그냥 지나갈 것 같습니다.

로컬 LLM 작업을 한 카테고리에 모아 둔 기능

로컬 모델은 osFoundry 데스크톱 앱에서 오픈 웨이트 모델을 내가 관리하는 하드웨어 위에서 다루기 위한 기능 묶음입니다. 사이드바에 '로컬 모델' 카테고리가 따로 있고, 그 안이 Run(실행), Build(만들기), Measure(측정) 세 소제목으로 나뉩니다. Run에는 탐색, 서버, 플레이그라운드 등이, Build에는 내 모델, 데이터셋, 학습, 양자화 등이, Measure에는 평가와 벤치마크 등이 들어 있습니다.

Ollama나 LM Studio를 써 봤다면 Run 쪽은 거의 같은 감각입니다. 모델을 찾고, 받고, 말을 걸어 봅니다. 차이는 그다음 단계입니다. 모델을 작게 만드는 양자화, 내 데이터로 학습시키는 파인튜닝, 내 질문으로 채점하는 평가까지 같은 앱 안에서 이어집니다. 추론 엔진으로 llama.cpp가 함께 들어 있어서 따로 설치할 것도 없습니다. 이 글에서는 실무에서 자주 쓰는 아홉 개 화면(탐색, 서버, 플레이그라운드, 내 모델, 데이터셋, 학습, 양자화, 평가, 벤치마크)을 중심으로 정리합니다.

첫 화면, 모델 탐색

사이드바에서 '탐색'을 누르면 '모델 탐색' 화면이 열립니다. 이 화면 구성을 보면 카테고리 전체의 방향이 보입니다. 먼저 내 컴퓨터 사양을 읽고, 그다음에 모델을 보여 줍니다.

왼쪽 필터에는 텍스트 생성, 요약, 번역, 임베딩 같은 Hugging Face 작업 유형과 멀티모달, 비전, 오디오 그룹이 있고, 위에 검색창이 있습니다.
상단 배너는 모델 목록보다 먼저 내 컴퓨터를 읽은 결과입니다. 예시에서는 16GB 통합 메모리 중 모델에 쓸 수 있는 건 약 12GB, 지금 비어 있는 건 약 9GB이고, 추정치는 Q4_K_M과 4K 컨텍스트 기준이라고 적혀 있습니다.
카드마다 붙는 배지는 초록색 Fits(들어감), 주황색 Tight(빠듯함), 빨간색 Too big(너무 큼) 세 가지이고, 필요한 메모리 추정치도 함께 나옵니다. 안 들어가는 모델도 숨기지 않고, 들어가는 모델을 앞에 둘 뿐입니다.
오른쪽 위 버튼으로 클라우드 API 제공사 목록(Providers)과 이미 가진 모델(내 레지스트리)로 넘어갈 수 있습니다.
카드를 열면 상세 화면에서 '로컬에 설치'로 내려받습니다. 보통은 배지에 맞는 양자화된 GGUF 버전을 고르게 됩니다.

활용 1. 개발팀이 사무실 데스크톱 한 대를 같이 쓰기

처음 예시는 팀 단위입니다. 다섯 명 규모의 스타트업 개발팀에 메모리가 넉넉한 데스크톱이 한 대 있고, 나머지는 모두 노트북이라고 해 보겠습니다. 큰 모델은 데스크톱에만 올라가지만 다들 쓰고 싶어 하는 상황입니다.

데스크톱에서 '서버'를 열고 This Mac을 선택한 뒤 Access 탭으로 갑니다. '로컬 네트워크(LAN)의 다른 기기에서 접근 허용'을 체크하고 원격 액세스를 켜면, 다른 기기에서 쓸 수 있는 모델 목록이 바로 보입니다.

그다음 기기 키 영역에서 '새 키'를 누르고, 팀원 노트북 이름을 붙여 '키 만들기'를 합니다. 키는 하나씩 따로 폐기할 수 있고, 추론 전용 키는 모델 실행만 가능하고 에이전트 세션에는 접근하지 못합니다. 퇴사자나 분실한 노트북이 생겨도 그 키만 지우면 됩니다.

노트북 쪽에서는 '서버'에서 '서버 추가'를 열어 데스크톱 주소와 키를 넣고 '연결 테스트'를 누릅니다. 연결되면 데스크톱 모델이 노트북의 모델 목록에 그대로 나타납니다. 화면에도 안내되어 있듯이 통신은 암호화되지 않은 HTTP라서, 사무실 LAN처럼 믿을 수 있는 네트워크에서 쓰는 것이 전제입니다.

속도가 실무에 쓸 만한지는 '벤치마크'에서 '새 벤치마크'를 만들어 확인합니다. '빠르게' 설정 그대로 돌리면 초당 토큰 수, 첫 토큰까지 걸린 시간(TTFT), 지연 시간이 기록됩니다. 조금 더 빠르게 하고 싶다면 서버의 구성 탭에 있는 '추측 디코딩'에서 같은 계열의 작은 모델을 초안 모델로 지정하고 '지금 다시 시작'한 뒤 다시 측정해 비교하면 됩니다.

활용 2. 1인 개발자가 노트북에 맞게 모델 줄이기

두 번째는 16GB 맥북으로 사이드 프로젝트를 하는 1인 개발자입니다. 마음에 드는 모델이 F16 원본만 있고 크기가 약 15GB라서, 이대로는 메모리에 올라가지 않습니다.

이럴 때 '양자화' 화면을 씁니다. 'The model to shrink'에서 줄일 모델을 고르고, 앱이 추천하는 Q4_K_M을 선택해 실행합니다. 함께 들어 있는 llama-quantize가 이 컴퓨터 안에서 파일을 다시 씁니다. 업로드는 없습니다.

예시에서는 14.97GiB였던 모델이 4.58GiB, 원본의 3.3분의 1로 줄었습니다. 여기서 많이들 놓치는 부분이 품질 확인입니다. '품질 측정'을 누르면 원본과 비교해 다음 토큰이 얼마나 같게 나오는지가 비교 표에 채워지고, '속도 측정'으로 초당 토큰 수도 볼 수 있습니다.

마지막으로 '플레이그라운드에서 사용해 보기'를 누르면 바로 플레이그라운드로 넘어갑니다. 플레이그라운드는 프롬프트 하나를 2~4개 모델에 동시에 보내 답을 나란히 보여 주는 화면입니다.

패널 아래에 TTFT와 단어 수가 나오기 때문에, 원본급 큰 모델과 줄인 모델을 놓고 속도와 답변 톤을 한 번에 비교할 수 있습니다.

활용 3. 비개발 직군이 업무용 모델 고르고 말투 학습시키기

세 번째는 개발자가 아닌 경우입니다. 작은 쇼핑몰에서 CS를 맡고 있는 담당자가 두 가지를 알고 싶어 합니다. 어떤 모델이 정산서 합계를 정확하게 읽는지, 그리고 우리 쇼핑몰 말투로 답장을 쓰게 할 수 있는지입니다.

첫 번째 질문은 '평가'에서 해결합니다. '사용자 지정 벤치마크'를 누르고 이름을 붙인 뒤, 정산서 10건과 각각의 정답 금액을 붙여 넣습니다. 채점 방식은 '정확히 일치' 그대로 두고 '벤치마크 만들기'. 이어서 '새 평가 실행'에서 내 컴퓨터에 있는 모델 두 개와 방금 만든 벤치마크를 선택하고 '평가 시작'을 누릅니다. 질문은 모두 이 컴퓨터 안에서 각 모델로 전달됩니다.

예시에서는 한 모델이 90점, 다른 모델이 70점이고 Diff 열에 20점 차이가 표시됩니다. 남의 질문으로 매긴 리더보드가 아니라 우리 회사 문서로 나온 점수라서 선택 근거로 쓰기 좋습니다.

두 번째 질문은 학습으로 넘어갑니다. 지난 문의와 실제로 보낸 답장을 한 줄에 한 쌍씩 정리한 파일을 준비합니다. '데이터셋'에서는 이 파일을 가져오거나 '허브' 탭에서 공개 데이터를 찾을 수 있고, '라벨링 스튜디오'로 라벨 작업도 할 수 있습니다. 준비가 끝나면 '학습에 사용'으로 넘깁니다.

'학습'에서 '새 작업'을 누르면 베이스 모델 선택부터 검토까지 4단계로 진행하는 창이 뜹니다. '학습 대상'에서 '로컬 (이 기기)'를 고르면 이 기기의 GPU로, 클라우드 크레딧 없이 학습합니다. 학습 방식은 LoRA입니다.

'학습 시작'을 누르면 손실(loss) 값이 내려가는 걸 보면서 기다릴 수 있습니다. 완료된 어댑터는 '내 모델'에 원래 베이스 모델 정보와 함께 등록되고, 완료된 실행에서 모델과 채팅하기를 누르면 기기에서 돌릴 수 있게 준비된 뒤 플레이그라운드에서 바로 말을 걸어 볼 수 있습니다.

다른 기능과 이어지는 지점

로컬 모델 기능은 앱의 다른 부분과도 연결됩니다. 설치한 모델이나 연결한 서버의 모델은 채팅에서 쓰는 모델 목록에 그대로 올라가서, 평소 대화에 쓸 수도 있고 Providers에서 추가한 클라우드 모델과 플레이그라운드에서 나란히 비교할 수도 있습니다. 탐색에서 '노트북에서 사용'을 고르면 해당 모델용으로 준비된 JupyterLab 노트북이 열립니다.

노트북이 아니라 실제 GPU에서 서비스하고 싶어지면 Deployments와 Cloud GPU에서 관리형 엔드포인트로 올리는 흐름으로 이어집니다. 고객 앞에 내놓기 전에는 Safety에서 배포된 모델에 레드팀 테스트를 돌릴 수 있습니다. 기기 안에서 돌아가는 추론 엔진은 로컬 LLM 추론 페이지, 학습 쪽은 LoRA 파인튜닝 페이지에 더 자세히 정리되어 있습니다.

자주 묻는 질문

GPU나 게이밍 PC가 꼭 있어야 하나요?
아닙니다. 최근 노트북이면 소형~중형 모델은 충분히 돌아가고, 탐색 화면의 배지로 내려받기 전에 들어가는지 확인할 수 있습니다. 성능 좋은 데스크톱이나 서버가 있으면 고를 수 있는 범위가 넓어질 뿐입니다.

데이터가 클라우드로 나가나요?
로컬 추론, 양자화, 로컬 학습, 내 컴퓨터 모델로 돌리는 평가는 이 컴퓨터 안에서 끝납니다. 외부 서비스를 쓰는 건 클라우드 GPU 학습과 엔드포인트, Providers의 API 쪽이고, 화면에도 '크레딧 필요' 같은 표시가 붙어 있습니다.

평가와 벤치마크는 뭐가 다른가요?
평가는 내가 정한 질문에 대한 답이 맞는지 채점합니다. 벤치마크는 초당 토큰 수, 첫 토큰까지 걸린 시간처럼 속도와 메모리를 측정합니다.

Ollama나 LM Studio와 같이 써도 되나요?
됩니다. '서버'의 '서버 추가'로 Ollama, LM Studio, vLLM 등으로 돌리고 있는 추론 서버를 연결하면 그 모델도 osFoundry 모델 목록에 함께 나타납니다.

데스크톱 앱은 osfoundry.io/ko/download에서 받을 수 있습니다.

osFoundry Memory 기능 정리, AI가 배운 것을 다음 작업의 맥락으로 쓰는 법

tauchiii — Fri, 06 Nov 2026 12:45:56 +0000

입사 3주 차 신입 개발자가 사내 AI 어시스턴트에게 "배포 전에 꼭 돌려야 하는 체크가 뭐예요?"라고 묻습니다. 답은 그럴듯하지만, 팀이 지난달에 바꾼 절차가 아니라 예전 위키 문서 기준입니다. 정답은 어딘가에 분명히 적혀 있는데, AI가 그 문서를 보지 못했을 뿐입니다.

Knowledge 기능 한 줄 정리

osFoundry에는 이런 문제를 다루는 기능들이 모여 있습니다. Note, Knowledge Base, Memory(Memory Groups 포함), Lessons, Chat History, Indexed Folders입니다. 쉽게 말하면, 사람이 쓴 문서와 AI가 작업하면서 알게 된 내용을 쌓아 두는 곳, 그리고 그중 무엇을 다음 실행에 "맥락(context)"으로 넘길지 정하는 스위치들의 묶음입니다.

데스크톱 앱에서는 하나의 큰 화면이 아니라 역할별로 화면이 나뉘어 있습니다. 내 문서는 노트(Notes), 팀이 함께 관리하는 문서는 지식 베이스(Knowledge Base), 어시스턴트와 에이전트가 기억하는 내용은 메모리(Memory, 부제 "마에스트로가 알고 읽는 것"), AI가 검색할 폴더는 인덱스(Indexes) 화면입니다. 노션 위키 옆에 ChatGPT를 띄워 두고 쓰는 분이라면, 그 위키와 AI의 메모장이 한 앱 안에 있고 칸마다 "AI가 읽어도 되는지" 스위치가 달려 있다고 생각하면 됩니다.

AI 에이전트 메모리를 다룬 글들을 보면 보통 단기 기억(현재 대화)과 장기 기억(외부에 저장했다가 다시 불러오는 것)으로 나누고, 핵심은 전부 저장하는 것이 아니라 "선별"이라고 정리합니다. osFoundry의 메모리 화면은 그 장기 기억을 사람이 직접 보고, 고르고, 끌 수 있게 만든 화면이라고 보면 이해가 쉽습니다.

메모리 화면 둘러보기

메모리 화면에서 Agents를 연 모습입니다(데이터는 예시). 눈여겨볼 부분은 다섯 곳입니다.

왼쪽 메뉴: Memory Groups, Memory Browser, Chat History, Agents, Sessions, Lessons. 그 아래 Indexing 영역의 Chunking Station, Indexed Folders, Embeddings는 인덱스 화면으로 연결됩니다.
메모리가 있는 에이전트 목록: 에이전트마다 메모리와 교훈이 몇 개인지 표시됩니다.
What it knows(아는 내용): 완료된 단계와 채팅 턴에서 저장되어 이후 실행에서 다시 읽히는 내용입니다. 예시에서는 Postgres 버전, 테스트 명령어, 작은 PR을 선호한다는 점이 들어 있습니다.
What it learned(학습한 내용): 리뷰어가 작업을 거부했거나 단계가 실패했을 때만 기록되는 규칙입니다. 문제없이 끝난 실행에서는 기록되지 않습니다.
Move what it learned: Save to a file / Import from a file. 메모리와 교훈은 이 기기에 저장되고 에이전트를 다른 머신으로 옮겨도 자동으로 따라가지 않기 때문에, 여기서 파일로 옮깁니다. 오른쪽 위 Settings와 Turn off로 에이전트 메모리 자체를 켜고 끌 수 있습니다.

활용 1. 팀 온보딩 문서를 AI가 답할 수 있게 만들기

앞에서 본 신입 개발자 팀의 이야기입니다. 팀 리드는 배포 절차, 코드 리뷰 규칙, 장애 대응 런북을 한곳에 모으기로 합니다.

지식 베이스 화면에서 New Knowledge Base(새 지식 베이스)를 만들고, New article(새 문서)로 직접 쓰거나 Import content(콘텐츠 가져오기)로 기존 자료를 가져옵니다. PDF, DOCX, Markdown, TXT, HTML 파일은 물론 Notion, Confluence, GitBook 내보내기, WordPress XML, 웹사이트 크롤링까지 고를 수 있습니다. 실무에서 자주 놓치는 부분은, 문서를 고쳐도 AI 검색 대상이 자동으로 바뀌지 않는다는 점입니다. 수정한 뒤에는 툴바의 Generate chunks(청크 생성)를 눌러 최신 버전이 검색되도록 해 둡니다.

그다음 메모리 → Memory Groups에서 "온보딩", "옛 절차" 같은 그룹을 나눕니다. 각 그룹의 When can this be recalled?(언제 떠올릴 수 있나요?) 설정에서 온보딩 그룹은 Always on(항상 켜짐)으로 두면 프로젝트가 다른 그룹을 골랐더라도 어디서나 검색되고, 옛 절차 그룹은 Never로 두면 저장은 그대로 둔 채 검색에서 완전히 빠집니다. 이렇게 하면 처음 장면처럼 예전 문서가 답에 섞이는 일을 줄일 수 있습니다.

활용 2. 처음 보는 코드베이스를 의미로 검색하기

레거시 프로젝트를 넘겨받은 백엔드 개발자의 경우입니다. "로그인 잠금 로직이 어디 있지?"를 grep으로 찾으려 해도, 코드에는 lockout이라는 단어가 한 번도 안 나옵니다.

인덱스 화면의 Sources 탭에서 Add folder로 프로젝트 폴더를 고릅니다. 스캔은 무료이고, 무엇이 인덱싱될지 먼저 보여 줍니다. 로컬에서 인덱싱(Index locally)을 고르면 내 컴퓨터의 모델로 임베딩을 만들기 때문에 코드가 밖으로 나가지 않습니다. 파일이 바뀌면 자동으로 다시 인덱싱 스위치를 켜 두면 수정 사항도 따라갑니다.

이제 마에스트로에게 평소 말투로 질문하면, 에이전트가 키워드와 의미를 함께 써서 폴더를 검색하고 파일 경로와 줄 번호로 답합니다.

작업하면서 에이전트가 알게 된 사실은 메모리 → Agents → What it knows에 쌓입니다. 다음 대화는 그 내용을 안고 시작하므로 같은 설명을 반복할 일이 줄고, 쌓인 내용은 언제든 직접 확인할 수 있습니다.

활용 3. 에이전트가 배운 "교훈"을 사람이 검수하기

에이전트가 변경안을 만들고 리뷰어 단계가 검사하는 팀이라면 Lessons 화면을 꼭 봐 두는 게 좋습니다. 리뷰어가 거부한 실행이나 실패한 단계에서 교훈이 기록되고, 에이전트는 다음 실행 전에 가장 최근 교훈을 최대 8개까지 읽습니다. 교훈은 이 컴퓨터에만 저장되고 업로드되지 않습니다.

메모리 → Lessons를 열면 모든 에이전트의 교훈이 출처 실행 ID와 함께 "When …: …" 형식으로 나열됩니다. "테스트가 실패하면 코드를 고친다. 테스트를 수정하거나 건너뛰거나 지워서 통과시키지 않는다" 같은 교훈은 그대로 둡니다.

주의할 것은 from outside content(외부 콘텐츠에서 가져옴) 배지가 붙은 교훈입니다. 예시의 항목은 에이전트가 읽은 가격 페이지에서 나온 것으로, 특정 요금제를 항상 추천하라는 내용입니다. 에이전트는 이런 교훈을 참고만 하고 지시로 따르지는 않지만, 남겨 둘 이유도 없으니 Retire(폐기)를 누릅니다. 폐기된 항목 표시를 켜면 해당 교훈이 회색으로 남아 있고 다시 복원할 수 있어서, 나중에 경위를 추적하기도 좋습니다.

다른 기능과의 연결

Knowledge 기능은 혼자 쓰기보다 다른 화면에 맥락을 넘기는 역할을 합니다. 가장 많이 읽는 쪽은 앱 안의 어시스턴트인 마에스트로로, 필요할 때 메모리 그룹을 검색하고 인덱싱된 폴더는 폴더 검색으로 씁니다. Agent team이나 Single agent에서 일하는 에이전트는 각자의 메모리와 교훈을 참여하는 대화에 가져갑니다. 인덱스 화면의 Health 탭에는 Chunking Station과 Embeddings가 있어서, 변경되었거나 실패했거나 아직 청크로 나뉘지 않은 노트, 문서, 파일을 확인할 수 있습니다. Chat History에는 긴 대화가 요약(컴팩션)될 때 원래 대화가 파일로 남아, 요약 뒤의 원문으로 돌아갈 수 있습니다. 노트 화면의 가져오기… → 폴더 가져오기… 또는 .zip 아카이브 가져오기…로 Obsidian 보관함이나 Notion 내보내기를 노트로 옮길 수도 있습니다. 자세한 내용은 에이전트 메모리 그룹과 지식 베이스 소개 페이지에 정리되어 있습니다.

자주 묻는 질문

AI가 내 노트를 전부 알아서 읽나요?
아닙니다. 어시스턴트는 메모리를 자동으로 읽지 않고, 질문에 기억이 필요할 때 검색합니다. 그 검색이 어디까지 닿는지는 메모리 그룹별 Always on / Normal / Never 설정이 정하고, 폴더는 인덱스 화면에서 추가하기 전까지 읽지 않습니다.

데이터는 어디에 저장되나요?
에이전트의 메모리와 교훈은 이 기기에 저장되며, 교훈은 업로드되지 않습니다. 메모리 그룹은 개인용 또는 워크스페이스 공용, 기기 또는 클라우드로 나뉘고, 메모리 화면 상단에 양쪽 개수가 표시됩니다.

Chat History, Sessions, Lessons는 뭐가 다른가요?
Chat History는 대화 원문, Sessions는 에이전트가 각 단계에서 남긴 기록, Lessons는 다음부터 에이전트가 따르는 규칙입니다. 앞의 둘은 확인용 증거이고, Lessons는 폐기하고 복원할 수 있는 지침입니다.

데스크톱 앱이 꼭 필요한가요?
폴더 인덱싱, 노트로 파일 가져오기, Chat History, 에이전트 메모리 보기처럼 내 컴퓨터를 읽는 기능은 데스크톱 앱에서 동작합니다. 다운로드 페이지에서 받을 수 있습니다.

osFoundry Loop와 Graph 차이 정리, 반복 작업과 분기 워크플로를 구분해서 쓰는 법

tauchiii — Fri, 06 Nov 2026 12:40:25 +0000

금요일 오후 6시, 배포 전에 테스트를 돌렸더니 두 개가 빨간색입니다. AI에게 고쳐 달라고 했고 "수정했습니다"라는 답이 왔는데, 다시 돌려 보면 여전히 실패합니다. 로그를 붙여 넣고, 다시 묻고, 또 붙여 넣는 사이에 퇴근 시간이 지나갑니다.

이런 "될 때까지 반복"과 "상황에 따라 갈라지는 흐름"을 사람이 붙어 있지 않아도 돌아가게 만드는 기능이 osFoundry 데스크톱 앱의 Loop(루프)와 Graph(그래프)입니다. 이 글에서는 실제 화면을 기준으로 두 기능이 무엇인지, 실무에서는 언제 어느 쪽을 쓰는지 정리합니다.

Loop와 Graph, 한 문단으로 정리

Loop는 에이전트 팀에게 목표, 채점 방법, 상한을 주고 목표를 달성할 때까지 라운드를 반복하게 하는 기능입니다. 최대 라운드 수와 "연속 몇 번 실패하면 멈출지"가 정해져 있고, 필요하면 일정 같은 트리거를 붙여 정기 실행도 할 수 있습니다. Graph는 중간 결과에 따라 다음 단계가 달라지는 작업을 위한 워크플로입니다. 조건 분기, 실패한 부분만 다시 하기, 여러 에이전트에게 동시에 나눠 주기, 사람의 승인 기다리기, 다른 Graph 호출하기를 하나의 프로그램으로 저장해 두고 재사용합니다.

두 기능 모두 데스크톱 앱 사이드바에 있고, "루프" 바로 아래에 "그래프"가 있습니다. 구분 기준은 앱 코드에도 적혀 있을 만큼 단순합니다. Loop는 항상 같은 경로로 가고, Graph는 가면서 경로를 고릅니다. 익숙한 도구로 비유하면 Loop는 "통과 기준이 내장된 정기 잡", Graph는 "진짜 if 문을 쓸 수 있는 파이프라인 정의"에 가깝습니다. 참고로 Graph는 차트를 그리는 기능도, 지식 그래프도 아닙니다.

Loop 실행 화면 둘러보기

테스트를 통과시키는 Loop가 끝난 뒤의 화면입니다(테스트 이름 등은 예시 데이터). 처음 볼 때 알아 두면 좋은 부분은 다음과 같습니다.

왼쪽 세션 목록: Loop 실행은 한 번마다 독립된 세션이 됩니다. 아래에 붙는 "Verified"는 마지막 라운드가 실제 검사를 통과했다는 뜻이지, AI의 자기 보고가 아닙니다.
가운데 상단의 라운드 표시: "Round 3 of 4"와 판정 방법(여기서는 npm test 종료 코드가 0이면 완료), 그리고 연속 검증 실패 횟수가 나옵니다. 헛도는 Loop를 멈추는 기준이 이 카운터입니다.
"라운드" 탭: 라운드마다 "1 of 3 met", "2 of 3 met", "3 of 3 met"처럼 몇 개 조건을 만족했는지 나오고, 펼치면 어떤 조건이 통과했는지 볼 수 있습니다. 옆의 "에이전트 세션"에는 에이전트별 대화가, "팀 구성원"에는 참여 멤버가 나옵니다.
오른쪽 인스펙터: Goal, 트리거, Hooks 탭에서 목표 진행률, 이 세션을 무엇이 시작하는지, 실행 주변의 가드레일을 확인합니다.
위쪽 "일시중지"와 "취소": 다음 검사를 기다리지 않고 지금 멈추고 싶을 때 씁니다.

활용 1: 테스트가 진짜 통과할 때까지 돌리기 (1인 개발자)

도입부의 상황입니다. AI의 "수정했습니다"를 믿는 대신, 테스트 러너가 합격 여부를 정하게 합니다.

사이드바에서 "루프"를 열고 "새 세션"을 누르면 "새 루프 실행" 대화상자가 뜹니다. 검색창에 "JS suite"를 입력하면 Get the JS suite green이 나옵니다. 시작하기 전에 오른쪽 카드에서 동작 방식을 확인할 수 있다는 점이 핵심입니다.

누가 실행하나: debugger 에이전트가 리드하고 vitest-expert, jest-expert, typescript-expert가 참여
어떻게 멈추나: 최대 4라운드, 연속 3번 실패하면 중지
어떻게 채점하나: npm test를 실행해 종료 코드가 0일 때만 완료

목표 문구에는 "테스트를 통과시키려고 assertion을 고치지 말 것"도 들어 있습니다. AI가 자주 빠지는 "테스트 쪽을 고쳐서 통과시키기"를 처음부터 막아 두는 셈입니다.

"시작 방법"에서 "추가만 하기" 대신 "지금 한 번 실행"을 고르고, 프로젝트와 "작업 위치" 폴더를 지정한 뒤 "지금 실행"을 누릅니다. 이후에는 "라운드" 탭을 열어 두기만 하면 됩니다. 예시 실행에서는 1라운드에 3개 중 1개, 2라운드에 2개, 3라운드에 3개 모두 통과했고, 그 시점에 Loop가 스스로 멈추면서 세션에 Verified가 붙었습니다.

결과물은 "고쳤습니다"라는 메시지가 아니라, 어느 라운드에서 어떤 테스트가 통과했는지 남은 기록입니다. 같은 목록에 Python, Go, Rust, Java 테스트, 타입 에러, lint, 불안정한 테스트 찾기용 Loop도 있어서 "깨끗해질 때까지 반복" 류의 작업에 그대로 쓸 수 있습니다.

활용 2: 파일마다 따로 리뷰하고 하나로 합치기 (팀 리드)

이번에는 팀 리드의 상황입니다. 큰 변경 사항이 올라오면 파일마다 리뷰어를 따로 붙이고, 마지막에 하나의 리포트로 합치고 싶습니다. 위험한 변경은 사람이 승인한 뒤에만 적용하고 싶고요.

여기서 Loop는 맞지 않습니다. Loop는 매 라운드 같은 계획을 반복하기 때문입니다. "항목 수만큼 펼쳤다가 합치기", "중간에 멈춰서 사람에게 묻기"처럼 흐름이 갈라지는 작업은 Graph가 담당합니다.

사이드바에서 "그래프"를 열고 목록 옆의 "+"를 누릅니다. "그래프 만들기"에서 "작동하는 그래프로 시작" 또는 "스타터 선택"을 고릅니다.
스타터를 고르면 자주 쓰는 형태의 예제가 사용 시점 설명과 함께 나옵니다. 여기서는 Review each item, then merge(항목마다 에이전트 하나씩 동시에 돌리고, 마지막에 한 번에 합치기)를 씁니다.
"세션 구성"에서 "동시 최대 에이전트 수", 토큰 경고, "하드 토큰 상한", 기본 입력, 단계별 에이전트와 모델을 정합니다.
"실행"을 누르면 실행 화면에서 단계별 진행을 실시간으로 보고, "일시중지"나 "취소"도 할 수 있습니다.

승인이 필요한 흐름이라면 Propose, ask, then apply 스타터가 출발점입니다. 변경안을 만든 뒤 멈추고, 사람이 "승인"을 눌렀을 때만 적용합니다. 승인을 기다리는 동안 병렬로 진행 중인 다른 작업은 계속됩니다. 이 밖에도 Triage and route(한 번 분류해서 전문 에이전트 한 명에게만 보내기), Three opinions, one answer(같은 질문을 세 갈래로 묻고 판정자가 하나로 정리) 같은 스타터가 있습니다.

Graph의 프로그램 자체는 코드이고, 드래그 앤 드롭 다이어그램이 아닙니다. 분기나 횟수 제한이 있는 재시도는 실제 제어문이어야 하기 때문입니다. 다만 직접 처음부터 쓸 필요는 없고, Maestro나 에이전트에게 작성을 맡긴 뒤 입력과 상한은 세션 구성 화면에서 바꾸는 식으로 나눠 쓰면 됩니다.

실행이 끝나면 "변경 사항" 탭에서 그 실행이 만들거나 수정한 파일을 확인할 수 있고, 일부는 되돌릴 수도 있습니다. "기록" 탭에는 이전 실행이 쌓이니, 실패한 실행과 고친 뒤의 실행을 나란히 비교할 수 있습니다. 브라우저에서도 Graph 내용을 읽을 수는 있지만, 실행은 데스크톱 앱에서 합니다.

활용 3: 평일 아침 경쟁사 체크 자동화 (기획자, 비개발자)

마지막은 코드를 쓰지 않는 기획자나 마케터의 경우입니다. 매주 경쟁사 사이트를 손으로 돌아보던 일을 Loop에 맡깁니다.

"새 루프 실행" 목록 맨 위의 "여기서 시작하세요 — 별도 설정이 필요 없습니다" 영역에 Watch the competitors가 있습니다. 웹 검색만 하고 내 파일은 건드리지 않기 때문에 준비 없이 쓸 수 있는 Loop로 분류되어 있습니다. "이번 실행의 목표 (선택)"에 지켜볼 회사와 볼 항목(예: 가격, 신기능, 채용)을 적고, "지금 한 번 실행"을 고른 뒤 "지금 실행"을 누릅니다. 첫 리포트에는 지난번 이후 바뀐 점만 날짜와 출처가 붙어서 정리되고, 회사가 스스로 주장한 내용은 검증되지 않은 주장으로 따로 표시됩니다.

결과가 괜찮다면 정기 실행으로 바꿉니다. 오른쪽 트리거 탭에서 "일정 추가"를 누르면 일정 설정 화면이 열립니다. Every 30 min, Hourly, Daily 09:00, Weekdays 09:00 프리셋 중 하나를 고르면 cron 식과 다음 세 번의 실행 시각이 표시됩니다. 실무에서 유용한 질문도 두 가지 있습니다. 이전 실행이 아직 끝나지 않았으면 건너뛸지 기다릴지, 컴퓨터가 잠자기 상태였으면 몇 시간 늦게까지 실행할지입니다.

"일정 저장"을 누르면 트리거 탭에 "On a schedule"과 다음 실행 시각이 나타납니다. 일정은 데스크톱 앱이 열려 있는 동안 이 컴퓨터에서 실행되므로, 늦은 실행 허용 설정이 그 공백을 메워 줍니다.

다른 기능과의 연결

Loop의 "팀 구성원"에 들어가는 에이전트는 Agent team이나 Agent Registry에서 준비한 것입니다. Loop 자체는 재사용 가능한 프리셋으로 osStudio에서 버전 관리되므로, 품질 기준이나 재시도 상한을 바꿔도 이력이 남습니다.
Graph는 만들 때 고정 식별자를 받습니다. Loop나 다른 Graph에서 호출할 수 있게 하기 위해서입니다. 덕분에 "평일 9시에 도는 Loop가 분기하는 Graph를 호출"하는 구성이 가능합니다.
Message에서는 Loop와 Graph도 사람, 단일 에이전트와 함께 채널 멤버가 될 수 있어서, 진행 상황이 팀이 원래 쓰는 방으로 들어옵니다.

정기 실행은 에이전트 cron 실행, 시작 조건 전반은 에이전트 트리거 페이지에 더 자세히 정리되어 있습니다.

자주 묻는 질문

Loop는 그냥 cron 잡인가요?
아닙니다. 일정은 선택 사항일 뿐이고, Loop의 본체는 "팀 + 목표 + 채점 + 상한"입니다. 라운드마다 어떤 조건을 만족했는지 기록이 남고, 트리거 없이 수동으로 한 번만 돌려도 됩니다.

Loop도 병렬로 돌아가는데 Graph는 언제 필요한가요?
병렬 여부는 기준이 아닙니다. 이전 단계 결과에 따라 다음 경로가 바뀔 때, 실패한 부분만 다시 하고 싶을 때, 사람 승인을 끼워야 할 때, 다른 워크플로를 불러야 할 때 Graph를 씁니다. 매번 같은 단계로 끝난다면 Loop가 더 간단합니다.

멈추지 않고 돌아서 API 비용이 많이 나오지 않을까요?
제공되는 Loop에는 최대 라운드 수와 연속 실패 시 중지가 있고, 시작 전에 카드에서 확인할 수 있습니다. Graph에는 "동시 최대 에이전트 수"와 "하드 토큰 상한"이 있습니다.

코딩을 못 해도 쓸 수 있나요?
Loop는 대화상자에서 고르고 목표와 트리거만 정하면 됩니다. Graph 내부는 코드지만, 스타터에서 시작해 Maestro에게 수정을 맡기면 입력, 상한, 단계별 에이전트는 화면에서 바꿀 수 있습니다.

데스크톱 앱은 osfoundry.io/ko/download에서 받을 수 있습니다.

osFoundry Maestro 플랜 모드와 승인 모드 정리, AI 에이전트에게 맡기기 전에 계획부터 보는 법

tauchiii — Fri, 06 Nov 2026 12:34:51 +0000

밤 11시, 스타트업 백엔드 개발자 지훈 님은 AI 에이전트에게 리팩터링을 맡겨 두고 "허용" 버튼을 누르고 있습니다. 처음 몇 번은 명령어를 꼼꼼히 읽지만, 열 번쯤 넘어가면 내용은 보지 않고 버튼만 누르게 됩니다. 흔히 말하는 승인 피로입니다. 그렇다고 전부 자동으로 돌리기에는, 에이전트가 무엇을 읽고 왜 그 파일을 고쳤는지 나중에 확인할 방법이 없습니다.

Maestro 한눈에 보기

Maestro는 osFoundry 데스크톱 앱의 메인 AI 작업 공간으로, 사이드바의 Maestro에서 열 수 있습니다. 채팅처럼 요청을 보내면 에이전트가 로컬 폴더의 파일을 읽고, 검색하고, 수정하고, 터미널 명령을 실행하는데, 그 과정이 전부 대화 안에 한 줄씩 남습니다. Claude Code나 Cursor에서 "계획 먼저, 실행 나중"으로 쓰는 플랜 모드를 써 봤다면 비슷한 개념이 들어 있다고 보면 됩니다. 차이는 데스크톱 앱 화면 안에서 작업 기록, 근거, 비용, 변경 파일을 탭으로 나눠 볼 수 있고, 승인 방식도 채팅마다 고를 수 있다는 점입니다.

화면은 네 가지 질문으로 보면 쉽습니다

에이전트에게 일을 맡긴 뒤 궁금한 것은 보통 네 가지입니다. 화면의 각 부분이 그 질문에 하나씩 답합니다.

무엇을 했나: 대화 안의 작업 단계 행입니다. 예시에서는 src/ 목록(38개 파일) → deleteUser grep(0건) → account.ts, users.ts 읽기 순서로 진행됐고, 행마다 소요 시간이 붙습니다. 행을 펼치면 도구에 넘긴 입력과 결과가 그대로 보입니다.
무엇을 근거로 했나: 상단의 소스 탭입니다. 답을 만들 때 참고한 자료가 남습니다.
무엇을 바꿨나: 변경 기록 탭과 파일 탭입니다. 이 채팅이 쓴 파일이 모입니다. 수정 내용은 오른쪽 미리보기에 diff로 열립니다.
얼마나 들었나: 로그 탭의 비용(Costs)에서 모델별, 요청별 비용을 확인합니다.

그리고 이 모든 것을 미리 제어하는 곳이 입력창 위의 바(샌드박스, 플랜, 도구, 목표)와 입력창 아래의 메뉴(폴더, 저장소, Router, 모델, 승인 모드 등)입니다.

실무에서 써 본 세 가지 장면

프리랜서 개발자, 클라이언트 앱에 회원 탈퇴 기능 붙이기

외주로 받은 앱에 설정 화면의 "계정 삭제" 버튼을 추가해야 합니다. 세션과 사용자 데이터를 지우는 기능이라 잘못 건드리면 곤란하고, 결제 쪽 코드는 클라이언트가 따로 관리하고 있습니다. 이럴 때는 플랜 모드를 켭니다.

입력창 위 바에서 플랜을 눌러 켭니다.
"설정에 계정 삭제 버튼 추가해 줘"라고 요청합니다.
에이전트는 파일 6개를 읽기만 합니다. 플랜 모드에서는 쓰기나 명령 실행 같은 도구를 앱이 실행 단계에서 거부하기 때문에, 프롬프트로 "아직 수정하지 마"라고 부탁하는 것과 달리 실수로 넘어갈 여지가 없습니다.
"승인 대기 중" 플랜 카드가 도착합니다.

예시 카드에는 수정할 파일 4개와 테스트 3개 추가, 그리고 src/billing/은 Stripe 쪽에 기록이 남으므로 건드리지 않는다는 내용이 적혀 있습니다. 카드가 오면 플랜 모드는 자동으로 꺼집니다. 범위가 맞으면 승인을 누르고, 그다음에야 파일 수정과 npm test -- account 실행(3개 통과)이 진행됩니다. 범위가 마음에 안 들면 취소를 누르면 되고, 폴더는 손대지 않은 상태 그대로입니다. 클라이언트에게 "이번에 바꾼 파일은 이 4개입니다"라고 설명하기도 편해집니다.

인수인계 받은 레거시 프로젝트, 로직 위치부터 찾기

에이전시에서 다른 팀이 만든 서비스를 넘겨받았습니다. "로그인 몇 번 틀리면 막히던데, 그거 어디서 처리해요?"라는 문의가 왔는데, 코드에서 lock으로 검색하면 아무것도 나오지 않습니다.

인덱스 화면에서 프로젝트 폴더를 한 번 추가해 의미 검색이 되도록 합니다.
그 폴더를 연결한 Maestro 채팅에서 위치를 묻습니다.
작업 단계에 폴더 검색 2건, 이어서 throttle.ts READ가 찍히는 것을 확인합니다.

답은 src/auth/throttle.ts(1~46줄)와 src/routes/session.ts(22~61줄)를 짚어 줍니다. 코드에는 lock out이라는 표현이 없고, 5번 실패하면 쿨다운을 15분 뒤로 잡은 뒤 비밀번호를 확인하기 전에 429를 반환하는 구조라는 설명도 붙습니다. 어떤 파일을 읽고 낸 답인지 행으로 남아 있으니, 문의에 답하기 전에 해당 줄을 미리보기로 열어 직접 확인하면 됩니다. 읽기만 하는 작업이라 승인 모드는 기본값이어도 문제없습니다.

팀 리드, 디자이너에게 문구 수정을 맡길 때 규칙 정하기

런칭 페이지 문구는 디자이너가 다듬는데, 파일은 개발 저장소의 src/Launch.tsx입니다. 팀 리드는 디자이너가 Maestro로 직접 고치게 하되, 몇 가지 안전장치를 걸어 두기로 합니다.

승인 모드를 "권한 및 승인"으로 바꿉니다. 도구를 호출하기 전마다 확인을 받습니다. 기본값인 "자동 수락"은 도구를 바로 실행하고, "플랜 우선"은 실행 전에 플랜을 작성하며, "우회"는 푸시와 폼 제출까지 포함해 승인을 전부 생략합니다. 메뉴에서도 우회는 경고 색으로 표시됩니다.
샌드박스를 켭니다. 쓰기 작업이 작업 폴더가 아니라 브랜치 쪽에 쌓입니다.
필요 없는 도구나 MCP는 도구 탭에서 이 채팅에 한해 꺼 둡니다.
디자이너가 "docs의 톤 가이드에 맞춰 문구 다듬어 줘"라고 요청하면, Maestro가 docs/tone.md를 읽고 소스를 검색한 뒤 수정을 제안합니다. diff를 확인해 수락하고, "브랜치로 내보내기"로 개발자 리뷰에 넘깁니다.

승인 창이 한 번에 하나씩 뜨는 대신 범위 자체를 좁혀 두는 방식이라, 승인 피로를 줄이면서도 메인 브랜치에 바로 들어가는 일은 막을 수 있습니다.

질문의 무게에 따라 다른 탭을 고르기

모든 질문에 Maestro가 필요한 것은 아닙니다. 같은 화면과 사이드바에 더 가벼운 선택지가 있습니다.

가벼운 질문: Maestro 화면의 Model chat 탭. 고른 모델 하나가 답하는 읽기 전용 대화로, 폴더나 도구, 승인 기능은 없습니다.
특정 모델로 작업까지: 사이드바의 채팅. 대화 전체를 모델 하나로 고정하고, 파일 수정 제안을 수락하거나 거절할 수 있습니다. 턴마다 모델이 바뀌지 않습니다.
답이 갈릴 만한 질문: Multi chat 탭. 같은 질문을 여러 모델에 보내 나란히 비교(Compare)하거나, 서로의 답을 익명으로 채점하게 한 뒤 한 모델이 종합하게(Council) 할 수 있습니다.

Maestro에서 시작한 작업은 다른 기능으로 넘어가기도 합니다. 출처가 붙은 보고서는 Research, 별도 브랜치에서 돌리는 코딩 에이전트는 Code, 샌드박스 변경을 합치는 곳은 버전 → 병합 스테이션입니다. 화면 구성은 Maestro 소개 페이지, 승인 흐름은 플랜 모드 페이지에서 데모로 볼 수 있습니다.

처음 쓸 때 많이 묻는 것

기본값이 자동 수락이면 위험하지 않나요?
읽기 위주의 질문이라면 자동 수락으로도 충분합니다. 파일을 고치거나 외부로 무언가를 보내는 작업이라면 "권한 및 승인"이나 플랜 모드, 샌드박스를 함께 쓰는 편이 안전합니다.

플랜 내용이 마음에 안 들면 어떻게 하나요?
취소를 누르면 아무것도 바뀌지 않은 상태로 끝납니다. 범위를 바꿔서 다시 요청하면 새 플랜을 받을 수 있습니다.

이미 적용된 변경을 되돌릴 수 있나요?
채팅에 /rewind를 입력하면 해당 턴이 바꾼 파일을 원래대로 돌릴 수 있습니다.

작업 단계 행이 너무 길게 펼쳐져요.
"과정 상세" 설정을 "간단히"로 바꾸면 접힌 상태로 보입니다. 표시만 달라지고 실행 방식은 그대로입니다.

데스크톱 앱은 osfoundry.io/ko/download에서 받을 수 있습니다.

osFoundry Agent team 기능 정리, 리더와 전문 에이전트에게 역할을 나눠 맡기는 법

tauchiii — Fri, 06 Nov 2026 12:29:18 +0000

오전 7시 40분, 서비스 기획자 지은 씨는 팀장에게 "주 4일제를 해도 성과가 유지된다는 근거, 출처까지 붙여서 점심 전까지"라는 요청을 받았습니다. 챗봇에 물어보면 그럴듯한 답은 바로 나옵니다. 문제는 숫자를 찾은 AI가 그 숫자가 맞는지 검증까지 스스로 한다는 점입니다. 자기 답을 스스로 반박하는 경우는 거의 없습니다. 자료를 찾는 사람, 숫자를 뽑는 사람, 출처 없는 숫자를 돌려보내는 사람이 따로 있어야 합니다.

한 문단으로 보는 Agent와 Agent team

osFoundry는 AI 작업을 내 컴퓨터에서 돌리는 데스크톱 앱입니다. 에이전트에게 일을 맡기는 입구가 두 개 있습니다. Agent(사이드바 이름은 Single agent)는 에이전트 하나에 목적 하나를 맡기는 방식입니다. 세션마다 AG-0001L 같은 ID가 붙고, 실행 기록이 남아서 나중에 그대로 따라가 볼 수 있습니다. Agent team은 리더 에이전트가 일을 단계별로 나눠 전문 멤버에게 하나씩 배정합니다. 각 단계의 결과는 사용자에게 전달되기 전에 리뷰어가 먼저 확인합니다. 두 메뉴 모두 사이드바의 Agents 섹션에 나란히 있고, 열리는 화면도 같습니다. 차이는 멤버 수뿐입니다. 비유하자면 PM이 있는 단톡방과 비슷합니다. 다만 요청, 인계, 반려가 전부 기록으로 남아서 나중에 다시 확인할 수 있습니다.

화면 구성 살펴보기

팀 세션 하나가 끝난 상태입니다. 질문과 답변은 데모용 예시 데이터입니다.

가운데, 리더와의 대화: 헤더에 "Leader · Orchestrate your team"이라고 표시됩니다. 질문은 여기에 한 번만 쓰면 되고, 정리된 답도 여기로 돌아옵니다. 예시에서는 행마다 출처가 달린 표와 "Where sources disagree", "Not covered" 항목이 함께 나옵니다.
가운데 상단 탭: Chat, Team mail, Email, Handoffs, Sub-agents, Proposals, Files가 있습니다. Handoffs에서는 누가 누구에게 일을 넘겼는지 확인합니다. Proposals에는 에이전트가 파일이나 설정 변경을 제안한 내용이 쌓입니다. 제안은 승인되기 전까지 반영되지 않습니다.
오른쪽, Agent session 패널: 멤버마다 카드가 한 장씩 있습니다. 리더가 맡긴 일, 호출한 도구(web_fetch, web_search), 결과가 표시되고, 그 아래에 리뷰어의 판정(예: "Approved")이 붙습니다. 위쪽에는 실행 선택("Run 1 · 07:40 AM")과 Cards / Graph 전환 버튼이 있습니다.
Team roster 탭: 이 세션에서 움직일 수 있는 멤버 목록입니다. 팀은 "누가 참여하는가"를 정한 명단일 뿐, 워크플로가 아닙니다. 작업 순서는 리더가 세우는 계획에 따라 정해집니다.
인스펙터: Goal, Trigger, Hooks 탭이 있습니다. 각각 도달할 목표, 이번 실행을 시작시킨 계기, 작업 전후의 체크를 확인하는 곳입니다.

실무 활용 1: 출처가 필요한 리서치는 팀에게

지은 씨의 경우처럼 자료 찾기, 숫자 추출, 반대 근거 찾기, 정리로 단계가 나뉘고, 중간 결과를 다른 눈으로 검증해야 하는 일은 팀이 잘 맞습니다.

사이드바에서 Agent team을 열고 New session을 누릅니다.
New team session 창에서 "Start from a team"을 그대로 두고, Team 목록에서 Deep Research Team을 고릅니다. deep-research-agent, research-analyst, data-researcher, search-specialist, academic-researcher 다섯 멤버가 불러와집니다.
"Who leads"에는 Orchestrator가 들어가 있습니다. 작업을 먼저 계획한 뒤 아래 에이전트들에게 단계를 위임하는 역할입니다. 특정 멤버에게 리더를 맡기고 싶다면 "make leader"를 누릅니다.
Create를 누르고, 리더 채팅에 질문을 한 번만 보냅니다.

리더는 질문을 다섯 단계로 나눕니다. 시험 사례 찾기, 연구 찾기, 숫자 모으기, 반대 근거 찾기, 마지막으로 하나의 답으로 정리하기입니다. 세 멤버가 동시에 시작하고, 숫자를 모으는 Data Researcher는 Search Specialist의 목록이 나온 뒤에 움직입니다.

이번 실행에서는 Data Researcher가 낸 40%라는 숫자가 "Sent back"으로 돌아왔습니다. 출처, 날짜, 무엇을 잰 숫자인지가 빠져 있다는 이유였습니다. 해당 단계는 다시 실행되었고, 출처를 찾은 뒤 승인되었습니다. 지은 씨가 받는 최종 결과는 답 하나입니다. 그 안의 숫자는 찾은 에이전트가 아닌 다른 역할이 한 번 더 확인한 것입니다. "Not covered" 항목도 솔직하게 적혀 있어서 팀장 보고에 그대로 쓸 수 있습니다.

실무 활용 2: 릴리스 작업에서 "누가 무엇을 했는지" 남기기

작은 제품팀에서 릴리스를 맡은 민수 씨의 팀 세션에는 리더와 함께 Release Drafter, Change Auditor, Docs Reviewer, QA Summarizer, Approval Prep 멤버가 있습니다. 릴리스 노트 초안, 변경 사항 감사, 문서 검토, QA 요약, 승인 자료 준비를 각자 맡습니다. 역할을 이름이 아니라 책임 범위로 나눈 구성입니다.

실행 전에 인스펙터의 Goal 탭에서 Set a goal을 누릅니다. 목표는 성공 기준으로 나뉘고, 처음에는 실패 상태였다가 에이전트가 충족할 때마다 초록색으로 바뀝니다. 기준을 모두 통과하거나 라운드 한도에 닿을 때까지 계속 실행됩니다. 민수 씨는 "승인 자료가 모두 준비됨"을 포함해 기준 세 개를 적었습니다.
실행 중에는 Handoffs 탭에서 리더 → 각 멤버 → 리더로 이어지는 흐름을 확인합니다.
멤버가 설정 변경을 제안하면 Proposals 탭에 나타나고, 민수 씨가 승인하지 않는 한 반영되지 않습니다.
중간에 검토가 필요하면 패널 상단의 Pause로 멈추고, 리더 채팅에 답장해서 방향을 바꿀 수 있습니다.

끝나면 릴리스 자료와 함께, 어느 부분을 누가 쓰고 누가 확인하고 누가 승인했는지 기록이 남습니다. "릴리스 노트의 이 문장은 어디서 나온 건가요?"라는 질문에도 바로 답할 수 있습니다.

실무 활용 3: 1인 개발자라면 단일 에이전트로 충분

모든 일에 팀이 필요한 것은 아닙니다. 1인 개발자 준호 씨는 일주일에 몇 번씩 회의록을 액션 아이템으로 정리하는데, 매번 같은 규칙 문단을 채팅에 붙여 넣고 시작했습니다. 이런 일은 역할 분담이 오히려 부담입니다. 규칙을 기억하는 에이전트 하나면 됩니다.

사이드바의 Single agent를 열고 New session을 누릅니다.
Create in chat 탭에서 원하는 일을 한 줄로 쓰고 Start를 누릅니다.
열린 채팅은 아직 준호 씨의 에이전트가 아니라 설정용 에이전트입니다. 몇 가지 질문에 답하면 이름, @handle, 지시문 전체를 제안합니다.
입력창 위에 나타난 카드에서 Show instructions로 지시문을 확인하고 Create agent를 누릅니다.

이렇게 만든 Action Items 에이전트에는 담당자나 기한을 추측하지 말고 빠졌다고 표시하라는 규칙이 들어 있습니다. 같은 채팅이 그대로 이 에이전트가 되고, 세션 목록에는 ID와 함께 남습니다. 다음부터는 이 에이전트를 골라 회의록을 붙여 넣기만 하면 됩니다.

다른 기능과의 연결

Agent와 Agent team이 일을 "시작하는" 곳이라면, Sessions는 돌아가는 일을 "지켜보는" 곳입니다. 채팅, 에이전트, 팀, 터미널 세션이 카드 한 장씩으로 표시되고, 실제 상태에 따라 Running, Needs you, Paused, Idle, Done, Failed 열에 자동으로 정리됩니다.

같은 팀 작업을 반복해서 돌려야 한다면 Loop를 씁니다. 명단, 트리거, 실행 한도를 묶고, 라운드마다 어떤 기준을 통과했는지 기록합니다. 중간 결과에 따라 진행 경로가 바뀌는 일은 Graph가 맡습니다. 리더와의 대화는 Maestro 채팅이라서 이어서 Maestro 작업으로 넘어갈 수 있습니다. 세션의 Enable sync를 켜면 프로젝트 메시지 채널과 연결되어, 사람과 에이전트가 한곳에서 대화합니다. 자세한 내용은 에이전트 기능 페이지와 에이전트 세션 소개에서 볼 수 있습니다.

자주 묻는 질문

단일 에이전트와 팀은 어떻게 구분해서 쓰나요?
규칙이 정해진 한 가지 작업(회의록 정리, 정해진 말투로 답장 초안 쓰기 등)은 단일 에이전트로 충분합니다. 단계마다 필요한 도구가 다르거나, 결과를 별도의 리뷰어가 확인해야 하는 일이라면 팀이 맞습니다.

세션을 시작한 뒤에 멤버를 바꿀 수 있나요?
없습니다. New team session 창에도 팀은 세션이 끝날 때까지 고정된다고 적혀 있습니다. 멤버 추가·삭제와 리더 지정은 Create를 누르기 전에 하고, 다른 구성으로 돌리고 싶다면 새 세션을 만듭니다.

클라우드로 데이터가 넘어가나요?
실행 방식은 Local과 Isolated 중에서 고릅니다. 화면 설명대로 둘 다 내 컴퓨터에서 내 키로 실행되며, 클라우드로는 아무것도 보내지 않습니다. 채팅 기록도 기본값은 이 기기에만 저장됩니다.

에이전트가 자기 지시문을 고쳐 쓰기도 하나요?
변경은 Proposals에 제안으로만 올라오고, 제안은 승인된 설정이 아닙니다. 에이전트가 자기 프롬프트를 수정해도 되는지는 별도 설정으로 정합니다.

데스크톱 앱은 osfoundry.io/ko/download에서 받을 수 있습니다.

osFoundry란? 채팅부터 로컬 모델까지, 데스크톱 AI 워크스페이스 전체 정리

tauchiii — Fri, 06 Nov 2026 12:23:47 +0000

오후 2시, 스프린트 회의가 끝나고 자리로 돌아오면 늘 같은 장면이 펼쳐집니다. 질문용 AI 챗봇 탭, 그 답을 다시 확인하려고 연 다른 챗봇 탭, 코딩 에이전트가 붙은 에디터, 그리고 지난주 자료를 모아 둔 메모 앱. 각자 일의 한 조각만 알고 있어서, 같은 배경 설명을 창마다 다시 붙여 넣게 됩니다. 실무에서 AI를 꽤 쓰는 분이라면 이 피로감이 익숙하실 겁니다.

osFoundry는 어떤 도구인가

osFoundry는 AI로 하는 일을 한곳에 모은 데스크톱 AI 워크스페이스입니다. AI 모델과의 채팅, 에이전트와 에이전트 팀에 맡기는 작업, 노트와 검색 가능한 지식, 내 컴퓨터에서 돌리는 오픈 모델, 팀이 쓰는 작은 앱 만들기까지 하나의 앱 안에서 처리합니다. 모델은 내 컴퓨터, 내 API 키로 연결한 클라우드 프로바이더, 대여한 클라우드 GPU 중에서 골라 쓸 수 있습니다.

앱은 카테고리로 나뉘고, 카테고리마다 여러 화면이 들어 있습니다. 한눈에 보면 이렇습니다.

카테고리	하는 일	대표 화면
Chat	모델과 대화	Maestro, Multi chat, Branchspace
Workstation	에이전트에게 긴 작업 맡기기	Code, Agent, Agent team, Loop, Terminal
Knowledge	글쓰기, AI가 기억하는 내용 관리	Paper, Note, Memory
Local Model	오픈 모델 찾기, 설치, 테스트	Explore, Playground
Custom App	팀용 사내 도구	Room
Discover	웹 리서치와 뉴스	Browser, News

굳이 비유하자면 VS Code 왼쪽의 액티비티 바와 비슷합니다. 아이콘마다 다른 도구가 열리는데, osFoundry에서는 그 도구들이 전부 AI용이고 같은 프로젝트, 같은 메모리, 같은 모델을 공유한다는 점이 다릅니다.

화면 하나로 구조 익히기

대부분 Chat 카테고리에서 시작하기 때문에, 여기서 화면 읽는 법을 익혀 두면 다른 화면도 금방 익숙해집니다. 아래는 Multi chat의 Council 모드입니다. 같은 질문을 세 모델에 보내고, 서로의 답변을 채점하게 한 모습입니다(예시 데이터).

상단 탭(Maestro, Model chat, Multi chat, Research, Wiki, Code): Chat 영역의 화면을 전환합니다. 도구까지 쓰는 Maestro, 출처를 달아 답하는 단순한 Model chat, 여러 모델을 나란히 쓰는 Multi chat, 심층 조사용 Research, 코드에서 문서를 만드는 Wiki, 코딩 에이전트용 Code입니다.
Compare / Council 전환: Compare는 답변을 나란히 놓고 직접 비교하는 모드, Council은 모델끼리 이름을 가린 채 서로 채점한 뒤 종합 답변을 쓰는 모드입니다.
답변 열: 한 열이 한 모델이고 프로바이더 태그가 붙습니다. 예시에서는 anthropic, ollama(로컬 실행), openai입니다. 클라우드 모델과 로컬 모델을 한 화면에서 섞어 쓸 수 있습니다.
오른쪽 패널: Answers → Ranking → Synthesis 단계와 Peer review 점수표가 보입니다. 최종 답만이 아니라 누가 어떻게 평가했는지까지 확인할 수 있습니다.
Run 버튼: 실행 전에 모델 호출이 몇 번 일어나는지 보여 줍니다(여기서는 7회). Peer ranking을 끄면 횟수가 줄어듭니다.

왼쪽에 목록, 가운데에 작업, 오른쪽에 "이 결과가 어떻게 나왔는지"를 보여 주는 패널. 이 배치는 다른 화면에서도 자주 나옵니다.

활용 사례 1: 1인 개발자의 첫 주

작은 쇼핑몰을 혼자 운영하는 개발자를 떠올려 보겠습니다. 코드베이스를 이해하는 AI가 필요하고, 가능하면 일부 작업은 노트북 안에서 끝내고 싶어 합니다.

월요일에는 Local Model의 Explore를 엽니다. 이 화면은 먼저 컴퓨터 메모리를 읽고(예시에서는 16GB), 오픈 모델마다 Fits, Tight, Too big 배지를 붙입니다. 초록색 Fits 모델을 설치한 뒤 Playground에서 몇 가지 질문을 던져 봅니다. Playground는 같은 프롬프트를 두 모델에 동시에 보내고, 답변이 시작되기까지 걸린 시간도 함께 보여 줍니다.

화요일에는 가격 포맷 함수를 고쳐야 하는데, 어디서 호출되는지 확신이 없습니다. IDE에서 프로젝트를 열고 함수를 우클릭한 뒤 Show Code Graph를 선택합니다.

호출하는 곳이 전부 나열되고, 코드에서 직접 읽어 낸 연결과 이름으로 추정한 연결이 구분되어 표시됩니다. Impact of change에는 영향을 받을 수 있는 심볼, 파일, 테스트 수가 정리됩니다. 행을 클릭하면 해당 위치로 바로 이동하고, Send to chat으로 이 그래프를 Maestro와의 대화에 넘길 수 있습니다.

목요일쯤에는 작은 작업을 코딩 에이전트에게 맡기기 시작합니다. ADE 화면에서는 작업마다 별도의 worktree가 생기고, Changes 탭에서 diff를 확인합니다. 마음에 걸리는 줄 옆(거터)을 클릭해 노트를 남기고, 모아 둔 노트를 한 번에 에이전트에게 보냅니다. 한 주가 끝나면 가벼운 질문용 로컬 모델과, 리팩터링 전에 영향 범위부터 보는 습관이 남습니다.

활용 사례 2: 작은 팀 리드의 첫 주

네 명의 팀원과 2주 단위로 릴리스하는 팀 리드에게 어려운 건 코드보다 "사람이든 AI든 누가 지금 뭘 하고 있는지"를 파악하는 일입니다.

먼저 Message를 엽니다. 채널과 DM은 Slack과 거의 같은 감각으로 쓰는데, AI 에이전트도 채널 멤버가 될 수 있다는 점이 다릅니다. #release에서 에이전트를 @멘션하면 답변과 실행 결과가 그 채널로 돌아오기 때문에 모두가 같은 내용을 봅니다.

다음으로 Workstation에서 Agent team을 구성합니다. 리더 에이전트가 전문 멤버들에게 일을 나눠 주고, Team mail, Handoffs, Sub-agents, Proposals가 각각 다른 탭에 남기 때문에 누가 누구에게 무엇을 넘겼는지 나중에 추적할 수 있습니다. 릴리스마다 반복하는 점검이 있다면 이 팀을 Loop로 만듭니다. Loop는 트리거(예: 평일 아침), 라운드와 재시도 상한, 성공 기준을 묶은 것으로, 기준을 통과할 때까지 라운드를 돌리고 라운드마다 어떤 기준이 통과됐는지 기록합니다.

여러 에이전트가 같은 저장소를 건드릴 때는 Code를 씁니다. 에이전트마다 브랜치와 worktree가 따로 생기고, 자동으로 머지되는 일은 없습니다. 끝난 실행 두 개를 고르고 Preview combined merge를 누르면, main에 넣기 전에 어떤 파일이 충돌하는지 알 수 있습니다.

줄 단위 리뷰는 사례 1과 같은 노트 기능을 씁니다. 노트에는 파일, 줄 번호, 코드 자체가 함께 묶여 에이전트에게 전달됩니다. 일주일 뒤에는 에이전트 작업이 보이는 채널, 알아서 돌아가는 릴리스 점검, 그리고 머지 후가 아니라 머지 전에 하는 리뷰 흐름이 자리 잡습니다.

활용 사례 3: 리서처와 작가의 첫 주

근무 제도에 관한 긴 보고서를 쓰는 사람에게 필요한 건 확인 가능한 출처입니다. AI가 자신 있게 틀리는 걸 여러 번 겪었기 때문에, 모델 하나의 답만으로는 불안합니다.

모델 하나로는 부족한 질문에는 앞에서 본 Multi chat의 Council 모드를 씁니다. 다른 두 모델이 낮은 점수를 준 답이 있으면, 그 부분을 더 파고들면 됩니다.

더 큰 질문은 Agents를 열고 New session을 누른 뒤, 준비된 Deep Research Team을 고릅니다. 리더가 질문을 여러 부분으로 나눠 Data Researcher, Search Specialist 같은 멤버에게 배정합니다.

각 단계는 사용자에게 전달되기 전에 별도의 검토 역할이 확인하고, 출처 없는 수치는 반려되어 다시 실행됩니다. 최종 답은 행마다 출처가 달린 표와 함께, 출처끼리 엇갈리는 부분과 다루지 못한 부분을 짧게 정리해서 돌려줍니다(이미지는 예시).

글쓰기는 Knowledge에서 진행합니다. Paper에서는 초안의 한 문장을 하이라이트하고 거기에 생각을 정리하는 공간을 붙인 뒤, Academic search, Browser, 그 문단만 다루는 Maestro 세션 같은 탭을 열 수 있습니다. 자료와 코멘트는 Note에 모아 둡니다. Discover에서는 Browser에 검색을 저장하고 News에서 키워드 채널을 구독할 수 있어서, 이번 보고서를 위해 읽은 자료가 다음 보고서에서도 그대로 남아 있습니다.

다른 기능과 어떻게 이어지나

카테고리는 따로 노는 제품이 아니라 서로 일을 넘겨주는 관계입니다. 바닥에 깔린 건 Local Model입니다. Explore에서 설치한 모델은 Maestro, Multi chat, 에이전트 세션의 모델 선택 목록에 그대로 나타납니다.

Knowledge는 Chat에 맥락을 공급합니다. Memory에서는 Maestro가 내 업무에 대해 무엇을 알고 있는지 확인할 수 있고, Indexed Folders에서는 에이전트가 검색할 폴더를 직접 고릅니다. Agent, Agent team, Loop의 결과는 Message 채널로 들어옵니다. Workstation이라는 이름의 화면에서는 채널, 노트, 파일, 에이전트 세션을 한 레이아웃에 나란히 열어 둘 수 있습니다. 에이전트와 만든 결과물을 팀 도구로 쓰고 싶어지면 Custom App으로 넘어갑니다. Room에는 팀의 앱과 그 Room 전용 Maestro 채팅이 함께 놓입니다. API 키와 프로바이더 설정은 Configuration에 모여 있습니다. 전체 화면 목록은 플랫폼 페이지에서 볼 수 있습니다.

자주 묻는 질문

기능을 전부 써야 하나요?
아닙니다. 보통 Chat의 Maestro나 Local Model의 Explore부터 시작하고, 필요할 때 다른 영역을 하나씩 추가합니다. 카테고리끼리 프로젝트와 메모리를 공유하기 때문에 처음에 해 둔 작업을 다시 할 필요가 없습니다.

데이터가 컴퓨터 밖으로 나가나요?
로컬 모델을 쓰면 기기 안에서 실행되므로 밖으로 나가지 않습니다. 내 API 키로 연결한 클라우드 모델에는 보낸 내용이 전달되고, 그 사용료는 해당 프로바이더가 청구합니다. 자세한 내용은 로컬 우선 페이지에 정리되어 있습니다.

개발자 전용 도구인가요?
Code, IDE, Terminal은 개발자용이지만 Message, Paper, Note, Research, Multi chat, Discover는 글을 쓰거나 조사하거나 팀을 이끄는 사람도 쓸 수 있도록 만들어져 있습니다.

비용이 드나요?
데스크톱 앱은 무료로 다운로드할 수 있고, 로컬 모델 실행에는 osFoundry 사용료가 붙지 않습니다. 다운로드 페이지에서 받을 수 있습니다.