728x90

UMC(University MakeUs Challenge)

1~3월 동안 어플리케이션 개발을 진행했다.

Java 기반 Spring Framework를 사용했으며, Mysql 데이터베이스를 사용했다. 

회원 가입, 회원 정보 수정, 로그인, 로그아웃, 회원 탈퇴 등 유저관련 기능들을 구현했으며, 로그인에서는 Kakao Login, Naver Login 과 같은 소셜 로그인 기능을 구현했다.

https://pw4ngc0.tistory.com/entry/%EC%BB%A8%ED%8C%8C%EB%A8%B8-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8

 

컨파머 프로젝트 후기

UMC 연합동아리 활동으로 앱개발 프로젝트를 진행했다. 1월 6일 ~ 3월 22일 까지 진행했으며 개인적인 사정으로 프로젝트 팀을 나오게되었다. 마침 오늘 Play스토어에 안드로이드 버전을 런칭하여

pw4ngc0.tistory.com

관련 후기이다.

 

공기업 전산직

어플리케이션 개발과 별개로 계속 진로에 대한 고민을 했었다. 

대부분의 IT관련 기업이나 IT 직무의 사무실들이 수도권에 위치하지만 수도권에서의 삶에 확신이 없어 고민을 했다.

많은 사람들과 복잡한 대중교통, 높은 집값 등의 이유와 수도권의 장점인 좋은 환경은 술을 전혀 마시지 않는 나에게 오히려 단점이라고 생각했다.

 

또 다른 이유는 계속 경쟁하며 살아갈 자신이 없다는 것이다.

대외활동과 군대에서 정말 뛰어난 사람들을 많이 만났다. 정말 학벌이 좋은 머리가 좋은 뛰어난 사람들, 좋은 학벌이 아닌 사람들 or 고졸 등의 사람들 중에서도 컴퓨터를 잘하고 정말 뛰어난 능력을 가진 사람들을 많이 만날 수 있었고, 이야기를 나눌 수 있었다. 

이러한 사람들은 머리가 정말 좋거나 컴퓨터를 정말 좋아하는 사람들이였다.

 

나름 학부생 기간동안 열심히 살았다고 생각한다. 학과공부, 대외활동, 프로젝트, 해당 활동들과 프로젝트들을 소화하기 위한 학습, 입대 후 군대에서의 개발 업무 등 어느정도 경쟁할 수 있을 정도의 삶은 살았다고 생각한다.

하지만 취업 후에도 학부생 기간 처럼 계속 열심히 살기에는 너무 힘들 것 같다는 생각이 들었다.

나는 머리가 좋지 않고 컴퓨터 공부 보다 놀거나 쉬는것을 좋아한다.

그렇기 때문에 위에서 말한 뛰어난 사람들이 많은 일반적인 대기업이나 IT기업 내에서 20~30년 동안 경쟁하기에는 어렵다고 생각했다.

 

위와 같은 이유들로 지방 공기업 전산직을 목표로 결정 했다.

 

현장실습

8월 1일 ~ 12월 31일 까지 5개월간 (주)쓰리디랩스 에서 현장실습을 진행했다.

현장실습을 진행한 이유는 보수적인 공기업 특성상 인턴이나 현장실습과 같은 회사경험을 좋게 생각할 것이라는 생각이 있었고 돈을 좀 벌고싶다고 생각해 현장실습을 지원하고 진행하게 되었다.

 

회사업무로는 회사내의 자체개발 소프트웨어 버그 / 기능 테스트 및 보고서 작성, 개발 업무 등을 진행했다. 

정부기관과 프로젝트를 진행하는 회사로 이전에 경험하지 못한 다양한 개발 경험들을 쌓을 수 있었다.

 

회사 업무도 적당히 좋았고 회사사람들도 정말 좋은분들이었다. 이런 회사가 또 있을까 싶을 정도로 좋은 사람들이 많았으며 실습생인 나에게 많은 배려를 해주어 정말 편하게 회사생활을 할 수 있었다.

 

회사 복지도 정말 좋았다. 매달 100만원에 가까운 간식비가 회사에서 직원들을 위해 제공되어 원하는 간식을 신청하면 주문해서 회사내에서 먹을 수 있게 해주었다. 간식 주문 업무를 담당하시는 직원분께서 편하게 요청하라고 말씀해주셔서 눈치없이 정말 편하게 요청했다. 먹고싶은 간식들을 다 먹어볼 수 있었다.

 

각 팀마다 매달 팀운영비가 주어졌다. 내가 속한 팀은 5명이었는데 월 30만원씩 회사에서 제공되어 회식이나 문화의날 때 사용할 수 있었다. 항상 점심에 팀회식을 진행했는데 비싸고 맛있는 음식들을 다양하게 먹어볼 수 있었다.

 

1~2달에 한번씩 회사 체육대회가 있었다. 마지막주 금요일에 했었는데 탁구, 풋살, 축구 등 다양한 종목들을 진행했다. 그중 11월에 진행한 축구를 제일 재밌게 했었다. 항상 회사 채용공고를 보면 이런 복지가 있는 것을 좋다고 생각했었다. 그러나 정직원 분들이 해당 날짜엔 업무진행이 불가능하여 행사날 전후로 정말 바쁘게 근무하는것을 보면서 무조건 좋은 것은 아니구나 라는 것을 알게 되었다.

 

유능한사람이 회사에 얻는 위치에 대해서도 알게되었다.

내가 속한 팀의 팀장님이 정말 유능한 분이였다. 대화만 해봐도 기술적으로 지식이 깊고 뛰어나신 분이란 것을 느낄 정도였다. 회사의 다른 분들과 이야기해도 항상 팀장님에 대한 평가는 좋은 평가였으며 많은 분들이 팀장님을 존경하는 것을 알 수 있었다. 

나도 회사에 입사한다면 팀장님처럼 유능한 사람으로서 인정 받을 수 있게 노력할 것이다.

 

 정직원분들이 정말 편하게 생활할 수 있도록 배려 해주시고, 궁금한 사항들에 대해서도 모두 답변 해주셔서 많이 배워갈 수 있었습니다. 모든 (주)쓰리디랩스 구성원 분들과 현장실습 기회를 주신 대표님, 제출 서류를 항상 검토해주시고 조언해주신 소장님, 항상 잘 챙겨주신 3팀 팀장님 및 팀원분들 정말 감사합니다. 

 

공기업 준비

현장실습을 진행하면서 공기업 관련 자격증 준비를 조금씩 할 수 있었다.

10월달에 보안기사 필기에 합격했으며 실기는 2023년도 1회차 시험을 준비할 생각이다.

