Dto와 Entity 사용 관련 질문

DTO 없이 Entity만 사용하는 건 기술적으로는 가능합니다.하지만 실무에서는 거의 분리해서 사용합니다.이유는 둘의 역할이 다르기 때문입니다.Entity: DB 테이블과 매핑되는 객체 (저장용)DTO: API 요청/응답을 위한 객체 (전달용)겉보기엔 비슷하지만, 목적 자체가 다릅니다.Entity를 그대로 사용하면 다음과 같은 문제가 생깁니다.API 스펙이 DB 구조에 종속됨→ password 같은 민감 정보가 그대로 노출될 수 있음요구사항 변경에 취약→ API 변경이 곧 DB 구조 변경으로 이어짐성능 문제 (Lazy Loading)→ 연관 객체까지 불필요하게 조회 (N+1 문제)순환 참조 문제→ JSON 변환 시 무한 루프 발생 가능데이터 제어 어려움→ 클라이언트가 의도하지 않은 필드까지 수정 가능DTO를 사용하면필요한 데이터만 선택적으로 전달 가능보안 강화 (민감 정보 숨김)계층 분리로 유지보수성 향상성능 최적화 가능이라는 장점이 있습니다.정리하면Entity는 “DB 중심 객체”,DTO는 “API 중심 객체”입니다.비슷하게 생겼지만 역할이 다르기 때문에,실무에서는 분리하는 것이 사실상 필수에 가깝습니다.다음 글도 참고하세요."DTO 없이 Entity만 쓰면 안 되나요?" 실무 기준으로 답해드립니다.https://hoazzinews.tistory.com/186처음엔 헷갈릴 수 있는 부분이지만, 이런 고민을 하신다는 것 자체가 이미 좋은 방향으로 가고 있다는 의미입니다.앞으로도 궁금한 점 있으면 편하게 질문 주세요!

application.properties 작성 관련 질문

돌돌님 안녕하세요.좋은 질문이에요. 결론부터 말씀드리면, 실제 프로젝트에서는 데이터베이스 비밀번호를 코드에 직접 노출하는 방식은 거의 사용하지 않습니다.강의에서 spring.datasource.password=1234처럼 작성한 이유는 학습 편의성과 빠른 실행 확인을 위한 것이에요. 하지만 실무에서는 보안상 이유로 다른 방식을 사용합니다.비밀번호를 코드에 직접 작성하면 다음과 같은 문제가 있습니다.깃허브와 같은 저장소에 업로드될 경우 비밀번호가 그대로 노출될 수 있습니다.팀원뿐만 아니라 외부인도 접근할 가능성이 있습니다.해킹이나 데이터 유출로 이어질 위험이 있습니다.이러한 이유로 실무에서는 보다 안전한 방법을 사용합니다.가장 기본적이고 널리 사용되는 방법은 환경 변수를 활용하는 방식입니다. 개발 서버나 운영 서버의 시스템(OS) 환경 변수에 비밀번호를 설정하고, 애플리케이션에서는 이를 참조하는 형태로 사용합니다.예를 들면 다음과 같습니다.시스템(OS) 환경 변수DB_PASSWORD=1234application-local.propertiesspring.datasource.password=1234application-dev.propertiesspring.datasource.password=${DB_PASSWORD}application-prod.propertiesspring.datasource.password=${DB_PASSWORD}이렇게 구성하면 코드에는 비밀번호가 포함되지 않고, 서버 환경에 따라 다른 값을 유연하게 사용할 수 있습니다.이 내용을 직접 실습해보면 가장 이해가 잘 되는데, 아직 서버(예: Ubuntu) 환경이 준비되지 않은 것 같아요.그래서 제 블로그 글을 통해 간접적으로라도 실습 흐름을 따라가 보시는 것을 추천드립니다.https://hoazzinews.tistory.com/4https://hoazzinews.tistory.com/5천천히 읽어보시면 전체 흐름을 이해하는 데 도움이 되실 거예요~~~처음에는 이런 설정 하나하나가 낯설고 어렵게 느껴질 수 있어요. 하지만 지금처럼 “왜 이렇게 해야 하지?”라고 고민하고 질문하는 과정 자체가 실력을 빠르게 성장시키는 가장 좋은 방법입니다.지금 배우고 있는 내용들은 당장 눈에 띄는 결과보다, 나중에 프로젝트를 할 때 큰 차이를 만들어주는 중요한 기반이 돼요. 조금씩이라도 이해하면서 쌓아가다 보면, 어느 순간 전체 흐름이 자연스럽게 연결되는 시점이 올 거예요.지금처럼 차근차근 꾸준히 공부해보세요. 충분히 잘 해내실 수 있습니다. 응원합니다~

