[우아한테크코스 5기] 레벨2 레벨인터뷰 회고

들어가며

6월 8일 두번째 레벨 인터뷰를 진행하였다. 나는 첫 레벨인터뷰때 말을 잘 못하고 더듬었던 부분이 있어서 이번 레벨2 인터뷰는 실제 면접처럼 준비해야겠다고 생각하고 말하기에 집중하고 준비하였다. 그리고 이번 미션에서는 1레벨보다는 공부를 많이 했다고 생각했기에 더 잘 할 수 있을 것이라고 생각했다.

---

시작

나는 2번째 타임으로 솔라와 함께 인터뷰를 진행하였다. 우리팀은 키아라, 나, 호이, 오도, 말랑, 주드, 도치, 푸우 였다. 나의 앞 타임은 키아라였다. 키아라는 말을 깔끔하게 잘 진행하였고, 그 다음 순서였던 나는 너무 떨렸다.

 

인터뷰

이번 레벨2 전반적으로 어떠셨나요 ?

저는 이번에 스프링을 처음 사용을 해봤는데 그런 만큼 좀 깊이 열심히 하고 싶었던 마음이 일단 컸어요. 그래서 초반에는 이제 미션 외에도 스프링에 대해서 학습도 많이 하고 공부를 하고 그랬는데 이제 후반부로 갈수록 해야 될 게 많아지고 미션도 좀 복잡해지다 보니까 스프링을 학습할 물리적인 시간이 부족해가지고 후반부에는 깊게 학습을 하지 못했는데 그게 좀 아쉬웠던 것 같습니다.

 

제가 준비한 질문 중에는 인터셉터가 있는데 혹시 인터섹터에 대해 아시나요?

저는 인터 셉터를 사용을 해봤었는데 저희 첫 번째 장바구니 미션 때 사용을 해봤었습니다.
사용자가 로그인을 하면 이제 저는 어드민 페이지에는 특정 유저만 접근을 하게 하고 싶었거든요. 그래서 이거를 컨트롤러 단에서 처리를 해주는 방법도 있겠지만 이거를 좀 더 앞단에서 처리를 해주면 좋지 않을까 해서 인터셉터처럼 요청이 들어왔을 때 그거를 전 후에 처리를 해줄 수 있다는 거를 알게 돼서 거기서 유저를 검증하는 방식을 사용을 했던 것 같습니다.

 

이제 어드민 페이지에 접속하기 전에 인터셉트에서 가로 치려면 프리핸들 메서드를 오버라이드를 해서 사용을 하잖아요 이에 대해 조금 자세히 설명해 주실 수 있을까요 ?

일단 제가 알고 있는 프리 핸들 메소드는 요청이 들어오고 그 뒤로 아규먼트 리졸버랑 컨트롤러 실행되기 전에 전 처리를 해 주는 것으로만 알고 있습니다.

 

인터셉터와 필터의 차이점을 알고 계실까요 ?

제가 생각하는 인터세터는 이제 스프링 단에서 특정 요청 아까 말했던 인증 같은 방식을 걸러내기 위한 용도로서 알고 있고 그리고 필터는 이제 스프링을 떠나서 웹에서 https 보안 같은 거를 처리를 한다든지 식의 좀 스프링과 다른 파트를 걸러내는 역할을 하고 있다고 알고 있습니다.

 

레벨 2에서 인터세터는 사용해보신 경험을 잘 말씀해 주셨는데 필터도 사용해보신적 있으실까요 ?

필터는 사용해보지 않았던 것 같습니다

 

스프링을 하면서 느꼈던 특징이 있을까요 ?

