GitHub

88 개의 포스트

github.blog/engineering

태그로 필터

github

GitHub Copilot 앱으로 첫 프롬프트 작성하기 (새 탭에서 열림)

GitHub Copilot 앱에서 첫 프롬프트를 작성할 때 완벽한 문장보다 작업 대상과 원하는 결과를 명확히 전달하는 것이 중요하다. 프로젝트를 연결한 뒤 자연어로 작은 작업부터 요청하고, 결과에 따라 프롬프트·모델·실행 방식을 점진적으로 조정하면 된다. 음성 입력, 모델 선택, 에이전트 및 원격 세션 같은 기능은 필요할 때 활용할 수 있다. ## 작업에 필요한 컨텍스트 연결 - Copilot이 코드를 수정하려면 먼저 작업 대상이 필요하다. - GitHub 저장소나 로컬 컴퓨터의 폴더를 에이전트 세션에 연결할 수 있다. - Copilot은 연결된 프로젝트의 코드와 파일을 살펴보고 요청과 관련된 부분을 찾아 작업한다. - 앱 홈 화면에서 기존 프로젝트를 선택하거나 새 프로젝트·로컬 폴더를 추가한다. ## 자연어로 원하는 작업 설명하기 - 별도의 문법이나 정해진 프롬프트 형식을 배울 필요가 없다. - 원하는 변경 사항을 평범한 문장으로 설명하면 된다. - 예시: `게임 목록에 가장 많이 투자된 순서 정렬 옵션을 추가해줘.` - 첫 요청이 충분하지 않으면 세부 조건을 추가하거나 수정 사항을 다시 요청할 수 있다. - 프롬프트는 한 번에 완성하는 것이 아니라 결과를 보며 반복적으로 다듬는 방식이다. ## 작업에 맞는 AI 모델 선택 - Copilot 앱에서는 작업을 처리할 AI 모델을 직접 선택할 수 있다. - 모델마다 복잡한 추론 능력이나 처리 속도 등 강점이 다르다. - 처음에는 기본 모델을 사용해도 충분하다. - 복잡한 작업이거나 결과가 기대에 미치지 못하면 다른 모델로 전환할 수 있다. - 모델 선택은 매번 사전에 세밀하게 설정해야 하는 항목이 아니라, 필요할 때 활용하는 도구다. ## 음성 입력으로 프롬프트 작성 - 프롬프트는 키보드로만 입력할 필요가 없다. - 내장 음성 입력을 사용하면 문제를 말로 설명하면서 긴 요청을 작성할 수 있다. - 음성은 프롬프트 입력창의 텍스트로 변환된다. - 전송 전에 내용을 검토하고 수정할 수 있어, 생각나는 대로 말한 뒤 정리하는 방식도 가능하다. ## 에이전트와 원격 세션 활용 - 세션 제목 메뉴에서 다른 에이전트를 선택하거나 원격 제어를 활성화할 수 있다. - 에이전트마다 작업 유형에 맞게 설정할 수 있으므로 목적에 맞는 에이전트를 고르면 된다. - 원격 세션을 사용하면 작업을 로컬 컴퓨터에서 시작한 뒤 웹이나 다른 기기에서 이어서 확인할 수 있다. - 노트북을 닫아도 세션의 진행 상황을 잃지 않고 나중에 다시 작업할 수 있다. - 이러한 설정은 첫 프롬프트 전에 반드시 구성할 필요는 없으며, 더 많은 제어가 필요할 때 선택하면 된다. ## 작은 작업부터 반복하기 - 이미 익숙한 프로젝트에서 작은 변경 사항부터 요청하는 것이 좋다. - 처음부터 모든 세부 사항을 예측하거나 완벽한 프롬프트를 작성할 필요는 없다. - 결과를 확인하면서 요청을 구체화하고, 필요하면 모델이나 세션 실행 방식을 바꾼다. - 핵심은 프로젝트를 선택하고 자연어로 작업을 요청해 실제 결과를 확인하는 것이다. 실용적으로는 “프로젝트 연결 → 작은 작업 요청 → 결과 검토 → 프롬프트 보완” 순서로 시작하는 것이 가장 쉽다. Copilot의 모델·음성 입력·원격 세션 기능은 기본 흐름에 익숙해진 뒤 작업 상황에 맞게 추가하면 된다.

github

코더에서 오케스트레이터로: 에이전트가 개발자의 역할을 어떻게 바꾸는가 (새 탭에서 열림)

한 번의 프롬프트로 코드를 만드는 시연과, 코드를 반복적·안전하게 배포하는 시스템을 구축하는 일은 다르다. AI 에이전트 시대의 개발자는 단순히 코드를 작성하는 사람을 넘어, 코드 생성부터 검증·리뷰·배포까지의 흐름을 설계하고 통제하는 ‘오케스트레이터’가 되어야 한다. 에이전트의 유연성과 CI·브랜치 보호·리뷰 같은 결정론적 통제를 결합해야 팀이 신뢰할 수 있는 개발 시스템을 만들 수 있다. ## 일회성 프롬프트에서 반복 가능한 워크플로로 - 한 번의 프롬프트는 빠르게 결과를 만들 수 있지만, 매번 안정적으로 재현되는 산출물을 보장하지는 않는다. - 실제 개발에는 다음 요소가 연결된 워크플로가 필요하다. - 작업을 시작하는 이벤트와 트리거 - 에이전트가 수행할 작업의 범위 - 코드 검증과 보안 검사 - 리뷰 및 승인 절차 - 안전한 병합과 배포를 위한 통제 - 따라서 개발자는 코드뿐 아니라 코드가 제안되고, 검증되고, 리뷰되고, 배포되는 시스템 자체를 설계해야 한다. ## 이벤트 기반 에이전트 흐름 - 익숙한 저장소 이벤트를 에이전트 작업의 시작점으로 활용한다. - 이슈에 특정 라벨 추가 - 예약된 야간 워크플로 실행 - 기타 GitHub 저장소 이벤트 - 이벤트가 GitHub Actions 워크플로를 실행하고, 사전에 범위를 정한 작업을 Copilot 에이전트가 수행한다. - 에이전트가 만든 결과는 풀 리퀘스트에 기록된다. - 이후 자동화된 검증 절차가 결과를 평가한다. - 린트 - 테스트 - 보안 스캔 - 빌드 검증 ## 에이전트의 유연성과 결정론적 통제 - 에이전트는 모호하고 맥락이 많은 작업을 처리하는 데 적합하다. - 반면 다음과 같은 규칙 기반 장치는 예측 가능하고 반복 가능한 품질 신호를 제공한다. - CI 검사 - CODEOWNERS - 필수 리뷰 - 브랜치 보호 규칙 - 브랜치 보호는 검증되지 않은 변경이나 승인되지 않은 병합을 막는다. - 위험도가 높은 변경에는 사람의 판단이 반드시 개입되도록 리뷰 요건을 설정할 수 있다. - 팀이 에이전트를 신뢰하려면 에이전트의 자율성을 무제한으로 허용하기보다, 명확한 결정론적 경계 안에서 운영해야 한다. ## 개발자의 역할 변화 - 개발자는 여전히 코드를 작성하지만, 동시에 다음을 책임진다. - 어떤 이벤트가 에이전트를 실행할지 정의 - 에이전트의 권한과 작업 범위 제한 - 에이전트와 검증·리뷰 단계 사이의 인계 설계 - 사람의 판단이 필요한 지점 결정 - GitHub Copilot은 이러한 자동화와 에이전트 운영을 한곳에서 관리하는 제어 평면 역할을 한다. - Copilot cloud agent 워크플로, GitHub Actions의 Copilot CLI, MCP를 통한 외부 도구·컨텍스트 연동은 같은 성숙 경로에서 선택할 수 있는 구현 방식이다. ## 작은 범위에서 시작하기 - 처음부터 전체 개발 프로세스를 자동화하기보다 범위가 명확하고 위험이 낮은 작업 하나를 선택하는 것이 좋다. - 예시: - 이슈 분류 - 문서와 테스트의 동기화 - 단순 유지보수 변경 - 기존 소프트웨어 개발 인프라에 Copilot을 단계적으로 도입하고, 실제로 필요한 다음 자동화 단계를 확인하며 확장한다. 실용적으로는 에이전트에게 제한된 권한을 부여하고, 모든 변경을 풀 리퀘스트와 자동 검사를 거치게 하는 방식이 적합하다. 즉, AI가 코드를 대신 작성하는 것보다 중요한 것은 사람이 통제 가능한 검증·승인·배포 체계를 설계하는 일이다.