IDE를 Eclipse로 설지해서 수업을 진행해도 되나요

kjb1045님 안녕하세요~말씀하신 eclipse 환경이 STS4를 말씀하시는거죠? 스프링부트 프로젝트는 STS4로 충분히 진행가능합니다. 수업에서 사용한 인텔리제이 Community Edition(무료버전) 와 달리 STS4에서는 프로젝트 생성을 IDE에서 직접할수 있어 보다 편리할 수 있습니다. 참고로 STS4가 아닌 STS3 또는 순수 Eclipse에서는 스프링부트 진행이 어려울수 있습니다. STS4를 사용하세요~^^ 가족여행으로 답변이 다소 늦은점 양해부탁드립니다.열공하시고, 응원할께요~~^^감사합니다.

일정 삭제 시 예외 발생 질문과 이전 질문에 대한 추가질문드립니다.

시그님 안녕하세요. 메리크리스마스요~~~^^:: 첫 번째 질문 답변 :::::::::::::::::::::::::::::::에러 로그를 보면java.lang.ClassCastException: class com.office.calendar.planner.jpa.PlannerEntity cannot be cast to class java.lang.Integer이걸로 봐서는 "PlannerEntity를 Integer로 캐스팅"하려다 ClassCastException이 발생한 걸로 보입니다.즉, deleteByPlanNo()의 실행 결과가 PlannerEntity인데, 메서드 선언은 int(삭제된 행 수) 로 되어 있어 발생한 듯 합니다.PlannerRepository.java에서 int deleteByPlanNo(int planNo);는 엔티티를 삭제하는데요, 이때 삭제하기 위해서 우선 내부적으로 조회 업무를 먼저 수행합니다.그리고 JPA(Hibernate)버전에 따라서 반환되는 값을 삭제된 행 수(int)로 반환하는 경우가 있는가 하면, 때로는 삭제하기 위해서 조회 된 PlannerEntity를 반환하기도 합니다.우선 확인해 볼 수 있는 것은 build.gradle 파일을 열어서 Spring Boot 버전을 확인해 보세요. 저는 3.4.3입니다.-- build.gradle --------------------------------id 'org.springframework.boot' version '3.4.3'------------------------------------------------이렇게 하면 Hibernate(JPA 구현체) 버전은 자동으로 설정되는데요, 이는 애플리케이션 실행 로그로 확인할 수 있습니다.-- build.gradle ---------------------------------------------------------implementation 'org.springframework.boot:spring-boot-starter-data-jpa'--------------------------------------------------------------------------애플리케이션을 실행 후 로그를 확인하면 다음과 같은 버전 정보가 있을 거에요.-- 애플리케이션 실행 로그 -----------------------------------------[Version] - HHH000412: Hibernate ORM core version 6.6.8.Final----------------------------------------------------------------Spring Boot 버전에 차이가 있다면 저와 동일하게 3.4.3으로 변경 후 다시 plan을 삭제해 보세요.(버전을 변경했다면 "Sync All Gradle Projects" 잊지마시구요.) 다른 방법은 @Modifying와 JPQL을 이용하는 방법인데요, PlannerRepository의 deleteByPlanNo()메서드를 다음과 같이 수정합니다.-- PlannerRepository --------------------------------------------@Modifying@Query("delete from PlannerEntity p where p.planNo = :planNo")int deleteByPlanNo(int planNo);-----------------------------------------------------------------이 코드는 "JPA에게 삭제 방식을 명확하게 지시하는 코드"로 SQL로 해석하면 다음과 같습니다.DELETE FROM planner WHERE plan_no = ?즉, "엔티티를 조회해서 지우지 말고, DB에 바로 delete 쿼리를 날려라!" 정도로 해석할 수 있습니다. :: 두 번째 질문 답변 :::::::::::::::::::::::::::::::아주 좋은 질문이에요.이는 시그님이 "개념을 이해하려고" 제대로 고민하고 있다는 증거입니다.에러가 안 나는 이유는 planner_fetch.js가 실행되는 순간에 planner.js의 함수 또는 변수를 "바로 실행 또는 참조"한 게 아니라, 나중에 실행될 함수 안에서 사용했기 때문입니다.즉 "정의"와 "실행"은 다릅니다.planner_fetch.js에서 사용하는 showDetailPlanView함수의 경우 fetchGetPlan(no)함수내에서 사용하고 있기 때문에 planner_fetch.js가 로딩되는 순간 바로 실행되는 것이 아니라 나중에 fetchGetPlan(no)함수가 호출되는 시점에 실행됩니다.current_year변수도 동일한 이유로 fetchGetCurrentMonthPlans()함수가 호출되는 시점에 참조하게 됩니다.만약 planner_fetch.js 상단에 다음과 같은 코드를 넣게되면-- planner_fetch.js --------------------------------------------console.logshowDetailPlanView: ${showDetailPlanView});console.logcurrent_year: ${current_year});----------------------------------------------------------------이는 에러가 발생합니다.이유는 planner_fetch.js가 로딩되는 순간 showDetailPlanView와 current_year가 바로 실행되기 때문입니다.이제 다시 "정의"와 "실행"에 대해서 "정의가 됐다고 바로 실행되는 것은 아니다."를 생각해 보시면 확실하게 이해될 수 있을 거에요. 크리스마스 시즌에도 코드를 보고 있다는 것 자체가 한 발 앞서 가고 있다는 증거입니다.지금은 에러가 나고, 왜 안 되는지 모르겠고, 같은 내용을 몇 번씩 다시 보는 시간이겠지만 이 시간이 쌓여서 "아, 그때 그거였구나" 하는 순간이 반드시 옵니다.오늘의 한 줄 코드, 오늘 이해한 하나의 개념이 시그님을 전혀 다른 개발자로 만들어 줄 거에요.지금 이 시간 자체가 크리스마스 선물이라고 생각하고 열코딩하세요.^^ 응원합니다.~

