한화시스템 SW BEYOND 캠프로부터 시작된 개발자 성장일기 Week 1 - '시작이 반이다.'

Step . 1 '시작이 반이다.'

드디어 시작이 된 나의 부트캠프 첫 수업..

오전에는 강사님을 소개하는 OT로 진행했고, 6개월동안 교육이 어떻게 진행되는 지 설명해주셨고, 오후부터는 진짜 강의가 들어갔다.

아무것도 모른 상태로 진행한 나의 코드 입력은 개강전 JAVA 기초 강의 영상부터였다.

영상을 보며 화면 속 강사님의 코드만 따라치기 바빴던 나의 모습이 떠오르며
'그래도 이렇게 해보고 가면 강의 들을 때 도움이 될거야.' 라고 생각한 것도 잠시..

IntelliJ 부터 시작하는 게 아니였다..

강사님의 경험으로 만들어진 커리큘럼은
git & github 개념부터 시작하는 것이였다.

😂

터미널로 코드를 작성한 적은 한번도 없었기에
수업을 따라가기 바쁜 시간이였지만,
차근차근 따라가며 이해하는 것에 흥미를 느꼈다 !

---

git & github 개념잡기

1. git이란?

파일의 변경 이력을 기록하고 여러 사람이 함께 작업할 수 있게 해주는 분산형 버전 관리 시스템
쉽게 말하면 코드를 작성하며 원하는 시점마다 깃발이 꽂아 자유롭게 이동하여 가능한 소스코드 버전관리 시스템으로 보면된다.

1-1. git의 기능

- 버전관리

알맞는 코드를 작성하여 파일의 변경 이력을 기록, 필요한 경우 이전 버전으로 되돌릴 수 있다.

용어	설명
cd Desktop	바탕화면으로 폴더 이동
cd ..	한 단계 위 폴더로 이동
cd ~	사용자 홈 폴더로 이동
ls	숨김 파일 제외하고 목록 표시
touch ~~~.txt	파일 생성 명령어
git config --	git 사용자 정보를 설정할 때 사용
git config --global user.name "깃 닉네임"	내 컴퓨터 전체에 한 번만 설정 → 모든 프로젝트에 적용
git config --global user.email "깃 이메일"	내 컴퓨터 전체에 한 번만 설정 → 모든 프로젝트에 적용
git init	깃 저장소 초기화
add	변경된 파일을 스테이징 영역에 추가

더 많은 명령어가 있지만, 기본적으로 사용되는 명령어다.

- 브랜치 (branch)

개발시 다양한 단계나 기능을 분리하여 관리할 수 있다.
영어는 나뭇가지라는 뜻으로, 개발을 할 때 작업물이 나뭇가지 모양으로 뻗어나간다는 의미로 해석하니 쉽게 이해됨. (나중에 한번 더 설명)

브런치를 통해 여러기능을 동시에 개발하고 협업에 용이하다고 보면 된다.

- 협업

여러 개발자가 동일한 프로젝트에서 병렬로 작업할 수 있게 지원

---

2. github란?

Git 호스팅 사이트 중 하나이다. 시간과 공간의 제약 없이 협업이 가능하다. 공개 저장소로 만들 시 모르는 사람과도 협업 가능하다. 누구든지 기여할 수 있는 공개 저장소 프로젝트이다. => 오픈소스
GitHub 외에도 GitLab, BitButcket등 다양한 호스팅 사이트가 있다.

2-1. github의 기능

저장소 호스팅
: 프로젝트의 소스 코드를 온라인에 저장하고 관리할 수 있다.
Pull Request 및 Issue Tracking
: 개발자들이 코드 변경 사항을 검토하고 통합하기 위한 매커니즘을 제공하며, 버그나 개선 사항을 추적할 수 있는 시스템을 제공한다.
문서화 및 위키
: 프로젝트 관련 문서와 정보를 저장하고 공유할 수 있는 위키 기능을 제공한다.

---

이제 실습으로 들어가보자.

어찌저찌 강사님과 옆 팀원분의 도움으로 git과 github 다운받는 데까지 성공했고,
이제 터미널을 열어.. 터미널 어떻게 여는데..?
맞다.. 나는 터미널 하나 열 줄 모르는데 맥북을 지른 것이였다..

그래도 맥북을 쓰면 나중에 이로운 점이 많다고 들어 자신을 위로하며 강의를 들었다🥹

놀라운 점은 로컬저장소를 만드는 단계부터 파일을 만들어 이 파일이 옮겨지고 저장되는 모든 상황들이 코드들로 만들어 진다는 것이였다.

