프로젝트에서 보기 →

프론트엔드 개발자가 백엔드 개발자에게 바라는 점

태그
기타 개발자 코딩 프론트엔드
시작일
종료일
수정일

https://www.youtube.com/watch?v=1ScgKKan6eQ

description: |-

1. 이건 꼭 알아야 한다^1

이 콘텐츠는 프론트엔드 개발자가 협업 과정에서 경험하는 불편과 기대를 바탕으로, 백엔드 개발자에게 바라는 협업 방식이 무엇인지(특히 “싫은 백엔드” vs “같이 일하고 싶은 백엔드”의 차이)를 구체 사례로 설명한다.^1

[? 질문] 프론트엔드 개발자가 백엔드 개발자에게 가장 아쉬워하는(싫어하는) 행동은 무엇인가[^2]
[= 답] API/인터페이스 변경 사항을 해놓고 프론트에 공유하지 않는 것(상태 코드, 응답 프로퍼티 등 변경을 “바꿔놓고 안 알려주는” 상황)이 가장 큰 스트레스이며, 배포 직전/직후에 이런 일이 발생하면 프론트는 뒤늦게 깨닫고 디버깅 비용을 치르게 된다.[^6]

[? 질문] 프론트엔드 개발자가 “같이 일하고 싶다”고 느끼는 백엔드 개발자는 어떤 사람인가[^7]
[= 답] 변경/흐름을 사전에 투명하게 공유하고, 단순히 말로만이 아니라 플로우차트 등으로 전체 흐름(Flow)까지 전달해서 프론트가 시행착오를 피하도록 돕는 개발자다.[^7]

[? 질문] 백엔드는 프론트의 작업 부담을 어떤 방향으로 줄여줄 수 있는가[^9]
[= 답] 프론트에서 불필요한 “연상 작업/가공 작업”을 많이 하지 않도록, 프론트가 화면/기능 구현에 집중할 수 있는 형태로 API를 제공하고, 에러메시지/에러 케이스를 명확히 내려주는 것이 도움 된다.[^9]

2. 큰 그림^1

이 영상은 “프론트엔드 개발자 관점에서 백엔드 개발자에게 바라는 점/아쉬운 점”을 토크 형식으로 풀어낸 짧은 협업 커뮤니케이션 콘텐츠다.^1 특히 실무에서 자주 터지는 API 변경 공유 누락, 배포 시점의 혼선, 에러 처리의 불명확성, 책임 전가성 발언(프론트에서 해줄 수 있잖아) 같은 상황을 사례로 든다.[^3]

  • 프론트 입장에서 가장 큰 문제는 **“바꿔놓고 말 안 하기”**이며, 이는 디버깅 비용과 일정 리스크로 직결된다.[^6]
  • “좋은 백엔드”는 변경점만 던지는 수준이 아니라, 전체 흐름(Flow)과 의도를 구조적으로 공유해 프론트가 안전하게 구현하도록 만든다.[^7]
  • 협업의 질은 “누가 더 할 수 있냐”가 아니라, 서로의 역할 경계를 존중하며 인터페이스 계약을 관리하는 데서 결정된다.[^12]

3. 하나씩 살펴보기^1

3.1 주제 소개: “백엔드에게 바라는 점/아쉬운 점”을 프론트 관점에서 말해보자^1

📸 0:00

영상은 진행자가 “이런 시간에는 … 백엔드에게 바라는 점 혹은 아쉬운 점을 이야기해보는 시간을 가져온다”는 식으로 토크 주제를 연다.^1 즉, 단순 기술 튜토리얼이 아니라 협업 경험에서 나온 불만/개선 포인트를 공유하는 콘텐츠임을 먼저 밝힌다.^1

이어 진행자는 프론트엔드 관점에서 “같이 일하고 싶어지는 요소”가 있을 것이고, 그런 점들이 무엇인지 말해달라고 요청한다.[^2] 이때부터 출연자는 ‘싫은 유형’과 ‘좋은 유형’을 대비시키며 구체 사례를 든다.[^2]

3.2 프론트가 정말 싫어하는 유형 1: 배포 직전/직후에 API가 달라져 있고, 공유가 없는 경우[^3]

📸 0:30

출연자는 “제가 정말 싫어하는 것은 … 서버에 배포하는 백엔드 개발자”라는 식으로, 배포 시점과 맞물린 커뮤니케이션 부재를 강하게 문제 삼는다.[^3]

