[트러블 슈팅]백엔드개발자가 프론트엔드와 협업하기

안녕하세요 개발자 왕라니입니당!!

 

백엔드 개발자가 되기 위해 열심히 공부하는 주니어 개발자분들 많으실 거라고 생각합니다!

 

백엔드에서 API 개발하면서 다들 다음 같은 생각 하셨을 것 같습니다.

음.. 응답 Json으로 이 정도 필드들이면 되겠지...? 에이 이런 간단한 계산은 프론트가 하겠지 ㅋ

 

혹시 저만 이런 생각했던 걸까요? ㅎㅎ..

 

백엔드 개발자 꿈나무만 60명 정도 모여서 학습을 하던 부트캠프 시절에선, 짧은 기간 안에 간단한 프로젝트를 하나씩 개발해내야 하다 보니 얼른 API 하나씩 완성하고 서버 측에서 안정적인지 확인하는 것에 초점을 맞추기 때문에 FE와의 협업을 생각해 본 적이 없던 것 같습니다.

 

개발자가 반드시 가져야 하는 소양인 "협업능력"이 중요하다는 것은 모든 개발자들이 알고 있을 겁니다.

 

그런데 협업은, 같은 서버를 개발하고 관리하는 백엔드 개발자끼리 Github에서 컨벤션 맞추기, PR 코드리뷰 규칙 정하기 등의 협업도 있겠지만, 프로젝트 차원에서 프론트엔드 개발자와의 협업도 반드시 존재하기에 이런 경험이 없으면 실무에서 상당히 난감하리라 생각이 듭니다.

 

저도 주니어 개발자로서 일하고 있지만, 서버 측 API 개발에 대한 부분만 집중하느라 FE와의 협업을 고려하지 못했었고, 어떻게 하면 BE - FE 사이에 유연하고 효율적인 협업이 가능할까.. 어떻게 하면 FE 개발자와 원만한 소통과 좋은 협업을 할 수 있을까 고민해 보았습니다.

 

그래서 내린 결론은...!!

내가 만든 백엔드 서버에 맞게 프론트엔드도 만들어보기

입니다. 제가 어느 정도 개발해 놓은 서버의 스펙에 맞게 잠시 프론트엔드 개발자가 되어 그 마음을 이해해보려 했습니다.

 

여기서 아마 의문이 드실 겁니다.

 "백엔드 개발자가 어떻게 프론트엔드 개발을 하게..?" 

 

사실 요즘 개발자 분들은 대충 감이 오실 겁니다. 제가 하려는 방식은 바이브 코딩이라고도 합니다.

 

요즘은 AI 모델이 개발에도 많이 특화되어 있기 때문에 개발자들이 빠르게 성장하고 빠른 결과를 낼 수 있게 되었습니다.

 

그래서 저는 바이브 코딩으로 AI와 함께 간단하고 빠르게 프론트엔드 부분을 개발해 보도록 했고, 개발 과정과 BE - FE을 연결하면서 깨달은 점에 대해서 말해보고자 합니다.

 

(참고로 저는 FE 개발자가 아니라 개발된 결과물의 퀄리티가 상당히 안 좋을 수는 있지만, 단순히 경험을 위해 작성한 아주 간단한 FE였으니 퀄리티는 눈감고 넘어가주시길 바랍니다🙇‍♀️🙇‍♂️)

 

1. FE 개발 스택 정하기

사실 저의 입장에선 뭘로 개발하느냐는 중요하지 않았습니다. 그래도 제가 개발 중인 프로젝트와 다양한 저의 환경에 따라 프론트부분을 개발할 수 있는 다양한 언어들 중 Next.js를 선택하였습니다.

 

선택한 근거는 다음과 같았습니다.

 

1. 빠른 구축(풀스택 개발에 유리함, 폴더기반 쉬운 라우팅)

2. SSR 

3. 입문이 쉬움

 