github

Java용 GitHub Copilot SDK 사용하기 (새 탭에서 열림)

Ed Burns는 Microsoft와 GitHub 기술에 자바다운(idiomatic) 개발 경험을 제공하는 Principal Software Engineer입니다. 1997년부터 자바를 사용해 왔으며, 클라이언트·서버·클라우드·AI 등 다양한 영역에서 활동해 왔습니다. ### Ed Burns의 역할 - Microsoft와 GitHub 기술 생태계에 자바 관용적 개발 경험을 도입하는 업무를 담당합니다. - Principal Software Engineer로서 기술 방향과 개발 경험 개선에 기여합니다. ### 자바 경력과 전문 분야 - 1997년부터 자바를 다뤄 온 숙련된 개발자입니다. - 다음과 같은 폭넓은 영역에서 경험을 쌓았습니다. - 클라이언트 애플리케이션 - 서버 애플리케이션 - 클라우드 기술 - 인공지능(AI) ### 실용적인 결론 이 글은 특정 기술이나 방법론을 설명하기보다는 Ed Burns의 경력과 전문성을 소개하는 약력입니다. 자바가 클라이언트부터 AI까지 다양한 기술 영역에서 활용되어 왔다는 점을 보여줍니다.

github

GitHub Copilot 앱의 슬래시 명령어 가이드 (새 탭에서 열림)

GitHub Copilot 앱의 슬래시 명령어는 채팅 입력창에서 `/`로 시작해 세션 관리, 프로젝트 탐색, 작업 모드 전환을 빠르게 수행하도록 돕는다. CLI가 터미널과 디렉터리·작업 경로 관리에 초점을 둔다면, 앱의 명령어는 시각적 인터페이스와 멀티 세션 워크플로에 맞춰 계획 수립, 비판적 검토, 자동 구현 등을 지원한다. 특히 `/plan`으로 작업을 설계하고 `/spar`로 위험을 검토한 뒤 `/autopilot`으로 구현하는 흐름이 핵심이다. ## 슬래시 명령어의 개념과 앱·CLI의 차이 - 채팅 입력창에 `/`를 입력하면 현재 상황에서 사용할 수 있는 명령어 자동완성 메뉴가 표시된다. - CLI 명령어는 터미널 중심으로 설계되어 디렉터리 추가(`/add-dir`), 작업 디렉터리 변경(`/cwd`) 등을 담당한다. - Copilot 앱은 프로젝트 컨텍스트와 파일 접근을 시각적으로 관리하므로 `/add-dir`, `/cwd` 같은 명령어가 필요하지 않다. - 앱에서는 세션 이동, 프로젝트 관리, 에이전트 작업 방식 제어 등 워크플로 중심의 명령어를 제공한다. - `/clear`, `/model`처럼 CLI와 앱에서 공통으로 사용할 수 있는 명령어도 있다. ## `/plan`으로 코딩 전에 작업 설계 `/plan`은 구현에 앞서 작업을 분석하고 단계별 계획을 세우는 명령어다. 실행하면 세션이 **Plan 모드**로 전환되며, 채팅 입력창의 **Mode** 메뉴에서도 같은 모드를 선택할 수 있다. - 새 기능 개발: - 변경이 필요한 파일, 컴포넌트, 의존성을 파악한다. - 예: `/plan`으로 2단계 인증 도입에 필요한 작업과 구현 순서를 정리한다. - 대규모 리팩터링: - 복잡한 코드 변경의 범위와 위험 요소를 확인한다. - 한 번에 전환하지 않고 점진적으로 마이그레이션할 방법을 수립한다. - 버그 조사: - 원인이 불명확한 장애의 가능한 원인을 탐색한다. - 진단 절차와 수정 작업을 단계별로 계획한다. ## `/spar`로 가정과 설계 검증 `/spar`는 Copilot이 반대 의견을 제시하도록 해 설계의 허점, 위험, 트레이드오프를 검토하는 명령어다. - 아키텍처 선택 검증: - Redis 캐시의 무효화 전략, 확장성, 일관성 문제 등을 점검한다. - 구현 방식 비교: - REST와 GraphQL, 동기 처리와 비동기 처리처럼 여러 접근법의 장단점을 비교한다. - 애플리케이션 요구사항에 맞는 선택을 추천하도록 요청할 수 있다. - 마이그레이션 계획 검토: - 데이터베이스나 인프라 이전 과정의 엣지 케이스와 배포 위험을 찾는다. - 무중단 또는 최소 다운타임 조건에서 발생할 문제를 미리 점검한다. - 성능 최적화 비판: - 지연 로딩 등 최적화가 사용자 경험을 해치거나 불필요한 복잡성을 만들 가능성을 확인한다. - 숨은 병목과 부작용, 더 단순한 대안을 함께 검토한다. ## `/autopilot`으로 구현 자동화 `/autopilot`은 계획한 목표를 바탕으로 여러 구현 단계를 Copilot이 직접 수행하도록 하는 명령어다. 실행하면 세션이 **Autopilot 모드**로 전환되며, Mode 메뉴에서도 선택할 수 있다. - 새 기능 구현: - 필요한 파일을 식별하고 코드를 수정한다. - 관련 테스트를 추가하거나 업데이트하도록 요청할 수 있다. - 예: 사용자 보고서를 CSV로 내보내는 기능을 설계부터 구현까지 진행한다. - 대규모 유지보수: - 의존성 업데이트, 리팩터링, 문서 개선처럼 여러 단계가 필요한 작업에 적합하다. - React 버전 업그레이드 시 호환성 문제를 수정하고 테스트 통과 여부까지 확인하도록 할 수 있다. - 사용자는 세부 단계마다 지시하기보다 최종 목표와 제약 조건을 전달하는 방식으로 작업할 수 있다. ## `/rubber-duck`로 문제를 대화형 검토 `/rubber-duck`는 문제를 설명하고 다른 관점에서 검토받는 디버깅 지원 명령어다. - Copilot이 별도의 모델을 사용해 독립적으로 검토하는 방식으로 소개된다. - 혼자 문제를 설명하며 사고를 정리하는 ‘러버 덕 디버깅’ 과정을 Copilot과 수행할 수 있다. - 제공된 글 내용은 이 명령어 설명 중간에서 끝나므로, 구체적인 사용 예와 전체 동작 방식은 확인할 수 없다. 실무에서는 먼저 `/plan`으로 범위와 순서를 정리하고, `/spar`로 설계의 위험을 검증한 다음, 충분히 구체화된 작업을 `/autopilot`에 넘기는 방식이 효과적이다. 자동 구현을 사용하더라도 테스트와 변경 내용을 직접 검토해 결과를 확인하는 것이 좋다.

github

멀웨어 보안 권고를 npm을 넘어 확장한 방법 (새 탭에서 열림)

