1. 소프트웨어 개발 Plan

  • 요구조건은 계속해서 변화함
  • 디자인 시 모든 문제를 미리 알 수 없음
  • water-fall 모델은 소프트웨어 개발에 부적합
    • 속도에 더 치중하는 것이 일반적

애자일 개발 방법론 (Agile Development)

  • 짧게 자주 반복해서 계산해 나가자!
  • 아는 만큼, 보이는 만큼 만들어가자
  • 개발 단위가 짧은 사이클이 됨 = 스프린트 (Sprint)
    • 보통 2주

매 사이클마다 다음 작업 반복

  • 작업 별로 우선순위 결정 (Backlog Prioritization)
    • 보통 PM들이 수행
    • Grooming이라고도 부름
    • 각 작업별로 중요도와 복잡도 결정 (Point)
    • 미리 우선순위를 만들어놓아야 함 - 그렇지 않을 경우 Planning이 길어짐
  • 이번 사이클에 일할 작업 결정 (Planning)
  • 매인 Standup 미팅 (5분-10분)
    • 상황 빠르게 공유 & 문제 상황 공유
  • 마지막 날 Retrospective & Demo 미팅
    • 잘 된 부분, 아쉬운 부분, 개선할 점 등 회고
    • 이번 스프린트에 무엇을 했는지 시각화하여 공유

스프린트 카드 예제

  • 타이틀
    • 작업 타이틀
  • 세부설명
  • 포인트 (숫자)
    • 중요도와 복잡도
  • 성공의 정의
    • Definition of Done
  • 체크리스트
    • 이 작업이 성공적으로 끝나는데 필요한 세부 작업들


  • software
    • JIRA
    • Trello

플래닝 포커 (Planning Poker)

  • 작업별 일정 산정 기법
    • 작업별로 포인트를 산정
    • 포인트의 정의는 회사마다 다름
      • ex) 1 포인트는 1 full day for a developer
  • 개발자들이 모여 다 같이 작업별로 들어가는 일정을 산정하는 방법
    • 일정의 투표
    • 너무 다른 의견들이 존재할 경우 약간의 토론을 거쳐 어느 정도 수렴할 때까지 진행

일일 스탠드업

  • 매일 모든 팀원들이 10-15분씩 모여서 각자 상황 공유 : 빠르게 !!
  • 공유 내용
    • 마지막 스탠드업 이후로 한 작업들
    • 오늘 하려고 하는 일이나 진행 중인 일
    • 일을 함에 있어 문제가 있거나 도움이 필요하면 언급
  • 논의가 필요한 일들은 스탠드업에서 다루는 것이 아니라, 따로 모여서 회의를 진행해야 함

2. 개발 시작 / tracking

흔히 사용되는 툴

  • JIRA
    • 프로젝트 관리를 위한 전반적인 기능을 제공하는 툴
      • Agile Scrum 관리 툴, SVN, Wiki 등
    • 많은 수의 회사들이 프로젝트 관리를 위해 사용
  • Trello
    • Agile Scrum 관리를 위한 툴
    • JIRA에 비해 훨씬 더 직관적인 단순한 인터페이스 제공
    • JIRA가 최근 인수해서 결국 같은 회사가 됨

3. 소스 버전 컨트롤

  • 개발자들이 자신이 개발하는 소프트웨어의 소스 코드에 발생하는 변경사항들을 관리할 수 있도록 해주는 시스템

  • 코드에 생기는 변경사항을 쉽게 추적할 수 있음
    • ex) 에러 발생 시 이전 버전으로 Rollback
  • 두 사람 이상이 공동 개발 시 코드의 공유와 변경이 용이
  • 최근 시스템들은 코드리뷰도 지원
  • 코드 백업의 역할 수행

소프트웨어

  • CVS (Concurrent Version System)
  • SVN (SubVersionN)
  • Git/Github
    • 가장 인기있는 버전 컨트롤 소프트웨어
    • 웬만한 오픈소스 소프트웨어들은 Github 상에 존재
    • GitHub == Git + Bug Tracking (Issue) + Wiki on Cloud

