한화시스템 BEYOND SW캠프 - 3일차

수업 내용

2025년 7월 17일

Git CLI 환경에서 사용법

초기 설정

# 깃 초기 설정
$ git config --global user.name '깃허브 아이디'
$ git config --global user.email '깃허브 이메일'

# CRLF 문제 해결(window 유저에 해당)
$ git config --global core.autocrlf input

# 깃 설정 확인
$ cat ~/.gitconfig

# 현재 git의 디폴트 브랜치 확인
$ git config --get init.defaultBranch

# 기본 브랜치 main으로 변경
$ git config --global init.defaultBranch main
$ git config --get init.defaultBranch

#.git 디렉토리 생성 및 확인
$ git init
$ ls -al

레포지토리에 파일 추가하기

$ touch test.txt

# 코드 작성(수정 후 :wq)
$ vim test.txt

코드 변경 후 작업 트리 상태 출력

# 코드 수정
$ vim test.txt
$ git status

# 변경 사항 확인
$ git diff

# 변경 사항 add 및 commit
$ git add test.txt

# 다시 add한 것을 되돌리고 싶다면
$ git restore --staged .

$ git commit

# 이후 커밋 로그 메시지 최소 세줄 작성할 것
# 1 행: 변경에 대한 요약
# 2 행: 빈 행
# 3 행: 상세 메시지

# 'git commit -m'으로 작성할 때는 git commit -m '메시지1' -m '' -m '메시지2'
# 이런식으로 작성하면 된다.

변경 이력 확인하기

# 변경 이력 확인(끌 때는 q)
$ git log

# 변경 이력과 함께 차이점 표시(끌 때는 q)
$ git log -p

# 제목만
$ git log --oneline

특정 커밋과 현재의 차이 표시

$ git diff [7자리 커밋 오브젝트명]

변화 확인하기

staging area 차이 표시

$ git diff
# 또는
$ git diff --cached

레포지토리와 차이 표시

$ git diff HEAD

• (HEAD 관련)
  HEAD
  # 최신 커밋 (현재 브랜치의 마지막 커밋)
  HEAD~1
  # 1개 이전 커밋
  HEAD~2
  # 2개 이전 커밋
  HEAD~3
  # 3개 이전 커밋

변경한 파일 인덱스에 등록하는 방법

# 변경한 파일을 전부 인덱스에 등록(변경한 기존 파일만 등록)
$ git add -u

# 모든 파일을 인덱스에 등록(새로 작성한 파일까지 등록)
$ git add -A
# 또는
$ git add .

이전 커밋으로 복원하는 방법(안전하게)

$ git revert [취소하고 싶은 커밋의 오브젝트명]

새로운 브랜치 생성 및 확인

$ git branch [브랜치명]

# 생성된 브랜치 확인
$ git branch

해당 브랜치로 전환

$ git checkout [전환할 브랜치]

# 브랜치 전환된 것 확인
$ git branch

main 브랜치로 전환

$ git checkout main

지정한 브랜치의 내용을 현재 브랜치에 merge

$ git merge [merge할 브랜치명]

# merge 메시지 뜨면 작성할 것9

브랜치 삭제

$ git branch -d [브랜치명]

레포지토리 복제

$ mkdir -p c:/gitwork/testproject2
$ cd -p c:/gitwork/testproject2

$ git clone [복제할 레포지토리]

# 복제 된 브랜치 확인

원격지에 push

$ git branch -M main
$ git remote add origin [원격지 https url 주소]
$ git push -u origin main
$ git pull origin main

GitHub Issue템플릿 설정

깃허브의 Issue를 만들 때 사용자가 계속 사용할 템플릿을 만드는 기능이다.

• Issue를 설정하려는 레포지토리에 들어가서 Settings를 누른다.

• settings의 General에서 Feature 영역에 Issue 템플릿을 설정할 수 있는 기능이 있다. Set up templates 를 누르면 레포지터리에 .github 폴더가 생성되고 템플릿이 그 폴더 안에 생성된다.

• 다른 역할의 탬플릿을 수동으로 만들기 위해서는 레포지토리의 .github 폴더에 들어가서 create new file을 누른다.

• 아래 이미지와 같은 형식의 파일명을 적고 원하는 내용을 작성하면 템플릿이 완성된다.(아래 같은 경우 PR 템플릿으로 PR이 발생하면 사용되는 템플릿 양식이다.)

GitHub Organization

같은 프로젝트를 여러 명이서 더 효율적으로 관리, 협업을 위한 깃허브의 기능이다.

Personal Repo와 Organization의 차이점

