[우테코] 레벨3 레벨인터뷰: 인터뷰 실제 대화 스크립트, 피드백

 

💋 인트로

우테코에서는 매 레벨이 끝날 때마다 레벨 인터뷰를 진행한다. 일종의 모의면접

이번 레벨에서는 각 팀이 서비스 구현을 끝냈기 때문에 해당 서비스를 만드는 동안 생겼던 이슈들을 바탕으로 레벨인터뷰 질문지를 구성하고 진행했다. 

내 질문은 미리 작성해둔 레벨로그를 바탕으로 크루들이 해줬으며, 이후에 인터뷰어, 옵저버에게 피드백을 받았다.

 

이번 포스팅에서는 네이버 클로버노트를 통해 정리한 실제 대화 스크립트와 받았던 피드백을 정리해 보려고 한다.

실제 면접 상황에서 이렇게 대답한다면 어떨지 나중에 또 읽어봐야겠다...ㅋㅋ

 

 

반응형

 

💋 실제 대화 스크립트

2023.08.29 화 오후 2:30 ・ 28분 48초

인터뷰어(토리) 01:28 안녕하세요. 간단한 자기소개와 서비스 소개 한 번만 부탁드립니다.

깃짱 01:33 안녕하세요. 저는 우아한 테크코스 5기 깃짱이라고 합니다. 저희 서비스는 이름은 스탬프크러쉬입니다. 카페 사장님들의 카페 사장님들을 개성을 갖고 카페 쿠폰을 관리하고 싶은 니즈와 카페를 사용하는 고객들의 편리하게 쿠폰을 관리하고 싶은 니즈가 만나서 탄생한 서비스입니다.

인터뷰어(토리) 02:04 나 질문 해도 될까요? 여기 예외 상황에 대한 api 설계에서 예외 상황에 대한 정리 정리를 어떻게 하셨는지 간단하게 설명해 주실 수 있나요?

깃짱 02:30 api 설계 내에서 예외 상황이라고 썼던 건데 혹시 그 어떤 의도를 물어보신 거죠?

인터뷰어(토리) 02:42 저는 에러 메시지나 이런 쪽에 대한 커스텀 처리를 했다는 건가라는 그런 의도...

깃짱 02:50 그거는 api 자체에서 같은 현상에 대해서 예외 상황으로 볼 것이냐 아닐 것이냐에 대한 얘기였고, 그러면 커스텀 예외에 대해서 질문하신 건가요?

인터뷰어(토리) 03:02 네 근데 적혀 있지 않는데 커스텀 예외를 사용해서 에러 처리를 하셨나요?

깃짱 03:06 네 저희는 사용했습니다.

인터뷰어(토리) 03:08 어떤 식으로 커스텀 예외 처리를 하셨는지 간단하게 설명해 주실 수 있나요?

깃짱 03:14 StampCrushException이라고 이제 최상위의 런타임 익셉션을 상속한 걸 넣고, 그 하위에서 이제 기본적으로는 메시지를 넣고 아니면 그 Throwable 객체까지 받는 걸로 만들어서 예외를 만들었었고요. 이렇게 하게 된 이유는 아무래도 표준 예외 갖고는 저희가 정의한 상황에 대해서 정확하게 설명하기도 어렵고 섞여서 그 상태 코드가 나가다 보니까 조금 그 부분에서 정확한 예외 상황을 보여주기 위해서 이렇게 사용했습니다.

인터뷰어(토리) 03:54 그러면 http 상세 코드 말고 따로 정의한 에러 코드를 사용하셨다는 말인가요?

깃짱 04:02 아니요 원래 상태 코드를 사용했습니다.

인터뷰어(토리) 04:07 그럼 그 메시지는 혹시 프론트 엔드에게 전달되는 메시지를 작성하셨는지 아니면 사용자에게 직접 전달될 메시지를 사용하셨는지 궁금합니다.

깃짱 04:18 프론트에게 전달될 메시지를 사용했습니다.

인터뷰어(홍실) 04:27 프론트에게 메시지를 보여준 것 외에 에러들을 발생한 Exception들을 처리하는 별도의 로직이 있었나요?

깃짱 04:34 에러가 발생했을 때 로그를 간단히 찍었어요.

프론트에 보여주는 메세지는 사실 사용자에게 어떻게 하면 노출이 될 수 있기 때문에 조금 더 자세한 내용들은 로그에 따로 적어서 사용했습니다.