코드 리뷰

  • 주니어 개발자나 새로 온 개발자들을 트레이닝 시키는 최선의 방법
  • 단점은 리뷰를 해야 하는 사람들이 이미 바쁘다는 것!
    • 스프린트 플래닝시 이를 고려하여 태스크 할당해야 함


  • 좋은 코드 리뷰 방법
    • 요청하는 이
      • 되도록 조금씩 자주 요청, Unit test와 같이 요청하면 최상
      • 주석을 최대한 추가하고, 무슨 이유에서 무엇을 하려고 하는 것인지 설명
    • 리뷰하는 이
      • 코딩 스타일에 대한 것보다는 코드 자체에 대해 이야기
      • 충분히 시간을 들여 도움이 되는 리뷰 제공
    • 코드 리뷰에 편리한 툴 사용


  • Github
    • 이전 코드와 새로 들어간 코드를 highlighting 하여 보여줌

4. Test

  • 테스트가 기본 ! !
  • 개발 시 테스트를 어떻게 할 것인지부터 생각
    • 테스트 코드부터 작성
  • 코드 구성 자체가 테스트에 편리하게 되는 효과
    • 자신이 만드려는 기능에 대해 더 생각하게 됨
    • 코드 자체가 잘 구성되어 있지 않으면 테스트가 불가능

테스트 종류

  • Unit Test
    • 모듈의 특정 기능 (함수) 테스트
    • 보통 테스트라고 하면 유닛 테스트를 말함
  • Integration Test
    • 여러 모듈을 통합하여 하는 한 차원 위의 테스트
  • Acceptance Test
    • 트래픽이 몰릴 때 견딜 수 있는지 테스트
  • UI Test
    • 요즘은 Selenium 등의 툴을 이용해서 웹페이지 자체의 기능을 테스트하는 것이 대세

테스트의 중요성

  • 많은 회사들이 코드 변경의 일부로 Unit Test를 의무적으로 요구
    • 테스트가 없으면 아예 코드 체크인이 실패
  • 테스트가 많을수록 이점이 증대
    • 시스템 안정성 증대
    • Refactoring 할 경우, 혹은 신입 엔지니어가 코드를 수정할 때 편리
  • 테스트를 작성하기가 너무 힘든 경우에는 스프린트 플래닝 때 시간을 넉넉히 배당

5. Build

  • 자신(팀)이 개발한 소프트웨어를 최종적으로 출시하기 위한 형태로 만드는 것
    • 테스트가 빌드의 중요한 일부로 포함
  • 개발이 끝나기 전부터 빌드를 하면 소프트웨어의 안정성 증대
    • Continuous Integration!

Continuous Integration (CI)

  • 코드 변경시마다 테스트를 다 돌리는 것

  • 코드 Repo는 하나만 유지 (Master)
  • 코드 변경을 최대한 자주 반영
  • 테스트를 최대한 추가
    • Test Coverage
  • 빌드를 계속적으로 수행 (자동화)
    • Commit Build vs. Nightly Build
  • 성공한 빌드의 프로덕션 릴리스 (자동화)

빌드 실패

  • 많은 회사들이 빌드 실패시 빌드가 다시 성공할 때까지 코드 변경 금지 -> 모든 사람들을 잡아두게 됨
  • 어느정도 조직이 커지면 빌드만 전담하는 엔지니어가 생김
  • 빌드 실패시 가벼운 형태로 패널티를 부여하기도 함 :)

Jenkins

  • 오픈소스 CI 빌드 소프트웨어
    • CI와 관련한 모든 기능 지원
      • 플러그인의 형태로 지원
  • 빌드된 소프트웨어의 배포 (릴리스)를 위해서도 사용 가능

Github과 연동되는 CI 서비스

  • Github Actions
  • Travis CI
  • Circle CI
  • …