마우스로 움직이고 다운받고 하는 것들이 코드들로 이루어 진 것이였다니,
나는 한번 더 흥미를 느끼던 것도 잠시.. 흥미와 재능은 별개라고 느꼈다.
코드들을 입력하고 있으나 눈에 보이지 않아 이게 맞게 되는 것인지 몰랐다.

실습을 하던 와중, 어느덧 마지막 수업이 끝이 났고 나는 이해가 되지 않는
것들을 부여잡고 강의실에서 나머지 공부를 이어갔다.

git add, git commit, git init....

1일 차 느낀점

첫 날 배운 git과 github 라는 프로그램을 접하며 IntelliJ로 단순히 코드만 잘친다고 되는 게 아니라는 걸 뼈저리게 느끼며 나는 첫날부터 남아서 복습을 했고,
다행히 혼자가 아닌 옆에 팀원분도 복습을 하고 간다고 하여 외롭지 않게 복습을 하였다.

---

Step.2 '내가 이렇게 열심히 살아본 적이 있던가?'

---

집과 거리가 꽤 멀어 40분~1시간이 걸려 9시까지 입실을 하기 위해 7시 기상을 했다.
아침까지 먹고 비몽사몽 준비하는 나를 칭찬한 것도 잠시..
강의를 들으며 나는 당황하기 바빴고, 점점 적응되는 IOS와 함께 점점 친해지는 옆에 팀원분들에게 도움을 받으며 강의를 이어나갔다.

오늘은 어제 배운 git과 github를 활용하여 시각적으로 표현해주는 GUI 도구인
Source Tree를 시작으로 VS Code를 배우는 날이다.

---

git & github 활용하기

1. Source Tree 란?

Source Tree는 Git 저장소를 시각적으로 관리할 수 있는 GUI 도구이다. 이를 통해 복잡한 명령어 없이도 브랜치 관리, 커밋, 머지 등을 직관적으로 수행할 수 있다.

한마디로 git을 활용하여 코드로 움직이는 모든 것들을 눈으로 볼 수 있게 해주는 프로그램인 셈이다.

드디어.. 지금까지 눈에 보이지 않아 답답하던 내 마음을 달래줄 프로그램이구나...!!!

---

2. VS Code 란?

VS Code는 마이크로소프트에서 개발한 소스 코드 편집기이다. 다양한 프로그래밍 언어를 지원하며, 확장 기능을 통해 기능을 확장할 수 있다.

사실, 나는 메모장에 개발에 필요한 기능이 추가된 거라고 이해했다.

---

여기서 활용되는 Branch에 대해서도 알아보자

3. Branch(나뭇가지, 분기)

위에서도 나온 내용으로 협업에 용이하게 사용되며, 터미널에 코드를 입력하여 작업한 게 소스트리에 나오는 게 나뭇가지 모양을 닮았다고 해서 유래된 것이라고 한다.

아래 이미지를 보면.. 나뭇가지처럼 보이진 않지만 나중에 복잡한 작업을 하게되면 나뭇가지처럼 뻗어 연결되서 보이게 된다.

실습으로 만든 나의 소스트리 첫 작업.. 맞게 한지는 잘 모르겠다..
나중에 보면 내 문제점이 보이겠지?

여기서 브랜치에 대해 설명하자면 main 브랜치가 있고,
main 브랜치는 원본 프로젝트라고 생각하면 된다.
그렇게 수정된 내용을 커밋 할 때마다 최신 업데이트되어
main 브랜치 포인터가 변경된다.

새 브랜치를 추가하게 된다면 이미지와 같이 옆에 다른 선이 생기고,
다른 선이 업데이트 내용이라고 보면 된다.

그렇게 업데이트에 문제가 없다면 main브랜치와 새 브랜치를 병합을 하고
이로써 최종 업데이트가 된다는 거다.

여기서 주의할 점

업데이트를 진행할 땐, 메인을 건들지 않고 브랜치를 통해 업데이트를 꼭 진행해야된 다는 점이댜.

주의할 점에 어느정도 이해는 했지만 설명을 잘했는지 모르겠다.

---

3-1. git Branch 전략 예시

(1). git flow

Git Flow는 명시적으로 버전관리가 필요한 이를 테면, 스마트폰 어플리케이션, 오픈소스 라이브러리/프레임워크 등의 프로젝트에 적합하다.

웹 어플리케이션은 특성상 사용자는 항상 최신의 단일 버전만을 사용하므로 여러 버전을 병렬적으로 지원할 필요가 없다. 또한 웹 어플리케이션은 하루에 몇 번이고 릴리즈될 수 있다. 이런 특성상 웹 어플리케이션 개발에 Git Flow는 다소 적합하지 않다.

