프런트엔드3 프런트엔드 백엔드 협업 (API 명세, 역할 분리, 커뮤니케이션) 프런트엔드와 백엔드가 각자 맡은 코드만 잘 짜면 된다고 생각했다면, 그건 저도 처음엔 그랬습니다. 하지만 실제 서비스 흐름을 직접 들여다보니 그 생각이 완전히 틀렸다는 걸 금방 알게 됐습니다. 하나의 기능이 사용자 앞에 멀쩡히 서 있으려면, 화면과 서버가 정확한 규칙으로 끊임없이 대화해야 합니다.프런트엔드 백엔드 협업, API 명세: 협업이 무너지는 지점은 항상 여기였습니다일반적으로 프런트엔드는 화면을, 백엔드는 서버를 담당한다고 알려져 있습니다. 저도 처음엔 그 정도로만 이해하고 공부를 시작했습니다. 그런데 막상 로그인 기능 하나를 놓고 흐름을 따라가 보니, 두 영역이 얼마나 촘촘하게 얽혀 있는지 실감했습니다.사용자가 아이디와 비밀번호를 입력하고 버튼을 누르는 순간, 프런트엔드는 그 값을 서버로 전송합.. 2026. 5. 17. 풀스택 개발자 (서비스 흐름, 핵심 역량, 실전 준비) 풀스택 개발자를 준비하는 분들의 포트폴리오와 모의면접 답변을 점검하다 보면 프런트엔드와 백엔드를 모두 해봤다는 말은 하지만, 실제 서비스 흐름을 하나로 연결하지 못하는 경우를 자주 봅니다. 어떤 준비생은 React 화면과 Spring API를 모두 만들었다고 했지만 버튼을 누른 뒤 요청이 서버로 전달되고 데이터베이스에 저장된 뒤 다시 화면에 반영되는 흐름을 설명하지 못했습니다. 또 다른 준비생은 로그인, 게시판, 배포까지 경험했다고 적었지만 GitHub README에는 화면 캡처만 있고 API 명세, DB 구조, 오류 해결 기록은 빠져 있었습니다. 저는 이 지점이 풀스택 개발자 준비에서 가장 아쉬운 부분이라고 생각합니다. 중요한 것은 여러 기술을 넓게 나열하는 것이 아니라, 서비스 흐름을 이해하고 핵심 .. 2026. 5. 4. 서버와 클라이언트 관계(요청과 응답, 프런트엔드, 백엔드) 팀 프로젝트에서 게시글 저장 버튼을 눌러도 데이터가 등록되지 않는 문제를 함께 검토한 적이 있습니다. 프런트엔드 담당자는 서버가 응답하지 않는다고 생각했고, 백엔드 담당자는 화면에서 요청값을 잘못 보냈다고 판단했습니다. 두 사람 모두 자신의 코드만 확인하면서 상대 영역의 문제라고 생각했지만 브라우저의 네트워크 기록을 열어 실제 요청과 응답을 비교하지는 않았습니다. 요청 본문을 확인해 보니 화면에서는 게시글 제목을 title이라는 기준으로 보냈지만 서버에서는 다른 항목명을 기다리고 있었습니다. 서버는 필수값이 없다는 오류를 반환하고 있었지만 화면에서는 모든 실패를 같은 문구로 처리해 원인을 알기 어려웠습니다.이 사례에서 필요한 것은 화면 코드와 서버 코드 중 어느 쪽이 더 잘못됐는지를 따지는 일이 아니었습.. 2026. 4. 27. 이전 1 다음