Ankit은 GitHub에서 Dependabot 팀을 이끄는 시니어 엔지니어링 매니저입니다. Dependabot은 34개 이상의 패키지 생태계에 걸쳐 3천만 개가 넘는 저장소를 감시하며, 소프트웨어 공급망 공격에 대응하는 역할을 합니다. 이러한 광범위한 책임 때문에 Ankit은 공급망 보안 위협에 대해 높은 경계심을 유지하고 있습니다. ### Ankit의 역할 - GitHub의 Supply Chain Security 조직에서 Dependabot 팀을 이끕니다. - 엔지니어링 관리자로서 소프트웨어 의존성 및 공급망 보안과 관련된 업무를 담당합니다. ### Dependabot의 감시 범위 - 3천만 개 이상의 저장소를 모니터링합니다. - 34개 이상의 패키지 생태계를 지원합니다. - 다양한 패키지 관리자와 의존성을 다뤄야 하므로 매우 광범위한 보안 대응이 필요합니다. ### 소프트웨어 공급망 보안 - 패키지와 의존성은 애플리케이션 보안에 직접적인 영향을 줍니다. - 의존성의 취약점이나 악성 패키지는 다수의 저장소에 빠르게 확산될 수 있습니다. - Dependabot의 대규모 감시 범위는 공급망 공격을 조기에 탐지하고 대응하는 데 중요한 역할을 합니다. 이 글의 제공된 내용은 Ankit과 Dependabot의 역할 및 규모를 소개하는 부분에 해당하며, 구체적인 기술적 주장이나 구현 세부사항은 포함되어 있지 않습니다.

github

GitHub 법무팀이 Copilot CLI를 활용해 업무 흐름을 간소화한 방법 (새 탭에서 열림)

GitHub 법무팀은 엔지니어가 아니어도 Copilot CLI를 활용해 반복적인 법무 업무를 자동화하고, 자신의 판단 기준을 반영한 도구를 직접 만들 수 있음을 보여준다. 계약서 작성·검토와 DMCA 통지 분석 같은 업무를 평문 지침, 정책 자료, 템플릿으로 구조화해 일관성과 처리 속도를 높였다. 다만 AI는 법률적 판단을 대체하는 것이 아니라, 사람이 최종 검토하는 의사결정 지원 시스템으로 활용됐다. ## 반복 업무를 AI 도구로 전환한 배경 - 법무팀의 업무에는 유사 계약 검토, 반복적인 법률 질의 응답, 기존 가이드 재활용 등 반복 작업이 많았다. - 구성원들은 전통적인 프로그래밍 경험이 부족했지만, 자신의 업무 방식과 판단 기준은 명확히 알고 있었다. - Copilot CLI에 자연어로 원하는 기능을 설명하고 저장소와 연결하면서, 프롬프트를 일회성으로 사용하는 대신 재사용 가능한 내부 도구로 발전시켰다. - 지침과 자료를 저장소에서 관리해 버전 관리, 일관성 확보, 협업이 가능해졌다. ## `terms-ai`: 계약 작성 스타일 가이드 구축 - Ngandu Kasuku는 데이터·인프라·제품 통합 관련 파트너십 계약이 급증하자 계약 작성 도구 `terms-ai`를 만들었다. - 저장소에 다음 자료를 정리했다. - AI 작업 지침 - 계약 작성 리소스 - 업무 흐름 - 기존에 승인된 계약서 - 평문 중심의 계약 작성 원칙을 내부 스타일 가이드로 만들었다. - 불필요하게 고어체인 법률 용어를 줄임 - 더 명확하고 읽기 쉬운 문장 사용 - 계약 전반에 동일한 문체와 기준 적용 - 기존 파트너와의 과거 계약 및 승인된 문서를 참고해 새 계약서나 부속합의서 초안을 작성할 수 있게 했다. - 민감한 계약서와 내부 정보는 공개 저장소에 포함하지 않고, 접근 제어가 적용된 내부 환경에 보관했다. - 결과적으로 계약 검토와 작성 시간이 약 절반으로 줄었고, 조항의 일관성과 개인의 작성 스타일 반영 수준이 향상됐다. - 핵심은 AI가 단순히 초안을 생성한 것이 아니라, 변호사의 경험과 판단 방식을 도구에 내장했다는 점이다. ## DMCA 통지 분석을 위한 평문 기반 워크플로 - Jesse Geraci는 DMCA 통지를 처리하기 위해 소스 코드를 빠르고 정확하게 분석해야 하는 문제에서 출발했다. - 처음에는 팀원들이 각자 작성하던 일회성 프롬프트를 다음과 같은 반복 가능한 지침으로 정리했다. - DMCA 통지 분류 - 코드 비교 - 라이선스 확인 - 우회 행위 검토 - 분석 결과 보고서 작성 - 전통적인 소스 코드 대신 다음과 같은 평문 파일을 중심으로 워크플로를 구성했다. - 업무 절차 지침 - 정책 및 법률 참고 자료 - 보고서 템플릿 - 변호사가 가진 언어 구성 능력과 법률적 방법론을 구조화된 업무 로직으로 활용했다. - 고객용과 변호사용 분석 모드를 분리했다. - 고객용: 빠른 결과와 에스컬레이션 권고 제공 - 변호사용: 심층 검토와 양측 주장 분석 제공 - 외부 데이터 소스를 연동하면서 팀이 재사용할 수 있는 표준 워크플로로 확장됐다. ## 데스크톱 앱과 재사용 가능한 법무 에이전트 - 초기 평문 워크플로는 이후 사전 정의된 법무 작업을 실행하는 데스크톱 앱으로 발전했다. - 앱 자체를 구축하려면 상당한 코드가 필요했지만, 실제 업무 동작을 바꾸는 지침은 여전히 Markdown과 자연어로 편집할 수 있다. - DMCA 코드 분석을 넘어 다음 업무로 범위가 확대됐다. - 계약서 검토 - NDA 분류 - 위험 평가 - 컴플라이언스 점검 - 답변 초안 작성 - 내부적으로는 다음과 같은 재사용 가능한 스킬과 에이전트로 업무를 나눌 수 있다. - 접수 및 초기 분류 - 플레이북 기준 대조 - 위험 점수 산정 - 증거 검증 - 에스컬레이션 경로 결정 - 보고서 조립 - 기술적 구현이 복잡해져도 법무팀은 읽기 쉬운 Markdown을 통해 AI의 동작과 기준을 직접 통제할 수 있다. ## 인간의 법률 판단을 중심에 둔 AI 활용 - 법무 Copilot은 변호사를 대체하는 시스템이 아니라 구조화된 의사결정 지원 도구다. - AI 활용의 목적은 다음과 같다. - 법률 분석의 일관성 향상 - 판단 과정의 투명성 확보 - 반복 업무의 확장성 강화 - 사람이 중요한 쟁점과 최종 판단에 집중하도록 지원 - 조직은 완벽한 상용 솔루션이나 전문 개발자를 기다리지 않고, 먼저 자신의 방법론·기준·결과 형식을 명확히 정의할 수 있다. 작게는 반복되는 계약 검토나 자료 분류처럼 시간을 가장 많이 빼앗는 업무 하나를 골라, 자연어 지침과 내부 자료를 재사용 가능한 워크플로로 정리하는 것이 현실적인 시작점이다. 단, 민감한 자료에는 접근 제어를 적용하고, AI 결과는 반드시 담당자의 검토와 승인을 거치도록 설계해야 한다.

github

거대한 AI 생성 풀 리퀘스트 하나를 검토 가능한 스택으로 바꾸기 (새 탭에서 열림)