일정 등록 및 조회 부분 강의 질문입니다.

시그님 안녕하세요.시그님의 질문을 보니까, 그냥 따라 치는 게 아니라 왜 이렇게 설계했는지를 고민하면서 공부하고 있는 것 같아요. 아주 좋은 질문입니다.:: 1번 질문 답변 :::::::::::로 불러온 JavaScript 파일들은 "하나의 공용 공간(window)"에서 실행되기 때문에 서로의 함수와 변수를 사용할 수 있습니다.위 코드는 브라우저에서 다음과 같이 처리됩니다.1. planner_fetch.js를 읽고 실행2. 그 다음 planner.js를 읽고 실행3. 이 두 파일은 각각 다른 파일이지만, 브라우저에서는 하나의 JavaScript 실행 공간에서 실행결과적으로 파일이 나뉘어 있어도 "같은 공간"에서 실행되기 때문에 서로의 전역 변수, 함수 등을 공유할 수 있습니다.하나 더 중요한 사실이 있는데요, 로딩 순서가 중요합니다.위와 같은 순서라면, planner_fetch.js가 먼저 실행되고 planner.js에서 planner_fetch.js 안의 함수를 사용할 수 있습니다.하지만, 로딩 순서를 변경하면다음과 같은 에러가 발생할 수 있습니다.fetchPlans(); // 에러 (아직 정의되지 않음)즉, 먼저 로드된 파일의 함수만 사용할 수 있습니다.지금까지의 답변을 요약하면"JS 파일은 각각 독립 실행되는 게 아니라, 로 불러온 순간부터 모두 하나의 공용 공간(window)에 합쳐져서 실행된다." 라고 할 수 있습니다.조금 더 추가하면 "파일을 나누는 이유"는 역할을 분리하고 가독성과 효율적인 유지보수를 위함입니다.역할 분리: planner.js → 화면/이벤트, planner_fetch.js → 서버 통신가독성: 한 파일에 다 넣으면 코드가 너무 길어짐유지보수: 수정 범위가 명확하게 됨:: 2번 질문 답변 :::::::::::'/planner/plan/3' 이 아니라 '/planner/plan?no=3' 형식을 사용했을까요?이유는 "설계 방식의 차이" 때문입니다.'/planner/plan?no=3' 방식(쿼리 파라미터)은 "plan을 조회하는데, 번호가 3인 것을 조회하자!"이고'/planner/plan/3' 방식(경로 변수)은 3 이 리소스 자체를 의미하며 "번호가 3인 plan을 조회하자!" 입니다.쿼리 파라미터 방식은 검색, 조회 조건 전달에 많이 사용되고 초보자가 이해하기 쉬우며 서버에서 처리하기도 간단합니다.반면 경로 변수 방식은 REST API에서 더 "정석적인 표현"이고 일반적으로 백엔드 API 설계가 잘 되어 있을 때 사용합니다.강의에서 경로 변수 방식이 아닌 쿼리 파라미터 방식을 사용한 이유는 "Fetch로 서버에 요청하는 흐름을 이해하는 것"에 목적을 두어서 입니다.만약 욕심이 난다면 경로 변수 방식으로 시도해보는 것도 좋은 학습 방법입니다.추가적으로 좀 더 설명을 드릴께요.많은 요청이 DB과 관련이 있기 때문에 DB관점에서 살펴보면 더욱 좋습니다.DB에서는 "조건"으로 데이터를 조회합니다. 예를 들어------------------SELECT *FROM planWHERE no = 3;------------------위와 같은 쿼리에서 "plan"은 테이블을 "no = 3"은 조회 조건(where절)을 나타냅니다. 즉, DB는 항상 "테이블 + 조건" 구조로 데이터를 조회합니다.이것을 쿼리 파라미터 방식에 대응 시키면 다음과 같습니다.-----------------------------------/planner/plan?no=3 /planner/plan → plan 테이블?no=3 → WHERE no = 3-----------------------------------직관적이기도 하고 URL 구조가 DB 조회 구조와 1:1로 매칭되어 "plan 테이블에서 no가 3인 데이터를 조회해라!"라는 의미를 쉽게 알 수 있습니다.다음으로 경로 변수 방식(/planner/plan/3)에 대응 시키면 DB 관점이 아니라 "리소스 관점"이 되어 이미 식별된 하나의 데이터(Primary Key) 처럼 취급됩니다.URL만 보고는 이게 조회 조건인지, 리소스 식별자인지 바로 와닿지 않을 수 있습니다.어느 방식이 "더욱 좋다"라고 이분법적으로 결정하기는 다소 무리가 있지만 실무에서는 /planner/plan/3 이 REST 관점에서 더 깔끔해서 자주 사용되지만,DB 설계와 데이터 조회 사고를 먼저 익히는 단계에서는 쿼리 파라미터 방식이 이해와 확장에 유리하다고 볼 수 있습니다.

