본문 바로가기

개발 노트/Backend,CMS,API8

[Backend] API 파일 및 이미지 업로드 보안 검수 기준 가이드 웹이나 앱 서비스를 개발하고 운영하다 보면 프로필 이미지, 게시글 첨부파일, CMS 배너 등 파일을 업로드하는 기능을 구현할 일이 정말 많습니다. 처음에는 그냥 파일 받아다가 특정 폴더에 저장하면 끝나는 간단한 기능처럼 보이지만, 막상 운영하다 보면 보안적으로 신경 쓸 부분이 한두 가지가 아닙니다.가장 위험한 실수는 클라이언트가 보낸 파일명, 확장자, MIME 타입을 그대로 믿고 서버에 저장하는 것입니다. 자칫하면 이미지가 아니라 실행 파일이 올라와 서버가 털리거나, 내부 경로가 노출되고, 너무 큰 파일 때문에 서버 디스크가 꽉 차는 장애가 생길 수도 있습니다.정상적인 요청만 들어오면 참 편하겠지만, 실무에서는 항상 악의적인 입력이나 예외 상황을 먼저 막아야 하더군요. 나중에 다른 프로젝트 할 때도 까먹.. 2026. 5. 21.
[Backend] 웹 관리자 CMS 인증과 모바일 앱 토큰 인증 확실하게 분리하기 웹 관리자 화면(CMS)과 모바일 앱 API를 한 서버 안에서 같이 개발하는 경우가 많습니다. 관리자 화면은 운영자가 브라우저로 로그인해서 데이터를 등록하고 수정하는 공간이고, 앱 API는 모바일 앱이 공개 데이터나 사용자별 데이터를 조회하는 인터페이스입니다.둘 다 인증이 필요하긴 한데, 목적과 방식이 완전히 다릅니다. 이걸 대충 섞어서 개발하면 나중에 보안 경계가 흐려지고, 에러 처리할 때 앱이 오작동하는 큰 문제가 생깁니다.처음에는 같은 서버에서 같은 유저 테이블(User Table)을 쓰니까 인증도 비슷하게 처리하면 되겠지 싶지만, 운영하다 보면 기능과 오류 처리 방식이 완전히 달라서 Route 단계부터 철저하게 분리해야 안전합니다. 저의 경우에도 예전에 이 경계를 모호하게 잡았다가 고생했던 기억이.. 2026. 5. 21.
모바일 앱 API 오류 응답 형식을 하나로 고정해야 하는 이유와 설계 방법 (Laravel 예시) 웹과 모바일 앱 API를 같이 개발하고 운영하다 보면, 성공 응답은 data, meta, pagination 같은 구조를 예쁘게 잘 맞춥니다. 앱 화면에서 바로 쓰기 좋은 형태로 신경을 많이 쓰죠.그런데 오류 응답은 생각보다 뒤로 밀리기 쉽습니다. 저의 경우도 처음에는 대충 에러 메시지만 던져줬다가, 앱 쪽에서 예외 처리가 자꾸 꼬이는 문제를 겪었습니다. 어떤 API는 message로 오고, 어떤 API는 error로 오고, 서버가 터지면 HTML 오류 페이지가 날아오니 앱 인터셉터(Interceptor)에서 공통 처리를 만들기가 불가능하더군요.앱 API에서 오류 응답은 하나의 '계약'입니다. HTTP status만 맞추는 걸로 끝내면 안 되고, 앱이 화면 안내, 재로그인, 필드별 에러 표시, 재시도 같.. 2026. 5. 21.
[Next.js 전환] 기존 Backend/CMS를 Next.js로 바꿀 때 앱 API 경계 유지하는 방법 이래저래 서비스를 운영하다 보면, 기존 Laravel(PHP)로 되어 있는 백엔드나 CMS 프로젝트를 Next.js로 전환하고 싶을 때가 있습니다.저의 경우도 최근 관리자 CMS 화면을 Next.js로 바꾸고 앞단에 BFF(Backend For Frontend)를 두는 구조를 검토했었는데요. 이때 가장 헷갈리고 조심해야 하는 부분이 바로 화면과 앱 API 사이의 경계를 어디서 나눌지 정하는 일입니다.화면 바꾸는 김에 API 구조도 싹 정리하면 깔끔할 것 같지만, 실제 운영해보면 화면 전환과 앱 API 계약 변경은 완전히 다른 문제입니다. 이미 배포된 모바일 앱은 사용자들이 바로 업데이트를 안 하기 때문에, 응답 필드 하나만 잘못 바꿔도 구버전 앱에서 바로 크래시가 나거나 장애로 이어집니다.기존 앱 API.. 2026. 5. 21.
[Backend] API 캐시(Cache)와 레이트 리밋(Rate Limit) 적용할 때 놓치는 실무 운영 기준 정리 웹이든 앱이든 서버를 같이 만지며 운영하다 보면, 같은 콘텐츠를 여러 사용자가 반복해서 조회하는 상황을 자주 보게 됩니다. 공지사항, 배너, 카테고리 목록 같은 공개 데이터는 매번 DB에서 무겁게 긁어올 필요가 없죠. 이럴 때 캐시를 적절히 붙여주면 응답 속도도 빨라지고 DB 부하도 크게 줄일 수 있습니다.반대로 시스템을 보호하는 고민도 해야 합니다. 봇이 들어와서 목록 API를 과도하게 긁어가거나, 특정 검색 API를 짧은 시간에 마구 호출하면 서버 자원이 금방 바닥납니다. 이때는 Rate Limit(요청 제한)을 걸어서 필터링을 해줘야 합니다.처음에는 '캐시는 빠르게 만드는 기능, 레이트 리밋은 과도한 요청을 막는 기능' 정도로 쉽게 생각하기 쉬운데요. 실무에서 기준 없이 대충 붙였다가는 오히려 데이.. 2026. 5. 21.
[Backend] 앱 API 목록 조회 설계 기준 정리 (Pagination, Filter, Sort Allowlist) 앱 Backend API를 만들 때 목록 조회는 정말 숨 쉬듯 만드는 기능입니다. 공지사항, 게시글, 배너, 관광지 목록 등 화면에 뿌려주는 데이터의 90%는 목록이니까요.처음에는 그냥 page, keyword 정도만 대충 받아서 넘겨도 잘 돌아가는 것처럼 보입니다. 하지만 서비스가 조금만 커지면 정렬 기준이 추가되고, 카테고리나 지역 필터가 붙고, 관리자 상태값 처리까지 뒤엉키면서 API마다 파라미터 이름과 응답 구조가 제각각이 되기 일쑤입니다.저의 경우에도 혼자서 서버와 앱을 같이 만지다 보니, 초기에 기준을 안 잡아두면 나중에 프론트엔드 코드 짤 때 공통 처리가 안 돼서 고생하곤 했습니다. 자꾸 까먹고 놓치는 부분이 많아서 실무에 바로 적용할 수 있도록 기준을 정리해 둡니다.1. 내가 겪었던 문제들.. 2026. 5. 20.

티스토리툴바