[WIL] 220725-220731

Ariul·2022년 7월 31일
0

🔍Weekly I Learned

목록 보기
3/7

주특기 입문

3주 차에는 팀 과제와 개인 과제를 진행하면서 Spring 학습을 시작했다.
그리고 일주일 동안 나의 모습은........

울고 있는 나의 모습,,,,,,, 바보 같은,, 나의 ,,,모습,,,,,,,


1. 팀 과제

팀 과제는 스프링의 핵심 키워드에 대해 공부하고 정리하는 것이었다.

💡JPA가 무엇인가요?

  • Java Persistence API의 줄임말로, 자바 진영의 ORM 기술 인터페이스

  • ORM(Object-relational mapping; 객체 관계 매핑)

    • 객체는 객체대로 설계하고, 관계형 데이터베이스는 관계형 데이터베이스대로 설계
    • 이를 ORM 프레임워크가 중간에서 매핑
      ⇒ JPA가 가지는 인터페이스 규칙을 지키며 자바에서 클래스를 만들어 실행하면, DB에 테이블이 자동으로 생성된다!
  • JPA의 장점

    • JPA는 기존의 반복 코드는 물론이고, 기본적인 SQL도 직접 만들어서 실행해 준다.
    • JPA를 사용하면 개발 생산성을 크게 높일 수 있다.
    • JPA를 사용하면, SQL과 데이터 중심의 설계에서 객체 중심의 설계로 패러다임을 전환할 수 있다.
    • 이에 따라, DB와 OOP 패러다임의 불일치를 해결할 수 있다.
      ⇒ JPA를 통해 자바가 주도권을 가지는 객체 중심의 설계를 할 수 있고, 객체가 저장된 데이터를 Insert 하거나 Select 할 때 JPA가 자동으로 매핑해서 데이터를 넣어주기 때문

💡Controller, Service, Repository가 무엇인가요?

관심, 책임, 성격 등이 서로 다른 것들을 분리하면 분리된 각 요소의 응집도가 높아지고 결합도는 낮아진다. Spring은 요청을 처리하기 위한 계층을 3가지로 나누었다.

@Controller

  • Presentation Layer(프레젠테이션 계층)
  • 클라이언트로부터 HTTP 요청을 수신하고 그에 맞는 응답을 돌려준다.
  • 서비스 계층, 데이터 액세스 계층에서 발생하는 Exception을 처리한다.

@Service

  • Service Layer(서비스 계층)
  • Controller에서 전달받은 사용자의 요청에 따라 데이터를 가공해서 데이터베이스로 전달하거나, 데이터베이스에서 데이터를 전달받아 가공하여 사용자에게 전달한다.
  • 프레젠테이션 계층과 데이터 액세스 계층 사이를 연결하는 역할로, 두 계층이 직접적으로 통신하지 않게 한다.

@Repository

  • Data Access Layer(데이터 접근 계층)
  • 데이터를 저장하거나 조회하기 위해 DB에 접근하고, ORM을 주로 사용하는 계층이다.
  • DB CRUD 작업을 처리하고, DB를 관리한다.
요약하면! 
Controller를 통해서 외부 요청을 받고, 
Service로 비즈니스 로직을 수행하고, 
Repository에서 DB CRUD 작업을 처리하고 DB 관리한다!

💡Bean은 무엇인가요?

  • 컨테이너 안에 들어있는 객체로, 필요할 때 컨테이너에서 가져와서 사용한다.
  • @Bean을 사용하거나 xml 설정을 통해 일반 객체를 Bean으로 등록할 수 있고, Bean으로 등록된 객체는 쉽게 주입하여 사용 가능하다.
  • 의존성 주입은 IoC 컨테이너에 들어 있는 객체들끼리만 가능하다.

💡Ioc란 무엇인가요?

  • Inversion of Control, 제어의 역전
  • 객체의 생성에서부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀐 것을 의미, 또는 제어 권한을 자신이 아닌 다른 대상에게 위임하는 것이다.
  • 대부분의 프레임워크가 이러한 구조를 가지기 때문에 개발자는 프레임워크에 필요한 부품을 개발하고 조립하는 방식의 개발을 하게 된다.
  • 이렇게 조립된 코드의 최종 호출은 개발자에 의해서 제어되는 것이 아니라 프레임워크의 내부에서 결정된 대로 이뤄지는데, 이를 "제어의 역전"이라고 표현한다.