• Personal Repo: 주인 1명, 혼자서 여러 PR(pull request)를 감당해야함.(다른 사람이 소스 코드 포크를 떠가면 여러 명의 PR을 감당할 수 있음.)

• Organization: 주인 1명과 그 외의 여러 명 추가할 수 있다, 여러 레포지토리를 관리할 수 있다, 여러 PR을 다른 사람들과 같이 관리할 수 있다.

• 프로필에서 Your organizations를 클릭한다.

• new organization을 클릭한다.

• 무료 요금제를 선택한다.

• Organization 이름과 깃이메일, organization이 비즈니스용인지 개인용인지를 선택하고 next를 클릭한다.

• Oraganization이 잘 만들어졌고 people을 누르면 조직내의 맴버들을 확인할 수 있다. invite member버튼을 누르고 깃허브 아이디를 입력한뒤, invite를 누르면 조직으로 초대할 수 있다.

GitHub의 Fork

다른 사람의 원격 저장소를 자신의 원격 저장소로 복사할 수 있게 하는 깃허브의 기능이다.
포크에 성공하면 본인 계정에 본인이 설정한 원격 저장소의 이름으로 새로운 레포지토리가 생성된다.

소프트웨어 개발 프로세스 용어

• 프로그램: 시간의 흐름에 따라 작업이 이루어지는 것, 명령어가 나열된 것
• 애플리케이션: OS 위에서 동작하는 컴퓨터 프로그램
• 소프트웨어: 어플리케이션을 만드는데 기여되는 모든 것
• 프로세스: 개발할 때의 절차, 작업을 수행하는 일련의 절차

소프트웨어 개발 프로세스 특징

1. 개발 과정이 복잡하다.
2. 개발 과정이 길다.
3. 인력이 많다.

프로세스 모델

• 폭포수 모델(선형순차적 모델):

  • 장점
    • 구조가 명확하고 이해하기 쉽다.
    • 각 단계의 명확한 구분으로 문서화가 잘된다.
    • 큰 규모의 프로젝트나 변경이 거의 없는 프로젝트에 적합하다.
  • 단점
    • 변화에 대응하기 어렵고 유연성이 부족하다
    • 사용자 피드백을 개발 과정 후반에야 받을 수 있다.
    • 프로젝트 초기 단계에서 정확한 요구사항을 파악해야한다.

• 애자일 프로세스 모델(애자일 방법론):

  • 장점
    • 빠르게 변화하는 요구 사항에 유연하게 대응할 수 있다.
    • 정기적인 피드백을 통해 고객의 요구사항을 더 잘 반영할 수 있다.
    • 팀원 간의 긴밀한 협력과 의사소통이 장려된다.
  • 단점
    • 프로젝트의 규모가 커지면 관리가 복잡해질 수 있다.
    • 문서화가 충분히 이루어지지 않을 수 있다.
    • 프로젝트 이해도가 낮은 팀원의 참여가 어려울 수 있다.
    • 초기에 최종 비용과 시간을 추정하기 어려울 수 있다.

스프린트

많지 않은 작업량과 짧은 개발 기간 단위로 업무를 진행한다.

• 장점:
  • 빠르게 변화하는 요구 사항에 유연하게 대응할 수 있다.
  • 정기적인 피드백을 통해 고객의 요구사항을 더 잘 반영할 수 있다.
  • 팀원 간의 긴밀한 협력과 의사소통이 장려된다.
• 단점
  • 프로젝트의 규모가 커지면서 관리가 복잡해 질 수 있다.
  • 문서화가 충분히 이루어지지 않을 수 있다.
  • 초기에 최종 비용과 시간을 추정하기 어려울 수 있다.

스크럼

애자일 개발의 한 형태, 팀이 정해진 기간 동안 목표를 달성하기 위해 협력하는 프레임워크이다.

계획, 검토, 일일 스탠드업 미팅 등 정기적인 회의를 통해 프로젝트를 관리한다.

팀의 개선과 프로젝트 관리를 위한 애자일 방법론이다.

1. 제품 책임자:
   • 제품 기능 목록을 만들고 비즈니스 관점에서 우선순위와 중요도를 매겨 스프린트 계획 수립 시까지만 역할을 수행한다.
2. 스크럼 마스터
   • 제품 책임자를 돕고 스크럼 팀이 스스로 조직하고 관리하도록 지원하며 개발 과정에 방해될 만한 요소를 찾아 제거한다.