https://pw4ngc0.tistory.com/entry/2022-4%ED%9A%8C-%EC%A0%95%EB%B3%B4%EB%B3%B4%EC%95%88%EA%B8%B0%EC%82%AC-%ED%95%84%EA%B8%B0-%ED%9B%84%EA%B8%B0

 

2022 4회 정보보안기사 필기 후기

정보보안기사 필기 후기 2022년도 4회 정보보안기사 필기시험에 합격했습니다. 2022년도 4회차 시험문제와 답안 입니다. 정보보안기사 필기를 준비하시는 분들은 꼭 풀어보시는 것을 추천합니다.

pw4ngc0.tistory.com

 

한국사 1급도 취득했다.

첫시험은 보안기사 필기시험 후 2주뒤였는데 거의 공부를 하지않았다. 보안기사 공부로 너무 지쳐있어서 거의 공부를 하지못했고 한국사를 조금 쉽게 생각했던것 같다. 

이후 11월 한달동안 진짜 열심히 준비했다. 한국사 기본기도 전혀 없었고 단순 암기 능력이 매우 낮아 한국사 공부를 하는데 어려움이 많았던 것 같다. 기본적인 개념 숙지 후 47회차부터 61회차 까지 모든 회차들을 풀면서 모든 보기들에 대한 해설도 정리하면서 오답을 진행해 원하는 등급을 얻을 수 있었다.

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

 

2023

 

기본적인 공기업 전산직 서류준비들을 진행할 생각이다.

1~2월 토익

3~4월 보안기사 실기

5~10월 정보처리기사 필/실기

10~11월 OPIc

 

이후 NCS 및 전공공부를 진행해 공기업 필기시험 준비를 진행할 생각이다. 빠르면 2024년도 늦어도 2025년도에는 원하는 공기업에 입사하고싶다.

 

공기업과 공공기관들의 정원을 줄인다는 기사들이 많이나왔다. 하지만 별로 의미없다고 생각한다. 1명을 뽑더라도 결국 될사람은 되기 때문에 항상 열심히 꾸준히 준비할 생각이다.

'중요한 것 꺾이지 않는 마음'

 

원하는 것을 얻기위해 열심히 노력하는 2023년도를 보낼것이다.

728x90

'ETC > Review' 카테고리의 다른 글

2022 4회 정보보안기사 필기 후기  (0) 2022.10.24
컨파머 프로젝트 후기  (0) 2022.03.23
2021 회고록  (0) 2021.12.31
728x90

정보보안기사 필기 후기

2022년도 4회 정보보안기사 필기시험에 합격했습니다.

2022년도 4회차 시험문제와 답안 입니다. 정보보안기사 필기를 준비하시는 분들은 꼭 풀어보시는 것을 추천합니다.

틀린문제의 빨간 볼펜으로 작성한 숫자의 경우 가답안의 정답입니다. 실제 발표된 정답과 다를 수 있으므로 시험문제 아래의 정확한 답안과 대조하여 학습하시길 바랍니다.

문제

답안

점수

공부방법 및 기간

알기사 정보보안기사 필기책과 필기강의를 이용해서 학습했습니다.

필기강의를 통해서 내용을 먼저 이해하고 이해한 내용을 복습하여 암기하는 방식으로 공부를 했습니다.

현장실습 기간동안 회사와 병행하며 평일 퇴근후 3~4시간, 주말 8~10시간정도씩 한달 ~ 한달 반 정도 준비했습니다.

 

알기사 책의 이론내용들이 정말 잘 정리되어 있으며 강의 또한 강사님 께서 쉽게 이해할 수 있도록 설명해 주셔서 편하게 공부할 수 있었습니다. 문제의 경우 시간이 부족해 1200제중 600문제 정도만 풀고 최근 기출문제들을 풀며 공부했습니다. 각 문제들에 대해 해설이 잘 정리되어있어 이론학습 후 알기사 1200제 및 기출 책에 있는 내용들을 이용해 학습하는 것을 추천합니다.

 

시험

2022년도 4회차 필기 10월 8일 토요일 14:00시 PBT 시험을 응시했습니다.

 

시험은 2시부터 2시간 반정도 진행하여 4시반까지 진행했습니다. 12시쯤 입실하여 기출 문제들 위주로 공부를 했습니다.

-> 해당 시간동안 공부했던게 정말 큰 도움이 됐다고 생각합니다.

 

기출이나 예상문제들과 똑같은문제들은 10%~ 20% 정도였던것 같습니다. 많은 문제들을 풀어보지 못해 정확한 수치는 아니지만 몇몇 문제들에서 기출에서 풀었다고 생각했던 문제들이라는 느낌을 받았습니다. 또한 똑같은 문제들은 아니지만 비슷한 문제들도 정말 많았습니다.

 

자신있었던 시스템보안에서 점수가 가장낮게 나왔고 제일 어렵다고 생각했던 정보보안관리 및 법규에서 점수를 가장 잘받았습니다. 단점을 보완하고자 시험직전 정보보안관리 및 법규 내용을 상세하게 공부한것이 도움되었습니다. 시스템보안에서는 문제들이 어렵기도 했고, 긴장해서 실수한 부분들이 많았습니다.

 

 헷갈리는 문제들과 어려운 문제들에 대해서는 소거법을 통해 보기를 줄이고 찍었던것들이 정답을 받아 운좋게 합격할 수 있었습니다.

 

시험 합격발표는 2022.10.21 9:00시에 발표되었습니다. 필기시험 면제의 경우 시험응시일이 아닌 합격 발표일 기준 2년으로 2022.10.21 ~ 2024.10.21 기간동안 필기시험 면제를 받아 언제든 실기시험에 응시 할 수 있습니다.

후기

준비 시간이 부족해 꼼꼼하게 공부하지 못해 많이 아쉽습니다. 시험 당일날 까지도 이론지식 습득이 많이 부족하다고 느낄 정도였습니다. 좀더 꼼꼼하게 공부했더라면 더높은 점수와 동회차 실기시험도 준비할 생각이었으나 실기시험의 난이도와 준비기간 및 현재 지식 수준을 고려했을 때 동회차 실기시험은 무리가 있다고 생각했습니다.

 

정보보안기사 시험 자체의 난이도가 높다고 생각합니다. 범위도 다양하고 최신 취약점이나 리눅스 설정파일, 리눅스 명령어를 통한 설정 등 이론책이나 기출에 나오지않는 범위의 문제나 보기가 나오는경우도 있다 보니 전반적인 이론내용이나 기출문제들에 대해서는 정확하게 이해하고 숙달하고 있는것이 중요하다고 생각합니다. 또한 보안이라는 분야특성상 컴퓨터공학의 전반적인 지식을 바탕으로 응용하는 분야이기 때문에 컴퓨터공학에 관련된 지식만으로는 합격하기 어렵다고 느꼈습니다. 전공자분들도 꼼꼼하게 공부하시는 것을 추천합니다.

 