💡DI는 무엇인가요?

  • Dependency Injection, 의존관계 주입
  • Spring 프레임워크에서 지원하는 IoC의 형태이다.
  • 클래스 사이의 의존관계를 Bean 설정 정보를 바탕으로 컨테이너가 자동적으로 연결해 주는 것을 말한다.(컨테이너가 실행 흐름의 주체가 되어 애플리케이션 코드에 의존관계를 주입해 준다.)
  • 의존성(Dependency)
    • 현재 객체가 다른 객체를 참조하고 있다면 다른 객체들을 현재 객체의 의존이라고 한다.
    • 하나의 모듈이 바뀌면 의존한 다른 모듈까지 변경되어야 하기 때문에 위험하다.
  • DI의 장점
    • 비즈니스 로직의 특정 구현이 아닌 클래스를 생성하는데 매우 효과적이다.
    • 클래스를 재사용할 가능성을 높이고, 다른 클래스와 독립적으로 클래스를 테스트할 수 있다.

2. 블로그 백엔드 서버 만들기 개인 과제

다음 요구사항에 맞게 서비스를 완성하여 AWS 배포까지 완수하는 것이 개인 과제였다.

  1. 서비스 완성
1) 전체 게시글 목록 조회 API
    - 제목, 작성자명, 작성 날짜를 조회
    - 작성 날짜 기준으로 내림차순 정렬
2) 게시글 작성 API
    - 제목, 작성자명, 비밀번호, 작성 내용을 입력
3) 게시글 조회 API
    - 제목, 작성자명, 작성 날짜, 작성 내용을 조회 
4) 게시글 비밀번호 확인 API
    - 비밀번호를 입력받아 해당 게시글의 비밀번호와 일치 여부 판단
5) 게시글 수정 API
6) 게시글 삭제 API
  1. AWS 배포
1) RDS 연결
	- MySQL을 이용하기
2) EC2 배포 
	- Ubuntu EC2 구매 후 8080 포트와 80번 포트를 연결
    - 포트 번호 없이도 서비스에 접속 가능하게 하기

결론적으로 서비스 완성 실패! 배포도 실패! 모두 실패! 하하하하하하

(1) 기능 구현 문제

우선 나의 계획은 이러했다.

  1. 스프링을 쓰면서 만나는 무지막지한 오류들을 구글링으로 해결하기가 너무 어렵다.
    각자 버전도, 환경 설정도 다르기 때문일 것.
  2. 전체적인 흐름과 원리를 알아야 어디서 어떤 문제가 생긴 건지 알 수 있고, 해결하기 수월할 것 같다.
  3. 강의들을 찾아듣자. 스프링의 대가 김영한 님의 로드맵을 구매하자.
  4. 강의 예제(item-service)를 따라 만들자. 그리고 이를 변형하고 기능을 추가하여 과제를 진행하자.

    그런데 강의 예제의 Repository는 인터페이스가 아닌 클래스였다.
    ⇒ JpaRepository 상속 X → save나 findById 등을 Repository에 다 만들었다.
    ⇒ 상세 페이지 조회, 비밀번호 확인 후 수정과 삭제 기능 모두 구현했지만 날짜 및 정렬 기능을 구현하지 못했다.
    그래서 Repository를 인터페이스로 만들어서 JpaRepository를 상속했다.
    ⇒ 날짜 및 정렬 기능은 구현이 가능하나, 상세 페이지를 조회하면 값이 안 불러와진다.
    ⇒ 전체 페이지에는 값을 불러올 수 있으므로 API나 타임리프 문법 문제인 거 같다.

혼자 끙끙거리다 다른 팀원 분과도 함께 고민해 봤지만 해결할 수 없었다.
그래서 기술 매니저님 게더 순회 시간을 기다렸는데 그마저도 놓쳐버렸다.
이날 컴퓨터 과부하가 심해서 인텔리제이도, 크롬도 갑자기 종료됐는데 그때 게더에서 로그아웃이 되어,, 다녀가신 줄도 몰랐던,,🤦‍♀️

마감 시간이 임박해서 날짜랑 정렬 기능을 제외한 나머지를 모두 구현한 페이지를 배포하기로 했다.

(2) 배포 문제
이미 마감 전날에 배포까지 완료하신 팀원분께서 DB 연결이랑 배포는 캠프에서 제공해 주는 문서만 잘 따라가면 돼요! 라고 하셔서 DB 연결과 배포는 어렵지 않을 거라 생각했다.

근데 MySQL.... My라며.. 나에겐 Yoursql..? His.. HerSQL인 줄 몰랐지.......
처음 데이터베이스를 생성하고 연결했을 때 데이터 저장이 안 되길래
기존 데이터베이스를 삭제하고 재생성했지만 또! 실패했다

안 되겠다! 일단 배포를 하자! 라는 생각에 빌드를 했고,
배포하려고 하니 jar 파일에 엑세스 할 수 없다는 오류 메시지가 떴다.

아주 일났다.
마감시간은 다가왔고, 하는 수없이 어떤 문제를 겪고 있는지 적고 미완성으로 깃허브 URL만 제출했다.