JWT 기반 인증

grgwde23님 좋은 질문에 감사합니다!사실 JWT는 React + Spring Boot 같이 프론트엔드와 백엔드가 분리된 구조에서 진정한 강점을 발휘합니다.그래서 저도 현재 React + Spring Boot를 활용한 강의를 구상 중이긴 한데요, 진행 중인 프로젝트가 12월에 마무리되는 일정이라 그 전에는 본격적인 강의 제작이 조금 어려울 것 같아요~ㅜㅜ조금만 기다려주시면, 더 체계적인 구성으로 찾아뵐 수 있도록 하겠습니다!그 전에 궁금해하신 "서버 확장 시 세션 관리 문제 해결" 부분에 대해서 JWT 기반 인증의 전체적인 구조와 같이 설명드릴게요.[JWT 기반 인증의 전체적인 구조]1.로그인 요청: 사용자가 ID/PW를 입력해서 로그인 요청을 보냅니다.2.서버에서 인증 처리: Spring Security가 사용자의 정보를 검증하고, 인증에 성공하면 JWT 토큰을 생성합니다. 이때 보통 Access Token과 Refresh Token 두 개가 함께 발급됩니다.3. 클라이언트가 토큰 저장: 발급받은 토큰(Access Token, Refresh Token)을 클라이언트(React 등)가 저장합니다. - Access Token은 메모리나 localStorage에 저장하고, - Refresh Token은 보안을 위해 httpOnly 쿠키에 저장하는 방식이 일반적입니다.4. API 요청 시 토큰 포함사용자 요청 시 Access Token을 Authorization 헤더에 담아 서버에 요청합니다.서버는 이 토큰을 검증하고, 인증된 사용자로 인식해 요청을 처리합니다.5. Access Token 만료 시클라이언트는 Refresh Token을 이용해 Access Token 재발급 요청을 할 수 있습니다.Refresh Token도 만료되었거나 유효하지 않다면, 재로그인이 필요합니다.[서버 확장과 세션 관리의 문제 및 해결 방안]기존의 세션 기반 인증 방식(HttpSession)에서는 사용자의 로그인 상태를 서버 메모리에 저장합니다.이 방식은 단일 서버에서는 괜찮지만, 서버를 여러 대로 확장(스케일 아웃) 하면 문제가 발생합니다.예를 들어,사용자가 A서버에서 로그인했는데, 다음 요청은 B서버로 가면 세션 정보를 찾을 수 없습니다.이를 해결하려면 세션 정보를 공유 저장소(Redis, DB 등) 에 저장해야 하는데, 이는 설정과 유지보수 측면에서 다소 번거롭고 복잡합니다.이런 문제를 해결하기 위한 방안으로 JWT를 사용하는데요,JWT는 사용자의 인증 정보를 클라이언트가 직접 들고 다니는 구조이기 때문에, 서버가 인증 상태를 기억할 필요가 없습니다.어떤 서버로 요청이 오더라도, JWT 토큰만 유효하다면 인증이 가능하고, 서버 간 세션 공유가 필요 없어집니다.또한, 로드 밸런서 뒤에 여러 서버가 있더라도 인증에 문제가 없기 때문에 서버 확장 시 매우 유연하고 안정적인 인증 시스템 구축 가능하게 됩니다.마지막으로, 아쉽게도 바로 추가 강의를 진행해드리지 못해 죄송하고 양해 부탁드립니다.지금처럼 꾸준히 질문하고 학습해 나가신다면, 실무에서도 충분히 활용 가능한 수준까지 금방 도달하실 거예요!앞으로도 좋은 질문 언제든 환영이고, 끝까지 응원하겠습니다.

