안녕하십니까 강사님 강의 너무 잘 듣고 있습니다. 서버 개발에 필요한 일련의 과정을 정리하는데 많은 도움이 되고 있습니다.
강의 내용에 대한 질문은 아닙니다. 이제 취업을 하기위한 포트폴리오를 만들 단계라고 생각하는데 개인 프로젝트를 할 때 가이드 라인을 여쭙고자 질문드립니다.
실무에선 상황마다 물론 다르겠지만 강사님께선 보통 프로젝트 주제를 선정하고,
요구사항을 정리한 다음
테이블 설계를 하시고 그다음
API 스펙을 정한 다음 개발에 착수하시나요?
그리고 API 스펙을 정할 때 controller에 진입하기 위한 경로들을 모두 정하신 다음 본격적인 코드 작성을 하시는지도 궁금합니다.
항상 개인 프로젝트를 하다 보면 프로젝트 시작 단계에서 고려하지 못한 부분들을 놓쳐 결국 프로세스가 뒤죽박죽 되고 헷갈리게 되는것 같더라구요..
그래서 강사님의 개인적인 개발 프로세스를 슬쩍? 알려주시면 감사하겠습니다.
좋은 강의 만들어주셔서 감사합니다:)
그리고 프로젝트를 할 때 완성된 결과물을 보여주기 위해선 어느 정도의 ui도 필요할 것 같은데 이런 경우 rest api를 만들기 보단 ssr 애플리케이션을 만드는 것이 나을까요..?
두서 없는 질문이라서 죄송합니다ㅎㅎ..
안녕하세요, lano님! 좋은 질문 감사드립니다! 😊
질문 주신 내용에 대해 하나씩 답변 드려볼게요!!
[1. 상황마다 물론 다르겠지만 강사님께선 보통 프로젝트 주제를 선정하고, 요구사항을 정리한 다음 테이블 설계를 하시고 그다음 API 스펙을 정한 다음 개발에 착수하시나요?]
아~ 말씀해주신 것처럼 상황마다 굉장히 다르긴 합니다!
다만, 확실한건 요구사항 정리를 먼저 하는건 맞습니다! 요구사항이 정리되어야, 어떤 방식으로 코딩을 할지 정할 수 있으니까요! 그 다음은 보통 API에 대한 대략적인 스펙을 생각합니다. API의 스펙을 생각하다 보면 테이블에 도움이 되는 부분이 있거든요!
예를 들어, API를 개발해야 하는데, 1번 API에서는 유저 정보, 유저 세부 정보, 책 정보, 책 세부 정보와 같이 정말 많은 데이터를 조회해야 한다고 해보겠습니다. 이때 만약 유저 정보와 유저 세부 정보를 다른 테이블로 분리하게 되면 1번 API가 호출될 때마다 2개의 테이블에 계속해서 조회를 해야하죠. 때문에 테이블 구조를 하나로 합칠 수도 있고, 원천 데이터 테이블은 각각 두되 이를 조회용으로 만드는 기능 및 통합용 테이블을 추가할 수도 있습니다.
그 다음은 위에서 보신것처럼 API를 구현하기 위해 자연스럽게 테이블 구조를 고민하게 되고, 개발을 진행하며 상호보완적으로 다듬어 나가게 됩니다.
[2. 그리고 API 스펙을 정할 때 controller에 진입하기 위한 경로들을 모두 정하신 다음 본격적인 코드 작성을 하시는지도 궁금합니다]
controller에 진입하기 위한 경로라고 하시면, HTTP의 method나 path를 말씀해주시는 것 같습니다!
이 부분은
@GetMapping어노테이션 등으로 쉽게 바꿀 수 있다보니, 클라이언트와 논의가 완료되어 있다면 그 과정에서 자연스럽게 경로가 정해진 상태로 개발에 착수하게 되고요! 논의가 아직 되지 않았다면, 그냥 아무렇게나 (😅) 경로를 정해둔 다음 클라이언트와 논의해서 최종 결정하는 편입니다.[3. 항상 개인 프로젝트를 하다 보면 프로젝트 시작 단계에서 고려하지 못한 부분들을 놓쳐 결국 프로세스가 뒤죽박죽 되고 헷갈리게 되는것 같더라구요..]
아이고~ 그쵸그쵸! 사실 이런 과정은 어떤 프로젝트를 진행 하더라도 마찬가지입니다! 이런 느낌을 표현해주신 것 같아요!!
A만 생각해서 개발을 했더니~ 예외 case로 B와 C가 생겼다. 그래서 B와 C를 대응하려고 했더니 점점 코드가 엉켜가고~ 현재 테이블로는 대응이 안되는 것 같고~~ 점점 쉽지 않다!이는 새로운 프로젝트를 시작하더라도 마찬가지이고 (결국 코드는 작성한 순간 레거시가 되니까요) 심지어는 대부분 만들어진 프로젝트를 유지보수하니 항상 겪는 상황이라 할 수 있죠 ㅎㅎㅎ
case마다 대응 방법이 너무 다르기에 "이렇게 하면 해결됩니다!" 라고 명확히 알려드릴 수는 없지만, 결국 하나하나 고민하고 풀어내는 과정에서 경험과 노하우가 쌓이게 되고 익숙해지는 것 같습니다!
[4. 그리고 프로젝트를 할 때 완성된 결과물을 보여주기 위해선 어느 정도의 ui도 필요할 것 같은데 이런 경우 rest api를 만들기 보단 ssr 애플리케이션을 만드는 것이 나을까요..?]
몇 가지 방법이 있을 것 같아요!! SSR (자바를 사용하신다면, thymeleaf로 view를 구성하실 수도 있고, Next.js 같은 프레임워크를 쓰실 수도 있죠!) 을 쓰실 수도 있고 아니면, REST API를 만드시고 react와 같은 CSR로 화면을 구성하실 수도 있을 것 같습니다!
react, spring boot 환경 구성과 같은 키워드로 검색하시면 https://velog.io/@u-nij/Spring-Boot-React.js-%EA%B0%9C%EB%B0%9C%ED%99%98%EA%B2%BD-%EC%84%B8%ED%8C%85 와 같은 글을 보실 수 있습니다! 👍
조심스러운 생각으로는, 어떤 방법을 사용해서 프로젝트를 진행하셨는지 보다 프로젝트 진행 과정에서 부딪힌 문제와 해결 과정이 조금 더 중요하지 않을까 싶습니다! 😊
제 답변이 도움이 되었으면 좋겠습니다~!!
언제든 또 궁금한 점 있으시면 편하게 질문 주세요!! 감사합니다! 🙇
답글
lano
2023.04.15세세하고 친절한 답변 감사합니다. 덕분에 머리속을 정리할 수 있었습니다.
정말 강의 들으면서 절차 지향에서 조금 더 객체 지향적으로 리팩토링 하는 부분도 인상적 이었고 배포와 관련된 강의도 정말 좋았습니다.
또 다른 좋은 강의로 뵙게 되면 좋겠습니다 감사합니다!!