[회고] 기업 2차 과제테스트 후기

목차

1. 준비 과정 회고
2. 2차 과제 테스트 회고
   1. 기술적인 방향으로 배운점
   2. 감정적으로 느낀점

 

준비 과정 회고

어떤 기업 1차 코딩 테스트를 통과하고, 기업 2차 과제테스트를 진행하게 되었다.

2차 과제 테스트 내용은 자바, 스프링을 활용해서 API 개발하는 과제 테스트였다. 최근까지 프로젝트를 진행을 했었기 떄문에, 오히려 코딩테스트보다 자신있는 부분이 있었다.

다만, 프로그래머스에서 진행되는 과제테스트인만큼, 환경이 프로그래머스에서 제공한 과제테스트 형태랑 비슷하다고 생각되어 문제를 풀어보려고 했다.

 

준비 과정에서 연습한 프로그래머스 과제 테스트 연습

https://school.programmers.co.kr/skill_check_assignments/232

위 과제 테스트 말고도 아래의 다른 API 서버 개발도 도움이 됐다고 말하시는 분도 있는 것 같았다.

https://school.programmers.co.kr/skill_check_assignments/430

 

준비 과정에서 배운점

 

1. 자바 어노테이션

자바의 기본적인 부분을 더 이해하려고 노력하게 된 계기가 되었다. 최근에 올린 자바 어노테이션 정리의 경우, 해당 과제 테스트를 풀면서 공부하게 되었다.

프로그래머스 과제 테스트에서는 롬복을 사용할 수 없었기 때문에, 스프링 개발에 자주 사용하는 Getter, Setter, Builder, RequiredArgsConstructor 등의 어노테이션을 직접 구현을 해야했다. 해당 어노테이션이 어떤 부분을 구현해주는 것인지는 알았지만, 어노테이션이 어떻게 그것을 구현 가능하게 하는지는 몰랐기 때문에, 이번 기회에 어노테이션의 동작 원리 및 구현체를 공부할 수 있는 계기가 되었다.

 

어노테이션 관련 정리

https://ganjisriver.tistory.com/15

 

2. Jdbc

스프링 개발자가 주로 사용하는 MyBatis나 JPA 등의 ORM 없이 자바 표준 인터페이스인 Jdbc를 활용하여 개발하는 방법을 익혔다.

 

주문관리 API 과제테스트에서는 ORM을 사용하지 않고, Jdbc를 활용하여 DB와 통신을 해야하는데, ORM이 없이 어떻게 통신을 구축할 수 있었을까를 고민해본 계기가 되었다.

 

Jdbc도 오래된 방식과 편의성을 갖춘 방식이 있는데, DataSource 인터페이스를 직접 다루면서 DB Connection을 직접 열고 복잡하게 진행하는 방식이 있고, JdbcTemplate을 사용하면 비교적 쉽게 쿼리를 관리할 수 있다.

자바 ORM의 근간이 되는 Jdbc기술을 직접 활용해 본 것이 좋았다.

 

3. 디렉토리 구조 및 코드 명명 규칙

내가 최근에 했던 프로젝트는 repository, service, controller 등의 레포지토리 외의 레이어 구분이 중구난방인 느낌이었는데, 테스트를 보고 그 외의 레이어들을 어떻게 나눌지 더 와닿은 느낌이었다.

 

4. 테스트 코드 및 디버깅

테스트 코드를 작성한 경험이 부족하기 때문에, 테스트 코드를 통한 디버깅을 하는 것이 익숙하지 않았다. 그래서 문제를 푸는데 익숙하지 않았다.

또한, 내가 옛날에 적당히 작성한 테스트코드에서 어떤 점을 보완해서 작성해야할 지에 대해 느낀 테스트가 아니었나 싶다.

 

2차 과제 테스트 회고

2차 과제테스트를 진행하면서 많은 것들을 느꼈고 아쉬운 점이 너무 많은 테스트였다.

 

기술적으로 배운점 또는 의문점

1. RequestHeader를 통해 전달되는 클라이언트의 요청 파라미터

 

RequestHeader에 왜 클라이언트의 요구 파라미터를 포함시켜 보낼까

과제테스트의 요구사항에는 HTTP 요청 메소드와 관계없이 RequestHeader에 클라이언트 요청 파라미터를 담아 보냈다.

 

근데 우리가 일반적으로 알고 있는 클라이언트의 요청 파라미터는 Query String, Path Variable, 또는 Body에 담아주는 정도가 아닌가 싶었다.

 