인터뷰어(루카) 04:54 재사용성을 고려해서 api 설계를 해주셨다고 했는데요. 정확히 재사용성이 어떤 것을 의미하는지와 그것을 재사용성을 높이기 위해서 어떤 노력을 해 주셨는지에 대해서 설명해 주시면 감사하겠습니다.

깃짱 05:08 네네 api 한번 조금 예시를 들어서 설명을 드리자면 예를 들어 물건이 5개가 있는데 어떤 화면에서는 그 물건에 대한 데이터를 정확히 보여줘야 하고 어떤 화면에서는 그 물건에 대해서 그냥 5개로 총 개수만 보여줘야 할 수도 있다고 이렇게 있던 상황이 있다고 생각해볼게요. 그러면 api를 만들 때 사이즈를 붙여서 5개로 그 데이터를 축소해버리면 그 api는 해당 화면에 거의 특화되어서 만들어지기 때문에 재사용성이 굉장히 떨어진다고 생각을 했어요. 그래서 아까 태오가 말했던 것처럼 좀 리소스 자체에 집중을 해서 최대한 프론트엔드가 여러 번의 요청을 통해서 화면을 구성할 수 있도록 만들려고 노력했습니다.

인터뷰어(루카) 05:58 그러면 일단은 실질적으로는 저희 서버 api에 사용하는 클라이언트는 저희 클라이언트 개발자들이잖아요 근데 뷰에 좀 맞춰진 api라고 하면 클라이언트가 훨씬 더 쉽게 이해를 할 수 있을 텐데 좀 리소스에 집중된 api를 설계할 때 그 api 설계를 어떻게 조금 더 명확하게 명세화하고 설명 클라이언트가 봤을 때 어떻게 이해 가능하게 했는지에 대해서 좀 설명해 주실 수 있을까요? 어떻게 전달했는지...

깃짱 06:29 네 저도 저희 서비스가 이제 api 공개용이 아니기 때문에 뷰에 조금 의존적으로 명세가 짜질 수 있다는 부분은 인지를 했습니다. 근데 그럼에도 좀 이렇게 했던 이유는 저희가 사례를 하나 말씀을 드리자면 저희가 굉장히 좀 고집했던 부분이 전화번호만을 입력해서 편리하게 고객의 쿠폰을 사장 입장에서 조회하는 것이 중요했어요.

깃짱 06:55 편리성이 굉장히 중요한 한 축이어서 그래서 전화번호를 입력하게 되면 원래 처음에 계획했던 플로우가 임시 회원이거나 가입 회원이거나 아무튼 전화번호를 통해 조회를 하고 그런 다음에 내 카페에 이 회원이 쿠폰을 가지고 있는지 없는지 따라서 쿠폰을 가지고 있으면 일단 그 쿠폰을 보여지게 되고 가지고 있지 않다면 새로운 쿠폰을 발급받게 되고 이런 식으로 플로우가 굉장히 분기가 여러 차례 되었거든요. 그래서 처음에는 이거를 그냥 한 번의 요청으로 처리를 하려고 했어요. 한 페이지에서 일어나는 일이니까

그랬더니 프론트든 백이든 굉장히 한쪽에서 분기가 많이 일어나고, 그렇게 api 명세를 짜다 보니까 이게 어떤 일을 하는 api인지 오히려 더 불명확해지는 일이 발생했어요. 그래서 차라리 뷰에 의존적이지 않게 회원을 조회하는 api 쿠폰을 조회하는 거 그리고 회원을 만들고 쿠폰을 발급하고 이렇게 네 가지로 api를 분리하니까, 오히려 뷰에 의존적이지도 않고 리소스를 기준으로 더 명확하게 나뉘는 그런 상황이 발생해서 나누는 게 굉장히 유용했던 경험이 있습니다.

 

인터뷰어(홍실) 08:12 개인적으로 가장 궁금했던 게 팀 문화에 이제 디스커션을 많이 활용했다고 되어 있어요. 그래서 디스커션 가보니까 되게 많은 주제들이 토픽들이 있었는데 디스커션을 활용하면서 이 문제를 디스커션에서 논의를 하니까 정말 잘 해결됐다는… 정말 잘 논의를 할 수 있었다 했던 그런 문제 사항이 있는지 예시를 하나 들어줄 수 있을까요?

