[인프런 워밍업 클럽 0기 백엔드] 1주차 발자국 (내용 정리 + 미션 수행 정리)
인프런 워밍업 스터디의 1주차가 마무리되어 가고 있는 한 주입니다.1주차 동안 학습했던 내용들과 미션 수행 관련된 내용까지 한 번에 정리하고자 합니다.추가로 1주차 동안 학습한 내용, 과제 수행은 개인 블로그에 별도로 상세하게 정리해 둔 부분이 있습니다.참고하실 분들은 참고해 주시면 좋을 것 같습니다😁제 블로그 주소 링크 남겨드리겠습니다.😁 (1~7일 차 학습 내용, 과제 수행)https://twojun-space.tistory.com/category/%ED%9A%8C%EA%B3%A0/InFlearn%20Warming-up%200%EA%B8%B0%20BE 1. [0일 차] - 인프런 워밍업 스터디 0기 Orientation1-1. 스터디 진행 방식, 일정, 완주 러너와 우수 러너 기준 정리 등(1) 스터디 진행에 있어 필요한 부분들을 코치님께서 모두 정리해 주셨습니다.(2) 또한 디스코드에 발자국 작성법, 완주, 우수러너의 기준 선정 등 다양한 내용들이 디스코드에 나와 있어서 과제 수행에 별 어려움은 없었습니다. 1-2. 코치님의 추가 강의 : 자바의 역사(1) 코치님께서 Orientation 이후 자바의 역사에 대해 간단하게 정리해 주셨는데, 이 부분에 대해 정리해 보겠습니다. 1-3. Java 7(1) 프로그래밍 언어 자바의 암흑기가 찾아온 버전으로, 다른 언어들보다 오래 되었고, 기능이 한참 부족하다는 의견들이 다수 존재한 상황 (2) 당시 사람들의 생각 : 데이터 타입, 조건문, 반복문, OOP, Generic 정도만 다루면 잘 다루는 거 아니야? 라는 생각들이 당시 대다수 사람들의 생각 1-4. Java 8 (2014년)(1) 자바 8을 기점으로 언어의 대격변이 발생했던 시기 (2) Functional Programming(FP), Lamba Expression, Stream API, Optional operation, 날짜, 시간을 다루는 방법 등 (LocalDateTime) 등 현재 시점에서도 가장 많이 사용되는 자바의 핵심 문법들이 등장하기 시작함 1-5. Java 9 (2017년)(1) 자바 9부터 자바의 버전업 주기가 대부분 6개월로 변경 1-6. Java 11(1) 2024년 현재 기준으로 서비스 기반 IT 기업들의 주력 프로그래밍 언어로 선정된 자바 1-7. Java 21 (2023년)(1) 자바의 현 시점 가장 최근 버전 2. 0주 차 개인 회고(1) 이번 스터디를 통해 지금까지 학습해 왔던 스프링, JPA와 관련된 내용을 적용해 보고 싶었다.(2) 자바 8에 등장하게 된 핵심 문법들은 지금도 많이 사용되고 있고 이 부분에 대해 따로 한 번 정리해야겠다는 생각을 하게 되었다.(3) 우수 러너로 선정되어 개인적인 성장에 한 걸음 더 다가가고 싶다는 생각을 할 수 있었다.(4) 파이팅😊 2. [1일 차] - 스프링 프로젝트 메타 데이터, 서버와 네트워크, HTTP, URL 등 기본 지식 등 학습 내용 정리2-1. 프로젝트 메타데이터(1) 스프링 부트 프로젝트 생성 시 메타데이터인 Group, Artifact, Description, Dependencies 추가 등 프로젝트를 구성함에 있어 설정할 수 있는 메타데이터들, 의존성을 추가하는 방법을 알아봤다. 2-2. 서버와 네트워크(1) 서버와 네트워크의 정의와 특징 HTTP 통신의 핵심이 되는 네트워크 지식, IP, DNS, 등에 대해 빠르게 요약 및 정리할 수 있었다. 2-3. 웹 기반 서비스에서의 통신 규약, HTTP(HyperText Transfer Protocol)(1) HTTP의 정의, 요청과 응답에 각각 사용되는 HTTP Request Message, HTTP Response Body, REST API를 정의할 때 자원과 행위를 명시하는 데, 이때 행위를 명시할 때 사용되는 HTTP Method(GET, POST...등)에 대해 학습했다. 2-4. API(Application Programming Interface)(1) API는 프론트엔드와 백엔드 간의 통신을 위한 규약, 규칙 수단을 의미, 추가적으로 REST API, RESTful API에 대해 개인적으로 따로 정리해 보았다. 2-5.API를 개발하기 위한 다양한 Annotation(1) API 명세의 중요성, @RestControler, @GetMapping, @PostMapping, @RequestParam 등 다양한 어노테이션에 대해 정리할 수 있었다. 2-6. 1주차 학습에 대한 회고(1) 백엔드를 공부하면서 지금까지 다양한 용어를 공부했었지만 무의식적으로 용어를 계속 사용하다보니 정의와 아예 어긋나게 알고 있었던 개념들이 조금 있었다. (2) 이번 학습을 통해 잘못 이해하고 있던 부분을 바로 잡긴 했지만 조금 더 빨리 알았으면 좋았을 것 같다는 생각을 해보며 과거에 공부했던 부분을 다시 정리해 보고 잘못 알고 있는 부분은 바로 잡을 필요가 있다고 생각했다. 3. [1일 차] - 과제 수행 : 자바의 어노테이션(1) 인프런 블로그에 별도로 정리한 내용 : https://www.inflearn.com/blogs/6610 3-1. 자바의 어노테이션이란?, 어노테이션을 활용하면서 생기는 장점(1) 코드 가독성 향상, 반복되는 어노테이션의 공통화(2) 커스텀 어노테이션 생성 가능(3) 컴파일 시점에서의 오류 체크 가능 등어노테이션을 활용하면 다양한 장점이 존재한다. 3-2. 어노테이션의 종류(1) 표준 어노테이션(빌트 인 어노테이션), 메타 어노테이션(2) 표준 어노테이션 : @Override, @FunctionalInterface, @Deprecated 등...(3) 메타 어노테이션 : @Target, @Retention, @Inherited, @Repeatable 3-3. 커스텀 어노테이션 정의 방법public @interface SimpleAnnotation { }(1) 별도의 커스텀 어노테이션 생성 가능 @Retention(RetentionPolicy.RUNTIME) @Inherited @Target(ElementType.TYPE) @RestController @RequestMapping("/new") public @interface CustomMyAnnotation { String name() default "MemberController"; String value(); }@CustomMyAnnotation(name = "MemberController", value = "MemberController") @RequiredArgsConstructor public class MemberController { private final MemberService memberService; @GetMapping("/list") public List<MemberListResponseDto> getAllMemberList() { List<Member> allMemberList = memberService.findAllMembersList(); return allMemberList.stream() .map(member -> new MemberListResponseDto(member)) .collect(Collectors.toList()); } } 3-4. 과제 접근 방법, 회고(1) 접근 방법코드 공통화 등 여러 이점을 챙기기 위해 커스텀 어노테이션을 사용해야 하는데, 이 부분에 대해서는 메타 어노테이션에 대한 이해가 필요하다고 생각하여 우선 커스텀 어노테이션을 정의하기 위한 메타 어노테이션을 별도로 공부했다. 이후 위의 코드에서 공통으로 묶을 수 있는 어노테이션을 확인하고 이 부분에 대해 별도로 메타 어노테이션까지 적용해 봄으로써 커스텀 어노테이션을 생성해 볼 수 있었다. (2) 과제 회고개발을 해 보면서 별도로 커스텀 어노테이션을 사용해 본 적이 없어서 이 부분이 조금 낯설게 느껴졌지만 계속 반복해서 학습하다 보니 커스텀 어노테이션의 필요성, 언제 사용되는지 등에 대해 조금 인사이트가 생긴 것 같다. 4. [2일 차] - JSON, HTTP API 코드 작성, 배운 내용을 기반으로 도메인(회원) Entity 개발, 데이터베이스에 대한 기본 개념 4-1. POST 방식에서 데이터를 주고받는 방법, JSON의 구조(1) POST 방식에서 요청 데이터를 서로 주고받는 데 사용되는 데이터 형식 : JSON(2) 자바스크립트 객체 문법으로 구조화된 데이터들을 담을 수 있는 구조 : JSON(3) Key=value의 타입 구성 4-2. HTTP API 코드 작성, @RequestBody(1) 실제 코드를 작성해 보고 Postman을 이용해 API 응답 결과가 반환되는 것을 확인(2) @RequestBody : POST, PUT 방식에서 요청 바디에 적재한 데이터를 자바의 컨트롤러 메서드의 파라미터 객체와 매핑하는 어노테이션 4-3. 회원 도메인 개발(1) @RestController 어노테이션의 경우 응답 결과의 형식이 JSON으로 반환되도록 설계되어 있다. 4-4. Section 1 정리(1) 스프링 프로젝트의 구조, 실행 방법(2) 네트워크, IP 주소, 도메인 네임, 포트 번호, HTTP Request/Response 구조, 클라이언트-서버 구조, 기본적인 API 개념들 학습 (3) Spring Boot 기반으로 기본적인 GET, POST API 설계 방법4-5. 지금까지 설계한 API의 문제점(1) 데이터베이스의 부재 - 영속성을 관리하기 위한 수단이 존재하지 않는다.4-6. 데이터베이스의 개념(1) RDBMS(Relational Database Management System)의 개념과 정의, SQL(Structured Query Language)4-7. 2일 차 학습 내용 개인 회고(1) 위의 회원 API를 개발할 때 데이터베이스를 전혀 사용하지 않고 메모리에서 동작하도록 자바 컬렉션을 사용해서 데이터를 저장하고 조회했는데 평소 데이터베이스에서 CRUD를 하다 보니 자바 컬렉션에서 처리하는 코드들이 조금 낯설게 느껴진 것 같다.5. [2일 차] - 과제 수행 : GET, POST API 설계소스 코드 : https://github.com/twojun/InFlearn_WarmingUp_Club_BE_0 5-1. 문제 1번(1) 두 수를 입력하면 다음과 같은 결과가 반환되는 GET API를 설계한다.(2) URL Path : /api/v1/calc(3) Query parameter : num1, num25-2. 접근 및 해결 방법(1) 쿼리 파라미터가 사용되므로 @RequestParam을 통해 매핑시킬 수 있도록 한다.(2) DTO를 제외한 순수 엔티티 계층에는 @Setter를 열지 않는다.(3) 응답을 위한 별도의 DTO를 만들어서 클라이언트 측으로 반환한다.5-3. 문제 2번(1) 날짜를 입력하면 무슨 요일인지 알려주는 GET 조회 API를 설계한다.(2) URL Path, Query parameter의 경우 임의로 설계해도 상관없다.(3) 본인은 문제에서 기재된 URL과 쿼리 파라미터를 동일하게 설계했다.5-4. 접근 및 해결 방법(1) 날짜를 원하는 형식으로 포맷팅하기 위해, getDayOfWeek(), getDisplayName(TextStyle.SHORT, Locale.ENGLISH등의 날짜와 관련된 메서드를 별도로 찾아보고 문제에 적용시켰다.5-5. 문제 3번(1) 요청 메시지 바디에 리스트 형태로 여러 수를 입력하고 해당 수들의 모든 합을 계산하는 POST 조회 API를 설계한다.(2) API에서 받게 되는 요청 바디의 예시는 아래와 같다.5-6. 접근 및 해결 방법(1) 클라이언트에서 리스트 형태로 바디를 전송하기 때문에 이를 받아서 객체로 파싱하기 위해 위와 같이 List 컬렉션을 내부에 선언해 주었다.(2) 해당 과정에서 자바의 기본 생성자가 필요하다.(2) 반환 결과에서 기본 생성자가 추가적으로 필요한데 이유는 다음과 같다.위의 예외는 스프링의 Jackson 라이브러리의InvalidDefinitionException 예외이며, jackson 라이브러리가 JSON 내부에 객체 형태로 넘어온 값을 실제 객체로 변환하기 위해 역직렬화 과정을 거치는데, 이 과정에서 기본 생성자가 없어서 역직렬화가 실패했기 때문에 위와 같은 예외가 발생하는 것. 따라서 관련 클래스에 기본 생성자를 추가해 줘야 한다.5-7. 과제 수행 회고 (1) 과제를 수행하면서 날짜 정보를 나타낼 수 있는 LocalDate, 날짜와 시간 정보를 모두 나타내는 LocalDateTime에 대해 한 번씩 정리해 볼 수 있었다. 날짜 + 시간 정보가 함께 필요한 환경에서 LocalDateTime은 거의 필수로 사용되는 것 같다. (2) 또한 API 반환 관련 부분을 많이 찾아보면서 Jackson 라이브러리의 역직렬화에 대해 조금 더 자세히 찾아볼 수 있었는데, JSON ↔ 객체 사이의 데이터를 변환해야 하는 일이 있을 때 주체 클래스에서 기본 생성자가 변환 과정에서 반드시 필요하다는 것을 인지했고 이런 부분을 설계할 때는 기본 생성자를 조금 더 신경쓰도록 주의해야 할 것 같다.6. [3일 차] - 데이터베이스 기본적인 DDL, DML, MySQL 데이터 타입, 데이터베이스 도입에 따른 도메인 코드 수정6-1. 데이터베이스 DDL(Database Definition Language) (1) 기본적인 데이터베이스 및 테이블 생성, 및 목록 확인 6-2. MySQL의 대표적 데이터 타입(1) 숫자형 타입(정수형, 실수형 타입)(2) 문자열 타입(3) 날짜, 시간 타입 6-3. 데이터베이스 CRUD(DML : Database Manipulation Language)(1) INSERT INTO~ VALUES(2) SELECT ~ FROM ~ WHERE(3) BETWEEN ~ AND ~(4) IN, NOT IN,(5) UPDATE ~ SET ~ WHERE (조건절 명시 유의)(6) DELETE FROM ~ WHERE ~ (조건절 명시 유의) 6-4. 회원 도메인 Controller 코드 수정(1) 코드 : https://github.com/twojun/InFlearn_WarmingUp_Club_BE_0 (2) jdbcTemplate.update() : 쿼리를 통해 데이터베이스에 대한 갱신(update, delete insert) 발생 시 사용 가능한 메서드로 파라미터로 넘어온 값들을 실제 SQL의 ?(와일드 카드) 부분과 매핑시키는 역할을 수행한다. (3) jdbcTemplate.query(sql, new RowMapper<UserListDto>()RowMapper의 경우 쿼리의 결과를 받아서 원하는 결과 객체를 반환하는 역할을 수행한다.이후 결과 반환을 위해 UserListDto가 필요하므로 생성자에 원하는 결과값을 파라미터로 넣어서 해당 객체를 생성 후 반환한다.(4) 또한 람다식을 이용해 코드를 좀 더 간결하게 작성할 수 있었다. 6-5. 3일 차 학습 내용 개인 회고(1) 스프링에서 Repository를 다룰 때 거의 하이버네이트와 같은 ORM 기반 기술만 쓰다 보니 직접적으로 JdbcTemplate을 통해 데이터베이스에 접근하는 것은 코드가 손에 익숙하지 않았던 것 같다. 이 부분이 조금 아쉬웠다. (2) 람다와 스트림에 대한 추가 정리가 필요하다고 생각했다. 7. [3일 차] - 함수형 프로그래밍, 람다식, Stream API, Method Reference (1) 과제 수행 GitHub : https://github.com/twojun/java8_core_study 7-1. 익명 클래스의 정의, 특징 정리(1) 익명 클래스의 의미, 익명 클래스가 갖는 주요 특징과 함께 코드를 작성하면서 익명 클래스를 실제로 사용하는 이유(함수형 인터페이스와 람다식과 연계) 7-2. 함수형 프로그래밍(Functional Programming) & 람다 표현식(Lambda expression) 정리(1) 함수형 프로그래밍의 뜻, FP가 자바에서 가지게 되는 의미(2) 람다 표현식 정의와 특징, 일급 객체(3) 함수형 인터페이스의 뜻과 사용될 수 있는 데이터 타입(4) 람다 표현식 작성 방법과 람다식을 더 줄일 수 있는 메서드 참조(Method Reference)(5) Method Reference : 실행하려는 람다식의 메서드를 참조해서 파라미터의 정보, 반환 타입을 추론한 뒤 람다식에서 선언이 불필요한 부분을 제거 7-3. 자바에서 기본적으로 제공하는 함수형 인터페이스Predicate<T> , Consumer<T>, Function<T, R>, Supplier<T> 7-4. Stream API(1) 스트림의 정의와 주로 사용되는 곳(2) 스트림 파이프라인 : 중간 연산과 최종 연산 정리(3) 중간 연산과 최종 연산의 주요 메서드들, 주의사항 7-5. 과제 수행 회고(1) 하이버네이트와 같은 ORM 기술을 사용하면서 람다와 스트림이 자주 사용되고, 코드의 가독성을 올려주는 데 효과적이라고 생각했었으며 이번 계기로 이 부분을 다시 한 번 정리해 볼 수 있었다. (2) 람다식, 스트림의 코드 스타일을 외우기 보다는 많이 사용해보면서 체화시키는 부분이 중요하다고 생각했다. 8. [4일 차] - 회원 도메인 수정, 삭제 API (1) 4일차 관련 내용은 도메인에 대한 코드 수정 위주이다.(2) 관련 내용 수행 코드 : https://github.com/twojun/InFlearn_WarmingUp_Club_BE_0 8-1. 회원 수정, 삭제 API를 직접 작성해 보면서 생각해 보아야 할 것?(1) 현재 회원 도메인만 봐도 컨트롤러 레벨에서 문제점이 하나 있다.(2) 하나의 컨트롤러가 너무 많은 책임과 역할을 갖고 있다.조회, 예외 처리(비즈니스 로직), 데이터베이스 통신 등 많은 역할을 수행하고 있다.지금은 요구사항이 예제 수준으로 작지만 요구사항이 10가지만 되어도 컨트롤러에서 모든 코드를 감당하기 어려울 것이다.따라서 이 부분을 해결해야 한다. 8-2. 학습 내용 개인 회고(1) 좋은 컨트롤러는 들어온 요청에 대해 적절한 처리를 다른 계층에서 수행해 주고 응답만을 돌려받아 다시 클라이언트측으로 반환하는 역할을 수행해야 하는데 좋은 컨트롤러란 무엇인가? 라는 부분에 대해 다시 한 번 생각해 봤다. (2) 너무 많은 기능을 담당하는 코드가 컨트롤러에 존재하면 가독성은 물론 유지보수가 매우 어려워진다. 이 부분을 빠르게 개선해야 할 것 같다고 생각했다. 9. [4일 차] - 과제 수행 : API 개발9-1. 문제 1번(1) 과일 가게에 입고된 과일 정보를 저장하는 API를 설계하자.(2) HTTP Method : POST(3) HTTP Path : /api/v1/fruit 9-2. 문제 접근 및 해결 방법(1) 이후 문제의 요구사항에 맞추기 위해 미리 테이블 컬럼에 판매 여부를 저장하는 is_sale 컬럼을 생성한다.(2) 이후 코드는 과일 정보를 저장하기 위한 SQL 문자열을 별도로 작성하고 jdbcTemplate.udpate() 메서드를 사용해서 실제 과일 상품의 정보를 저장하도록 한다. (3) 이후 정상적으로 테이블에 로우가 적재된 것을 확인 (4) int보다 long 타입을 사용해 보도록 하자.본인이 생각하고 있는 이유가 정확하진 않을 수도 있지만, 수의 표현 범위에서의 차이이지 않을까 싶다. int의 경우 약 21억 정도의 크기를 갖는 수를 저장할 수 있는데 해당 자료형이 담는 수도 매우 커보이지만, 이 부분이 실무를 넘어가면 21억보다 큰 수를 받아야 하는 상황이 종종 생길 수도 있기 때문에 long 타입을 사용하는 것으로 알고 있다 9-3. 문제 2번(1) 과일이 판매되면 판매된 과일 정보를 기록하는 API를 설계하자.(2) HTTP Method : PUT(3) HTTP Path : /api/v1/fruit9-4. 문제 접근 방식 및 해결 방법(1) 입고된 과일의 컬럼 정보 is_sale을 1로 변경해야 입고된 과일로 간주한다.(2) 입고되지 않은 과일의 정보를 바꾸는 것 자체가 모순이기에 이 부분에 대해선 IllegalStateException 예외를 던지도록 한다.(3) 코드를 작성해서 정상 결과 반환을 확인했다.9-5. 문제 3번(1) 특정한 과일을 대상으로 판매된 금액, 판매되지 않은 금액의 총합을 계산해보는 API를 설계하자.(2) HTTP Method : GET(3) HTTP Path : /api/v1/fruit/stat(4) HTTP Query parameter : name 9-6. 문제 접근 방법 및 해결 방법(1) 위에서 정의한 판매 상태를 기준으로 각각의 총합 금액을 계산하는 쿼리를 작성한다.(2) 이후 각각 조회된 결과를 받고 별도의 결과 반환 DTO를 만들어서 해당 값들을 DTO로 반환할 수 있도록 코드를 작성했다.(3) 정상적으로 문제에서 요구된 특정 과일에 대한 판매, 미판매 금액이 조회되는 것을 확인할 수 있었다. 9-7. 과제 수행 개인 회고(1) 저번 과제에 이어서 API를 추가적으로 설계해 보면서 REST API 설계에 대해 익숙해 질 수 있었다.(2) 이번 스터디를 계기로 더 많은 API를 반환하는 것을 연습해 보면 더 좋을 것 같다고 생각했다. 10. [5일 차] - 클린 코드, Controller-Service-Repository로 계층 분리하기(계층형 아키텍처) (1) 관련 내용 수행 코드 : https://github.com/twojun/InFlearn_WarmingUp_Club_BE_0 10-1. 클린 코드(1) 클린 코드가 무엇인지 이를 통해 얻을 수 있는 장점(2) 안 좋은 코드가 쌓여가면 프로덕트의 생산성이 낮아지는 점을 인지할 수 있었다. 10-2. 계층형 아키텍처(1) Controller-Service-Repository 형태와 같이 각 계층이 서로에 맞게 분리되어 있는 설계 구조를 의미(2) 각 계층에서 수행되는 역할 정리 10-3. 회원 도메인에 대해서 계층형 구조로 개선 (1) 단순 사용자 정보 수정만이 아닌, 생성, 조회, 삭제 등 모든 비즈니스 포인트를 Controller-Service-Repository 계층 구조로 분리하는 작업 진행 10-4. 5일 차 학습 내용 개인 회고(1) 이번 학습을 통해 클린 코드의 중요성, 모든 역할을 하나의 계층에서 정의하는 것이 아닌 각각의 역할에 따라 계층을 나누고 코드를 분리하는 것이 가독성도 좋고 협업하기 좋은 코드라고 생각할 수 있었다. (2) 앞으로도 코드를 작성하면서 더 좋은 계층구조를 갖는 코드가 무엇인지 생각하고 코드를 작성할 필요성을 느끼며 반성할 수 있는 기회였다. 11. [5일 차] - 클린 코드 적용하기11-1. 주사위 게임 코드 리팩토링(1) 과제 수행 코드 : https://github.com/twojun/java8_core_study(2) 기존 주사위 게임 코드를 클린 코드로 변경해보는 과제였다. 11-2. 문제 접근 및 해결 방법 & 개인 회고(1) 아래의 코드가 만약 주사위의 눈의 수가 30 또는 100까지 늘어난다면? 요구사항 수정에 의한 코드 변경 파급력이 급격하게 커지게 된다. 변경에 의한 파급력이 최대한 작아지게, 또한 읽기 좋게 코드를 수정하려면 어떻게 해야 할까? 라는 생각을 가지고 코드를 작성했던 것 같다. 아래의 코드를 개선된 클린 코드로 리팩토링해 봐야겠다고 생각했다. (2) 본인은 Scanner보다는 BufferedReader를 사용하는 것이 더 익숙해서 코드에 BufferedReader를 적용시켰다. (3) 메서드, 클래스 단위로 나누어서 코드를 작성해도 좋지만 사용자로부터 최대 나올 수 있는 주사위 눈의 수, 게임 반복 횟수를 입력받고 관련 주사위 수가 몇 번 나왔는지 출력하면 되는 문제이기 때문에 별도의 클래스나 메서드로 나누지 않고 간단하게 자료구조(배열)을 확인해 문제를 풀었다. (4) 과제가 끝난 후 다른 분들 코드를 보면 메서드, 클래스 단위로 대부분 나누어 코딩하신 것 같아서 나만 너무 이상하게 코딩했나라는 생각을 했지만, 클린 코드의 의미를 되돌아 보면 읽기 쉬운 코드도 특징 중 하나이기에 최대한 간결하고 눈에 들어올 수 있도록 자료구조를 활용해 표현했지만 뭔가 부족한 느낌이 든다. 12. 1주차 총 회고(1) 스터디가 시작된지 1주일이 경과했다. 디스코드에서 보니 다들 열심히 하시는 분들이 많으신 것 같고 항상 열정적이신 코치님, 동료분들이 있어서 스터디하기 좋은 환경인 것 같다. (2) 열심히 참여해서 개인적인 성장에 한 걸음 더 다가서려고 한다.😄