AI 코딩 에이전트는 짧은 시간에 대규모 기능을 구현하지만, 모든 변경을 하나의 거대한 PR에 담는 방식은 리뷰 품질과 병합 속도를 떨어뜨린다. 이 글은 기능을 데이터·API·애플리케이션 연결·UI처럼 논리적 계층으로 나누고, 각 계층을 작은 PR로 쌓는 “스택드 풀 리퀘스트(stacked pull requests)”를 대안으로 제시한다. 이를 통해 에이전트의 생산성은 유지하면서도 각 변경을 독립적으로 검토하고 관리할 수 있다. ## AI가 만든 대규모 PR의 문제 - 쇼핑 어시스턴트에 상품 검색 기능을 추가하면 다음 변경이 한 PR에 함께 들어가기 쉽다. - 새 데이터 모델과 시드 데이터 - API 라우트와 입력 검증 - 클라이언트 연결 - UI 및 빈 상태·오류 상태·대체 상태 - 결과적으로 1,000~1,700줄 이상의 큰 diff가 만들어질 수 있다. - 리뷰어는 변경 내용을 한 번에 이해하기 어렵고, PR 설명이 길지만 구체적이지 않으면 검토를 뒤로 미루게 된다. - 리뷰가 늦어지면서 문맥이 사라지고 피드백 품질이 낮아지며, 충돌과 수동 동기화가 늘어난다. - 결국 기능이 충분히 검토되지 않은 채 병합될 위험이 커진다. ## 스택드 풀 리퀘스트의 기본 원리 - 하나의 대형 PR 대신 기능을 논리적으로 분해해 여러 개의 작은 PR로 만든다. - 각 PR은 하나의 관심사만 다루며, 리뷰어가 한 번에 이해할 수 있는 크기로 제한한다. - PR은 의존성 순서에 따라 연결된다. - 하위 계층이 먼저 구현되고, 상위 계층은 그 변경을 기반으로 작업한다. - 이전 계층에서 얻은 문맥은 다음 계층으로 자연스럽게 이어지므로, 전체 기능을 매번 처음부터 읽을 필요가 없다. - 데이터 담당자, 백엔드 담당자, UI 담당자처럼 변경 영역에 맞는 리뷰어를 배정할 수 있다. ## 상품 검색 기능의 스택 구조 | 계층 | 브랜치 | 작업 내용 | 의존 대상 | |---|---|---|---| | L1 | `feat/catalog-data` | 타입이 지정된 카탈로그, 시드 데이터, 검증, 데이터 접근 모듈 | `main` | | L2 | `feat/search-api` | 검증을 포함한 `/api/products/search` 엔드포인트 | L1 | | L3 | `feat/chat-grounding` | 채팅이 API를 호출하고 실제 상품 데이터에 기반해 응답 | L2 | | L4 | `feat/grounded-ui` | 상품 인용 카드와 UI 상태 처리 | L3 | - 데이터, API, 애플리케이션 연결, UX가 각각 독립된 작업 단위가 된다. - 각 계층은 자체적으로 리뷰할 수 있지만, 전체 기능은 계층 간 의존성을 통해 완성된다. - 가장 기반이 되는 작업을 스택의 아래쪽에 배치하고, 그 위에 이를 사용하는 작업을 쌓는다. ## GitHub 도구와 초기 설정 - GitHub는 PR 화면뿐 아니라 터미널에서도 스택드 PR을 관리할 수 있다. - `gh-stack` CLI 확장 설치: ```bash gh extension install github/gh-stack ``` - 코딩 에이전트가 스택 구조를 이해하고 생성·관리하도록 관련 스킬을 설치할 수 있다. ```bash gh skill install github/gh-stack ``` 또는: ```bash npx skills add github/gh-stack ``` - 스택을 시작하기 전에 스택의 기준 브랜치(stack base)를 정해야 한다. - 일반적으로 `main`이 기준이 된다. - CI 검사와 병합 규칙이 전체 스택에서 이 기준을 바탕으로 평가된다. - 모든 계층에 CI가 존재하는지 확인해야 한다. - 각 PR 계층마다 CI 검사가 실행된다. - 따라서 작은 PR이라도 테스트와 규칙 검증을 통과해야 한다. ## 에이전트별 작업 분담 - 에이전트에게 전체 기능을 한 번에 맡기기보다, 계층별로 역할과 범위를 지정한다. - 예시 구성: - L1: 데이터 모델러 에이전트 - L2: 백엔드 에이전트 - L3: 프론트엔드 에이전트 - L4: 프론트엔드 에이전트 - 각 에이전트는 하나의 작업 스트림과 엄격한 범위를 따르도록 구성한다. - 이런 방식은 에이전트가 자동화 루프에서 작업하더라도 결과물이 지나치게 커지는 것을 방지한다. - 작업 순서는 데이터 기반을 먼저 만들고, API, 채팅 연결, UI 순으로 진행한다. ## 실용적인 적용 방법 - 기능을 시작할 때 먼저 데이터·도메인 모델·API·애플리케이션 연결·UI로 나눈다. - 각 PR이 단일 관심사만 포함하는지 확인한다. - 기반 브랜치를 먼저 만들고, 각 후속 브랜치를 바로 이전 계층에서 파생한다. - 계층별로 적절한 리뷰어를 배정하고, 각 PR에 해당 계층의 목적과 검증 방법을 명확히 작성한다. - AI 에이전트에는 “전체 기능 구현”이 아니라 특정 스택 계층과 변경 범위를 명시하는 것이 좋다. - 스택드 PR은 리뷰 부담을 줄이는 대신 브랜치 의존성을 관리해야 하므로, CLI와 자동화 도구를 함께 사용하는 것이 효과적이다.

github

일찍 멈추지 마라: 메모리 속도로 소스 코드의 대소문자를 정규화하기 (새 탭에서 열림)

GitHub는 코드 검색 엔진 Blackbird에서 대규모로 수행되는 유니코드 케이스 폴딩을 메모리 대역폭에 가까운 속도로 최적화했다. 핵심은 비ASCII 문자를 만나면 즉시 중단하는 기존 최적화를 제거하고, 전체 버퍼를 분기 없이 처리해 컴파일러의 SIMD 벡터화를 유도한 것이다. Apple M4에서 단순 구현의 약 3.1GiB/s 처리량을 45GiB/s 이상으로 끌어올렸으며, 분기 없는 코드는 벡터화를 가능하게 할 때만 이점이 있다는 점도 확인했다. ## 케이스 폴딩과 소문자 변환의 차이 - 케이스 폴딩은 표시를 위한 변환이 아니라 문자열 비교를 위한 정규화다. - 대소문자만 다른 문자열을 동일하게 취급하기 위해 사용된다. - 검색 엔진 - 정규식의 `(?i)` 옵션 - 대소문자를 구분하지 않는 사용자명과 호스트명 - 일반적인 소문자 변환과 달리 케이스 폴딩은: - 로케일에 독립적이다. - 문맥에 의존하지 않는다. - 비교 관계가 일관되고 대칭적이다. - 그리스어 final sigma, 터키어의 `I`, 독일어 `ß`처럼 소문자 변환과 케이스 폴딩 결과가 달라지는 문자가 있어 `to_lowercase`를 대체 수단으로 사용하면 잘못된 검색 결과가 발생할 수 있다. - 공개된 Rust `casefold` 크레이트는 Unicode `CaseFolding.txt`의 단일 문자 변환인 C·S 상태만 구현한다. - `ß → ss`와 같은 다중 문자 변환은 지원하지 않는다. - 터키어 전용 폴딩도 지원하지 않는다. - ripgrep과 정규식 엔진도 유사한 제한을 둔다. ## GitHub에서 케이스 폴딩이 중요한 이유 - Blackbird는 1억 8천만 개 이상의 저장소와 480TB가 넘는 소스 코드를 색인한다. - 색인 전에 모든 바이트를 폴딩하고, 검색 결과 후보를 확인할 때도 케이스 폴딩이 반복적으로 수행된다. - 소스 코드는 대부분 ASCII이므로 ASCII 경로를 메모리 속도로 처리하는 것이 가장 큰 성능 개선 요소다. - 비ASCII 입력은 드물기 때문에, 최적화의 목표는: - 흔한 ASCII 경로를 최대한 빠르게 만들고 - 드문 유니코드 경로가 ASCII 성능을 방해하지 않게 하는 것이다. ## 조기 종료를 제거한 ASCII 처리 기존 방식은 비ASCII 바이트를 만나면 즉시 반복문을 종료하고 유니코드 처리로 넘겼다. ```text if byte >= 0x80 { break } ``` 하지만 이 데이터 의존적 `break`는 컴파일러의 루프 벡터화를 막는다. 개선된 구현은 다음과 같이 동작한다. - 모든 바이트를 끝까지 순회한다. - `high_bit_acc |= byte`로 모든 바이트의 최상위 비트를 누적한다. - 반복문이 끝난 뒤 누적값을 한 번만 검사해 비ASCII 문자가 있었는지 확인한다. - 따라서 반복문 내부에는 데이터에 따른 분기나 조기 종료가 없다. 이 방식은 비ASCII 여부를 동일하게 알아내면서도 SIMD 명령을 사용할 수 있게 한다. ## 분기 없는 ASCII 대소문자 변환 ASCII 대문자 변환도 조건문 대신 산술 연산으로 처리한다. - `b.wrapping_sub(b'A') < 26` - 바이트가 `A`부터 `Z` 사이일 때만 참이 된다. - 별도의 분기 없이 대문자 여부를 0 또는 1 마스크로 만든다. - `u8::from(is_upper) << 5` - 대문자이면 ASCII의 비트 5를 설정해 소문자로 바꾼다. - 그 외 문자는 아무 변화가 없다. - 모든 바이트를 항상 저장하므로 조건부 저장 명령도 제거된다. 결과적으로 루프는 다음 특성을 갖는다. - 데이터 의존적 분기 없음 - 조기 종료 없음 - 연속적인 메모리 접근 - LLVM이 NEON 기반 16바이트 단위 SIMD 코드 생성 가능 ## 벤치마크와 성능 개선 Apple M4에서 5.7KB ASCII 버퍼를 처리한 누적 측정 결과는 다음과 같다. - 조기 종료와 분기 조건을 사용하는 순진한 구현: **3.1GiB/s** - 본문만 분기 없이 바꾸고 조기 종료를 유지한 구현: **2.6GiB/s** - 조기 종료를 제거한 구현: **7.6GiB/s** - 대문자 판별과 저장까지 분기 없이 처리한 최종 구현: **45GiB/s 이상** 성능 향상의 핵심은 단순히 분기를 없앤 것이 아니다. - 조기 종료 제거가 루프 벡터화를 가능하게 했다. - 대문자 변환의 분기 제거가 완전한 벡터화를 가능하게 했다. - 최종 성능은 사실상 메모리 대역폭 한계에 도달했다. ## 스칼라 코드에서는 분기 없는 방식이 느릴 수 있다 - 조기 종료를 유지한 채 본문만 분기 없이 바꾼 구현은 오히려 3.1GiB/s에서 2.6GiB/s로 느려졌다. - 기존 분기 방식은 실제로 값이 바뀌는 대문자일 때만 저장한다. - 소문자, 숫자, 공백이 대부분인 일반 텍스트에서는 조건부 저장 분기가 매우 잘 예측된다. - 반면 분기 없는 구현은 모든 바이트를 무조건 저장해 불필요한 쓰기 트래픽이 발생한다. - 따라서 분기 없는 코드는 그 자체로 항상 빠른 것이 아니다. - 이 사례에서는 분기 없는 코드가 SIMD 벡터화를 가능하게 하는 수단이었기 때문에 최종적으로 큰 이득을 냈다. 실용적으로는 데이터 규모가 크고 반복 횟수가 많은 바이트 처리에서 조기 종료가 정말 최적인지 확인해야 한다. 특히 루프의 조기 종료가 SIMD 벡터화를 막는다면, 전체 버퍼를 일정한 흐름으로 처리하고 마지막에 상태를 확인하는 방식이 훨씬 빠를 수 있다.

