67단계개발팀 저장소를 경영의 말로 읽기
개발팀의 변경 기록이 쌓이는 저장소를 경영의 말로 읽게 한다.
걸리는 시간 · 읽기 약 5분 · 따라 하기 약 30분 · 난이도 ★★☆ 실무 · 처음엔 건너뛰어도 되는 단계 · 화면 확인 2026.09.27
이 단계를 마치면
- 저장소, 커밋, 이슈, Pull Request가 각각 무엇인지 경영의 말로 설명할 수 있다.
- GitHub를 연결해, 지난주 개발 변경을 "고객에게 보이는 것"과 "안 보이는 것"으로 나눈 표를 받는다.
- 개발팀과 대화할 때 쓸 개발 용어 단어장을 시작한다.
"이번 주 개발팀은 뭘 바꿨나요?" 이 질문에 "버그 수정 몇 건이요"라는 답이 돌아온다면, 그 몇 건 안에 무엇이 들어 있었는지 리더로서는 알 길이 없다. GitHub는 개발자의 도구로 알려져 있지만 리더에게도 쓸모가 크다. 개발팀이 이번 주에 무엇을 바꿨는지, 어떤 요청이 밀려 있는지가 모두 저장소에 기록되어 있기 때문이다. 문제는 그 기록이 코드와 개발자의 언어로 쓰여 있다는 것이다. Claude를 GitHub에 연결하면 그 기록을 경영의 언어로 옮겨 읽을 수 있다.
리더가 왜 저장소를 읽어야 하나
개발팀의 보고는 대개 개발팀이 정리한 말로 올라온다. 정리에는 정리한 사람의 시선이 들어간다. 바쁜 사람은 "이번 주 버그 수정 몇 건"으로 뭉뚱그리고, 그 안에 결제 화면의 문구 변경처럼 영업팀이 알아야 할 것이 섞여 있어도 드러나지 않는다. 저장소는 가공되기 전의 기록이다. 리더가 직접 읽는다고 개발팀을 감시하게 되지는 않는다. 오히려 같은 기록을 놓고 대화하게 된다. 질문이 "이번 주 뭐 했어요?"에서 "결제 화면 문구가 바뀌었던데 고객센터에 알렸나요?"로 달라진다.
칼럼에서 읽기 「[AX CEO가이드] 회계장부 보듯이, 코드장부도 봐야 한다」
“경영자가 회계 숫자를 직접 읽지 않으면 분식을 당하듯, 코드를 '개발팀 블랙박스'로 방치하면 회사의 가장 큰 리스크를 스스로 보지 못하는 상태가 된다.”
“코드 한 줄을 읽으라는 뜻이 아니다. 회계를 모르는 경영자도 재무제표의 핵심 지표는 읽어내듯, 코드를 몰라도 코드장부의 핵심 질문은 던질 수 있어야 한다는 뜻이다.”
「회계장부 보듯이, 코드장부도 봐야 한다」에서 말한 코드장부가 보관되는 곳이 저장소다. Claude를 GitHub에 연결해 합쳐진 변경과 오래 열린 이슈를 경영의 말로 옮겨 읽게 하면, 코드를 몰라도 그 장부에 질문을 던질 수 있다.
저장소를 읽기 위한 네 단어
| 개발 용어 | 경영의 말로 |
|---|---|
| 저장소(repository) | 한 제품의 코드와 그 변경 기록을 모아 둔 서류함 |
| 커밋(commit) | 한 번 저장한 변경. 누가, 언제, 무엇을 왜 바꿨는지 짧은 설명이 붙는다 |
| 이슈(issue) | 해야 할 일이나 고칠 문제를 적은 카드. 고객 불만이 여기로 들어오기도 한다 |
| Pull Request(PR) | "이 변경을 본 제품에 합쳐 주세요"라는 결재 요청. 검토와 승인을 거쳐 합쳐진다 |
이 네 단어만 알아도 저장소의 대부분이 읽힌다. 리더가 주로 볼 곳은 합쳐진 PR과 오래 열려 있는 이슈다.
연결과 범위
GitHub 연결자를 붙이면 Claude가 저장소의 파일, 변경 이력, 이슈, Pull Request를 읽는다. 이 단계에서는 읽기만 한다. 코드를 고치고 올리는 일은 제3부에서 익힌 Claude Code의 몫이다. 지금은 저장소가 어떻게 생겼는지 눈에 익히는 것이 목적이다.
회사 저장소는 기밀 덩어리다. 코드에는 제품의 노하우가, 설정 파일에는 때로 내부 주소가 들어 있다. 개인 계정으로 회사 저장소를 연결해도 사내 규칙에 어긋나지 않는지 먼저 확인한다. 허락 화면에서 "모든 저장소"와 "선택한 저장소"를 고를 수 있다면 선택한 저장소만 준다. 연습은 공개 저장소나 수업용 샘플 저장소로 한다.
전·후 비교
"이 저장소 분석해 줘"라고 하면 폴더 구조와 사용 언어에 대한 설명이 길게 나온다. 개발자에게는 쓸모가 있지만 리더에게는 읽을거리만 늘어난다. 리더에게 쓸모 있는 질문은 결정과 이어진다. "이번 주에 합쳐진 변경을 고객에게 영향이 있는 것과 없는 것으로 나눠 줘." "이 저장소는 무엇을 하는 프로그램인지 개발자가 아닌 사람에게 설명해 줘." "오래 열려 있는 이슈 가운데 고객 불만과 관련된 것을 골라 줘." 답을 받으면 모르는 용어는 바로 되묻는다. 제3부에서 Claude Code를 쓰며 어렴풋이 지나친 말들이 이렇게 하나씩 제 뜻을 찾는다.
직무별 변형
- 대표·임원: 월 단위로 "합쳐진 변경 가운데 매출이나 고객 경험에 닿는 것"만 본다.
- 영업·고객지원 리더: 주 단위로 "고객에게 보이는 변화"와 "고객 불만 이슈의 진행"을 본다. 고객 안내문 초안까지 받는다.
- 기획자: 기획 문서와 실제로 합쳐진 변경이 어긋나는 곳을 찾게 한다.
개발 출신이 아닌 한 이사가 이 방법으로 주간 회의를 어떻게 바꿨는지 보자.
현장 장면
물류 스타트업의 정 이사는 개발 출신이 아니다. 주간 회의에서 개발팀 보고를 들어도 무엇이 중요한지 가려내기 어려웠다. 고개는 끄덕였지만 절반쯤은 흘려듣기 일쑤였다. 처음에는 Claude에게 "지난주 커밋 정리해 줘"라고 입력했다. 커밋 수십 개가 하나하나 번역되어 나왔다. "리팩터링", "의존성 업데이트" 같은 말이 가득해 오히려 더 막막했다.
정 이사는 질문을 바꿨다. "지난주에 합쳐진 PR만 봐. 각각을 쉬운 말로 한 문장, 고객에게 보이는 변화인지 예/아니오, 영업팀이 알아야 하는지 표로." 표가 확 짧아졌다. 그중 한 항목이 눈에 들어왔다. "배송 추적 화면에서 예상 도착 시간 표시 방식 변경." 고객에게 보이는 변화였고, 영업팀이 대형 화주에게 설명해야 할 내용이었다.
아쉬운 점도 있었다. 표에는 "캐싱 로직 개선(속도 향상)"이 "고객에게 보이지 않음"으로 나와 있었다. 속도가 빨라지면 고객도 느낄 텐데, 정 이사는 고개를 갸웃했다. 되물었더니 Claude는 PR 설명만으로는 고객이 체감할지 알 수 없다고 답했다. 정 이사는 그것을 회의 질문 목록에 올렸다.
그 뒤로 회의가 달라졌다. 정 이사가 던지는 질문이 구체적으로 바뀌었고, 개발팀도 설명하는 수고가 줄었다고 했다. 정 이사는 모르는 용어를 되물을 때마다 뜻을 짧게 적어 두었다. 그 목록은 곧 개발팀과 함께 보는 단어장이 되었다.
따라 하기
- 사내 규칙을 확인한다. 연습용이면 공개 저장소 하나를 고른다. 성공 기준: 회사 저장소를 쓸지 공개 저장소를 쓸지를 규칙에 근거해 정했다.
- 설정의 연결자 항목에서 GitHub를 연결하고, 허락 화면에서 어느 저장소에 접근을 주는지 확인한다. 성공 기준: 필요한 저장소만 선택해 주었거나, 그럴 수 없음을 확인하고 적었다.
- 저장소 하나를 골라 "이 저장소가 무엇을 하는지 개발자가 아닌 사람에게 설명해 줘"라고 묻는다. 성공 기준: 세 문장 안팎의 설명을 내가 이해하고 남에게 다시 말할 수 있다.
- 아래 프롬프트로 최근 변경을 요약받는다. 성공 기준: 표의 모든 행에 "사용자에게 보이는 변화인가"가 채워져 있다.
- 답에 나온 낯선 용어 세 개를 골라 되묻고, 뜻을 짧게 적어 둔다. 성공 기준: 단어장에 용어 세 개가 생겼다.
복사해 쓰는 프롬프트
GitHub의 [저장소 이름] 저장소를 읽어 줘. 나는 개발자가 아니다.
1) 이 저장소가 무엇을 하는 프로그램인지 세 문장으로 설명해.
2) [기간] 동안 합쳐진 Pull Request를 아래 표로 정리해.
열: 변경 제목, 쉬운 말로 무엇이 바뀌었나, 사용자에게 보이는 변화인가(예/아니오/알 수 없음), 영업·지원팀이 알아야 하는가.
PR 설명만으로 판단할 수 없으면 "알 수 없음"이라고 쓰고, 개발팀에 물을 질문을 하나 붙여.
3) 열려 있는 이슈 가운데 오래된 것과 고객 불만과 관련된 것을 골라 줘.
코드 용어는 괄호 안에 쉬운 말을 붙여.
저장소에는 아무것도 쓰지 마. 이슈·댓글·변경 모두 만들지 마.
막히면 이렇게
| 증상 | 원인 | 처방 |
|---|---|---|
| 회사 저장소가 목록에 안 나온다 | 조직이 외부 앱 접근을 막았거나, 허락할 때 저장소를 고르지 않았다 | 허락 화면에서 고른 저장소를 다시 보고, 조직 관리자에게 묻는다(69단계) |
| 답이 개발 용어로 가득하다 | 독자가 누구인지 말하지 않았다 | "나는 개발자가 아니다"와 "괄호 안에 쉬운 말"을 넣는다 |
| 커밋이 너무 많아 요약이 길다 | 커밋 단위로 보고 있다 | 합쳐진 PR 단위로 보게 한다 |
스스로 점검
- ☐ 커밋과 Pull Request의 차이를 경영의 말로 설명할 수 있다.
- ☐ 합쳐진 변경 가운데 영업·지원팀에 알릴 것 하나를 찾았다.
- ☐ 단어장에 용어 세 개를 적었다.
점검 해설 보기
- 커밋은 한 번 저장한 변경이고 Pull Request는 "이 변경을 본 제품에 합쳐 주세요"라는 결재 요청이라는 차이를 경영의 말로 설명하면 통과다. 헷갈리면 「저장소를 읽기 위한 네 단어」 표를 다시 보고, 리더가 볼 단위가 왜 합쳐진 PR인지 「기억할 것」의 셋째 문장으로 확인한다.
- PR 요약 표에서 사용자에게 보이는 변화이면서 영업·지원팀이 알아야 할 항목 하나를 골라, 누구에게 무엇을 알릴지 적었으면 통과다. 표가 개발 용어로 가득하다면 「막히면 이렇게」대로 "나는 개발자가 아니다"와 "괄호 안에 쉬운 말"을 넣고, 커밋 대신 합쳐진 PR 단위로 다시 받는다.
- 답에서 낯선 용어 세 개를 골라 되묻고, 뜻을 짧게 적은 단어장이 있으면 통과다. 아직 없다면 「따라 하기」 5번을 하고, 「현장 장면」의 정 이사처럼 되물을 때마다 계속 더해 나간다.
기억할 것
- GitHub는 개발팀의 업무 일지다. 읽기만 해도 회의에서 던지는 질문이 달라진다.
- 회사 저장소를 연결하기 전에 사내 규칙을 확인한다. 연습은 공개 저장소로 한다.
- 리더에게 필요한 단위는 결재가 끝난 변경, 곧 합쳐진 PR이다. 커밋 하나하나까지 볼 필요는 없다.