인터셉터

jsshin님 안녕하세요.^^좋은 질문입니다! 맞습니다. Spring Security를 적용하게 되면 기존에 세션을 기반으로 로그인 여부를 확인하는 인터셉터는 더 이상 필요하지 않습니다. 왜냐하면 Spring Security는 세션 대신 SecurityContext를 통해 인증 정보를 관리하기 때문입니다.그래서 이후 강의에서 기존 인터셉터 코드는 삭제하게 되는데요. 아마 이 부분이 강의 흐름상 다소 혼동을 드렸을 수도 있겠네요. 이 부분은 다른 수강생분들도 헷갈릴 수 있는 부분이라, 조만간 강의에 보완 설명을 추가해서 좀 더 쉽게 이해하실 수 있도록 정리해 드리겠습니다.좋은 피드백 주셔서 진심으로 감사드립니다!

DTO 관련

jsshin님 안녕하세요.^^아주 좋은 질문입니다. DTO는 계층 간 데이터를 전달하는 객체로서, 원칙적으로는 값을 변형하지 않는 것이 설계적으로 더 깔끔합니다.현재 코드처럼 memberDto의 pw 값을 passwordEncoder.encode()로 인코딩한 후 다시 memberDto에 반영하면, DTO가 단순 데이터 전달 객체라는 역할과 조금 어긋날 수 있다는 지적은 충분히 타당합니다.DTO의 값이 메서드 실행 중에 변경되면, 이후 코드에서 혼란을 줄 수 있고, 코드의 직관성이 떨어질 수 있습니다.그래서 실무에서는 보통 인코딩된 비밀번호를 별도의 변수로 관리하거나, DTO → Entity 변환 과정에서 처리하는 방식을 더 많이 사용합니다. 이렇게 하면 코드의 가독성과 안정성이 올라갑니다.다만, 이번 온라인 강의에서는 스프링 입문자분들께 패스워드 인코딩이 어떤 시점에 이루어지는지 직관적으로 보여드리기 위해 memberDto의 pw를 직접 변경하는 방식을 사용했습니다.즉, 객체가 한 번 수정되고 그 수정된 값이 저장되는 과정을 명확하게 이해하도록 돕기 위한 교육적인 목적이 있었습니다.결론적으로 실무에서는 더 깔끔한 설계로 개선할 수 있고, 강의에서는 학습자의 이해를 돕기 위해 일부 의도적인 것입니다. 그리고 이런 부분을 예리하게 캐치해서 질문하고, 직접 리팩토링까지 시도해 본 점은 정말 훌륭합니다. 무한 박수를 보냅니다. 이런 자세야말로 진짜 개발자로 성장하는 최고의 밑거름이고, 객체지향 설계에 대한 매우 훌륭한 감각을 가지고 있다는 증거입니다.열심히 공부하는 그 자세에 진심으로 감사드리고, 앞으로도 계속 응원하겠습니다.