그 맥락은 대략 다음과 같이 전개된다.

  • 프론트는 프론트 나름대로 이미 “준비해놨을” 수 있다(기능 구현, 연동 코드 작성, 테스트 준비 등).[^3]
  • 그런데 실제 환경에서 호출해보면 “API … 늦어 …”처럼(표현은 거칠지만) 예상과 다른 동작/응답이 발생하면서 문제가 드러난다.[^4]
  • 프론트는 연동 과정에서 “말도 안 되는 것 같은데요”라는 느낌을 받지만, 결국 확인하다 보면 백엔드 쪽에서 뭔가를 바꿔 올렸고(배포했고), 그 사실을 프론트가 전달받지 못한 상태였다는 결론으로 이어진다.[^4]

여기서 핵심 불만은 “바뀌었을 수 있다”가 아니라, 바뀐 사실을 안 알려준다는 점이다.[^5]

[? 질문] 왜 “배포 직전/직후 변경 공유 누락”이 프론트에 치명적인가[^4]
[= 답] 프론트는 자신이 작성한 코드가 틀렸다고 가정하고 시간을 들여 추적하지만, 실제 원인은 인터페이스 변경일 수 있어 불필요한 디버깅과 일정 지연을 만든다(특히 배포 타이밍이면 더 큰 혼선이 된다).[^4]

3.3 프론트가 정말 싫어하는 유형 2: 상태 코드/응답 프로퍼티를 바꿔놓고 안 알려주는 백엔드[^5]

📸 0:51

출연자는 싫은 사례를 더 구체화한다. “뭐 바꿔놓고 안 가르쳐 주는 … 개발자 싫고요”라고 하며, 나중에 돌려보니 안 되는 걸 알게 되는 상황을 말한다.[^5]

특히 다음 같은 “인터페이스 계약” 요소들이 갑자기 달라지는 경우를 든다.

  • “갑자기 상태 코드가 … 변경되어 있다”[^6]
  • “(응답) 프로퍼티가 … (달라졌는데) 안 가르쳐 준다”[^6]

즉 프론트엔드가 의존하는 것은 단지 엔드포인트 URL만이 아니라,

  • 어떤 상태 코드로 성공/실패를 구분하는지
  • 실패 시 어떤 에러 바디/메시지가 오는지
  • 응답 JSON의 필드(프로퍼티) 이름/형식이 무엇인지
    같은 API의 계약(Contract) 전반인데, 이를 일방적으로 바꿔놓고 공유가 없으면 프론트는 “원인이 내 코드인지, 서버인지”를 한참 헤매게 된다.[^6]

[h 이 파트에서 영상은 “프론트가 싫어하는 백엔드”의 핵심을 ‘기술력 부족’이 아니라 ‘변경 커뮤니케이션 부재’로 잡는다.] [^6]

3.4 같이 일하고 싶은 백엔드: 변경을 ‘전부’ 알려주고, 흐름(Flow)까지 공유하는 사람[^7]

📸 1:11

출연자는 “반대로 좋은 백엔드 개발자는 그런 걸 다 알려주셔서 …”라고 하며, 이상적인 협업 방식을 제시한다.[^7]

여기서 ‘좋은 백엔드’의 특징은 단계적으로 묘사된다.

  1. 변경 사항을 모두 공유한다
    “그런 걸 다 알려주셔서”라는 표현처럼, 상태 코드/프로퍼티 등 연동에 영향 있는 변경을 숨기지 않고 전달한다.[^7]

  2. 프론트가 “피하게” 만든다(함정을 피하도록)
    출연자는 공유의 목적을 단순 알림이 아니라 프론트가 시행착오를 피하도록 돕는 것이라고 말한다.[^7]

  3. 흐름까지 공유하고, 심지어 플로우차트까지 제공한다
    “이 흐름까지 다 … 플로우차트 까지 공유”라고 말하며, 단편적인 API 스펙 전달을 넘어 기능/상태 전이/예외 케이스를 구조적으로 보여주는 커뮤니케이션을 높게 평가한다.[^7]

그 결과 출연자는 그런 백엔드가 있으면 “데려오고 싶다”는 표현으로 협업 선호를 강하게 드러낸다.[^8]

[!TIP] “스펙 전달”보다 강력한 것은 “흐름 전달” 프론트는 화면 단에서 사용자 액션 → 요청 → 응답 → 상태 변화로 이어지는 전체 시나리오를 구현한다. 그래서 엔드포인트 목록만 주는 것보다, 플로우차트/시퀀스/상태도로 “정상/예외 흐름”을 공유하면 연동 비용이 크게 줄어든다는 메시지를 이 영상은 강조한다.[^7]

3.5 에러 메시지/에러 케이스: “뜬금없는 서버 에러” 대신, 프론트가 이해 가능한 형태로 내려달라[^8]

📸 1:24

출연자는 또 다른 불만으로 에러 메시지의 불명확성을 언급한다.[^8]

