프론트엔드 · 백엔드

프론트엔드란?

프론트엔드와 백엔드를 나눠 보기 시작하면 가장 먼저 바뀌는 것은 장애 신고가 도착하는 자리입니다. '주문이 안 돼요'라는 한 문장짜리 민원도, 버튼이 아예 눌리지 않은 것인지 눌렸는데 서버가 거절한 것인지에 따라 불러야 할 사람이 달라집니다. 실무에서는 브라우저에서 F12를 눌러 Network 탭을 보는 30초로 갈리는데, 요청이 서버까지 갔는지 여부가 첫 번째 갈림길입니다. 여기서 방향을 잘못 잡으면 엉뚱한 팀이 며칠을 씁니다.

둘의 경계는 대개 API라는 약속 지점에 놓입니다. 프론트는 '이 주소로 이런 값을 보내겠다', 백은 '이런 형식으로 답하겠다'를 미리 맞춰두고 각자 작업하기 때문에, 화면과 서버를 서로 다른 회사가 동시에 개발하는 일도 가능합니다. 응답 코드도 단서가 되는데, 400번대는 요청 쪽, 500번대는 서버 쪽 문제인 경우가 많습니다. 둘을 모두 다루는 사람을 풀스택이라 부르지만, 이는 혼자 다 해낸다는 뜻이 아니라 경계를 넘어 대화가 된다는 뜻에 가깝습니다.

일을 맡길 때도 이 구분이 견적서의 단위가 됩니다. '쇼핑몰 하나'가 아니라 '화면 18종과 API 24개'로 적으면 일정과 투입 인력이 계산되고, 중간 점검에서 어느 쪽이 밀렸는지 눈에 보입니다. 다만 백엔드와 서버·네트워크를 운영하는 인프라(데브옵스) 영역은 또 다릅니다. 사이트 접속 자체가 안 되는 장애는 코드가 아니라 서버 용량이나 도메인 설정 문제인 경우가 많아, 개발자에게 밤중에 전화할 일이 아닌 사안이 섞여 들어옵니다.

현장에서 가장 자주 어긋나는 지점은 '화면이 느리다=프론트 탓'이라는 짐작입니다. 목록이 늦게 뜨는 원인의 상당수는 데이터베이스 조회가 몇 초씩 걸리는 데 있고, 이때 이미지 용량을 줄이고 애니메이션을 걷어내도 체감 속도는 그대로입니다. 바이브 코딩에서도 같은 함정이 생깁니다. AI에게 화면만 시켜 그럴듯한 시안을 받고 시연까지 통과했는데, 새로고침하면 입력한 데이터가 사라지는 껍데기인 경우입니다. 발주서에 화면 개수만 적고 데이터를 어디에 저장하고 누가 검증하는지를 빼면, 오픈 직전에 일정과 예산을 처음부터 다시 짜게 됩니다.