회고14 DND 12기 백엔드 후기 (2024.12.30 ~ 2025.02.22) DND 12기 활동기간 : 2024.12.30 ~ 2025.02.22 (총 8주)포지션 : 백엔드팀 인원 : 4명(디자이너2,안드로이드1,백엔드1) 처음 우리 팀은 디자이너 2명, 안드로이드 2명, 백엔드 2명으로 총 6명이었는데, 불가피하게 2명이 제명되면서 최종적으로 4명이 프로젝트를 이어가게 됐다. 나는 백엔드 파트를 맡았고, 디자이너 2명과 안드로이드 1명과 함께 협업했다.4주차까지는 격주 회고를 꾸준히 작성했지만, 5주차부터 예기치 못한 문제들이 매주 터지는 바람에 내 러닝 루틴과 회고 패턴이 크게 흔들렸다. 팀을 둘러싼 여러 이슈들을 해결하느라 정신없이 지냈지만, 다행히도 이전에 진행했던 우테코 프리코스와 12시간에 걸친 미션 구현 & 코드리뷰 연습(코딩 5시간, 코드리뷰 7시간)에서 길러.. 2025. 2. 24. [2025. 러닝] 4주차 러닝 후기 4주차 기록 목표: 3km 5번뛰기할말:이제는 3km 잘 뛴다. 3km를 다 뛰고 나서 확 오는 탈진감이 완화됐다.러닝 루틴이 생긴 것 같다.뭔가 오늘 할일을 하나 마치고 나면 -> 바람 쐴 겸 러닝 뛰었다.이번 주 내내 그랬다. 어느새 1달 러닝을 뛰었는데, 1~2주차때 너무 힘들었던 걸 생각하면, 현재 많이 성장한게 느껴진다. 2025. 1. 25. DND 커피챗 | ERD - 좌표(latitude·longitude)만 저장하는 것과 주소(address)까지 함께 저장하는 것 중, 어느 쪽이 더 효율적인가요? 준비한 질문좌표(latitude·longitude)만 저장하는 것과 주소(address)까지 함께 저장하는 것 중, 어느 쪽이 더 효율적인가요? 배경 및 상황프로젝트 주요 기능: "사용자가 설정한 동네 반경 내에서 사건/사고 게시글이 올라오면 알림 발송"클라이언트에서 (위도, 경도) 좌표를 받고, 서버에서 이를 주소로 변환해 테이블에 저장하려고 합니다.현재 ERD에는 `address`(동 단위 예: 효자동)와 `latitude`, `longitude`를 모두 넣어두었는데, 이 세 항목이 중복되거나 필요 이상이 아닐까 고민됩니다.(예: 좌표만 저장하면 주소는 필요할 때만 변환해서 조회하면 될 수도 있는데, 괜히 `address`까지 같이 저장해둬야 하나?)GPT 4.0 모델이 "전부 관리하라"고 조언해.. 2025. 1. 24. DND 커피챗 | ERD - 테이블에 여러 타입이 있을 때, 분리해야 할까? 준비한 질문테이블에 여러 타입이 있을 때, 분리해야 할까? (알림 테이블의 두 타입 : 전체 알림, 지역 알림) 배경 및 상황 저희 시스템에서 "알림"은 크게 두 종류입니다. 1. 전체 알림 (예: 전국 단위 공지나 긴급 재난 알림) 2. 지역 알림 (특정 지역 혹은 반경을 설정한 사용자에게만 발송)현재 알림 테이블에는 지역 정보를 참조하는 외래 키(FK)가 있는데, 전체 알림일 때는 이 FK가 `NULL`이어야 하는 상황이 발생합니다. "단일 테이블로 관리하되, 지역 정보 컬럼에 `NULL`을 허용하면 되지 않나?"라고 생각하고 있지만, "NULL 컬럼이 늘어나는 것"에 대한 우려도 있습니다. 한편, 알림 유형별로 테이블을 분리하면 스키마가 깔끔해지지만, 과연 그만한 가치가 있는지는 확신이 .. 2025. 1. 24. DND 커피챗 | ERD - 1:1(@OneToOne) 연관관계에서 테이블을 합칠지, 분리할지에 대한 기준 준비한 질문1:1(@OneToOne) 연관관계에서 테이블을 합칠지, 분리할지에 대한 기준을 물어보고 싶습니다. 배경 및 상황제 ERD에서 `User` 테이블과 `UserProfileImage` 테이블이 1:1 관계입니다.사실상 라이프 사이클이 같고(프로필 이미지는 항상 존재하며, 유저가 삭제되면 이미지도 삭제됨) 이미지 변경도 빈도가 낮습니다. 그래서 굳이 두 개로 나누지 않고 한 테이블에 합쳐버리면, 조인을 한 번 덜 해도 되니 쿼리 효율이 좋아 보이기도 합니다.다만 테이블을 분리하면 "책임 분리"가 명확해지고, 확장성도 좋아질 것 같다는 장점이 있습니다.이번 기회에 "1:1 관계 테이블 설계 기준"을 제대로 잡아보고 싶습니다.구체적인 궁금증1:1 관계에서 테이블을 분리할지 합칠지를 결정할 때 최우선.. 2025. 1. 23. DND 커피챗 | ERD - 모든 테이블에 createdAt, updatedAt을 두는 것에 대한 고민 준비한 질문모든 테이블에 createdAt, updatedAt을 두는 것이 바람직한지 여쭤보고 싶습니다. 배경 및 상황현재 거의 모든 테이블(예: 이모지 테이블 등)에 createdAt, updatedAt 컬럼을 두고 있습니다.운영 중 발생한 이슈 추적이나 변경 이력 파악에 편리하다고 알고 있지만, 클라이언트가 굳이 필요로 하지 않는 컬럼까지 일괄로 두는 것이 성능 저하로 이어지지 않을까 걱정됩니다. 특히 "한 컬럼의 데이터를 읽을 때 같은 블록 단위의 모든 데이터를 읽는다"고 들었는데,이 때문에 불필요한 I/O가 발생할 여지가 있다고 생각합니다."모든 테이블에 다 넣어도 괜찮을까?" 또는 "어떤 기준으로 컬럼을 두고/빼야 할까?"에 대해선뜻 결정하기 어렵습니다. 구체적인 궁금증createdAt, upd.. 2025. 1. 23. 이전 1 2 3 다음
