Post

삐약이 시절 처음 Spring 으로 백엔드 개발을 마치고 작성했던 회고를 슬쩍 꺼내 올려봅니다

Posted
By Jung Dayeon
19 min read

안녕하세요 🫠 이번에는 부끄럽지만 처음으로 Spring boot 를 활용한 백엔드 개발을 무사히 마치고 작성했던 회고를 메모장에만 보관해두고 있다가 슬쩍 올려보고자 합니다 그동안 메모장에 봉인해두고 살다가 갑자기 올리는 이유는, 뭐든 초심을 지키면서 내가 처음에 의도했던 방향대로 나아가는 건 어렵기 때문입니다.

처음 개발을 시작했을 때, 잘하는 사람들은 나와는 먼 존재처럼 느껴졌고, 나는 나 자신과의 싸움에 집중했습니다. 부족한 부분을 살펴보고 반성하며 스스로 발전하려고 노력 했습니다. 하지만 시간이 지나면서, 나도 모르게 남들과 나를 비교하는 모습을 발견했습니다. 비슷한 위치에서 경쟁해야 할 사람들의 기술 스택이나 강점을 보며 나를 돌아보기보다는, 내 결과물이 완벽하지 않다는 이유로 스스로를 부끄럽게 여긴 채, 앞서간 사람들을 따라잡으려 한다는 걸 느꼈습니다.

어제의 나보다 더 나은 사람이 되자라는 유명한 말이 있듯 저도 저만의 색이 있고 강점이 있는 사람이고, 단점을 극복하는 것도 물론 중요하지만, 그 과정에서 나의 강점을 잃지 않는 것이 더 필요하다고 생각합니다. 단점은 갈고 닦아도 남들과의 경쟁에선 장점이 될 수 없고, 결국 단점을 가장 축소화하면서 제 강점을 잘 살리는게 중요한 것 같아요.

그리고 그 강점들이 첫 회고에서도 잘 드러난다고 생각합니다. 그래서 그 당시의 솔직한 회고를 공유하며, 지금의 내가 초심을 잃지 않고 잘 나아가고 있는지 돌아보는 계기로 삼으려고 합니다.

FACT

  • 문고 1차 API 작성
    • ENTITY
      • BOOK Table
      • BOOK_RENTAL Table
    • DAO
      • BookRepository
      • BookReservationRepository
      • FindAdminBookRepository & FindBookRepository
    • DTO
      • AdminBookInfoDto
      • BookInfoDto
      • SearchDto
    • SERVICE
      • BookAdminService
      • BookService
    • CONTROLLER
      • BookAdminController
        • findAllBook
        • createBook
        • updateBook
        • deleteBook
        • returnBook
      • BookController
        • findAllBook
        • bookReservation
        • extendBook

