Skip to content
dlsnfl0615 edited this page Jul 24, 2026 · 1 revision

📄 원본(노션): https://app.notion.com/p/3a719935b8ae8044a6aecd440d08e033 — 최종 동기화 2026-07-24

오전 스크럼

  • ✅ 생년월일 넣어야 함. (ERD) DATE 데이터 타입이 있다. 이거 쓰면 됨.

    Date? DateTime? TimeStamp?

    MySQL의 날짜·시간 타입은 JPA에서 보통 java.time 계열로 매핑합니다. java.util.Date는 레거시라 새 코드에서는 권장하지 않습니다.

    MySQL 타입 권장 Java 타입 의미
    DATE LocalDate 날짜만 저장
    TIME LocalTime 시간만 저장
    DATETIME LocalDateTime 날짜와 시간, 시간대 없음
    TIMESTAMP LocalDateTime 또는 Instant 날짜와 시간, 시간대 처리 주의

    예를 들어:

    birth_date DATE,
    created_at DATETIME,
    updated_at TIMESTAMP
    

    JPA 엔티티는 다음처럼 작성할 수 있습니다.

    @Entity
    public class User {
    
        @Id
        private UUID id;
    
        private LocalDate birthDate;
    
        private LocalDateTime createdAt;
    
        private LocalDateTime updatedAt;
    }

    별도의 @Temporal은 필요하지 않습니다. @Temporaljava.util.DateCalendar를 사용할 때 필요한 레거시 애너테이션입니다.

    MySQL DATE

    날짜만 저장한다면 LocalDate입니다.

    @Column(name = "birth_date")
    private LocalDate birthDate;
    birth_date DATE
    

    값은 다음처럼 저장됩니다.

    2026-07-24
    

    MySQL DATETIME

    시간대 정보 없이 날짜와 시각을 저장합니다.

    @Column(name = "created_at", nullable = false)
    private LocalDateTime createdAt;
    created_at DATETIME NOT NULL
    

    값:

    2026-07-24 15:30:00
    

    LocalDateTime에는 Asia/Seoul, UTC 같은 시간대 정보가 없습니다.

    MySQL TIMESTAMP

    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=8080
    

    Q: AWS의 Secrets Manager를 고려해 보았나? A: 결국 DB 비밀번호 몇 개를 안전하게 보관하려고 배포 구조가 상당히 복잡해짐 + 단일 서버에서는 비용도 생각하면 효용성이 낮음.

    현재는 단일 EC2 기반의 MVP이므로 systemd의 Environment File (.env)을 통해 운영 설정을 관리한다. 설정값은 Git 저장소와 분리하고 파일 권한을 제한한다. 향후 서버가 다중화되거나 비밀값 회전 및 접근 감사가 필요해지면 AWS Secrets Manager 또는 Parameter Store로 이전한다.

  • ✅ ORM (JPA)에서 1:N 관계? @ManyToOne, @OneToMany annotation을 사용하자. 이렇게 되면 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원 단위로 포인트 충전 가능하기로 합의.

  • 로그인 탕에

  • 포인트 충전 페이지 참고

    네이버페이 충전 현대백화점그룹 통합멤버십 (H.Point)

  • 에셋 (아이콘, 이미지 등)들은 어디에 올릴 것인가? 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 - 실시간까지는 아니지만 근처의 드리미 위치를 받고 있어야 하기 때문에 저장.

Action 1

  • 단체로 논의를 할 일이 생겼을 때, 타이머를 띄워놓고 그 내에서만 결정하기
  • 대주제를 띄워놓고 한다 (범위를 벗어나지 않게)
  • 현재 주제랑 관련 없는 내용은 드래프트에 같이 넣어두고 추후에 회의
  • 아침에 회의 + 점심 먹고 14:00 회의 + 저녁에 회의 (타이머도) 그 사이에는 자신이 다른 할 수 있는 일이 있다면 그 것에 집중하는 것이 중요.

Action 2

  • 스프링 기본사용법 알아오기
  • AI를 쓰되 내용을 설명할 수 있을 정도로 숙지
  • 남들한테 공유하기 전에 정리하기
  • 정리할 때 프롬프트를 사용했다면 해당 프롬프트 공유

🛵 쉼, 부름

Softeer Bootcamp 8th · WEB Team 3


🏠 시작하기

🤝 협업

📋 기획안

🧠 기술 결정 기록 (ADR)

🕸️매칭 시스템

🧪 부하 테스트

🔧 트러블슈팅

🗓️ 데일리 스크럼


Repo

Clone this wiki locally