일단 제가 다른 프레임워크를 사용을 안 해봐서 이 스프링이 이 기능이 스프링의 기능이다라는 거는 잘 모르겠지만 제가 느꼈던 스프링의 기능은 일단 어노테이션이라는 게 너무 잘 적용돼 있었던 것 같거든요. 그래서 저희가 그냥 어노테이션만 작동을 하더라도 레벨 1 때는 따로 코드적으로 처리를 해줬어야 되는 것들이 어노테이션으로 다 해결이 되었던 것 같습니다. 그리고 저희가 제가 장바구니 미션 때 커스텀 어노테이션을 만들어서 사용을 해봤었는데 그때는 로그인한 거를 위한 커스텀 어노테이션이었지만 그거 외에도 다양한 방면으로 사용할 수 있을 것 같아서 좀 더 확장성 있는 프로그램을 만드는 데 좋지 않을까라는 생각을 하게 되었습니다.

 

의존성 주입에 대해서 알고 계신가요?

스프링에서 의존성 주입 알고 있습니다. 저는 주로 이제 스프링에서 의존성 주입이라고 하면 먼저 저희가 빈을 등록을 해놨는데 이제 등록된 빈들이 ioc 컨테이너에 다 올라가 있잖아요 거기 있는 것을 이제 그 후에 객체를 가져와서 사용하는 방식으로 사용을 했었는데 이제 수정자에서도 주입을 해줄 수도 있고 아니면 생성자에서도 주입을 해줄 수도 있고 필드로도 주입을 해줄 수 있었는데 저는 생성자로 제일 주입을 많이 해줬던 것 같습니다. autowired라는 어노테이션을 이용해서 주입을 많이 해줬던 것 같습니다.

 

생성자 주입을 사용한 장점이 있을까요 ?

제가 생성자 주입을 했던 거는 생성자 주입의 장점보다는 다른 주입들의 단점이 먼저 보여서 그렇게 처리를 했었는데요. 일단 수정자 주입 같은 경우에는 생성이 안 되고, 주입될 경우에는 이제 널 프린트 익셉션이 나오거나 그럴 수 있고, 이제 필드 주입 같은 경우에는 스프링 프레임워크가 없으면 주입을 해줄 수 없다는 단점이 있어요. 그래서 이런 단점 때문에 저는 생성자 주입이 최선이라고 생각을 해서 선택하게 되었습니다.

 

혹시 미션을 하면서 예외처리를 어떻게 하셨나요 ?

일단 저는 발생하는 코드에서 발생하는 예배들을 모두 커스텀 익셉션으로 돌렸는데요. 제가 의도하는 대로 출력을 하거나 아니면은 클라이언트가 요청을 보냈을 때 단순하게 예외가 발생하는 게 아니라, 메시지를 통해서 어떤 예외가 발생했는지를 명확히 알 수 있도록 처리를 하였습니다.

 

혹시 이제 각각의 컨트롤러에서 예외 처리를 하셨나요? 아니면 컨트롤러 어드바이스를 활용하셔서 전역적으로 사용하였나요 ?

저는 컨트롤러 어드바이스를 사용해서 여러 개의 컨트롤러에서 발생하는 익셉션에 대해서 글로벌적으로 처리를 해줬던 것 같습니다.

 

그렇게 컨트롤러 어드바이스를 사용하면 어떤 장점이 있나요?

일단 컨트롤러 어드바이스를 사용을 하게 되면, 원래 여러 개의 컨트롤러가 있다고 했을 때, 그 컨트롤러마다 비슷한 중복 코드가 많이 발생할 가능성이 있을 것 같습니다. 그래서 이거를 하나의 global exeption 핸들러 같은 걸로 묶어서 사용을 하게 되면, 이런 중복 코드를 제거할 수 있을 것 같습니다.

 

혹시 레벨 2에서 학습하시다가 되게 어려움을 겪었던 경험이 있으신가요?

저는 이제 레벨 2를 학습을 하면서 저희가 중반부에 디스패처 서블릿에 대한 내용이 나왔었거든요 이제 저는 그거에 대해서 좀 학습을 하려고 봤는데, 이제 생각보다 이게 딥하고 코드적으로 봤을 때도 양이 엄청 많고 어떤 코드를 봐야 될지에 대해서 잘 감이 좀 안 잡혔습니다. 그래서 그래도 이거를 학습을 포기하는 것보다는 학습을 해야 된다고 생각을 해서 내부적인 코드 또 중요하겠지만 코드에 집중하기보다는 이 처리 과정이 어떤 방식으로 흘러가는지에 대해서 좀 더 집중했던 것 같습니다.

 