깃짱 08:41 저희가 거기서 테스트 코드 규칙에 대해서 작성을 했었는데 각자 이렇게 테스트 코드를 어떻게 사용하고

그러니까 저희가 처음에는 테스트 코드를 그냥 자기 취향대로 썼어요. 그러고 나서 3차 데모데이쯤에 통일을 하기로 했는데 그렇다 보니까 각자 자신의 상황에 대해서 이제 말로 하면 다 까먹기 때문에 거기에 작성해놓고 서로 조율하는 그런 경험이 굉장히 좋았던 것 같습니다.

인터뷰어(홍실) 09:14 테스트 코드를 얘기해 주셔서 테스트 코드 관련해서 좀 써주셨잖아요

테스트 코드 속도 향상에 대한 부분을 써주셨어요. 아마 제가 이해한 바로는 테스트 컨텍스트 캐싱을 활용을 해서 성능을 향상을 하려고 했던 게 맞나요?

깃짱 09:36 네 Mock Bean 같은 거는 공통적으로 사용하고 이런 거 말씀하시는 건가요?

인터뷰어(홍실) 09:41 맞아요. 옥빈 같은 거를 하나의 helper였던지 최상위 테스트 클래스에서 모아서 했던 것 같은데 컨트롤러 슬라이스 테스트를 썼을 때 서비스들도 mocking을 원래 하잖아요. 서비스들도 실제 api 컨트롤러 슬라이스 테스트에서 mocking을 했는데 걔를 상위 클래스에서 굳이 모킹을 안 한 이유가 있나요? 그러니까 하위에서 워킹을 하게 되면 결국에는 컨텍스트 캐싱이 안 되잖아요. 왜냐하면 설정 파일이 다 다르니까

그런 것도 혹시 상위에서 캐싱을 해보려고 했던 시도가 있었는지 아니면 안 한 이유가 별도로 있는지…

깃짱 10:21 서비스도 모킹을 했냐는 얘기인가요?

인터뷰어(홍실) 10:24 서비스도 모킹이 되어 있는데 걔는 왜 상위로 안 빼고 따로 별도의 컨트롤러에서 모킹을 따로 했는지 이유가 궁금했어요…

깃짱 10:34 저희가 도메인이 정말 많습니다. 그래서 테이블이 엔티티가 21개이어서 각 컨트롤러에서 사용하는 서비스가 그닥 겹치는 일이 없었어요. 그래서 상위에 놓기에는 21개를 놓고 사용할 수는 없어서 결과적으로는 겹치는 것만 위로 올리다 보면 사실 그렇게 많이 겹치지 않아서 이렇게 했습니다.

인터뷰어(홍실) 11:04 알겠습니다.

그리고 테스트 코드에서도 봤을 때 슬라이스 테스트로 작성을 해주셨다고 했어요. 제가 봤었을 때는 e2이랑 슬라이스랑 도메인 테스트가 있다고 그런 식으로 구성이 됐던 것 같은데 혹시 통합 테스트를 작성하지 않고 슬라이드 테스트만 작성하신 이유가 있는지

깃짱 11:30 인수 테스트를 작성했어요.

인터뷰어(홍실) 11:39 인스 테스트랑 슬라이스 테스트만을 구성한 이유가 있는지로 정정할게요. 인스 테스트랑 슬라이스 테스트 외에도 저희가 별도로 서비스에서 통합 테스트도 많이 사용하는 편이잖아요.

근데 서비스에서 통합 테스트를 하지 않고 인수 테스트로만 이제 통합 환경을 테스트해 본 이유가 있는지

깃짱 11:56 저희가 좀 도메인이 너무 많고 하다 보니까 좀 테스트 코드를 짜기가 좀 벅찬 경우가 많았어요. 그래서 레포디토리 테스트를 꼼꼼히 작성하자는 약속을 하고, 그거를 믿고 인스테스트를 작성했으니 최종 플로우도 됐으니 그걸 믿고 갔던 것 같습니다. 그렇게 하다 보면 좀 겹치는 부분이 많다고 생각했어요. 만약에 서비스를 통해서도 레포디토리를 함께 테스트하면 이미 레포지토리를 테스트했기 때문에 겹치는 부분이 많아진다고 생각해서 그렇게 했던 것 같습니다.