3. 스크럼 팀
   • 팀원은 보통 5 ~ 9명으로 구성되며 사용자 요구사항에서 사용자 스토리를 도출하고 이를 구현한다. 기능을 작업 단위로 나누고 일정이나 속도를 추정해서 제품 책임자에게 알려준다. 매일 스크럼 회의에 참여하여 진척 상황을 점검하고 스프린트에서 생산된 결과물을 제품 책임자에게 시연한다.

스크럼의 장점

• 팀 구성원 간의 높은 수준의 협력과 의사소통을 촉진한다.
• 빠른 피드백 루프를 통해 제품을 지속적으로 개선할 수 있다.
• 복잡한 프로젝트를 더 효과적으로 관리할 수 있다.

스크럼의 단점

• 팀 구성원의 경험과 자기 조직화 능력에 크게 의존한다.
• 대규모 프로젝트에는 적용하기 어려울 수 있다.
• 엄격한 일정과 빈번한 회의로 스트레스를 받을 수 있다.

요구사항이란?

사용자 또는 고객이 제품에 대해 기대하는 것(서비스, 외견, 조건)을 말한다.

프로젝트의 기초를 형성하며 개발 전반에 걸쳐 중요한 지침 역할을 한다.

요구사항의 목적

프로젝트의 목표를 명확히 하고 무엇을 개발할지 구체적으로 안내한다.

프로젝트의 범위를 정의, 의사소통을 원활하게 한다.

기능적 요구사항

시스템이 수행하는 구체적인 기능들을 명시한다.

비기능적 요구사항

시스템이 어떻게 동작해야 하는지에 대한 요구사항이다.(성능, 보안, 신뢰성, 사용 편의성)

요구사항 추출 과정

• 인터뷰: 다양한 이해관계자들과 요구사항을 대화로 직접 듣고 개별적인 관점과 깊이 있는 정보를 얻을 수 있다.
• 워크숍: 다양한 이해관계자들과 요구사항에 대해 토론하는 활동이다. 다양한 관점을 수렴 및 합의점에 도달 할 수 있다.
• 설문조사: 특정한 질문에 대한 답변을 통해 많은 수의 사용자로부터 요구사항을 수집하는 방법이다. 빠르고 비용 효율적으로 대규모 데이터를 수집할 수 있다.

요구사항 분석 절차

1. 요구사항 정리 및 분류
2. 요구사항 검토 및 우선순위 결정
3. 모델링 및 분석
4. 검증 및 승인
5. 명세서 작성
6. 반복 및 정제

명세서 작성 시 지킬 사항

• 명확성: 모든 이해관계자가 이해할 수 있도록 명확하고 구체적인 언어를 사용한다.
• 완전성: 모든 필수 요구사항을 포함하며, 누락된 내용이 없어야 한다.
• 추적 가능성: 각 요구사항이 원본 출처로 추적될 수 있도록 한다.
• 검증 가능성: 요구사항이 실제로 검증 가능해야 하며, 측정 가능한 기준을 포함해야 한다.

요구사항 검증

• 리뷰: 문서화된 요구사항을 이해관계자와 함께 검토하여 정확성, 완전성, 가독성을 확인한다.
• 테스트 케이스: 각 요구사항에 대해 테스트 케이스를 작성하고, 해당 테스트를 실행하여 요구사항이 충족되는지 검증한다.
• 프로토타입: 초기 단계에서 요구사항을 기반으로 프로토타입을 제작하고 이를 이해관계자에게 제시하여 피드백을 받는다.
• 시뮬레이션: 복잡한 시스템의 경우, 시뮬레이션을 통해 요구사항이 실제 운영 환경에서 어떻게 작동하는지 평가할 수 있다.

요구사항 변경 관리

• 변경 요청 프로세스: 모든 변경 요청은 공식적인 프로세스를 통해 제출되어야 한다.
• 영향 분석: 제안된 변경이 프로젝트에 미칠 영향을 분석한다.
• 변경 승인: 변경 사항에 대한 승인은 이해관계자나 변경 관리 위원회가 담당한다.
• 변경 기록 및 추적: 모든 변경 사항은 문서화 되고 추적 가능해야 한다.
• 통신 및 업데이트: 승인된 변경 사항은 모든 관련 이해관계자에게 통신되며, 관련 문서 및 계획은 업데이트 된다.

UML이란?

통합 모델링 언어(UML, Unified Modeling Language)는 소프트웨어 공학에서 사용되는 표준화 된 범용 모델링 언어로 소프트웨어의 개념을 다이어그램으로 그리기 위해 사용하는 시각적인 표기법