추가 강의 해주실수 있나요?

culwonder.company님 안녕하세요! 강의를 긍정적으로 봐주셔서 정말 감사합니다.말씀해주신 Swagger와 QueryDSL 모두 실제 프로젝트에서 많이 활용되는 중요한 기술이라 저도 강의 주제로 충분히 고민하고 있는 부분입니다.다만 현재는 단순히 개념만 전달하는 수준이 아니라, 실무 프로젝트와 연계된 실전 중심의 구성을 고민 중인데요,이렇게 접근하다 보면 자연스럽게 강의 범위가 꽤 넓어지고, 학습자분들께 부담이 될 수 있다는 점도 함께 고려하고 있습니다.그래서 아직은 방향만 구상 중이며, 어떤 방식으로 구성해야 가장 효과적일지 신중히 고민하고 있는 단계입니다.앞으로도 학습 흐름을 해치지 않으면서 실무에도 도움이 될 수 있도록 잘 준비해보겠습니다.게다가... 사실 요즘 개인 프로젝트로 밤낮을 코드와 함께 보내고 있어서, 머릿속에서 Swagger랑 QueryDSL이 막 강의 안으로 뛰어들고 싶어 해도제가 “잠깐만… 지금은 말고…” 하고 잠시 말리는 중이기도 합니다. ㅎㅎ그래도 좋은 의견 주신 덕분에 동기부여 확실히 되었고요,조만간 더 좋은 구성으로 찾아뵐 수 있도록 잘 준비해보겠습니다!강의 열심히 들어주셔서 정말 감사드리고,앞으로도 차근차근 실력 쌓아가실 수 있도록 응원하겠습니다! 소중한 의견 정말 감사드리고요, 끝까지 강의 잘 따라오실 수 있도록 끝까지 응원하겠습니다!

데이터베이스 테이블이 중복 생성 되는 오류

changhui님 안녕하세요,지방 출장 일정으로 답변이 다소 늦어진 점 양해 부탁드립니다. 말씀해주신 상황을 보면 USER_MEMBER와 user_member 두 개의 테이블이 생성된 이유는 MySQL의 테이블 이름 대소문자 구분 설정과 관련이 있을 가능성이 높습니다.MySQL에서 테이블 이름의 대소문자 구분 여부는 운영체제(OS)에 따라 다르며, 또한 MySQL 자체 설정 값에도 영향을 받습니다. Windows는 기본적으로 대소문자를 구분하지 않지만, Linux는 기본적으로 대소문자를 구분합니다.또한 MySQL 설정 값 중 lower_case_table_names의 값에 따라 테이블 이름 처리 방식이 결정되는데요, 해당 설정은 아래 쿼리로 확인할 수 있습니다.SHOW VARIABLES LIKE 'lower_case_table_names';결괏값(value)으로'0'이면 대소문자를 구분합니다.(Linux, 일부 Mac)'1'이면 테이블 이름을 소문자로 통일해서 처리합니다.(Windows)'2'이면 저장은 원래 이름으로 하되, 비교는 소문자로 합니다.(일부 Mac) changhui님께서 Windows를 사용하고 계시다면 lower_case_table_names 값이 '1'일 가능성이 높고, Mac을 사용 중이시라면 '0'일 가능성이 높습니다.현재 USER_MEMBER와 user_member 테이블이 동시에 존재하고, 로그인 기능이 특정 테이블에만 연결되어 있다면, 설정이나 Entity 매핑에서 일관성이 필요한 상황으로 보입니다.운영체제와 MySQL 설정을 먼저 확인하신 뒤, 실습 환경에 맞게 테이블 매핑을 정리하시면 정상적으로 동작할 수 있을 거예요. 항상 성실하게 실습에 임해주셔서 감사합니다.앞으로도 차근차근 실력을 쌓아가시길 진심으로 응원합니다!