그럼 혹시 dispatcher servlet에 대해 설명해주실 수 있나요?

일단 디스패처 서블릿 같은 경우에는 요청이 들어오면 그거에 대해서 많은 기능을 처리를 해야 될 텐데 다른 메소드들로 위임을 해주는 거라고 알고 있습니다. 이 디스패처 서블릿이 나왔던 이유 중에 하나는 원래는 요청이 들어오면 그거에 대한 서블릿들이 다 생성이 되면서 같은 기능을 하는 여러 개의 서블릿들이 만들어졌었는데 이거를 앞단에서 미리 선 전 처리를 하기 위해서 나왔던 것으로 알고 있고요. 그리고 이게 그리고 이제 디스패처 서블릿이 핸들러 매핑이나 핸들러 매핑을 찾아가서 그 컨트롤러에 맞는 요청에 맞는 컨트롤러를 찾아오고 이제 핸들러 어 찾아온 다음에 핸들러 어댑터를 통해서 이 컨트롤러를 사용할 수 있는 어댑터를 찾고 그리고 인터셉터를 거치고 알규먼트 리졸버를 거치고 컨트롤러를 거친 후에 다시 반환 값을 dspatcher servlet으로 받아와서 뷰 리졸버를 통해서 뷰를 반환하거나 아니면 뷰 resolver를 안 거치고 json 같은 body를 반환하는 방식으로 처리되는 것으로 알고 있습니다.

 

http를 이번에 처음 경험하셨을 것 같은데 이는 상태가 없죠 이게 어떤 의미인가요? 

제가 알고 있는 거는 진짜 말 그대로 상태를 안 가지고 있다 정도만 알고 있습니다.....

 

그러면 상태를 안 가지고 있는 주체가 누구죠? 누가 상태를 안 가지고 있죠?

저는 서버라고 생각을 합니다. 이게 http와 관련이 있는지는 모르겠는데 이제 상태 관련해서 제가 미션을 진행을 하면서 스프링에서 또 스프링 빈 같은 것들이 상태를 가지면 안 되잖아요. 근데 이제 저는 상태를 가지게 될 경우에는 싱글톤으로 등록할 게 아니라 프로토 타입 같은 걸로 등록을 하게 되면 상태를 가지면서 사용을 할 수 있지 않나 서버가 라는 생각으로 사용을 했었습니다. 근데 이제 그렇게 사용을 하면 이 상태를 스프링이 관리를 해주기도 관리를 할 수도 없고 그리고 데이터가 계속 생기다 보면 메모리적으로도 부하가 생긴다고 생각을 해서 결국에는 싱글톤으로 바꾸게 되었는데 결국 여기서도 상태라는 게 없다. 무 상태성을 유지한 거라고 저는 생각을 합니다.

 

프론트 엔드 크루들이랑 미션을 같이 하면서 어려운 점이 있었나요 ?

