간단한 CRUD 구현 및 기능에 대한 API 문서까지 작성하여, 프론트엔드 개발자분께 전달을 완료했다.
이번 주에 정말 다양한 문제를 만나게 되었는데, 크게 두가지가 기억에 남는다.
현재 우리의 Siders 웹 앱의 게시글은 다음과 같이 구성되어야 한다.
나는 이러한 복잡한 구조를 JSON 형태로 받아본 적이 없다. 그래서 어떻게 구성해야 할지를 몰랐다.
처음에는 각 객체마다 DTO를 만들어서, Entity와 똑같은 구조를 유지하도록 했다. 그리고 테스트 코드를 돌려서, @RequestBody로 값을 잘 받아오는지 테스트를 수행했다.
JSON 관련 에러가 났다. 파싱이 안된다는 것이다. 나는 단순히 아, 복잡한 구조의 JSON은 @RequestBody를 사용할수가 없구나.. 라고만 생각했다. 그래서 다른 방법을 찾아서 적용하려다가, 혹시나 현업자분들은 이유를 아실 것 같아서 왜 안되는지에 대한 이유를 여쭈었었다.
하지만 의외의 대답을 들었다.
아무리 복잡한 구성이어도, @RequestBody가 필드 명이 동일하면 맞춰서 알아서 넣어준다는 것이었다. 그리고 추가적으로 나에게 물어보셨다.
“혹시, 기본 생성자는 넣어두셨나요??”
나는 넣지 않았었다. 왜냐면 넣지 않아도 @RequestBody가 이전에는 잘 동작했을 뿐만 아니라, @Setter를 넣어주는데 굳이..? 라는 생각이 있었기 때문이다. 그래도 바로 적용을 해보고, 테스트를 돌려보았다. 갑자기 바인딩이 너무 잘 된다. 이유를 여쭤봤었다. “왜 기본생성자를 넣어야 잘 되는건가요..?”
“아, @RequestBody는 ‘리플렉션’이라는 방법으로 값을 넣어주기 때문에 그래요.”
라는 답변을 받았다.
여기서 나는 1차 충격을 받았다. 리플렉션이라는 기술을 듣기만 했지, 매번 지금은 필요없으니까.. 라고 생각하며 공부하기를 미뤘었기 때문이다. 바로 공부를 시작했고, 이유를 깨닫게 되었다.(https://jojoldu.tistory.com/407)
이래서 기초가 중요하다고 하나보다. 문제의 원인을 파악하려면, 그 구조를 알아야 파악이 쉽기 때문이다. 만약 저 분들이 안계셨으면 나는 다른 키워드로 검색했을지 모른다. 역시 너무 고민해도 혼자서 해결이 안될 때는 여쭤보도록 하자고 다짐했다. (질문은 항상 → 질문 방법 이걸 따르자 ㅎㅎ;)
그리고, 기술을 알고 사용하는 것과 모르고 사용하는 것은 정말 다르기 때문에, 기술을 사용하더라도 알고 사용하도록 하자!