최종 불합격, 독서: 예외처리, 개발 안티패턴에 대하여

오늘은 드디어 최종 면접 결과가 나왔다. 나는 당연하게(?) 안내해주던 방식인 카카오톡을 통해 전달이 될줄 알고, 카카오톡에 집중하고 있었는데, 결과는 메일로 전달이 되었다. 그리고 이것을 알게된 것은 핸드폰의 자동 메일 수신을 통해 알게되었다.

 

나는 강남언니 의 백엔드 주니어 직군에 지원했다.

 

메일로 결과가 전달됬다는 것은 내용을 보지 않아도 불합격임을 알 수 있었다. 그래서 솔직히 메일을 보기가 두려웠다. 한 3초정도 생각후에 바로 열어봤다. 결과는 예상한대로 불합격이였다. 불합격이라는 사실이 아쉽지 않다면 거짓말이다. 결과를 어느정도 예상한 나였지만, 속상했다. 

 

하지만 내가 지금 속상함을 느낄 여유가 없다. 분명 어느 부분에서 내가 부적합하다는 판단을 했고, 나를 불합격 처리를 했다. 그리고 나는 부적합했던 부분을 개선할 필요가 있다. 이는 힐링페이퍼의 기준에 맞춘다기보다 다음에는 마이너스를 플러스로 바꾸고싶기 때문이다. 

 

---

셀프 피드백: 무엇이 문제였을까?

 

이와 관련하여, 스스로 고민을 해보았는데, 아무래도 내가 개인프로젝트로 작성한 신발 주문 시스템이 Java 와 Spring 으로 한 첫 프로젝트이다보니, 이 부분에서 전문성이 부족하다 판단하지 않았을까? 하는 생각이 가장 먼저 들었다. 나는 이 부분에 대해서 부족한 부분은 계속해서 학습할 수 있음 + 개인프로젝트를 보고선 판단 할 수 있을 것 이라고 생각했다. 근데 이 부분이 문제였다면, 해당 부분에 대해서 질문을 해주셨으면 좋았으려만, 1차 기술면접에서의 Spirng DI, IoC 의 질문을 제외하곤 관련 질문을 받아보지 못했다.

 

두번째로 생각해본 부분은 개인 프로젝트의 기능이 너무 간단하다는 것이다. 사실 이건 억지스러운 내용이라고 생각하는데.. 프로젝트에 관한 이야기기로, 이벤트를 Publish 하고 Consume 하는 것만하는 것 아니냐?(이벤트 기반 아키텍처를 통해 구현한 내용 중) 한 질문이 있었다.

 

외부 API와 연동한게 있느냐? 하는 질문이라고 생각하는데,  외부 API 를 사용하는 등 기능의 풍족함(?) 보다는 내부 아키텍처를 고민하고, 제어 가능한 문제를 컨트롤할 수 있는 코드 구조 및 아키텍처를 설계했다에 초점을 두었기에, 해당 부분은 우선순위에서 밀렸었다. 근데 만약 이게 문제가 됬다고한다면.. 나는 외부 API도 활용할 줄 모르는 사람으로 보였다는걸까..?  아직 해당 내용에 관한 구현이 없었기에 그렇게 보일 수 있다고 생각하지만, 내가 초점과 우선순위로 선정한 부분을 전달했었고, 이 후로는 관련 질문을 받아보지 못했다.

 

마지막으로 예측해보는 문제는, 퇴사 이유가 아닐까 생각해본다. 내가 결정적으로 퇴사를 결심하게 된 계기는, 사수와의 개발 가치관의 차이와 개발팀 문화 때문이었다. 나는 차이점에 호소를 하지 않고 다름을 인정하고 나왔다. 이 부분에 대한 의사 전달도 분명하게 했는데, 이부분에서 안맞았을지도 모르겠다. 

 

이에 대해 피드백을 요청했는데 과연 피드백을 받아볼 수 있을까? 받아 볼 수 있었으면 좋겠다. 

 

---

독서: 예외처리, 개발 안티패턴에 대하여

 

오늘의 독서는 예외처리에 대한 부분과 개발 안티패턴에 대한 내용을 독서했다. 예외처리에 관한 내용은 지난 10개월간 담당했던 프로젝트 유지보수 업무 진행 간, 했던 고민이기도 했는데 이렇게 책에서 내용으로 언급을 해주니 상당히 반가웠다.

 

개발 안티패턴에 관한 내용은 개발하는데 있어 나쁜 관행에 대한 이야기이다. 해당 부분을 모두 읽은 것은 아니지만, 상당히 재밌었다.  나는 어느것이 좋은 관행이고, 나쁜 관행인지 알지 못했다. 사실 이것에 대해서는 명확한 답이 없지만, 이전까지는 사수의 경험과 말이 모두 정답처럼 받아들이는 수 밖에 없었다. 분명 사수님이 좋았던 부분도 있지만, 개선해야할 안티패턴도 분명히 많이 존재했었다. 이런부분들은 내가 책을 통해 공부하는 습관 덕에 알 수 있었는데, 이번 개발 안티패턴에 관한 내용을 독서하면서 조금 더 명확하게 인지하고 이해할 수 있게되는 것 같다.

 

---

예외처리에 대하여

 