github

GitHub Copilot 앱에서 세션과 풀 리퀘스트 쌓기 (새 탭에서 열림)

10년 넘은 React 15·Less·구버전 react-bootstrap 기반 프로젝트를 GitHub Copilot 앱으로 현대화한 경험을 소개합니다. 한 번에 전체를 바꾸려 하지 않고, 기존 작업을 세션과 브랜치별로 나누어 순차적으로 진행하는 “스택 세션” 방식이 핵심입니다. AI가 계획 수립, 코드 변경, PR 생성, 브랜치 전환까지 지원하면서 오래된 프로젝트의 대규모 유지보수를 현실적으로 수행할 수 있었다는 결론입니다. ## 오래된 프런트엔드 현대화의 어려움 - 개인용 대시보드 애플리케이션을 2014년경부터 운영해 왔습니다. - React 15, Less, 구버전 `react-bootstrap` 등 의존성이 수년간 업데이트되지 않았습니다. - 애플리케이션 규모가 아주 크지는 않지만, 구조가 충분히 복잡해 수작업으로 정리하려면 수주가 걸릴 상황이었습니다. - 과거에도 현대화를 시도했지만 호환성 문제 때문에 중단한 경험이 있었습니다. ## 첫 시도: 전체 현대화를 한 번에 진행하기 - Copilot의 Plan 모드에서 다음 작업을 요청했습니다. - Tailwind와 vanilla CSS 중 적절한 방식 검토 - Less 제거 - 접근성 및 반응형 개선 - 의존성 현대화 - React 기능의 점진적 정리와 통합 - 링크의 hover/focus 스타일 개선 - 입력 필드의 테두리 반경 축소와 라벨 정리 - 컨테이너 최대 너비와 적절한 줄바꿈 적용 - Claude Opus 4.8과 GPT-5.5의 검토를 거쳐 계획을 다듬은 뒤 실제 변경을 시작했습니다. - 그러나 처음부터 `main` 브랜치를 기준으로 작업한 것이 문제였습니다. AI가 충분히 좋은 계획을 세웠더라도, 현재 운영 중인 코드의 실제 기준 브랜치를 잘못 선택하면 결과가 실행되지 않을 수 있었습니다. ## 기존 `dev` 브랜치와의 충돌 발견 - 과거에 중단한 줄 알았던 현대화 작업이 실제로는 `dev` 브랜치에 일부 남아 있었습니다. - 현재 배포 환경은 `main`이 아니라 부분적으로 업데이트된 `dev` 브랜치를 사용하고 있었습니다. - 따라서 새 작업을 `main`에서 시작하면 기존 기능과 설정이 누락될 수 있었습니다. - 변경 규모가 커서 `dev`의 내용을 `main`으로 병합하기보다, 기존 PR을 닫고 `dev`에서 새 작업을 시작하는 편이 안전했습니다. - Copilot은 사용자의 지시에 따라: - 기존 세션의 PR을 닫고 - `dev`에서 새 브랜치를 만들고 - 기존 스타일·접근성 개선안을 새 기준에 맞게 다시 적용했습니다. ## 테스트 중 발견한 오래된 의존성 문제 - 스타일 변경 후 테스트하는 과정에서 `findDOMNode`, `componentWillReceiveProps` 관련 경고가 나타났습니다. - 문제의 상당 부분은 애플리케이션 코드가 아니라 오래된 `react-bootstrap`에 있었습니다. - Copilot의 Plan 모드에 다음 두 가지 선택지를 검토하게 했습니다. - `react-bootstrap`을 업그레이드해 기존 컴포넌트를 마이그레이션하기 - 라이브러리를 완전히 제거하고 현대적인 대체 구현으로 교체하기 - 분석 결과, 기존 라이브러리를 유지하기보다 전체 교체하는 방향이 권장되었습니다. ## 스택 세션과 분리된 pull request - `react-bootstrap` 교체는 기존 스타일·접근성 작업과 관련이 있지만, 범위가 크게 늘어나는 별도 작업이었습니다. - AI를 활용하면 구현 비용이 낮아 보여 여러 문제를 한 번에 해결하고 싶어지지만, 결과적으로 1만 줄 규모의 거대한 PR이 될 수 있습니다. - 이를 방지하기 위해 작업을 다음처럼 나눴습니다. - 먼저 현재 스타일·접근성 작업을 하나의 PR로 제출 - 해당 작업을 기반으로 새 세션과 브랜치를 생성 - 새 세션에서 `react-bootstrap` 교체를 별도 PR로 진행 - 첫 번째 PR을 `dev`에 병합한 뒤 두 번째 PR을 병합 - 이렇게 각 세션이 이전 세션의 결과 위에 쌓이도록 구성하면 작업 간 의존성은 유지하면서도 변경 범위와 검토 단위를 작게 만들 수 있습니다. ## 실용적인 결론 - AI에게 전체 프로젝트를 한 번에 현대화하게 하기보다, 기준 브랜치와 작업 범위를 먼저 확인하는 것이 중요합니다. - 스타일 개선, 의존성 교체, 기능 리팩터링을 각각 독립적인 세션과 PR로 나누면 테스트와 롤백이 쉬워집니다. - 특히 오래된 저장소에서는 현재 배포 브랜치가 무엇인지 확인한 뒤, 그 브랜치에서 새 세션을 시작하는 방식을 추천합니다.