합격 커트라인은 100문제중 60문제 정답시 합격이기 때문에 어느정도 학습을 했다면 어려운 시험내용에서도 합격하는것은 가능하다고 생각합니다. 절반인 50문제는 확실하게 맞히고 50문제중 10문제를 찍어서 맞힐경우 합격이 가능하기 때문에 저와 같은 경우 처럼 학습이 부족하더라도 '합격'은 가능하다고 생각합니다. 하지만 이후 실기 시험에서는 정확한 지식내용을 요구하기 때문에 동회차 필실기를 준비하실 분들이라면 이론내용을 꼼꼼하게 학습하시는것을 추천합니다.

필기 시험을 준비하면서 학습의 부족함을 많이 느껴, 정보보안기사 실기시험은 2023년도 1회차 시험을 준비할 생각입니다.

 

각종 시스템해킹 기법과 네트워크 해킹기법의 경우 동아리와 BOB에서 직접 실습하고 학습했던 것들이 종종 있어 공부하기 편했습니다. 보안기사를 공부하면서 해킹동아리 및 BOB등의 경험들이 기억나 좋았습니다. 

728x90

'ETC > Review' 카테고리의 다른 글

2022  (0) 2022.12.31
컨파머 프로젝트 후기  (0) 2022.03.23
2021 회고록  (0) 2021.12.31
728x90

UMC 연합동아리 활동으로 앱개발 프로젝트를 진행했다.

1월 6일 ~ 3월 22일 까지 진행했으며 개인적인 사정으로 프로젝트 팀을 나오게되었다.

마침 오늘 Play스토어에 안드로이드 버전을 런칭하여 해당 프로젝트의 리뷰를 남긴다.

 

프로젝트 주제

OTT 서비스들에대해 작품을 추천하는 어플리케이션이다. 넷플릭스와 디즈니+, Apple TV 등등 다양한 OTT서비스들의 작품들을 디비에 저장하고 유저들 개개인의 취향에 맞게 작품을 추천하는것이 최종 목표이다.

 

팀 구성

1월~2월까지는 백엔드 Spring 4명, 프론트 android 3명, 디자이너 1명으로 팀으로 진행했으며,

3월 22일 현재까지는 spring 3명, android 2명, ios 1명, 디자이너 1명으로 진행했다.

나는 Spring 파트로 프로젝트 진행을 했으며, 개인적인 사정으로 오늘까지만 프로젝트에 참여했다.

Android 어플리케이션은 현재 Play스토어에서 다운받을 수 있으며, IOS 버전도 출시될 예정이다.

 

프로젝트 구조

Spring, Mysql 등을 사용했으며 Spring은 intellij 프로그램을 통해 작성했다. 서버는 AWS의 Ubuntu 환경에서 작동하며 이미지 파일의 경우 S3에서 처리했으며, DB처리의 경우 JDBC로 정상적인 서비스를 구현하고 이후 JPA로 변경하는 작업을 수행했다.

대략적인 어플리케이션 동작 구조이다.

나는 서버인 Spring파트를 맡아서 프론트에서 보내는 요청에따라 DB에서 데이터를 가져와 프론트에 전송하는 기능들을 구현 했다.

 

Spring 구조

Spring 내부구조이다. 회원가입이나 회원탈퇴, 정보수정 등 디비의 Update, insert, delete 관련된 API들은 UserService에 구현했으며, 정보수정 및 회원 정보조회, 로그인과 같이 select구문을 사용하는경우 UserProvider에 구현했다.

프로젝트 진행

Spring에서 소셜로그인, 회원가입, 나의정보보기, 나의 정보수정, 회원 탈퇴 API를 만드는 것을 담당했다.

 

로그인

소셜로그인 기능으로는 카카오로그인과 네이버 로그인을 구현했다. 그중 위 코드는 카카오 로그인이다.

PostLoginReq 데이터 객체 형식으로 들어오는 데이터를 받아 유저가 디비에 존재하는지 확인하여  디비에 존재한다면 바로 로그인을 존재하지 않는다면 회원가입으로 이동하도록 설계했다.

 

소셜로그인 기능의 경우 사용은 많이해봤지만 구현된코드나 UMC교육기간동안 접해보지 못하여 처음에는 어려움을 많이 겪었다. 물론 관련된 코드들은 구글링을 통해서도 많이 공부할 수 있었고 해당 소셜로그인 관련 공식홈페이지에도 친절하게 알려준다. 어렵게 느껴졌던 이유는 로그인 프로세스를 이해하지못했다.

카카오 로그인 프로세스의 경우 아래와 같다.

프론트에서 카카오로그인 클릭 후 계정 로그인 -> 카카오 서버로 전송

-> 카카오서버에서 해당 유저확인후 kakao access token 발급 -> Spring에서 해당 access token을 통해 kakao 서버에 유저관련 정보 획득 -> 디비에 저장후 로그인 및 회원가입 데이터로 사용

 

회원가입

회원가입의 경우 사용자가 입력한 정보를 받아서 디비에 저장하는 방식이다.

nickname, 프로필사진, 성별, 생년월일, 구독하는 ott 서비스, 좋아하는 장르 등의 데이터를 받아 디비에 저장한다.

 

Spring에서 사진을 처리하는것이 어려웠다. MultipartFile 데이터가 들어가는 경우 front에서 Json 형태로 데이터를 받지못한다. 사진파일을 별도로 처리할수가 없어 데이터형식을 form-data 형식으로 바꾸고 각각 데이터들을 따로 받았다.

즉 로그인처럼 하나의 객체형식으로 받지못하고, 각각의 데이터를 송신받았다. 이후 Spring에서 처리하기 쉽도록 하나의 객체에 데이터들을 삽입하여 회원가입을 진행하도록 했다.

 

컨파머 어플리케이션의 경우 휴대폰번호, 본인인증, 본명, 패스워드 등을 요청하지 않기 때문에 디비에서도 해당 유저가 누구인지 전혀 식별할수 없다. 100% 익명성을 보장한다. 

 

나의 정보보기

여기서부터 jwt가 쓰인다. jwt는 spring 서버에서 발급해주는 토큰이다. 해당 토큰을 통해서 로그인한 유저를 식별하고, 본인의 정보를 조회할 수 있게 해준다. 타인의 정보를 조회할수 있는 상황을 방지하기 위하여 jwt 토큰을 사용한다.

 

 나의 정보수정

