인프런 워밍업 클럽 4기 BE - 4번째 발자국

✅ 강의 수강학습 요약Test Double -Mock과 Stub, @Mock, @MockBean, @Spy, @SpyBean, @InjectMocks BDDMockitoMockist vs Classicist 테스트 작성 원칙테스트는 하나의 목적만 가지도록외부 요인에 영향을 받지 않는 고정된 Fixture필요한 데이터는 given절에, 간접 데이터는 @BeforeEach 등에서 처리테스트에 필요한 데이터는 가능한 제어 가능한 값으로 구성테스트 수행도 비용이므로 공통 환경을 모아 관리 학습 테스트 를 통해 익숙하지 않은 라이브러리나 기술을 익힐 수 있음! 학습 회고4주간의 과정 동안 흐릿했던 지식들이 조금씩 뚜렷해지고, 그동안 무심코 사용하던 어노테이션이나 리팩토링과 테스트코드에 대해 왜 그런 식으로 쓰는지, 더 나은 방식은 무엇인지를 고민해볼 수 있었다. 처음에는 단순히 돌아가는 코드에 대한 확인 정도로만 생각했던 테스트를 이제는 책임을 분리하고 안정적인 코드를 만들기 위한 구조적 도구라고 인식하게 되었다. 4주동안 끝까지 놓지 않고 따라온 것 자체가 개인적으로는 작지 않은 성취였다. 리팩토링 / 테스트코드를 막연하게 두려워하기보다 하나씩 풀어나갈 수 있겠다는 마음이 생긴 것에 의미를 두고 싶다. 정말 좋은 기회였다고 느낀다! ✅ 미션해결 과정1번 미션에서는 Mockito와 Spring 환경에서 각각 사용되는 테스트 어노테이션들의 차이를 실제 사용 맥락을 중심으로 정리했다.2번 미션에서는 각 객체 생성 및 동작을 어떤 위치에 배치할지 고민하며, 공통된 준비와 사용자와 게시물은 @BeforeEach에, 댓글을 직접적인 테스트 도메인으로 보고 given절에서 명시적으로 생성하는 구조로 정리했다. 미션 회고어노테이션의 차이를 정리하면서 어떤 상황에서 어떤 걸 써야 좋을지 기준을 명확히 할 수 있었다. 테스트 흐름을 구성해보는 미션을 하면서 결국 핵심 도메인이 무엇인지, 어떤 객체가 테스트의 중심 대상인지 판단하고 구조를 잡는 게 중요하다는 걸 배웠다. 앞으로 테스트를 구성할 때도 도메인 흐름과 역할을 기준으로 구분하는 습관을 유지하고 싶다.

인프런 워밍업 클럽 4기 BE - 2주차 발자국

