탐구개발

계층구조는 실무에서 자주 마주치는 주제입니다. 카테고리의 대중소 분류나 조직도의 상하위 구조처럼요. 저 역시 몇 차례 관련 기능을 구현하며 고민을 거쳤고, 이번 글에서는 계층구조 설계에 대한 의사결정 과정을 정리해 보았습니다. 실무에서의 계층구조 특징모든 실무에서는 아니겠지만 제가 겪었던 실무에서의 특징은 다음과 같습니다.보통 깊이(depth)가 5를 넘지 않는다.한 레벨의 하위 데이터(children) 수도 1000개 이상으로 폭증하는 경우는 드물다.기준 데이터 성격이라 변경 빈도도 낮은 편이고, 상하위 재배치가 자유롭지는 못해, 구현이 상대적으로 단순했다.다만 depth와 children이 사실상 무제한이고, 상하위 재배치가 매우 자유로워야 한다는 요구상이 추가된다면 난이도는 확 올라갑니다. 물론..

실무에서 판매업체별 배송정책과 물류센터 데이터가 분리 관리되다 보니, 물류센터 변경이 배송정책에 제때 반영되지 않는 문제가 발생했습니다. 반복적인 DB 직접 수정보다 원인과 운영 현실을 함께 고려해 해결책을 검토했습니다. 이 글은 그 의사결정 과정과, 더 나은 방법이 있었는지까지 돌아보는 회고입니다. 배경과 상황배송정책판매업체마다 1개 이상 보유배송유형/방식/주체/주소 등의 정보를 포함물류센터배송주체가 특정 값일 때 물류센터 정보를 조회하여 배송정책의 데이터로 활용배송정책과는 별도로 어드민에서 따로 등록수정하여 관리사용현황물류센터 정보 변경은 드문 편입니다.물류센터 정보를 참조하는 배송정책도 많지 않습니다.문제점물류센터 정보가 변경되어도 배송정책에 자동 반영되지 않음.배송정책이 물류센터 PK를 참조하지..

설문 결과의 통계값을 간단하게 보여주는 기능을 추가하고자 했습니다. 기존에 Elastic Beanstalk에 배포된 서버가 있었지만, 단순한 통계 집계 기능의 경우 메인 서버에서 처리하는 것보다 서버리스 구조로 구현하는 것이 더 효율적이라고 판단하였습니다. 이에 따라 AWS Lambda와 DynamoDB를 활용하여 서버리스로 구현하였습니다. DynamoDB에 저장할 데이터 형식을 어떻게 설계할지 고민한 과정을 작성한 글입니다. 저장 데이터다음과 같은 데이터를 저장하려고 합니다.testId : 테스트 이름 (예: 오늘의치킨(chicken))resultType : 결과 유형(예: 굽네(goobne), 교촌(kyochon))count: 해당 결과의 수 Case 1: testId + resultType ..