오늘은 첫 3계층 웹 프로젝트(Static Server - Api Server - Database)를 진행하면서 느낀 클린 코드에 관한 나의 생각을 공유하고자 포스팅 하게 되었다.

2020년도 4월 초부터 진행한 webper 프로젝트(Github저장소)는 Api 서버로 spring boot를 사용하고 있고, 클라이언트에게는 React기반의 View를 서비스할 Static Server를 두고 있다.

우리 팀은 프론트 앤드 개발자 2명과 백 앤드 개발자 1명으로 구성되어 있는데, 프론트 앤드 개발자 중 한명은 휴학생 이다.

휴학을 하신 프론트 앤드 개발자 분(이하 A)께서는 휴학을 하시다 보니, 학기 중에 다른 팀원에 비해서 상대적으로 시간이 많았다.

클라이언트의 개발 속도가 Api서버의 개발 속도보다 훨씬 빨랏고 결국, A는 테스트 서버(데이터만 주고 받을)를 직접 만들어 나름 데이터를 정의해 개발을 진행했다.

학기가 끝난 후, A는 잠깐 서울에 가게 되고, 백앤드 개발자(이하 ‘나’) 와 또 다른 프론트 개발자(이하 B)만 남게 되었다.

나는 Api서버에 Spring Security를 사용해 인증 까지는 구현했으나, 그 이후로는 진행이 많이 되지는 않은 상황이었다.

나는 A가 서울에 가기전에 적어주고 떠난 데이터 명세 ppt를 보고 클라이언트 쪽 프로세스를 유추해 가면서 객체 지향적으로 api 서버를 구축 하기 위해 노력하였다.

아래 그림은 A가 건내준 데이터 명세 ppt의 일부이다.

A가 없는 3주의 시간동안 나름 객체 지향적으로 api서버를 구축하였고, 문서화 및 CI/CD도 진행하였다.

A가 돌아오고 난 후, 우리 팀은 프로젝트를 마무리 짓기 위해 백과 프론트 사이에 통신을 주고 받았고 이 과정에서 정말 자잘한 이슈가 계속 생겼다.

대부분의 이슈는 프론트 단에서 특정 api를 사용하기 위해 A가 원하는 요청과 응답이 내가 api서버를 구현하면서 생각했던 요청과 응답이 아닌 것이다…

프론트 앤드에서 서버의 특정 api 사용시 나름 고정된 프로세스가 있는 것 같아 보였지만(Redux 패턴 때문?), A가 서울 가기 전에 보내준 데이터 명세에는 이러한 내용이 존재하지 않았기 때문에 나는 이러한 프로세스를 전혀 고려하지 않고 Api 서버를 구축했다.

발생한 이슈 중 가장 큰 문제는 Java의 ORM 명세인 JPA를 구현하는 Hibernate를 사용하는 Spring api 서버의 특정 api에서 A가 원하는 응답을 제공하기 위해서는 아주 더러운 코드를 짜거나, 도메인 내부 설계를 변경하지 않으면 불가능 하다는 것이었다…

그래서 나는 선택 해야 했다….

  1. 도메인 설계를 변경하면 전체적으로 엄청난 코드 변화를 유발할 텐데.. 프로젝트 마감이 3일 남은 이 시점에서 위와 같은 수고로움 에도 불구하고 객체 지향적인 코드를 작성할 건지..
  2. 많은 시간과 노력이 드는 객체 지향적인 코드는 좀 미뤄두고… 일단 프론트가 원하는 api 응답을 구현을 위해서 더러운 코드를 작성할 것인지…

결국에 나는 2번을 선택했지만, 왜 현업에서 클린코드를 강조하지만, 정작 클린코드를 실현하지 못하는지 알 것 같다….

매일 변경되는 요구사항 속에 우리는 객체 지향적인 코드를 선택할 것인지 아니면 빠른 기능 구현을 선택하고 다른 부분에 더 집중할 것인지… 동아리 선배가 말한 것처럼 개발은 매 순간 trade-off 관계 인 것 같다.

객체 지향에 있어서 가장 중요한 것은, 기존의 요구사항을 만족하면서 미래에 변화될지도 모르는 요구사항에 유연하게 대처하고, 적응할 수 있는 설계를 구현하는 것이 매우 중요한 것 같다.

동아리 선배님의 조언 (현 11번가 개발자)

https://github.com/citerus/dddsample-core

시간 날 때 Import 받아서 쭉 읽어보자!! (DDD 관련 내용)

이번 프로젝트 마감(동아리 성과발표)을 끝내고 webper 프로젝트를 다시 TDD 기반으로 리팩토링 해봐야 겠다.