github

Dependabot 길들이기: 업데이트를 그룹화하고, 주기를 늦추되, 보안 업데이트는 신속하게 (새 탭에서 열림)

활성 저장소에서는 Dependabot이 의존성마다 개별 PR을 생성해 알림, 리뷰, CI 실행을 과도하게 늘릴 수 있다. 글은 Microsoft GCToolkit 사례를 통해 의존성 업데이트를 생태계별로 그룹화하고 주기를 월간으로 늦추면 유지보수 소음을 크게 줄일 수 있다고 설명한다. 다만 일반 버전 업데이트와 달리 보안 업데이트는 신속하게 처리되므로, 업데이트 빈도를 낮춰도 보안 대응 속도는 유지할 수 있다. ## Dependabot이 만드는 유지보수 소음 - GCToolkit의 578개 커밋 중 92개가 Dependabot 버전 업데이트였으며, 최근 12개월에만 61개가 발생했다. - 기존 설정은 다음과 같았다. - GitHub Actions만 감시 - 매일 업데이트 확인 - 최대 10개의 PR 허용 - 의존성 10개가 업데이트되면 PR 10개, CI 실행 10회, 리뷰 알림 10건이 발생한다. - `open-pull-requests-limit: 10`은 PR 수를 제한할 뿐, 업데이트가 쏟아지는 원인을 해결하지 못한다. ## 여러 업데이트를 하나의 PR로 그룹화 - `groups`와 `patterns: ["*"]`를 사용하면 모든 의존성 업데이트를 하나의 PR로 묶을 수 있다. - 예를 들어 10개의 업데이트가 발생해도 다음처럼 처리된다. - 브랜치 1개 - PR 1개 - CI 실행 1회 - 리뷰 및 병합 1회 - 그룹 이름은 자유롭게 정할 수 있으며 PR 제목과 브랜치 이름에 표시된다. - 규모가 큰 프로젝트에서는 테스트 라이브러리, 운영 의존성 등 목적별로 여러 그룹을 만들 수 있다. - 모노레포에서는 `directories`와 `group-by: dependency-name`을 사용해 여러 디렉터리에 같은 의존성이 있을 때 하나의 PR로 통합할 수 있다. ```yaml - package-ecosystem: "npm" directories: - "/apps/*" schedule: interval: "monthly" groups: monthly-batch: group-by: dependency-name patterns: - "*" ``` ## 업데이트 주기를 일간에서 월간으로 변경 - `interval: daily`는 평일마다 업데이트를 확인하므로 지속적인 PR 생성으로 이어질 수 있다. - `interval: monthly`로 바꾸면 계획 가능한 월간 배치 방식으로 전환된다. - 그룹화와 결합하면 생태계별로 한 달에 하나의 일괄 PR을 받게 된다. - 프로젝트 특성에 따라 `weekly`를 선택할 수도 있고, `schedule.day`와 `schedule.time`으로 실행 시점을 지정할 수 있다. - 의존성이 안정적인 성숙한 라이브러리에는 월간 주기가 적합하다. ## 실제 사용하는 생태계를 모두 설정 - 기존 설정은 GitHub Actions만 대상으로 했지만, GCToolkit은 Maven 기반 Java 프로젝트이므로 Maven 의존성도 별도로 등록해야 했다. - 생태계마다 `updates` 항목을 추가해야 한다. ```yaml - package-ecosystem: "github-actions" directory: "/" schedule: interval: "monthly" groups: monthly-batch: patterns: - "*" - package-ecosystem: "maven" directory: "/" schedule: interval: "monthly" groups: monthly-batch: patterns: - "*" ``` - GitHub Actions와 Maven 업데이트는 각각 독립된 그룹과 일정으로 관리된다. - 소음을 줄이는 것뿐 아니라, 실제 애플리케이션 의존성까지 Dependabot이 감시하도록 만드는 것이 중요하다. ## 보안 업데이트는 빠르게 유지 - 월간 일정과 그룹 설정은 일반적인 버전 업데이트의 처리 방식을 조정하는 설정이다. - Dependabot 보안 업데이트는 별도의 메커니즘으로 동작하므로, 일반 업데이트 주기를 늦춰도 보안 취약점 대응까지 월간으로 미뤄지지 않는다. - 따라서 평상시에는 일괄 업데이트로 리뷰 부담을 줄이고, 보안 수정은 기존처럼 신속하게 처리하는 균형을 유지할 수 있다. ## 실용적인 적용 방법 - 안정적인 저장소라면 생태계별로 `monthly` 일정과 전체 의존성 그룹화를 적용한다. - 업데이트가 자주 필요하거나 변경 영향이 큰 프로젝트는 `weekly` 또는 목적별 다중 그룹을 사용한다. - GitHub Actions뿐 아니라 Maven, npm 등 실제 사용하는 모든 패키지 생태계를 `dependabot.yml`에 등록한다. - 보안 업데이트 설정은 별도로 확인해 취약점 수정이 지연되지 않는지 점검한다.

github

npm 및 GitHub Actions의 공급망 공격 교란 (새 탭에서 열림)

