회의록 (legacy)

[ooMia]

spring-templates

Microsoft Copilot을 통해 작성한 프로젝트 사전 준비 요건에 대한 답변입니다.

프로젝트 목적과 목표

• 프로젝트를 진행하는 이유는 무엇인가요?
• 프로젝트가 비즈니스에 어떤 가치를 더해줄 것인가요?
• 프로젝트의 성공 기준은 무엇인가요?

프로젝트 범위와 일정

• 프로젝트에서 진행할 업무의 범위는 무엇인가요?
• 프로젝트에서 진행하지 않을 업무의 범위는 무엇인가요?
• 프로젝트의 주요 마일스톤과 기한은 무엇인가요?

프로젝트 팀원과 역할

• 프로젝트에 참여할 팀원은 누구인가요?
• 각 팀원의 책임과 권한은 무엇인가요?
• 의사결정 방법은 무엇인가요?

프로젝트 커뮤니케이션과 협업

• 프로젝트에 관련된 정보를 어떻게 공유할 것인가요?
• 피드백을 어떻게 주고받을 것인가요?
• 어떤 커뮤니케이션 채널과 빈도를 사용할 것인가요?
• 어떤 협업 툴을 사용할 것인가요?

[ooMia]

혼자 생각해두고 있었던 건 크게 세 가지입니다.

1. 기존 과정에서는 하나의 프로젝트를 완성하기 위해 풀 스택의 관점에서 신경썼다(Docker, AWS 등). 이제는 백엔드 코드 퀄리티(모듈화/가독성/테스트 등 유지보수)에만 집중해보자.
2. 특히, 테스트를 신경써보자. 유닛 테스트에 대한 책을 읽고 있는데, Anti Pattern을 피하고, Best Practice를 적용하는 것에는 이론적인 학습을 바탕으로 한 실습이 필요할 것 같다.
3. 특히, 대표적인 비즈니스 요구사항을 재현해보자. 이를 템플릿으로 제작해두면 두고두고 재사용 가능.

이외에도 GitHub 내부의 기능들을 잘 활용하여 프로젝트를 관리해보면 좋을 것 같다는 생각을 했어요. 매번 다분화되어 있는 내용들을 통합하여 정리하는게 번거롭다고 생각했거든요. 본래라면 목적에 맞게 채널을 분리할 수 있지만, 유독 GitHub만 사용 경험이 적은 것 같아 이번 기회에 사용해보고자 했습니다.

[ooMia]

유튜브 영상을 토대로 간추린 백엔드 개발자 필요 역량 키워드를 녹여낸 프로젝트 목표를 제안합니다!

계산기

• OOP
• Exception Handling
• Test (Unit, Integration, E2E)

게시판

• JPA 기반 ORM
• Query 성능 최적화
• Pagenation

e-commerce 서비스

• 시스템 설계(MSA)
• JPA 기반 ORM + queryDsl
• Transaction 성능 최적화

이전 프로젝트가 이후 프로젝트의 템플릿으로 확장되어 사용되길 기대하며 단계적으로 기획했어요.

---

추가적으로 고려해볼만한 키워드는 다음과 같습니다.

• ELK 스택(Elasticsearch, Logstash, Kibana)
• Message Queue
• Java Version별 기능 활용
• @Async 어노테이션과 ThreadPool 설정
• SQL Injection 방지
• Caching

[ooMia]

실무와의 연관성을 직접 검증하지 않을 수 있는 방법 중 하나는 시중의 개발자 양성 커리큘럼의 프로젝트 주제를 참고하는 방법이에요! 일례로 백엔드 취업 스쿨 교육 과정 소개서에도 주제들이 있습니다. 이외에 온라인 교육 사이트들을 돌아다니면서 정보를 수집하는 것도 방법이 되겠죠.

개인 노션에 간단히 내용 정리 중에 있습니다.

[haxr369]

노션 글 잘 봤습니다! 5가지 과목 중에서 제가 준비하고 있던 것도 있고 아닌 것도 있지만, 미아님과 함께하면 재밌게 많이 할 수 있을 것 같네요!!!

[ooMia]

방향성 논의 (2024-02-22)

1. 기반 시스템에 활용할 수 있는 모듈을 만들어보고, 웹으로 배포해보고, 실제로 사용해보는 경험
   • 통합 테스트 성능을 실행 시간으로 정의
   • 일차적으로 시간 측정 모듈을 작성해보는 것이 좋다고 판단
2. 이후 우테코 과제를 기반으로 OOP 설계 원칙 준수와 테스트 코드 작성

Details

