단한의 개발 탐사기

들어가며Laiteu의 포트폴리오 서비스를 운영하면서 큰 구조 변경이 필요한 시점이 왔습니다. V1 API는 MVP 단계에서 빠르게 구현되어 기본적인 기능을 제공했지만, 서비스가 성장하면서 새로운 요구사항들이 늘어났습니다. 특히 기존 API 구조로는 수용하기 어려운 데이터 모델의 근본적인 변경이 필요했고, API 응답 포맷도 전면적인 수정이 불가피했습니다.이러한 변경사항을 적용하면서도 이미 서비스 중인 웹 서비스와의 호환성을 유지해야 하는 과제가 있었습니다. 이에 따라 API 버전을 분리하는 전략을 선택했고, EC2 인스턴스 내에서 여러 버전의 API 서버를 동시에 운영하는 구조를 구현하게 되었습니다. 이 글에서는 다중 버전 API 서버 구현 과정에서 겪은 기술적 도전과 해결 방법을 공유하고자 합니다.실제..

들어가며작품 포트폴리오 서비스를 개발하면서, 대표 이미지 지정 기능이 새롭게 추가되었습니다. 기존에는 업로드된 첫 번째 이미지를 대표 이미지로 사용했는데, 이는 MVP(Minimum Viable Product) 단계에서 충분했습니다. 하지만 알파테스터들의 피드백을 통해 대표 이미지를 직접 선택하고 싶다는 요구사항이 생겼고 이에 따라 저장 로직을 개선하게 되었습니다.문제 인식초기 개발 시에는 단순히 이미지 배열의 첫 번째 요소를 대표 이미지로 사용했습니다. 이는 다음과 같은 이유 때문이었습니다:단순한 구현: 별도의 필드나 로직 없이도 대표 이미지를 결정할 수 있었습니다.데이터 중복 최소화: 이미지 ID를 한 번만 저장하면 되었습니다.조회 성능: 대표 이미지를 가져올 때 추가적인 필드 조회가 필요 없었습니다..

들어가며API 응답 형식의 표준화는 백엔드 개발에서 매우 중요한 부분입니다. 일관된 응답 형식은 API를 사용하는 클라이언트 개발자의 개발 경험을 크게 향상시키고, 프로젝트의 유지보수성을 높여줍니다. 하지만 개발 초기 단계에서는 이러한 표준화의 중요성을 간과하기 쉽습니다. 빠른 기능 구현에 집중하다 보면, 각 API 엔드포인트마다 서로 다른 응답 형식을 가지게 되고, 이는 결국 기술 부채로 남게 됩니다.저희 팀도 작품 즐겨찾기 서비스를 개발하면서 이러한 문제를 경험했습니다. 프론트엔드 개발자가 API 연동 시 매번 다른 방식으로 응답을 처리해야 했고, 에러 처리도 일관성이 없었습니다. 이에 따라 API 응답 형식을 표준화하는 작업을 진행하게 되었고, 그 과정에서 많은 것을 배울 수 있었습니다.문제 인식처..

들어가며AWS로 개발/운영 환경을 구축하고 있던 중, AWS Billing 대시보드를 검토하다가 예상보다 많은 비용이 발생하고 있는 것을 발견했습니다. Cost Explorer로 지난 3개월간의 비용 추이를 분석해보니 매월 약 15% 정도 비용이 증가하고 있었고, EC2 인스턴스와 관련 리소스들이 전체 비용의 80% 이상을 차지하고 있었습니다.문제 상황1. 높은 EC2 비용현재 prod 서버와 dev 서버를 모두 운영 중이었습니다. prod 서버는 m6g.medium($33.84), dev 서버는 t4g.medium($29.95) 인스턴스를 사용하고 있었는데, 월 EC2 비용만 $63.79가 발생하고 있었습니다.처음에는 dev 서버의 인스턴스 타입을 t4g.small로 다운그레이드하는 것을 고려했습니다...

들어가며지난 글에서 웹콘텐츠 창작자들을 위한 포트폴리오 서비스 LAITEU의 기획 배경과 전체적인 기술 스택에 대해 소개했습니다. 이번에는 "왜 MongoDB를 선택했는지", 그리고 "실제로 어떻게 데이터를 설계했는지"에 대해 이야기해보려 합니다.MongoDB, 무엇이 다른가?MongoDB를 설명하기 전에, 기존의 관계형 데이터베이스(RDBMS)와의 차이점부터 간단히 짚어보겠습니다.예를 들어 웹툰 작가의 작품을 저장한다고 생각해봅시다. 관계형 데이터베이스에서는 다음과 같은 테이블 구조가 필요할 것입니다:작품 테이블 (제목, 설명 등)작품 이미지 테이블 (이미지 URL, 순서 등)작품 태그 테이블 (태그 정보)작업 과정 테이블 (스케치, 선화, 채색 등의 단계별 정보)그런데 일러스트 작가의 경우는 어떨까요..

들어가며국내 웹콘텐츠 시장은 코로나19 이후 급격한 성장을 이루었고, 이에 따라 웹툰/웹소설/일러스트 작가부터 성우, 애니메이터, 역/식자, 편집자 등 콘텐츠 창작에 관여하는 창작자들의 수도 크게 증가했습니다. 하지만 시장의 성장 속도에 비해 체계적인 작업 과정과 분업화된 직무에 맞는 인력을 찾고 소통할 수 있는 플랫폼은 부재한 상황이었습니다.특히 창작자들의 소통은 주로 트위터나 카페 등에서 개별적으로 이루어지고 있었고, 작품이나 작업 과정을 아카이빙하기 위해서는 여러 플랫폼을 동시에 이용해야 하는 불편함이 존재했습니다. 게다가 구인구직을 위한 포트폴리오 제출 시에도 기존의 일반적인 포트폴리오 플랫폼들은 웹콘텐츠 창작자들의 특성을 제대로 반영하지 못했습니다.라이트(LAITEU)는 이러한 문제를 해결하기 ..