Prologue

사실 저는 화면을 만드는 일도 많이 하지만,
지금 하는 작업들을 가만히 보면 이미 한참 전부터 백엔드와도 꽤 깊게 엮여 있었습니다.

예전에는 백엔드라고 하면 뭔가 거대한 서버, 복잡한 아키텍처, 낯선 용어부터 떠올랐습니다.
그런데 실제로 작업을 하다 보니 생각보다 더 현실적인 영역이더라고요.

데이터를 어디서 가져오는지, 누가 접근할 수 있는지, 어떤 값을 저장하고 어떻게 꺼내는지.
결국 서비스가 굴러가게 만드는 쪽 이야기였습니다.

백엔드는 멀리 있지 않을걸?

이거 아님

처음엔 저도 백엔드를 되게 멀게 봤습니다.

프론트는 눈에 보이니까 재밌고,
백엔드는 왠지 잘못 건드리면 큰일 나는 영역처럼 느껴졌습니다.

그런데 사이트를 직접 만들고 운영하기 시작하니까
백엔드는 특별한 사람이 따로 하는 일이 아니라
서비스를 만들다 보면 결국 만나게 되는 영역이었습니다.

예를 들어 이런 것들입니다.

• 로그인 처리
• 권한 확인
• 데이터 저장
• 수정 요청 검증
• 관리자 API 분리
• 세션 확인
• 업로드 처리
• 메일 발송
• 외부 서비스 연동

이런 건 화면만 잘 만든다고 해결되지 않습니다.
버튼을 눌렀을 때 실제로 무슨 일이 일어나는지가 더 중요해집니다.

그때부터 백엔드는 “어려운 다른 세계”가 아니라
내가 만드는 서비스의 뒤쪽 구조로 보이기 시작했습니다.

내 기준 백엔드

제가 생각하는 백엔드는 거창하지 않습니다.

일단 제 작업 기준으로 보면 백엔드는 대체로 이런 쪽입니다.

항목	내용
인증	로그인, 세션, 접근 제한
데이터	조회, 저장, 수정, 삭제
검증	잘못된 요청 차단
권한	관리자, 사용자 구분
연결	DB, 메일, 스토리지, 외부 API
안정성	에러 처리, 예외 대응

이걸 보면 화려한 영역은 아닙니다.
오히려 되게 현실적입니다.

프론트가 “어떻게 보일까”에 가깝다면,
백엔드는 “그래서 실제로 되게 만들 수 있나”에 더 가깝습니다.

예쁜 화면은 눈에 바로 들어오지만,
백엔드는 잘 만들수록 오히려 존재감이 적습니다.
문제 없이 돌아가면 조용하고, 터지면 바로 티가 납니다.

그래서 더 중요합니다.

화면 뒤에서 진짜 일어나는 일

이런 일은 일어나지 않아요(....)

버튼 하나를 눌렀다고 끝이 아닙니다.

예를 들어 사용자가 “저장” 버튼을 누르면
백엔드에서는 생각보다 많은 걸 확인해야 합니다.

1. 로그인한 사용자인지
2. 이 요청을 보낼 권한이 있는지
3. 값이 비어 있거나 이상하지 않은지
4. 저장 대상이 실제로 존재하는지
5. DB에 넣어도 되는 형식인지
6. 실패했을 때 어떤 응답을 줄지

화면에서는 버튼 한 번입니다.
그런데 뒤에서는 꽤 많은 확인이 돌아갑니다.

그래서 백엔드는 “기능의 뒷부분”이 아니라
사실상 기능이 실제로 성립하게 만드는 본체에 가깝습니다.

겉으로는 조용한데,
실제로는 뒤에서 제일 바쁘게 일하는 쪽이라고 느낍니다.

직접 만들수록 더 체감하는 것

백엔드를 직접 만지면 가장 먼저 느끼는 건
아무 값이나 믿으면 안 된다는 점입니다.

처음에는 프론트에서 입력값 잘 막아두면 괜찮아 보입니다.
그런데 조금만 생각해보면 그걸로 끝이 아닙니다.

사용자는 예상과 다르게 입력할 수 있고,
요청은 우회해서 들어올 수도 있고,
프론트가 멀쩡해 보여도 서버에서는 다른 문제가 생길 수 있습니다.

그래서 백엔드에서는 자꾸 이런 생각을 하게 됩니다.

• 이 값은 진짜 안전한가
• 이 요청은 믿어도 되는가
• 이 유저가 이 작업을 해도 되는가
• 실패하면 어디서 막아야 하는가
• 나중에 문제 생기면 추적 가능한가

이런 고민들이 쌓이면서
백엔드는 단순 구현보다 판단의 영역이 크다는 걸 느끼게 됩니다.

코드 몇 줄보다
어디서 막을지, 어디서 허용할지, 어디까지 신뢰할지가 더 중요해집니다.

프론트와 백엔드는 절친 관계

진짜 반가워서 이러는 거 마즘

개발을 하다 보면 프론트와 백엔드를 완전히 분리해서 생각하기가 어렵습니다.

왜냐하면 프론트에서 편하게 쓰고 싶은 구조가
백엔드 응답 형식에 영향을 주고,
백엔드의 권한 구조가
프론트 화면 흐름을 바꾸기도 하기 때문입니다.

예를 들면 이런 식입니다.

• 프론트에서 한 번에 뿌리기 좋게 응답 구조 설계
• 수정/삭제 버튼 노출 조건과 권한 로직 연결
• 목록 화면 정렬 기준과 DB 필드 설계 연결
• 에러 메시지와 사용자 경험 연결

즉, 프론트는 겉면이고 백엔드는 속이라는 식으로
깔끔하게 반 나누기 어렵습니다.

실제로 서비스 만들 때는 둘이 계속 얽힙니다.
그래서 저는 백엔드를 볼 때도
단순히 서버 코드만 보는 게 아니라
서비스 흐름 전체 안에서 같이 보게 됩니다.

Epilogue

참 쉽죠?

예전에는 백엔드를 어려운 영역으로만 봤는데,
지금은 오히려 서비스의 중심에 더 가깝다고 느낍니다.

화면은 눈에 보이지만,
서비스를 실제로 굴러가게 만드는 쪽은 결국 뒤에 있습니다.

그래서 백엔드 카테고리 첫 글도
대단한 기술 이야기보다
제가 백엔드를 어떻게 보게 됐는지부터 남기고 싶었습니다.

앞으로 이 카테고리에서는
거창한 설명보다 실제 작업에 가까운 이야기들을 하나씩 정리해보려고 합니다.

화면 뒤에서 진짜 일이 벌어지는 곳.
제 기준의 백엔드는 대충 그런 쪽입니다.