55장. 개발 도구 연결 — GitHub · Jira · Database · Monitoring

54장에서 붙이기 전에 물을 것 다섯 개를 봤다.

이 장은 실제로 붙일 만한 것들이다.

기준은 하나다.

Agent가 그 정보를 못 봐서
우리가 매번 복사해 넣고 있는가.

1️⃣ 이슈 트래커

가장 효과가 확실하다.

20장에서 티켓을 Task로 변환했다.
그때 티켓 내용을 손으로 붙여넣었다.

@tickets/PAY-2841.md 를 읽고...   ← 미리 저장해둬야 함

연결하면 이렇게 된다.

PAY-2841 티켓을 읽고 작업 Task로 변환해줘.
댓글도 함께 확인해줘. 결정된 사항이 댓글에 있을 수 있어.

🔥 댓글이 핵심이다.

티켓 본문은 초기 요구사항이고,
실제 결정은 댓글에 흩어져 있다.

사람도 매번 스크롤해서 읽는 그것을
Agent가 읽고 정리한다.

권한은 읽기만 준다.

"allow": ["mcp__jira__get_issue", "mcp__jira__search_issues"],
"deny": ["mcp__jira__create_issue", "mcp__jira__update_issue"]

⚠️ 티켓 상태를 Agent가 바꾸게 하지 않는다.

“진행 중” 으로 바꾸는 것은 사람의 신호다.

2️⃣ GitHub / GitLab

두 가지 용도가 있다.

PR 리뷰 코멘트를 읽는다

PR #482 의 리뷰 코멘트를 읽고
지적된 것 중 아직 반영 안 된 것을 정리해줘.

리뷰어 세 명의 코멘트 스무 개를
빠짐없이 확인하는 일은 사람이 자주 놓친다.

PR 본문을 만든다

이 브랜치의 커밋들을 읽고 PR 설명 초안을 만들어줘.
- 무엇을 왜 바꿨는지
- 리뷰어가 중점적으로 볼 부분
- 테스트한 내용

⚠️ 생성까지는 시키되 머지는 막는다.

"allow": ["mcp__github__get_pull_request", "mcp__github__create_pull_request"],
"deny": ["mcp__github__merge_pull_request"]

머지는 사람이 누른다.
되돌리기 어려운 일이기 때문이다.

3️⃣ Database — 읽기 전용으로만

가장 유용하고 가장 위험하다.

27장에서 스키마를 엔티티로 파악했는데,
실제 DB를 보면 알 수 있는 것이 다르다.

orders 테이블의 status 컬럼에 실제로 어떤 값들이 있어?
각각 몇 건인지도.

status  | count
--------+--------
PAID    | 1,240,331
SHIPPED |   890,112
LEGACY_X|        12   ← 코드에 없는 값

🔥 마지막 줄 같은 발견이 이 연결의 가치다.

코드에는 없는 enum 값이 데이터에 남아 있다.
29장에서 말한 “코드로 알 수 없는 것” 이다.

인덱스 판단도 마찬가지다.

이 쿼리의 실행 계획을 확인해줘.
orders 테이블의 실제 행 수와 인덱스 목록도 함께.

27장에서 “로컬 데이터가 적어 실행 계획을 믿을 수 없다” 고 했다.
읽기 전용 연결이 그 문제를 푼다.

반드시 지킬 것

1. 읽기 전용 계정을 별도로 만든다
2. 운영이 아니라 리드 레플리카에 붙인다
3. 개인정보 컬럼은 계정 수준에서 차단한다
4. 쿼리 타임아웃과 행 수 제한을 건다

⚠️ 세 번째를 빠뜨리면
select * from users 한 번에 개인정보가 Context에 들어온다.

그리고 대화 기록에 남는다.

58장에서 이 문제를 자세히 다룬다.

4️⃣ 모니터링 · APM

33장의 장애 분석이 달라진다.

어제 14시부터 14시 30분 사이
주문 취소 API의 에러율과 p95 응답시간을 확인해줘.
평소와 비교해서.

사람이 대시보드를 열고 시간 범위를 맞추고
스크린샷을 찍어 붙여넣던 일이 사라진다.

트레이스가 있으면 더 강력하다.

traceId 8f3a91c2 의 전체 스팬을 가져와줘.
어느 구간에서 시간이 걸렸는지.

24장에서 만든 추적 ID가
여기서 제값을 한다.

5️⃣ 로그 시스템

14:00~14:30 사이 order-service 의 ERROR 로그를
메시지 패턴별로 묶어서 상위 10개만 보여줘.

⚠️ 여기서 12장의 함정이 다시 나온다.

로그를 통째로 가져오면 Context가 찬다.

# CLAUDE.md
- 로그 조회는 항상 집계하거나 상위 N건으로 제한한다
- 원문이 필요하면 특정 traceId 로 좁혀서 가져온다

연결하지 않는 것

⚠️ 다음은 붙이지 않는 편이 낫다.

마지막 줄이 농담처럼 보이지만
“전사 SaaS를 다 붙여보자” 는 시도가 실제로 있다.

기준은 54장과 같다.

지금 매번 복사해 넣고 있는가.
아니면 그냥 붙일 수 있어서 붙이는가.

권한 최소화 원칙

붙이는 모든 서버에 공통으로 적용한다.

읽기        기본 허용
생성        경우에 따라 (PR 본문, 코멘트)
수정        확인 후
삭제·실행   금지

그리고 토큰도 최소 권한으로 발급한다.

GitHub 토큰   repo:read, pull_request:write
DB 계정       특정 스키마 SELECT only
APM 토큰      읽기 전용 API 키

🔥 MCP 서버 설정에서 막는 것과
토큰 자체를 제한하는 것은 다른 층이다.

둘 다 한다.

설정은 실수로 풀릴 수 있지만
토큰 권한은 서버 쪽에서 강제된다.

이 장의 핵심

• 기준은 하나다 — 지금 매번 복사해 넣고 있는가
• 이슈 트래커에서 진짜 가치는 본문이 아니라 댓글에 흩어진 결정이다
• 티켓 상태 변경은 사람의 신호이므로 Agent에게 맡기지 않는다
• PR 생성은 시키되 머지는 막는다
• DB 읽기 연결로 코드에 없는 데이터의 실제 상태를 알 수 있다
• 읽기 전용 계정, 레플리카, 개인정보 컬럼 차단, 타임아웃이 전제다
• select * 한 번에 개인정보가 Context와 대화 기록에 남는다
• 모니터링을 붙이면 24장의 추적 ID가 제값을 한다
• 로그는 항상 집계하거나 상위 N건으로 제한한다
• 배포·결제·알림 발송은 붙이지 않는다
• MCP 설정 제한과 토큰 권한 제한은 다른 층이다 — 둘 다 한다