✅ 강의 수강학습 요약의도를 잘 전달하는 주석 작성, 요소 정렬 기준 통일, 관심사 중심의 패키지 분리로 코드의 가독성과 탐색 효율을 높인다.기존 기능을 해치지 않으며 개선하고, 정렬 도구나 스타일 설정을 통해 일관된 품질을 유지한다.Optional: null 처리를 명확히 표현하며, 조건 분기 없이 값의 유무에 따라 함수형 스타일로 처리할 수 있다.일급 컬렉션: 컬렉션을 감싸는 객체로, 컬렉션과 관련된 도메인 로직을 함께 묶어 의미를 부여하고 무결성을 보장할 수 있다. 메서드 내부에서 추상과 구체가 섞이지 않도록, 역할 단위로 메서드를 분리해 동일한 추상화 수준을 유지한다.데이터를 꺼내와서 처리하기보다, 객체가 스스로 처리하게 하여 책임과 응집도를 높인다.하나의 객체가 하나의 이유로만 변경되도록 하고, 관련 로직을 모아 유지보수하기 쉬운 구조를 만든다. 학습 회고단순한 코드 수정이 아닌 의미 있는 구조 개선 작업으로서의 리팩토링을 고민하게 되었다. 이해하기 쉬운 코드라는 것이 뭘 말하는 것인지도 더 잘 이해할 수 있었다. 메서드 분리와 추상화 수준 통일만으로도 코드의 가독성과 유지보수성이 크게 달라진다는 점을 체감했다. 기술적인 개선뿐 아니라 읽는 사람을 고려한 코드 작성을 고민하게 된 한 주였다. ✅ 미션해결 과정강의에서 배운 리팩토링 기준들(조건문 정리, 네이밍 개선, 추상화 수준 통일 등)을 정리한 뒤, 실제 코드에 단계적으로 적용했다. 중복된 로직은 enum이나 헬퍼 메서드로 분리하고, 책임에 따라 메서드를 나누는 데 집중했다.각 단계에서 왜 이 리팩토링이 필요한지를 고민하며 리팩토링의 목적을 의식하려 했다. 미션 회고평소 막연하게 느껴졌던 리팩토링 작업이 구체적인 체크리스트를 갖고 하나씩 적용하자 훨씬 명확하게 느껴졌다. 이해하기 쉬운 코드를 작성하는데 있어 메서드 단위 책임 분리와 네이밍의 중요성을 실감했다. 단순히 줄이거나 정리하는 수준이 아니라 의도를 드러내기 위한 구조화가 중요하다는 점을 알게 되었다.

인프런 워밍업 클럽 4기 BE - 미션 Day 18