• Master (Main)
  • Production 에 출시가 가능한 브랜치
• Develop
  • 개발이 완료 된 최신 브랜치
  • 신규 개발된 내역이 처음 합쳐지는 브랜치
• Feature
  • 각 기능을 개발하는 브랜치
  • 기능 개발 단위로 Feature 브랜치가 생성됨
• Release
  • Develop 브랜치에서 생성됨
  • 개발이 완료되어 출시를 위해 준비하는 브랜치
• Hotfix
  • Production 에 배포 된 버전에서 발생한 버그를 수정하는 브랜치

사실 오늘 강의중에 이 내용이 제일 이해가 쉬웠다.
왜냐면, 강의해주실 때 혼자 롤에 비유해서 생각했더니 이해가 빨랐다.

---

(2). github flow

GitHub Flow는 깃허브를 기반으로 한 간단하고 유연한 개발 워크플로우로 주요 목표는 신속한 배포와 효율적인 협업을 지원하는 것이다. Git Flow와 달리 단일 브랜치를 사용하여 개발하는데, 이는 하나의 버전이 만들어지면 바로 배포될 수 있다는 의미이다.

• 개발을 위해 마스터 브랜치에서 개발 브랜치를 생성한다.
• 개발자는 지속적으로 개발 브랜치에 코드 변경 사항을 제출한다.
• 작업이 완료되면 코드 검토를 위해 풀 요청을 제출한다.
• 검토 또는 검증 중에 코드를 마스터 분기에 동기화하거나 새 제출을 생성하여 검토 또는 검증 피드백에 응답한다.
• 코드 검토를 통과하고 개발 브랜치가 검증된 후 코드를 마스터 브랜치에 병합한다.
• 지속적인 배포를 위해 최신 버전의 프로덕션 환경을 배포한다.

main 브랜치 직접 커밋하는 경우는 맨처음 프로젝트만.

전략 한줄평

git flow는 게임 업데이트와 비슷
glthub flow는 웹 개발시 좋음

---

협업 실습을 하면서 위에서 설명은 안했지만, 코드들이 충돌하는 것에 대해 소스트리를 통해서 눈으로 확인하고 깃허브를 통해 이슈와 풀 리퀘스트를 주고받으며 팀원과 오류를 해결해 나갔고 병합까지 해보는 시간을 가졌다.

add, commit, push, pull, mergh....

이로써 이틀차가 마무리 되었다.
실습했던 걸 복습하는 차원으로 나머지공부를 어김없이 진행했고,
두시간 반정도 2명과 함께 실습했던 걸 다시 복습하는 시간을 가졌다.

나머지 공부가 끝나고, 공부에도 체력이 필요하니 좋은 의미로 런닝을 하러갔다가
체력이 너무 안좋다는 걸 깨닫고 자주 해야겠다는 생각이 들었다..

2일 차 느낀점

'아는만큼 보인다.'
어제 배운 git & github 를 소스트리로 대입하여 활용하니 어느정도 습득이 빨랐고, 눈에 보이니 더욱 흥미를 느끼는 시간이었다.
내일은 또 어떤 내용을 배울지 기대되고 점점 적성에 맞는 것 같아
희열을 느끼는중🔥

---

Step.3 습관들이기

이제 이른 아침을 맞이하는게 조금 피곤해졌다.
거즘 두달 가까이 밤낮이 왔다갔다 하는 탓이였을까..

어쩔 수가 있나.. 피곤한 몸을 이끌고 강의실로 향했다.

오늘 오전시간엔 어제 실습했던 것에 연장선으로 2명이서 하던 실습을
4~5명이서 하는 git & github 활용하는 실습을 했다.

---

어제 복습을 하고 집에 가서 그런지 어느정도 실습에 대해 적응이 되었고,
강사님이 선정해주신 팀원 5명과 의견을 주고 받았다.

협업 실습에는 아래 github의 기능을 사용하였다.

협업

1. 프로젝트 리더 설정과 세팅
2. Collaborators 메뉴로 팀원 초대
3. 프로젝트 이슈 생성
   3-1. 레이블 설정
   3-2. 마일스톤 설정
4. 프로젝트 설정

- 실습

우리 조 모두 이왕하는 거 도움되는 프로젝트를 만들기 위해 의견을 조율하다가 많은 시간을 보냈더니, 강사님이 주신 시간내에 못해서 완성하지 못해 아쉬움이 많이 남았다.😭

