Ed Burns는 Microsoft와 GitHub 기술에 자바다운(idiomatic) 개발 경험을 제공하는 Principal Software Engineer입니다. 1997년부터 자바를 사용해 왔으며, 클라이언트·서버·클라우드·AI 등 다양한 영역에서 활동해 왔습니다.
### Ed Burns의 역할
- Microsoft와 GitHub 기술 생태계에 자바 관용적 개발 경험을 도입하는 업무를 담당합니다.
- Principal Software Engineer로서 기술 방향과 개발 경험 개선에 기여합니다.
### 자바 경력과 전문 분야
- 1997년부터 자바를 다뤄 온 숙련된 개발자입니다.
- 다음과 같은 폭넓은 영역에서 경험을 쌓았습니다.
- 클라이언트 애플리케이션
- 서버 애플리케이션
- 클라우드 기술
- 인공지능(AI)
### 실용적인 결론
이 글은 특정 기술이나 방법론을 설명하기보다는 Ed Burns의 경력과 전문성을 소개하는 약력입니다. 자바가 클라이언트부터 AI까지 다양한 기술 영역에서 활용되어 왔다는 점을 보여줍니다.
Ankit은 GitHub에서 Dependabot 팀을 이끄는 시니어 엔지니어링 매니저입니다. Dependabot은 34개 이상의 패키지 생태계에 걸쳐 3천만 개가 넘는 저장소를 감시하며, 소프트웨어 공급망 공격에 대응하는 역할을 합니다. 이러한 광범위한 책임 때문에 Ankit은 공급망 보안 위협에 대해 높은 경계심을 유지하고 있습니다.
### Ankit의 역할
- GitHub의 Supply Chain Security 조직에서 Dependabot 팀을 이끕니다.
- 엔지니어링 관리자로서 소프트웨어 의존성 및 공급망 보안과 관련된 업무를 담당합니다.
### Dependabot의 감시 범위
- 3천만 개 이상의 저장소를 모니터링합니다.
- 34개 이상의 패키지 생태계를 지원합니다.
- 다양한 패키지 관리자와 의존성을 다뤄야 하므로 매우 광범위한 보안 대응이 필요합니다.
### 소프트웨어 공급망 보안
- 패키지와 의존성은 애플리케이션 보안에 직접적인 영향을 줍니다.
- 의존성의 취약점이나 악성 패키지는 다수의 저장소에 빠르게 확산될 수 있습니다.
- Dependabot의 대규모 감시 범위는 공급망 공격을 조기에 탐지하고 대응하는 데 중요한 역할을 합니다.
이 글의 제공된 내용은 Ankit과 Dependabot의 역할 및 규모를 소개하는 부분에 해당하며, 구체적인 기술적 주장이나 구현 세부사항은 포함되어 있지 않습니다.
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 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을 병합해야 한다.
디자인과 개발의 핸드오프는 일방향일 필요가 없으며, 디자이너가 Figma Make에서 실제 코드베이스를 직접 수정하고 PR까지 이어지는 작업 흐름을 제안한다. 작은 접근성·사용성 개선을 티켓과 백로그에 맡기지 않고 디자이너가 직접 처리하면, 엔지니어는 대규모 아키텍처 작업에 집중하면서도 제품의 완성도를 높일 수 있다. Figma Design, Figma Make, Figma agent, GitHub 연동을 활용해 캔버스에서 검토하고 코드로 반영하는 것이 핵심이다.
## 작은 개선이 백로그에 묻히는 문제
- “간격을 조금 줄여 달라”거나 “스크린 리더가 잘못 읽는다”와 같은 수정은 중요하지만 규모가 작아 우선순위 경쟁에서 밀리기 쉽다.
- 디자이너가 요구사항을 티켓으로 작성하면 엔지니어가 의도를 해석해야 하므로, 스크린샷과 설명을 주고받는 과정에서 디자인의 뉘앙스가 손실된다.
- 그 결과 엔지니어는 실제 구현보다 디자이너의 결정을 번역하는 데 시간을 쓰게 된다.
- 글에서는 이러한 문제를 해결하기 위해 디자이너가 저위험·고완성도 작업을 처음부터 끝까지 맡는 방식을 제안한다.
## MOSF 웹사이트의 접근성 개선 사례
- 가상의 박물관인 ‘Museum of Speculative Futures(MOSF)’가 사례로 등장한다.
- 엔지니어는 대규모 정보 구조 재작성에 집중해야 하고, 디자이너는 웹사이트의 접근성 문제를 해결하려 한다.
- PM은 엔지니어가 구조 개편 같은 고난도 작업을 계속 담당하고, 디자이너가 세부적인 접근성·사용성 개선을 직접 처리하도록 역할을 나눈다.
- 목표는 기술적으로 동작하는 수준을 넘어, 다양한 사용자가 실제로 편리하게 사용할 수 있는 웹사이트를 만드는 것이다.
## 캔버스에서 사용자 피드백 수집
- 디자이너는 수정 전에 현재 경험을 점검하기 위해 Figma Design의 Figma agent를 사용한다.
- 첫 방문자, 재방문 회원, 스크린 리더 사용자 등 여러 합성 페르소나를 생성하고 사이트를 탐색하게 한다.
- 합성 페르소나는 실제 사용자 조사나 대면 테스트를 대체하지 않지만, 초기에 명백한 마찰을 발견해 후속 사용자 조사에 집중할 여지를 만든다.
- 탐색 결과 다음과 같은 문제가 확인된다.
- 전시 페이지의 내비게이션 라벨이 모호함
- 주요 행동 유도 버튼(CTA)이 눈에 잘 띄지 않음
- 날짜 선택기가 한눈에 이해하기 어려움
- 검색 결과가 없을 때 빈 화면만 표시됨
- 각각은 대규모 기능 변경은 아니지만, 여러 문제가 누적되면 사이트의 접근성과 사용성이 크게 떨어질 수 있다.
## 팀 검토를 거친 디자인 수정
- 디자이너는 에이전트가 발견한 문제를 바탕으로 디자인을 수정한다.
- 이후 디자이너, 엔지니어, PM이 캔버스에서 변경 사항을 함께 검토한다.
- 검토 대상에는 방문 페이지의 더 명확한 라벨, 눈에 잘 띄는 CTA, 사용하기 쉬운 날짜 선택기 등이 포함된다.
- 디자인 단계에서 팀의 합의를 먼저 확보하므로, 코드 수정 이후에 요구사항을 다시 해석하거나 되돌리는 일을 줄일 수 있다.
## Figma Make로 실제 코드에서 작업
- 디자이너는 프로덕션 코드와 연결된 Figma Make를 사용해 캔버스의 수정 사항을 실제 코드에 반영한다.
- 기존처럼 티켓을 생성해 백로그에 넣고 엔지니어가 나중에 구현하기를 기다리지 않는 것이 핵심이다.
- Figma Make, GitHub 연동, 주석과 리뷰 기능을 통해 디자인 변경을 코드 변경으로 연결하고 팀 검토를 이어간다.
- 최종적으로 작업은 풀 리퀘스트(PR) 단계까지 진행되며, 디자이너가 캔버스에서 시작한 개선을 병합 가능한 코드 변경으로 전달한다.
- 이 방식은 엔지니어의 책임을 없애는 것이 아니라, 엔지니어가 코드 품질과 구조를 검토하는 동안 디자이너가 세부적인 사용자 경험 개선을 주도하도록 역할을 재배치한다.
작은 접근성·사용성 개선은 별도 티켓으로 쌓아두기보다, 디자이너가 실제 코드에서 직접 수정하고 엔지니어와 PR 리뷰를 진행하는 편이 효율적이다. 다만 합성 페르소나의 결과는 초기 탐색용으로 활용하고, 중요한 접근성 판단은 실제 사용자 조사와 기술 검증으로 보완하는 것이 바람직하다.
GitHub는 코드 저장소를 넘어, 버전 관리와 협업을 배우고 오픈소스에 참여하기 위한 개발자의 기반이다. 이 글은 Git과 GitHub의 기본 개념부터 계정 보안, 저장소 생성, Markdown, 브랜치와 풀 리퀘스트를 활용한 협업 흐름까지 초보자가 익혀야 할 내용을 단계적으로 설명한다. 핵심은 변경 사항을 Git으로 관리하고, GitHub에서 브랜치와 풀 리퀘스트를 통해 안전하게 공유·검토·통합하는 것이다.
## 버전 관리와 Git의 기본 개념
- 버전 관리는 파일의 변경 내용을 시간순으로 기록해 무엇이 언제, 왜 바뀌었는지 확인하고 이전 상태로 되돌릴 수 있게 한다.
- Git은 가장 널리 사용되는 버전 관리 시스템이다.
- Git의 작업 영역은 다음 세 가지로 나뉜다.
- **Working directory**: 실제 파일을 수정하는 공간
- **Staging area**: 다음 커밋에 포함할 변경 사항을 검토하고 준비하는 공간
- **Local repository**: 커밋된 변경 이력이 저장되는 공간
- 기본 흐름은 `git status`로 상태를 확인하고, `git add`로 변경 사항을 스테이징한 뒤, `git commit`으로 기록을 저장하는 방식이다.
- “코드를 push한다”는 말은 로컬에 만든 커밋을 GitHub의 원격 저장소에 업로드한다는 뜻이다.
## GitHub 계정 보안과 프로필 관리
- GitHub 계정은 개발자 정체성과 포트폴리오 역할을 하므로 보안을 강화해야 한다.
- **Settings → Password and authentication**에서 2단계 인증(2FA)을 활성화하면 비밀번호가 유출돼도 추가 인증 없이는 계정에 접근하기 어렵다.
- 2FA 복구 코드는 기기를 잃어버렸을 때 계정에 다시 로그인할 수 있는 중요한 수단이므로 비밀번호 관리자에 안전하게 보관해야 한다.
- 사용자 이름과 동일한 이름의 공개 저장소를 만들고 README를 추가하면, 해당 README가 GitHub 프로필에 표시된다.
- 프로필 README에는 기술, 프로젝트, 관심 분야 등을 작성해 개발자 포트폴리오로 활용할 수 있다.
## 자주 사용하는 Git 명령어
- `git config --global user.name "..."`: 커밋에 기록할 사용자 이름 설정
- `git init`: 현재 폴더를 Git 저장소로 초기화
- `git clone <url>`: 원격 저장소를 로컬로 복제
- `git status`: 변경 사항과 스테이징 상태 확인
- `git add .`: 모든 변경 사항을 스테이징
- `git commit -m "message"`: 스테이징된 변경 사항을 커밋
- `git switch -c <branch>`: 새 브랜치를 만들고 해당 브랜치로 이동
- `git push`: 로컬 커밋을 GitHub에 업로드
- `git pull`: GitHub의 최신 변경 사항을 내려받고 병합
- `git merge <branch>`: 다른 브랜치의 변경 사항을 현재 브랜치에 통합
## 첫 번째 GitHub 저장소 만들기
- 저장소(repository)는 프로젝트 파일과 변경 이력을 관리하고 여러 사람이 함께 작업하는 프로젝트의 중심 공간이다.
- GitHub 대시보드에서 **New**를 선택한 뒤 저장소 이름과 공개·비공개 여부를 지정해 만들 수 있다.
- README를 함께 생성하면 방문자가 프로젝트를 처음 이해하는 안내문 역할을 한다.
- 필요에 따라 다음 항목도 추가할 수 있다.
- **`.gitignore`**: 운영체제 파일, 의존성 폴더, 임시 빌드 결과물처럼 추적할 필요가 없는 파일을 Git에서 제외
- **라이선스**: 다른 사람이 코드를 어떤 조건으로 사용·수정·배포할 수 있는지 명시
- `.gitignore`를 사용하면 저장소에 실제 소스 코드와 중요한 파일만 남겨 프로젝트를 깔끔하게 유지할 수 있다.
## Markdown으로 문서 작성하기
- Markdown은 일반 텍스트에 간단한 기호를 추가해 제목, 목록, 링크, 코드 블록 등을 표현하는 가벼운 문서 형식이다.
- GitHub의 README, 이슈, 풀 리퀘스트, 댓글 등 대부분의 텍스트 작성 영역에서 사용된다.
- 일부 HTML 태그와 함께 사용해 문서를 읽기 쉽고 구조적으로 만들 수 있다.
- 좋은 Markdown 문서는 프로젝트의 목적과 사용 방법을 빠르게 전달해 저장소의 접근성을 높인다.
## GitHub Flow를 이용한 협업
- GitHub Flow는 공유 프로젝트에 변경 사항을 안전하게 반영하기 위한 반복적인 작업 절차다.
- 일반적인 순서는 다음과 같다.
1. 저장소를 로컬에 `clone`
2. 작업용 브랜치 생성
3. 코드나 문서 수정
4. 변경 사항 커밋
5. GitHub에 `push`
6. 풀 리퀘스트 생성
7. 검토와 승인 후 병합
- 기능별로 브랜치를 분리하면 기존 코드에 직접 영향을 주지 않고 독립적으로 작업할 수 있다.
- 풀 리퀘스트를 통해 동료가 변경 내용을 검토하고, 테스트 결과나 새로운 동작을 확인한 뒤 병합할 수 있다.
- 예를 들어 공유 AI 프롬프트를 수정할 때도 별도 브랜치에서 변경하고, 풀 리퀘스트로 결과를 검토한 후 병합하면 팀 전체가 개선된 프롬프트를 사용할 수 있다.
처음에는 모든 Git 명령어를 외우기보다 `status → add → commit → push` 흐름과 브랜치·풀 리퀘스트 과정을 반복해 익히는 것이 좋다. 또한 2FA를 설정하고, README와 `.gitignore`를 갖춘 저장소를 만들어 작은 프로젝트부터 GitHub Flow를 연습하면 협업과 오픈소스 참여로 자연스럽게 확장할 수 있다.
Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 보안 프로그램을 이끌고 있습니다. 주요 업무는 취약점 관리, 보안 개발 수명주기(SDL) 도구, 개발자 중심의 보안 자동화이며, 조직이 안전한 선택을 쉽게 할 수 있는 시스템을 구축하는 데 집중합니다.
### 대규모 보안 프로그램 운영
- GitHub에서 대규모 보안 프로그램을 주도합니다.
- 다양한 팀과 시스템에 적용할 수 있는 확장성 높은 보안 체계를 구축합니다.
### 주요 전문 분야
- **취약점 관리:** 보안 취약점을 식별하고 추적·개선하는 프로세스
- **보안 개발 수명주기 도구:** 개발 과정 전반에 보안을 통합하는 도구와 체계
- **보안 자동화:** 개발자의 업무 흐름 속에서 보안 조치를 자동화하는 기술
### 개발자 중심의 보안 철학
- 보안을 별도의 부담으로 만들기보다 개발자가 자연스럽게 따를 수 있도록 설계합니다.
- “안전한 선택이 가장 쉬운 선택”이 되도록 시스템과 자동화 기능을 구축합니다.
- 대규모 환경에서도 일관되게 작동하는 실용적인 보안 솔루션을 지향합니다.
Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 취약점 관리와 보안 개발 생명주기 도구를 이끌고 있다. 개발자가 보안상 올바른 선택을 쉽게 할 수 있도록, 대규모 환경에서 작동하는 보안 시스템과 자동화 기술을 구축해 온 전문가다.
### GitHub에서의 역할
- GitHub의 대규모 보안 프로그램을 주도한다.
- 주요 업무는 다음과 같다.
- 취약점 관리
- 보안 개발 생명주기(SDLC) 도구
- 개발자 중심의 보안 자동화
### 전문성과 경력
- 대규모 시스템을 설계하고 운영한 경험을 보유하고 있다.
- 보안 프로세스를 개발자의 업무 흐름에 자연스럽게 통합하는 데 집중한다.
- 조직이 보안을 별도의 부담으로 느끼기보다, 안전한 선택을 쉽게 실행하도록 만드는 것을 목표로 한다.
제공된 내용은 기술 블로그 본문이 아니라 저자 소개에 해당하므로, 특정 기술이나 구현 방법에 대한 추가적인 요약은 어렵다.
Madison Ficorilli는 취약점 투명성 분야의 전문가로, GitHub에서 보안 관리자로 활동하며 자문 데이터베이스 큐레이션 팀을 이끌고 있습니다. 취약점 신고·대응·공개에 깊이 관여하며, OpenSSF와 CVE 프로그램에서도 관련 표준과 생태계 발전에 기여하고 있습니다. 그녀의 전문성은 GitHub와 카네기멜런대학교 SEI CERT에서의 사고 대응 및 취약점 조정 경험을 바탕으로 합니다.
### GitHub에서의 역할
- GitHub의 시니어 보안 관리자로 근무합니다.
- 보안 권고 데이터베이스의 큐레이션 팀을 이끌고 있습니다.
- 취약점 정보가 정확하고 일관되게 정리·공개되도록 관리합니다.
### 취약점 투명성과 공개
- 취약점 신고, 대응, 공개 절차의 개선을 주요 관심사로 삼고 있습니다.
- 보안 취약점 정보를 투명하게 공유해 사용자와 오픈소스 생태계가 효과적으로 대응하도록 돕습니다.
- 관련 오픈소스 보안 커뮤니티에서 협업과 표준화에 참여합니다.
### 오픈소스 및 CVE 생태계 기여
- Open Source Security Foundation(OpenSSF)의 관련 워킹 그룹 공동 의장으로 활동합니다.
- CVE 프로그램 이사회 구성원으로서 취약점 식별자와 공개 체계의 발전에 관여합니다.
- 기술적 대응뿐 아니라 취약점 관리 정책과 거버넌스에도 기여합니다.
### 이전 경력과 전문성
- GitHub에서 제품 사고 대응 분석가로 일하며 보안 사고 대응 경험을 쌓았습니다.
- 카네기멜런대학교 소프트웨어공학연구소(SEI)의 CERT Coordination Center에서 취약점 조정 업무를 담당했습니다.
- 이러한 경험을 통해 취약점 발견부터 조정, 대응, 공개까지 전 과정을 이해하고 있습니다.
그녀의 경력은 개별 기업의 보안 대응과 국제적인 취약점 공개 체계를 연결하는 데 초점을 둡니다.ીએમ
GitHub의 Arthur Searle은 회사의 핸들 중심 문화와 원격 근무 환경, 성별 확정 의료 지원 덕분에 직장에서 비교적 안전하고 자연스럽게 트랜지션할 수 있었다고 말합니다. 이름·대명사 변경 과정의 행정적 마찰은 있었지만, 동료들의 존중과 지지를 통해 자신의 정체성으로 일하는 기쁨을 경험했습니다. 이 글은 트랜스젠더 구성원이 직장에서 겪는 어려움뿐 아니라, 포용적인 환경이 만들어내는 안도감과 기쁨도 함께 보여줍니다.
## IT 지원에서 보안 엔지니어로
- Arthur는 IT 지원과 운영 업무로 커리어를 시작한 뒤, 독학으로 코딩을 배웠습니다.
- 동료의 추천으로 GitHub에 입사해 IT Engineering 팀에서 근무했습니다.
- 보안 관련 문제와 풀 리퀘스트를 여러 보안 팀에 지속적으로 제기한 결과, 6개월 만에 Enterprise Security 팀으로 이동했습니다.
- 주요 SaaS 플랫폼의 인프라를 코드로 이전하는 작업에 참여했고, 옥스퍼드대학교에서 버전 관리 관련 강연도 진행했습니다.
## 핸들 중심 문화가 만든 정체성의 연속성
- 입사 당시 법적 이름은 Ursula였지만, 온라인 핸들은 계속 `gleeblezoid`였습니다.
- GitHub의 원격 중심 문화에서는 실명보다 핸들을 자주 사용하기 때문에, 이름을 바꾸더라도 기존의 업무 정체성과 관계를 유지하기 쉬웠습니다.
- 다른 회사처럼 모든 사람이 외모와 실명만으로 서로를 식별하는 환경이었다면 트랜지션 과정이 더 어려웠을 것이라고 설명합니다.
- 내부 시스템에서 이름과 대명사를 업데이트한 뒤, 대부분의 동료가 자연스럽게 새 이름을 사용했습니다.
## 의료 지원과 원격 근무의 장점
- GitHub는 직원 모두에게 성별 확정 의료와 관련된 복지 혜택을 제공합니다.
- Arthur는 해당 혜택으로 다음과 같은 비용을 지원받을 수 있었다고 말합니다.
- 음성 훈련
- HRT 처방약
- 상담 및 치료
- 원격 근무 덕분에 출근 복장이나 이동 중 다른 사람의 시선에 대해 걱정할 필요가 적었습니다.
- 업무 소통 대부분이 Slack과 GitHub에 글로 남기 때문에, 음성 훈련이나 HRT로 목소리가 변하는 시기에 하루 종일 직접 말해야 하는 부담도 줄었습니다.
- 만화 캐릭터 아바타처럼 외모와 성별 표현에서 자유로운 문화 역시 불필요한 추측과 판단을 줄였습니다.
## 직장에서 트랜스젠더로 살아가는 현실
- Arthur는 직장에서 커밍아웃하지 못하거나, 이름 변경 과정에서 행정적 문제를 겪는 트랜스젠더 동료들을 알고 있다고 말합니다.
- 새로운 사람을 만날 때마다 자신의 정체성을 반복해서 설명해야 하는 경우도 있습니다.
- 본인은 급여 시스템 등에서 법적 이름을 바꾸는 행정 절차를 제외하면 비교적 순조롭게 트랜지션할 수 있었습니다.
- 동료들은 그를 특별히 다르게 대하지 않고, 원하는 이름과 대명사를 사용하며 일반적인 동료로 존중했습니다.
## 지지와 긍정적인 감정
- 트랜스젠더로 살아가는 일이 항상 쉽거나 사회적으로 받아들여지는 것은 아니지만, 경험이 고난만으로 정의되는 것은 아니라고 강조합니다.
- 직장에서 처음 자신의 이름을 듣고 남성 대명사로 불렸을 때 큰 감동을 느꼈습니다.
- 한 동료가 면도 키트를 보내준 일처럼, 동료들의 작은 배려가 강한 소속감과 기쁨을 만들었습니다.
- 동료들은 Arthur와 관련된 농담과 밈을 공유하며 그의 트랜지션을 진심으로 축하하고 지지했습니다.
- 그는 “항상 남성이었지만, 남성으로 살아가고 사회에 참여할 시간과 지원이 필요했다”고 말하며 글을 마무리합니다.
기업이 트랜스젠더 구성원을 지원하려면 의료비 보장뿐 아니라 이름·대명사 변경 절차, 원격·비동기 소통, 외모에 대한 판단을 줄이는 문화까지 함께 마련해야 합니다. 궁극적으로 중요한 것은 트랜지션을 특별한 사건으로만 다루지 않고, 구성원이 원하는 정체성으로 존중받으며 평범하게 일할 수 있도록 하는 것입니다.
코딩 속도보다 더 큰 병목은 Jira, Figma, Confluence, Slack, Git 등에 흩어진 정보를 모으고 조정하는 비용입니다. 글은 LLM을 단발성 프롬프트 도구가 아니라 반복 가능한 개발 워크플로의 실행 엔진으로 활용해야 한다고 주장합니다. 이를 통해 구현 전 요구 사항을 통합하고, 불확실성을 드러내며, 구현 후 검증까지 자동화하는 오케스트레이션 중심의 프런트엔드 개발이 가능해집니다.
## 프런트엔드 개발의 병목 변화
- 하나의 기능을 구현하려면 여러 시스템을 오가야 합니다.
- 요구 사항: Jira
- 디자인: Figma
- 기술·정책 문서: Confluence
- 의사결정과 논의: Slack
- 구현과 검증: Git
- 프런트엔드 개발자는 이 정보를 통합해 실제 사용 가능한 결과물로 조립하는 역할을 담당합니다.
- 주요 부담은 코드를 작성하는 일보다 다음과 같은 컨텍스트 작업에 있습니다.
- 티켓과 디자인 분석
- 에지 케이스 확인
- 제품·백엔드 팀과의 동기화
- 기존 코드와 재사용 가능한 구성 요소 탐색
## 프롬프트에서 반복 가능한 워크플로로
- 단발성 프롬프트는 한 번의 작업에는 유용하지만, 반복성과 누적 효과가 부족합니다.
- 워크플로는 입력부터 출력까지의 표준화된 경로입니다.
- 여러 시스템에서 관련 컨텍스트 수집
- 요구 사항 요약
- 모호하거나 충돌하는 내용 식별
- 구현 계획과 파일 목록 제안
- 사람이 검토한 뒤 코드 수정 진행
- 이 구조에서 LLM은 단순히 코드를 생성하는 도구가 아니라 워크플로를 실행하는 엔진입니다.
- 한 번 구축한 워크플로는 티켓의 내용이 달라져도 동일한 패턴으로 적용할 수 있어 확장성이 높습니다.
## 연결된 개발 컨텍스트와 Noah MCP
- LY Corporation의 Noah MCP는 Jira, Confluence, Slack, GitHub 같은 내부 도구를 연결합니다.
- AI 에이전트가 사람이 복사해 붙여넣은 정보가 아니라 실제 업무 시스템에 존재하는 컨텍스트를 직접 읽고 추론할 수 있게 합니다.
- 이를 통해 개발자는 각 시스템을 수동으로 방문하고 정보를 노트에 조합하는 작업을 줄일 수 있습니다.
- 핵심은 AI를 별도의 도구로 사용하는 것이 아니라 기존 업무 흐름 안에 배치하는 것입니다.
## 구현 전 요구 사항 통합
예시 기능은 검색·필터·정렬과 역할 기반 필터 표시가 있는 목록 페이지입니다. 기존 방식에서는 개발자가 Jira, Figma, Confluence, Slack, 코드베이스를 직접 확인한 뒤 계획을 작성합니다.
워크플로 기반 방식에서는 에이전트에게 다음을 요청합니다.
- Jira 티켓 분석
- 관련 Confluence 문서 검색
- Slack의 최근 의사결정 확인
- 유사한 코드 구현 탐색
- 코드 수정 없이 다음 결과 반환
- 요구 사항 요약
- 프런트엔드 영향 범위
- 관련 파일
- 구현 체크리스트
- 테스트 체크리스트
- 미해결 질문
에이전트가 도출한 계획에는 다음과 같은 구체적인 정보가 포함됩니다.
- `FeatureListPage.tsx`, `FeatureList.tsx` 등 신규 파일
- 기존 `useTableFilters`, `useUrlState` 훅의 재사용
- `GET /api/<feature>`의 기존 페이지네이션 API 활용
- 역할별 필터 표시
- viewer: 검색, 상태 필터, 날짜 범위
- editor: owner 필터 추가
- admin: 내부 전용 플래그 추가
- 필터·정렬·페이지 상태를 URL 파라미터와 동기화
- 로딩, 빈 결과, 검색 결과 없음 상태 구현
## 숨겨진 요구 사항과 재작업 방지
- Slack 논의에서 필터 상태를 `localStorage`가 아니라 URL에 저장해야 한다는 결정이 발견됩니다.
- URL 공유가 가능해지고
- 새로고침 후에도 상태가 유지되며
- 다른 사용자가 동일한 화면을 재현할 수 있습니다.
- 코드베이스 검색을 통해 이미 존재하는 훅을 재사용할 수 있습니다.
- 불필요한 중복 구현 방지
- 기존 동작과의 일관성 유지
- 개발 시간 단축
- 구현 전에 다음과 같은 미해결 사항도 드러납니다.
- 필터·정렬 상태를 URL에 저장할지 여부
- 빈 상태에서 “필터 초기화” 버튼을 제공할지 여부
- 이런 문제를 PR 리뷰 단계가 아니라 구현 전에 발견하면 재작업 가능성을 줄일 수 있습니다.
## 코딩 이후의 폐쇄 루프 검증
워크플로는 코드 생성에서 끝나지 않고 검증 단계까지 포함해야 합니다.
- 구현 후 원래 계획과 실제 변경 사항을 대조합니다.
- 자동 검증 항목을 실행합니다.
- 타입 검사
- 린트
- 관련 단위 테스트
- 스모크 테스트 또는 로컬 검증 흐름
- 에이전트는 다음 결과를 보고합니다.
- 통과한 검사
- 실패 후 수정한 문제
- 자동화하지 못한 검증
- UI 상태별 스크린샷이나 확인 메모
- PR 전 남은 위험 요소
- 이 폐쇄 루프를 통해 계획, 구현, 검증이 하나의 연속된 개발 사이클이 됩니다.
## 실용적인 적용 방향
프런트엔드 팀은 먼저 Jira·문서·메신저·코드 검색을 묶은 “구현 전 분석 워크플로”부터 도입하는 것이 좋습니다. 이후 구현 계획 승인, 코드 수정, 자동 테스트, PR 전 검증을 단계적으로 연결하면 단순한 코드 생성보다 재작업 감소와 품질 향상이라는 더 큰 효과를 얻을 수 있습니다.
Figma는 코드 레이어를 통해 실행 가능한 코드를 디자인 캔버스 안에서 생성·비교·수정할 수 있도록 한다. 디자이너와 개발자는 코드와 디자인을 오가는 대신 같은 Figma 파일에서 아이디어를 함께 탐색하고, 팀의 피드백을 반영하며, 최종 코드를 저장소에 반영할 수 있다. 코드 레이어는 디자인과 개발의 경계를 좁혀 협업 중심의 프로토타이핑을 가능하게 하는 기능이다.
## 캔버스에서 코드 시작하기
- Figma Design의 툴바에서 코드 레이어를 추가하거나, 기존 프레임을 코드로 변환할 수 있다.
- Figma Agent에게 원하는 결과를 설명해 코드를 생성할 수도 있다.
- 템플릿에서 시작하거나 직접 만들고 싶은 내용을 프롬프트로 입력할 수 있다.
- GitHub 저장소를 가져오거나 로컬 폴더를 업로드해 기존 코드베이스를 불러올 수 있다.
- Figma Make에서 생성·수정한 코드도 캔버스의 코드 레이어로 가져와 팀과 공유할 수 있다.
## 여러 대안을 나란히 비교하기
- 기존 프레임을 복제해 여러 디자인 방향을 시험하듯 코드 레이어도 복제해 대안을 만들 수 있다.
- 실제로 작동하는 화면을 캔버스에서 비교하므로 정적인 시안만 볼 때보다 사용 경험을 구체적으로 평가할 수 있다.
- 요소를 이동·조정·리사이즈하면 코드에 즉시 반영된다.
- 프롬프트로 새 버전을 생성하면서도 기존 버전은 보존할 수 있다.
- 팀원은 공유 파일 안에서 댓글을 남기거나 동일한 코드 레이어를 대상으로 Agent에 추가 작업을 요청할 수 있다.
## 코드와 디자인 레이어 오가기
- `Extract designs` 기능을 사용하면 코드의 현재 상태를 편집 가능한 Figma 레이어로 변환할 수 있다.
- 전체 화면뿐 아니라 특정 화면, 상태, 사용자 플로우만 선택해 캔버스로 가져올 수 있다.
- 코드로 구현된 인터랙션과 상태를 시각적으로 분석하고, 일반적인 Figma 디자인 요소처럼 편집할 수 있다.
- 캔버스에서 수정한 내용은 한 번의 클릭으로 코드 레이어에 업데이트할 수 있어 디자인과 구현 사이의 반복 작업이 짧아진다.
## 코드 편집과 저장소 반영
- 코드 에디터에서 원하는 변경 사항을 주석이나 설명으로 작성하고 Agent에게 수정을 요청할 수 있다.
- 필요하면 개발자가 직접 코드를 편집할 수도 있다.
- 수정 결과를 다시 코드 레이어로 변환해 팀에 공유할 수 있다.
- 최종적으로 확정한 변경 사항은 저장소에 push해 실제 소스 코드에 반영할 수 있다.
- 따라서 Figma 캔버스는 단순한 시각화 공간이 아니라, 아이디어 탐색부터 코드 변경 및 공유까지 이어지는 협업 환경이 된다.
## 출시 계획
- 코드 레이어는 2026년 6월 기준 향후 몇 주 동안 비공개 베타로 제공될 예정이다.
- 초기 접근 권한은 Figma의 베타 신청 페이지를 통해 요청할 수 있다.
- 기능 세부 사항과 Config에서 발표된 다른 업데이트는 Figma Help Center와 Figma Learn에서 확인할 수 있다.
실무에서는 코드 레이어를 최종 구현을 자동화하는 도구라기보다, 디자인·개발팀이 여러 구현안을 빠르게 실험하고 합의하는 공동 프로토타이핑 환경으로 활용하는 것이 적합하다. 특히 기존 코드베이스를 불러와 실제 동작을 검토한 뒤 디자인과 코드를 반복적으로 조정하는 워크플로에 유용하다.
Ashley Willis는 GitHub의 개발자 관계 부문을 이끄는 수석 디렉터로, 오픈소스와 개발자 커뮤니티를 중심으로 활동하고 있습니다. 기술을 더 인간적으로 만들고, 기여자를 지원하며, 소외된 목소리를 대변하는 리더십을 강조합니다. 또한 접근성과 회복력 있는 팀 구축을 통해 실제 사용자에게 도움이 되는 도구와 환경을 만드는 데 집중합니다.
### 개발자 관계와 오픈소스 리더십
- GitHub에서 개발자 관계(Developer Relations) 조직을 이끕니다.
- 오픈소스 생태계와 커뮤니티에 대한 깊은 관심을 바탕으로 활동합니다.
- 개발자의 참여와 기여를 촉진하는 환경을 만드는 데 주력합니다.
### 커뮤니티와 기여자 지원
- 기술을 사용하는 사람들의 경험을 중심에 둔 활동을 펼칩니다.
- 오픈소스 기여자를 지원하고, 다양한 개발자들의 목소리를 확대합니다.
- 기술 커뮤니티가 더 포용적이고 지속 가능하게 성장하도록 돕습니다.
### 포용성, 접근성, 팀의 회복력
- 소외되거나 충분히 대표되지 못한 집단의 목소리를 강조합니다.
- 누구나 사용할 수 있는 접근성 높은 도구와 공간을 만드는 데 관심을 둡니다.
- 변화와 어려움에 대응할 수 있는 회복력 있는 팀 문화를 구축합니다.
### 기술을 더 인간적으로 만들기
- 리더십과 기술 옹호 활동을 사람 중심의 관점에서 결합합니다.
- 단순히 기능적인 도구를 넘어, 실제 사용자의 필요를 충족하는 기술을 지향합니다.
- 개발자와 커뮤니티를 배려하는 태도를 기술 조직 운영의 핵심 가치로 삼습니다.
결국 이 글은 Ashley Willis를 기술 전문성뿐 아니라 사람, 커뮤니티, 포용성을 중시하는 개발자 관계 리더로 소개합니다. 기술 조직은 제품 개발과 함께 기여자 지원, 접근성, 다양한 목소리의 반영도 함께 고려해야 한다는 점을 시사합니다.
Technical Writer(TW)는 문서를 작성·관리하는 역할을 넘어, 지식이 축적되고 활용되는 제품과 시스템을 만드는 제품 오너로 확장되고 있다. 토스의 문서 플랫폼 ‘토독’은 누구나 쉽게 문서를 작성하고, 조직의 지식을 한곳에 모으며, AI가 활용할 수 있도록 하는 것을 목표로 한다. 궁극적으로는 문서화가 별도 업무가 아니라 실제 업무 과정에서 자동으로 발생하고, 지식의 최신성과 품질까지 시스템이 관리하는 구조를 지향한다.
## TW가 제품을 만드는 이유
- TW는 어떤 문서가 읽기 어려운지, 좋은 문서의 조건이 무엇인지, AI가 잘 활용할 수 있는 문서 구조가 무엇인지 깊이 고민해 온 직무다.
- 이러한 전문성을 문서 작성에만 적용하지 않고, 문서와 지식 관리 제품의 설계 원칙으로 확장한다.
- 제품 오너로서 사용자 인터뷰, 제품 방향 설정, 로드맵·우선순위 결정, 기능 기획과 구현까지 직접 수행한다.
- 문서 요구사항을 개발팀에 전달하는 역할이 아니라, 제품의 문제를 정의하고 해결책을 만드는 메이커로 일한다.
## 기존 내부 문서의 문제점
- **높은 작성 장벽**
- 정적 사이트 생성기 기반 문서는 저장소 클론, 마크다운 작성, PR 생성과 리뷰 과정을 거쳐야 했다.
- 개발자에게는 익숙하지만 디자이너나 PM에게는 문서 작성 자체를 포기하게 만드는 장벽이 됐다.
- **낡고 불필요한 지식의 누적**
- 작성자와 작성 이유를 알 수 없는 메모, 변경된 정책을 설명하는 문서, 미완성 초안 등이 쌓였다.
- 문서의 양이 많아질수록 실제로 신뢰할 수 있는 지식을 판별하기 어려워졌다.
- **지식의 파편화**
- 문서가 SSG, 문서 도구, 코드, 메신저 대화, 개인의 기억 등에 흩어져 있었다.
- 지식이 한곳에 모이지 않으면 조직 차원의 축적과 재활용이 어려웠다.
## 토독의 핵심 가치
- **누구나 쉽게 문서 작성**
- 별도의 개발 과정 없이 문서를 만들고 수정할 수 있다.
- GitHub, 기존 문서 도구, 사내 메신저 등 다양한 출발점의 지식을 토독으로 연결할 수 있다.
- **AI를 통한 지식 활용**
- 토독의 문서를 팀별 봇과 연결할 수 있다.
- API, CLI, MCP를 제공해 요청 봇, 제품 스펙 관리 등 다양한 방식으로 활용할 수 있다.
- **단일 진실 공급원(SSoT)**
- 여러 곳에 흩어진 정보를 모아 완결된 문서로 구성한다.
- 어떤 지식이 최신이고 유효한지 한곳에서 확인할 수 있게 한다.
- **확장 가능한 플랫폼**
- 조직이나 팀마다 별도 도구를 선택하고 인프라를 구축할 필요가 없다.
- 하나의 플랫폼 안에서 각 팀이 독립적인 문서 공간을 운영할 수 있으며, 계열사로도 확장할 수 있다.
## 문서 품질을 자동으로 관리하기
- 문서 작성 장벽을 낮추면 문서 수는 늘지만 품질이 떨어질 수 있다.
- 기존에는 TW가 직접 문서를 리뷰하고 낡은 문서를 찾아 수정했다.
- 토독은 TW가 정의한 ‘좋은 문서’의 기준을 다음 기능으로 전환하고 있다.
- AI 교정 기능
- 문서 봇을 통한 초안 작성
- 자동 리뷰와 개선점 제안
- 다만 사용자가 직접 문서를 작성해야 한다는 전제만으로는 충분하지 않다고 판단했다.
## 업무 과정에서 자동으로 생성되는 문서
- 문서화를 별도의 업무로 요구하기보다, 일하는 과정에서 자연스럽게 문서가 생성되도록 한다.
- 사내 메신저의 의사결정과 논의, 코드 변경 내역 등을 자동으로 문서화한다.
- 코드 변경이나 의사결정 이후의 논의를 모니터링해 문서가 계속 갱신되도록 설계한다.
- 단순히 정보를 수집하는 데 그치지 않고 다음을 판단하는 것이 목표다.
- 정책과 실제 코드가 일치하는가
- 해당 지식이 실제 업무에서 사용되고 있는가
- 문서가 얼마나 최신 상태인가
- 현재도 유효한 지식인가
## TW 전문성의 시스템화
- 좋은 문서를 직접 쓰는 능력에서, 좋은 문서가 반복해서 생산되도록 시스템을 설계하는 능력으로 중심이 이동한다.
- 문서가 읽히지 않는 이유에 대한 경험은 누구나 쉽게 쓰고 AI도 잘 읽는 문서 기준으로 전환된다.
- 좋은 문서에 대한 판단은 AI 교정과 자동 리뷰의 기준이 된다.
- 낡은 문서를 식별하고 유효성을 판단하는 역량은 지식 신선도와 신뢰도를 관리하는 시스템으로 구현된다.
- TW의 역할은 다음과 같이 정리된다.
- 흩어진 지식이 모일 장소를 만든다.
- 좋은 문서의 기준을 정의한다.
- 사람의 판단을 시스템에 반영한다.
- 업무 과정에서 문서가 자연스럽게 만들어지게 한다.
- 축적된 지식이 스스로 갱신되도록 한다.
## 지향하는 업무 환경
- 시스템이 오래된 문서를 감지해 담당자에게 알리고 개선안을 제안한다.
- 프로젝트 관리 도구를 별도로 갱신하지 않아도 업무 과정의 기록이 자동으로 정리된다.
- 릴리즈 공지와 반복적인 문의 답변이 지식으로 남아 신규 구성원의 학습 비용을 줄인다.
- 한 번의 업무가 조직 전체에서 재사용 가능한 흔적으로 남아 실행 시간을 단축한다.
- TW는 반복적인 문서 관리보다 제품의 방향과 지식 거버넌스 설계에 집중한다.
결국 토독의 목표는 문서를 잘 쓰게 만드는 데서 끝나지 않는다. 조직의 업무 흐름 자체가 신뢰할 수 있는 지식을 만들고 갱신하도록 설계하는 것이 핵심이며, 이는 TW의 전문성을 조직 전체의 시스템으로 확장하는 방식이다.
AWS DevOps Agent에 코드 변경사항을 운영 배포 전에 검토하고 자동으로 테스트하는 릴리스 관리 기능이 프리뷰로 추가되었습니다. 에이전트는 조직의 자연어 기준, 의존성 안전성, 접근 제어, 운영 환경 요구사항을 검토하고 변경사항에 맞는 테스트를 생성·실행합니다. 이를 통해 AI가 생성한 코드 증가로 발생한 리뷰 병목과 운영 환경과 테스트 환경의 차이를 줄이고, 코드 작성부터 배포까지 자동화 수준을 높일 수 있습니다.
## AI 코드 증가로 인한 리뷰와 테스트 병목
- AI 코딩 도구 확산으로 풀 리퀘스트 수가 리뷰·테스트 역량보다 빠르게 증가하고 있습니다.
- 일정 압박 때문에 사람이 코드를 충분히 검토하지 못한 채 승인하는 문제가 발생합니다.
- 테스트 환경이 운영 환경과 달라 실제 배포 후에야 문제가 발견될 수 있습니다.
- AI 모델은 사람이 시간 압박 속에서 놓치기 쉬운 기능 및 보안 문제를 탐지할 수 있어, 빠르면서도 안전한 배포가 중요해졌습니다.
## 릴리스 준비성 검토
- 모든 코드 변경사항을 다음 기준으로 분석합니다.
- 운영 환경 요구사항
- 서비스 및 리포지터리 간 의존성 안전성
- 사용자가 정의한 내부 표준과 모범 사례
- AWS Well-Architected Framework에 따른 접근 제어 변경사항
- 여러 리포지터리의 의존성을 분석해 한 서비스의 변경이 다른 서비스에 미칠 영향을 확인합니다.
- 별도의 기준을 지정하지 않으면 일반적인 모범 사례를 적용합니다.
- AWS가 관리하는 격리 환경에서 애플리케이션을 실행하고 다음을 확인합니다.
- 빌드 성공 여부
- 애플리케이션 실행 가능 여부
- 기본적인 사용자 여정과 기능 동작
- 분석 결과는 AWS DevOps Agent 콘솔과 GitHub·GitLab 풀 리퀘스트 댓글에 표시됩니다.
- Kiro power 또는 Claude Code 플러그인을 통해 커밋 전에 IDE에서 직접 검토를 실행할 수도 있습니다.
## 조직별 자연어 기준 설정
- AWS DevOps Agent 콘솔에서 `Knowledge` → `Instructions`로 이동해 검토 기준을 편집합니다.
- `Release readiness review`에 특정 작업용 지침을 추가할 수 있습니다.
- 일반 영어 문장으로 다음과 같은 내부 기준을 정의할 수 있습니다.
- 암호화 및 네트워크 접근 규칙
- 로깅과 관측 가능성 요구사항
- 민감 데이터 분류 및 고위험 리소스 식별
- 차단하지 않고 경고만 해야 하는 기준
- 모든 에이전트에 공통 기준을 적용하려면 `All agents` 지침을 수정합니다.
## 자동 릴리스 테스트
- 웹 애플리케이션과 API 애플리케이션을 대상으로 변경사항에 특화된 테스트 계획을 자동 생성합니다.
- 정적인 테스트 스위트를 반복 실행하는 대신, 변경 내용과 영향 범위를 분석해 테스트를 구성합니다.
- 다음 유형의 문제를 검증합니다.
- 기능적 정확성
- 기존 동작의 회귀
- 서비스 간 통합 문제
- 수동 테스트 계획에서 누락될 수 있는 시나리오
- 고객이 제공한 운영 유사 환경에서 병합 전에 테스트를 실행합니다.
- 각 실행 결과에는 다음 구조화된 산출물이 포함됩니다.
- 메트릭
- 로그
- 트레이스
- 테스트 실행 요약
## 검토 실행 방법
- 먼저 GitHub 또는 GitLab 리포지터리를 Agent Space에 연결해야 합니다.
- 연결된 코드는 인덱싱되며, 리포지터리와 클라우드 리소스 간 의존성을 나타내는 지식 그래프가 생성됩니다.
- 웹 앱에서 Agent Space를 선택한 뒤 `Web app` 탭과 `Operator access`를 선택합니다.
- 릴리스 준비성 검토는 다음 방식으로 실행할 수 있습니다.
- 연결된 리포지터리에 풀 리퀘스트 제출
- 채팅에서 온디맨드 요청 실행
- 채팅에서는 다음과 같이 요청할 수 있습니다.
```text
Perform a production risk analysis on my repository branch
```
- 이후 분석할 리포지터리와 브랜치를 지정합니다.
- 브랜치 이름, 풀 리퀘스트 번호, 커밋 SHA를 기준으로 분석할 수 있습니다.
- 인프라 영향, 설정 변경, 배포 시 발생 가능한 위험을 종합적으로 검토합니다.
- 완료 후 후속 질문을 통해 특정 변경사항의 하위 소비자, 영향받는 파일과 줄 번호, 해결 방법을 추가로 확인할 수 있습니다.
## 검토 결과와 보고서
- `Changes` 메뉴의 `Proposed changes` 표에서 실행된 검토를 확인할 수 있습니다.
- 카테고리와 상태로 필터링하거나 이름으로 검색할 수 있습니다.
- `Timeline` 탭에서는 에이전트가 호출한 도구, 참고한 의존성, 각 단계의 관찰 내용을 시간순으로 확인할 수 있습니다.
- `Report` 탭에는 다음 정보가 제공됩니다.
- 최종 권고 조치
- 발견된 심각한 문제 수
- 커밋 리비전
- 변경된 파일 수
- 권고 조치는 다음 세 가지 중 하나입니다.
- `BLOCK`
- `Proceed with Caution`
- `Safe to Release`
- 보고서의 주요 구성은 다음과 같습니다.
- `Analysis`: 권고 조치의 근거와 발견된 위험
- `Issues`: 심각도별 문제 목록
- `Recommendations`: 문제 해결을 위한 구체적인 조치
- `Changes`: 변경된 파일, 변경 유형, 분류, 변경 내용
AWS DevOps Agent의 릴리스 관리 기능은 사람의 리뷰를 완전히 대체하기보다는, AI 생성 코드가 늘어난 환경에서 반복적인 위험 분석과 변경별 테스트를 자동화하는 보조 수단으로 활용하는 것이 적절합니다. 우선 내부 보안·운영 기준을 자연어 지침으로 명확히 정의하고, 풀 리퀘스트 단계에서 릴리스 준비성 검토를 실행한 뒤 운영 유사 환경의 자동 테스트를 병행하는 방식을 권장합니다.