영상의 표현은 다소 거칠고 음성 인식이 매끄럽지 않지만, 요지는 다음 흐름으로 이해된다.

  • 프론트에서 볼 때 “없는 에러메세지”, “뜬금 없는 모양(의) 서버 에러”처럼 원인을 파악하기 어려운 에러가 떨어지는 경우가 있다.[^8]
  • 이런 케이스가 있으면 사실상 프론트는 추측/역추적을 해야 하고, 원인이 백엔드에 있어도 프론트는 “선뜻 … 달라고(수정해달라고) 말을 못”하는 상황이 생긴다.[^9]
  • 그래서 이상적인 백엔드는, 프론트가 요청했을 때(혹은 요청하기 전에) 먼저 나서서 “제가(내가) 보면 될 것 같다”는 식으로 문제를 확인하고 정리해주는 태도가 좋다고 말한다.[^9]

[m 여기서 ‘좋은 태도’는 단지 친절이 아니라, 에러를 ‘누가 고치냐’가 불명확할 때 협업 비용을 줄이는 행동으로 제시된다.] [^9]

3.6 프론트의 “연산/가공 작업”을 최소화해주는 API/역할 분담에 대한 기대[^9]

📸 1:43

출연자는 협업에서의 역할 분담 감각도 언급한다. “프론트엔드에서 하는 … 연상 작업(가공/처리)을 최소화”해주는 것이 좋다는 취지로 말한다.[^9]

이 말의 결은 다음과 같다.

  • 프론트는 UI/UX 구현과 상태 관리만으로도 일이 많다.
  • 그런데 백엔드 응답이 불친절하거나(의미 없는 에러), 일관성 없거나(필드/상태코드 제각각), 프론트가 쓸데없이 “맞춰주는” 로직을 많이 넣어야 하면 프론트 코드가 복잡해진다.[^9]
  • 따라서 “그냥 … 상태 … 그런 것만 할 수 있도록 만들어 주는 게 좋은” 협업이라고 말한다(프론트가 본연의 역할에 집중하도록).[^10]

[!IMPORTANT] 영상이 말하는 포인트(뉘앙스) “프론트에서 할 수 있잖아”가 아니라, 프론트가 굳이 안 해도 되게 인터페이스/에러/흐름을 설계하고 공유해달라는 요청이다.[^10]

3.7 진행자의 정리: “존나 패고 싶은 백엔드” 유형을 항목으로 재진술[^11]

📸 2:23

중후반부에서 진행자는 출연자의 말을 받아 “말씀해주신 … 백엔드 개발자 분들을 … 정리”하듯 다시 나열한다.[^11]

진행자가 언급하는 정리 포인트는 크게 두 가지로 읽힌다.

  1. “자기 인터페이스가 … 변경을 놓고 알려주지 않는 개발자”
    즉, 인터페이스 변경 공지 누락이 1번 문제로 재확인된다.[^11]

  2. 프론트/백엔드가 “서로 연산 작업을 … 가져갈까” 결정해야 하는데, 그 과정에서
    “프론트에서 해줄 수 있는 거 아니야”라고 말하는 개발자
    즉, 역할 협의 대신 책임 전가/일방적 요구처럼 들리는 커뮤니케이션을 문제로 지적한다.[^12]

여기서 진행자는, 프론트와 백엔드 사이에는 “어떻게 보면 서로 연산 작업을 가져갈까 하는 결정”의 갈림길이 늘 존재한다고 전제한다.[^12] 즉 경계가 완전히 고정된 것이 아니라, 프로젝트/상황에 따라 어디서 처리할지 협의가 필요한데, 그 협의가 무너지면 갈등이 생긴다는 관점이다.[^12]

[? 질문] “프론트에서 해줄 수 있는 거 아니야?”가 왜 문제로 언급되는가[^12]
[= 답] 해야 할 일을 조율하는 대신, 프론트의 부담과 맥락을 무시한 채 일방적으로 떠넘기는 말로 들리기 쉽고, 결과적으로 협업 관계를 악화시키는 행동으로 인식되기 때문이다.[^12]

3.8 마무리: 말이 적을 수도 있지만, 감사 인사와 종료[^13]

📸 2:56

진행자는 대화가 “되게 말씀이 없네요”처럼(토크 분량/리액션에 대한 농담성 언급으로 보임) 지나가지만, 어쨌든 협업에서 겪는 불만은 “사실 모르는 거죠”라는 식으로 정리한다.[^13] 즉, 상대가 의도적으로 괴롭힌다기보다 서로의 맥락을 몰라서 생기는 문제일 수 있음을 살짝 열어둔다.[^13]

마지막으로 출연자에게 감사 인사를 하고 영상은 “오늘은 여기서 마무리… 다음 시간에 만나요”로 끝난다.[^13]

