금요일 저녁, 개인 개발용 EC 사이트를 만들면서 AI 에이전트에게 세 가지 작업을 동시에 맡겼습니다. 반올림 수정, 할인 코드 추가, 가격 표시 테스트 추가입니다. 모두 "완료했습니다"라는 응답을 받았지만, 이대로 main 브랜치에 넣어도 괜찮은지 확신할 수 없습니다. 같은 함수를 두 개의 에이전트가 덮어쓰지는 않았는지, 세 가지를 합쳐도 테스트가 통과하는지 말이죠. osFoundry의 Code는 바로 이런 타이밍을 위한 화면입니다.
osFoundry는 채팅, 에이전트, 파일, 각종 도구들을 하나의 창에 모아 놓은 데스크톱 애플리케이션입니다. 코드와 관련된 부분에는 역할이 다른 세 가지 화면이 있습니다.
- Code: 여러 AI 에이전트에게 같은 리포지토리에서 병렬로 작업을 맡기는 화면입니다. 실행할 때마다 전용 Git 브랜치와 작업 폴더(worktree)가 준비되며, 차이점 확인, 테스트, 통합 머지(merge) 미리 보기를 거친 후에 직접 머지를 할지 결정합니다. 임의로 머지되는 일은 없습니다.
- IDE: 로컬 폴더를 열어 사용자가 직접 코드를 작성하는 에디터입니다. 탐색기(Explorer), 소스 관리(Source Control), 터미널, 문제(Problems), 테스트 패널에 더해, 열려 있는 파일을 기반으로 답변을 제공하는 어시스턴트가 오른쪽에 배치되어 있습니다.
- Wiki: 현재 작업 중인 리포지토리를 읽어 들여 출처를 명시한 문서 페이지를 작성하는 기능입니다. 출처 코드가 변경되면 해당 페이지에 표시가 됩니다.
Code와 Wiki는 Maestro, Model chat, Multi chat, Research와 같은 탭 배열에 있으며, IDE는 사이드바에 독립적인 항목으로 존재합니다. 비유하자면, IDE는 "Git 패널이 붙은 VS Code"와 같고, Code는 "작성자가 모두 AI 에이전트인 풀 리퀘스트 목록"과 비슷합니다. 다만 다른 점은 브랜치가 아직 자신의 PC에서 한 발짝도 나가지 않았다는 것입니다.
화면의 주요 부분은 다음과 같습니다(실행 내용은 예시입니다).
- 레일 상단 바: 세 개의 에이전트가 같은 파일에 대해 서로 충돌하는 내용을, 차이점(diff)을 열기 전에 알려줍니다. 여기서는
src/cart.js 입니다. 옆의 "한 번에 검토"를 통해 선택된 실행들을 나란히 확인해 볼 수 있습니다.
- 실행 레일: 작업 이름, 추가 및 삭제된 줄 수, 작업 시간, 브랜치가 한 줄씩 배열됩니다. '검토 대기', '확인 필요', '접힌 이력'처럼 사용자가 무엇을 해야 하는지에 따라 그룹화되어 있습니다.
- 중앙 대화창: 실행을 클릭하면 에이전트에게 무엇을 요청했는지, 작업 중에 어떤 내용을 주고받았는지를 읽어볼 수 있습니다.
- 오른쪽 패널: 변경(Changes), 파일(File), 커밋(Commit), 검토(Review), PR 탭에서 실행별 실제 차이점을 확인할 수 있습니다. 아직 커밋되지 않은 작업 내용이 먼저 나오고, 브랜치에 커밋된 내용이 나중에 나옵니다.
- 오른쪽 하단 머지 영역: 완료된 실행을 선택하면 여기서 테스트와 통합 머지 미리 보기를 할 수 있습니다.
앞서 언급한 개인 개발자의 사례입니다. Code의 "새로운 실행"에서 작업을 한 줄로 작성하고 에이전트를 선택하는 것만으로, 실행마다 전용 브랜치와 폴더가 분리됩니다. 같은 폴더에서 여러 개를 구동하면 작업 트리가 지저분해져서 막히기 쉽지만, 여기서는 처음부터 AI 전용 작업장이 분리되어 있어 자신이 작업 중인 폴더에는 영향을 주지 않습니다.
세 가지 작업을 마친 후 상단 바에 "충돌"이 나타나면, 세 개 모두에 체크하고 "한 번에 검토"를 누릅니다. 머지 영역에는 "충돌 미확인", "테스트 안 함"이라고 표시됩니다. 초록색 OK가 아니라, 솔직하게 "아직 모르겠다"고 말해주는 것이 핵심입니다. 그 아래에서 src/cart.js 에 "충돌(Conflict)" 라벨이 붙고, 브랜치별 변경 부분(hunk)이 나열됩니다. 반올림 수정과 할인 코드가 둘 다 total()을 덮어쓰고 있었다는 것을 여기서 알 수 있습니다.
다음으로, 실행마다 "테스트"를 누릅니다. 테스트는 해당 실행 전용의 worktree 내에서 동작하므로 자신의 체크아웃은 오염되지 않습니다. 초기 설정에서는 "브랜치를 머지하려면 테스트 통과가 필요합니다"라고 되어 있으며, 이는 설정에서 변경할 수 있습니다. 세 가지 모두 통과했습니다. 하지만 하나씩 통과했다고 해서 조합해서 작동하는 것은 아닙니다. 그래서 "통합 머지 미리 보기"를 누르면, 일회용 복사본 안에서 먼저 머지를 시도하며 "2개는 문제없이 머지 가능합니다・1개가 충돌합니다"라는 결과를 반환합니다.
문제가 없는 2개를 머지하는 순간에 비로소 자신의 브랜치가 변경됩니다. 충돌이 발생한 할인 코드의 브랜치는 그대로 남아있기 때문에, 에이전트에게 수정 후 다시 시도하도록 맡길 수 있습니다. 브랜치 단위가 아니라 "각 에이전트의 좋은 점만 취하고 싶다"면, "브랜치에 조합하기"에서 변경 부분을 하나씩 선택하여 새로운 브랜치를 만들 수도 있습니다.
장시간 작업 시 사소하지만 도움이 되는 부분은 앱이 도중에 멈췄을 때의 처리입니다. 실행 상태가 '실행 중'으로 방치되지 않고 '중단'된 것으로 돌아오며, 브랜치는 유지되고 있다고 표시됩니다.
다음은 팀에서 IDE를 사용하는 경우입니다. 사이드바의 'IDE'에서 프로젝트 폴더를 열면, 왼쪽에 탐색기(Explorer)와 소스 관리(Source Control), 중앙에 탭, 아래에 터미널/출력/문제/테스트가 나열되고 오른쪽에 어시스턴트가 배치됩니다. 어시스턴트는 모든 기기에서 사용할 수 있는 동기화 채팅이거나 이 장치에만 남는 로컬 채팅으로 시작할 수 있습니다.
예를 들어, 공통 함수인 formatPrice의 사양을 변경하고 싶다고 가정해 봅시다. 해당 함수를 마우스 오른쪽 버튼으로 클릭하여 '코드 그래프 표시'를 선택하면 호출하는 곳과 호출되는 곳이 목록으로 나타납니다. 채워진 점은 코드에서 직접 읽어온 호출이며, 비어 있는 점은 추론(inference)에 의한 것이므로, 비어 있는 부분은 직접 눈으로 확인하는 것이 안전합니다. '변경 영향도'는 호출하는 곳의 더 상위 호출까지 거슬러 올라가며, 이 표시 예시에서는 '15 심볼・14 파일・3 테스트'라고 나옵니다. 행을 클릭하면 해당 행으로 이동할 수 있고, '채팅에 보내기'를 통해 그래프 전체를 어시스턴트에게 전달할 수 있습니다.
또 다른 사용처는 AI가 변경한 내용을 확인하는 것입니다. 소스 관리에서 변경된 파일을 열면, 마지막으로 AI가 작성한 파일에는 작은 로봇 아이콘이 붙고, 아래 줄에 모델명과 변경 이유가 표시됩니다. '검토(Review)'를 누르면 해당 내용의 직전에 저장된 사본과 비교한 차이점(diff)이 열리므로, 그 변경 사항만 볼 수 있습니다. 표시 예시에서는 타임아웃 시간이 30초에서 3초로 줄어들었습니다. 바로 위의 댓글에는 '큰 사진 업로드에는 20초 이상 걸립니다'라고 적혀 있습니다. 커밋하기 전에 인지할 수 있는지 여부에 따라 이후의 재작업(hand-over) 정도가 크게 달라집니다.
사용자가 저장하지 않은 편집을 하고 있는 파일에 에이전트가 내용을 작성했을 경우, 무조건 어느 쪽을 선택하는 것이 아니라 '내 내용 유지' 또는 '디스크상의 버전 사용' 중 무엇을 원하는지 물어봅니다.
마지막으로, 코드를 수정하기보다 이해하고 싶은 사람들을 위한 위키(Wiki)입니다. 예를 들어 새로 합류한 멤버나 사양에 대한 질문이 잦은 지원 담당자가 모르는 리포지토리 전체 구조를 파악하고 싶을 때 유용합니다. 설계서가 오래된 채 방치되어 구식이 되는 것은 흔히 발생하는 일이지만, 위키는 코드를 출발점으로 페이지를 작성하기 때문에 이 문제에 정면으로 맞설 수 있습니다.
위키에서 '폴더 열기' 또는 '공개 리포지토리 클론'(https://나 git@ URL)을 선택하면 앱이 로컬에서 프로젝트 구조를 읽어옵니다. 프로젝트에 무언가를 작성하기 전에는 반드시 확인 절차가 있으며, 생성할 폴더의 경로가 그대로 표시됩니다. '지금은 안 함'을 선택하면 아무것도 작성되지 않습니다.
동의하면 '페이지 생성'으로 한 번에 하거나, '페이지 만들기'로 주제를 하나 지정하여 작성하게 할 수 있습니다. 설정에서는 1개 페이지에 얼마나 많은 소스를 전달할지(깊이: 빠른/표준/심층)와 어느 정도의 내용을 검증할지(검증: 비활성화/샘플/전체)를 선택할 수 있습니다. '전체'로 설정하면 비용이 약 2배가 됩니다. 페이지 작성 전에 비용이 표시되므로, 먼저 대략적인 예상치를 확인한 후 진행할 수 있습니다.
각 페이지에는 path:line 출처가 붙으며, 클릭하면 IDE에서 해당 행이 열립니다. 한 달 뒤, 레일(rail) 페이지에 '이 페이지가 참조하는 파일이 페이지 생성 후에 변경되었습니다'라는 표시가 있다면, 다시 작성한 후 읽어야 한다는 신호입니다. 간단한 질문이라면, 페이지 옆 채팅창에서 물어볼 수 있습니다. 답변에도 해당 프로젝트의 path:line이 붙으며, '리트라이 정책에 대한 페이지를 써줘'와 같이 일반적인 언어로 페이지를 요청할 수도 있습니다. 페이지 자체는 리포지토리 내의 Markdown 파일이기 때문에, 코드와 동일한 풀 리퀘스트(Pull Request)로 검토가 가능합니다.
세 가지 화면은 서로 이동할 수 있습니다. 위키 출처를 클릭하면 IDE의 해당 행으로 가고, IDE의 '이 폴더의 위키'에서는 위키로 돌아갈 수 있습니다. IDE 어시스턴트와 위키 페이지 옆 채팅은 Maestro를 기반으로 하므로, 다른 Maestro 채팅과 같은 방식으로 질문할 수 있습니다. 코드를 정확한 단어가 아닌 의미로 찾고 싶을 때는 인덱스 화면에서 로컬 검색 인덱스를 만들어 두면, Maestro가 이를 사용하여 검색합니다. Code의 실행 결과를 팀에 공유할 준비가 되면, 'PR 생성'으로 해당 브랜치의 풀 리퀘스트를 열 수 있습니다.
각 화면은 제품 페이지 데모에서 직접 확인해 볼 수 있습니다. Code와 IDE 페이지를 참고해 주세요.
데스크톱 앱이 필요하신가요?
네, Code, IDE, Wiki는 로컬 폴더, Git의 worktree, 셸(shell), 언어 서버를 사용하므로 osFoundry 데스크톱 앱에서 작동합니다.
에이전트가 임의로 자신의 브랜치에 병합(merge)하는 경우가 있나요?
없습니다. 실행은 각각 전용 브랜치와 폴더에서 작동하며, 자신의 브랜치가 바뀌는 것은 병합(merge) 버튼을 누를 때뿐입니다. 초기 설정에서는 테스트에 통과한 브랜치만 병합할 수 있습니다.
Wiki는 Notion 같은 팀용 위키인가요?
아닙니다. 코드 리포지토리에서 파일과 줄 번호 출처가 포함된 문서를 작성하고, 코드가 변경된 페이지에 표시하는 기능입니다. 아키텍처 개요나 온보딩 자료와 같이 코드 기반의 문서용입니다.
충돌(conflict)한 브랜치는 어떻게 되나요?
그대로 남아 있습니다. 문제가 없는 브랜치만 먼저 병합(merge)하고, 충돌된 브랜치는 에이전트가 그 위에서 다시 수행하도록 하거나, "브랜치에 조합하기" 기능을 사용하여 변경된 부분을 선택하여 가져올 수 있습니다.
데스크톱 앱은 osfoundry.io/ja/download에서 무료로 다운로드할 수 있습니다.