로그인 정보에야 Authorization 헤더에 담거나 커스텀 헤더를 만들어 보내는 것을 많이 봤지만, 주문 정보, 재고 수량, 상품 이름, 상품 번호 등의 정보를 왜 RequestHeader에 담아서 요청을 하는지 이해가 안 갔다.

POST의 경우 RequestBody에 담아줄수도 있다고 생각하는데, 모든 요구사항의 요청 파라미터가 RequestHeader에 담겨있었다.

 

같이 프로젝트 해주시는 분들의 답변

 

대부분 본인들의 회사에서도 요청파라미터를 로그인 인증 토큰이 아닌 이상에야 RequestHeader에 담는 경우는 거의 못봤다고 하셨다.

그나마 사용하는 근거는 로드밸런서, 샤딩 또는 API 중첩콜 등의 측면이 있을 수 있다고 말씀해 주셨다.

로드밸런서, 샤딩 때문에?

 

api 중첩콜?

 

처음 들었을 때 무슨소리인지 몰랐다. 로드밸런서 또는 DB 샤딩이 요청 파라미터를 Header에 담는 것이 무슨 연관관계가 있을까

 

그리고 api의 호출의 호출, opentelemetry, baggage header가 무슨 뜻인가.. 

 

찾아보고 해당 내용 업데이트 해보겠다. 

 

2. 테스트코드를 통한 안정감 및 철저한 설계

 

테스트코드를 갖고 디버깅을 하는 연습을 했어야했다.

일반적으로 특정 api를 테스트할 때, 포스트맨으로 직접 호출해보고 에러가 발생하면 에러난 부분을 트레이싱을 통해 발견하고 고치는 방식으로 디버깅을 해왔는데, 직접 api를 요청하는 것이 아닌 테스트코드로만 디버깅을 하는 부분이 어려웠다. 어떤 메시지를 확인해야하는지 감이 안잡혔고, 심지어 VSCode 환경이라 더 그랬던 것 같다.

 

이러한 어려운 점과 별개로, 실제 내가 진행하는 프로젝트에 이런 테스트코드가 있다면, 안정감있게 프로젝트를 배포하고 진행할 수 있겠다는 생각이 들어서, 현재 진행하고 있는 프로젝트에도 적용해봐야겠다는 생각이 들었다.

 

2차 테스트를 통해 느낀점

1. 스프링 시큐리티 관련

 

스프링 시큐리티를 직접 구현한지 1년이 넘었는데, 스프링 시큐리티를 부분적으로 구현해야하는 문제가 있었다.

무엇이든 구현 이전의 원리를 파악하고, 그에 맞는 구현을 시도해야한다는 걸 다시 느낀다.

심지어, 그 당시 구현할 때도 지금과 다르게 구현 자체에만 급급해서 원리를 제대로 파악하지 못했었다.

다른 부분은 다 자신이 있었지만 시큐리티 관련으로 나올 것이라고 생각하지 못한 것이 큰 패착이었던 것 같다.

 

그냥 멘탈 붕괴

테스트 코드에서 적혀 있는 yml파일 key값과 요구사항에 적혀있는 yml파일의 key값이 달라서, 아무리 요구사항대로 yml파일에 값을 넣어도 test코드가 통과가 안됨.. 1차 멘탈 붕괴 나중에 공지로 올라왔지만 이미 해당 부분에 1시간 이상을 쏳아부었던 상태였다..

로그인 인증부분 외적으로는 일반적으로 그냥 GlobalExceptionHandler 만들어서 에러 캐치하고, 기본적인 페이징을 이용한 조회 구현 등 그렇게 어려운 부분은 없었다고 생각하지만, 로그인 인증 과정이 이루어지지 않으면 테스트가 통과되지 않는다는 것을 깨달은 순간 2차 멘탈 붕괴되어 그대로 망했다..

 

예기치 못한 상황에도 멘탈을 잡아야된다는 생각을 하게 되었고, 떨어지겠지만 좋은 경험이었다고 생각하려고 한다.

 

기본에 충실하자

최근에 진행하고 있는 사이드 프로젝트에서도 나와 비슷한 처지의 취준생 팀원이 커스텀 어노테이션을 만들어, 에러가 발생할 경우 디스코드로 알람이 오게 하는 기능을 구현했는데, 구현 과정에서 HttpServletRequest에 있는 정보를 갖고 필터까지 조작하는 로직이 있었는데, 정말 스프링과 자바에 대한 원리의 이해가 깊구나라는 생각을 했고, 역시 기본과 원리에 충실해야함을 계속해서 느낀다.