안녕하세요.

자율프로젝트 삼성SDI 기업연계 S106 어프로브 조의 발표를 맡은 저는 발표자 이지영입니다.

그럼 JIRA API를 활용한 프로젝트 관리를 주제로 진행한 저희의 CO:RE 발표 시작하겠습니다!

발표순서로는

프로젝트 배경과 기능소개, 기술스택과 시스템구성도, 기대효과 후 마무리 하겠습니다.

저희는 JIRA API를 활용한 프로젝트 관리라는 주제로 배포되는 내용에 대한 정리와

동료의 코드리뷰가 원활히 진행되고 있는지 관리와 모니터링이 필요함을 목표로 명세서를 받아 프로젝트를 구상 하였습니다.

프로젝트의 필수 구현 기능들과 추가 구현기능들을 모두 구현하더라도 프로젝트의 목표중 하나인 코드리뷰측면을 만족시킬 수 없다고 판단하여

프로젝트 관리와 코드리뷰 그리고 개발 이슈에 중점하여 프로젝트를 재구성 해 보았습니다.

그렇다면 개발자에게 코드리뷰란 무엇일까요? 여러분께서는 프로젝트를 진행하며 코드리뷰 잘 진행되고 계실까요?

누군가는 코드리뷰를 단순한 오류 검출을 넘어, 전체적인 팀의 기술력과 개인의 성장 그리고 협업능력을 강화해준다고 말합니다.

또다른 누군가는 부담스럽고 피로감있는 형식적인 절차라고 평가하기도 합니다.

• X 그럼에도 불구하고, 코드리뷰는 팀 내의 코드 일관성과 유지보수성, 그리고 지식공유의 중요한 수단입니다. 그렇게 저희는

저희 코리는 배포 버전에 대해 내용을 요약하여 관리할 수 있고, 사용자별 커밋과 이슈, PR과 리뷰에 대한 통계를 제공해 드립니다. 또한, PR에 대해 리뷰어를 자동으로 할당하여 주는데 이때, 리뷰어는 현재 쌓여있는 PR과 진행중인 이슈를 체크하여 자동으로 할당하여 드립니다. 개인이 해결할 수 없는 이슈를 등록하여 다른 팀원에게 재할당 및 분배하고 개인별 리뷰와 이슈에대해 일자를 지정하여 일정을 관리할 수 있도록 하였습니다.

-X 그럼 저희의 코리 프로토타입 화면을 만나보겠습니다. -O 대시보드 페이지에서는 버전별로 패치노트를 조회 및 수정할 수 있고, 개인이 올린 커밋과 리뷰, 이슈와 PR의 통계를 확인하실 수 있습니다. 또한, 개인에게 할당된 PR 리뷰목록과 이슈항목에 대해 Deadline과 상태를 체크할 수 있습니다.

PR페이지에서는 보낸 PR과 받은 PR을 분리하여 보여주며 PR의 응급도와 코드리뷰 마감일자와 리뷰 갯수 그리고 상태를 확인하실 수 있습니다.

또한 리뷰어는 코멘트 뿐만 아니라 Gerrit의 점수제를 적용하여 특정 점수를 넘겨야지만 PR을 Merge할 수 있게 기획하였습니다.

해당 페이지는 Issue 페이지로 본인이 해결할 수 없는 이슈를 등록하거나, 할당받은 이슈를 해결할 수 없을때 재배치를 요구할 수 있는 페이지 입니다.

달력페이지에서는 개인에게 할당되어 현재 남아있는 코드리뷰 혹은 이슈의 마감일자를 확인하실 수 있습니다.

저희는 프로그램을 기획하며 안정성을 바탕으로 데이터의 신뢰성을 높인 프로그램을 개발하고자 했습니다.

그렇다면 그러한 안정성과 데이터 신뢰성을 위하여 저희는 어떠한 기술스택을 적용했을까요?

첫 번째로 고려한 기술스택은 MSA 입니다. 기존의 모놀리식 시스템은 단일 애플리케이션으로 이루어져 있어 특정 부분에 문제가 발생하면 전체 시스템 장애로 이어지게 됩니다. MSA는 특정 서비스 장애가 타 서비스에 영향을 최소로 주거나 아예 주지 않도록 구성이 가능하므로 프로젝트 진행에 영향을 최소화 하기 위해서 MSA를 적용하였습니다.

두 번째로, 서킷 브레이커 패턴입니다.

저희 프로젝트에서는 github와 jira api가 주요 기능의 응답시간에 영향을 줄 수 있기 때문에

호출한 다른 서비스에 장애가 발생했다면, 그로 인해, 해당 서비스까지 문제가 발생할 수 있습니다. 또한, 지속적으로 장애가 발생한 서버에 계속 요청을 보내는것은 리소스가 낭비됩니다.

이럴때, 호출이 실패시 일정시간 동안 해당 호출을 차단하여 시스템의 추가적인 부하를 방지하고, 특정 시간이 지난 후 외부 서버가 복구되면 상태를 자동으로 복구하는 서킷 브레이커 패턴을 적용할 수 있습니다.

서킷 브레이커 패턴을 활용하여 장애가 발생한 서비스가 안정될 때까지 요청을 중지하고, 장애가 발생한 서비스가 더 이상 쓰레드와 메모리 등의 자원을 점유하지 못하도록 막을 수 있습니다. 또한, 주기적으로 서비스의 복구상태를 확인하고, 가능한 빠른 실패를 반환하여, 사용자에게 빠른 응답을 전달할 수 있습니다. 더불어, 외부에서 발생한 장애에 대해 다른 소스로부터 값을 얻거나, 서킷 브레이커가 자체적으로 캐싱해 둔 값으로 응답하는 등 다양한 방법으로 장애 대응이 가능하므로 서킷 브레이커 패턴을 고려하였습니다.

세번째로, 카프카 입니다.

kafka는 전달한 데이터를 가져갈 때까지 메세지를 유지할 수 있습니다. 즉, 트래픽 스파이크 상황에서 데이터를 임시로 저장하고 처리 속도를 조절함으로써 시스템 과부화를 막을 수 있습니다. 또한 외부 서비스에 많은 요청이 가면 응답시간이 지연되는 문제가 발생할 수 있습니다. 카프카를 활용해서 외부 서비스와 비동기 통신을 통해 성능을 개선하고자합니다.