인프런 워밍업 클럽 4기 BE 클린코드 & 테스트Practical Testing: 실용적인 테스트 가이드미션 Day 18@Mock주로 Spring과 무관한 순수 Mockito 기반의 단위 테스트에서 가짜 객체 mock을 생성하는 데 사용 @MockBeanSpring 테스트 환경에서 기존 스프링 빈을 Mock 객체로 교체@WebMvcTest, @SpringBootTest 등의 테스트에서 의존성을 대체할 때 사용 @Spy실제 객체를 생성하여 일부 메서드의 동작만 Stub 처리하거나 감시 @SpyBean@Spy와 유사하지만 Spring 컨테이너에 등록된 실제 빈을 래핑함 @InjectMocks@Mock 또는 @Spy로 생성한 객체들을 테스트 대상 클래스에 자동으로 주입함@BeforeEach void setUp() { 1-1 / 2-1 / 3-1: 사용자1 생성에 필요한 내용 준비 1-2 / 2-2 / 3-2: 사용자1 생성 1-3 / 2-3 / 3-5: 게시물 생성에 필요한 내용 준비 (사용자1의 게시물) 1-4 / 2-4 / 3-6: 게시물 생성 (사용자1의 게시물) } @DisplayName("사용자가 댓글을 작성할 수 있다.") @Test void writeComment() { // given 1-5: 댓글 생성에 필요한 내용 준비; // when 1-6: 댓글 생성; // then 검증 } @DisplayName("사용자가 댓글을 수정할 수 있다.") @Test void updateComment() { // given 2-5: 댓글 생성에 필요한 내용 준비 2-6: 댓글 생성; // when 2-7: 댓글 수정; // then 검증 } @DisplayName("자신이 작성한 댓글이 아니면 수정할 수 없다.") @Test void cannotUpdateCommentWhenUserIsNotWriter() { // given 3-3: 사용자2 생성에 필요한 내용 준비 3-4: 사용자2 생성 3-7: 댓글 생성에 필요한 내용 준비 (사용자1의 댓글) 3-8: 댓글 생성 (사용자1의 댓글); // when 3-9: 사용자2가 사용자1의 댓글 수정 시도; // then 검증 }

인프런 워밍업 클럽 4기 BE - 미션 Day 16

인프런 워밍업 클럽 4기 BE 클린코드 & 테스트Practical Testing: 실용적인 테스트 가이드미션 Day 16 ✅ Persistence Layer (Repository)특징데이터베이스와 직접 엑세스하는 부분으로, 실제 데이터 CRUD에 집중하고 비즈니스 가공 로직이 포함되지 않도록 한다.테스트 방법@DataJpaTest를 사용해 JPA 관련 컴포넌트만 로딩해 빠르게 테스트 가능하나 자동 롤백 등 제한SpringBootTest로 전체 빈 로드해 실제 환경과 비슷하게 테스트 yml 파일에서 별도 프로파일을 두고 ddl 설정 등 다르게 테스트 환경 분리 가능given 단계에서 테스트에 필요한 데이터 객체를 설정사이즈 체크하고, 핵심 필드만 뽑아서 contains로 값이 잘 포함돼 있는지 확인 ✅ Business Layer (Service)특징핵심 비즈니스 로직이 담겨 있는 부분으로, Persistence Layer와 상호작용 하며 도메인 요구사항을 처리한다. 로직 흐름 관리가 중요하며 트랜잭션을 보장해야 한다. 테스트 방법Repository 레이어와의 상호작용을 포함한 통합 테스트의 형태로 작성하고 테스트를 진행 빌더 객체를 생성하는 테스트용 메서드를 따로 만들어 given을 간결하게 만들 수 있음비즈니스 상황에서 가능한 예외 케이스들을 다양하게 상정하며 테스트를 작성 ( + 필요 시 동시성 이슈 고려)@AfterEach를 활용해 데이터 클렌징 시 deleteAllInBatch() 사용 권장@Transactional 활용하여 테스트 시 롤백 처리 간편하나 방식에 대한 이해와 함께 사용할 것 (readOnly = true) : JPA에서 스냅샷 저장 및 변경 감지를 생략해 성능 향상에 이점이 있고 CQRS(Command / Read 책임분리) 구조에도 부합하게 활용 가능서비스 클래스에 디폴트로(readOnly = true) 를 적용하고, CUD 메서드에 별도로 @Transactional 사용 추천 ✅ Presentation Layer (Controller)특징가장 상위에서 사용자의 요청을 받고 응답을 반환하는 계층으로, 비즈니스 로직이 전개되기 전 dto를 매핑하고 요청 값의 유효성을 검증하거나 예외를 처리하는 것에 중점을 두도록 한다. 테스트 방법@WebMvcTest를 통해 다른 레이어들을 Mocking 처리하여 컨트롤러를 독립적으로 테스트@MockBean 로 만든 Mock 객체를 컨테이너에 주입해 실제 의존성과 분리된 환경 조성MockMvc를 이용해 엔드포인트 동작 시뮬레이션 및 검증

인프런 워밍업 클럽 4기 BE - 3주차 발자국

✅ 강의 수강학습 요약Layered Architecture컨트롤러, 서비스, 리포지토리 등 계층 간 책임을 명확히 나누는 구조 Hexagonal Architecture애플리케이션의 핵심 도메인을 중심에 두고, 외부 의존성(입출력, DB 등)을 포트와 어댑터로 분리해 유연성과 테스트 용이성을 높인 구조 패러다임 불일치객체지향 프로그래밍과 관계형 데이터베이스의 개념 차이에서 발생하는 불일치로 객체의 참조와 DB의 외래 키 간의 차이를 적절히 매핑해야 한다.Spring Data JPA기본적인 CRUD 쿼리를 인터페이스 정의만으로 제공하며 복잡한 쿼리는 직접 구현하거나 QueryDSL 등을 활용할 수 있다.QueryDSL자바 코드 기반으로 JPQL을 작성할 수 있게 해주는 라이브러리로 타입 안정성과 동적 쿼리 작성에 유리하다. @Transactional(readOnly = true)읽기 전용 트랜잭션 설정으로, 변경 감지를 비활성화해 성능을 최적화할 수 있다.Optimistic Lock / Pessimistic Lock낙관적 락은 충돌이 없을 것이라 가정하고 버전 번호로 변경을 감지하고, 비관적 락은 먼저 락을 걸어 동시 수정을 방지한다.CQRS명령(Command)과 조회(Query)의 책임을 분리하는 아키텍처 패턴으로 복잡한 읽기/쓰기 로직을 분리해 성능과 유지보수성을 높일 수 있다.@RestControllerAdvice / @ExceptionHandler공통 예외 처리를 위한 방법으로 커스텀 예외를 만들어 처리할 수도 있다.Bean Validation@NotBlank, @NotNull 등의 어노테이션을 통해 요청값에 대한 유효성 검사를 명시적으로 정의할 수 있다.Mockito / @MockBean테스트 시 외부 의존성을 가짜 객체로 대체해 원하는 동작을 검증하거나 테스트 범위를 좁히는 데 사용된다. 학습 회고그동안 스프링과 테스트 코드에 관련해 파편적으로만 알고 있던 지식들을 조금 더 체계적으로 정리할 수 있었다. 완전히 처음 접해보는 것이 아닌 개념들이라도 제대로 공부하지 않은 채 그냥 가져다 쓰기만 했던 어노테이션이나 설정의 의미에 대해 생각해보는 계기가 되었다. 시간을 내어 수강하는 것이 쉽지만은 않지만 어떻게든 흐름을 따라가다보면 결국 얻는 것이 있을거라 믿는다. ✅ 미션해결 과정어디부터 시작할지 고민하다가 BoardIndexConverter, CellSnapshot, GameBoard처럼 눈에 띄는 핵심 클래스를 골라 간단한 메서드부터 테스트 코드를 하나씩 작성해보았다. 정상 동작을 확인하는 것부터 시작해 예외 상황까지 케이스를 넓혀가면서 어떤 흐름으로 접근해야 하는지 조금은 감을 잡을 수 있었다. 내부 구현에 너무 의존하지 않고 각 메서드가 맡은 역할과 책임에 맞게 동작하는지를 중심으로 테스트 코드를 작성하려 의식하며 미션을 수행해 보았다. 미션 회고전체 코드에서 어떤 부분을 골라 먼저 작성할 지 생각하는 것부터가 쉽지 않았지만 작은 단위부터 차근차근 확인해 나가면서 테스트 작성 흐름에 약간씩 익숙해질 수 있었던 것 같다. 가독성 있는 테스트 네이밍이나 @DisplayName을 정하는 부분에서 생각보다 많은 고민이 필요해 역시 네이밍이 가장 힘든 부분이라는 걸 다시 한 번 느끼는 시간이었다.

인프런 워밍업 클럽 4기 BE - 1주차 발자국

✅ 강의 수강학습 요약섹션: 추상추상과 구체적절한 추상화란 도메인의 문맥 안에서, 정말 중요한 핵심 개념만 남겨서 표현하는 것이름 짓기메서드 이름으로 메서드의 주제, 구체적인 내용을 명확히 드러내야 한다. 내부를 더 작은 단위의 메서드로 쪼갤 수도 있다.메서드 선언부파라미터와 반환타입을 통해 많은 정보를 전달할 수 있다.추상화 수준 일치하나의 세계에서는 추상화 레벨을 동등하게 맞춘다.매직 넘버/스트링 제거상수 추출로 이름을 지어 가독성과 유지보수성을 높일 수 있다.섹션: 논리, 사고의 흐름뇌 메모리 적게 쓰기읽는 사람이 외워야 할 내용을 줄이고, 코드 구조를 단순하게 만든다.Early return, 중첩 줄이기Early return으로 else 사용을 지양하고, 중첩구조를 줄인다.공백 라인, 부정어 활용흐름 단위마다 공백을 주고, 부정 연산자보다 부정의 의미를 담은 단어, 부정어구를 사용해 메서드명을 구성한다.해피 케이스와 예외 처리예외 상황도 함께 고려하여 처리하거나 발생 가능성을 낮추어야 한다.Stream API, Optional 사용NPE방지, Optional이 필요한 상황에 사용한다.섹션: 객체 지향 패러다임객체의 책임 분리하나의 객체는 하나의 관심사만 갖고, 관심사끼리는 느슨하게 연결 (높은 응집도, 낮은 결합도)객체 설계하기비공개 필드, 비공개 로직을 갖고 공개 메서드 선언부를 통해 외부 세계와 소통한다. getter/setter를 지양하고, 데이터를 꺼내기보다는 객체에 메시지를 보내 역할을 맡긴다. SOLID SRP, OCP, LSP, ISP, DIP 원칙을 적용해 유지보수와 확장에 유리한 구조를 만든다.DI / IoC의존성은 외부에서 주입받고, 객체 생성과 흐름 제어는 프레임워크에 맡긴다.섹션: 객체 지향 적용하기상속과 조합상속보다는 조합을 통해 더 유연한 구조를 만든다.Value Object와 EntityVO는 불변성, 동등성, 유효성 검증을 보장해야 한다. Entity는 식별자를 가지며 식별자가 같으면 같은 객체로 간주, VO는 식별자 없이 내부의 모든 값이 다 같아야 동등한 객체이다.일급 컬렉션컬렉션 하나만 필드로 갖는 객체로, 의미와 로직을 부여하고 반환 시 외부 수정 방지를 위해 복사본을 반환한다.Enum상수의 집합으로, 상태와 관련된 로직을 함께 담아 도메인 개념을 명확히 표현할 수 있다. 값이 자주 바뀐다면 DB로 관리하는 것이 더 적절할 수 있다.OCP를 위한 추상화와 다형성if문 대신 다형성을 활용해 변경 없이 확장 가능한 구조를 만든다.숨겨져 있는 도메인 개념 도출하기코드에 숨어 있는 개념들을 찾아 별도로 추출해 모델링한다. 학습 회고일주일 동안 진도표에 맞춰 모든 강의를 따라가는 것이 생각보다 쉽지 않았다. 특히 코드 리팩토링 실습을 따라가면서, 내가 아직 IDE 활용에 능숙하지 않다는 점을 체감했다. 그럼에도 새로운 기능들을 많이 알게 되었고, 앞으로 더 잘 활용할 수 있을 거라는 생각에 강의를 듣길 정말 잘했다고 느낀다. 스케줄이 밀리기도 했지만, 그럼에도 미션을 수행해 제출할 수 있어 다행이다. 완벽하지는 못해도 꾸준히 따라가려는 태도를 유지하며 이번 기회를 통해 실무에 도움되는 내용을 하나라도 더 배워가고 싶다. 다음 주에는 시간을 조금 더 잘 안배해 예제 코드를 활용한 실습에 더 집중해보고자 한다. 내 페이스로 따라가다 보면 리팩토링과 개발 환경에 대한 감각도 자연스레 익숙해지길 기대한다.✅ 미션해결 과정Day4 미션으로는 로직의 흐름을 한눈에 파악하기 어려운 상태의 validateOrder() 메서드를 강의에서 배운 리팩토링 기준에 따라 개선하였다. 이전까지는 리팩토링을 한다고 하면 도대체 어디서부터 어떻게 시작해야 할지 막막했으나 강의에서 배운 리팩토링 기준을 정리해두고, 그 기준을 하나씩 적용해가며 개선하니 훨씬 수월했다.SOLID 원칙을 자신의 언어로 정리하라는 미션을 수행하면서는 LSP의 예로 ‘조류 클래스를 상속한 펭귄은 나는 기능을 수행하지 못하여 예외가 발생하는 것’과 같이 쉽고 간단한 예시를 함께 찾아보고 떠올리며 지식을 내면화 하는데 집중해 보았다. 각 원칙이 실제 상황에서 어떻게 적용되는지 이해할 수 있었다. 미션 회고이번 미션을 통해 강의에서 배운 리팩토링 기준을 실제 코드에 직접 적용해보며, 막연하게만 느껴졌던 리팩토링이 구체적인 기준을 따라 단계적으로 실행할 수 있는 작업이라는 점을 체감했다. 특히 메서드 네이밍만으로도 코드의 책임과 의도를 훨씬 명확하게 할 수 있다는 점이 인상 깊다.SOLID 원칙 또한 단순히 개념을 암기하는 것이 아닌, 예시와 함께 다시 정리하고 내 언어로 설명할 수 있게 된 점이 큰 수확이었다. 읽기 쉬운 코드로 만드는 것을 훨씬 덜 막막하게 느끼게 된 한 주였다.

인프런 워밍업 클럽 4기 BE - 미션 Day 4

인프런 워밍업 클럽 4기 BE 클린코드 & 테스트Readable Code: 읽기 좋은 코드를 작성하는 사고법미션 Day 41. [섹션 3. 논리, 사고의 흐름] 내용을 중심으로 읽기 좋은 코드로 리팩토링✔ 사용자가 생성한 '주문'이 유효한지를 검증하는 메서드.✔ Order는 주문 객체이고, 필요하다면 Order에 추가적인 메서드를 만들어도 된다. (Order 내부의 구현을 구체적으로 할 필요는 없다.)✔ 필요하다면 메서드를 추출할 수 있다.AS ISpublic boolean validateOrder(Order order) { if (order.getItems().size() == 0) { log.info("주문 항목이 없습니다."); return false; } else { if (order.getTotalPrice() > 0) { if (!order.hasCustomerInfo()) { log.info("사용자 정보가 없습니다."); return false; } else { return true; } } else if (!(order.getTotalPrice() > 0)) { log.info("올바르지 않은 총 가격입니다."); return false; } } return true; } TO BEpublic boolean validateOrder(Order order) { if (hasNoItems(order)) return false; if (hasInvalidTotalPrice(order)) return false; if (hasNoCustomerInfo(order)) return false; return true; } private boolean hasNoItems(Order order) { if (order.getItems().isEmpty()) { log.info("주문 항목이 없습니다."); return true; } return false; } private boolean hasInvalidTotalPrice(Order order) { if (order.getTotalPrice() public class Order { public boolean hasCustomerInfo() { // 로직 } //추가 public boolean hasNoCustomerInfo() { return !hasCustomerInfo(); } }Early return, 메서드 추출해 validateOrder 추상화 레벨 일관화, 공백 사용으로 가독성 향상, ! 피하기2. SOLID 정리S - SRP 단일 책임 원칙 (Single Responsibility Principle)하나의 클래스는 하나의 책임(관심사, 역할)만 가져야 한다.이 객체는 딱 하나의 이유로만 바뀌는가?예) Order 클래스주문 목록 저장, 총 금액 계산, 주문 상태 변경만 존재 -> OK결제, 이메일 전송 로직 포함 -> NOT GOODO- OCP 개방-폐쇄 원칙 (Open-Closed Principle)기능은 확장 가능하게 열어두되(open) - 기존 코드는 수정 없이 닫아둔다(closed)다형성, 추상화 등을 활용, 기존 코드의 수정 없이 새로운 요구사항을 반영할 수 있어야 한다.대표적 위반 패턴) if else~L- LSP 리스코프 치환 원칙 (Liskov Substitution Principle)부모 클래스를 사용하는 곳에 자식 클래스를 넣어도 문제가 없어야 한다.자식 클래스가 부모 클래스의 책임을 준수하고, 부모처럼 행동해야 한다.부모의 기능을 자식이 무시하거나 예외를 던질 시 LSP 위반(기능을 추가하더라도 기존 부모의 기능을 제대로 지켜야 함)I - ISP 인터페이스 분리 원칙 (Interface Segregation Principle)인터페이스는 클라이언트가 필요한 기능만 가지도록 나눠야 한다.여러 기능이 섞인 인터페이스에 의존하면 필요하지 않는 메서드까지 강제로 구현하게 된다.D- DIP 의존성 역전 원칙 (Dependency Inversion Principle)구현체에 직접 의존하지 말고 추상화에 의존해야 한다.저수준 모듈에 에 직접적으로 의존하면 변경 시 고수준 모듈에 영향을 미친다.인터페이스나 추상 클래스를 통해 의존성 연결

인프런 워밍업 클럽 4기 BE - 미션 Day 2 추상과 구체

인프런 워밍업 클럽 4기 BE 클린코드 & 테스트Readable Code: 읽기 좋은 코드를 작성하는 사고법미션 Day 2추상과 구체 예시 구체 LevelTCP/IP 프로토콜에 의해 연결된 네트워크를 이용해 판매자와 데이터를 주고받는다.몸을 가리고 보호하는 천으로 만든 여러 물건들 중 원하는 물품을 고른다.선택한 물품의 값을 치름으로써 나의 소유물로 만든다. 추상 Level인터넷으로 옷을 쇼핑한다.

[인프런 워밍업 클럽 1기 BE] 1주차 발자국

인프런 워밍업 클럽 1기 스터디 첫 주가 마무리 되었다. 학습 요약 및 회고, 미션 진행 과정과 회고, 첫 주를 마무리한 소감 및 앞으로의 각오 순으로 간략하게나마 첫 발자국을 작성한다. 첫 주의 학습 요약 및 회고진도표를 충실히 따랐다면 18강까지 학습이 완료 되어야 했지만 지난 한 주간 사정이 여의찮아 진도가 꽤 뒤쳐졌다. 발자국 작성 시점에서 수강 완료한 9강까지만 작성하겠다. 2주차에는 최대한 시간을 내어 진도율을 따라잡고자 한다. 섹션 0강의 소개와 준비본격적인 시작에 앞서 강의를 위해 준비하는 단계를 가졌다. Java와 인텔리제이, git은 설치되어 있었지만 PostMan이라는 api 테스트 툴을 처음 접해보았는데 다음 섹션에서 언급하겠지만 상당히 유용하고 편리하다. DBMS 역시 오라클만 사용해 보았기 때문에 영상을 따라 MySQL을 설치했다. 영상으로 명료하게 안내해 주셨기 때문에 프로그램 설치와 프로젝트 환경 설정에 어려움이 없었다. '프로젝트를 시작하는 첫 번째 방법' 영상에서는 올려주신 파일을 통해 Gradle 프로젝트를 불러왔는데, 내가 경험했던 첫 프로젝트가 떠올랐다. 국비학원에서 연식 있으신 강사님에게 배우며 프로젝트를 진행했는데, 스프링부트가 아닌 스프링으로 프로젝트를 해 보라는 말씀을 곧이곧대로 듣고 당시 maven으로 팀원과 손수 하나하나 환경 설정을 했다. 각자의 로컬환경에서 프로젝트를 통일하는데도 어려움이 꽤 있었다. 빌드 속도도 빠르고 복잡한 pom.xml로부터 해방시켜 주는 Gradle... 앞으로는 Gradle 쓸 일만 있었으면 싶은 바람이 있지만 두 빌드툴을 다 사용해 보는 경험은 나름대로 유의미할 거라고 생각해 본다. 섹션1생애 최초 API 만들기2-4강에서 서버 요청, 네트워크, HTTP와 API의 기초적인 개념을 학습하였다. 비유를 활용한 강사님의 설명이 굉장히 이해하기 쉽고 재미있었다. 대략 알고 있는 내용도 많았으나 복잡한 용어로 곧장 설명하고자 하면 머리에서 정리되지 않았던 것이 비유적으로, 또 원인 중심적으로 접근하니 훨씬 쉽고 간단명료하게 와닿는다. 특히 [집 주소]는 [ip] , 이를 알기 쉽게 [파란집]으로 대체한 것이 [도메인] 처럼 실생활적 단어에 일대일로 대응하여 용어를 설명하는 방식이 빠른 이해에 효과적이었다.HTTP Method도 이미 배우고 프로젝트로 구현해본 개념이지만 이 강의를 들으며 이제야 내가 무엇을 하고 있었는지가 확실해진 기분이 든다. 한 편으로는 내 머릿속이 이리도 엉망진창이었구나 싶다. 내가 무엇을 하는지 알고 행하는 것과 모르고 행하는 것은 정말 다르다. 아무래도 다 알기 전에 실천하고 행하는 것이 개발 공부의 미덕으로 여겨지고는 하는데, 나 자신은 개인적으로 선이해가 수행되지 않으면 실행하는 과정을 굉장히 힘겨워하는 타입이다. 지난 프로젝트 경험은 일단 하나하나 부딪히는 방식이었기에 여전히 머릿속에서 정리되지 않은 개념이 많다. 이번 강의 스터디가 모르고 행했던 것들을 다시 한 번 이해하는데 많이 도움되고 있고, 앞으로도 그럴 것이 기대된다. 차 주의 학습 목표이번 주 학습 시간이 적었던 것이 아쉽고, 다음 주부터는 진도표에 맞출 수 있도록 이른 시일 내에 진도율을 높이는 것을 목표로 더 적극적으로 수강할 것이다. 미션 과정 및 회고1일차 미션 - @Annotation어노테이션을 사용하고 있었지만 어노테이션의 의미에 대해 따로 디깅해 본 적은 없었기에 확실한 개념 이해에 도움을 주는 미션이었다. 구글링을 통해 여러 블로그를 찾아보고 책도 들춰보고 GPT에도 물어본 결과를 취합하여 질문에 따른 답을 작성했다. 내가 사용해 본 것들 외에도 컴파일 시에 검사를 하게하는 등 많은 기능을 하는 다양한 어노테이션들과, 커스텀 어노테이션을 정의하는 방법에 대해 새롭게 알게 되었다.https://dev-de.tistory.com/76 2일차 미션 - api 만들기2일차 미션으로는 GET, POST API를 만드는 세 가지 문제를 해결하였다. 어떤 방법이 더 나을지 나름대로 고민하였으나 완전히 만족스럽지는 않다. 또한 PostMan의 편의성에 감탄했다. 기초가 부족한 편이기에 아무것도 없었다면 List로 JSON을 받는다는 생각을 못 했을 텐데 문제에 Hint가 있는 것이 도움 되었다. 강사님의 피드백에 따라 date를 String으로 받지 않고 LocalDate를 바로 사용하는 방식으로 수정할 것이다.https://dev-de.tistory.com/77 3일차 미션 - 람다식에 대해람다식에 대해서는 이전에 타인의 코딩테스트 답변을 보고 공부 필요성을 느껴 간단히 알아본 적이 있었기에 그때 작성한 블로그 글을 보고 질문에 답변했다. 그러나 미션과 함께 제시된 [키워드]에 맞추어 디깅하다보니 람다식과 관련하여 여전히 잘 모르고 있던 내용들이 쏟아졌고 훨씬 깊이 있게 공부할 수 있었다.https://dev-de.tistory.com/78 소감 및 각오아직 많이 진행하지 않았지만 벌써 이번 인프런 워밍업 클럽 1기 스터디와 자바와 스프링 부트로 생애 최초 서버 만들기, 누구나 쉽게 개발부터 배포까지! [서버 개발 올인원 패키지]> 강의를 통해 새롭게 알고 배운 것이 많다. 지식적인 면 외에도 처음 인프런 워밍업 클럽 신청 시에 적어서 제출했던 '이번 스터디를 통해 기대하는 바'가 이루어지고 있다. 일상 유지를 어려워하며 취준을 위한 노력이 멈췄던 내게 정말로 다시 발을 내딛는 계기가 되어준다. 끝까지 강의와 미션 수행을 잘 따라가며 이 작은 레이스를 탈 없이 완주하고, 많은 것을 얻어가고 싶다.