인터뷰어(루카) 12:38 웹 환경에서 테스트할 때 테스트 격리를 위해서 BeforeEach 콜백 인터페이스를 활용했다라고 말씀해 주셨는데 하는 역할과 테스트 격리를 어떻게 하셨는지에 대해서 조금 대략적으로 설명을 해 주실 수 있으실까요?

깃짱 12:55 BeforeEach 콜백이라고 하는 인터페이스를 구현하면 그러고 그 인터페이스를 인터페이스 구현체를 빈으로 등록하면 이제 해당 메서드에 beforeEach()였나 그런 메 오버라이드된 메소드에 구현된 내용을 항상 그 빈에서 항상 그렇게 실행을 하게 됩니다. 그래서 그 부분에다가 저희 테이블을 다 가져오는 그런 sql 명령어를 통해서, 반복을 통해서 테이블을 다 테이블 내용을 초기화하는 sql 문을 써놓고 그거를 인스테스트의 최상단 테스트에다가 ExtendsWith 위드라는 어노테이션을 사용해서 넣어놨어요. 그렇게 하면은 인수 테스트 최상단 테스트를 구현한 모든 테스트들에서 항상 해당 DataCleaner라고 저희가 정의해 놓은 그 메서드를 항상 실행하게 됩니다.

편의 클래스에 가까운 성격이라고 생각하시면 됩니다.

인터뷰어(토리) 14:05 그거에 대해서도 얘기가 나오고 회원가입 로그인을 할 때 OAuth를 사용하셨다고 적혀 있는데 어떤 OAuth를 사용했는 그 어떤 플랫폼을 사용했는지 그렇게 선택한 이유가 있는지?

깃짱 14:23 카카오를 사용했습니다. 처음에는 네이버를 사용하려고 했는데 이게 사실 지금 트러블 슈팅이 명확히 안 되어 있는데 그 사업자 등록을 아마 해야만 되는 것 같기도 하고 아무튼 자꾸 승인이 잘 나지 않아서 어쩔 수 없이 선택하게 되었습니다.

인터뷰어(토리) 14:46 그러면 카카오 OAuth를 할 때 어떤 식으로 회원가입 로그인이 일어나는지 플로우를 간단하게 설명해 주실 수 있나요?

깃짱 14:54 프론트 쪽에서 카카오로 로그인 버튼을 누르게 되면 저희가 미리 등록해놨던 카카오에서 정해준 그 페이지로 이동을 해서 거기서 유저가 인증을 마치고 이제 카카오 쪽에서 승인이 됐다고 하면은 임시 비밀번호인 authorization code를 함께 저희가 지정해놓은 redirect uri로 보내주게 돼요. 그러면 프론트 측에서는 그거를 응답으로 받아서 백엔드한테 authorization code를 함께 넘겨줘요.

그러면 백엔드 쪽에서는 이미 등록해놓은 정보와 함께 오소라이제이션 코드를 카카오 플랫폼 쪽으로 보내면 이제 거기서 엑세스 토큰을 받아서 그 뒤로는 리소스를 그걸로 사용할 수 있게 됩니다.

인터뷰어(토리) 15:38 아까 회원 가입을 할 때 보니까 기본적으로 닉네임만 제공이 되는 걸로 아는데 다른 선택 사항들을 추가로 넣으셨더라고요. 혹시 그런 이유가 있을까요?

깃짱 15:52 저희 서비스가 고집하는 부분이 전화번호를 통한 간편한 적립이어서 사실 정말 솔직히 말하면 카카오를 사용하기 전에 전화번호를 받을 수 있을 줄 알았어요. 그랬는데 닉네임만 줘서 조금 당황스러웠는데 그래도 얼른 전화번호를 별도로 만드는 api를 데모데이 바로 전날 만들어서 붙였어요.

인터뷰어(루카) 16:17 OAuth인증에 대해서 설명을 해 주셨는데 OAuth 인증이 완료가 되고 이제 스탬프 크러쉬 인증 인가를 토큰이나 세션 어떤 방법을 채택하셨을 것 같은데 채택하신 방법과 선정 이유에 대해서 조금 설명해 주실 수 있으실까요?

깃짱 16:37 저희는 jwt 토큰을 따로 만들어서 발급해주는 방식을 사용했고 사실 가장 간편해서 사용한 것이 컸습니다. 또 세션을 사용하기에는 저희도 서버에 별도의 저장을 하고 싶지가 않아서 그렇게 사용했습니다.

