애자일 방법론, HTTP 상태코드

<<오늘 공부한 내용>>
애자일 방법론 - 스크럼
Rest API를 위한 HTTP 상태 코드

 

오랜만에 기말고사를 끝내고 돌아와서 다시 TIL작성을 시작한다.

오늘은 이번에 개발팀에 도입하게된 애자일 방법론 중 스크럼, 그리고 Rest API 응답코드에 대해서 써봐야지.

---

애자일 방법론 - 스크럼

짧았던 몇 개월동안 새로운 프로젝트를 진행하면서 느꼈던 것은 일정관리가 쉽지 않다는 것이다. 기획과 디자인이 완성된 상태에서 시작한 것도 아니고 기존 사이트의 유지보수도 함께 진행해야해서 예상했던 일정에서 계속 고쳐나가야 했다. 학교 중간, 기말고사까지 겹쳐 일정이 밀리고 밀리는 과정에서 '아.. 대책이 필요하다'라는 생각이 들었다.

 

소프트웨어 공학이라는 수업에서 배웠고, 정보처리기사에서 한번 더 공부한 애자일 방법론이 생각났다. 빠른 반복 작업을 통해 개발을 해나가는 방법론. 그 중에서 '스크럼'이라는 방식을 도입해보기로 결정했고 어떤 식으로 스크럼을 이해했는지 간단하게 작성해본다.

 

• 추구 가치
  • 용기 : 옳은 일을 할 수 있도록 팀원간 갈등과 도전을 위한 용기를 가져라!(설명 : 해당 기능이 이해가 안되거나 문제가 있다면 말할 수 있어야 하고, 더 일을 잘 할 수 있는 환경을 요구하고, 자신의 신념을 설득 시켜야 한다. 또한 도전적으로 시도해보는 용기와 완료 할 수 없는 업무량이라고 모두 말 할 수 있어야 한다.)
  • 집중 : 할 일을 하라. 모든 노력과 기술은 성공을 위해 집중하고, 그 외는 걱정(신경쓰지) 마라!(설명 : 한번에 하나의 일부터 마무리하고, 업무에 집중 할 수 있도록 불필요한 회의 참석은 지양하며, 루틴한 반복 작업은 제거 하거나 자동화해야 한다.)
  • 약속(헌신/책임) : 팀의 목표 달성을 위해 개개인이 공약한 목표 달성을 위해 팀에 헌신하며, 이를 달성 위해 필요한 모든 권한을 부여하라!(설명 : 개인보다는 팀성과 달성이 우선이고, Value 있는 SW를 개발 할 수 있게 최대한 지원과 권한이 필요하다.)
  • 존중 : 경력과 경험이 사람을 만든다. 팀원들을 존중하라!(설명 : 개개인별로 장단점이 있고, 그 사람이 그렇게 할 수 밖에 없는 이유가 있을것이다.)
  • 투명성/개방성 : 프로젝트에 대한 모든 내용을 투명하게 공개하라!(설명 : 제품백로그, 스크럼 회의, 스프린트 리뷰를 통해 공유되며, 자신에게 불리해도 숨기지 않고 도움을 요청한다.)
• 주요 역할자
  • 제품 책임자(Product Owner)
    • 제품 백로그(요구사항) 관리/설명
    • 제품 백로그의 우선순위 관리
    • 만족스럽게 개발되었는지 확인
  • 스크럼 마스터(Scrum Master)
    • 팀을 보호하고 장애 요소를 해결
    • 일일 스크럼 회의를 진행
    • 모니터링 및 Tracking
• 용어
  • 제품 백로그(Product Backlog) : 개발할 제품의 요구사항인 사용자 스토리 집합이며, 우선순위로 관리 -> 기획팀에게 요구사항을 받으며 가능 여부에 따라 주기적으로 피드백하는 프로세스를 결정했다
  • 스프린트(Sprint) : 계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택 -> 우리팀은 소규모니까 1주로 잡아야지
  • 스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의(4주 스프린트 기준 8시간 정도 수행)
  • 스프린트 백로그(Sprint Backlog) : 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록
  • 칸반 보드(Kanban Board) : 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판 → 트렐로로 칸반보드를 작성하기로 결정!
  • 일일 스크럼 회의(Daily Scrum Meeting) : 매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의(매일 15분 정도 수행) -> 출근 시간 및 요일이 다르기 때문에 매일 슬랙에 간단하게 작성하기로 했다
    • 장애요소는 화이트보드에 적어놓고 지속적으로 해결한다. 만약 해결보다 쌓이는게 만다면 회사는 팀을 충분히 지원하지 않는 것이며, 일일 스크럼 회의는 생산적이지 않은 낭비로 인식된다.
  • 스프린트 리뷰(Sprint Review) : 스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토(4주 스프린트 기준 4시간 정도 수행)
  • 스프린트 회고(Sprint Restospective) : 스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선(4주 스프린트 기준 3시간 정도 수행)