저의 입장에선 이 세 개가 매력적이었습니다. 이중 SSR 은 서버-사이드-렌더링의 약자로, 서버 측에서 클라이언트에게 HTML의 내용을 완성해 전송하게 됩니다.

이 부분이  좋았던 건, 나중에 이 웹 사이트가 다른 사람들에게 학습 및 정보전달로 알려지게 되기 쉽다는 것입니다.

 

CSR와 같은 클라이언트 측에서 HTML을 완성하는 형태의 웹사이트는 구글 검색 엔진에서 빈 페이지로 인식되는 경우가 많은 반면 SSR 방식의 웹사이트는 이미 HTML 내부에 웹 페이지가 가져야 할 정보들이  다 들어있기 때문에 검색엔진에 노출되기도 유리하다고 합니다.

 

저에겐 제 스스로의 학습, 그리고 그 학습내용의 기록하는 것도 중요하지만 제가 성장하면서 경험한 내용을 다른 사람도 같이 즐기고 느꼈으면 좋겠다는 생각으로 블로그 포스팅을 하고 있습니다.

 

하루에 2명 이하의 사람들이(사실상 0명에 수렴 중) 제 글을 봐주시고 있지만 점점 제 프로젝트가 개발되어 갈 때마다 읽는 분들이 필요로 한다면 서버도 배포하여 구경하고 이용할 수 있게 하는 것이 최종목표입니다!!

 

2. 내 BE 개발 상황 살펴보기

우선 웹에서 기본적인 소통을 담당하는 게시판 기능을 만들어 놓았습니다.

 

제 상상으로는, 메인 페이지에 들어가면 화면 중간에 게시글 목록이 있고 각각의 게시글을 클릭하여 내용을 볼 수 있는 전형적인 게시판을 상상하였습니다.

 

이걸 위해서 기본적으로 게시판 관련 CRUD 기능은 다음과 같습니다.

 

• 게시글 작성
• 게시글 수정
• 게시글 삭제(Soft Delete)
• 게시글 조회
  • 게시글 전체 조회(Soft Delete 제외, 이하 동일)
  • 내 게시글 전체 조회
  • 게시글 단건 조회
  • 특정 유저의 게시글 전체 조회

조회 관련 API가 많은 상황입니다. 다음 사진은 제 상상에서의 메인페이지 UI입니다.

구구는 제 프로필 사진중 펭귄역할을 담당하는 악당 분의 이름입니다.

대충 위와 같은 형태를 상상하였습니다.

 

우선 메인화면에서 게시글을 페이지네이션을 적용하여(한 번에 너무 많은 데이터를 불러오는 것을 방지) 리스트업 하고, 단건의 게시글을 들어가서 볼 수 있게 하고 싶었습니다.

 

일단 혼자 개발하는 작은 프로젝트이고, 지금 FE 부분은 제 상상에 맡긴 채로 BE 개발을 진행했기 때문에 전체 게시글 조회의 Response Entity에는 다음과 같은 필드들을 포함하게 했습니다.

// PostSummaryResponse.kt
{
    "title": "게시글 제목",
    "nickname": "왕란",
    "createdAt": "2025-05-01"
}

 

이렇게 메인화면에서 포함될 게시글 하나의 정보들을 3개의 필드로 정하고, Page에 List로 담아 return 하게 했습니다.(읽고 계신 분은 알 겁니다. 아주 중요한 정보를 빠트렸다는 것을..)

 

그렇게 했더니 위 사진과 같은 페이지를 구현하는데에 아무런 문제가 없었고 깔끔하게 리스트가 나오더군요. 그래서 상세 보기 버튼을 눌렀는데?

 

404... 가 나왔습니다. 뭐가 문제지?

(사실 이때, Spring Security의 필터 문제인가? 그럼 403 일 텐데 Post 객체를 프론트에서 만들어서 렌더링 하고 있는데 왜 안되지..라는 고민을 했습니다)