매일 오후 7시부터 9시까지 진행하되, 반으로 나눠 이론적인 내용과 실습을 병행

• 이론적인 내용을 모두 습득하는 것이 불가능하다고 판단
• 적절한 선에서 실습으로 결과물을 만들고, 유지보수 관점에서 개선하며 최대한 실무 워크 플로우를 모방하고자 함

과제

1. 일요일 오후 7시까지 위 주제에 대해 간단히 정리하기
   • GitHub Discussion 적극 활용

🔔 문화를 만들어나가는 과정이므로, 자유롭게 건의하되, 결정된 사항은 기록해두기

[ooMia]

작성해두고 보니까 매일 작성해야 하는 내용이 있다면 템플릿으로 만드는 것도 좋을 것 같네요
다만, 템플릿을 만드는 것도, 또 그 형식을 지키고자 얽매이는 것도 수고로운 일이라 생각합니다.
반드시 필요한 게 아니라면 기존 포스트를 템플릿으로 취급하여 형식을 재사용하는 방식으로 충분할 것 같아요

[haxr369]

넵! 일요일부터 매일 진행한 내용은 기존 포스트 참고해서 작성해요!

[ooMia]

조사 및 실습 내용 공유 (2024-02-25)

22일에 논의된 과제에 명시된 과제를 기준으로 개별 조사 및 실습 진행

A. 시간 측정 모듈

솔(@haxr369) 시간 측정 모듈 설계에 대한 고민 및 조사 링크

• Spring AOP를 통해 간단히 구현 가능
• 모듈화를 고려하여 디자인 패턴 장단점 정리 및 AspectJ 도입 시도

B. 우테코 과제 - 로또

미아(@ooMia) 책임에 따른 객체 분리

• VO: 불변 값. Lotto, Money
• Class: 상호 작용. LottoVendor

과제

1. 금일 회고록 작성 (느낀 점 / 목표 및 계획)
2. 우테코 Lotto 3월 4일 오후 7시까지 완성
   • 우테코 camp.nextstep.edu.missionutils 유틸 클래스 없이 구현
   • 공통 테스트 코드 결합 (ApplicationTest.java)

참고

• 🔔 자유롭게 건의하며 문화 만들기. 결정 사항은 기록해두자
• 기록 간 GitHub Discussion을 적극적으로 활용해보자
• 발표 형식이라면 자료 예습 과정이 필요하다. 질문 없이 바로 이해하기 쉽지 않음.
• 각자의 내용을 축약해서 회의록에 추가하는 방식으로 정리하자.

[ooMia]

회고록 (목표 및 계획)

느낀 점은 회의록의 참고에 추가함

• Reflection API를 활용한 모듈 구현 시도

  • 특정 함수의 실행 시간 측정을 위한 구조 설계
    • 실행 결과가 반영되지 않아야 함 (stateless)
    • 결과 반환 방식 정의 (sout, file, string)
    • (선택) n회 평균 계산을 위한 멀티스레딩 도입
  • 구현 및 테스트

• 우테코 Lotto 2024-03-04 17:00까지 완성

  • 공동 레포 생성 및 초기화
  • 코드 리뷰 간 언급한 개선 사항 반영

[haxr369]

회고록

1. 시간 측정 모듈을 만들 때 고려할 것 (메서드의 인수와 반환 타입, 간편한 사용)
2. 디자인 패턴의 단순 이해를 넘어 실 사용 사례 실습 필요성
3. 우테코 과제에서 절차지향적을 객체지향적으로 재설계

목표

시간 측정 모듈

• JDK 동적 프록시나 CGLIB 같은 동적 프록시 기술을 이용해서 시간 측정 모듈과 핵심 모듈의 의존성을 낮춤
• 콘솔 로그는 "[클래스 명] [함수 명] 실행 시간" 형식으로 출력

우테코 - 로또

• 관심사 분리에 입각한 클래스 설정 (로또, 벤터, 사용자, 돈, ...)
• 기존 단위 테스트를 클래스 단위로 세분화
• 최소 5개 PR을 보고 각 PR에서 배울 점을 찾아서 적용하기 - 셀프 코드 리뷰

[haxr369]

우테코 코드 작성 및 리뷰 (2024-03-04)

느낀 점은 회의록의 참고에 추가바람

우테코 과제 - 로또

미아 @ooMia

1. MVC 패턴에 따른 5가지 원칙 정리 From Commit Message Convention #2
2. 절차적으로 작성한 코드에 대한 통합 테스트 작성 어려움
3. package-private을 통해 구현부를 숨기고, 인터페이스 역할의 클래스만 제공하여 결합부 최소화

