-
Notifications
You must be signed in to change notification settings - Fork 3
07 24
📄 원본(노션): https://app.notion.com/p/3a719935b8ae8044a6aecd440d08e033 — 최종 동기화 2026-07-24
-
✅ 생년월일 넣어야 함. (ERD) DATE 데이터 타입이 있다. 이거 쓰면 됨.
Date? DateTime? TimeStamp?
MySQL의 날짜·시간 타입은 JPA에서 보통
java.time계열로 매핑합니다.java.util.Date는 레거시라 새 코드에서는 권장하지 않습니다.MySQL 타입 권장 Java 타입 의미 DATELocalDate날짜만 저장 TIMELocalTime시간만 저장 DATETIMELocalDateTime날짜와 시간, 시간대 없음 TIMESTAMPLocalDateTime또는Instant날짜와 시간, 시간대 처리 주의 예를 들어:
birth_date DATE, created_at DATETIME, updated_at TIMESTAMPJPA 엔티티는 다음처럼 작성할 수 있습니다.
@Entity public class User { @Id private UUID id; private LocalDate birthDate; private LocalDateTime createdAt; private LocalDateTime updatedAt; }
별도의
@Temporal은 필요하지 않습니다.@Temporal은java.util.Date나Calendar를 사용할 때 필요한 레거시 애너테이션입니다.날짜만 저장한다면
LocalDate입니다.@Column(name = "birth_date") private LocalDate birthDate;
birth_date DATE값은 다음처럼 저장됩니다.
2026-07-24시간대 정보 없이 날짜와 시각을 저장합니다.
@Column(name = "created_at", nullable = false) private LocalDateTime createdAt;
created_at DATETIME NOT NULL값:
2026-07-24 15:30:00LocalDateTime에는Asia/Seoul,UTC같은 시간대 정보가 없습니다.JPA에서는
LocalDateTime으로도 매핑할 수 있습니다.private LocalDateTime updatedAt;
다만 MySQL의
TIMESTAMP는 DB 세션 시간대에 따라 변환될 수 있기 때문에 서버, JVM, MySQL의 timezone 설정이 다르면 시간이 어긋날 수 있습니다.전 세계 기준의 절대 시점을 명확하게 저장하려면 다음처럼
Instant를 고려할 수 있습니다.@Column(name = "created_at", nullable = false) private Instant createdAt;
애플리케이션에서는 UTC로 저장하고, 화면에 표시할 때 한국 시간으로 변환합니다.
ZonedDateTime koreaTime = createdAt.atZone(ZoneId.of("Asia/Seoul"));
다만 부트캠프 프로젝트에서 국내 서비스이고 모든 서버 시간대를 통일할 예정이라면
LocalDateTime으로 시작해도 충분합니다. -
✅ yml? properties?
설정을 어떻게? - properties + .env
맞습니다. 구조는 보통 이렇게 갑니다.
application.properties ↓ ${환경변수명} EC2의 환경변수 ↓ /etc/boormi/boormi.env ↓ systemd가 읽어서 Spring Boot 프로세스에 주입application.properties:spring.datasource.url=${DB_URL} spring.datasource.username=${DB_USERNAME} spring.datasource.password=${DB_PASSWORD} spring.profiles.active=${SPRING_PROFILES_ACTIVE:prod} server.port=${SERVER_PORT:8080}
EC2의
/etc/boormi/boormi.env:DB_URL=jdbc:mysql://127.0.0.1:3306/boormi DB_USERNAME=boormi_app DB_PASSWORD=strong-password SPRING_PROFILES_ACTIVE=prod SERVER_PORT=8080Q: AWS의 Secrets Manager를 고려해 보았나? A: 결국 DB 비밀번호 몇 개를 안전하게 보관하려고 배포 구조가 상당히 복잡해짐 + 단일 서버에서는 비용도 생각하면 효용성이 낮음.
현재는 단일 EC2 기반의 MVP이므로 systemd의 Environment File (.env)을 통해 운영 설정을 관리한다. 설정값은 Git 저장소와 분리하고 파일 권한을 제한한다. 향후 서버가 다중화되거나 비밀값 회전 및 접근 감사가 필요해지면 AWS Secrets Manager 또는 Parameter Store로 이전한다.
-
✅ ORM (JPA)에서 1:N 관계?
@ManyToOne, @OneToManyannotation을 사용하자. 이렇게 되면 select할 때 Lazy Loading / Eager Loading 중 이걸 사용해야 함.@ManyToMany도 쓸 순 있지만 별로임. -
React 작업중. (Claude)
WebStorm IDE를 사용하면 좋다.
-
PortOne → CI → 개인 정보 Masking? 테이블을 나누어야 할지도. CI는 사용자를 지속적으로 식별할 수 있는 값이라 개인정보 보호법 적용 대상입니다. 따라서
- 평문 로그 출력 X
- API 응답 X
- 관리자 화면 그대로 출력 X
- 필요한 경우 암호화 저장
이 일반적인 권장사항입니다.
본인인증으로 받은 CI와 개인정보는 일반 회원 정보와 분리된 테이블에 저장하고, 화면 및 로그에는 마스킹된 정보만 노출하도록 설계했습니다. 향후 운영 환경에서는 컬럼 암호화나 KMS 연동을 적용할 수 있도록 구조를 분리했습니다.
USER ------------ user_id nickname role ... USER_PRIVATE ------------ user_id (FK) ci name phone birth
비밀번호는 여전히 사용자 (boormi) 테이블 내부에 넣어도 됨.
-
API 추가 명세서 - 포인트 / 결제 관련 api
-
✅ 결제를 통한 충전 최소 단위가 얼마면 좋을까? 100원 단위로 포인트 충전 가능하기로 합의.
-
로그인 탕에
-
포인트 충전 페이지 참고