4. 핵심 통찰[^6]

  1. [c 프론트가 가장 힘들어하는 것은 ‘실수’가 아니라 ‘무통보 변경’이다.] 변경 자체보다, 상태 코드/프로퍼티 등 계약이 바뀌었는데 공유가 없어서 프론트가 원인 분석에 시간을 쓰게 되는 구조가 문제로 제시된다.[^6]
  2. [h 좋은 백엔드는 스펙을 던지지 않고 ‘흐름’을 공유한다.] 플로우차트까지 제공하며 정상/예외 흐름을 전달하면 프론트는 구현과 디버깅을 훨씬 안정적으로 할 수 있다고 말한다.[^7]
  3. [h 에러는 “뜬금없게” 오면 협업 비용이 폭증한다.] 프론트가 이해 가능한 에러 메시지/케이스가 없으면 추측과 핑퐁이 늘고, 프론트는 수정 요청조차 조심스러워지는 상황이 생긴다.[^8]
  4. [m “프론트에서 해줄 수 있잖아”는 역할 협의 실패의 신호다.] 어디서 처리할지는 협의의 문제인데, 이를 압박/책임 전가처럼 말하면 프론트 입장에서 ‘같이 일하기 싫은’ 유형이 된다.[^12]

실행 관점에서 영상이 암묵적으로 요구하는 행동은 다음처럼 정리할 수 있다.[^7]

  • API 변경 시 프론트에 사전 공지하고, 배포 시점에는 특히 변경 내역을 명확히 남긴다.[^6]
  • 단순 문장 공유가 아니라 플로우차트/시퀀스/시나리오로 정상/예외 흐름을 전달한다.[^7]
  • 에러 응답을 일관된 포맷과 의미 있는 메시지로 설계해 프론트가 원인 파악을 할 수 있게 한다.[^8]

5. 헷갈리는 용어 정리 (해당 시에만)[^6]

API: 프론트엔드가 서버에 요청하고 응답을 받기 위해 사용하는 인터페이스(엔드포인트, 요청/응답 형식, 상태 코드, 필드 구조 등 “계약” 전반).[^6]
상태 코드(Status Code): HTTP 응답의 성공/실패를 나타내는 코드(예: 200, 400, 500 등). 영상에서는 이것이 “갑자기 변경”되는 상황이 문제로 언급된다.[^6]
프로퍼티(Property): JSON 응답 등에 포함되는 필드/키. 영상에서는 이 구조가 바뀌는데 공지가 없는 경우를 싫은 사례로 든다.[^6]
플로우차트(Flowchart): 요청-응답, 처리 단계, 예외 분기 등을 도식화한 흐름도. “좋은 백엔드”가 공유해주면 협업이 쉬워진다고 말한다.[^7]

참고(콘텐츠 정보)^1

  • 제목: 프론트엔드 개발자가 백엔드 개발자에게 바라는 점^1
  • 채널: 딩코딩코^1
  • 길이: 3분 21초^1
  • 링크: https://www.youtube.com/watch?v=1ScgKKan6eQ^1

[^2]: @[00:12] "…얘기해 보는 시간을…"; @[00:25] "…어떤게 있어… 말씀해 주실 수 있나요" [^3]: @[00:30] "제가 정말 싫어하는 것은… 서버에 배포하는… 백엔드 개발자…" [^4]: @[00:34] "…실제에서 api… (문제)…"; @[00:39] "…말도 안되는 것 같은데요"; @[00:44] "…하다보면… 올리게 됩니다" [^5]: @[00:51] "뭐 바꿔놓고 안가르쳐 주는…"; @[00:59] "…나중에 돌려 보니까 안되는걸…" [^6]: @[00:59] "갑자기 상태 코드가… 변경…"; @[01:05] "…프로퍼티… 안가르쳐 준다" [^7]: @[01:11] "…그런걸… 다 알려주셔서…"; @[01:11] "…흐름까지… 플로우차트 까지 공유…" [^8]: @[01:24] "…없는 에러메세지…"; @[01:30] "…뜬금 없는… 서버 에러…"; @[01:38] "…케이스들이 있어요" [^9]: @[01:43] "…선뜻… 말을 못하잖아요"; @[01:45] "…먼저 나서…"; @[01:46] "…프론트엔드에서 하는… 작업들을 최소화…" [^10]: @[01:53] "…그냥… 상태… 그런 것만 할 수 있도록 만들어 주는 게…" [^11]: @[02:23] "…정리… 말씀해주셨어요"; @[02:33] "첫 번째… 변경… 알려주지 않는 개발자…" [^12]: @[02:38] "…서로 연산 작업을… 결정…"; @[02:43] "프론트에서 해줄 수 있는 거 아니야 라고…" [^13]: @[02:56] "…말씀이 없네요"; @[03:14] "…감사의 말씀… 마무리…"; @[03:15] "…다음 시간에 만나요"

← 프로젝트에서 보기