인터뷰어(루카) 17:00 토큰에는 어떤 정보가 담겨 있을까요?

깃짱 17:03 저희 토큰은 현재는 멤버 아이디를 갖고 만들고 있어요. 그래서 조금 보완할 예정입니다.

인터뷰어(토리) 17:15 배포 자동화를 하셨다고 했는데 어떤 팁을 사용해서 하셨는데, 어떤 툴을 사용해서 하셨는지..?

깃짱 17:22 깃허브 액션으로 ci를 했고 젠킨스로 cd를 했습니다.

인터뷰어(토리) 17:29 두 개를 다르게 선택한 이유가 있으실까요?

깃짱 17:34 ci의 깃허브 액션을 나중에 추가하게 된 건데, 이거는 코드에 병합하기 전에 마지막으로 테스트 코드가 통과하는지 이런 것들을 확인하고 나서 병합을 하는 게 더 안전하다고 생각해서 좀 강제성을 부여하려고 한 거고 젠킨스는 배포된 파일을 전송하기 위해서 사용했습니다.

인터뷰어(토리) 18:03 여기에 장애 발생 대응을 위한 수동 배포 스크립트 작성이 깃허브 스크립트를 말씀하시는 건가요?

깃짱 18:14 아니요 개발 서버로 직접 들어가서 처음에 깃허브를 풀 받고 빌드하고 빌드된 파일을 최상단에 옮겨서 그 jar 파일을 실행하고 이것까지의 과정을 얘기한 스크립트입니다.

인터뷰어(토리) 18:30 그럼 해당 스크립트는 서브 모듈로 관리를 하신 건가요? 아니면 그냥 서버 내부에 파일을 바로 작성하신 건가요?

깃짱 18:41 서브 모듈로 관리했습니다. 그래서 해당 스크립트에도 이제 git add 서브 모듈이었나..? 그런 서브 모듈을 함께 추가하는 과정이 필요합니다.

 

인터뷰어(루카) 18:59 도메인이 테이블 일단 erd가 매우 복잡하게 보여지는데요. erd에서 저희가 한번 유심히 봐야 될 어떤 관계나 혹은 뭔가 어려움 erd에 대해서 조금 추가적으로 설명해 주실 수 있는 내용이 있으실까요?

깃짱 19:22 네 이름이 굉장히 헷갈리는데 잘 들어주세요. 카페를 생성하게 되면은 이제 그 카페에 부수적으로 따라오는 게 카페 Policy이라고

저희가 정한 예를 들어 8개의 아메리카노 한 잔, 이런 정책이 있고 또 그 정책에 굉장히 의존적인 쿠폰 디자인이 있어요. 왜 의존적이냐면 쿠폰의 뒷면에 찍히는 스탬프의 개수가 8잔에 1개면 동일해야 될 거 아니에요

그래서 이렇게 두 가지를 설정하게 되는데 저희가 굉장히 고민을 많이 했던 포인트가 한 번 쿠폰을 발행받게 되면은 ‘만약에 그 뒤에 사장님이 정책이나 디자인을 변경했다면 어떻게 될까요’를 굉장히 많이 고민을 했어요. 결과적으로는 사용자한테 그 당시 쿠폰 발급 당시의 약속은 반드시 지켜야 된다. 그러면서도 또 사장님한테는 불리한 걸 정책을 사용하게 되면 사장님이 절대 사용을 안 할 거기 때문에

깃짱 20:30 그래서 그 사이에서 많은 조율을 하다가 결과적으론 현실과 똑같이 가자고 결론을 내렸어요.

그래서 현재 발급 당시에 그런 디자인과 Policy를 전부 복사를 해오는 형태로 데이터베이스에 저장을 합니다. 이 부분을 이렇게 구현한 거에 대해 방금 설명을 드렸고 조금 더 개선할 수 있는 거는 이제 fk를 지정하지 않고서 soft delete를 사용해서 Cafe Policy이나 디자인을 그렇게 모두 다 생으로 베껴오는 방식 말고 좀 개선을 할 수 있을 것 같다고 생각합니다.

인터뷰어(토리) 21:18 여기 쿠폰 정책이랑 카페 정책이 나눠져 있는데 제가 방금 이해한 바로는 쿠폰 정지기 카페 정책이랑 다를 게 없어 보여서 이게 잘 보이지는 않지만 뭐가 다른 건지 혹시 설명해 주실 수 있나요?