6. Git

  • 분산 환경을 지원하는 소스 버전 컨트롤 시스템
    • branch (원본의 copy본)를 만들어 거기에 작업을 함
    • 분산 환경 : copy본이 내 local에 존재하여 local에서 작업 가능 -> 서버로 업로드 -> merge
    • 서버에 연결이 되지 않아도 작업 가능

  • CVS, SVN은 항상 서버에 연결되어 있다는 전제 하에 사용 가능했음

  • 다수의 개발자가 공동 개발
  • 코드 리뷰 가능
  • 코드 백업

  • 과거의 코드로 롤백 가능

  • 팀원들과 같이 코딩 가능, 코드 충돌이 생기면 해결 가능
  • 코드 변경을 주기적으로 저장하면서 리뷰를 받을 수 있음
  • 모든 코드 변경 기록됨
  • 지금 코드의 스냅샷(버전)을 잡아 나중에 필요시 버전 간 이동 가능

  • 꼭 코드 뿐만 아니라 모든 텍스트 파일에 사용 가능

  • 기본 기능 : clone, init, add, commit, push, pull, merge, branch, checkout
  • 고급 기능 : rebase, cherry-pick.reset, revert, git-flow

7. Git 관련 용어

  • Repo
    • Repository
    • Git으로 관리되는 소프트웨어 프로젝트
  • Master/Main
    • 한 Repo에서 기본이 되는 메인 코드
    • Source of Truth
  • Branch
    • 자신의 Repo에서 새로운 기능 개발 등을 위해 Master 혹은 다른 Branch로부터 만든 코드 작업본
    • 작업 후 나중에 원본 Branch와 다시 병합하려는 목적으로 만들어짐
  • Clone
    • 다른 계정에 존재하는 Repo로부터 새로운 Local Repository를 만드는 것
  • Commit (Check-in)
    • 내가 만든 코드 변경을 Branch의 Local Repository에 반영하는 것


  • 작업은 항상 내 컴퓨터에 있는 Local Repository에서 일어나며 Pull, Push를 통해 Git 서버 상의 Remote Repository와 연결됨

  • Pull
    • Master와 같은 Remote Repository로부터 마지막 Pull 이후 변경된 것을 다시 가져오는 작업
    • Master (혹은 Branch)와 동기화하는 것
    • 출근해서 가장 먼저 하는 일 : Git Pull !!
    • Remote -> Local
  • Push
    • 본인이 작업 중인 로컬 복사본 (Local Repository)에서 서버 (Remote Repository)로 변경사항들을 복사하는 것
    • Local -> Remote
  • Merge
    • Pull이나 Push 했을 경우 두 Branch (대부분 이 둘 중 하나는 Master) 간의 충돌(Conflict)을 해결하는 과정
    • 많은 경우 이는 자동으로 해결되나, 몇몇 경우에는 직접 손으로 충돌을 해결해야 함
  • 전체 플로우
    • master/main -> Remote Branch 브랜치 생성
    • Remote Branch -> Local Branch : pull
    • Local Working Copy -> Local Branch : commit
    • Local Branch -> Remote Branch : push
    • Remote Branch -> master/main : merge

8. 시나리오

  • Branch 생성 git checkout -b 브랜치이름, git branch 브랜치이름
    • 새로운 repo를 만드는 경우에는 git init부터 사용
  • 새 Branch로 작업 공간 이동 git checkout 브랜치이름
  • 해당 Branch에서 코드 변경 후 커밋 git commit -m "메세지" 파일이름
  • 해당 Branch에서의 변경을 서버로 반영 git push -u origin 브랜치이름
  • 해당 Branch와 Master의 Merge를 위한 리뷰 요청 (Pull Request)
    • github.com에서 UI를 이용하여 요청 !
    • git request-pull
  • 다른 개발자가 코드 리뷰 후, 직접 Merge 하든지 Merge 해도 좋다고 응답
    • 문제가 있을 경우 그 내용을 답변으로 보냄 (Request changes / Comment)

Pull Request

  • 보통 자신의 branch를 master에 merge하고 싶을 때 다른 이들에게 코드 리뷰를 요청하는 용도로 사용
  • Pull Resquest에는 일련 번호가 붙으며, 쉽게 revert 가능
    • 즉, 이전 상태로 돌아가는 것이 쉬움

9. Github

  • Git repo 호스팅/클라우드 서비스
  • 문서화를 위한 Wikis와 버그리포트와 트랙킹을 위한 Issues 제공
  • 자신이 만든 repo들이 public일 경우 무료
    • private repo 수에 따라 가격대가 결정됨