CI, CD 인프라의 세상
이번 스프린트의 백엔드 과제는 CI, CD였다. 처음 접해보는 개념이라서 좀 쫄기도 했고, 어디까지 공부해야하나가 고민이기도 했다. 다행히 주말에 개인적으로 공부해온 후, 아루가 CI, CD에 대해 팀 블로그 글을 써서 강의를 해주었다! (갓아루🙏) 사실 쉘 스크립트 기반이라 이게 무슨 명령어인지 이해하는 것부터 어렵긴 했다. 그래도 물어보면 착착 알려주고, 때로는 혼자 생각해내게 닥달도(^^) 해주면서 점점 플로우를 이해해나갈 수 있었다!
떠올려보면 1차 데모데이 전날, 테스트가 터지는 버전이 develop 브랜치에 올라가서 pr을 몇 번이나 파서 fix를 했었었다. 이젠 CI가 되고나니 이런 불편이 해소되는구나! 막 적용하는 게 아니라 역시 불편을 경험하고 적용하니 제대로 기술을 적용하는 기분이다.
객체 지향 vs DB 관점
점점 서비스에 로직이 늘어나다보니 이렇게 서비스에 많은 로직이 있는 게 맞을까? 레벨 1 때 배웠던 객체지향은 어디로 갔지? 하는 문제제기가 백엔드 팀 내에서 있었다. 그래서 다시 한 번 정말 ‘객체지향적’으로 엔티티를 짜보자! 하는 시도를 하게되었다.(ps. 이 리팩토링 브랜치명은 pure-java-is-god 이었다🙏) 물론 객체지향적이게 짜려다보니 OneToMany나 양방향 연관관계 등도 마구마구 쓰이게되었지만, 비로소 서비스가 가벼워지고 각 책임에 맞게 로직들이 도메인 레이어로 분리되었다는 것을 느끼며 신나했었다.
하지만… 검증이나 비즈니스 로직을 적용하다보니 문제가 발생했다. 양방향 연관관계로 인해서 A 객체를 검증하는데 B 객체의 로직이 필요한데 이 검증 로직은 또 A 객체의 메서드를 사용하는, 순환참조 문제가 발생했다. 뿐만 아니라 비즈니스 로직이 도메인 레이어로 내려감에 따라 비즈니스 로직, 관련 검증 로직에 변화가 있을 때 도메인을 수정해야하면서 해당 도메인이 연관된 다른 곳에도 영향을 미치게되었다. 리팩토링을 하다 하다 이건 아니다 싶어서, 결국 jpa와 객체지향을 모두 잡을 수는 없는 건가? 서비스가 커지는 것을 감수해야하는 건가? 하는 결론을 잠정적으로 내렸다.(ps. 이 시기의 리팩토링 브랜치명은 we-are-lost 이었다😇)
고민 끝에 네오를 찾아갔고, 뜻밖의 결론을 얻게되었다.
우리가 자바가 익숙해서 그렇지 자바, 스프링을 안쓰는 사람들 입장에서는 객체지향을 약간 버리고 jpa에 맞춰서 코드를 짜는 것이 그렇게 문제될 일은 아니라는 것이었다. 우리 코드가 불편한 게 아니라 레벨 1을 배운 입장에서의 우리의 마음이 불편한 것일 뿐이라고.
레벨 1때는 객체 지향이 중요하다는 것을, 레벨 2 때는 jpa를 써야하는데 어떻게 객체 지향과 조율해야할지 고민하는 것을 배운 것이고, 레벨 3가 된 지금은 알아서 판단해라의 단계라고 했다. 연관관계가 필요한 경우를 트레이드 오프를 고려해서 판단해야하는 것이지 ‘레벨 1때 그렇게 배웠기때문에’는 이유가 되지 않는다는 걸 다시 한 번 깨달았다.
2차 데모데이
1차 데모데이는 기획 발표에 가까웠기때문에 2차 데모데이가 구현한 기능을 시연하는 첫 데모데이였다고 할 수 있다. 기능 시연과 CI, CD 적용 사항을 발표했고, 코치들이 피드백을 해주었는데 그걸 들으면서 무언가 와장창 깨지는 기분이었다. (좋은 쪽으로!)
핵심은, 우리가 핵심 기능에 필요하지 않은 것들을 구현하느라 시간을 쏟았고, 정작 ‘리뷰 작성과 확인’이라는 하나의 사용자 플로우를 보여주는 데는 미흡했다는 것이다.
- ‘리뷰 작성과 확인’이라는 한 싸이클을 사용자가 경험하게 하는데에만 집중해서 기능 구현을 했어야했다. 그래서 데모데이를 통해 그게 좋은 사용자 경험이었는지, 어떤 점이 좋지 않았는지를 파악하는 것을 목표로 했었어야했다.
- 사용자 경험 테스트를 위해 ‘더 좋은 질문’에 대해서 고민하고 적용하는데 시간을 들였어야했다.
- 그에 따라 엔티티도 다 짜놓고 시작하려고 하지말고 가볍게 시작했어야했다. 이번에 ERD 구조를 객체지향적으로 하냐, db 관점으로 하냐를 고민하는데 시간이 많이 걸렸다. 그 과정에서 핵심 기능에 필요하지 않은 ‘리뷰어 그룹’, ‘깃헙 로그인’ 등을 고려하다보니 엔티티 구조가 복잡해지고, 검증 로직을 짜는데 시간이 많이 들었다.
- 협업적으로도 느낀 것이 많았다. 결과물로 만들어진 서비스가 작아도 괜찮다는 것이었다. 하나의 기능 구현이더라도 고민을 많이 해보고 한 것이 더 중요하고, 결과보다 그 속에서 정립한 프로세스가 더 중요하다는 것.
현실세계는 불확실성이 높다. 따라서 좋은 결과도 망가질 수 있다. 하지만 협업, 프로세스가 잘 준비되어있으면 변화에 잘 대응할 수 있어서 오히려 항상 좋은 결과를 갖게된다.
폭풍같던 데모데이 이후 절치부심(?)해서 우리팀은 로그인이고 리뷰어 그룹이고 싹 다 빼고, 가장 빠르게 사용자가 우리 서비스의 ‘리뷰 작성과 확인’이라는 한 싸이클을 경험해볼 수 있게 기능 구현을 하는 것을 다음주 목표로 잡았다. 어떻게 보면 2주간 개발한 것을 지우고 다시 개발하는 것이기도 하지만 오히려 마음은 편했다. 우리가 ‘지금’ 해야하는 것이 비로소 명확해진 느낌이다.