정보수정 코드이다. 회원가입과 많이유사하다. 닉네임이나 프로필사진, 구독중인 ott 서비스, 좋아하는 장르 등을 수정할 수 있다. S3 를 사용하여 이미지 파일들을 관리하였는데 해당 url이 노출되는것을 막기위해 검은색으로 칠했다. 저곳에는 s3 url이 들어간다. 회원가입과 다르게 사진파일을 처리하는것에 조금 어려움이 있었다. 프로필 사진을 없앨경우, 변경할경우 등등 을 고려하여 코드를 작성했다.

 

여기까지가 구현한 UserController 코드들이다.

이외에도 유저가 디비에 저장되어있는지 확인하는기능, 회원의 닉네임을 호출하는기능 등등 UserService 200줄, UserProvider 200줄, UserDao 350줄 정도를 작성했으나 모두 리뷰하기에는 너무 길기때문에 UserController까지만 진행하겠다.

 

3월 JPA

1~2월동안 정상적으로 서비스하는 Spring 코드를 완성했다. 이후 어플리케이션 성능 개선을 위해 DB 접근방식을 JDBC에서 JPA로 변경하는 작업을 했다. JPA관련학습은 인프런의 김영한님의 JPA강의를 학습했다.

Entity 설계부터 JPARepository를 이용한 쿼리문 작성 등 한달동안 JPA를 경험할 수 있었다.

 

Entity를 통해 디비테이블을 객체화하여 관리하는방식이 신기하고 재밌었으며, JPARepository또한 간편하게 CRUD 쿼리를 생성해주어 편했다. 해당 쿼리문을 100%신뢰 할 수 없다고생각하여 Extract JPQL Query 옵션을 통해 쿼리문을 확인했다.

Extract JPQL Query옵션을 사용하면 위처럼 쿼리문을 확인할 수 있다. 

JPARepository가 자동으로 쿼리문을 생성해주지만 해당 쿼리문들을 직접 확인하는과정은 꼭 필요하다고 생각한다.

 

최대한 Controller를 수정하지않고 JDBC를 JPA로 교체할려 노력했으나 이후 팀원들의 방향에 따라 Controller의 코드도 달라질 수 있다고 생각한다.

개인적인 일정으로 JPA 교체작업을 완료하지 못하여 아쉬움이 있으나 내가 작성한 Controller의 기능들에 한해서는 모두 JDBC에서 JPA로 교체하는 코드를 작성했기 때문에 어느정도 JPA를 경험할 수 있었다.

후기

초기에 기본적으로 코드작성할때는 편하게 작성했던것으로 기억한다. User를 처리하는 부분은 구글링하면 코드도 많고, UMC 교육과정동안 User관련 데이터 처리를 가볍게나마 접했으며, 해당 프로젝트 이전에 공부했던 김영한의 스프링 기초 강의에서도 User관련 처리에대해 학습했기 때문에 순수 코드를 구현하는 부분에서는 편하게 구현 했다.

 

이후 자체적인 코드 테스트에서부터 어려움이 생겼다. 디비쿼리문들이 오류를 출력하거나 정상적으로 작동되지 않았으며, 기존에 처리해주지 않았던 소셜로그인, 이미지파일처리 등을 구현하면서 어려움이 많아졌다.

 

 회원가입 및 회원정보보기 정보수정 코드들의 모든 디비쿼리들이 정상작동하지않았으나 UserDao의 디비 쿼리문 수정을 통해 해결했으며, 소셜 로그인 기능 구현의 경우 Android를 담당하시는 팀원분들과 함께 진행해야 했기 때문에 계속해서 의견을 주고받으며 오류들을 수정해 나갔다.

 

소셜로그인 기능을 구현후 테스트 및 코드 수정을 안드로이드 파트 분들과 협업을 통해 진행했는데 해당 과정이 가장 힘들었지만 가장 재미있었다. 안드로이드 파트 팀원분들이 작업시간을 배려해주어 편하게 작업할 수 있었다.

 

소셜 로그인기능을 완료한 이후 이미지파일을 처리하는 기능을 회원가입과 정보보기, 정보수정에 각각 넣는것도 어려웠다. 이미지 파일이 없는경우 모든 데이터를 json 형식으로 간단하게 처리가 되어 편하게 진행할 수 있었다.

그러나 MultipartFile 데이터가 포함된 경우 json형태로 전송하지 못하고 form-data형식으로 전송받아야 했으며, 이미지파일 추가로 인해 UserController의 Parameter, 이후 Controller에서 호출하는 모든 UserService 메소드, UserDao의 db쿼리문 등 모두 수정해 주었다.

 

1~2월 동안 JDBC를 통해 서비스를 완료한 프로그램에서 내가 작성한 코드들 모두 합쳐봐야 900 ~ 1000줄정도이다.

코드의 양은 많지않지만 코드를 구현하는데 있어서 고민하는 시간이 정말 많았던것 같다.

 구글링뿐만 아니라 보내는 데이터를 처리하는 방식에대한 고민, 팀원, 지인들에게 자문을 구하는 등 고민하고 코드를 수정하는데 정말 많은 시간이 필요하다는 것을 알게되었다. 

또한 코드를 실제로 테스트해봄으로써 작성한 코드들이 정상작동하는지 확인하고 수정하는것에도 시간이 많이 필요하며, 백엔드 담당을 맡게 되더라도 프론트와 함께 협업하는 상황이 반드시 발생한다는것 또한 알게되었다.

 

모든 기능 구현이후 자체테스트에서 문제가 발생했으며, 자체테스트를 통과하기 위해 코드를 수정했다.

이후 android와 연결하는 과정에서도 모든 기능들에 문제가 발생하여 코드를 수정하는 과정을 거쳤다.

실력이 없었기 때문에 어려움을 느낀것도 당연하다.

또한 어려움을 느꼈기 때문에 시간투자를 많이하여 어느정도 프로젝트 진행시간에 맞출 수 있었다.

 

프로젝트 팀원들에게 정말 많은 도움을 받았다. 본 프로젝트가 개발 프로젝트로서는 첫 프로젝트였으며 개발 실력이 가장 낮았기 때문에 팀원들에게 도움요청을 많이했다. 덕분에 많이 배울 수 있었고, 실력을 기를 수 있었다.

또한 대학교 지인들에게도 자문을 구해 어려움을 해결하기도 했다. 여러 방면으로 도움을 주신 지인, 팀원분들 모두에게 감사하다.

 

오류가 발생했을 때의 스트레스는 오류를 해결했을 때의 성취감에 비할바가 되지않았으며 프로젝트 기간동안 팀원분들과 함께 의논하고 문제들을 해결해 나가는과정이 정말 재미있었다.

