이번 거래가 다루는 범위와 발표에서 명확히 밝히지 않은 부분
우선 무엇이 인수되었는지부터 살펴보겠습니다. 보도 자료에 명시된 자산은 Cosmos, Auggie CLI, Code Context Engine 및 관련 기술입니다. Cosmos의 향후 역할은 명확하게 명시되어 있습니다: "Cosmos는 Harness Cosmos Software Factory Agent가 되어, 아이디어부터 코드에 이르기까지 엔지니어링 작업을 자동화하는 명확한 역할을 수행할 것입니다." 또한 보도 자료에서는 "Harness Cosmos를 이제 사용할 수 있습니다"라고 밝히고 있습니다.
보도 자료 중 두 구절이 context에 대해 언급하고 있습니다. 첫 번째는 인덱스에 관한 것입니다: "Augment의 Code Context Engine은 코드베이스의 실시간 맵을 유지하므로, 변경 사항이 기존 코드에 자연스럽게 녹아듭니다." 두 번째는 memory에 관한 것입니다: "공유 memory는 각 리뷰에서 얻은 교훈을 다음 변경 사항으로 전달합니다." 두 가지 모두 Harness Cosmos가 앞으로 제공할 기능의 일부로 설명되어 있습니다.
Harness 자체의 블로그 게시물에는 기존 사용자를 겨냥한 문구가 추가되었습니다: "고객은 Harness Cosmos Software Factory Agent를 도입하거나, 선호하는 코딩 도구를 계속 사용하거나, 둘 다 사용할 수 있습니다." 또한 제품과 팀에 대해 "우리는 제품, 기술, 그리고 이를 만든 사람들에게 투자하고 있습니다"라고 언급했습니다.
발표 내용과 FAQ에서 설명하지 않는 것은 기존 계정에 대한 구체적인 운영 방식입니다. 현재의 워크스페이스, 인덱스 및 Expert memory가 어떻게 이동하는지, 결제나 데이터 처리 방식에 변화가 있는지, 또는 보도 자료에서 인수 자산으로 명명되지 않은 VS Code 및 JetBrains용 Augment 확장 프로그램은 어떻게 되는지 등입니다. 이것이 그 자체로 문제가 있다는 신호는 아닙니다. 공개된 자료는 방향성에 관한 것이며, 기존 고객을 위한 운영상의 세부 정보는 Harness와 Augment로부터 직접 제공될 것임을 의미합니다.
이러한 공백이 바로 지금 인벤토리(자산 조사)를 수행해야 하는 이유입니다. 어떤 context가 설계상 이식 가능한지 알기 위해 이메일을 기다릴 필요가 없습니다.
리포지토리에 저장되는 Context
Augment의 문서에는 규칙과 워크스페이스 가이드라인이 저장되는 위치가 명확히 나와 있습니다: "Workspace Guidelines 및 Rules는 리포지토리에 직접 저장됩니다." CLI 문서에서도 워크스페이스 규칙에 대해 동일하게 설명합니다: "Workspace rules는 프로젝트 리포지토리에 저장되며 해당 특정 프로젝트에만 적용됩니다."
Augment는 도구 중립적인 파일도 읽습니다. 규칙 계층 구조에는 .augment/rules/와 함께 CLAUDE.md 및 AGENTS.md가 포함되며, 작업 중에 하위 디렉터리에서 AGENTS.md 및 CLAUDE.md를 찾아냅니다. 팀이 이 파일들에 작성한 모든 내용은 버전 관리되고, 검토 가능하며, 다른 에이전트도 읽을 수 있습니다. 이는 특정 벤더 계정이 아닌 귀하의 리포지토리에 속합니다.
로컬 컴퓨터에 저장되는 Context
개인 설정은 귀하와 더 가까운 곳에 위치합니다. "User Guidelines는 IDE에 로컬로 저장되며 해당 IDE의 모든 향후 채팅에 적용됩니다." VS Code의 경우, Augment는 파일 이름을 다음과 같이 명시합니다: "Visual Studio Code에서 사용자별 가이드라인 파일은 ~/.augment/user-guidelines.md입니다." CLI의 경우, "User rules는 홈 디렉터리에 저장되며 모든 프로젝트에 적용됩니다."
이것들은 홈 디렉터리에 있는 일반 파일입니다. 아무도 커밋하지 않기 때문에 잊어버리기 쉽지만, 가장 문자 그대로 귀하의 소유입니다.
Augment 플랫폼에 저장되는 Context
나머지는 서비스에 의해 보관됩니다. 인덱싱이 가장 명확한 예입니다: "Augment가 활성화된 워크스페이스를 열면 코드베이스가 Augment의 보안 클라우드로 자동 업로드됩니다." 원격 Context Engine도 동일하게 작동합니다: "HTTP를 통해 Augment가 호스팅하는 Context Engine에 연결"하면 선택한 리포지토리의 기본 브랜치를 인덱싱합니다.
Cosmos Expert memory 역시 플랫폼 측에 있습니다. "Memory를 통해 Expert는 세션 전반에 걸쳐 유용한 context를 유지할 수 있습니다. 이는 공유 가상 파일 시스템(VFS)에 범위가 지정된 지식을 저장합니다." 문서에는 "Expert의 memory는 해당 팀에 속하며 워크플로우에 적합한 범위로 분리됩니다"와 "Expert는 자체 VFS 디렉터리 아래에 읽기 쉬운 Markdown 형식으로 정보를 작성합니다"라고 덧붙여져 있습니다.
인덱스는 코드를 통해 다시 빌드할 수 있습니다. 하지만 Expert memory는 다릅니다. 이는 수개월간의 리뷰 댓글, 수정 사항 및 결정의 잔재가 짧은 노트로 정제된 것입니다. 이것이 바로 귀하가 제어할 수 있는 형태로 가장 확보해야 할 부분입니다.
사람들이 대신 시도하는 잘못된 방법들
아무것도 변하지 않을 것이라 가정하기. 당분간은 사실일 수 있습니다. 하지만 "일부 자산"이 매각되었고, 공개된 자료는 각 기존 워크스페이스의 마이그레이션 경로가 아니라 Cosmos의 미래를 다루고 있습니다. 연속성을 가정하기보다는 확인해야 할 사항으로 취급하십시오.
모든 것을 잃을 것이라 가정하기. 이 역시 틀렸습니다. 규칙, 워크스페이스 가이드라인 및 AGENTS.md 파일은 리포지토리에 있습니다. 사용자 가이드라인과 사용자 규칙은 로컬 컴퓨터의 파일입니다. Augment의 동작을 결정하는 context의 상당 부분은 처음부터 플랫폼에 있지 않았습니다.
인덱스 내보내기 시도하기. 인덱스는 코드에서 빌드된 파생 결과물입니다. 복사본을 가질 필요가 없습니다. 리포지토리를 인덱싱하는 모든 도구는 자체적으로 인덱스를 빌드합니다.
아무것도 하지 않고 마이그레이션 안내를 기다리기. 아래의 인벤토리 작업은 반나절이면 충분하며, Harness가 다음에 무엇을 발표하든(Cosmos를 새 이름으로 계속 사용하는 경우를 포함하여) 유용합니다.
모든 것을 하나의 벤더 규칙 형식으로 마이그레이션하기. 나중에 다른 도구를 평가할 때 .augment/rules/는 변환이 필요합니다. Augment Code에서 Cursor로 마이그레이션하기에 대한 노트에서 자세히 설명하듯이, 도구 중립적인 파일이 더 범용적으로 쓰입니다.
해결책: Augment Context를 저장 위치별로 분류하고 이식 가능한 레이어 완성하기
1단계: 팀의 Augment context가 있는 모든 위치 조사하기
리포지토리별, 개인별로 간단한 목록을 만드십시오.
각 리포지토리에서 하위 디렉터리의 중첩된 복사본을 포함하여 .augment/rules/, .augment-guidelines, AGENTS.md 및 CLAUDE.md가 있는지 확인하십시오. Augment의 frontmatter가 워크스페이스 규칙의 적용 시점을 제어하므로, 어떤 규칙이 항상 적용되고 어떤 규칙이 조건부로 적용되는지 기록해 두십시오.
각 개발자의 컴퓨터에서 ~/.augment/rules/를 확인하고, VS Code 사용자의 경우 ~/.augment/user-guidelines.md를 확인하십시오. JetBrains 사용자는 IDE 설정을 확인해야 합니다. Augment는 "VSCode에서 정의된 가이드라인은 JetBrains IDE로 전파되지 않으며 그 반대도 마찬가지입니다"라고 명시하고 있기 때문입니다.
플랫폼 측면에서는 Cosmos Expert 목록, memory가 활성화된 Expert, 각 Expert가 사용하는 범위를 나열하십시오. Augment의 문서에 따르면 "모든 템플릿 Expert에 대해 Memory가 활성화되어 있습니다"라고 하므로, 템플릿을 사용하는 경우 memory가 누적되고 있다고 가정해야 합니다. 이 memory를 의도적으로 튜닝해 왔다면, Augment Cosmos Expert가 피드백을 통해 학습하는 내용 제어하기에서 설명하는 설정들을 기록해 두어야 합니다.
마지막으로, 어떤 리포지토리가 원격 Context Engine에 연결되어 있는지, 어떤 컴퓨터가 Auggie CLI를 통해 로컬 서버를 실행하는지 기록해 두십시오.
2단계: Expert가 학습한 내용을 읽기 쉬울 때 기록해 두기
Expert memory는 Markdown으로 저장되며, 대화형 세션에서 Expert는 "무언가를 기억할 때 이를 알려주어 사용자가 수정하거나 거부할 수 있도록 합니다." 덕분에 검토가 가능합니다. 각 Expert 및 리포지토리 범위에 대해 기억된 지침을 읽어보십시오.
그런 다음 이를 분류하십시오. 일부는 명명 규칙, 리뷰 표준, 테스트 실행 없이는 절대 업그레이드해서는 안 되는 종속성, 특정 테이블을 소유하는 서비스 등 지속적인 팀 지식일 것입니다. 일부는 노이즈이거나 이미 오래된 정보일 것입니다.
지속적인 항목들은 귀하의 언어로 리포지토리에 옮기십시오. 짧은 AGENTS.md 섹션이나 워크스페이스 규칙이면 충분합니다. Augment의 자체 가이드라인도 이러한 구분을 지지합니다: "명시적인 워크플로우에는 skill이나 Expert 지침을 사용하고, 지속적인 작업을 통해 학습된 context에는 memory를 사용하십시오." 학습된 교훈이 입증되면, 코드가 있는 곳에 명시적인 지침으로 남겨둘 가치가 있습니다.
개인 context에 대해서도 동일하게 수행하십시오. 개발자의 user guidelines에 개인적 선호도가 아닌 팀 규칙이 포함되어 있다면, 해당 규칙을 리포지토리로 이동하여 그 사람이나 노트북이 떠나더라도 유실되지 않도록 하십시오. 이러한 인수인계의 일반적인 버전은 팀원이 퇴사할 때 팀의 AI context 유지하기에서 다룹니다.
3단계: 규칙 레이어를 여러 도구에서 읽을 수 있도록 유지하기
Augment는 AGENTS.md 및 CLAUDE.md를 계층적으로 읽으므로 편리합니다. 공유 규칙을 이 파일들에 넣어두면 Augment에서 계속 작동하면서 다른 에이전트도 읽을 수 있습니다. .augment/rules/는 frontmatter를 통한 조건부 적용과 같이 진정으로 Augment 기능에 의존하는 항목에만 사용하십시오.
파일들이 실제로 읽히고 있는지 확인하십시오. Augment 문서에는 놓치기 쉬운 범위 지정 세부 사항이 언급되어 있습니다: ".augment/rules/에 있는 파일은 워크스페이스 루트에서만 로드되며 하위 디렉터리에서는 로드되지 않습니다." 중첩된 context는 대신 중첩된 AGENTS.md 파일에 넣어야 합니다. 더 광범위하게는, AI 에이전트가 작성된 지침 파일을 무시하는 이유에서 팀들이 자주 겪는 로딩 규칙을 살펴봅니다.
귀하의 팀이 Claude Code에서 Augment로 전환한 경우, Claude Code에서 Augment Code로 마이그레이션하기의 역매핑은 유용한 체크리스트가 됩니다. 들어올 때 변환했던 항목들이 바로 나갈 때 변환해야 할 항목들입니다.
MemoryLake에서 설정하기
2단계와 3단계는 팀 지식을 리포지토리로 이동합니다. 하지만 여러 리포지토리에 걸친 결정 사항, 규칙 뒤에 숨겨진 이유, 한 프로젝트에서 얻어 다음 프로젝트에 적용할 교훈, 모든 도구에서 사용하고 싶은 개인 작업 선호도 등 리포지토리에 맞지 않는 context도 있습니다. MemoryLake는 이번 분기에 어떤 벤더가 귀하의 코딩 에이전트를 소유하든 상관없이 해당 레이어를 독립적으로 유지할 수 있는 공간입니다.
귀하는 자신의 언어로 항목을 직접 작성합니다. Augment, Harness, 귀하의 리포지토리 또는 다른 벤더의 저장소에서 데이터를 읽거나 쓰거나 삭제하지 않습니다. 회사의 코드나 결정 사항에 관한 내용을 추가하기 전에 조직의 정책을 확인하십시오.
1단계: API 키 생성
로그인하고 대시보드에서 키를 생성합니다. 이 키는 Augment나 Harness 계정과는 별개로 귀하의 MemoryLake 워크스페이스에 속합니다.
2단계: 첫 번째 memory 업로드
2단계에서 Expert memory에서 분류한 여러 리포지토리에 걸친 교훈과 특정 코드베이스에 국한되지 않는 개인 선호도부터 시작하십시오. 항목당 하나의 결정 또는 선호도를 날짜와 함께 작성합니다.
3단계: AI 및 에이전트 연결
사용 중인 코딩 에이전트와 어시스턴트를 연결합니다. 이렇게 하면 Cosmos에 머물든, 다른 에이전트를 추가하든, 전환하든 동일한 context를 사용할 수 있습니다.
실제 업무에서 달라지는 점
첫 번째 차이점은 명확한 그림을 얻게 된다는 것입니다. 모든 것을 구분되지 않은 하나의 Augment context 더미로 취급하는 대신, 어떤 부분이 Git에 있고, 어떤 부분이 노트북에 있으며, 어떤 부분이 플랫폼에 있는지 알게 됩니다.
두 번째는 플랫폼에 보관되는 부분이 원래 있어야 할 크기로 줄어든다는 점입니다. 인덱스는 코드에서 다시 빌드됩니다. Expert memory는 계속 제 역할을 수행하지만, 가장 중요한 교훈은 리포지토리에 검토된 텍스트로도 존재하게 됩니다.
세 번째는 선택권(optionality)입니다. Harness Cosmos를 도입하든, 발전하는 Augment 도구를 계속 사용하든, 다른 도구를 평가하든 규칙은 그대로 유지됩니다. context를 이식 가능하게 유지해야 하는 더 넓은 논거는 AI memory는 기능인가 락인(lock-in)인가에서 다루고 있습니다.
네 번째는 앞으로 어떤 변화가 오든 회복 탄력성을 갖추게 된다는 점입니다. 이 분야에서 인수합병, 이름 변경, 요금제 변경은 흔한 일입니다. 자신이 제어하는 파일에 context를 보관하는 팀은 이를 지식 유실 사건이 아닌 단순한 조달(procurement) 문제로 취급합니다.
Harness 인수 이후 Augment 사용 팀을 위한 베스트 프랙티스
행동하기 전에 인벤토리를 조사하십시오. 리포지토리 규칙, 로컬 가이드라인, 플랫폼 보관 context를 별도로 나열하십시오.
지금 Expert memory를 읽어보십시오. Markdown 형식이며 검토 가능합니다. 지속적인 교훈은 리포지토리로 승격시키십시오.
공유 규칙에는 도구 중립적인 파일을 우선 사용하십시오. AGENTS.md 및 CLAUDE.md는 Augment뿐만 아니라 그 외의 도구에서도 작동합니다.
개인 가이드라인에서 팀 규칙을 분리하십시오. 개인 파일은 그 사람이 떠날 때 함께 사라집니다.
인덱스를 보존하려고 애쓰지 마십시오. 인덱스는 귀하가 사용하는 도구에 의해 코드로부터 다시 빌드됩니다.
계정 세부 정보를 직접 확인하십시오. 보도 자료에서 추측하기보다는 Harness나 Augment에 워크스페이스, 데이터 처리 및 확장 프로그램에 대해 직접 문의하십시오.
명확한 기준으로 대안을 비교하십시오. 대안을 검토 중이라면, 엔지니어링 팀을 위한 최고의 코드베이스 memory 도구에서 평가 항목을 확인하십시오.
결론
Harness는 Cosmos, Auggie CLI, Code Context Engine 및 관련 기술과 이를 만든 팀을 인수했습니다. 이번 발표는 코드 context와 배포 context가 연결되는 미래를 설명하며, 기존 고객에게 Harness Cosmos를 도입하거나, 선호하는 도구를 계속 사용하거나, 둘 다 사용할 수 있다고 안내합니다.
아직 명확히 밝혀지지 않은 부분은 기존 워크스페이스, 인덱스 및 Expert memory가 어떻게 이전되는가 하는 점입니다. 하지만 귀하의 context를 보호하기 위해 그 답변을 기다릴 필요는 없습니다. 규칙과 워크스페이스 가이드라인은 이미 리포지토리에 있습니다. 사용자 가이드라인과 사용자 규칙은 로컬 컴퓨터의 파일입니다. 인덱스는 다시 빌드할 수 있습니다. 지금 조치를 취해야 할 부분은 Expert memory입니다. 이를 읽고, 가치 있는 내용을 남겨 귀하의 팀이 소유한 파일에 기록하십시오.
그렇게 하면 이번 인수는 팀이 가진 지식의 유실에 대한 문제가 아니라, 단순히 도구 선택에 관한 질문이 될 것입니다.