development-containers

1 개의 포스트

github

하네스만 있으면 된다 (대부분) (새 탭에서 열림)

AI 생산성의 핵심은 새로운 모델·MCP·프롬프트를 끊임없이 추가하는 데 있지 않고, 에이전트 하네스(harness)를 제대로 이해하고 활용하는 데 있다. 글은 GitHub Copilot의 여러 도구에서 공통으로 사용되는 하네스 중심의 단순한 워크플로를 제안하며, 자율 실행 환경에서 먼저 프로토타입을 만들고 요구사항의 복잡성을 조기에 발견하라고 권한다. 다만 자율성을 높일수록 샌드박스 등 안전한 실행 환경을 함께 마련해야 한다. ## 도구보다 하네스 이해하기 - GitHub Copilot CLI, Copilot 앱, VS Code, Visual Studio, JetBrains 등 다양한 도구가 있지만 핵심 상호작용 방식은 점점 비슷해지고 있다. - 하나의 하네스를 익히면 여러 Copilot 환경에서 같은 방식으로 작업할 수 있다. - 처음 시작한다면 UI 요소가 적고 프롬프트와 에이전트 동작에 집중할 수 있는 Copilot CLI가 적합하다. - 중요한 것은 어떤 도구를 선택했는지가 아니라, 에이전트가 작업을 수행하고 파일·명령·결과를 다루는 방식을 이해하는 것이다. ## 자율 실행과 안전한 환경 - `/allow-all` 또는 “Allow All” 설정을 사용하면 에이전트가 매번 사용자의 승인을 기다리지 않고 명령을 실행할 수 있다. - 모든 작업을 일일이 승인하면 생산성 향상이 줄어들고, 사용자가 승인 요청을 무심코 넘기게 될 위험도 있다. - 에이전트의 자율성은 생산성에 중요하지만, 잘못된 명령 실행이나 데이터 손실 같은 위험이 있다. - 특히 회사의 private 데이터가 있는 로컬 환경에서 YOLO 모드를 사용하는 것은 위험하다. - GitHub Codespaces나 개발 컨테이너처럼 격리된 샌드박스 환경에서 실행하는 것이 안전하다. ## 구현 전에 여러 프로토타입 만들기 - AI를 이용하면 과거에는 별도 프로젝트 단계였던 프로토타이핑을 짧은 프롬프트만으로 수행할 수 있다. - 예를 들어 날짜 선택기라면 다음과 같이 여러 시안을 한 번에 생성할 수 있다. ```text Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare. ``` - 여러 레이아웃을 비교하면 연·월·일을 단계적으로 확대하는 방식처럼 처음에는 생각하지 못했던 상호작용을 발견할 수 있다. - 이미지, 도형, 레이아웃 같은 시각적 결과물은 복잡한 요구사항을 긴 텍스트보다 빠르게 이해하게 해준다. - 시각적 프로토타이핑은 UI뿐 아니라 API 설계에도 적용할 수 있다. - 예를 들어 분석 데이터 다운로드 API에 대해 여러 구현 방식을 Mermaid 다이어그램으로 비교하면 요구사항과 제약을 조기에 파악할 수 있다. - 프로토타입은 에이전트 작업의 숨은 복잡성을 드러내며, 구현 후 재작업에 드는 시간과 토큰을 줄여준다. ## 모델과 대화 흐름 유지 - 대부분의 작업에는 중간 크기의 모델과 중간 수준의 reasoning을 사용하는 것이 적절하다고 제안한다. - 하나의 기능·버그·개선 작업을 진행하는 동안 모델과 reasoning 수준을 가급적 바꾸지 않는 것이 좋다. - 같은 모델과 설정을 유지하면 이전 대화가 캐시되어 후속 요청의 토큰 비용을 줄일 수 있다. - 모델을 자주 바꾸기보다 일관된 컨텍스트를 유지하는 것이 작업 효율에 유리하다. ## 실용적인 적용 순서 - Copilot CLI 등 하네스에 가까운 도구로 에이전트의 기본 동작을 익힌다. - 실제 로컬 시스템 대신 Codespaces나 개발 컨테이너에서 자율 실행을 활성화한다. - 구현 전에 HTML 목업, 다이어그램 등 여러 프로토타입을 생성한다. - 선택한 모델과 reasoning 설정을 작업 끝까지 유지한다. - 프로토타입으로 요구사항을 구체화한 뒤 계획과 구현 단계로 넘어간다. 어진 글의 본문은 “계획 수립” 섹션 초입에서 끝나므로, 이후 계획·구현 단계의 구체적인 내용은 제공된 자료만으로 확인할 수 없다.