전체적인 프로젝트의 후기는 "재미있었다" 이다.

개인적인 일정으로 함께 프로젝트를 진행하지 못함에 많은 아쉬움을 느끼지만 팀원이 아닌 컨파머 이용자로서 팀 컨파머를 항상 응원한다.

 

play스토어 컨파머 링크

https://play.google.com/store/apps/details?id=com.corn.cornfarmer_android

 

프로젝트의 후기를 최대한 생생하게 남기고자 생각나는대로 두서없이 작성했다.

이글을 마지막으로 블로그 관리 또한 개인적인 일정으로 못하게 될 예정이다.

728x90

'ETC > Review' 카테고리의 다른 글

2022  (0) 2022.12.31
2022 4회 정보보안기사 필기 후기  (0) 2022.10.24
2021 회고록  (0) 2021.12.31
728x90

홈화면 추가

웹브라우저 url에 http://localhost:8080을 입력해서 접속하면 위의 HomeController의 home메소드가 실행된다.

Return "home"은 tempaltes의 home.html을 반환한다는 의미이다.

 

 

home.html

members/new 로 가게하는 회원가입 과 /members 로 이동시키는 회원 목록 이 있다.

home.html 출력화면

위 파일 목록을 보면 원래 home의 디폴트는 static/index.html 이였다.

home의 디폴트가 home.html이 되었는데 그 이유는 요청이 들어올 때, 스프링 컨트롤러에서 해당 요청에 해당하는 메소드를 찾고 해당하는것이 없을 경우 static내에서 파일을 찾아 출력해주기 때문이다.

위의 코드에서는 컨트롤러에 @GetMapping("/") 에 해당하는 home 메소드가 존재하기 때문에 해당 메소드를 실행시켜 home.html을 반환하는 것이다.

 

회원가입

/member/new로 Get 요청이 들어오는 경우 실행되는 createForm 메소드이다. members/createMemberForm.html

을 반환한다.

createMemberForm.html

이름을 입력받아 회원가입하고 해당 데이터를 /member/new 경로에 post방식으로 전송한다.

createMemberForm.html 출력

등록을 누를경우 해당 데이터가 /member/new 경로로 post 데이터 전송을 한다.

name을 받기위해 Controller 디렉토리에 추가해준 MemberForm이다.

createMemberForm에서 name을 반환할 경우 해당 값을 받기 위한 클래스이다.

 

create메소드

 

createMemberForm에서 post보낸 데이터를 받는 메소드이다.

post 전송방식에 매핑하기 위해  @PostMapping을 이용하고 createMemberForm에서 받은 정보가 MemberForm form으로 전송되고 해당 정보를 새로 생성한 member객체에 넣어 memberService.join을 통해 메모리에 저장한다.

해당 동작이 끝나면 home 화면으로 redirect 시켜준다.

 

회뭔 목록 조회

memberService.findMembers를 통해 저장된 회원들의 정보를 모두 가져온다.

model 객체에 addAttribute를 통해 가져온 정보를 model객체에 저장하고 해당 정보를 members/memberList에 반환한다.

members/memberList

Thymeleaf를 사용해 모든 회원들의 정보를 출력시킨다.

${member.id}는 member.getId() 메소드의 결과를 반환하고, ${member.name}은 member.getName() 메소드의 결과를 반환하여 출력한다.

 

3명의 회원을 등록하고 members 로 get요청하여 memberList.html을 출력한 결과이다.

728x90

'Programming > Spring' 카테고리의 다른 글

스프링 빈과 의존관계  (0) 2022.01.06
회원 관리 예제  (0) 2021.12.30
웹개발 기초  (0) 2021.12.21
728x90

MemberController에서 MemberService를 통해 회원가입을 하고 MemberService를 통해서 데이터를 조회할 수 있어야 한다.

MemberController와 MemberService는 의존관계이다.

MemberController가 MemberService를 의존한다.

 

스프링이 시작할 때 스프링 컨테이너에 @Controller, @Service, @Repository 등의 어노테이션을 가진 클래스 객체들을 생성하고 스프링 빈으로 등록해서 관리한다.

 

스프링 컨테이너 : 스프링에서 객체를 관리하는 것. 객체의 생명주기를 관리하고 컨테이너에 담겨있는 객체들을 스프링 빈(Bean)이라고 부른다.

 

@Controller, @Service, @Repository 어노테이션이 존재하는 클래스들의 경우 객체를 스프링 빈(Bean)으로 등록해 스프링 컨테이너에서 관리한다.

 

위처럼 MemberService() 객체를 new로 할당해서 사용할 수도 있지만, Spring 컨테이너에 저장된 빈을 불러서 사용하면된다.

new를 통해 객체를 생성해서 할당할 경우, 모든 Controller가 각각의 Service 객체를 사용하게 된다.

-> 자원이 낭비되며 비효율 적이다.

스프링 컨테이너에는 각 객체들이 하나만 빈으로 등록되어 해당 빈을 공유하는 형태로 사용하기 때문에 new를통한 객체 할당을 통해서 사용하는것보다 훨씬 효율적으로 사용이 가능하다.

생성자에 @Autowired 어노테이션을 사용하면 스프링 컨테이너에 빈으로 존재하는 MemberService 객체를 연결해 준다.

-> MemberController가 memberService를 의존하게 된다. (Dependency Injection : 의존성 주입)

 

@Controller 어노테이션이 존재하는 MemberController 클래스는 스프링이 시작할 때 자동으로 스프링 컨테이너에 스프링 빈으로 등록된다.

@Autowired 어노테이션을 통해 스프링 빈을 연결하는 경우 해당 객체또한 스프링 컨테이너의 스프링빈으로 등록되어 있어야한다. 즉 위 코드에서는 memberService가 스프링 빈으로 등록되어 있어야 한다는 것이다.

@Service 어노테이션의 경우 @Controller와 마찬가지로 스프링이 시작할때 컴포넌트 스캔에 의해 스프링 빈으로 등록된다. MemberService에서도 생성자에서 @Autowired를 사용하는데 이때 사용되는 MemberRepository 또한 스프링 빈으로 등록되어 있어야한다.

@Repository 어노테이션도 스프링 시작시 스프링 빈으로 등록시켜준다.

 

코드들은 위 그림과 같이 의존관계가 연결된다.

 

 

컴포넌트 스캔과 자동 의존관계 설정

@Controller, @Service, @Repository와 같이 어노테이션으로 스프링 빈을 등록하는 경우는 컴포넌트 스캔 방식에 해당한다. @Component 어노테이션이 스프링 빈으로 등록하는 어노테이션이지만, @Controller, @Service, @Repository 어노테이션의 내부에 @Component가 존재해 세가지 어노테이션 모두 스프링 빈으로 등록된다.

 