npm과 GitHub Actions를 겨냥한 공급망 공격은 계정 탈취, CI/CD 취약점 악용, 자격 증명 탈취, 악성 패키지 확산을 연쇄적으로 결합한다. GitHub는 단일 방어 기능보다 공격 단계별로 핵심 연결고리를 끊는 다층 방어가 필요하다고 보고, npm과 GitHub Actions에 계정 보호·워크플로 권한 제한·캐시 보호·무자격 증명 배포 등의 기능을 도입했다. 목표는 공격을 완전히 제거하기보다 초기 침해와 권한 상승, 자격 증명 유출, 대규모 확산을 차단하고 탐지·대응 시간을 확보하는 것이다. ## 공급망 공격의 구조 - 공격은 대개 다음 단계로 진행된다. - 유지보수자 계정이나 프로젝트의 GitHub Actions 워크플로를 침해한다. - CI/CD 환경에서 더 높은 권한과 자격 증명을 찾는다. - 토큰과 계정 정보를 외부로 유출한다. - 탈취한 자격 증명으로 다른 패키지와 프로젝트를 연쇄적으로 감염시킨다. - 공격 방식은 다양하지만, 초기 침해·권한 상승·확산이라는 공통된 흐름을 가진다. - 따라서 하나의 보안 기능보다 공격 사슬의 영향력이 큰 지점을 여러 단계에서 차단하는 접근이 필요하다. ## 초기 침해 차단 - **고영향 npm 계정 보호** - 이메일 주소를 변경하거나 2FA 복구 코드를 사용한 고영향 npm 계정은 72시간 동안 읽기 전용 상태가 된다. - 피싱으로 계정을 탈취당하더라도 공격자가 즉시 악성 버전을 배포하지 못하게 한다. - 해당 기간 동안 유지보수자가 계정을 복구하거나 이상 행위를 확인할 수 있다. - **`pull_request_target`의 안전한 checkout 기본값** - 포크에서 제출된 풀 리퀘스트의 신뢰할 수 없는 코드를 워크플로가 실행하는 “pwn request” 취약점을 완화한다. - `actions/checkout`은 일반적으로 악용되는 트리거에서 포크의 비신뢰 코드를 checkout하지 않도록 변경됐다. - 관리자가 위험을 검토한 뒤 명시적으로 예외를 선택해야 하며, 기존 버전에도 변경 사항이 백포트됐다. - **워크플로 실행 주체와 트리거 제한** - 엔터프라이즈·조직·저장소 수준에서 누가 워크플로를 실행할 수 있는지 설정할 수 있다. - 허용할 워크플로 트리거 유형도 제한할 수 있다. - 이를 통해 Actions 인프라에 최소 권한 원칙을 적용하고 공격 표면을 줄인다. - **비신뢰 트리거의 Actions 캐시 읽기 전용화** - 공격자가 워크플로 실행 권한을 얻은 뒤 공유 캐시를 오염시켜 더 높은 권한의 워크플로를 공격하는 경로를 차단한다. - 신뢰도가 낮은 워크플로는 다른 워크플로와 공유되는 캐시를 수정할 수 없게 된다. - 결과적으로 릴리스·패키지 배포 워크플로의 고권한 자격 증명 탈취로 이어지는 권한 상승을 어렵게 만든다. ## 자격 증명 탈취와 유출 방지 - **장기 자격 증명 제거** - CI/CD 파이프라인에 저장된 장기 토큰은 공격자가 가장 먼저 노리는 대상이다. - npm Trusted Publishing은 장기 자격 증명 없이 패키지를 배포하도록 해 탈취 가능한 비밀 정보를 줄인다. - CircleCI도 Trusted Publishing 공급자로 추가되어, CircleCI 기반 배포에서도 장기 자격 증명 제거가 가능해졌다. - **Actions 네트워크 방화벽** - 기술 프리뷰 단계의 기능으로, Actions 실행 중 발생하는 모든 외부 네트워크 트래픽을 기록한다. - 악성 코드 다운로드나 새 도메인으로의 자격 증명 유출처럼 비정상적인 통신을 탐지하는 데 활용할 수 있다. - 향후에는 네트워크 외부 연결 제한과 정책 기반 차단을 지원해 유출이 발생하기 전에 공격을 막는 방향으로 확장될 예정이다. ## 악성 패키지 확산 억제 - **npm 단계적 게시(Staged Publishing)** - 패키지 배포 자격 증명만 가지고는 새 버전을 즉시 공개할 수 없도록 한다. - 배포된 패키지는 추가 승인과 npm CLI 또는 npmjs.com에서의 2FA 인증이 완료될 때까지 보류된다. - 선택적으로 활성화할 수 있으며, 자동화·CI/CD 자격 증명과 실제 배포 승인 절차를 분리한다. - 탈취된 배포 자격 증명으로 악성 버전을 대규모 배포하는 공격을 줄인다. ## 실용적인 권장 사항 npm 유지보수자는 고영향 계정 보호, Trusted Publishing, 단계적 게시를 검토하고, GitHub Actions 사용자는 포크 PR 처리 방식과 캐시 공유 구조를 점검하는 것이 좋다. 또한 워크플로 실행 주체를 최소화하고, Actions 네트워크 트래픽을 모니터링하면 자격 증명 유출과 연쇄 확산을 조기에 발견할 가능성을 높일 수 있다.

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 설정을 작업 끝까지 유지한다. - 프로토타입으로 요구사항을 구체화한 뒤 계획과 구현 단계로 넘어간다. 어진 글의 본문은 “계획 수립” 섹션 초입에서 끝나므로, 이후 계획·구현 단계의 구체적인 내용은 제공된 자료만으로 확인할 수 없다.

github

초보자를 위한 GitHub Copilot 앱: 시작하기 (새 탭에서 열림)

GitHub Copilot 앱은 단순한 채팅 도구가 아니라, 프로젝트별 AI 에이전트 세션을 관리하고 코드 작성부터 리뷰·병합까지 지원하는 통합 개발 작업 공간이다. 여러 작업을 동시에 진행하고, 캔버스에서 UI를 직접 확인·수정하며, Agent Merge로 PR 리뷰와 CI 문제 대응까지 자동화할 수 있다. 글은 초보자가 프로젝트를 연결해 세션을 시작하고 실제 개발 workflow에 Copilot을 활용하는 방법을 소개한다. ## 프로젝트를 중심으로 시작하는 작업 - Copilot 앱의 각 에이전트 세션은 특정 프로젝트와 연결된다. - 기존에 작업한 GitHub 프로젝트를 선택하거나 GitHub 저장소·로컬 컴퓨터에서 새 프로젝트를 추가할 수 있다. - 프로젝트가 연결되면 에이전트가 코드베이스, 파일, 개발 도구에 접근한 상태로 작업을 시작한다. - 예를 들어 “기존 애플리케이션에 breadcrumb navigation을 추가해 달라”고 요청하면 에이전트가 다음 작업을 수행할 수 있다. - 관련 파일과 수정 위치 탐색 - 코드 변경 - 테스트 실행 - 변경 사항 검증 지원 - 세션 시작 전에 개발 환경과 파일을 수동으로 준비할 필요가 줄어든다. ## 여러 작업을 동시에 진행하는 세션 - 기존 세션을 중단하지 않고 다른 질문이나 작업을 위한 추가 세션을 만들 수 있다. - **Quick Chat**을 사용하면 Copilot 앱 홈 화면에서 별도의 대화를 시작할 수 있다. - 각 세션을 다음과 같이 독립적인 주제에 사용할 수 있다. - 새로운 기능 구현 - 코드베이스 구조 조사 - 가능한 구현 방식 비교 - Copilot 앱이나 worktree 사용법 질문 - 원래 작업 세션으로 돌아오면 이전 맥락과 변경 사항을 확인한 뒤 작업을 이어갈 수 있다. - 작업별로 대화를 분리하면 서로 다른 개발 흐름을 섞지 않고 진행 상황을 관리하기 쉽다. ## 캔버스를 이용한 UI 확인과 개선 - UI 작업에서는 코드 검토뿐 아니라 실제 화면을 직접 확인하는 것이 중요하다. - Copilot 앱의 **canvas**는 애플리케이션, 계획, 칸반 보드, 체크리스트 같은 작업 결과물을 대화 옆에서 시각적으로 보여주는 공유형 공간이다. - `/create-canvas Open this app in a browser canvas` 명령으로 별도 터미널이나 브라우저를 열지 않고 애플리케이션을 실행할 수 있다. - **Enable Canvas Dev Mode**를 켜면 캔버스에서 특정 UI 요소를 직접 선택할 수 있다. - **Pick & Polish** 기능을 사용하면 선택한 요소를 다음 요청의 컨텍스트로 전달해 다음과 같은 반복 개선이 가능하다. - 화면의 특정 요소 선택 - 수정 요청 작성 - 변경 결과 확인 - 추가 조정 반복 - 텍스트 기반 설명만으로 UI를 수정하는 것보다 시각적 결과를 기준으로 구체적인 피드백을 제공할 수 있다. ## Agent Merge를 활용한 PR 후속 작업 - 코드 변경이 끝난 뒤에는 pull request, CI, 코드 리뷰 과정이 이어진다. - Copilot 앱의 PR 옵션에서 **Agent Merge**를 활성화하면 에이전트가 PR 진행 상황을 모니터링한다. - 허용할 작업을 선택할 수 있으며, 주요 예시는 다음과 같다. - 리뷰 피드백 반영 - CI 실패 원인 해결 지원 - merge conflict 처리 - 리뷰 중 변경 요청이나 자동화된 검사 실패가 발생하면 Agent Merge가 대응 작업을 수행하고 PR을 병합 가능한 상태로 준비한다. - 필수 검사가 모두 통과한 뒤 사용자가 최종적으로 병합할 수 있다. ## AI 에이전트 기반 개발 workflow - Copilot 앱은 하나의 대화창보다 실제 소프트웨어 개발 과정에 맞춘 작업 공간을 제공한다. - 기본 workflow는 다음과 같이 구성된다. 1. 프로젝트 선택 2. 작업별 에이전트 세션 생성 3. 필요할 때 Quick Chat으로 조사·질문 4. 캔버스에서 실행 결과와 UI 확인 5. PR 생성 6. Agent Merge로 리뷰·CI·충돌 대응 7. 검사 통과 후 병합 - 사용자는 코드 작성뿐 아니라 탐색, 시각적 검증, 리뷰 대응까지 한 환경에서 이어서 진행할 수 있다. 새 기능이나 오래된 backlog 작업을 하나 선택해 프로젝트를 연결하고, 작업별 세션과 캔버스를 활용해 작은 범위부터 시작하는 것이 좋다. 다만 AI가 만든 변경 사항과 테스트 결과는 직접 검토한 뒤 PR을 병합해야 한다.

