우리는 왜 CI/CD에 실패하였는가?

이전글에서 필자는 필자가 생각하는 CI/CD에 대하여 논하였다. CI/CD란 무엇인가?

CI/CD란 무엇인가?

 

그렇다면 이번 글에서, 왜 필자가 이번 프로젝트에서 CI/CD를 실패했다고 생각했는지에 대하여 작성해 보도록 하겠다.

 

엄밀히 말하자면 필자는 CD보다는, CI에 실패했다고 생각하고 있다. 이전글에서도 말했듯, CI의 가장 큰 목적은 머지데이의 안좋은점을 제거하는데 있다고 생각한다. 하지만 프로젝트를 진행하면서 나름 치밀하게 CI/CD를 구축했다고 생각했음에도 불구하고 언제나 코드를 머지할때면 수 많은 Merge Confilict에 치이고 말았다.

이러한 상황은 필자를 "이게 정말 CI가 구축된것이 맞는가?" 란 의문으로 이끌었다.

 

이에대한 분석을 진행한 결과, 결국 모든 문제는 PR에서 부터 시작됐다는 결론을 내리게 됐다.

 

1. PR의 크기가 너무 크다

필자가 속한 깃들다팀은 모든 PR에 대하여 팀원들의 Approve가 있어야지만 PR의 Merge가 가능하도록 컨벤션을 만들었다. 그 말인 즉슨, 팀원들이 코드를 읽고, 피드백을 남겨야 한다는 것을 의미하게 된다.

 

위 숫자를 보자, 필자가 속한 팀의 PR Line수를 3개정도만 임의로 가져온 것이다. 기본적으로 항상 1000줄에 가까운 Line수를 보인다. 이러게 많은 Line의 추가와 File Changes는 코드리뷰의 병목을 가져올수밖에 없다. 각각의 팀원들도 자신이 맡은 일이 있기때문에 다른 팀원의 코드에 많은 리소스를 쏟을 수 없다. Line의 기술블로그 를 읽어보면 코드리뷰에 대하여 많은 팁을 제공하고 있으며 공통적으로 하는 말은 리뷰의 시간과 리소스를을 짧고, 적게 가져가자로 귀결된다. 그렇다. 결국 이러한 큰 PR단위가 CI를 망치는 주된 원인이 된 것이다.

아직까지는 감이 오지 않는 독자가 있을것이다. 그렇다면 필자는 큰 PR단위가 무엇이 문제이기에 CI를 망쳤다고 주장하는것일까?

 

2. PR이 너무 많이 쌓인다.

큰 PR단위는 결국 리뷰의 병목을 발생시키고 PR이 쌓이도록 유도한다. CI의 목적이 무엇인가? 이름 그대로 코드의 지속적 통합이다. 하지만 PR이 쌓인다는것은, 지속적인 통합이 진행되지 않고, 통합이 계속 미뤄진다는 것을 의미한다. 이제 눈치를 챘는가?? 큰 PR이 지속적으로 쌓이면 어떤 문제가 발생할지.......

 

3. 결국에는 또 다시 머지데이로...

그렇다. 큰 PR이 수십개 쌓이는 순간 머지데이의 늪에 또 다시 빠지게 된다. 수십개의 파일 변경과 수천라인의 PR이 적개는 몇개, 많게는 수십개 쌓였다면 이를 머지하는데 또 다시 다른 PR과의 병합을 해결해야 한다. 또한 지속적인 코드 병합에 실패하면서 지속적 통합이라는 그 근본에도 접근하지 못하게 된다. 이것이 과연 올바른 CI라고 할 수 있을까?

 

실제로 프로젝트를 진행하면서 이렇게 쌓인 PR은 데모데이 전날에 다함께 모여 후다닥 Merge하는 형태로 이어졌다. 이것도 머지데이의 차이점이 무엇인가? CI를 힘들게 구축해놓고 또 다시 과거의 머지데이를 반복하는꼴이 돼버렸다.

 

 

결론.

이번 글에서는 왜 필자의 프로젝트에서 구축한 CI가 실패한 CI라고 생각했는지에 대하여 작성해봤다. 정말 아이러니하게도. CI프로세스 자체는 제대로 구축되어 있었으나, 그 실패의 원인은 전혀 다른곳에 있었다.

작은 PR 법칙이 왜 존재하는지 또 다시 체감하였다. 그렇다면 이를 깨닫고 필자는 작은PR법칙을 잘 지키고 있냐고 물어본다면 대답은 NO다. 아직까지는 PR의 크기를 나누고, Issue의 발행 단위를 제대로 나누는 연습을 더 해야한다고 생각한다. 이론적으로는 이해했지만 아직까지 적용하기에는 내공이 부족한 것 같다.

 

이 글을 통해 CI/CD 프로세스를 구축하는것만으로 만족하지 말고 힘들게 구축한 프로세스를 제대로 활용할 수 있는 힌트가 되었으면 한다.

 

 

reference

https://blog.banksalad.com/tech/banksalad-code-review-culture/

코드 리뷰 in 뱅크샐러드 개발 문화 | 뱅크샐러드

https://engineering.linecorp.com/ko/blog/effective-codereview/#send-pull-request-early

효과적인 코드 리뷰를 위해서 - LINE ENGINEERING