• 정적 다이어그램
  • 클래스 다이어그램: 프로그램 안의 주요 클래스와 주요 관계를 보여준다.
  • 객체 다이어그램: 시스템 실행 중 어느 순간의 객체와 관계를 포착.
  • 복합 구조 다이어그램: 내부 구조를 표현.
  • 배치 다이어그램: 소프트웨어, 하드웨어, 네트워크를 포함한 실행 시스템의 물리 구조표현.
  • 컴포넌트 다이어그램: 컴포넌트 사이의 의존관계 묘사. 컴포넌트를 구성하는 요소들과 그것들을 구현하는 요소들도 모두 표현 가능.
  • 패키지 다이어그램: 대규모 시스템에서 주요 요소 간의 종속성을 나타내거나 여러 클래스들의 그룹화 된 매커니즘을 나타낼 때 사용

• 동적 다이어그램
  • 활동 다이어그램: 플로우 차트가 UML에 접목된 개념.
  • 상태 다이어그램: 한 객체의 상태 변화를 다이어그램으로 표현
  • 유스케이스 다이어그램: 시스템과 사용자가 상호작용하는 경우를 나타내는 기능 위주의 다이어그램
  • 시퀀스 다이어그램: 시간 흐름에 따른 객체 사이의 상호작용 표현
  • 통신 다이어그램: 객체 사이의 관계를 중심으로 표현
  • 타이밍 다이어그램: 객체 상태 변화와 시간 제약을 명시적으로 표현

개발 프로세스

• 요구사항 분석 → 프로그램 설계 → 프로그램 구현 → 테스트/ 납품 → 유지보수

요구사항

고객 및 소프트웨어 개발에 관계 된 사람들이 시스템 개발에 앞서 개발되는 프로그램에 필요한 조건이나 능력을 말함

요구사항 프로세스

• 요구사항 추출 → 요구사항 분석 → 요구사항 명세 → 요구사항 검증 → 요구사항 유지보수

요구사항 조건

• 명확성
• 완전성
• 일관성
• 검증 가능성

트랜잭션

논리적 일의 단위를 말한다.

유스케이스 다이어그램

시스템이 제공하는 기능과 그 기능을 사용하는 사람이나 다른 시스템 사이의 상호작용을 시각적으로 표현한 다이어그램이다.

• 액터: 시스템과 상호작용을 하는 시스템 외부의 존재, 시스템 관점에서 바라 본 사용자의 역할
• 유스케이스: 개발 대상이 되는 시스템이 제공하는 개별적인 기능
• 포함관계: <<include>>, 포함관계, 공통 동작을 강제적으로 포함시킬 때 사용한다. 반드시 실행되어야 하는 유스케이스를 표현한다.
• 확장관계: <<extend>>, 기본 유스케이스의 특정 조건에서만 확장 동작을 실행할 때 실행할 때 사용한다. 선택적/조건적 기능을 나타낸다.
• 일반화 관계(속이 빈 화살표): 어떠한 유스케이스나 액터가 다른 것보다 더 구체적이거나 특수한 형태임을 나타낸다.
• 연관관계(일반 화살표): 사용자가 상화작용할 수 있는 유스케이스(기능)를 나타낸다.

새롭게 배운 점

오늘 수업에서는 여러 다양한 지식들을 배웠다. Git의 CLI 환경에서의 사용법부터 GitHub의 템플릿 설정 방법과 Organization 생성 방법, GitHub의 Fork에 대해 배웠고 소프트웨어 개발 프로세스와 사용자의 요구사항에 대한 간단한 지식을 익혔다. 마지막으로 UML 중 하나인 유스케이스 다이어그램을 동료와 함께 그려보면서 요구사항을 어떻게 문서로 남기는지에 대해서도 배웠다.

부족한 점

어제도 Git을 공부하면서 부족한 점을 느꼈지만, 오늘 또한 GitHub의 여러 다양한 기능을 배우면서 다시 한번 나의 부족한 Git을 다루는 실력과 지식을 체감할 수 있었다. GitHub에는 내가 아직까지 모르는 다양한 기능들이 너무 많았고 배우면 배울 수록 점점 모르겠다는 생각마저 들었다. 하지만 그럴수록 Git과 GitHub는 개발자에게 없어서는 안될 필수 툴이라는 생각이 들었고 반드시 익혀야 겠다고 생각했다.

앞으로의 계획 혹은 다짐

오늘 교육장에서 많은 사람들이 PCCE 시험을 대비하여 프로그래머스의 코딩테스트 문제들을 푸는 것을 보았다. 나도 뒤쳐질 수 없겠다라는 생각이 들었다. PCCE 시험 전까지 많은 알고리즘 문제를 풀어봐야 겠다고 생각했다.