4월 초쯤 슬랙에 내 이름이 태그되었다.
관리페이지 내, 셀렉트 박스에 해당 value가 빈 값으로 노출된다는 게 문제였다.

디버깅을 시작했다.
해당 파일은 Container / Presenter 패턴으로 되어있었고,
Container 컴포넌트는 1000줄이 넘을정도로 거대했다.

처음 이 컴포넌트를 접했을 땐, 불만이 가득했다.

아니 대체..😡

지금 생각해보면 경솔했다.
gitlens extension을 이용하면, 코드에 커서를 올렸을 때 커밋, 작성자, 작성시기를 볼 수 있다.
대략 2~3년 전 코드였다.

프론트라고 불리는 진영은 변화의 속도가 엄청 빠르다.
1년만 지나도, 프론트는 레거시코드가 되기 일쑤다.
개발을 처음 시작할 당시, React 17버전이었는데, 곧 React 19버전 릴리즈를 앞두고 있다.

즉, 당시엔 이와 같은 코드, 이와 같은 패턴이 대중적이었을 수도 있다.
변화가 빠른 프론트에선 당시엔 맞았지만 현재는 더 나은 개발방법들이 무수히 존재한다.

훗날 내가 작성한 코드도, 2~3년 뒤 그 누군가 봤을 때, 아니 대체.. 보다 더 심한 말을 듣게 될 것이다.
인간은 쉽게 누군가를 평가한다.
나는 이 사례로 이를 경계하기로 했다.
누군가를 쉽게 평가하지말자.

---

위와 같은 생각을 한지 얼마지나지 않아, 오늘 부메랑이 되어 내게 꽂혔다.
디버깅 이후, 해당 코드를 디버깅하기 너무 힘들어서, 편법(?)을 사용했는데, (state를 하나 더 만들었다..)
프론트에선 문제를 해결했지만, 본질적인 문제는 해결하지 못한 상태였다.

결과적으로 오늘 그 폭탄이 터졌다.
결국 서버개발자가 이를 발견하고 나를 호출했고, 나는 다시 이 문제를 직면하게 됐다.
부끄러웠다.
근본적인 문제해결도 못했으면서, 코드컨벤션 평가나 하고 앉아있던 내가 너무 부끄러웠다.

---

한 시니어개발자는 내게 이렇게 말해주었다.

에러가 나는 걸 숨기는 것보단, 에러가 터지도록 놔두는게 더 나을 수 있다.

에러를 해결한게 아니라, 숨기면 그 에러는 결국 발견하지 못하는 에러가 되어버린다는 의미였다.
그리고 그 에러는 결국 부메랑이 되어 내게 꽂힌다..
기존보다 훨씬 커지고, 거대해진다.

해결하던가, 터지도록 놔두던가.
가장 안 좋은 방법은 숨기는 것이다.