예외처리에 대한 고민은 모듈을 만들면서 하게되었다. 개발 중인 모듈에서는 사용하는 또다른 모듈에서 발생할 수 있는 예외를 핸들링했다. 그런데 이렇게 할 경우, 개발중인 모듈에서 에러핸들링에 대한 반환 값을 어떻게 해야할지 몰랐다. null을 반환한다? 새로운 에러 감싸 상위 함수에 전달한다? 어찌해야할지 몰랐다.

 

이에 대하여, 나는 개발 중인 모듈에서 에러핸들링을 하지 않기로 했다. 정확히는 최상위 모듈에서 에러를 핸들링하도록 하였다. 당시에는 null 을 반환하여, null 일경우 최상위 모듈에서 다시 유효성 검사를하는 것이 비효율적이라 생각했고, 새로운 예외 를 만드는 것이 불필요한 과정이라고 생각했기 때문이다.

 

그리고 책에서는 이에 대한 가이드라인을 제시했다. 예외처리 유형은 내가 고민한 부분 그대로였다.

 

• 직접 catch 를 통해 처리하고, 상위 코드에 전파하지 않는다.
• 상위 함수에 예외를 그대로 전달한다.
• 발생한 예외를 다시 새로운 예외로 감싼 후 상위 함수에 전달한다.

 

함수 내에서 예외를 catch 할 것인지 아니면 상위 함수에 예외를 전달할 것인지는 전적으로 상위 함수가 이 예외에 대해 관심을 가지고 있는지 여부에 달렸다. 과거의 나는 관심에 대해서 고민을 하지 못했다. 상위 함수가 이 예외에 관심이 있다면 상위 함수에 예외를 전달하고, 그렇지 않다면 직접 catch 하여 처리하면 된다.

 

상위 함수에 예외를 전달하느냐 마느냐의 경우에는, 상위 함수가 해당 예외를 이해할 수 있는지에 따라 달라진다. 상위 함수가 이해할 수 있는 예외라면 상위 함수에 직접 전달하고, 그렇지 않다면 이해할 수 있는 새 예외로 감싸 전달한다.

 

추가적으로 public 함수와 protected 함수에서는 호출자의 행동을 제약할 수 없기 때문에 null 이나 빈 값 처리를 하는 것이 필수적이다. 반대로 private 함수의 경우 null 이나 빈 값 처리를 할 필요가 없다.

 

 

---

개발 안티패턴

 

나는 개발에는 정답이 없다고 생각한다. 하지만 분명한 오답은 존재한다. 그리고 안티패턴에 대해 이야기를한다면, 안티패턴은 오답이라 말할 수 있을까? 나는 안티패턴은 오답이라고 생각한다.

 

"경계를 존중하라" 의 일부분

 

이번 독서에서 가장 기억에 남는 안티패턴에 대한 설명 중, "경계를 존중하라" 가 기억에 남는다. 해당 내용은 의존성에 대한 추상화 경계를 넘지 말라 를 강조한다. 추상화 경계는 코드의 계층 주위에 그리는 논리적 경계로 주어진 계층의 관심사 집합을 의미한다.

 

이를 위반하는 사례는 흔한 내부아키텍처인 MVC 패턴에서 비즈니스 로직이 여렇 계층에 퍼져있는 경우를 이야기할 수 있다. 이는 명백하게, 추상화 경계를 넘어든 것이다. 각 계층은 다른 계층을 몰라야하는데, 특정 계층이 모든 것을 알고있다.

 

이것이 문제가 되는 이유는 무엇일까? 바로 추상화의 장점을 없애기 때문이다. 하위 계층의 복잡성을 상위 계층으로 끌어올린다면 하위 계층에서 일어나는 모든 변경사항과 그 영향을 관리해야한다. 이는 테스트하기 어려워지고 유지보수하기 어려워진다.

 

나는 이 문제의 원인을 MVC 아키텍처의 높은 자유도 때문이라고 생각하였는데, 이를 개선하기 위해 클린아키텍처라고 불리는 헥사고날 아키텍처, Ports and Adapters 패턴을 공부했다. 헥사고날 아키텍처는 정확히 MVC 패턴에서 추상화 경계릉 명확하게 해주는 것은 아니다. DDD 에서 보다 DDD를 준수할 수 있도록 보조해주는 것인데, 이 패턴을 통해 MVC 패턴에서 겪은 추상화 경계를 넘나드는 문제를 해결할 수 있을 것이라고 판단하여 공부하게 되었다.

 

이외에도 조금 생각을 해야하는 내용들을 오늘 읽어볼 수 있었는데, 솔직하게는 머릿 속에 명확하게 책에서 이야기하는 내용이 이해되진 않는다. 번역이 잘못된 것 같기도하고... 그렇다. 그래도 재밌다. 

 

---

오늘은 이것저것 오만가지 생각이 들었던 하루인것 같다. 복잡함, 속상함, 아쉬움, 기대, 걱정 등 오만가지 감정도 교차했다. 비록 도전에 실패했지만, 내 도전은 멈추지 않는다!! 힘들고, 아픔의 순간이 있어 더 단단해지고 성장할 수 있다고 생각하기에.. 오늘 일로인한 힘듬은 오늘까지만 하고서, 오늘보다 나은 내일을 위해 잘 준비해고 다듬어야겠다.

 

할 수 있 다.