형상 관리 (Git · SVN)

13강이 따로 만든 모듈을 합쳐 검증하는 단원이었다면, 14강은 그렇게 쌓이는 코드 변경을 누가·언제·왜 바꿨는지 추적·통제·기록하는 형상 관리(SCM) 단원이다. 매 회차 1문제 이상 나오는 빈출 강이고, 확실한 점수밭은 셋 — 형상 관리 4활동(식통감기), SVN vs Git(SVN=중앙·Git=분산), 명령어 함정 트라이앵글(commit≠push·풀=fetch+merge·충돌은 사람).

핵심 암기: 형상 관리 4활동 식통감기 · 베이스라인 시점 고정+변경 통제 시작점 · SCM 도구 SVN=중앙·Git=분산 · commit ≠ push · 풀=fetch+merge · 충돌은 사람이 해결 · Git ≠ GitHub

형상 관리 기초

형상 관리(SCM)와 4대 효과 ·형상 관리·1순위·

[정의] 형상 관리(Software Configuration Management, SCM) = 개발 과정에서 발생하는 모든 변경(소스 코드·문서·빌드 산출물)을 식별·통제·기록해 일관성과 추적성을 유지하는 활동. 한 줄로 '누가·언제·왜·무엇을 바꿨는지 기록하고, 함부로 못 바꾸게 통제'.

[표] 도입 효과 4가지 — '형상 관리 도입 효과로 옳은 것?' 단골.

🔑 암기 4대 효과 = 추적·복원·협업·품질. ⚠️ 함정 정의에 '성능 향상·코드 최적화'가 보이면 함정 — 그건 리팩토링이고, 형상 관리는 직접적 성능 효과가 없다. '소스 코드만 관리'도 함정(문서·빌드물 전체 포함). 🎯 빈출 정의 매칭('식별·통제·기록·일관성' 든 보기가 정답) + 4대 효과 매칭. 거의 매회. 📝 기출 '형상 관리 정의로 옳은 것?'.

형상 항목(CI) 6종 ·형상 항목·

[정의] 형상 항목(Configuration Item, CI) = 형상 관리의 대상이 되는 모든 산출물. 소스 코드만이 아니다.

[분류] 대표 6종 — 소스·문서·빌드물·라이브러리·테스트·릴리스.

⚠️ 함정 '형상 항목 = 소스 코드만'은 100% 함정 — 문서·빌드물·테스트 자산까지 전부. 형상 항목 CI(Configuration Item)와 지속적 통합 CI(Continuous Integration)는 약어만 같고 완전히 다른 개념. 🎯 빈출 '형상 항목이 아닌 것?'에 성능 지표 같은 비산출물을 끼워 출제. 간헐.

형상 관리 4활동 — 식통감기 ·형상 관리·1순위·

[정의] 형상 관리는 4개 활동이 순서대로 돈다. 14강 시험 1순위 매칭.

[흐름] 식별 → 통제 → 감사 → 기록.

🔑 암기 식통감기 — 식별·통제·감사·기록. '식통감(感)을 기록하다'. ⚠️ 함정 '식별→감사→통제→기록'(통제·감사 순서 바꿈)이 매년 1순위 단골. 식별은 항상 1번, 기록은 항상 4번 — 가운데 통제·감사 순서만 정확히. '식별·통제·감사 3단계'(기록 누락)도 함정. CCB(형상 통제 위원회)는 통제 활동의 주체. 🎯 빈출 4활동 순서 매칭 + CCB·CR(변경 요청서) 키워드 매칭. 매년 빈출 1순위. 📝 기출 '형상 관리 4활동을 올바른 순서로?'.

베이스라인(Baseline) ·베이스라인·1순위·

[정의] 베이스라인(Baseline) = 공식적으로 합의된 형상 항목의 묶음 + 그 시점. 이 시점 이후 모든 변경은 변경 통제 절차(CCB 심사) 를 통과해야만 반영된다. 한 줄 본질 = 시점 고정 + 변경 통제 시작점.

💡 비유 게임 세이브 포인트 — 특정 시점 상태를 통째로 저장했다가 그 시점으로 복원. 4대 효과 중 '시점 복원'의 실체가 베이스라인.

[표] 개발 단계별 4종 — 이름·시점만 가볍게.

🔑 암기 베이스라인 = 시점 고정 + 변경 통제 시작점. ⚠️ 함정 '베이스라인 이후 자유롭게 수정 가능'은 매년 1순위 함정 — 본질을 정반대로 뒤집은 표현. '단순한 백업과 같다'(백업+변경 통제), '비공식 시점'(공식 합의), '소스 코드만'(형상 항목 전체)도 함정. 🎯 빈출 정의 매칭 + '요구사항 완료=기능 / 개발 완료=제품' 시점 매칭. 거의 매회. 📝 기출 '베이스라인 설명으로 옳은 것?'.

