1. 자동화가 늘면 출입증도 늘어난다
팀 프로젝트에서 코드를 올리는 사람은 다섯 명인데, 외부 서비스에 접속하는 프로그램은 열 개일 수 있습니다. 배포 작업, 데이터 수집기, 알림 봇이 저마다 인증 정보를 사용하기 때문입니다. 사람이 퇴장했다고 프로그램의 접근 권한까지 사라지는 것은 아닙니다. 서비스가 커질수록 “누가 어떤 권한으로 접속할 수 있는가”를 데이터로 관리해야 하는 이유입니다.
GitHub는 2026년 9월 21일 Enterprise Cloud에서 기업의 자격 증명 목록을 내보내는 기능을 발표했습니다. 기업 소유자 또는 관련 조회 권한을 가진 사용자가 CSV와 REST API를 통해 목록을 확인할 수 있습니다. 일반 개인 저장소에 동일한 관리 기능이 제공된다는 뜻은 아닙니다. 이번 글에서는 이 소식을 출발점으로, 유료 기업 계정 없이도 가상 데이터로 만들 수 있는 권한 점검 대시보드를 설계합니다.
여기서 자격 증명은 프로그램이나 사용자가 자신을 증명할 때 쓰는 토큰과 키 등을 뜻합니다. 출입증 비유로 생각하면 소유자는 출입증을 받은 사람, 권한은 들어갈 수 있는 방, 만료일은 출입증 유효기간입니다. 목록을 만드는 일과 실제 출입을 차단하는 일은 서로 다른 작업입니다. 실습에서도 조회와 변경 기능을 구분해 설계합니다.
2. 비밀값과 관리용 메타데이터를 구분하자
토큰 원문은 요청을 인증하는 데 쓰이는 비밀값입니다. 반면 소유자, 생성 시점, 만료 상태 같은 메타데이터는 그 토큰을 관리하기 위한 설명입니다. 대시보드가 필요한 것은 대부분 후자입니다. 화면을 만들기 위해 비밀값까지 모으면 분석용 데이터베이스가 또 하나의 비밀 저장소가 되어 관리 부담이 커집니다.
GitHub 문서에 따르면 CSV에는 토큰 원문이 포함되지 않습니다. 또한 한 자격 증명이 여러 조직에 승인되어 있으면 여러 행으로 나타납니다. 빈칸은 정보가 없거나 해당하지 않음을 뜻하므로 “만료되지 않음”이나 “사용하지 않음”으로 일괄 해석하면 안 됩니다. 이 세 가지 특징만 알아도 처음 만드는 집계 화면의 흔한 오류를 피할 수 있습니다.
실습에서는 실제 계정 이름도 수집하지 않고 member-a, member-b 같은 가상 소유자를 사용하세요. 가상 식별자는 실습 안에서만 유일하게 정합니다. 실서비스의 모든 자격 증명 종류를 같은 식별 방식으로 처리할 수 있다고 가정하지 말고, 실제 연동을 확장할 때는 종류별 식별 규칙을 별도로 검토해야 합니다. 관리 정보 역시 조직의 구조를 드러낼 수 있으므로 공개 예제와 운영 자료를 섞지 않는 것이 좋습니다.
근거 자료 · GitHub Docs · 기업 자격 증명 목록 해석
3. 데이터 한 행이 무엇을 뜻하는지 먼저 정한다
아래 표는 직접 만든 가상 데이터입니다. cred-a는 두 조직에 승인된 하나의 자격 증명이고, cred-b는 다른 자격 증명입니다. 표의 행은 세 개지만 자격 증명은 두 개입니다. 세 행을 그대로 세어 “토큰 세 개”라고 보고하면 데이터 수집은 성공했어도 분석은 틀립니다. 데이터의 기본 단위, 즉 한 행이 나타내는 대상을 먼저 적어 두는 습관이 필요합니다.
SQL 설계에서는 credentials 테이블에 자격 증명 자체를, grants 테이블에 조직별 승인 관계를 저장하는 방법을 제안합니다. 하나의 자격 증명과 여러 승인 관계를 분리하면 소유자나 만료 정보를 매 행마다 반복하지 않아도 됩니다. 반대로 원본 CSV를 그대로 보관하는 staging 테이블도 남겨 두면 잘못 정제했을 때 원본과 비교할 수 있습니다.
대시보드에는 자격 증명 수와 승인 관계 수를 따로 표시하세요. 여기에 수집 시각을 붙여야 오래된 결과를 현재 상태로 오해하지 않습니다. 월요일에 두 개였던 목록이 수요일에 세 개가 되었더라도 신규 발급인지, 수집 범위가 넓어진 것인지 확인하기 전에는 위험 증가라고 단정할 수 없습니다.
| 가상 자격 증명 | 소유자 | 승인 조직 | 만료 상태 |
|---|---|---|---|
| cred-a | member-a | team-red | expires |
| cred-a | member-a | team-blue | expires |
| cred-b | member-b | team-red | unknown |
4. Python에서 SQL까지: 작은 처리 흐름 만들기
다음 흐름은 교육용 설계 예시입니다. 우선 가상 CSV를 읽고 필수 열을 확인합니다. 그다음 날짜를 일정한 형식으로 바꾸고, 승인 관계를 분리해 저장합니다. 변환 과정에서 원본 행 번호와 오류 이유를 남겨야 화면에서 이상한 값이 보였을 때 입력 자료까지 거슬러 올라갈 수 있습니다. 잘못된 날짜를 조용히 오늘 날짜로 바꾸는 처리는 피하세요.
Python에서는 csv 모듈로 파일을 읽고 datetime으로 시간값을 해석하는 연습을 할 수 있습니다. 시간대가 없는 값은 정책을 정해 거부하거나 별도 검토 대상으로 분류합니다. 데이터베이스에는 일관된 시간 기준으로 저장하고 화면에서 한국시간으로 표시하도록 역할을 나눕니다. 문자열을 잘라 월과 일만 비교하면 연도가 바뀔 때 잘못된 결과가 생길 수 있습니다.
아래 SQL은 앞 절에서 제안한 두 테이블에 대한 설계 예시이며 실제 운영 데이터에 실행한 결과가 아닙니다. COUNT(*)로 각 테이블의 서로 다른 대상을 셉니다. 대시보드 숫자가 달라도 오류가 아닐 수 있다는 점을 설명할 수 있어야 합니다. 하나의 자격 증명이 조직 두 곳에 승인된 테스트를 먼저 넣으면 중복 집계 문제를 빠르게 발견할 수 있습니다.
설계 흐름
가상 CSV → 열·날짜 검증 → 원본 보관 → 자격 증명/승인 관계 분리 → SQL 집계 → 조회 화면
-- 교육용 테이블을 전제로 한 SQL 설계 예시
SELECT COUNT(*) AS credential_count FROM credentials;
SELECT COUNT(*) AS grant_count FROM grants;5. CSV 실습을 API 수집으로 확장할 때
파일 하나를 읽는 작업과 네트워크에서 목록 전체를 가져오는 작업은 다릅니다. GitHub의 목록 API는 커서 기반으로 페이지를 나누며 다음 페이지는 Link 헤더로 안내합니다. 전체 개수는 제공되지 않습니다. 따라서 첫 응답만 받고 수집 완료로 표시하는 코드는 목록 일부를 전체로 보고할 수 있습니다. 문서의 다음 페이지 안내를 따라가는 로직이 필요합니다.
실습에서는 실제 기업 API 대신 두 페이지의 가상 응답을 준비하세요. 첫 페이지 처리 후 두 번째 요청이 실패하도록 만들어 보고, 이때 화면에 “완료”가 뜨지 않는지 확인합니다. 수집 작업에는 시작, 진행 중, 완료, 실패 같은 상태를 두고 모든 페이지가 처리된 뒤에만 새 집계 결과를 공개하는 방법을 제안합니다.
클라우드 학습과 연결할 때는 예약 수집 작업, 저장소, 조회 서비스를 분리해 봅니다. 네트워크 재시도는 횟수와 간격을 제한하고, 같은 작업이 다시 실행되어도 같은 승인 관계가 계속 추가되지 않게 설계합니다. Java 백엔드는 조회 요청의 사용자 권한을 확인하고 집계 결과를 반환하는 역할을 맡을 수 있습니다. 이 구성은 제안하는 실습 구조이며 GitHub 내부 구현에 대한 설명은 아닙니다.
근거 자료 · GitHub Docs · 자격 증명 목록 REST API
6. 규칙 기반 점검과 AI 요약은 어디에 쓸까
처음에는 설명 가능한 규칙 세 개로 시작하는 것이 좋습니다. 예를 들어 만료가 임박한 가상 항목, 만료 상태가 unknown인 항목, 실습에서 정한 기간 동안 사용 기록이 없는 항목을 각각 분류합니다. 이때 “점검 필요”와 “침해 확인”을 같은 표식으로 처리하지 마세요. 사용 기록이 비어 있다는 사실만으로 공격이나 방치를 확정할 수는 없습니다.
AI를 붙이고 싶다면 원본 비밀값이나 실제 조직 자료를 보내는 대신 가상 집계 결과를 자연어로 설명하게 합니다. 예를 들어 “자격 증명 2개, 승인 관계 3개, 만료 상태 미확인 1개”를 입력하고, 어떤 숫자가 왜 다른지 설명하도록 요청합니다. 모델이 없는 사용자 이름을 만들거나 미확인 항목을 만료된 것으로 바꾸면 오류로 기록합니다.
숫자 집계와 상태 판정은 SQL 및 명시적인 규칙으로 수행하고, AI는 읽기 쉬운 설명을 돕도록 역할을 좁히는 설계입니다. 모델이 생성한 문장에는 입력에 없는 원인이나 조치를 덧붙이지 않았는지 확인해야 합니다. 특히 자동 폐기 같은 실제 변경은 이 실습 범위에 포함하지 않습니다. 사람이 검토할 근거와 상태를 명확히 전달하는 것만으로도 충분한 학습 목표가 됩니다.
| 방법 | 실습에서 맡길 일 | 확인할 한계 |
|---|---|---|
| SQL 집계 | 항목 수와 승인 관계 수 계산 | 테이블 단위와 중복 처리 |
| 명시적인 규칙 | 정한 조건에 맞는 점검 후보 분류 | 조건 밖의 상황과 빈값 |
| AI 설명 | 가상 집계 결과를 쉬운 문장으로 요약 | 숫자 변경과 근거 없는 추론 |
7. 1주 프로젝트: 화면보다 실패 사례부터 설계하기
첫날에는 가상 자격 증명 12개와 승인 관계 18개를 직접 구성하세요. 이 숫자는 실습용 목표이며 측정 결과가 아닙니다. 같은 항목의 다중 조직 승인, 알 수 없는 만료 상태, 잘못된 날짜, 조직 승인이 없는 항목을 포함합니다. 각 입력에 대해 기대하는 결과를 표로 먼저 적으면 구현 뒤에 정답을 바꾸는 일을 줄일 수 있습니다.
둘째 날과 셋째 날에는 Python 검증과 SQL 저장을 구현하고, 넷째 날에는 Java 또는 익숙한 백엔드로 읽기 전용 화면을 연결합니다. 다섯째 날에는 가상 API의 중간 페이지 실패를 재현하고, 재실행 후 중복 관계가 생기지 않는지 확인합니다. AI 요약은 기본 집계가 맞는 것을 확인한 팀의 선택 과제로 두면 됩니다.
평가는 화면의 화려함보다 데이터 정확성을 중심으로 합니다. 준비한 사례 중 기대 결과와 일치한 비율, 잘못된 입력을 발견한 건수, 실패한 수집을 완료로 표시한 횟수, AI 설명에서 입력 숫자가 달라진 횟수를 기록하세요. 테스트 자료가 작다면 비율 옆에 분자와 분모를 함께 적어야 결과를 과장하지 않습니다. 예를 들어 4개 중 4개 통과가 모든 상황에서 완벽하다는 뜻은 아닙니다.
최종 발표에서는 잘 처리된 정상 사례 하나와 실패 사례 두 개를 보여 주세요. 중복 승인을 어떻게 셌는지, 빈값을 왜 별도 상태로 남겼는지, 일부 페이지만 수집되었을 때 무엇을 표시했는지 설명하면 됩니다. 이 프로젝트의 핵심은 보안 도구를 흉내 내는 데 그치지 않고, 데이터 의미를 유지하면서 수집·저장·설명하는 전체 과정을 스스로 검증하는 것입니다.
학생이 이 이슈에서 확인할 것
- 행 수와 자격 증명 수가 다른 이유를 설명할 수 있나요?
- 빈값과 만료되지 않음을 구분해 저장했나요?
- API의 중간 페이지 실패를 완료로 처리하지 않나요?
- AI 요약의 숫자를 원래 집계와 대조했나요?
가상 자격 증명 12개와 승인 관계 18개로 읽기 전용 점검 대시보드를 만드세요. 중복 집계, 알 수 없는 만료 상태, 수집 중단 사례의 기대 결과와 실제 결과를 비교해 발표하세요.
관심 기술을 대학의 프로젝트로 연결하세요.
전공의 학습 흐름을 이해하고 학생이 직접 만든 결과를 확인한 뒤, 자신에게 맞는 입학 계획을 세워 보세요.