어려운 개념을 설명하기보다는 이제 백엔드의 의견을 프론텐드 크루들에게 전달을 하는 과정에서 설명하는 시간이 좀 길었었는데요. 그렇게 된 이유는 저희가 협업을 진행을 하면서 프론트엔드 은 이제 저희가 장바구니다 보니까 가격을 계산을 한다든지 이런 로직들이 있었잖아요. 근데 이제 프론트 크루분들은 자신들이 모든 것을 계산을 해서 반환을 해주겠다. 이런 식으로 주장을 했었고요. 백엔드 입장에서는 그래도 이게 정확한지 아닌지도 잘 모르겠고 우리가 검증을 해야 되지 않나 우리가 계산을 해서 검증을 한 번 더 해야 되지 않나라는 의견 사이에서 충돌이 좀 있었습니다. 그래서 결국에는 결론적으로는 이제 프론트에서 뷰에서 보여지는 계산은 프론트 핸드 크루들이 하고 서버 데이터베이스로 저장되는 계산 같은 경우에는 백엔드 크루에서 하는 걸로 결론이 났었는데요. 이렇게 결론이 원래는 한쪽에서만 하려던 것을 이렇게 반반으로 나눴던 이유는 둘 다 에서도 처리를 할 수는 있지만 둘 다 처리하는 거는 좀 비효율적이라고 생각을 했고 그리고 만약에 백엔드에서만 처리를 했을 때는 프론트 엔드에서 계속해서 api를 호출을 해야 되니까 그런 단점들이 있어서 그렇게 나누었고 이제 서버는 결국에는 데이터베이스에 저장을 해야 하는 입장이니까 저희는 이제 프론트엔드 크루분들한테 만약에 그렇게 프론텐드분들이 데이터를 넘겨주신다면은 서버를 거치지 않고 바로 데이터베이스로도 가도 상관없지 않느냐라는 말로 계속해서 얘기를 하면서 의견을 바꿔 나갔던 것 같습니다.

 

얘기하신 가격의 계산은 할인이나 그런 게 들어가지 않는 그냥 일반적인 가격인가요?

할인이나 이런 것도 다 포함해서 모든 계산적인 로직들을 다 원래는 프론트 엔드 크루들이 프론트 엔드에서만 그 모든 계산을 처리를 하겠다. 그래서 이제 리퀘스트 같은 경우에도 실제 금액, 할인된 금액 이런 거를 보내주겠다라는 의견이었어요.

 

그럼 이 유저가 할인을 받아야도 되는 유저인지 어떻게 알 수 있죠?

할인을 받아도 되는 유저로 하였습니다.

 

모든 사람이 다 할인을 받는 구조인가요 ?

저희는 쿠폰을 사용했었습니다. 그래서 쿠폰을 선택해서 할인할 수 있도록 처리를 했습니다.

 

클라이언트에서 유저 1번이라는 사람이 쿠폰을 보유하고 있다고 가정하고 쿠폰에 대한 데이터와 함께 할인을 해달라고 요청을 했어요.

저희가 이제 쿠폰의 데이터를 모두 그 사용자가 소유하고 있는 쿠폰의 데이터를 보내고 이제 그거에 대한 계산은 프론트 엔드에서 계산을 했는데요. 이제 반환하는 과정에서 사용한 담은 장바구니 아이템이나 쿠폰 이런 것들을 반환을 해줬는데 거기에는 따로 가격적인 요소는 없었고 그 이후에 오더가 들어왔을 때 백엔드 서버에서 처리를 해주었습니다.

 

오더 요청을 받았을 때는 서버에서 이 사람이 쿠폰의 소유자가 맞는지를 다시 확인하였나요 ?

이제 저희가 백엔드 크루가 3명이었었는데 3명 각각으로 구현을 해서 다양한 방식을 사용을 했었는데 저 같은 경우에는 일단 검증을 해줬던 것 같습니다. 아무리 프론트 엔드에서 잘못된 데이터가 넘어올 가능성도 있기 때문에 그렇게 검증을 해줬던 것 같습니다.

 

그러면 본인이 검증했던 요소는 어떤 것들이 있어요?

일단 제가 검증했던 요소는 저희가 요청으로 카트 아이템이랑 쿠폰에 대한 아이디 값을 받아왔었는데 일단 이 두 개가 이 사용자에 대해서 유효한지에 대해서 확인을 했고요. 유효한지에 대해서 확인을 하고 처리 가능한지를 확인을 해서 처리가 가능하다 싶으면 데이터베이스에 저장을 하는 방식을 사용했고, 안 될 경우에는 예외를 프론트 엔드 쪽으로 넘기는 방식을 사용했습니다.

 

오션이 생각하는 좋은 개발자란 무엇인가요?