스프링이 시작할 때 @Component 어노테이션들을 스캔해서 스프링 빈으로 등록하는 것을 컴포넌트 스캔이라고 한다.

@Autowired는 스프링빈을 연결하는 역할을 한다.(의존 관계 설정)

 

@Component스캔의 범위는 @SpringBootApplication 어노테이션이 존재하는 클래스의 패키지와 해당 패키지의 하위패키지에서만 작동한다.

@SpringBootApplication 어노테이션 내부에 @ComponentScan 어노테이션이 존재한다.

 

**스프링은 스프링 컨테이너에 스프링 빈을 등록할 때, 기본적으로 싱글 톤 등록을 한다.**

싱글 톤 : 하나만 등록하여 해당 객체를 공유한다.

예를 들어 MemberController의 경우도 하나의 객체만 컨테이너에 스프링 빈으로 등록해서 공유한다. MemberController 객체가 여러개 스프링빈으로 등록되지않는다.

 

자바 코드로 직접 스프링 빈 등록하기

@Service, @Repository, @Autowired 어노테이션을 제거한 후 코드를 작성한다.

SpringConfig 파일을 새로 하나 생성한다.

@Configuration 어노테이션은 설정 파일을 만들기 위한 어노테이션이며, Bean을 등록하기 위한 어노테이션이다.

@Configuration 클래스 내부에 @Bean 어노테이션 작성시 해당 객체를 Bean에 등록한다는 의미를 가진다.

위 코드는 MemberService와 MemoryMemberRepository 객체를 Bean으로 등록하는 코드이다.

 

위코드를 통해 코드로 직접 스프링 빈을 등록한 경우에도 아래처럼 구조가 가능해진다.

스프링이 시작될 때, memberRepository와 memberService를 스프링 컨테이너에 올려 빈으로 등록한다.

MemberService 생성자에 파라미터로 memberRepository를 넣어주는데 이때 들어가는 memberRepository는 빈으로 등록된 memberRepository이다.

 

자바코드로 직접 등록할 때에도 Controller는 컴포넌트 스캔으로 올라가야 하기 때문에 @Controller 어노테이션을 꼭 써줘야한다. 또한 Controller 생성자에서 스프링 빈 객체를 가져올 때도 컴포넌트 스캔 방법인 @Autowired 어노테이션을 작성해주어야한다.

 

Dependency Injection의 3가지 방법

1.생성자 주입(생성자에 @Autowired 어노테이션 사용)

2.필드주입(필드에 @Autowired 어노테이션 사용)

3.Setter 주입(set 메소드가 public으로 사용되며 어디서든 호출이 가능해져 개발중 문제가 생길 수 있다.)

 

가장 좋은 방법은 생성자 주입이다.(생성자에 @Autowired 어노테이션을 통해 빈 객체를 연결하는것)

 

실무에서는 주로 Controller, Service, Repository와 같은 코드들은 컴포넌트 스캔을 사용한다고 한다. 정형화 되지 않거나, 상황에 따라 구현 클래스를 변경해야 하는 경우 설정을 통해 코드로 직접 스프링 빈으로 등록한다고 한다.

 

MemberRepository의 경우 Memory를 사용하는 구현체에서 DB를 사용하는 구현체로 바꿀 예정이기 때문에 컴포넌트 스캔이아닌 코드로 직접 빈에 등록하는 코드를 남겨둔다.

 

@Autowired를 통해 Dependency Injection을 하는 경우 MemberController와 MemberService 와 같이 스프링이 관리하는 객체 즉 스프링 빈 객체들에 한해서만 가능하다. 스프링 빈으로 등록되지 않은 객체들은 @Autowired 사용이 불가능하다.

 

728x90

'Programming > Spring' 카테고리의 다른 글

웹 MVC 개발  (0) 2022.01.08
회원 관리 예제  (0) 2021.12.30
웹개발 기초  (0) 2021.12.21
728x90

지난 1년을 정리해보고자 한다.

 

탈보안

올해 초부터 고민하다가 보안분야 공부를 멈추고 개발공부를 시작하게 됐다.
군대에서도 보안쪽을 준비하기 위해 시스템프로그래밍과 네트워크 프로그래밍, 어셈블리어 등에 대한 공부를 했었고,

업무로도 시스템 프로그래밍 관련된 업무를 했었다. 점점 보안에 대한 흥미는 잃게되고 개발쪽에 재미를 느끼게 된것같다.

막연하게 개발쪽으로 공부를 해야겠다고만 생각하고 뚜렷한 목표를 세우지 못했었다.

목표가 없으면 불안함이 생긴다는 것도 이때 알게됐다.

 

백엔드

목표없이 복학하게 되었고, 학교 수업 및 과제로 JSP,HTML,CSS,Javascript, JAVA, Spring을 접하게 됐다.
Java/Spring에 재미를 느끼게 됐다. (CSS, HTML이 너무 재미없었다.)

Java/Spring 백엔드쪽으로 공부를 계속 할 생각이다.

여름

학교 종강후 기본을 확실하게 다지고자 JAVA를 좀더 깊게 공부하기 위해 자바의 정석으로 공부를 했다.
JAVA에 대한 기본적인 문법들과 객체지향에 대해 깊게 공부할 수 있었다.
복습 및 정리를 위해 블로그를 다시 하게됐다.
주기적인 업로드와 꾸준한 조회수로 블로그 광고도 가능하게 됐다.
생각보다 뿌듯하고 재미도 있다. 앞으로도 꾸준히 공부하고 업로드할 예정이다.

보안회사에서 근무하는 친한 친구로부터 같이 일해보자는 입사제의?를 받았다.
BOB를 끝내고 군입대 이후로 너무 입사하고 싶었던 회사라 하루정도 깊게 고민했다.
그러나 개발쪽으로 진로를 정했기 때문에 거절했다.
아쉬움이 커 더 열심히 공부를 하게된 계기가 됐다.

 

UMC

연합동아리인 University MakeUs Challenge에 가입해서 활동하게 됐다.
해당 동아리에 가입하기 위해 자기소개서와 면접을 준비했다. 
개발쪽 이력이 하나도 없다보니 자소서 작성과 면접준비가 어려웠다.
다행히 합격하게 됐고, 첫 개발관련 대외활동이 UMC가 됐다.

