서론안녕하세요 팀 원코의 백엔드 개발을 맡고 있는 박준선입니다. 🙇‍♂️원코 프로젝트는 S3 이미지 저장 방식을 사용하고 있었는데요.S3 객체 URL을 그대로 DB 저장하고, 클라이언트 서버에게 S3 객체 URL를 서빙하는 구조였습니다.이번 포스팅은 기존 S3 방식에서"왜 CloudFront를 도입하게 되었고, 그 과정에서 발생한 문제와 그 해결 과정"을 정리해보고자 합니다.측정은 Chrome DevTools → Network에서 이미지 요청의 Duration과 Timing(Content Download)을 기준으로 했습니다."정확한 비교를 위해 Disable cache 옵션도 켜서 측정했습니다."본론기존 구조: S3 URL을 DB에 저장하던 방식원코 프로젝트 초반에는 구조가 단순했습니다.이미지는 AW..

서론원코 프로젝트는 TAVE 16기 후반기 연합 팀 프로젝트입니다. 듀오링고, 말해보카와 같은 학습 플랫폼에서 "경제"라는 주제로"AI가 알려주는 하루 10분 매일 경제 공부 플랫폼", "One Day Economy" 원코 서비스를 기획했습니다. 그러나,"그래서 사람들이 왜 우리 서비스를 사용해야 하지?"라는 질문에 답을 하지 못했었습니다. 그래서 새롭게 기획하게 된 "부모-자녀 페어링 기반 경제·금융 키워드 교육 서비스" 원코는 부모와 자녀가 함께 학습을 계획하고, 자녀에게 보상이라는 학습 동기를 부여하는 경제 금융 서비스입니다.본론새로운 기술과 근사한 아키텍처를 프로젝트에 도입하고 싶은 마음은 개발자라면 모두 공감하실 것 같습니다.저도 이때 당시 새로운 Tech Stack, Architecture 등..

보호되어 있는 글입니다.

서론 PR 작성이 숙제처럼 느껴질 때ONECO 팀에서 개발하면서 매번 반복되는 '루틴'이 하나 있었습니다. 바로 PR(Pull Request) 문서를 쓰는 일이었죠."자, 이번에 내가 뭘 바꿨더라?" 기억을 더듬는다.수정된 파일들을 하나하나 다시 훑어본다.커밋 로그를 복사해서 팀원들이 읽기 좋게 다듬는다.마지막으로 AI에게 "이거 문장 자연스러워? 논리적으로 이상한 건 없어?"라고 물어본다.처음엔 이게 참 좋은 습관이라고 생각했어요.문서를 꼼꼼히 쓸수록 코드 리뷰 속도도 빨라지고, 협업 퀄리티도 올라가니까요. 하지만 프로젝트 덩치가 커지고 작업량이 많아지니,어느샌가 이 과정이 기분 좋은 마무리가 아니라 피곤한 숙제처럼 느껴지기 시작했습니다."어차피 AI가 봐줄 거라면, 처음부터 맡기면 안 돼?"어느 날 ..

FamilyRelation / FamilyInvitation을 만들며 “도메인 규칙을 어디에 둘 것인가”를 정리한 기록이다. ONECO는 도메인 주도 개발(DDD)을 지향한다. Family 도메인을 구현하면서 가장 먼저 부딪힌 질문은 단순했다.“부모–자녀 관계는 단순 조인 테이블일까, 아니면 ‘연결’ 자체가 도메인일까?”“JPA @ManyToOne으로 멤버를 물고 갈까, 아니면 ID 값 참조로 갈까?”“연결 해제는 삭제인가, 상태 변화인가?”“초대 코드는 어떻게 만들고, 만료는 어떻게 처리할까?”이번 글은 위 질문들에 대해 팀(우리)이 내린 결론과, 그 결론이 코드에 어떻게 반영됐는지 정리한 설계 일지다. 1) FamilyRelation은 “관계”가 아니라 “연결”이다 Family 도메인은 단순히 mem..

Long vs MemberId(VO) — 결국 우리는 MemberId(VO)를 선택했다. 이전 글에서 ONECO는 FamilyRelation이 Member를 @ManyToOne으로 들고 가지 않고, parentId / childId 같은 값 참조(ID) 를 선택했다고 정리했다. [ONECO] Family 도메인에서 FamilyRelation 매핑 고민기ManyToOne vs 값 참조(ID) — 결국 우리는 “값 참조”를 선택했다 ONECO는 도메인 주도 개발(DDD)을 지향하며 진행 중인 프로젝트다. Family 도메인을 구현하면서, “부모–자녀 계정 연결”이라는 요구goodjunseon-tech-blog.tistory.com 그 다음 단계에서 팀이 마주친 고민은 이거였다. “그럼 그 ID는 그냥 ..

ManyToOne vs 값 참조(ID) — 결국 우리는 “값 참조”를 선택했다 ONECO는 도메인 주도 개발(DDD)을 지향하며 진행 중인 프로젝트다. Family 도메인을 구현하면서, “부모–자녀 계정 연결”이라는 요구사항을 표현하기 위해 FamilyRelation 엔티티를 만들었고, 여기서 아주 흔하지만 꽤 중요한 설계 갈림길을 만났다. FamilyRelation이 Member를 어떻게 참조해야 할까? JPA 연관관계(@ManyToOne)로 객체 그래프를 만들 것인가 아니면 parentId, childId 같은 식별자 값만 들고 갈 것인가이번 글은 그 고민 과정과 각 방식의 장단점, 그리고 ONECO에서 최종적으로 “값 참조”를 도입한 이유를 정리한 기록이다. 배경: FamilyRelation은 “..