깃짱 21:38 네 카페 정책은 현재 그러니까 카페 사장이 현재 등록해놓은 그 정책이어서 새로운 쿠폰을 발급받게 되면 그 현재 카페의 정책을 복사해서 쿠폰의 정책이 되는 거고요. 쿠폰 정책은 따로 수정할 수 있는 방법이 없어요. 이미 발급된 후에는 (사람들이 헤매는 중) 네 많이 복잡합니다.

 

[시간 종료]

 

💋 피드백

✔ 구두

인터뷰어(홍실) 23:53 제가 먼저 할게요. 일단은 테스트 관련해서 좀 여러 방면으로 물어봤는데 확실히 기준이 있었던 것 같아서 되게 좋았던 것 같아요. 사실 디스커션 들어가서 좀 봤거든요. 이게 몇 개는 논의 중이고 몇 개 논의 완료더라고요. 근데 논의 완료에서 아까 말했던 테스트 코드 관련된 부분이 되게 많고 이게 논의가 좀 잘 된 편인 것 같아서 좋았던 것 같아요. 학습적으로는 딱히… 협업적인 면에서 되게 잘 해 주신 것 같아요. 테스트 코드 기준이 있는 게 확실히 좋긴 하네요. 제가 테스트 코드를 좀 주요하게 봐서 좋았던 것 같아요.

깃짱 24:46 아까부터 꽂혀 계시더라고요. 아침부터…

인터뷰어(홍실) 24:50 아침부터 딱 봤는데 왜냐하면 테스트 컨텍스트 캐싱이 저도 되게 관심 있어 하는 주제였고 이걸로 성능 향상하는 것도 제가 팀원한테 밀어붙였던 게 있어가지고

깃짱 25:02 깃허브 액션 ci 기준 2초 향상되었어요.

인터뷰어(홍실) 25:05 이거 이거 상위 클래스로 서비스 다 목빈 올리면 몇 십 초 줄어들 겁니다.

옵저버(후추) 25:35 피드백 드리면 제 학습 측면에서 되게 다양한 주제들이 나왔는데 다 잘 알고 계신 것 같고 그걸 잘 말하시는 게 되게 인상 깊었습니다. 디스커션을 저도 잠깐 봤는데 그 자체를 사용한 것도 인상 깊고 뭔가 서로 논의할 부분에 대해서 논의하고 그냥 끝내버릴 수도 있는데 그거 자체를 기록으로 남겨서 문서화를 잘하는 팀 같다는 인상을 받았고요. OAuth 플로우도 잘 이해하고 계신데 아까 오류를 아직 이유를 모르겠다라고 하신 부분은 한 번 더 공부해 보시면 좋지 않을까 생각이 들었습니다. 말하기 측면에서는 뭔가 당차게 말하는 게 보여서 그게 되게 인상적이었고요. 필요한 경우에 한해 예를 들어 설명하거나 사례를 드는 것도 되게 말할 때 있어서 듣는이가 좋았던 것 같습니다. 근데 뭔가 말하다가 뭐지 말끝을 계속 잇는 경향이 좀 있어가지고 그것을 원하신다면 고치시면…

깃짱 26:46 선택이에요…?

옵저버(후추) 26:50 고쳐보시는 것도 나쁘지 않을 것 같다는 생각이 들어서…

인터뷰어(루카) 26:55 인터뷰어로서 리뷰를 좀 드리자면 일단은 프로젝트에 대해서 전반적으로 이해를 많이 하신 것 같고 평상시에 블로그 많이 훔쳐보는데 내용들 잘 정리하고 계신 것 같아서 좋았습니다. 그리고 테스트 규칙도 팀 내에서 잘 협의해서 잘 활용하고 계신 것 같아서 좋았고 특히 협업이나 기술 지식 전파 같은 게 잘 되고 있는 팀 같아서 그것이 좋았습니다.

그리고 어떤 소프트 스킬인 말하기 측면적으로는 일단 눈을 꾸준하게 마주치면서 이야기를 해주셔서 내용에 대해서 좀 신뢰감이 있었고요. 그리고 내용을 설명할 때 사례를 들어서 설명해 주시는 것이 인상 깊었습니다.

 

인터뷰어(토리) 27:47 저도 인터뷰 하면서 느꼈던 걸 얘기해보자면 협업을 하면서 한 개의 기준을 세워나가는 점이 좋았고요