-
에셋 (아이콘, 이미지 등)들은 어디에 올릴 것인가? EC2? S3? 깃허브 resource?
오전: 팀 시간 오전 10:15 ~ : 와이어프레임 오후 14:00 ~ 15:00 팀 시간 오후 15:00 ~ 17:00 스쿼드 세션 오후 17:00 ~ 18:00 피드백 세션 오후 18:00 ~ 19:00 팀 시간 (회고/다음주 플래닝)
- 프론트엔드
- S3 + Cloud Front
- 현재 문제점: error를 처리할 때 Common Response에서 많은 코드를 작성해야 swagger에 적용되는 문제가 있음. 해결법: 고민중.
-
박태은 1조 - 중고차 실시간 경매 헤이 딜러 등의 중고차 서비스 - 오토벨 서비스 딜러들에게 다 파는 위주의 앱들밖에 없음.
- 배경: 헤이 딜러 일반인이 판매 신청하면 평가 정보 추산 후 딜러들이 bid를 넣고 최고가인 것이 선정 후 판매자가 만족했는가?
미술품과 같이 실시간 경매를 하고 싶었음. MVP는 경매 위주. 평가사도 도입하는 것이 좋겠다. 하지만 후순위. 결제 시스템도 후순위로 하자.
- 테스트, 위치 이동이 너무 복잡할 것 같았음.
클로드에게 기획서 등을 넣으니까 리엑트 vite로 목업까지 다 해줌.
- github project!
-
정세호 2조 - 포켓몬 카드 경매: 어려울 것 같아서 이걸 선택했다. 포켓몬 카드 사람들이 많이 찾고있고, 여러가지 보다는 하나만 타겟을 해서 하는 것이 좋겠다고 생각함.
- 프론트 목업까지는 다 뽑았음.
- 크림을 클론 코딩을 이미 했음.
- 카드 시세가 있는 탭
- 경매할 수 있는 탭
- 판매 등록, 대시보드 탭도 다 만들어놓음.
- 이것을 기반으로 API뽑아서 하면 됨. - 프론트 연결을 해야 함. 프론트 엔드: 크림을 캡처를 해서 실제로 만들었다. - 판매 사이트를 기반으로.
- codex react skill. → 스크린샷을 프론트로 변한하는 것이 있음.
협업은? 단점: 동시 편집밖에 안됨. 장점: 뭔가 보기 좋긴하다. 위키 문서도 적혀있음. → 클론도 가능하구나. AI가 잘 짜줌. 프론트 → AI → 백 순서가 헷갈림. 결과적으로는 하나가 완성이 명확히 되려면 프론트 API가 짜지고 ERD를 짜는 것이 맞지 않을까? → 여기서 병목이 있는 것 같다는 생각중. 실시간 - 경매에서 사용자가 다른 사람이 상회 입찰을 하면 바로 바로 입찰하려는 심리가 있음. 이걸 UI로 빠르게 할 수 있어야 함. 프론트가 버텨줄까?
aws - nat용 java 이미지가 있음. S3에 프론트 빌드 한 결과물 + Cloud fron를 통해 캐시 서버. github secret - 다신 안보임 github variable - 다시 볼 수 있음 redis 사용.
-
이동혁 3조 - 회사 단지 내에서 배송 드리미에게 길 안내하는거 → 카카오 지도로 리다이렉트를 해준다.
-
박민서 7조 - 카카오 택시 클론 코딩 라이더 앱, 고객 앱 매칭을 하려고 했음.
- 경매 하고 싶었음.
경매가 조금 더 기술적으로 좁고 깊게 집중을 할 수 있을 것 같았음.
- 오히려 퀵서비스가 기술적 문제가 많긴 함. 기술적 문제가 하나면 그 문제를 배분하는 것이 일이다. AI를 사용하니까 단순 구현은 오래 걸리지 않을 것 같았음.
- 기획, 디자인에 시간을 아끼자 - 클론.
- 카카오 퀵 클론 - 캡처본을 저장한 것.
- 클론하면서 잘라내는데 시간이 걸림. 회의를 많이 했음.
일단은 웹 pwa → GPS
- 웹은 있어야 하는데 서비스가 앱으로 사용하는 경우가 많아서 앱을 만들어야 하는데 어떻게 해야할까?
- 그러면 섞어보자. 피그마 화살표 만들기.
기능 명세서를 뽑아서 github issue로 만들어서 배분도 한 상태. → 결제 여기도 포인트로 함. 배송 취소 배송 상태 정리 되어있음. 여기는 그냥 간단하게 매칭은 그렇게 됨. 슬랙은 그냥 잡다한 내용을 넣을 때 사용한다. github discussion으로 - daily 회고 KPT 방식 미리 사용하고 있었음. 결정이 된 회의록은 Wiki에 올려놓자. 배차 동시성 실시간 위치 처리 배송 상태, 전이, 정산 정합성. 주 담당자, 부 담당자를 정해서 진행. 실시간 위치 redis → 일부만 DB로 넘긴다.
- 세션 방식 인증 → 세션 저장소 redis를 사용.
- 경매 하고 싶었음.
경매가 조금 더 기술적으로 좁고 깊게 집중을 할 수 있을 것 같았음.
NFR-03 - 실시간 위치 업데이트 주기는 5~10초로. 굳이 움직이지 않을때 배터리 최적화 등은 생각하지 않음. NFR-04 - 실시간까지는 아니지만 근처의 드리미 위치를 받고 있어야 하기 때문에 저장.
- 단체로 논의를 할 일이 생겼을 때, 타이머를 띄워놓고 그 내에서만 결정하기
- 대주제를 띄워놓고 한다 (범위를 벗어나지 않게)
- 현재 주제랑 관련 없는 내용은 드래프트에 같이 넣어두고 추후에 회의
- 아침에 회의 + 점심 먹고 14:00 회의 + 저녁에 회의 (타이머도) 그 사이에는 자신이 다른 할 수 있는 일이 있다면 그 것에 집중하는 것이 중요.
- 스프링 기본사용법 알아오기
- AI를 쓰되 내용을 설명할 수 있을 정도로 숙지
- 남들한테 공유하기 전에 정리하기
- 정리할 때 프롬프트를 사용했다면 해당 프롬프트 공유
Team 3 · 석희 · 현성 · 동혁 · 현서
Softeer Bootcamp 8th · WEB Team 3 · 이 위키는 팀 노션에서 동기화됩니다 📄
🏠 시작하기
🤝 협업
📋 기획안
🧠 기술 결정 기록 (ADR)
- 세션 vs 토큰
- 세션 및 다중 탭 처리 정책
- 실시간 배달 상태 전달에 SSE를 선택한 이유
- SSE 연결은 왜 1개였다가 5개가 되고, 다시 1개가 되었을까
- 드리미 GPS 끊김 감지 정책
- Redis 기반 로그인 대기열 도입기
- 카카오 API 응답 Redis 캐시 설계
- 활동 내역 조회를 커서 기반 페이지네이션으로 진행
- 알림 - WebPush 도입 이유와 SSE의 한계
- S3 Presigned URL 도입 결정
- 포인트, 머니 시스템 설계
🕸️매칭 시스템
- 매칭 시스템 설계
- Command와 Producer Consumer를 조합한 single writer 구조의 매칭 엔진
- 제안은 누구에게 해야 할까
- 쉼, 부름의 부르미‐드리미 매칭은 어떻게 동작할까
- 배정 정책에 Greedy 배정을 선택한 이유
- 매칭 시스템 구현
🧪 부하 테스트
- 매칭 부하테스트
- 매칭 부하테스트 보고서 (8.12)
- 매칭 부하테스트 보고서 (8.13)
- 매칭 부하테스트 보고서 (8.13 · 외부 API 트랜잭션)
- 매칭 부하테스트 보고서 (8.18 · 배포환경 720명)
🔧 트러블슈팅
- UploadSession - 옛 키 재사용 공격 방어 설계
- 8/6 · EC2 SSH 접속 불가
- 8/7 · 매칭 확정 후 Delivery가 생성되지 않는 고아 Order 문제
- 8/8 · 영속성 컨텍스트 detach로 dirty checking 미반영 문제 (@Modifying(clearAutomatically = true))
- 매칭 확정 후 Delivery가 생성되지 않는 고아 Order 문제
- 매칭이 성공하지 않았음에도 Orders 테이블에 PENDING으로 상태 변경하는 문제
- 부르미 확인 타임아웃 시 주문 DB·매칭 메모리 불일치
- 주변 콜 조회 시 반복되던 주문 조회 개선
- 드리미 오프라인 조회에 필요한 복합 인덱스 추가
- 매칭 단계 취소시 포인트 이중 환불 문제
- 로컬 DevStorage 사용시 로그인 상태에서도 401 UNAUTHORIZED 뜨던 문제
🗓️ 데일리 스크럼