• 스크럼 진행 순서
  1. PO는 제품의 요구기능(User Story)과 우선순위를 제품 백로그로 정한다.
     • 개발팀원 각자: 요구사항에 우선순위 매기기
  2. PO가 정한 제품의 우선순위에서 어디까지 작업을 할지 팀과 조율 한다.
     • 개발팀 회의: 백, 프런트 api 회의 및 일정 공유
  3. 스프린트 목표를 구현 가능 하도록 팀에서 스프린트 백로그를 작성한 뒤 작업을 할당한다.(해설:PO는 기능과 우선순위에 대한 권한이 있고, 개발팀은 Sprint내에 해야 할 업무량을 결정할 권한이 있다. 특히 개발경험 있는 PO가 너무 적은 개발량을 문제제기 하기도 하지만, 실제 개발하는 개발팀원의 개발속도(Velocity)로 예측하며 조정이 중요하다.)
     • 스프린트 주기: 1주
     • 트렐로 활용
  4. 스프린트를 진행하는 동안, 매일 정해진 장소와 시간에 모든 개발 팀원이 참여하는 일일 스크럼 회의를 가진다.
     • 슬랙 채널 새로 파서 매일 올리기
     • 매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유(15분 정도)
  5. 매회의 스프린트가 종료할 때마다, 스프린트 리뷰(Review)를 통해 만들어진 제품을 검토하고 개선사항을 이해 한다.
  6. 제품의 리뷰를 통해 제품의 지속적 개선사항 도출이 끝나면, 스프린트 회고(Retrospective)를 통해 팀의 개발 문화(프로세스)에 대한 개선의 시간을 갖는다.(해설:스프린트 Review는 제품을 개선하는 활동이고, 회고는 우리(프로세스, 문화)를 성장시키는 활동이다.)
     • 스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선
  7. 다음 스프린트에서 수행할 백로그를 PO와 필요 인원이 모여 선정하고 계획하는 시간을 갖는다.

---

Rest API를 위한 상태 코드(참고)

프런트엔드와 API에 대해 회의하면서 어떤식으로 보내면 좋을까 고민하다가 공부한 내용이다.

현재 백엔드를 개발할 때 Rest 방식으로 API를 개발하고 있는데 다양한 프로토콜들 중에서 웹 환경에서 대부분 사용하는 HTTP 프로토콜을 사용하고 있다. 그래서 HTTP 요청이 성공했는지 실패했는지 클라이언트에 알려주기 위해 HTTP 상태 코드를 적용해보려고 한다.

흔히 아는 404 not found 말고 어떤 응답 코드가 있고, 어떤 식으로 보내면 좋을 지 찾아보고 프로젝트에 직접 적용시켜 보았다.

 

200번대 (성공)

• 200 ok: 클라이언트의 요청을 서버가 정상적으로 처리. 대부분 성공의 경우에 200으로 응답한다.
• 201 created: post, put에 대한 응답으로 주로 사용. 성공과 동시에 새로운 리소스가 생성되었따! http 헤더의 content-location으로 생성된 리소스의 위치 알려줄 수도 있다는 점.
• 202 accepted: 작업에 시간이 걸리기 때문에 나중에 알려주겠다는 의미. 비동기 개념
• 204 no content: 요청은 정상적이지만 따로 리턴 컨텐츠는 없음.

400번대 (요청 유효X)

• 400 bad request: 클라이언트의 요청이 유효하지 않아 작업 진행 안함. 오류 발생 시 파라미터의 위치, 입력값 등 에러 이유 명시해주기
• 401 unauthorized: 클라이언트에 권한이 없어서 작업 진행 안함 -> 인증을 안했다
• 403 forbidden: 클라이언트에 권한이 없어 작업 진행 안함 -> 인증은 했는데 권한이 없다.
• 404 not found: 클라이언트가 요청한 자원이 존재하지 않음
• 405 method not allowed: 허용되지 않은 http method다.
• 409 conflict: 클라이언트의 요청이 서버의 상태랑 충돌. 로직상 수행 불가.
• 429 too many requests: 클라이언트가 일정 시간 동안 너무 많은 요청 보냄

500번: 서버 에러