github

쿨다운이 필요한 이유: Dependabot이 이제 버전 업데이트를 내놓기 전에 기다리는 이유 (새 탭에서 열림)

Carlin은 GitHub Advanced Security에서 Dependabot을 담당하는 제품 관리자입니다. 소프트웨어 엔지니어링과 데이터 과학 경험을 바탕으로 데이터 중심의 제품 관리 방식을 활용합니다. 워싱턴에서 파트너와 반려견 Cookie와 함께 살며, 여가 시간에는 사이클링과 경쟁적인 보드게임을 즐깁니다. ### GitHub에서의 역할 - GitHub Advanced Security 조직에서 제품 관리 업무를 담당합니다. - 주요 담당 분야는 Dependabot입니다. - 보안과 의존성 관리 기능을 발전시키는 데 집중하고 있습니다. ### 기술적 배경과 업무 방식 - 소프트웨어 엔지니어링 경험을 보유하고 있습니다. - 데이터 과학 배경을 바탕으로 의사결정과 제품 전략을 수립합니다. - 데이터에 근거한 제품 관리 접근 방식을 중요하게 여깁니다. ### 개인 생활과 관심사 - 워싱턴에서 파트너 및 반려견 Cookie와 함께 생활합니다. - 여가 시간에는 사이클링을 즐깁니다. - 경쟁적인 보드게임에도 참여합니다. 전반적으로 Carlin은 개발 및 데이터 전문성을 활용해 GitHub의 보안 제품을 이끄는 제품 관리자입니다.

github

Copilot vs. 직접 API 접근: 실제로 무엇에 비용을 지불하고 있나요? (새 탭에서 열림)

같은 AI 모델을 사용하더라도 GitHub Copilot과 원시 API는 서로 다른 계층의 문제를 해결한다. Copilot은 이슈부터 코드 수정, 테스트, 풀 리퀘스트와 조직 정책 적용까지 연결된 개발 워크플로를 제공하고, 원시 API는 프롬프트·검색·라우팅·보안·로그·과금 등을 직접 설계하는 시스템 구축용 기반이다. 따라서 비용과 선택 기준은 토큰 단가만이 아니라 팀이 직접 소유하고 운영해야 하는 작업의 범위에 따라 결정된다. ## GitHub Copilot은 모델을 둘러싼 개발 도구 - Copilot의 모델 호출은 개발 작업 전체 중 한 단계에 불과하다. - 일반적인 유지보수 작업에는 다음 요소가 함께 필요하다. - GitHub Issue 분석 - 저장소와 관련 파일 탐색 - 코드 수정 및 diff 생성 - 저장소 지침과 허용된 명령 반영 - 터미널에서 테스트 실행 - Pull Request 생성 및 리뷰 - 조직의 보안·사용 정책 적용 - Copilot은 에디터, 저장소, 이슈, PR, 터미널, 조직 관리 기능을 하나의 흐름으로 연결한다. - 유료 플랜에서는 코드 자동 완성과 Next Edit Suggestions가 계속 포함되며, 더 많은 리소스를 사용하는 채팅·에이전트 작업에는 AI Credits가 적용된다. - 실제 작업 비용은 모델의 토큰 단가 외에도 다음 요인에 영향을 받는다. - 선택된 컨텍스트의 양 - 도구 호출 횟수 - 실패에 따른 재시도 - 이슈에서 리뷰 완료 PR까지 이어지는 전체 작업 경로 - 조직 플랜은 AI Credits를 조직 단위로 공유하고, 관리자가 예산과 사용량을 대시보드에서 추적할 수 있다. ## 원시 API는 직접 소유하는 시스템을 위한 기반 - API 직접 호출은 다음과 같은 시스템을 만들 때 적합하다. - 제품 기능에 포함되는 AI 기능 - 사내 에이전트 플랫폼 - 모델 평가·벤치마크 도구 - 자동화 파이프라인 - 개발자가 직접 결정할 수 있는 항목이 많다. - 프롬프트 구성 - 문서 및 코드 검색 방식 - 모델 라우팅 - 실패한 도구 호출의 재시도 정책 - 로그와 추적 데이터 저장 - 인증 정보와 보안 경계 - 과금 및 사용량 관리 - 예를 들어 사내 에이전트가 특정 태그의 이슈를 읽고, 회사 문서를 검색하고, 별도 시스템에 변경 요청을 만들며, 감사 기록까지 남긴다면 자체 데이터 경계·이벤트 트리거·승인 절차가 필요하다. - API는 이런 요구사항을 구현할 수 있는 기본 요소를 제공하지만, 저장소 파일을 어떻게 검색하고 에이전트 권한을 어디까지 허용할지는 개발자가 설계해야 한다. ## 에이전트 SDK는 두 계층 사이의 선택지 - 에이전트 SDK는 모델 API와 완성된 개발 도구 사이에서 오케스트레이션을 담당한다. - 일반적으로 다음 기능을 제공한다. - 도구 사용 - 세션 관리 - 스트리밍 응답 - 에이전트 실행 흐름 제어 - SDK에 따라 특정 제공업체에 종속되거나 여러 모델 제공업체를 지원할 수 있다. - GitHub Copilot SDK는 Copilot CLI를 구동하는 에이전트 런타임을 노출해, 직접 처음부터 에이전트 하네스를 만들지 않고도 검증된 실행 환경을 임베드할 수 있게 한다. - 이 런타임은 Copilot 구독 또는 사용자의 자체 provider key로 실행할 수 있다. ## BYOK: Copilot 워크플로와 모델 비용을 분리 - Copilot의 BYOK(Bring Your Own Key)는 지원되는 외부 모델을 Copilot Chat, Copilot CLI, VS Code에서 사용할 수 있게 한다. - 지원 제공업체에는 다음이 포함된다. - Anthropic - AWS Bedrock - Google AI Studio - Microsoft Foundry - OpenAI 및 OpenAI 호환 제공업체 - xAI - 모델은 Copilot의 하네스와 GitHub가 유지하는 통합 기능을 사용하지만, 토큰 비용은 사용자가 연결한 제공업체에 청구된다. - 기존 클라우드 계약이나 약정된 사용량이 있는 팀은 해당 계약을 유지하면서도 개발자는 익숙한 Copilot 환경을 사용할 수 있다. - Copilot CLI에서는 Azure OpenAI, Anthropic, 로컬 Ollama 모델 등도 사용할 수 있다. - BYOK는 글 작성 시점에 공개 프리뷰이므로 구매나 아키텍처 결정을 내리기 전에 최신 GitHub 문서를 확인해야 한다. - 엔터프라이즈와 조직 관리자는 GitHub 호스팅 모델과 BYOK 모델을 포함해 팀에서 사용할 모델을 정책으로 제한할 수 있다. ## 상황에 따른 선택 기준 - **원시 API를 선택할 때** - 자체 제품이나 내부 시스템에 AI를 통합해야 할 때 - 사용자 정의 프롬프트·검색·라우팅이 필요할 때 - 보안, 감사, 승인, 로그, 과금 체계를 직접 통제해야 할 때 - **GitHub Copilot을 선택할 때** - 개발자가 GitHub와 IDE 안에서 코드를 작성하고 리뷰할 때 - 이슈부터 PR, 테스트, 보안 정책까지 연결된 흐름이 중요할 때 - 조직 차원의 사용량·예산·모델 정책 관리가 필요할 때 - **BYOK를 고려할 때** - Copilot의 개발 워크플로는 유지하면서 특정 외부 모델이나 기존 클라우드 계약을 사용해야 할 때 실용적으로는 팀의 개발 생산성 향상이 목적이면 Copilot을, 독자적인 AI 제품이나 자동화 시스템 구축이 목적이면 원시 API를 우선 검토하는 것이 적절하다. 두 요구가 모두 있다면 Copilot 또는 Copilot SDK에 BYOK를 결합하는 방식도 선택지가 된다.