<button
  onClick={() => goToPost(post.id)}
  className="bg-blue-400 text-white px-3 py-1 rounded hover:bg-blue-500"
>
  상세보기
</button>

 

그리고 게시글 단건의 상세내용을 보기 위해 사용하는 API의 Controller 단의 작성된 내용은 다음과 같았습니다.

    @GetMapping("/posts/{postId}")
    fun getPostById(@PathVariable postId: Long): ResponseEntity<PostResponse> {
        val post = postService.getPostsById(postId)
        return ResponseEntity.ok(post)
    }

 

위 내용을 따르자면, 메인페이지에 있는 게시글의 ID 값을 가지고 /posts/{postId} 엔드포인트로 단건 조회 요청을 보내게 됩니다.

 

근데 백엔드에선 Post 객체를 다루는 중이고 이렇게 post.id를 가지고 요청을 하는데 왜 `/post/undefined`로 라우팅되고 있는 거지..?라고 생각했습니다.

 

그런데 정말 바보같이 메인페이지의 게시글 전체 조회를 했을 때 사용하고 있는 `PostSummaryResponse`의 json 필드값들이

제목, 작성자닉네임, 작성일 세 개밖에 없다는 걸 인지했습니다.

 

사실 메인페이지에선 단건 게시글 상세 보기 기능을 구현하지 않을 것이라면 이렇게 3개의 필드값만 return 하여도 문제없지만 메인페이지에서 바로 게시글 단건조회 API를 호출할 것이라면 Response에 ID 값도 넣어서 return 해야 하구나 라는 생각이 들었습니다.

 

여기서 느낀 점은,

프론트엔드와 개발 전 와이어프레임에 대해 충분히 회의하고 API 명세를 작성한 후 그것에 맞게 요청 - 응답을 설계해야겠다.

 

이런 생각이 들었습니다. 물론 당연한 이야기입니다. 하지만 제 프로젝트의 백엔드 개발을 혼자 하면서 상상으로 프로젝트를 설계하니 이런 말도 안 되는 문제를 내게 되었던 것입니다.

 

결론적으로..

대충 Post 객체를 보내니 프론트에선 필요한 정보만 갖다 쓰면 되겠지, 응답 Json에 대충 필드를 다 넣어주면 알아서 정제해서 쓰겠지.라는 이기적이고 막연한 생각을 접을 수 있었습니다.

 

이외에도 포스트맨으로 요청을 보내고 응답을 받아서 "아 제대로 동작하는구나~" 하고 넘어가는 것이 아닌 실제 서비스에서 어떻게 동작하는지, 프론트에선 어떻게 백엔드에서 return 한 정보를 사용하는지 좀 더 생각하면서 개발하게 된 계기가 된 것 같습니다.

 

저는 백엔드 개발자이기 때문에, 프론트엔드를 개발하는 역량 자체를 제 핵심 스킬로 키울 생각은 아직은 없습니다. 하지만 제가 좀더 테크니컬한 리팩토링을 진행하거나, 안정성, 성능개선을 진행하면서 테스트를 위해서 종종 프론트 부분의 개발도 진행해 보려고 합니다. (비율은 BE 5: FE 1 정도로 생각하고 있습니다. API 5개 개발하면 화면 구현하여 응답 속도, 반응 테스트 등등)

 

Next.js로 개발을 진행하니 저같이 한 번도 프론트 개발을 해본 적 없는 초보도 바이브 코딩으로 개발이 가능하고, BE - FE의 소통법, 프로젝트 설계법을 알 수 있어서 좋았던 것 같습니다.

 

제 글을 읽는 백엔드 개발자분이던 프론트엔드 개발자분이던 프로젝트 설계 단계에서 충분한 소통을 하고 문제없이 원활한 개발을 할 수 있으면 좋겠습니다.

 

읽어주셔서 감사합니다. 다음엔 인기 게시글을 캐싱하는 내용으로 돌아오겠습니다!!