오래된 시스템은 다시 빠르고 안전하게, 새 제품은 0 → 1로 만드는 Python·Django 백엔드 엔지니어

배경 · 문제

2018년부터 운영 요구에 맞춰 기능이 덧붙어 온 어드민(운영자용 관리 도구) 백엔드는 API 형식·시간 표기·권한 처리가 기능마다 달랐습니다. 같은 기능이 중복으로 등록돼 있고, 화면에 필요 없는 데이터까지 응답에 실려 나갔으며, 한국시간과 표준시(UTC)가 뒤섞여 시간이 잘못 표시되는 버그도 남아 있어, 새 기능을 붙일 때마다 같은 문제를 반복해 다뤄야 했습니다.

결정 · 구현

• API 응답 형식 표준화 — 화면에 실제로 필요한 데이터만 내려보내도록 응답을 정리해 불필요·민감 정보 노출을 없애고, 오류 응답 형식을 하나로 통일했습니다.
• 시간 표기 통일 — 모든 날짜·시간 값을 세계 표준시(UTC) 기준으로 통일하고, 한국시간으로 잘못 저장되던 데이터를 바로잡아 시간 오표시 버그를 제거했습니다.
• 회원 조회 성능 개선 — 회원 조회 API를 항목별로 분리하고 페이지네이션과 N+1 쿼리 제거를 적용해 조회 성능을 대폭 개선했습니다.
• 중복 · 레거시 정리 — 중복으로 등록돼 있던 레거시 관리자 API 경로 72개를 제거해 보안 위험과 혼선을 줄였습니다.
• 신규 관리 기능 개발 — 본인인증(KYC) 관리, 멤버십 표시 개편, 신고 게시글 일괄 숨김(대량 처리 속도 개선), 이용 제한 단계별 자동 승급과 변경 이력 기록을 새로 구현했습니다.

결과

흩어져 있던 어드민 백엔드를 하나의 일관된 체계로 재정비해 이후 기능 개발 속도와 유지보수성을 끌어올렸습니다. 특히 활동이 많은 회원 조회는 5초 이상 걸리던 응답을 300ms 이하로 줄였고(약 94% 단축), 응답 데이터 축소와 시간 표기 통일로 프론트엔드–백엔드 사이에서 반복되던 버그의 원인을 구조적으로 없앴습니다.

배경 · 문제

게시판을 넘어, 특정 주제나 브랜드(B2B) 단위로 운영되는 커뮤니티 공간 “스페이스”를 새로 출시해야 했습니다. 홈 노출·탐색·검색·운영자 도구까지 백엔드 전반을 새로 설계했고, 인플루언서(KOL)·코인 프로젝트·기업(B2B) 등 유형마다 동작이 달라 이를 아우르는 데이터 모델과 권한 설계가 필요했습니다.

결정 · 구현

• 커뮤니티 API 신규 설계 — 카테고리별 스페이스 목록, 홈 배너, 인기글·추천 스페이스, 내가 참여한 스페이스, 게시글 검색 등 필요한 기능 전반을 새로 만들었습니다.
• 목록 정확도 개선 — 글 목록을 여러 페이지로 나눠 불러올 때 같은 시각에 올라온 글이 누락되거나 중복되던 문제를 정렬 기준을 바로잡아 해결했습니다.
• 유형별 맞춤 로직 — 코인 프로젝트 스페이스 글에 관련 코인 정보를 자동으로 붙이고, 인플루언서 스페이스의 기본 탭·작성 권한을 구분했으며, 텔레그램 봇으로 올라온 글을 자동 등록했습니다. 기업(B2B) 스페이스에는 외부 콘텐츠를 자동 수집해 채우는 기능을 더했습니다.
• 다국어 · 운영 안정성 — 영문 번역 제공과 자동 번역 실패 시 원문 노출 처리, 운영 추적을 위한 로그 정비, 스페이스 수정 시 변경 이력 기록을 더했습니다.

결과

새 커뮤니티 제품을 백엔드에서 처음부터 설계·출시해, 일반 사용자와 기업(B2B) 양쪽을 모두 운영할 수 있는 구조를 확보했습니다.

배경 · 문제

포인트 후원을 하면 후원 표시 댓글이 자동으로 달려야 하는데, 월 최대 60%가 사라지고 있었습니다. 오류 알림 하나 없이 간헐적으로만 발생해 재현이 어려웠고, 2025년 8월 이후 10개월간 원인이 규명되지 않은 채 남아 있던 문제였습니다.

결정 · 구현

• 원인 규명 — DB 복제 지연 — 후원 저장은 원본 DB에서, 댓글을 다는 백그라운드 작업의 조회는 읽기 전용 복제 DB에서 일어나고 있었습니다. 복제 반영이 조금이라도 늦으면 방금 저장된 후원을 찾지 못해 조용히 실패한다는 것을 코드와 로그 추적으로 규명했습니다.
• 조회 경로 고정 — 후원 직후의 조회는 복제본이 아닌 원본 DB를 바라보도록 고정해, 복제 지연이 결과에 영향을 주지 못하게 했습니다.
• 커밋 후 발송 보장 — 후원 저장을 트랜잭션으로 묶고, 댓글·알림 발송은 저장이 완전히 끝난 뒤에만 실행되도록 순서를 보장했습니다. 그래도 실패하는 경우를 대비한 자동 재시도 안전망도 더했습니다.

결과

유실 원인을 구조적으로 제거해 배포 이후 재발 0건입니다. 이후 같은 원인으로 라이브 공지글 생성이 누락되던 문제가 발견됐을 때는 이 진단을 그대로 적용해 즉시 해결했습니다 — 한 번의 근본 해결이 같은 유형의 장애 대응 속도를 바꿨습니다.

배경 · 문제

webOS 기기의 펌웨어를 사용자가 USB나 서비스센터 없이 네트워크로 직접 업데이트(OTA)할 수 있어야 했습니다. 하지만 펌웨어 전체 용량이 약 2GB에 달해, 느린 가정용 네트워크에서는 다운로드에만 8시간가량 걸려 실사용이 어려웠습니다.

결정 · 구현

• 델타(차등) 업데이트 도입 — 기존 펌웨어와 새 펌웨어의 차이만 계산해 최소 용량의 경량 펌웨어를 생성하는 모듈을 개발했습니다.
• 펌웨어 보안 처리 — 암호화된 펌웨어를 기기에서 안전하게 복호화하는 모듈을 구현했습니다.
• 서버 통신 설계 — MQTT로 기기가 주기적으로 서버와 통신하며 새 업데이트 여부를 확인하도록 설계했습니다.
• 기존 자산 재활용 — 모바일 사업부의 델타 생성 도구를 webOS 환경에 맞게 이식해 개발 기간을 단축하고 범용성을 확보했습니다.

결과

업데이트 용량을 약 2GB에서 10MB 수준으로, 다운로드 시간을 8시간에서 20분 이내로 줄여, 느린 네트워크 환경에서도 안정적인 원격 업데이트를 가능하게 했습니다.