오버엔지니어링 하지 않기

 

내가 아는 거의 대부분의 개발자는 자기계발을 정말 열심히 한다.

 

최근 컨퍼런스에서 들었던 어떤 세션에서 재미난 말을 들었는데, 자바 스프링 진영에서 굉장히 유명하신 어떤 시니어 개발자분께서는 이런 말씀을 하셨다.

 

“하루 3시간씩 공부하는 것을 시스템화 합니다”.

 

이외에도 많은 많은 개발자들은 퇴근 후 개발을 계속하며 주말에도 스터디를 진행하곤 한다.

 

그만큼 배우는 것도 많고 보고 직접 해보는 것도 많다.

 

나 역시도 그렇다.

 

어제는 정말 기억에 남는 하루였다.

 

꽤 오랜 시간동안 고민했던 문제를 드디어 이해했던 역사적인 날이고, 문제가 해결되니 그 외의 다른 것들도 술술 이해가 가던 날이었다.

 

그리고 월요일인 오늘 뿌듯한 마음을 유지한 채로 출근하여 업무를 하던 중, 어제 내가 한달동안 고민했던 문제와 정확히 일치하는 상황이 발생했다.

 

나는 뿌듯함을 감추지 못하고 신나서 내가 배운, 내가 이해한 내용을 적용하고 또 감탄하며 신나게 코드를 써내려가고 있었다.

 

1시간 2시간,,, 점심을 먹고 3시간, 4시간, 5시간,,,, 6시간이 되던 때에도 끝이 보이지 않았다.

 

난 그래도 포기할 수 없었다. 사실 오늘 내가 만난 문제를 해결하는 방법은 딱 한가지 밖에 없었기 때문이다.

 

시간이 걸리더라도 이렇게 하는 것이 좋다. 아니 옳다.

 

왜냐? 마틴 파울러가 그랬으니까, 반 버논이 그랬거든, 그렉 영이 그랬단말이야. 이건 이렇게 해야하고 이럴땐 이게 쿨한 방법이라고 하니까.

 

결국 나는 옳은 선택을 했고, 쿨한 방법으로 요구사항을 구현해 나갔다.

 

누군가 나에게 이런 질문을 할 수도 있다.

 

“굳이 그렇게 했어야 됐어요?, 꼭 도메인과 인프라스트럭처를 분리했어만 했나요? 지금 하는 이 작업이 추후에 변경 가능성이 매우 높은가요? 비즈니스가 너무 복잡해서 인프라스트럭처의 로직이 침투하면 도메인 로직이 많이 복잡해지나요?”

 

이런 질문을 하는 사람은 내가 읽은 책을 읽지 않은 사람이다. 내가 읽은 글을 읽지 않은 사람이다.

 

생성, 조회만 존재하는 도메인에 2개의 API 를 제공하는데 6시간을 썼음에도 불구하고 나는 옳은 일을 한 것이다.

 

많은 선배 개발자들이 “그렇게 하는게 멋진 방법”이라고 했으니까.

 

오버엔지니어링 하지 않기.

 

개발자는 오버엔지니어링을 하지 않는것이 참 중요한 덕목인것 같다.

 

hexagonal-architecture 을 배우니 hexagonal-architecture 를 적용하고싶고, repository pattern 을 배우니 repository pattern 을 적용하고싶고, dip 를 배우니 dip 를 적용하고싶고.

 

굳이 문제점이 아닌 것을 문제점으로 드러내서 엊그제 책에서 배운 내용으로 멋지게 해결하고싶어 한다.

 

내가 오늘 직면한 문제는 과연 그 해결 방법이 정말 옳았을까?

 

사실 지금 생각해보면 내가 오늘 했던 실수는 순 오버엔지니어링 덩어리들이었다.

 

도메인에 집중하지 않고 책에서 배운 내용에 집중했기 때문이다.

 

도메인을 조금 더 들여다 보고 내가 작업하고 있는 위치가 어느 위치며, 시점이 어떤 시점이고 어떤 단계에 있는지를 고려했다면 사실 한시간 두시간이면 끝났을만한 문제였다. 정말 단순한 CRUD 였으니까.

 

소프트웨어는 말 그대로 soft 하기 때문에 software 이다.

 

내가 만들고 있는 것은 천공 카드가 아니다. 한번 만들면 끝이 아니라 계속해서 수정되고 변경되며 사라지고 다듬어져야 한다.

 

software 는 계속해서 말랑말랑한 상태를 유지한 채, 변하고 시간이 지남에 따라서 성숙해지고 완벽해지는 것이라고 한다.

 

오늘같은 태도라면 시작부터 완벽한 신전을 짓고 짜잔 하고 내보이려는 태도가 아닐까 싶다.