버전 관리 ⊂ 형상 관리 ·범위·

[정의] 버전 관리(VCS) 는 형상 관리의 부분 집합. 버전 관리는 주로 파일 이력 추적까지, 형상 관리는 그 위에 변경 통제(CCB)·베이스라인·감사·상태 보고서까지 묶은 더 큰 그림.

🔑 즉답 Git·SVN 자체는 버전 관리 도구 — 형상 관리 시스템의 한 부품. ⚠️ 함정 '버전 관리 = 형상 관리'(같은 개념)는 함정 — 부분 집합 관계. '형상 관리는 소스 코드만'도 범위를 좁힌 함정. 🎯 빈출 두 개념의 포함 관계 매칭. 간헐.

버전 관리 도구 — SVN vs Git

중앙집중형 SVN — 본관 도서관 ·SVN·

[정의] SVN(Subversion) = 중앙 서버 1개에 모든 이력을 두는 중앙집중형(Centralized VCS). CVS도 같은 부류. 2000년대~2010년대 중반 사내 표준이었고, 지금은 Git과의 비교 축으로 시험에 등장.

[표] 본질이 그대로 단점으로 이어진다.

💡 비유 '도서관 본관' — 책(코드)이 본관에 1권뿐, 본관 휴관 시 전 회원 마비(SPOF). ⚠️ 함정 'SVN은 중앙 서버 장애에도 작업 계속'·'SVN 오프라인 commit 가능'·'SVN 브랜치가 가볍다'는 모두 100% 함정(전부 Git의 강점). 🎯 빈출 SVN 단독 출제는 드묾 — 대부분 'SVN과 달리 Git은 ~' 비교 축으로 등장.

분산형 Git — 모두가 사본 + 3대 장점 ·Git·

[정의] Git = 모든 개발자 PC가 전체 이력의 완전한 사본을 갖는 분산형(DVCS). Mercurial(Hg)도 분산형. 2005년 Linus Torvalds가 Linux 커널 개발용으로 발표.

[표] 모든 본질이 '분산'에서 파생 — 3대 장점.

💡 비유 '모두가 책 전체 사본을 집에 보관' — 본관(원격)이 없어져도 누군가의 사본으로 전체 복원. SVN과 정반대 구조. 🔑 즉답 '분산형·전체 이력 사본 보유·오프라인 OK' 셋 중 하나라도 보이면 Git. 🎯 빈출 'Git의 장점으로 옳은 것?' — 오프라인·고가용성·가벼운 브랜치. 거의 매회. 💡 보충 Git 탄생 일화 — 상용 도구 BitKeeper가 Linux 커널의 무료 사용권을 회수하자 Linus가 2주 만에 직접 제작(2005). 시험엔 안 나오지만 '왜 분산형인가'의 배경.

SVN vs Git 결정적 차이 ·SVN vs Git·1순위·

[정의] 14강 매년 빈출 1순위. 한 줄 SVN=중앙·Git=분산에서 모든 차이가 파생.

🔑 암기 SVN=중앙·Git=분산 — 8축을 외우지 말고 '중앙이라서?' / '분산이라서?' 두 가지로만 판단. ⚠️ 함정 'SVN=분산·Git=중앙'(거꾸로)·'SVN 오프라인 commit 가능'·'Git commit은 서버 즉시 반영'·'Git은 중앙 장애 시 전 작업 멈춤'은 모두 두 모델 성질을 바꿔치기한 함정. 🎯 빈출 비교 매칭이 매년 단골 1순위. 보기에서 'SVN? Git?'만 분별하면 즉답. 📝 기출 'SVN과 Git의 차이로 옳은 것?'.

Git 실전 — 영역·명령어·브랜치·충돌

Git 4영역과 핵심 명령어 8종 ·Git 구조·

[정의] Git은 변경이 4개 영역을 거쳐 원격까지 간다. 이 4단계 구조가 'commit ≠ push'를 만든다(SVN은 작업→서버 1단계).

[흐름] Working → Staging → Local → Remote.

① Working Directory (작업 책상)
        │  git add  ▼
② Staging Area (결재 봉투)
        │  git commit  ▼
③ Local Repository (내 책장)        ← 여기까지 내 PC
        │  git push  ▼
④ Remote Repository (공용 자료실)   ← 여기서 팀 공유

🔑 즉답 commit·push·fetch·pull 네 개만 정확하면 출제분 90%. Staging Area(인덱스)의 존재가 SVN과의 결정적 차이 — 변경을 선별해 묶어 commit할 수 있다. 🎯 빈출 4영역 이름 매칭·명령어 동작 매칭. 간헐.

commit ≠ push ·명령어·1순위·