그래도 이제는 어느정도 나뭇가지의 느낌이 보여 신기했다 !
(나뭇가지같이 안생긴 거 저도 알아요. F 감성으로 갑시다.)

이 실습을 하며 느낀점

매니저님과 처음 했던 인터뷰가 떠올랐다.
프로젝트를 함께하는 팀원들과 의견 충돌이 있을 때 어떻게 할 것인지에 대한
질문이였다. 강사님께서도 팀원들과 의견을 주고 받을 때 싸우기도 한다며
점점 가슴에 와닿았다.

강사님의 버릇들이면 좋은 점 2개를 말씀해주셨고, 새겨들었다.
1. 말하는 연습
2. 자신의 코드를 남한테 보여주는 자세

내가 프로젝트를 할 때, 내가 꼭 전달해야되는 말을 습관들이기.

---

오후 시간에는 수강생 중, 질문으로 github 기능인 fork에 설명하는 시간과 활용하는 방법에 대해 설명해주시며 시작했다.

한마디로 다른 사람의 저장소(Repository)를 내 계정으로 복사해 오는 기능이라고 보면 된다.
사용방법을 실습을 해보긴 했지만 강의내용에는 없던 내용으로 자세하게 설명할 순 없는 점 이해바랍니다.........

아무튼, 오후에는 소프트웨어 개발 프로세스에 대한 이론을 배우는 시간을 가졌다.

---

소프트웨어 개발 프로세스의 정의

1. 소프트웨어 개발 프로세스의 정의

1-1. 기본 용어 정의

(컴퓨터) 프로그램
: 컴퓨터 명령어가 나열된 원시 코드(source code)

소프트웨어
: 컴퓨터에서 실행되는 모든 종류의 프로그램을 포함하는 넓은 개념이다. 하드웨어와 대조되는 개념으로, 물리적 장치가 아닌 데이터와 프로그램의 집합을 의미한다.

시스템 소프트웨어 (System Software)
: 운영 체제(OS)와 유틸리티 프로그램을 뜻한다. 하드웨어와 애플리케이션 소프트웨어 간의 중개 역할을 한다.
(ex. 윈도우, 리눅스, macOS, 안티바이러스 소프트웨어, 디스크 관리 도구)

응용 소프트웨어 (Application Software)
: 특정 사용자 작업을 수행하기 위한 소프트웨어를 뜻한다.
(ex: 워드 프로세서, 스프레드시트, 웹 브라우저, 게임, 메신저 등)

프로세스
: 주어진 일을 해결하기 위해 순서가 정해져 수행되는 일련의 절차를 뜻한다.
(ex: 요리 과정, 제품생산 과정, 다리나 건물의 건축 과정 등)

---

2. 주요 소프트웨어 프로세스 모델

2-1. 소프트웨어 프로세스 모델의 정의

소프트웨어 프로세스 모델은 개발 계획 수립부터 최종 폐기 까지의 전과정을 다루며 이러한 소프트웨어 개발 생명주기(Software Development Life Cycle)에 따라 어떻게 개발할 것인지 전체적인 흐름을 체계화한 개념이다.

요구사항 → 설계 → 구현 → 테스트 → 문서로 정리
모든 일의 순서로 생각하면 쉽다.
개발서에 요구사항을 들어주고, 설계단계를 거친 뒤 설계를 구현, 테스트를 반복하며, 최종 단계를 문서 코드를 짜고 작성하여 개발을 완성하는 과정인 것이다.

---

2-2. 폭포수(워터풀)

• 정의
  소프트웨어 개발의 전통적인 접근 방식이다.
  각 개발 단계(요구 사항 분석, 시스템 설계, 구현, 테스팅, 배포 및 유지보수)가 선형적으로 진행되며, 이전 단계가 완료된 후에만 다음 단계로 넘어간다.

• 장점

1. 구조가 명확하고 이해하기 쉽다
2. 각 단계의 명확한 구분으로 문서화가 잘 된다.
3. 큰 규모의 프로젝트나 변경이 거의 없는 프로젝트에 적합하다.

• 단점

1. 변화에 대응하기 어렵고 유연성이 부족하다.
2. 사용자 피드백을 개발 과정 후반에야 받을 수 있어, 초기 설계 오류의 수정이 어렵다.
3. 프로젝트 초기 단계에서 정확한 요구사항을 파악해야 하는데 이는 쉽지 않다.

글쓴이는 이 방법에 대해 설명을 들었을 때, 내가 정말 좋아하는 방식이다.
허술한 완벽주의자 성향이라, 처음에 완벽하게 하기 위해 시간을 갈아 넣는 성격이라 개발하는 데에 단점이라 생각하지만, 좋게 생각하면 집요하고 완성도 높은 작업물이 나올 것 같다는 생각이다.