솔 @haxr369

1. 유저의 구입 금액 입력에 따른 Customer 생성 동작 테스트
2. mock을 이용해서 객체를 가정
3. inputManager와 outputManger 같이 class 전체적으로 중복되는 파라미터는 필드에 저장 필요
4. 두 배열의 공통 요소 개수 찾는 로직에서 알아보기 어려운 코드는 보기 쉽게 정리. (시간이 많이 소요되지 않는다면 이미 존재하는 API 사용하기)

다음 목표 (2024-03-06)

• 코드 작성 기준 나열
• 상대방 코드 리뷰
• 회고록 작성

참고

• 🔔 자유로운 발의로 문화 만들기. 결정 사항은 기록하기
• 기록 간 GitHub Discussion 적극적으로 활용하기
• 발표를 계획한다면, 준비된 자료를 사전에 공유하자
• 회의: 다음 팀의 목표를 잡는 거시적인 관점의 논의 진행하기
  • 회의록: 회의 내용 요약
  • 회고록: 각자 느낀 점 및 목표/계획
• 프로젝트 시작은 협업을 위해 필요한 최소한의 합의 이후에 진행하자

[haxr369]

To Do

1. 통합 테스트인지 유닛 테스트인지 모호한 테스트 정리
2. junit vs mockito 차이 명확하게 인지하기
3. mvc, mvp,... 디자인 패턴 차이 조사하기
4. java 고급 자료구조 조사하기

[ooMia]

To-Do

• 우테코 통합 테스트 구현체 톺아보기
• mocking 사용 기준 조사
• @haxr369 코드 리뷰
• 코드 작성 기준 나열

[ooMia]

코드 작성 기준 (2024-03-06)

코드 통합을 위해 모범 사례에 대한 기준을 정리 링크
다음은 채팅에서 공유한 기록을 토대로 LLM을 통해 정리한 내용입니다.

모범 사례 기준

• MVC
  • Model은 Controller와 View에 의존하지 않아야 한다.
  • View는 Model에만 의존해야 하고, Controller에는 의존하면 안 된다.
  • View가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여주어야 하는 데이터에 대해서만 받아야 한다.
  • Controller는 Model과 View에 의존해도 된다.
  • View가 Model로부터 데이터를 받을 때, 반드시 Controller에서 받아야 한다.
• getter와 setter의 사용을 최소화하고, 클래스 간의 연관관계는 인스턴스를 사용하여 표현한다.
• 뷰든 컨트롤러든 액터의 입력을 받든 주체는 상관 없다. MVC는 데이터 흐름을 강제하기 위한 패턴이다. 입력이 이루어지는 시점에 대해, API는 컨트롤러가 받지만, 콘솔 애플리케이션은 표준 입출력을 통해 입력받는다.
• Record는 생성 시 결정하고 사용한다. 변경되지 않도록 primitive type과 immutable 객체를 사용한다.
• 클래스의 속성은 최대한 숨기는 것이 좋다. 메서드는 의미 단위로 생성되어야 한다.
• 요구사항에 존재하는 최소한의 내용만 작성하기 (YAGNI)
  • 사용되지 않는 코드는 삭제 또는 작성 의도와 함께 주석 처리
  • Model의 서비스에 대한 함수형 인터페이스를 작성하자 (단, 외부에서 사용하게 되는 시점에)
• 항상 정렬된 상태를 보장해야 하는 경우에만 정렬 자료 구조 사용

해결해야 할 문제

• 유효성 검사 방식에 대한 논의

  1. 미아: 객체는 수동적이어야 하며, 데이터를 조작할 수 있는 액터에게 예외를 처리하도록 해야한다.
  2. 솔: Validator를 만드는 것이 좋다. 예외 발생 시, stackTrace가 얕아지고, Exception 버블링을 방지한다.

• Enum을 사용할 기준을 명확히 해야 한다.

  1. 미아: Enum은 확장성이 낮으므로, 변경 가능성이 적고, 일차원적으로 매핑되는 상수에 한하여 사용한다. 다수의 레이어에서 공통적으로 사용하면 좋다.
  2. 솔: 관련도가 높고 일정한 규칙이 없는 관계에 대한 정의를 enum 선언

• getter 사용에 대한 기준

참고 (변경사항 없음)

• 🔔 자유로운 발의로 문화 만들기. 결정 사항은 기록하기
• 기록 간 GitHub Discussion 적극적으로 활용하기
• 발표를 계획한다면, 준비된 자료를 사전에 공유하자
• 회의: 다음 팀의 목표를 잡는 거시적인 관점의 논의 진행하기
  • 회의록: 회의 내용 요약
  • 회고록: 각자 느낀 점 및 목표/계획