[정의] 8명령어 중 가장 자주 나오는 함정 쌍. commit = 내 PC(Local)까지 / push = 원격 공유. SVN→Git 전환 시 가장 헷갈리는 부분이라 함정으로도 단골.

🔑 암기 commit ≠ push — commit은 내 책장, push는 공용 자료실. SVN commit은 Git의 push에 가깝다. ⚠️ 함정 'commit은 원격 즉시 반영'·'push 없이 commit만으로 팀이 봄'·'commit과 push는 같은 명령'은 모두 'commit이 자동 공유'라는 잘못된 가정 — 100% 함정. 🎯 빈출 commit 동작 매칭. 'commit'과 '원격·자동·즉시'가 한 줄에 있으면 함정. 매년 단골. 📝 기출 'git commit의 동작으로 옳은 것?'.

풀=fetch+merge ·명령어·1순위·

[정의] commit vs push와 쌍벽을 이루는 함정. git pull = git fetch + git merge. fetch는 가져만, pull은 가져와서 자동 병합.

🔑 암기 풀=fetch+merge — fetch는 편지 받아만, pull은 받아서 일지에 자동 반영. ⚠️ 함정 'pull은 가져만, fetch는 가져와서 합침'(거꾸로)·'fetch도 자동으로 Working에 반영'·'pull은 충돌 안 남'은 모두 함정. 충돌이 안 나는 건 fetch(가져만 오므로). 🎯 빈출 fetch vs pull 차이 매칭. 거꾸로 함정이 매년 단골. 📝 기출 'fetch와 pull의 차이로 옳은 것?'.

브랜치·머지와 충돌 — 충돌은 사람이 해결 ·브랜치·1순위·

[정의] 브랜치(Branch) = 현재 흐름에서 갈라진 독립 작업 라인(평행우주). 머지(Merge) = 다시 합치기. 브랜치 비용이 거의 0이라 자유롭게 실험하고, 실패하면 그 브랜치만 버리면 끝(main은 안전).

[표] 머지 2방식 — main이 그동안 바뀌었나 한 가지로 갈린다.

[흐름] 충돌(Conflict) = 두 사람이 같은 파일·같은 줄을 다르게 고쳤을 때만 발생. Git은 자동 해결하지 않고 마커만 표시한다.

<<<<<<< HEAD
  (main 쪽 변경 내용)
=======
  (feature 쪽 변경 내용)
>>>>>>> feature/korean

이후 사람이 파일을 열어 검토 → 어느 쪽을 살릴지 결정 → 마커 제거 → git add + git commit 으로 마무리.

🔑 암기 충돌은 사람이 해결 — Git의 일은 마커 표시까지, 결정은 개발자. ⚠️ 함정 'Git이 충돌 자동 해결'·'다른 파일·다른 줄도 충돌'(같은 파일·같은 줄만)·'충돌 시 머지 자동 취소'(진행 중 상태 유지)는 모두 함정. 🎯 빈출 충돌 처리 주체('사람') + FF/3-way 정의 매칭. 거의 매회. 📝 기출 '브랜치·머지·충돌 설명으로 옳지 않은 것?'.

Git ≠ GitHub와 CI 자동화 ·호스팅·

[정의] Git 은 분산형 SCM 도구, GitHub 는 그 위에서 원격 저장소를 호스팅하는 서비스. 도구와 플랫폼은 다르다.

💡 비유 'Git ≠ GitHub' — 영어(도구)를 할 줄 알면 어느 플랫폼이든 쓰듯, Git을 쓸 줄 알면 GitHub·GitLab·Bitbucket 어디서든 쓴다.

[흐름] CI(지속적 통합) — git push 가 자동 빌드·테스트의 방아쇠가 된다.

코드 수정 ─▶ git push ─▶ CI 서버 자동 빌드+테스트 ─▶ 통과 시 자동 배포

⚠️ 함정 'Git과 GitHub는 같다'가 매년 단골 — 도구 vs 서비스. 형상 항목 CI(Configuration Item) ≠ 지속적 통합 CI(Continuous Integration), 약어만 같다. 🎯 빈출 'Git ≠ GitHub' 한 줄. 호스팅 서비스 디테일은 출제 빈도 낮음. 💡 보충 CI 자동화는 13강 단위 테스트(JUnit)가 push 한 번에 자동 실행되는 흐름의 출발점 — 본격 빌드 자동화(Jenkins·Maven/Gradle)는 16강.

기출 다지기

[기출 1 출제] 다음 중 형상 관리(SCM) 의 정의로 가장 옳은 것은? (개념 식별·옳은 설명 고르기)