FEELING

  • 코드 및 DB 분석
    정확하게 어떤 걸 해야하는지 몰라서 정말 말 그대로 코드를 읽었다. 기존에 작성된 코드의 방식과 스타일, 명명 방식과 스타일 등을 참고 하고 그 방식을 맞춰야 하는 줄 몰랐다. 직관적인 naming과 기존 코드 분석이 삽질을 단축 해준다. 고등학교 때 문제의 답은 선지와 질문에 있다고, 이미 존재하는 기능을 구현하다 보니 문제의 답이 이미 구현되어 있는 코드에 대부분 존재했다.
  • API 개발 설계 문서
    코드를 작성할 때 한 번도 설계를 해본 적이 없었다. 학교에서는 교수님이 설계에 대한 가이드라인을 제시해주셨고, 프로젝트를 진행할 때에는 있었으면 하는 기능 위주로 그저 내키는 대로 코드를 작성했다. 솔직히 작성할 때만 해도 문서 작성의 필요성을 크게 실감하지 못했다. 하지만 이를 작성하고 코드 작업에 들어가니 내가 무엇을 어떤 가이드 라인으로 만들어야 하는가에 대해 보다 구체적인 틀이 잡혔고 이게 엄청난 삽질의 단축을 가져다 줬다. DRF로 팀프로젝트를 진행했을 때도 필요한 API나 Model에 대한 설계를 전혀 진행하지 않았고 그러다 보니 역할 분담이나 유지보수를 제대로 진행 되지 않고 마구잡이로 진행된 개발이었다 생각한다. 그때는 무언가 삐걱대는 것 같았고 그 이유는 잘 몰랐는데, 이제와서 생각해보니 설계나 계획 단계가 전혀 없어 생긴 문제인 것 같다. 설계 및 계획의 중요성에 대해 실감할 수 있던 기회였다. 개발이라는게 꼭 코드만 작성하는 작업이 아님을 깨달았다.
  • 유지보수와 가독성
    1학년 겨울방학 때 lua script 로 교내 게임 개발 해커톤에 참여한 적이 있다. 처음으로 다른 분들과 함께 개발을 진행한 경험이었다. 때문에 가독성이나 취합에 대해서는 전혀 고려하지 않아 scene 으로 작성해야할 것을, 나 혼자만 돌아갈 수 있는 코드를 작성했다. 당연하게 취합 과정에서 문제가 발생했다. 취합 담당하시는 분이 처음에는 나한테 안내 없이 혼자 오류 수정을 진행 하셨지만, 그 당시 나는 주석을 꼼꼼하게 작성하지 않았다. 필요성을 느끼지 못했었다. 결국 혼자 해결에 한계를 느끼시고 나에게 오류에 대한 연락을 취하셨고, 내가 scene 으로 코드를 변경을 진행했다. 당시에는 내가 오류를 수정 했고 프로젝트를 무사히 끝 마쳤으니 크게 문제 될 건 없다고 생각했었다. 하지만 이때 주석을 더 정확하게 달거나 상황 및 코드 공유를 더 용이하게끔 했다면 그 분이 코드 변경에 있어 큰 어려움을 겪지 않았을 것이고 결과적으로 해결한 것과 별개로 명백하게 나의 큰 잘못임을 이번 기회에 더 깨달았다. 이번에 가장 크게 느낀 건 가독성과 유지보수 가능한 코딩을 위한 노력이었다. 크게 고려하지 않았던 부분이라 그런지 더 신선하게 다가왔다.
  • 코드 리뷰
    처음으로 내 코드에 대한 리뷰를 받았다. 생각하지 못한 것에 대해 고려해볼 수 있는 기회가 되어 재밌었다. 그리고 내 코드에는 크게 이유가 없었음을 깨달았다. 내가 왜 이렇게 작성했고 왜 필요했는지에 대해 사고하면서 작성했어야 했다. 그동안은 내가 작성하고 싶은 방식대로 작성하고 코드 줄 수가 내 기준에서 간결 하면 만족했고 별로 고민해본 적 없는 영역이었던 좋은 코드란 무엇일까에 대해 고민하게 되었다. 하지만 내 지식이 얕아 그런지 좋은 코드와 DB 작성의 기준이 무엇일까는 아직 전혀 모르겠다. 
  • 내 성향
    개발 기간을 여쭤 보셨을 때, 안 해본 것에 대해 장담할 수 없어 그냥 4일이라고 찍었다. 난 정말 벼락치기에 특화 된 성향이기 때문에 4일이라는 리밋을 정해놓자 딱 그 안에만 끝낼 생각을 했고 역시 1-2일차 때는 느슨하게 진행하다가 3일차 때 벼락치기처럼 만들었다. 각 날짜 별로 목표치를 정하고 더 계획적으로 진행했으면 좋았겠다는 아쉬움이 남는다. 내가 내 한계를 미리 정해놓으면 안되겠다. 딱 그 정도치만 하려 하고 결국 딜레이 되면 그 정도도 못하게 된다.
    아는 게 없고 할 줄 아는 게 딱히 없다 보니 이러한 상황에서 열정만 보이는게 자칫 하면 취해 있을 수 있다는 생각을 한다. 그렇다 보니 열정도 없는 사람이 된 것 같다. 분수에 맞게 행동 하려다 보니 결국 더 수동적이고 위축 됐던 것 같다. 초반에 나를 잘 마인드 컨트롤 하고 적당한 정도의 자신감을 유지하는 방법이 필요하다. 초반 부스터를 내기 위한 방법을 강구해야겠다.
    내가 모르고, 못하는 걸 드러내는 건 어렵다. 물어보기 전에 질문을 필터링 하다보니 결국 남는 질문이 별로 없고, 시간이 지나면 해결되거나, 크게 안 궁금해진다. 이렇게 하면 발전이 더디고 해결이 늦다. 초등학생 때 영어학원 선생님도 미국에 캠프 갔을 때도 부딪히며 늘어야 하는데 나는 내 영어 문장이 완벽하지 못하다는 생각이 들면 입을 열지 않고, 이게 회화에 좋지 못한 습관이라는 소리를 들었는데 성인이 된 지금까지 못 고친 것 같다. “다 했다” 는 기준을 모르겠다. 무엇을 더 할 수 있는지 모르겠는데 다 한 건 아닌 것 같을 때가 제일 어렵다. 그럴 때 도움을 요청해야 하는데 그냥 멀뚱멀뚱 있었다. 반성해야겠다.