화면을 사용해서 기록을 하면서 뭔가 논의를 했다는 점이 굉장히 인상 깊었고요. 질문에 대해서 사례를 들면서 얘기했던 부분이 있었는데 이런 부분에서 뭔가 자기가 직접 느낀 점을 서비스를 개발하고 프로젝트를 하면서 직접 느낀 점에 대해서 사례를 들어서 그냥 전체적으로 이해도도 높아 보이고 그래서 좋았습니다. 말할 때 항상 자신감 있게 이해하는 점이 좋았습니다. 끝이에요.

 

✔ 피드백 시트

 

💋 서기의 기록

제나의 기록

[깃짱]
1. 자기 소개와 서비스 소개 부탁드립니다
2. 예외 상황에 대한 정의를 어떻게 하셨는지
    1. API 에 대한 ? 아니면 에러 메세지나? 커스텀에 대한 처리를 했다는건가? 라는 질문
    2. API 에서 동일 상황에 대해 예외로 처리할것인가 아닌가
3. 커스텀 예외를 사용하셨나
4. 예외 메세지를 프론트에게 혹은 사용자에게 전달할 메세지로 사용했는지
5. 프론트에게 보여주는 것 외에 예외 메세지를 다른 것에서 처리하는 일이 있었는지?
    1. 로깅할때
6. 재사용성을 고려해서 API 설계를 했다고 하셨는데 재사용성에 대한 설명과 어떤 API 에서 재사용성을 높였는지
    1. 뷰에 맞춰진 API 면 클라이언트가 훨씬 쉽게 이해할 수 있을텐데 리소스에 집중했으면 클라이언트가 어떻게 이해할 수 있을까
7. 개인적으로 가장 궁금했던게 팀문화에 디스커션을 많이 활용했는데 디스커션에 많은 토픽들이 있는데 이 문제를 디스커션에서 논의하니까 잘 논의가 됐다 하는 예시사항을 들어줄 수 있나요
8. 서비스는 상위에서 모킹을 왜 안했는지 (이 질문 잘 못정리했습니다ㅠ)
9. 인수테스트와 슬라이스 테스트만 작성한 이유가 있는지? 서비스에서 통합테스트를 하지 않은 이유?
10. 웹 환경에서 테스트할때 테스트 격리를 위해서 @BeforeEach Callback 을 이용해서 하셨다고 하는데 어떻게 하신건지
11. 회원가입/로그인을 할때 OAuth2 를 사용했다고 되어있는데 어떤 플랫폼을 사용했는지, 그걸 사용한 이유가 궁금하다
    1. 기본적으로 닉네임만 제공되는 걸로 아는데 추가 선택사항을 넣었는데 추가 선택사항을 넣은 이유가 있을까요
12. OAuth 인증에 대해 설명을 해주셨는데 OAuth 인증 이후 스탬프 크러쉬 인증을 어떤걸로 선정하셨는지와 그 이유에 대해 설명해주세요
13. 배포 자동화를 하셨다고 했는데 어떤 툴을 사용해서 하셨나요?
    1. 깃허브 액션과 젠킨스를 둘 다 사용하신 이유 ?
14. 장애 발생 대응을 위한 수동 배포 스크립트 작성이 깃허브 액션 스크립트 작성을 말하는 것인가?
    1. 해당 스크립트는 서브모듈로 관리 한건가? 아니면 서버 내부에 바로 파일을 작성한 건가?
15. 테이블 ERD 가 매우 복잡하게 보여지는데 ERD 에서 중점적으로 봐야할 부분? 
16. 쿠폰 정책과 카페 정책이 나누어져있는데 방금 이해한 바로는 쿠폰 정책이 카페 정책과 다를게 없어 보여서 뭐가 다른건지 설명해주실 수 있나요 ?

테오의 기록