일단 제가 생각하는 좋은 개발자라는 거는 함께 하기 좋은 사람이 좋은 개발자라고 생각을 합니다. 왜냐면 아무리 코드를 잘 작성을 하고 아무리 cs적인 지식이 높다고 하더라도 좀 같이 하고 싶은 마음이 없으면 저는 하는 협업을 할 때 별로다라고 생각을 하는데 이제 또 같이 하고 싶은 개발자라는 게 조금 기준이 명확하지 않을 수 있잖아요 근데 이제 저는 좀 서로 대화를 했을 때 최소 상대방을 경청을 해주고 자신의 의견만을 주장하지 않는 사람이라든지 아니면 뭔가 자신이 실수하거나 자신의 단점에 대해서 숨기거나 뭐 화내는데 급급하지 않고 좀 인정을 하면서 나아가는 사람인 것 같아요.

 

---

피드백

학습 좋았던 면 및 나빳던 면

스프링을 처음하였음에도 불구하고 의존성주입, 디스패처서블릿, 리졸브 등 레벨2 기간만으로 학습하기 벅찬 양일 수 있는데 모두 학습해서 좋았다. 하지만 스프링이 어렵다 보니 그외의 http와 같은 부분을 학습한 것이 부족했던 것 같다.

 

스프링 디스패처 서블릿 부분이 코드레벨까지는 어렵기 때문에 흐름을 이해하기위해 말을 했다. 이부분이 전략적으로 좋았다. 코드 레벨에서도 볼 수 있지만 이런 흐름을 학습한 것이 좋았다.방금 검증에 대해서 약간 대답을 깔끔하게 정리하지 못한 부분이 있는 것 같아서 검증의 필요성을 한번 잘 정리해 보시고 그 위치 또한 한번 고민을 같이 해보셨으면 좋을 것 같습니다.

인터뷰, 말하기 측면에서 좋은점 및 개선할 점

개선할 부분을 찾고싶었는데 어려웠다. 말을 하거나 생각할 때 눈을 못마주치는 점? 시선처리, 말속도, 목소리 크기 모두 좋았다.

 

되게 정리도 잘해 주시고 말이 길게 늘어지지 않았던 게 좋았던 것 같아요.
모르는 것이 나오더라도 바로 말부터 나가가지고 이게 말을 하다가 길을 잃지 않고 방향성을 먼저 잠깐 생각한 후에 말을 하니까 모르는 것에서도 어느 정도 논리를 지킬 수 있었던 것이 좋았습니다.

 

솔라의 피드백

내가 이걸 직접 했으니까 난 미션에서 구체적으로 어떤 이름의 어노테이션으로 만들었고 그거를 아까 로그인 기능에 쓰셨다고 했는데 그래서 내가 로그인 기능에 그걸 써서 어떤 점이 좋아졌는지 좀 내 경험을 더 풍부하게 구체적으로 말해주시면 더 좋을 것 같다. 대부분 미션에서 경험하신 걸 항상 같이 얘기를 해 주셔서 이 답변에 대한 신뢰도도 올라가고 이 사람이 구체적으로 했던 일들을 얘기를 하는구나 그 통으로 잡는 얘기를 외워서 말하는 게 아니라 그렇게 느껴져서 충분히 좋았던 것 같아요. 대신에 웹에 대한 프로토콜인 http랑 그리고 웹을 만나면서 갑자기 만나게 된 다른 친구들이 있을 거예요. http도 있고 한 세션도 오늘 이 인터뷰에서는 나오지 않았지만 인증이나 인가 이런 친구들 랩과 함께하는 친구들도 레벨 2에서 잘 정리하면 좋을 것 같다.

---

나가며

이번 인터뷰는 레벨1에 비해 말을 논리적으로 잘하고 끊기지 않게 내 의견을 잘 말했던 것 같다. 끝나고 호이가 오션 왤케 잘해요~ 라고 해주었을때 기분이 좋았다. 또한 솔라랑 진행했기 때문에 조금 더 편했던 것 같다! 짱~