• 프로젝트 시작은 협업을 위해 필요한 최소한의 합의 이후에 진행하자

[haxr369]

회고록

1. 우테코 문제를 풀면서 역할을 나누기 위해 고민했었는데 아직은 익숙하지 않은 것 같음
2. 유효성 검사에 대한 논의를 통해 각 계층에 대한 유효성 검사는 따로 따로 진행해야함을 알았음. ex) 컨트롤러는 사용자의 입력이 예상한 입력인지, DTO는 필드에 대해서, 모델은 인스턴스가 비즈니스 영역에서 사용 가능한지 검사. 액터에게 예외를 처리하도록
3. 다음 프로젝트나 과제를 시작 한다면 빠른 피드백을 위해 에런에게 코드 리뷰를 부탁하는 것도 괜찮을 듯. 에런도 도움을 주고 싶어함

enum에 관하여

기본적인 합의 사항

• 다수의 레이어에서 공통적으로 사용
• 요구사항에 나온 정의 중에서 enum으로 선언

enum 장점

• 실제 프로젝트에서 고정되는 값들이 꽤나 많음. 각 class에서 상수로 관리하는 것 보다 enum class 한 곳에서 관리할 수 있음
• 필드가 많아도 상관은 없음
  • 에러메세지
  • 대고객 메세지는 전송매체(SMS, Email, … )& 우선순위
• enum은 메서드 인자의 타입 안정성을 위해 사용한다.

enum 단점

• enum은 필드가 추가됐을 때 수정이 많이 필요하기 때문에 확장성이 없다.
• 비즈니스 로직이 enum에 강하게 의존하면 더욱 확장성이 없어지고 유지보수하기 어려워질듯.
  • enum 필드가 많아진다면 의존이 더 강해질듯

[haxr369]

앞으로의 방향성 (2024-03-11)

우테코 과제에 대한 회고

• 상호 피드백이 부족 → java에 대한 깊이가 깊어지기 때문
• 시간을 썼을 때 더 많은 성과가 필요

템플릿 기반 선택

• 다양한 로컬 환경에서도 잘 돌아가는 Docker 사용
• 싼 값에 클라우드에서 테스트를 돌릴 수 있는 github action 사용
• 확장성과 숙련도를 생각했을 때 Spring 프레임워크 선택

템플릿

템플릿이라 함은 기술에대한 이론적 이해 그리고 문제 상황(시나리오) 정의와 실험이 있다.

모범사례는 코드작성 기준을 따라야하며 성능도 고려해야한다.

• 모든 주제로 확장 가능한 가장 기초적인 Spring 프로젝트
• 일관성 있는 DB 제어를 위한 트랜젝션

과제

1. 우테코 로또 과제 수요일까지 코드리뷰 마무리
2. 시나리오에대한 고민

참고 (변경사항 없음)

• 🔔 자유로운 발의로 문화 만들기. 결정 사항은 기록하기
• 기록 간 GitHub Discussion 적극적으로 활용하기
• 발표를 계획한다면, 준비된 자료를 사전에 공유하자
• 회의: 다음 팀의 목표를 잡는 거시적인 관점의 논의 진행하기
  • 회의록: 회의 내용 요약
  • 회고록: 각자 느낀 점 및 목표/계획
• 프로젝트 시작은 협업을 위해 필요한 최소한의 합의 이후에 진행하자

[ooMia]

회의록 (2024-03-13)

고정 일정

• (월/수/금) 오전 10시 - 11시
• 별말 없으면 진행

내용 정리보다 난해한 부분을 주제로

• 여러 요청에 대한 동시성 제어
• 각 트래픽의 속성 정의
• 시스템 환경 정의
  • 마이크로 서비스
  • 분산 데이터베이스
  • 비동기 처리 (Spring WebFlux)
• 추상화하는 방식
  • 아키텍처적 (서버:DB)
  • 요청에대한 가정
  • 서버의 성능

통합 테스트

• 부하 테스트 (Load Test)
• 지속성 테스트 (Endurance Test)
• 스트레스 테스트 (Stress Test)
• 최고 부하 테스트 (Peak Test)

서버 성능 지표

• 처리량 (Transaction Per Second)
• 응답 시간 (Response Time)

템플릿의 가치

• 보다 더 효율적으로 문제를 해결하는 방법
  • 단, 효율의 정의에 따라 달라짐
    • 단순 성능, 확장성 뿐만 아니라 개발 속도도 비용
