본문 바로가기
삽질일기

[일기] 더 좋은 코드란 무엇일까?

by 권성호 2021. 12. 3.

한 달 전쯤인가, spring boot로 요구사항에 맞는 비즈니스 로직을 개발하면서 Exception 처리의 효율을 높이기 위해 공부한 내용을 코드에 반영 후 커밋했었다.

 

아래는 그 당시 공부했던 내용이다.

https://ksh-dev.tistory.com/27

 

java - Exception과 logging이 성능에 미치는 영향

1. 서론 개인 프로젝트는 사용자가 많은 경우가 드물기 때문에 부하가 있을 때 성능적으로 어떤 문제가 발생할지 경험하기 어렵고 따라서 고민도 덜 하게 되는 것 같다. 반면, 회사에서 개발을

ksh-dev.tistory.com

 

간단히 정리하면, 특정 상황에서 분기하기 위한 목적으로 Exception을 사용한다면, fillInStackTrace()를 Override 하여 stack trace를 남기지 않음으로서 Exception 생성의 비용을 최적화할 수 있다는 것이다.

당시에는 새로운 것을 공부하고 제품 코드에 반영하는 과정 속에서 큰 보람을 느꼈다.

 

그런데 시간이 지나고 시니어 분 께서 내가 작성한 Exception 처리에 대해 왜 stack trace를 찍지 않았는지 여쭤보셨다.

난 당연히 그 이유에 대해 설명할 수 있었지만 시니어분의 반응은 내 예상과 달랐다.

 

우리 팀은 회사의 많은 프로덕트를 구현함에 있어서 MSA구조를 취하고 있다. 

즉, 역할에 따라 서버가 모듈화 되어 있고 프로덕트의 요구에 따라 필요한 서버가 조합된다.

이렇기 때문에, 내가 개발한 서버는 여러 프로덕트의 모듈로 포함될 수 있고 프로덕트 단위로 프로젝트가 생기는 특성 상 내 서버를 일부 프로덕트 전용으로 개발하는 상황도 발생한다.

또한, 내가 개발한 서버를 참조하여 다른 서버들도 개발된다.

이러한 협업 과정에서 누군가가 내가 개발한 Exception 모듈을 임포트 하여 사용하는 일이 충분히 발생할 수 있다.

문제는 여기서 발생한다.

 

우리 팀에서 Exception Class에 fillInStackTrace()를 Override 하여 stack trace를 남기지 않는 방식은 그 누구도 사용하지 않았다.

따라서 다른 팀원분들이 내가 만든 Exception Class는 당연히 stack trace가 찍힐 것이라고 생각하고 코드를 작성할 것이다.

 

시니어 분 께서는 Exception이 가진 본래의 의미가 stack trace를 포함하고 있다는 것을 강조하셨다.

덧붙여서, Java로 개발하는 과정에서 수많은 라이브러리가 상위 수준에서 제공하는 기본 컨밴션이 있고 이를 함부로 훼손하는 것은 위험할 수 있다는 것을 항상 인지해야 한다고 말씀해 주셨다.(이는 Java에 국한된 내용이 아닐 것이다.)

 

여러 가지 생각이 들었다.

 

우선 첫 번째로 내가 틀린 건가?라는 생각이 가장 먼저 들었다. 

나도 분명한 장점을 인지하고 작성했던 코드였기 때문에 내가 틀린 것은 아니라는 생각이 들었다.

그럼 기존의 방식이 틀렸던 건가?

아니다. 기존의 방식도 분명 합당한 이유가 있었다.

 

결국 그 누구도 틀렸다고 생각하지 않는다. 다만 어떤 장점을 더 취할 것인가에 따라 결정이 달라질 수 있다고 생각한다.

그리고 이러한 결정은 개인이 아니라 협업하는 사람들 단위로 논의를 통해 이뤄져야 한다고 생각했다.

 

내가 잘못했던 것은, 공부한 내용에 대해 팀원들과 공유 없이 제품 코드에 반영했던 것이라고 생각하고 팀에게 아쉬운 부분은 이러한 코드를 그대로 반영해도 되는 개발 프로세스를 갖고 있다는 점이었다.

 

아직 어떤 부분을 나 혼자 결정해야 하고, 어떤 부분을 팀과 같이 결정해야 하는지 모르는 부분이 많다고 느꼈다.

또, 아무리 좋은 기술이라도 협업 관점에서 진행되지 않는다면 좋지 않을 수 있다는 생각이 들었다.

'삽질일기' 카테고리의 다른 글

더 좋은 개발자가 되기 위해  (0) 2021.12.17

댓글