3. 배우고 느낀점, 발전시켜야 할 점

메타인지와 일정 관리의 중요성

이번 주에 내가 실패한 원인을 분석해 보았다.

원인 1. 메타인지 부족

주특기 기간 동안 얻어 가야 할 것이 메타인지라고 했는데, 이제 그 의미를 제대로 깨달았다
아! 네 자신(주제)을 알라! 이 말이었구나

도대체 무엇이 문제였는지 분석하기 위해 다른 분들의 깃허브에 들어가서 코드를 봤다.
그리고 깨달았다. 문제를 어렵게 만든 건 나 자신이었구나.

실력이 엄청 뛰어나신 분들도 이렇게 간단하게 구현하려고 하셨는데,
나는 왜! WHY!? 내 수준도 실력도 고려하지 않고 길을 꼬아서 왔을까.

아차차 나 무지랭이었지!?

나 자신을 알고, 내 실력이 되는 선에서 문제를 해결하는 방법을 찾았어야 했다.

원인 2. 일정 관리 실패

이것도 결국 메타인지랑 이어지는 이야기이다.
기능 구현과 DB 연결, 배포 시간 등 모든 걸 고려해서 일정 관리를 했어야 했는데

안일했다.
모든 게 처음인 나의 상황을 고려하지 않았다.
모든 프로그램은 각 환경에 따라 다르게 동작하는 것도 고려하지 않았다.

나란 녀석.. 이런 변수를 예측하지 못하고 기능 구현에만 몰두하고 있었구나...... 🥹

비록 과제 구현은 실패했지만,
많이 반성했고 앞으로는 어떻게 해야 하는지를 깨달았던 뜻깊은 한 주였다.

그리고 일주일 만에 처음으로 바탕화면을 봤는데
항상 프로그램이나 크롬 창이 열려 있어서 볼 수 없었음

호엑 징그러워

프로젝트를 하다 꼬이고 꼬여서 어디서부터 어떻게 풀어나가야 할지 모르겠을 때마다 새 프로젝트를 생성했더니... 14개......?

더 이상 새 프로젝트를 생성하지 않고도 오류를 잡아낼 수 있고, 뚝딱뚝딱 원하는 걸 만들어낼 수 있는 실력 있는 개발자가 되고 싶다 😹

어떤 개발자가 되고 싶은가?

문득 내가 어떤 개발자가 되고 싶은지를 깨달았다. (실력 있는 개발자는 디폴트)

나는 노션(Notion)을 꽤 오래 써왔다.
대학생 때부터 노션에다 공부한 내용을 정리하고, 메모를 했고, 자료 정리와 일정 관리도 모두 노션으로 해왔다.

그때는 그냥 있으면 편한 서비스~ 정도로만 생각했는데
개발자가 되기 위한 로드맵을 짜고, 캠프에서 바쁜 나날을 보내다 보니
문득 '와 나 이거 없었으면 어떡할 뻔했지?'라는 생각이 들었고, 이후로 노션을 사용할 때마다 소중함을 느끼고 있다.

그리고 나에게 노션처럼, 누군가에게 '이거 없으면 어떡할 뻔했나'라는 생각이 들 만큼 가치 있고 소중한 서비스를 만들고 싶다는 생각을 했다.

그러니까 빨리 스프링이랑 친해져야지 (기승전 스프링)


4주차 예고(ft. Spring)

4주 차 과제는 3주 차 과제에서 몇몇 기능을 변경하고, 새로운 기능을 추가하는 것이다.
즉, 이번 주 과제를 하기 위해서 지난 주 과제를 완성해야 하는데..!
드디어 드디어 문제를 해결했다..! 예에~!~!~!!🎉
이제 날짜에 따라 최신순 정렬도 되고, 상세 조회 페이지에서 값도 불러와진다. 수정도 가능하다!
근데 왜 때문인지 삭제가 안 된다

어쨌든 이제 여기서 로그인, 회원가입, 댓글 관련 기능들을 추가해 나가면 된다!

일주일 동안 심신이 힘들었지만🥲
목요일에 안 풀리던 문제가 토요일에 풀리는 것을 보니
시간이 지나면 결국 다~ 해결이 되는구나 싶다

다음 주에는 또 어떤 짤로 울고 있을지 모르지만ㅋㅋㅋㅋ
나는 결국 해낼 걸 알고 있다!!!!!

++
그리고 우리 스프링이랑 에스큐엘이,,
너희 똑똑한 사람 좋아하는 거 같은데 내가 진짜 열심히 공부할게
나랑 빨리 친해지자! 제발❤️

profile
정성과 진심을 담아 흔적을 기록하자💡

0개의 댓글