---

2-2. 애자일 프로세스 모델(애자일 방법론)

• 정의
  변화에 유연하게 대응하고 고객의 지속적인 피드백을 수용하는 반복적인 개발 접근 방식이다.
  짧은 개발 사이클(스프린트)을 통해 지속적으로 제품을 개선한다.

  스프린트(sprint)
  : ‘전력 질주’를 뜻하며 작업량으로 볼때 그렇게 많지 않고 개발기간도 짧은 단위의
  작은 개발업무 동안 전력 질주하여 개발한다는 뜻이다.

• 장점

1. 빠르게 변화하는 요구 사항에 유연하게 대응할 수 있다.
2. 정기적인 피드백을 통해 고객의 요구 사항을 더 잘 반영할 수 있다.
3. 팀원 간의 긴밀한 협력과 의사소통이 장려된다.

• 단점

1. 프로젝트의 규모가 커지면 관리가 복잡해질 수 있다.
2. 문서화가 충분히 이루어지지 않을 수 있어, 프로젝트에 대한 이해도가 낮은 새로운 팀원의 참여가 어려울 수 있다.
3. 초기에 최종 비용과 시간을 추정하기 어려울 수 있다.

요즘, 개발자들 사이에선 애자일이 좋아지고 있다고 한다.
사용자/시장의 요구가 바뀔 때 빠른 피드백을 통해 유연하게 대응 가능하기 때문이라고 한다.

---

2-3. 폭포수(워터풀)와 애자일 비교

구분	폭포수	애자일(기민, 민첩)
추가 요구 사항의 수용	추가 요구사항을 반영하기 어려운 구조	추가 요구 사항을 수용할 수 있는 방법의 설계
릴리즈 시점	최종 완성된 제품을 릴리즈	수시로 릴리즈
시작 상태	시작 단계에서의 완성도가 매우 높음	시작 단계는 미흡, 점차 완성도가 높아짐
고객과의 의사소통	사용자와 산출물의 근거 중심, 대화 부족	처음부터 사용자의 참여 유도, 대화를 통한 개발 진행
진행 상황 점검	단계별 산출물에 대한 결과로 개발의 진척 상황을 점검	개발자와 사용자는 개발 초기부터 진행 상황 공유
분석/설계/구현 진행 과정	분석/설계/구현 과정이 명확	하나의 단계 또는 반복 안에 분석/설계/구현 과정이 모두 포함되어 동시에 진행
모듈(컴포넌트) 통합	구현이 완료된 후에 모듈 간의 통합 작업을 수행	개발 초기부터 빈번한 통합, 문제점을 빨리 발견하고 수정하는 방식

결론
어떤 방법론이 좋다 나쁘다가 아니라, 프로젝트 마다 맞는 방법론이 있다.

---

폭포수, 애자일의 이론이 끝나고 요구사항과 UML의 이론을 들은 후 실습을 했다.

여기서 UML이란,

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

---

실습은 draw.io 라는 사이트를 통해 진행했다.

대충 이런 사이트다. 다이어그램 도형을 손수 옮기는 번거로움이 있다.
실습 결과물에 대한 정답은 없지만, 강사님의 정답지를 공개해주실 예정이다.

3일차 느낀점

개발을 할 땐, 1인 개발자가 아닌 이상 함께 프로젝트를 하는 경우가 많을 것이다. 각자의 관점에 대해 의견을 나눌 때 의견 조율이 정말 중요하다는 걸 깨닫는 하루였다.
OT 때 자기소개를 했던 게 생각났다. 나는 내 성격에 대해 수강생들에게 소개를 했고 '친할수록 고집이 쎄다는 말을 한 게 감점이 되진 않았을까?' 라는 생각을 했다.

---

1 Week 느낀점

솔직히 아직 어려운 걸 안했고 어려운건가 싶다. 근데 어렵다고 느끼고 있다.
난 단지 적응이 안됐을 뿐이라고 생각한다.
제목과 같이 '시작이 반이다.' 라는 말처럼 생각하면, 나는 지금 반을 지나왔다.
앞으로 남은 반이 얼마나 길지 모두가 똑같을테지만 끝까지는 가야하지 않겠는가..
좋은 습관들이기, 팀원과의 완벽한 협업을 위하여 !

나란놈,, 오늘도 내일도 열심히 살기로 해.

다음주부턴 배운 것에 대해 복습하는 느낌으로 적을겁니다 ^^