본문 바로가기

laravel3

[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.
[백엔드 설계] 관리자 CMS와 모바일 앱 API 코드를 처음부터 분리해야 하는 이유 웹이랑 앱, 서버를 같이 만지며 운영하다 보면 꼭 마주치는 상황이 있습니다. 바로 공지사항, 관광지 정보, 배너, 카테고리 같은 데이터를 관리자 CMS에서 등록하고, 모바일 앱에서 API로 조회해서 보여주는 구조입니다.처음에는 "어차피 똑같은 DB 데이터 긁어다 쓰는 건데 대충 같이 쓰면 안 되나?" 하고 Controller나 Query를 같이 재사용하고 싶어집니다. 코드가 줄어드니까 처음엔 속도가 빠른 것처럼 느껴지거든요. 하지만 이거 귀찮다고 대충 섞어 쓰면 나중에 운영 중에 무조건 사고가 터지거나 고치느라 고생하게 됩니다.관리자는 수정, 삭제, 내부 메모나 검수 상태 확인이 필요하지만, 앱은 외부 사용자가 보는 거라 공개 가능한 데이터만 안정적인 형태로 받아야 하기 때문입니다. 저도 자꾸 까먹고 실.. 2026. 5. 20.