학기중 10주동안 백엔드,RestAPI, DB, Spring에대한 교육과 과제를 통해 실력을 키우고,
1~2월동안 앱개발 프로젝트를 진행하는 활동이다.
교육과 과제는 끝났고, 개발 프로젝트만 남겨놓은상황이다.
첫 개발 프로젝트를 앞두고 있지만 너무 실력이 부족한 상태이다.

Spring에대한 이해와 실력이 부족하다고 생각하여 인프런의 김영한님의 Spring강의를 듣고 블로그에 정리하기 시작했다.
현재 스프링강의를 통해 학습하는것이 정말 재미있다.

시험없는 컴퓨터공부는 재밌는것 같다.

 

 

개발 공부를 늦게 시작하다보니 실력이나 경험 모두 많이 부족한것같다.

열심히 해야겠다.

-----------------------------------------------------------------------------------------------------------------------------------

2022

인프런의 김영한님 Spring강의를 들으면서 진행하는 프로젝트에 계속 적용할 예정이다. 
학습도 중요하지만 실전에 적용하는것 또한 중요하다는것을 보안공부하면서 깨달았기 때문에 개발 공부에서 최대한 이론을 바탕으로한 실무능력향상에 초점을 두고 공부와 프로젝트를 병행할 것이다.

IPP를 준비하려한다. 학교수업은 재밌지만 시험기간때 오는 스트레스가 심해 2022-2학기는 현장실습을 통해 회사업무를 할 수 있도록 준비해볼 생각이다. 현장실습은 최대한 JAVA 또는 Spring에 관련된 업무를 하는쪽으로 하고싶다.

JAVA 코딩테스트 실력도 기를 것이다. 2023년도에 소마, 우테코도 경험해보고 싶기 때문에 코딩테스트와 Spring실력을 많이 기르는 2022년도를 보낼것이다.

728x90

'ETC > Review' 카테고리의 다른 글

2022  (0) 2022.12.31
2022 4회 정보보안기사 필기 후기  (0) 2022.10.24
컨파머 프로젝트 후기  (0) 2022.03.23
728x90

비즈니스 요구사항 정리 및 설계

데이터 : 회원ID, 이름

기능 : 회원 등록, 조회

 

백엔드 계층 구조

컨트롤러 : MVC 컨트롤러 역할

서비스 : 도메인 객체를 이용한 핵심 비즈니스 로직이 구현됨

도메인 : 회원, 주문, 쿠폰 등과 같이 데이터베이스에 저장되고 관리되는 비즈니스 도메인 객체

리포지토리 : 데이터베이스에 접근하여 도메인 객체를 DB에 저장하고 관리하는곳

 

아래 프로그램에서는 DB없이 메모리를 저장공간으로 사용한다.

 

도메인

데이터인 회원 ID와 name이 들어간 Member객체이다.

회원 도메인과 리포지토리 만들기

MemberRepository interface이다.

리포지토리는 도메인 객체를 DB에 저장하고 관리하는곳이기 때문에 domain.Member를 import한다.

이후 Member들을 DB에 저장하거나 관리하는 메소드들을 선언한다.

DB에 따라 해당 인터페이스를 상속받아 구현한다.

 

Memory를 DB로 구현한 MemoryMemberRepository

MemberRepository를 상속받아 MemoryMemberRepository를 구현한다.

해당 인터페이스의 save, findById, findByName, findAll 메소드들을 해당 클래스에서 구현한다.

1씩 sequence를 더하면서 id값을 부여, store(Map)라는 임시저장소(Memory DB)에 member 저장

 

findById : id값과 일치하는 id를 store에서 탐색

Null이 반환될 수 있기 때문에 Optional.ofNullable로 탐색

 

 

findByName :  name값을 기반으로 store에 저장된 값 탐색

stream()의 경우 for문으로 모든원소에 접근하듯이 모든 원소들에대해 접근한다고 생각하면 된다.

filter를 통해 name과 일치하는 멤버들을 걸러내고, findAny()를 통해 걸러진 값을 반환한다.

즉 store에 저장된 값중 이름이 name과 일치하는 경우를 반환한다.

 

모든 값들을 Member List로 반환한다.

 

회원 리포지토리 Test코드 작성

개발한 기능들을 main메서드를 실행시켜 테스트하는 경우 시간이 오래걸리고, 한번에 모두 테스트하기 어렵다는 단점이 있기 때문에 테스트코드를 생성하여 메소드들을 테스트하는것이 좋다.

test내에 리포지토리 패키지를 생성하여 test클래스를 작성해준다.

@Test 어노테이션을 사용하여 해당 메소드가 테스트 메소드임을 명시해준다.

위처럼 해당 테스트 메소드를 구현한뒤 해당 메소드만 실행시켜 테스트가 가능하다.

save를 실행시킬경우 해당 테스트코드 내에서 오류가 발생하거나 실패를 하게되면 해당 실행에서 경고를 반환한다.

테스트코드가 성공할경우 아래처럼 정상 종료가 된다.

테스트코드는 항상 해당 코드를 실행시키고 검증까지 완료해야한다. save 메소드의 경우 Member 데이터 생성과 save함수 실행, 이후 findById를 통해 해당 id를 검색하고 assertThat(member).isEqualTo(result)를 통해 검증을 완료했다.

 

findByName 테스트 코드

findByName을 검증하기 위해 데이터를 만들고 findByName을 통해 result를 반환받고 assertThat(result).isEqualTo(member1)을 통해 검증했다.

 

findAll() 테스트 코드

2개의 member를 생성 및 save하고 findAll()을 실행한다.

이후 findAll()의 반환의 결과가 2개 인지 확인하여 검증한다.

 

테스트코드의 경우 모든 메소드들을 한꺼번에 실행하여 테스트하는것도 가능하다.

여러 메소드를 한꺼번에 실행할 경우 각 메소드들이 순서와 상관없이 실행된다.

각 메소드들이 실행되면서 같은 데이터를 save하는 경우 에러가 발생한다.(중복 저장 예외)

이러한 문제를 해결하기 위해 아래의 코드를 추가해준다. 

@AfterEach는 해당 클래스내의 각 메소드들이 실행을 끝낼때 마다 실행되게하는 어노테이션이다.

 

MemoryMemberRepository의 clearStore메소드

위 메소드를 통해 각 메소드들이 끝날 때마다 저장소를 비워준다.

-> 중복 저장 예외를 방지할 수 있다.

 

위의 개발과정은 MemoryMemberRepository를 모두 구현하고, 테스트 코드를 통해 해당 클래스의 메소드들을 검증 했다. 해당 개발 과정을 뒤집어 테스트 코드를 먼저 작성하고 검증이 완료된 후 메소드를 구현할 경우 테스트 주도개발(TDD)이라고 한다.

 

MemberService 메소드 작성

Join() 메소드