• ① 소프트웨어 코드만을 백업·복원하는 활동
• ② 개발 과정의 모든 변경(소스·문서·빌드물)을 식별·통제·기록하여 일관성을 유지하는 활동
• ③ 소프트웨어 성능을 향상시키기 위한 코드 최적화 활동
• ④ 사용자 요구사항을 변경 없이 그대로 반영하는 활동

[기출 2 출제] 다음 중 형상 관리의 4가지 활동을 올바른 순서로 나열한 것은? (순서 매칭)

• ① 식별 → 감사 → 통제 → 기록
• ② 식별 → 통제 → 감사 → 기록
• ③ 통제 → 식별 → 기록 → 감사
• ④ 기록 → 통제 → 식별 → 감사

[기출 3 출제] 다음 중 베이스라인(Baseline) 에 대한 설명으로 옳은 것은? (개념 식별·옳은 설명 고르기)

• ① 베이스라인 이후에는 자유롭게 형상 항목을 수정할 수 있다
• ② 공식 합의된 형상 항목의 묶음 + 시점으로, 이후 변경은 변경 통제 절차를 통과해야만 반영된다
• ③ 베이스라인은 단순한 백업 파일과 동일한 개념이다
• ④ 베이스라인은 소스 코드만 포함하며 문서는 포함되지 않는다

[기출 4 출제] 다음 중 SVN(Subversion)과 Git 의 차이에 대한 설명으로 옳은 것은? (비교 매칭)

• ① SVN은 분산형 저장소, Git은 중앙집중형 저장소를 사용한다
• ② SVN과 Git 모두 오프라인 commit이 가능하다
• ③ Git은 분산형으로 모든 PC가 전체 이력 사본을 보유하며, SVN은 중앙집중형으로 중앙 서버에만 전체 이력이 있다
• ④ Git의 commit은 SVN과 동일하게 즉시 원격 서버에 반영된다

[기출 5 출제] 다음 중 분산형 SCM(DVCS, Git 포함) 의 특징으로 옳지 않은 것은? (아닌 것 고르기)

• ① 모든 개발자 PC가 전체 이력의 완전한 사본을 보유한다
• ② 오프라인에서도 commit·log·diff 등 대부분의 작업이 가능하다
• ③ 브랜치 생성 비용이 매우 가볍다
• ④ 중앙 서버에 장애가 발생하면 모든 개발자의 작업이 즉시 중단된다

[기출 6 출제] 다음 중 git fetch와 git pull 의 차이에 대한 설명으로 옳은 것은? (명령어 매칭)

• ① fetch는 원격 변경을 가져와서 자동 병합하고, pull은 가져만 온다
• ② fetch와 pull은 완전히 동일한 명령이다
• ③ fetch는 원격 변경을 가져만 오고, pull은 fetch + merge를 자동으로 수행한다
• ④ pull은 항상 충돌이 발생하지 않는 안전한 명령이다

[기출 7 출제] 다음 중 Git의 브랜치(Branch)·머지(Merge)·충돌(Conflict) 에 대한 설명으로 옳지 않은 것은? (아닌 것 고르기)

• ① 브랜치는 현재 코드 흐름에서 갈라져 나온 독립된 작업 라인이다
• ② Fast-forward 머지는 main에 변경이 없을 때 포인터만 이동시킨다
• ③ 3-way 머지는 main과 feature 양쪽에 변경이 있을 때 발생하며 머지 커밋을 생성한다
• ④ 충돌이 발생하면 Git이 자동으로 어느 쪽이 옳은지 판단해 병합한다

[기출 8 출제] 다음 중 git commit 의 동작에 대한 설명으로 옳은 것은? (명령어 매칭)

• ① commit은 원격 서버에 즉시 반영된다
• ② commit과 push는 동일한 명령어이다
• ③ commit은 Staging Area의 변경을 Local Repository에 저장하며, 원격 공유는 push가 별도로 필요하다
• ④ commit은 항상 자동으로 다른 개발자에게 공유된다

한 장 요약

🎯 합격 한 끗: 매 회차 점수밭 셋 = 형상 관리 4활동(식통감기) + SVN vs Git(SVN=중앙·Git=분산) + 명령어 함정(commit≠push·풀=fetch+merge·충돌은 사람). 단골 함정 7쌍 = 'SVN=분산·Git=중앙'(거꾸로), 'commit 원격 즉시 반영'(로컬까지), 'pull은 가져만·fetch는 합침'(거꾸로), 'Git이 충돌 자동 해결'(사람이), '베이스라인 이후 자유 수정'(통제 절차 필수), '식별→감사→통제→기록'(식통감기 순서), '형상 항목=소스 코드만'(전체 포함). 일곱 매칭(식통감기·베이스라인=시점고정+변경통제·SVN=중앙·Git=분산·commit≠push·풀=fetch+merge·충돌은 사람·Git≠GitHub)이 손에 박히면 14강은 거뜬.