[깃짱]
- 간단한 서비스 소개를 해줄 수 있는지?
- 예외 상황에 대한 정의를 어떻게 했는지?
- 예외 메세지는 프론트에게 전달하는 목적인지, 사용자에게 전달하는 목적인지?
- 프론트엔드에게 메세지를 보여주는 것 외의 예외 관련 처리가 있었는지?
- 재사용성을 고려해서 API 설계를 하셨다고 했는데, 재사용성이란 무엇인지, 그리고 재사용성을 높이기 위해서 어떤 노력을 했는지?
- 서버 API를 사용하는 사용자는 클라이언트 개발자들인텐데, 리소스 중심으로 API 설계를 할 때 어떻게 설명을 했는지?
- 고민을 할 때에는 Discussion을 사용했다고 했는데, Discussion을 통해 해결한 고민이 있는지?
- 테스트 코드 성능을 ‘컨텍스트 캐싱’을 활용해서 개선한 게 맞는지?
- 컨트롤러 슬라이스 테스트를 했을 때 상위 객체에서 Mocking 설정을 해주지 않은 이유가 있는지?
- 서비스에서 통합 테스트를 하지 않고 인수테스트, 슬라이스 테스트만으로 구성한 이유가 있는지?
- 웹 환경에서 테스트 할 때, 테스트 격리를 위해 BeforeEach 콜백을 사용했다고 했는데, 어떻게 사용했는지?
- 회원가입 / 로그인을 할 때, 어떤 OAuth 플랫폼을 선택했는지?
- 카카오 로그인을 할 때, 어떤 방식으로 로그인이 진행되는지 플로우를 설명해줄 수 있는지?
- 회원가입을 할 때, 기본적으로 닉네임만 제공되는 것으로 아는데 다른 정보를 추가적으로 제공하게 만든 이유가 있는지?
- Oauth 인증이 완료가 되고 난 뒤의 인가 방법에 대해 어떤 방법을 선정했는지? 이유는 무엇인지?
- 액세스 토큰에는 어떤 정보가 담겨 있는지?
- 배포 자동화를 하셨다고 했는데, 어떤 툴을 사용해서 했는지?
- CI/CD 과정에서 젠킨스와 깃허브 액션을 둘 다 사용하는 이유가 있는지?
- 장애 발생 대응을 위한 수동 배포 스크립트란 무엇인지? 스크립트는 서브모듈로 관리하는지?
- ERD가 복잡한데 추가적으로 설명해주실 수 있는 부분이 있는지?
- ERD에서 쿠폰 정책이랑 카페 정책이 둘 다 있는데 무엇이 다른건지?

에코의 기록

깃짱 서기
- 토리: 예외 상황에 대한 정의를 어떻게 했는지?
        - 커스텀 예외를 사용해서 예외 처리를 어떻게 했는지?
        - 그러면 http 상태코드 말고 따로 정의한 에러 코드를 사용했는지?
        - 메세지는 프론트엔드를 위했는지 아니면 사용자를 위했는지?
- 홍실: 에러를 처리하는 별도의 로직이 있었는지?
- 루카: 재사용성을 높이기 위해 어떤 노력을 했는지?
        - 뷰에 맞춰진 API면 편하게 사용할 수 있는데, 자원 기반 API를 어떻게 전달했는지?
- 홍실: 팀 문화에 디스커션을 활용했다고 하는데 디스커션에서 논의해서 더 좋았던 부분이 있었는지
        - 서비스들 목킹을 하는데 굳이 상위 클래스에서 목킹을 하지 않은 이유
        - 통합테스트를 작성하지 않고 인수테스트와 슬라이스 테스트만 작성했던 이유
- 루카: 웹 환경에서 테스트할때, 테스트 격리를 했다고 했는데 어떻게 했는지?
- 토리: OAuth를 사용했다고 하는데, 어떤 플랫폼을 설정했는지?
        - kakao oauth를 할때 어떤 플로우로 로그인이 되는지 설명
        - 회원가입을 기본적으로 닉네임 외에도 다른 정보들을 받은 이유
- 루카: OAuth 인증 후에 jwt 채택 선정 이유
        - 토큰에 담겨있는 정보
- 토리: 배포 자동화에 어떤 툴을 사용했는지
        - 두개를 다르게 선택한 이유
        - 장애 발생 대응을 위한 수동 스크립트 작성을 했다고 하는데 어떤 과정을 얘기한 것인지
        - 스크립트 관리는 서버 내부인지 아니면 submodule로 관리했는지?
- 루카: ERD가 매우 복잡하게 보이는데, 유심히 봐야할 관계나 추가적으로 설명해줄 수 있는지?
- 토리: 쿠폰 정책이랑 카페 정책이 나눠져 있는데, 쿠폰 정책과 카페 정책이 다를게 없어보이는데 뭐가 다른지?