join 내부에서 member중복을 검사하는 코드를 작성한 뒤 외부의 새로운 메소드로 생성했다.

ifPresent를 통해 findByName의 반환값이 존재한다면 throw new IllegalStateExceptioon("이미 존재하는 회원입니다.")를 실행시킨다.

ifPresent는 값이 존재할 경우 내부 로직을 실행시키는 기능을 제공한다.

 

위와 같이 MemberService 코드를 구현했다.

회원가입, 전체 회원조회, 회원ID를 통한 회원 조회 등 비즈니스적인 메소드들이 구현된다.

 

MemberService 테스트 코드 구현

위처럼 테스트코드의 메소드명을 한글로 지정해도 상관없다.

 

테스트 코드를 구현할 때 given-when-then 구성으로 코드를 작성하는것이 좋다.

given : 주어지는 것

when : 실행했을 때

then : 결과

 

어떤 것이 주어진 상황에서 코드를 실행했을 때 결과가 이렇게 나와야 한다는 과정을 정리하여 작성하는 방법이다.

given-when-then 의 회원가입 테스트코드

멤버가 given으로 주어지고 join메소드를 실행했을 때 검증을 위해 findOne을 통해 나오는 결과가 무엇인지 확인하는 과정이다.

 

중복 회원가입 예외 테스트코드

assertThrows는 두번째 인자로 주어진 로직 실행시 첫번째 인자에 해당하는 예외가 발생하는지 검사하는 함수입니다.

첫번째 인자가 IllegalStateException이 아닌 NullPointerException이라면 assertThrows에서 에러를 반환한다.

해당 로직에서 정상적으로 IllegalStateException 을 발생시키면 해당 예외를 예외객체 e에 저장하고,

assertThat을 통해 해당 예외 메세지를 "이미 존재하는 회원입니다." 와 비교하여 검증을 완료한다.

 

Service테스트 코드에서도 테스트별로 멤버들을 생성하고 저장하기 때문에 아래 코드를 넣어준다.

 

MemberService의 생성자 코드

MemberService의 생성자 인자로 memberRepository가 주어지며 각 MemberService마다 memberRepository를 별도로 갖게 된다.

 

테스트코드에서의 MemberService

@BeforEach를 통해 모든 메소드들이 실행되기전 해당 코드가 실행되도록 했다.

테스트코드 메소드들이 실행될 때 마다 MemoryMemberRepository()를 생성하고 서비스를 따로 생성해주며 서비스 객체 생성때마다 memberRepository를 생성해준다.

즉 각 테스트 메소드들이 각각의 memberService와 memberRepository를 갖게된다.

728x90

'Programming > Spring' 카테고리의 다른 글

웹 MVC 개발  (0) 2022.01.08
스프링 빈과 의존관계  (0) 2022.01.06
웹개발 기초  (0) 2021.12.21
728x90

인프런의 김영한님 Spring 강의 복습 및 정리

 

웹개발의 3가지 방법

1.정적 컨텐츠 : 서버의 동작 없이 요청한 HTML 파일을 그대로 내려주는것

2.MVC와 템플릿 엔진 : 서버에서 일부 동작을 통해 HTML을 가공하여 파일을 내려주는것 (JSP, PHP)

3.API : HTML로 파일을 내리는 것이아니라 JSON 형태의 데이터를 반환하는 방법

 

정적컨텐츠

스프링에서도 정적컨텐츠(Static Content) 기능을 제공한다.

 

서버 실행후 해당 파일 url 연결

해당 html 파일의 내용이 그대로 출력된다.

정적컨텐츠의 경우 요청한 html파일을 가공없이 그대로 출력해준다. 또한 동적 프로그래밍이 불가능하다.

 

MVC와 템플릿 엔진

MVC : Model, View, Controller

MVC 모델이 도입되기 이전에는 View에서 데이터가공까지 모두 처리하였다. ex) JSP, PHP

View는 화면과 관련된 일, 비즈니스 로직이나 서버 뒷단에 관련된 동작들은 Controller나 Back-end 비즈니스 로직에서 , View와 Controller, Back-end 에서 주고받는 데이터를 Model이라고 하는 데이터에 담아서 주고받는 구조로 동작한다.

 

Hello-mvc로 Parameter name을 가지고 GET 요청을 통해 서버에 요청하면 model객체에 addAttribute를 통해 파라미터로 받은 name값을 담아서 hello-template으로 전송한다. return의 목적지로 model 객체가 전송된다.

 

데이터를 전송할 때 사용하는 Model 객체의 경우 메소드의 파라미터로 선언만 해주면 Spring에서 만들어준다. Model 객체를 사용하기 위해 따로 메모리를 할당할 필요가 없으며 Spring에서 만들어준것을 사용하기만 하면된다.

addAttribute를 통해 저장된 값은 JSON형태이며 "name"이 key이고 파라미터로 전달받은 name이 value가 된다.

 

spring코드에서 반환되는 데이터가 전달되는 hello-template.html 이다.

Model 객체로 전달된 데이터의 key가 name인 value를 출력한다.

붉은색 선으로 밑줄 쳐져있는 name이 넘겨주는 파라미터 이름이고 푸른색 선이 가리키는 spring은 해당 파라미터의 값이된다.

전달받은 값을 addAttribute("name", name) 으로 Model 객체에 넣어주는데, key가 "name"이 되고 파라미터로 전달받은 값이 name에 들어가게된다. 즉 key : name, value : spring이 된다.

@RequestParam 어노테이션에 require=false를 넣어주는것은 해당 파라미터에 값이 없어도 실행되게 하는것이다.

파라미터 값을 채우지 않을 경우 default text인 hello! empty가 출력된다.

 

API

@ResponseBody 어노테이션을 사용할 경우 return에 의한 반환값이 그대로 HTTP response의 body에 삽입되어 HTML에 출력된다.

return "hello "+name 에 의해 name파라미터로 전송된 pw4ngc0가 삽입되어 출력됨을 알 수 있다.

 

API를 통한 객체 반환

Hello 객체에 name값을 넣어 반환한다.

객체를 반환할 경우 해당 객체의 데이터를 JSON형태로 출력해준다.

프론트에서 해당 객체를 가공하여 사용하는 것 같다.

 

@ResponseBody 어노테이션의 메소드가 객체를 반환할 경우 해당 객체를 JSON형태로 변환하여 HTTP 응답으로 넘겨준다.

728x90

'Programming > Spring' 카테고리의 다른 글

웹 MVC 개발  (0) 2022.01.08
스프링 빈과 의존관계  (0) 2022.01.06
회원 관리 예제  (0) 2021.12.30

+ Recent posts