Git 리드·아키텍트 CS 기초 면접
새 면접Q. Git의 내부 객체 저장소는 DAG(Directed Acyclic Graph) 구조를 사용합니다. 이 자료구조가 Git에 적합한 이유를 설명하고, 만약 일반 트리 구조나 링크드 리스트를 사용했을 때 발생할 수 있는 문제점을 분석해주세요. 특히 머지 커밋 처리 관점에서 설명해주세요.
여러 부모 노드를 가질 수 있는 구조의 필요성과 순환 참조 방지를 고려해보세요.
DAG는 방향성이 있으면서 순환이 없는 그래프로, Git에서 머지 커밋이 여러 부모를 가질 수 있도록 지원합니다. 일반 트리 구조는 노드당 하나의 부모만 허용하므로 두 브랜치의 머지를 표현할 수 없습니다. 링크드 리스트는 선형 구조로 브랜치 분기 자체를 표현할 수 없어 병렬 개발이 불가능합니다. DAG의 비순환 특성은 무한 루프를 방지하며 조상 탐색 알고리즘의 종료를 보장합니다. 이를 통해 Git은 복잡한 브랜치 히스토리를 효율적으로 관리하고 공통 조상 찾기 같은 연산을 수행할 수 있습니다.
- • DAG는 머지 커밋의 다중 부모 관계를 자연스럽게 표현
- • 비순환 특성으로 히스토리 탐색 알고리즘의 종료 보장
- • 트리나 리스트 구조로는 브랜치 분기와 병합을 표현할 수 없음
대규모 모노레포에서 복잡한 머지 히스토리를 추적하고 병목 지점을 분석할 때 DAG 구조 이해가 필수적입니다.
Git의 three-way merge에서 공통 조상을 찾는 알고리즘의 시간 복잡도는 어떻게 되며, 이를 최적화하기 위해 어떤 전략을 사용할 수 있을까요?
Q. Git의 diff 알고리즘은 두 파일 간의 최소 편집 거리를 찾는 문제입니다. Myers diff 알고리즘과 Patience diff 알고리즘의 시간 복잡도를 비교하고, 각각 어떤 상황에서 유리한지 설명해주세요. 또한 대용량 파일 비교 시 성능 최적화 전략을 제시해주세요.
최악의 경우와 평균적인 경우의 복잡도 차이, 그리고 파일 특성에 따른 알고리즘 선택을 생각해보세요.
Myers 알고리즘은 O((N+M)D) 시간 복잡도를 가지며, D는 차이의 크기입니다. 변경이 적은 경우 효율적이지만 완전히 다른 파일에서는 O(N²)에 근접합니다. Patience 알고리즘은 고유한 라인을 LCS(Longest Common Subsequence)로 먼저 찾아 O(N log N)의 안정적인 성능을 보이며, 코드 리팩토링처럼 블록 이동이 많은 경우 더 직관적인 결과를 제공합니다. 대용량 파일 최적화로는 청크 단위 해싱을 통한 사전 필터링, 변경 가능성이 높은 영역만 상세 비교, 그리고 멀티스레드 병렬 처리를 적용할 수 있습니다. Git은 파일 크기와 특성에 따라 알고리즘을 동적으로 선택하며, 바이너리 파일은 델타 압축을 사용합니다.
- • Myers는 변경이 적을 때 효율적이나 최악의 경우 O(N²), Patience는 O(N log N)으로 안정적
- • Patience는 코드 블록 이동이나 리팩토링 상황에서 더 의미있는 diff 생성
- • 대용량 파일은 청크 해싱, 선택적 비교, 병렬 처리로 최적화
대용량 바이너리 파일이나 자동 생성 코드가 포함된 저장소에서 diff 성능 문제를 진단하고 gitattributes 설정을 최적화할 때 필요합니다.
Git의 pack 파일에서 사용하는 델타 체인 최적화 전략과, 델타 체인이 너무 길어질 때 발생하는 문제를 어떻게 해결하시겠습니까?
Q. Git은 SHA-1 해시를 커밋 식별자로 사용해왔으나 SHA-256으로 전환 중입니다. 암호학적 해시 함수가 Git에서 만족해야 할 세 가지 핵심 속성을 설명하고, SHA-1의 충돌 취약점이 Git 저장소 보안에 미치는 실제 위험도를 평가해주세요.
결정론적 특성, 충돌 저항성, 그리고 일방향 함수 특성을 중심으로 생각해보세요.
Git 해시 함수는 첫째, 결정론적이어야 합니다. 동일한 콘텐츠는 항상 같은 해시를 생성해 분산 환경에서 일관성을 보장합니다. 둘째, 충돌 저항성이 필요합니다. 서로 다른 객체가 같은 해시를 가지면 데이터 무결성이 깨집니다. 셋째, 역상 저항성으로 해시에서 원본을 역추적할 수 없어야 합니다. SHA-1 충돌 공격은 이론적으로 가능하지만, Git의 경우 공격자가 의미있는 악성 커밋과 정상 커밋을 동일한 해시로 만들기는 매우 어렵습니다. 다만 장기적 보안과 규제 준수를 위해 SHA-256 전환이 진행 중이며, 하이브리드 모드로 하위 호환성을 유지하고 있습니다.
- • 결정론적 특성으로 분산 환경 일관성 보장
- • 충돌 저항성으로 데이터 무결성 유지
- • SHA-1 충돌 공격은 이론적으로 가능하나 실제 Git 공격은 매우 어려움
금융권이나 공공기관에서 보안 감사 시 SHA-1 사용에 대한 리스크 평가와 마이그레이션 계획 수립이 요구됩니다.
대규모 조직에서 기존 SHA-1 저장소를 SHA-256으로 마이그레이션할 때 고려해야 할 기술적 과제와 단계적 전환 전략을 설명해주세요.
Q. Git 저장소의 .git/objects 디렉토리는 수백만 개의 작은 파일을 생성할 수 있습니다. 이것이 파일시스템 성능에 미치는 영향을 inode 구조와 디렉토리 탐색 알고리즘 관점에서 설명하고, Git이 pack 파일로 이를 해결하는 방식을 설명해주세요.
파일시스템의 메타데이터 오버헤드와 디렉토리 엔트리 탐색 비용을 고려해보세요.
파일시스템에서 각 파일은 inode를 소비하며, 작은 파일이라도 메타데이터 오버헤드가 동일하게 발생합니다. 수백만 개의 loose 객체는 inode 고갈을 유발할 수 있고, 디렉토리 엔트리 탐색 시 선형 또는 트리 탐색 비용이 증가합니다. ext4나 XFS 같은 파일시스템도 단일 디렉토리에 수십만 파일이 있으면 성능이 저하됩니다. Git은 gc 명령으로 loose 객체를 pack 파일로 압축하여 하나의 대용량 파일과 인덱스로 관리합니다. pack 파일은 델타 압축을 적용해 저장 공간도 절약하며, 인덱스를 통한 이진 탐색으로 O(log N) 접근 속도를 보장합니다. 이로써 수백만 객체를 효율적으로 관리할 수 있습니다.
- • 작은 파일 다수는 inode 고갈과 디렉토리 탐색 성능 저하 유발
- • pack 파일로 통합하여 파일시스템 오버헤드 제거
- • 인덱스 파일을 통한 이진 탐색으로 O(log N) 접근 성능 확보
CI/CD 서버에서 Git 저장소 클론 속도가 느려지거나 디스크 I/O가 병목이 될 때 pack 파일 최적화가 필요합니다.
NFS나 분산 파일시스템 환경에서 Git 저장소를 운영할 때 발생할 수 있는 성능 문제와 해결 방안은 무엇인가요?
Q. Git의 스마트 HTTP 프로토콜과 SSH 프로토콜을 비교하여 각각의 장단점을 설명해주세요. 특히 방화벽 환경, 인증 방식, 그리고 대용량 저장소 클론 시 성능 차이를 중심으로 분석하고, 엔터프라이즈 환경에서 프로토콜 선택 기준을 제시해주세요.
HTTP의 상태 비저장 특성과 SSH의 지속 연결 특성, 그리고 보안 정책을 고려해보세요.
스마트 HTTP는 80/443 포트를 사용해 방화벽 통과가 쉽고, OAuth나 SAML 같은 현대적 인증 체계와 통합이 용이합니다. 상태 비저장 특성으로 로드 밸런싱이 간단하지만, 각 요청마다 인증 오버헤드가 발생할 수 있습니다. SSH는 22 포트를 사용하며 공개키 인증으로 안전하고, 지속 연결로 멀티플렉싱이 가능해 대용량 전송 시 효율적입니다. 그러나 방화벽 제약이 많고 키 관리 부담이 있습니다. 엔터프라이즈에서는 외부 접근은 HTTPS를 사용해 CDN과 캐싱을 활용하고, 내부 시스템 간 통신은 SSH로 성능을 최적화하는 하이브리드 전략이 효과적입니다. Git LFS 같은 대용량 파일은 HTTP가 더 유리합니다.
- • HTTP는 방화벽 친화적이고 현대적 인증 통합 용이, SSH는 성능과 보안 우수
- • HTTP는 상태 비저장으로 로드 밸런싱 쉬우나 요청당 인증 오버헤드 존재
- • 엔터프라이즈는 외부 HTTPS, 내부 SSH 하이브리드 전략 권장
글로벌 분산 팀 환경에서 지역별 방화벽 정책과 네트워크 레이턴시를 고려한 Git 인프라 설계 시 프로토콜 선택이 중요합니다.
Git 프로토콜의 협상 과정에서 클라이언트와 서버가 주고받는 capabilities 정보에는 어떤 것들이 있으며, 이를 통해 어떤 최적화가 가능한가요?
Q. 여러 프로세스가 동시에 같은 Git 저장소에 쓰기 작업을 수행할 때 Git은 어떻게 데이터 무결성을 보장하나요? ref 업데이트 시 사용되는 잠금 메커니즘과 원자적 연산을 설명하고, race condition이 발생할 수 있는 시나리오와 해결 방법을 제시해주세요.
파일 기반 잠금과 compare-and-swap 같은 원자적 연산 패턴을 생각해보세요.
Git은 ref 업데이트 시 .git/refs 디렉토리에 .lock 파일을 생성하는 파일 기반 잠금을 사용합니다. 프로세스는 먼저 해당 ref에 대한 lock 파일을 배타적으로 생성하고, 성공하면 ref를 업데이트한 후 lock을 해제합니다. 이는 운영체제의 원자적 파일 생성 연산을 활용한 것입니다. race condition은 두 프로세스가 동시에 같은 브랜치를 업데이트하려 할 때 발생하며, 한 프로세스는 lock 획득 실패로 재시도하게 됩니다. packed-refs 파일 업데이트는 전체 파일을 원자적으로 교체하는 방식을 사용합니다. CI/CD 환경에서 동시 푸시 문제는 서버 측 훅에서 충돌 감지 후 클라이언트 재시도 정책으로 해결하며, 필요시 분산 락 서비스를 도입할 수 있습니다.
- • 파일 기반 잠금으로 ref 업데이트의 원자성 보장
- • 운영체제의 원자적 파일 생성 연산 활용
- • 동시 업데이트는 lock 획득 실패 시 재시도 메커니즘으로 해결
대규모 CI/CD 파이프라인에서 수백 개의 빌드 잡이 동시에 같은 저장소에 태그를 생성하거나 브랜치를 업데이트할 때 동시성 이슈가 발생합니다.
분산 환경에서 여러 Git 서버가 복제본을 유지할 때 발생할 수 있는 일관성 문제와 이를 해결하기 위한 아키텍처 패턴은 무엇인가요?
Q. Git이 대용량 저장소를 처리할 때 메모리 사용을 최적화하는 전략을 설명해주세요. 특히 shallow clone, partial clone, sparse checkout의 차이점과 각각이 메모리와 네트워크 대역폭에 미치는 영향을 분석하고, 어떤 상황에서 각 기법을 선택해야 하는지 설명해주세요.
히스토리 깊이, 객체 필터링, 작업 디렉토리 범위 제한이 각각 어떤 리소스를 절약하는지 생각해보세요.
shallow clone은 --depth 옵션으로 히스토리 깊이를 제한하여 다운로드할 커밋 수를 줄입니다. 네트워크 대역폭과 디스크 공간을 절약하지만 전체 히스토리 탐색이 불가능합니다. partial clone은 --filter 옵션으로 특정 객체 타입을 지연 로딩하며, blob 객체를 필요할 때만 가져와 초기 클론 속도를 높입니다. 메모리와 네트워크를 모두 절약하며 필요시 객체를 자동으로 가져옵니다. sparse checkout은 작업 디렉토리에 체크아웃할 경로를 제한하여 디스크 I/O와 파일시스템 메모리를 절약하지만 전체 객체는 다운로드됩니다. CI/CD는 shallow clone, 모노레포 부분 작업은 sparse checkout, 대용량 바이너리 포함 저장소는 partial clone이 적합합니다.
- • shallow clone은 히스토리 깊이 제한으로 네트워크와 디스크 절약
- • partial clone은 객체 지연 로딩으로 초기 클론 최적화
- • sparse checkout은 작업 디렉토리 범위 제한으로 파일시스템 부담 감소
수십 GB 규모의 모노레포에서 CI 빌드 시간을 단축하기 위해 클론 전략을 최적화할 때 이 기법들을 조합하여 사용합니다.
Git LFS와 partial clone을 함께 사용할 때의 시너지 효과와 주의사항은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!