• DB 1대로 풀 수 있는 것을 DB 2대로 늘리지 않도록하는 기준

가장 간단하게!

문제가 되는 상황을 가지고 문제가 해결된 코드를 제시 - 최초 방향성은 재현
요청 간의 처리 시간이 다를 때, 각 요청에게 정합성이 맞는 데이터를 제공!
앞으로 확장성을 위해서 더 다양한 상황이 발생할 수 있는 이커머스를 예시로 잡고가는 방향도 있다.

템플릿

패키지 프라이빗을 하는 이유는 패키지 안에서만 중요 정보를 가둬둔다.
외부는 generator만 들려서 outputDTO를 받아서 할 수 있다.
ILotto => 일반적인 로또 - 처음 작성할 때 가장 중요하다고 생각하는 예를 들어 필드나 메서드

방향성

다음 주 월요일까지는 Spring Boot의 주제를 동시성 제어에대해 어떤 시나리오를 가지고 어떤 기준을 가지는 등 문제 정의
글 읽으면서 궁금한 점이나 제시할 점

조사 내용 공유 링크

시나리오

• 시스템 상황 정의 (은행 계좌이체, 온라인 결제)
  • 요청에 대한 제어
  • 요청 처리에 대한 제어
• 단순하게 재현하는 것에서부터 시작

참고 (변경사항 없음)

• 🔔 자유로운 발의로 문화 만들기. 결정 사항은 기록하기
• 기록 간 GitHub Discussion 적극적으로 활용하기
• 발표를 계획한다면, 준비된 자료를 사전에 공유하자
• 회의: 다음 팀의 목표를 잡는 거시적인 관점의 논의 진행하기
  • 회의록: 회의 내용 요약
  • 회고록: 각자 느낀 점 및 목표/계획
• 프로젝트 시작은 협업을 위해 필요한 최소한의 합의 이후에 진행하자

[ooMia]

회의록 (2024-03-15)

다음 발표 주제

다음 주 월요일 프론트원 오후 6시
발표 준비, 자료는 사전에 공유

주제: Java 스레드를 활용한 병렬 프로그래밍에서의 동시성 제어

@haxr369

• Thread pool, Lock, Mutex, Semaphore
• (여유 있으면) 리팩토링

@ooMia

• Java 21 Virtual Thread
• (여유 있으면) 도메인 주도 개발(DDD)

Know How

• 이 기술이 효율적/필요한 상황
  • 재현 가능한 시나리오 소개
• Before & After
  • 어떻게 하면 문제를 발생시킬 수 있는지
  • 어떻게 하면 문제가 해결되는지
  • (가능하다면) 보다 효율적인 해결책은 무엇인지

방향성

단순한 구조에서부터 점진적으로 확장

• POJO -> DBMS / JDBC -> Spring-Framework ( MVC/WebFlux, Spring JPA )
• 동시성 제어: 스레드 -> 단일 데이터베이스 -> 다중 데이터베이스 -> SOA -> MSA

** 단일 서비스 내 다중 데이터베이스 (SOA)
** 다중 (마이크로)서비스 내 다중 데이터베이스 (MSA)

참고 (변경사항 없음)

• 🔔 자유로운 발의로 문화 만들기. 결정 사항은 기록하기
• 기록 간 GitHub Discussion 적극적으로 활용하기
• 발표를 계획한다면, 준비된 자료를 사전에 공유하자
• 회의: 다음 팀의 목표를 잡는 거시적인 관점의 논의 진행하기
  • 회의록: 회의 내용 요약
  • 회고록: 각자 느낀 점 및 목표/계획
• 프로젝트 시작은 협업을 위해 필요한 최소한의 합의 이후에 진행하자

[ooMia]

회고

• 통합 구조를 설계하니 손쉽게 구현 가능했다.
• 함수 크기에 따라 분리하는 것처럼, 도메인도 역할별 분리 (SRP)
• 도메인은 Entity와 동일하지 않다. 서비스 관점에서 정의 가능

[haxr369]

회의록 (2024-03-22)

다음 발표 주제

다음 주 �수요일 디스코드 10시
발표 준비, 자료는 사전에 공유

주제: Java 스레드를 활용한 Spring 동시 요청 제어

@haxr369

• Spring Async
• Spring multi thread test 방법
• Spring actuator

@ooMia

• Spring 기본 템플릿 만들기 (최소한의 의존성)

방향성

• 실시간으로 작업 진행 상황을 공유할 수 있도록 GitHub project 칸반 보드를 적극적으로 사용하자.
• Spring에서 동시성 제어에 관한 재현 가능한 문제를 해결한다.