FINDING

처음으로 사용한 Spring이다 보니 관련 모든 내용이 FINDING 이긴 하지만, 추려서 정리하기로 했다.

  1. ENUM 사용법
    • String을 사용할 때보다 관계와 열거형임을 더 잘 드러낼 수 있었고, 값을 제한할 수 있다는 이점이 있었다.
    • 다시 사용되는 경우가 많다보니 따로 class로 빼서 관리하는 편이지만, 같은 class에 배치 시 관계를 보다 잘 알 수 있어 국소적으로 사용되면 같은 class에 배치해도 좋다.
  2. requestParam 과 requestBody 의 차이
    • requestParam은 요청 매개변수에 들어있는 기본 타입 데이터를 메서드 인자로 받아올 수 있다. 즉, Request URL의 쿼리 파라미터를 가지고 온다.
    • requestBody는 클라이언트가 전송하는 json 형태의 HTTP Body 내용을 Java Object로 변환 시켜주는 역할이다.
    • 따라서 좀 더 감추고 싶은 정보일 때 requestBody를 사용한다고 한다.
    • requestPart는 JSON, XML 처럼 복잡한 내용을 포함할 때 사용하는게 더 좋다. 따라서 사진 업로드 등에서 많이 사용된다.
  3. Page, List, Optional
    • List는 페이지 내용을 리스트로 반환한다. 따라서 페이지 수를 표시할 필요 없는 SNS 등에 주로 사용된다.
    • Page는 조회 쿼리 이후 전체 데이터 개수를 조회하는 쿼리가 한 번 더 실행된다. 따라서 전체 데이터 개수나 전체 페이지 수까지 확인할 수 있다. 문고는 페이지 수를 표시해야 하기 때문에 Page를 사용하여 작성하는 것이 용이하다.
    • Optional는 null이 올 수 있는 값을 감싸는 Wrapper 클래스로, 참조하더라도 NPE가 발생하지 않도록 도와준다.
  4. AWS S3
    • 파일 서버의 역할을 하는 서비스.
    • 서비스 인터페이스를 사용하여 웹에서 언제 어디서나 원하는 양의 데이터를 저장 및 검색 가능.
    • HTTPS 프로토콜을 사용하여 SSL로 암호화된 엔드포인트를 통해 데이터를 안전하게 업로드/다운로드 할 수 있으며 상주 데이터를 자동으로 암호화.
  5. Swagger 사용법
  6. Annotation 정리
    • @Transactional
      • 데이터베이스를 다룰 때 트랜잭션을 적용하면 데이터 추가, 갱신, 삭제 등으로 이루어진 작업을 처리하던 중 오류가 발생했을 때 모든 작업들을 원상태로 되돌릴 수 있다.
      • 두 개 이상의 데이터베이스를 참조할 때 주로 사용한다
    • lombok 생성자 주입 에노테이션
      • @NoArgsConstructor 어노테이션은 파라미터가 없는 기본 생성자를 생성
      • @AllArgsConstructor 어노테이션은 모든 필드 값을 파라미터로 받는 생성자를 생성
      • @RequiredArgsConstructor 어노테이션은 final이나 @NonNull인 필드 값만 파라미터로 받는 생성자를 생성
    • 스프링 빈으로 스프링 컨테이너에 등록하기 위한 에노테이션
      • @Component는 사용자가 만든 임의의 클래스를 빈으로 등록시키기 위해 사용. @Controller, @Service, @Repository 애노테이션은 @Component를 포함.
      • @Bean은 개발자가 임의로 만든 class 파일이 아닌 Map, List 등과 같은 직접 제어를 하지 않는 내외부 라이브러리에 대하여 사용하게 된다.
      • @Autowired는 @Component을 호출할 때 사용해 해당 @Component 선언된 클래스의 기능을 자유롭게 사용.

FUTURE ACTION

  • 코드를 작성할 때도 설계할 때도 이유를 생각하고 스스로 납득할 만한 해답이 있는 상태로 작성해야겠다.
  • 코드를 다 작성하고 주석을 마지막에 추가했다. 주석부터 달고 코드를 맞춰 작성해야겠다.
  • 데이터베이스 설계를 어떻게 해야하는지 잘 모르겠다. 데이터베이스에 대한 공부가 필요하다.
  • 일기 작성을 쉬고 있다보니 당일 기억이 휘발성이다. 당일에 대한 회고를 짧게라도 기록으로 남겨둬야겠다.
Doodle, Retrospect
Retrospect
This post is licensed under CC BY 4.0 by the author.