백엔드개발자와 프론트개발자는 어떤 방식으로 협업을 하나요?
친구들과 웹개발 프로젝트를 하나 시작했는데 전부 비전공자이고 코딩을 시작한지 얼마 안된 인원들입니다. 그 중에 제가 그나마 파이썬을 조금 할 수 있어서 장고와 gcp를 이용해서 백엔드를 만들고 있습니다. 저도 웹개발 공부를 시작한지 얼마 안된 초짜입니다.
지금 프론트엔드쪽은 html css js로 모양을 만들고 그걸 제가 받아서 장고의 템플릿변수? 그런걸로 db랑 연결되게 만들고 있는데 뭔가 비효율적인거 같고 이렇게 하는게 아닌거 같다는 느낌이 들었습니다.
실무에서는 어떤식으로 프론트엔드와 백엔드가 협업을 하나요? api를 사용한다는걸 본 거 같은데 백엔드는 api로 데이터만 넘겨주고 프론트는 그 데이터를 받아서 알아서 만드는건가요?
14개의 답변이 있어요!저희같은 경우에는 백엔드쪽에서 제작하고
함수명세서같은걸 만들어줍니다.
그럼 프론트엔드쪽에서는 그 함수명세서에 맞춰서
서버에 요청해 처리하는 로직을 만들구요
그 외 클라이언트에서 진행되는 처리는 대부분 프론크엔드 담당자가 구성합니다.
사용자에게 보여지는 부분이 중요하기 때문이에요.
말씀하신 API와 비슷하다고 할 수 있겠네요
보통 애플리케이션 개발은 외부 자원에 접근할 수 있는 API가 필요하다. 그리고 대개, API를 개발하는 백엔드 개발자와 애플리케이션 인터페이스를 개발하는 프런트엔드 개발자로 나눠 협업한다. 이때 두 직군 간 협업 과정에서 병목이 발생하기 쉽다.
프런트엔드 개발자는 동작하는 API를 기다리고 백엔드 개발자는 프런트엔드 요구에 맞춰 API, 또는 비즈니스 로직까지 변경해야 하는 일이 생긴다. 그러다 보니 교착 상태에 빠지거나 시간이 흐를수록 커뮤니케이션이 힘들어지기도 한다.
만약 당신이 이러한 문제를 겪고 있다면 지금부터 소개하는 두 가지 방법이 도움이 될 수 있다.
1.API 인터페이스 협의
가장 이상적인 방법은 API 인터페이스를 협의하는 과정을 갖는 것이다. 필요한 API는 요구사항 분석 과정에서 알 수 있다. 예를 들어 복수의 피드를 선택해 구독하는 기능을 떠올려보자. 자연스럽게 복수 피드에 대해 구독 요청을 할 수 있는 API가 필요함을 알 수 있다.
이어서 백엔드 개발자와 함께 구독 요청 API 인터페이스를 협의한다. API 인터페이스란 어떤 메서드와 URL로 요청 해야 하고 응답 형식은 무엇인가에 대한 약속이다. 이를 신뢰하고 각자 개발을 진행한다. 동작하는 API를 기다리지 않아도 된다.
2.팩토리를 이용한 개발
어떠한 API가 필요하고 또, 구현 가능한지 불확실할 때는 협의 미팅이 도움 되지만, 구현할 기능이 단순하고 필요한 API에 관해 대략적인 정보를 공유하고 있다면 오히려 비용일 수 있다. 그렇지만 API 응답 형태를 모르는 상태에서 예측으로 코드를 작성하면 통합 단계에서 애플리케이션 전체의 코드 변경이 필요할 수 있다.
친구 목록을 가져와 출력해주는 기능을 상상해보자. 이 요구사항에서 모델을 디자인할 수 있다.
네 어느정도 잘 알고 계신듯합니다.
프렌트 쪼겡서 html css js로 화면을 만들고 꾸미고 이벤트를 만들어 줍니다.
그리고 프론트 쪽에서 js를 통해 화면에서 여러가지 정보(파라미터)를 담아주고
백엔드가 그 정보들을 가공하고 DB까지 연결시켜줍니다.
실무에서는 좀 구어체로 말씀드리면 ...
프론트 "화면은 어느정도 완성됬구요 데이터셋에 파라미터 담아놨어요"
백 "알겠습니다. 처리할게요"
"엥? 에러나는데... 화면에서 페이징 처리할때 게시판 번호가 안넘어오는거 같은데 확인좀해주세요"
프론트 "아 그래요 ?? 한번 볼게요"
-----------------------------------------------------
프론트 "혹시 조회하는데 데이터가 안나오는데 ? 로그보니깐 서버에서 데이터가 안넘어와서요"
백 "아 넵"
"아 소스 수정했습니다 확인해보세요"
------------------------------------------------------
정말 간략하게...ㅎㅎ
뭐 이런식으로 진행되요 ...
사실 이게 몇백페이지가 되고
서버쪽 소스가 몇만줄이고
테이블이 수십 수백개인 곳에서는
이런 분류된 작업들이 일을 더 수월하게 만들어줘요
근데 질문자가 하시는 소규모의 프로젝트나 과제는 사실 혼자서 쓱쓱 처리하는게 효율적이겠죠
그래서 본인도 역할분담을 하시는데 효율이 안나온다 느끼신거 아닐까 싶습니다!!!
1.UI와 API 소개
API 란?
Application Programming Interface의 약자로 프로그램이 동작하는 환경을 제어하기 위해서 환경에서 제공되는 조작 장치이다.
이 조작 장치는 프로그래밍 언어를 통해서 조작할 수 있다. 아래 영상은 UI와 API의 차이점을 설명하기 위한 자료이다
UI란?
user interface사람(사용자)과 사물 또는 시스템, 특히 기계, 컴퓨터 프로그램 등 사이에서 의사소통을 할 수 있도록 일시적 또는 영구적인 접근을 목적으로 만들어진 물리적, 가상적 매개체를 뜻한다. 사람들이 컴퓨터와 상호 작용하는 시스템이다.물리적인 하드웨어와 논리적인 소프트웨어 요소를 포함한다.(중계자라고 생각하면 된다 사용자의 의중을 시스템에게 전달하고 시스템의 상태를 사용자에게 보여주는것 )
이 둘의 공통점과 차이점이있다
공통점은 interface이고 차이점은 UI=user로시작 API=Application으로 시작하는 것이다
웹브라우져를 놓고 봤을 때 일반적인 사용자들은 버튼과같은 일반 사용자가 사용하는 UI를 통해서 시스템을 제어하고 지위한다 하면 소프트웨어 개발 자들은 alert과 같은 API를 통해서 웹브라우저를 제어 한다는 차이가 있다
우리는 계층적인 관계에서 interface라고 부른다.
2.문서보는법
레퍼런스와 튜토리얼
프로그래밍을 공부하기 위한 자료는 크게 레퍼런스(reference)와 tutorial(안내서)가 있다. 통상 튜토리얼은 언어의 문법을
설명하고, 레퍼런스는 명령어의 사전을 의미하다. 본 수업은 자바스크립트에 대한 일종의 안내서라고 할 수 있고,
자바스크립트 사전(https://opentutorials.org/course/50)은 레퍼런스라고 할 수 있다.
입력값 // 출력값 // 데이터 타입 등을 정의 후에 문서를 통하여 커뮤니케이션 하시면 될 거 같습니다.
감사합니다.
일단 기초지식은 알고 계신것 같아서 말씀하신 용어들을 기준으로 설명을 드리면, 파이썬 쟝고를 사용해서 백엔드를 만드신다고 하셨는데, 쟝고의 템플릿변수를 이용해서 html에 값을 뿌려주고 렌더링을 하는 방식을 서버 사이드 렌더링이라고 말합니다. 즉 쟝고의 컨트롤러 단에서 모델을 호출하고, 모델에서 db에 접근(연결이라는 표현을 사용)하여 필요한 데이터를 가져온 후, 가공하여 서버쪽에서 화면에 뿌려주는 역할이죠.
사실 실무에서는 위와 같은 서버 사이드 렌더링 방식은 그렇게 권장되지 않습니다. (아직 많이 사용 되고 있는 부분이 있지만) 이유는 이렇게 서버사이드렌더링을 하게 되면 코드의 복잡성이 올라가고, 뷰(보이는 부분)과 모델(데이터)의 분리를 할 수 없어 확장성이 매우 떨어지기 때문입니다. 또한, SPA 이 필요한 상황에서 적합하지 않기 때문이죠. (SPA 같은 경우는 설명하면 글이 너무 길어질 수 있으니 검색해 보시는걸 추천드립니다.)
따라서 백엔드에서는 주로 클라이언트(사용자)가 특정한 요청을 했을 때, 예를 들어 게시판 목록을 요청했을 때, 백엔드에서는 해당 요청에 대한 API를 만들고, 이 API를 통해서 프론트엔드에 결과를 보내면(response) 프론트엔드에서는 받은 결과를 렌더링하는 식으로 협업이 진행됩니다. 미리 요청과 응답에 대한 구조를 확정지어 놓으면, 각자 자신의 역할만 수행할 수 있는 거죠.
코딩을 시작한지 얼마 안된 분들이시면 쟝고를 사용하여 서버사이드 렌더링으로 먼저 프로젝트를 진행해보시고, SPA 개념과 AJAX등 비동기 요청 처리에 대한 부분들도 함께 보시면서 이후에 제가 드린 말씀이 더 잘 이해될거라고 생각됩니다.
이미 잘 협업중이신걸로 보입니다.
만들고계신 백앤드 기능이 무엇인지, 장고의 템플릿변수를 어떻게 db와 연결하고있는건지
좀더 명확한 설명이 필요해 보입니다만, 첨언을 드리자면
질문자님꼐서 프론트 개발자들에게 정확히 요청하셔야하는것은
프론트 단에서의 Request 발생 시 백엔드 단으로 전달 받아야하는 매개변수의 정보와
백엔드 단에서 프로세스 처리 후 다시 프론트 단으로 리턴해야하는 결과값의 정보 입니다.
설계자가 따로 없는것으로 판단되기때문에 누군가 한사람 설계자를 선정해야할 것으로 생각됩니다.
- 백엔드는 api로 데이터만 넘겨주고 프론트는 그 데이터를 받아서 알아서 만드는건가요?
프론트 단에서 사용하는 데이터 도 프론트앤드 개발자가 만드는게 보통입니다.
물론 프로젝트 규모가 크고 데이터 의 종류도 방대하다면 각 데이터 시스템 마다 백엔드 개발자(보통 서버 개발자라고도 합니다)가 API 서버 형태로 구현을 하고 프론트 단에서는 API를 호출해서 받아온 데이터를 화면에 뿌려주기도 합니다.
하지만 대부분의 중소규모의 프로젝트 에서는 프론트앤드 개발자가 DB 나 외부시스템에서 데이터를 가져오는 부분 까지도 구현을 합니다. 이렇게 하는 이유는 아래와 같습니다.
1. 프론트 단이 화면을 그리는 속도가 백엔드가 데이터를 가공해서 보내주는 것을 구현하는 것 보다 훨씬 빠르기 때문에 데이터 기다리는 동안 시간이 붕 뜨게 됩니다. 그리고 시스템이 작은 곳에서는 데이터 종류가 많지 않기 때문에 프론트 와 백엔드를 구분해서 개발자를 투입하는 것이 개발사 에게 손해가 됩니다.
2. 프론트 와 백엔드 간에 의사소통 시간이 불필요한 낭비가 됩니다. 데이터 의 형식이나 정합성을 맞추는데 한사람이 할것을 두사람이 연결되서 하다보니..의사충돌도 생기고 두사람의 개발실력 이나 연차가 차이가 날 경우 한쪽의 퍼포먼스가 느려서 둘다 생산성이 안나올수도 있죠.
3. 무엇보다도 프론트 앤드 개발자도 서버쪽을 다룰수 있기 때문에 보통은 화면만 그리는 일만 하는걸 원하지 않습니다. 예상하시겠지만 화면만 그리는 개발자 보다는 서버쪽 프로그래밍도 할줄 아는 개발자가 연봉면에서 우대를 받을 것이기 때문에..프론트 개발자 자체가 화면단만 하기를 원하지도 않는게 보통이죠.
이정도면 답변이 됐나 모르겠네요.
안녕하세요.
요즘 파이썬이 대세라고는 알려져있습니다.
보편적으로 웹개발이 취업하기도 광범위합니다.
또한 기본적으로 java는독학하기에도 수월합니다.
자바스크립트를 시작으로해서 앞부분 프론트를 마무리하고 java로 들어서면서 서비스쪽(조금 더 디테일하게) 배우는것이 괜찮을 것 같습니다.
자바스크립트는 현재 많이 사용중이므로 쉽게 접근하실 수 있습니다.
감사합니다.
회사마다 조금씩은 다르지만 백엔드의 경우 API를 만들고 프론트엔드에서 API를 조회해서 데이터를 보여주기도 합니다.
Django를 가지고 API서버를 개발을 할수 있다보니 필요한 API를 만들어주면 될것 같습니다.
프론트엔드와 백엔드의 경우 API 정의서를 잘 만들어야 쉽게 프로젝트를 진행할수 있습니다.
Swagger 같은 도구를 사용해보면 쉽게 개발이 가능하지 않을까 합니다.
은행에 비교하면 좀 이해가 쉬울거에요
프론트는 은행고객, 백엔드는 은행이죠
고객은 자신의 계좌에서 돈을 넣을수도, 뺄 수도 있잖아요?
본인 계좌에 들은 돈을 출금하는것을 예로 들어보죠
먼저 고객(client)이 은행(API server)에 가서 은행원(api)에게 자신의 계좌에서 돈을 뽑아달라면서(request) 자신의 계좌 비밀번호(body)를 입력합니다(POST request) 그럼 은행원(api)은 입력한 비밀번호를 토대로 금고(DB)에서 돈(response DATA)을 꺼내어서 건네주죠
이처럼 프론트와 서버는 요청과 응답을 주고 받는다고 생각하시면 됩니다.
API에 대한 개념을 공부해보시면 될것 같습니다🙂
1. swagger
백엔드개발자가 개발한 api를 웹형태로 보여줍니다.
실제로 api를 실행시킬수도 있습니다
넣어야할 파라미터나 사용방법등을 넣을수 있어서 스웨거만 봐도 충분합니다
(물론 백엔드 개발자가 잘 기입해줘야함)
2. postman
request를 날려볼수 있는 tool 입니다.
open api 같은거를 테스트 할때 많이 사용합니다.
포스트맨도 스웨거랑 비슷하게 웹 형태로도 api 가이드를 제공할 수도 있으며,
실제 파일전송을 위한 파일 선택 기능이라던지
다양한 기능등을 지원해서 사용하기 편합니다.
백엔드 개발자가 export 해서 건내주면
나의 포스트맨에 import 해서 그대로 사용할수도 있습니다.
네, 보통은 API서버를 만들수있으면 API서버를 만들어 Restful한 API서버를 개발합니다.
REST APIRepresentational State Transfer의 약자로 HTTP 통신에서 어떤 자원에 대한 CRUD(Create, Read, Update, Delete) 요청을 Resource와 Method(GET, POS, DELETE등)로 표현하여 특정한 형태로 전달하는 방식을 말한다. HTTP 프로토콜 (링크를 기반으로 데이터를 요청하고 받음)의 장점을 최대한 활용 가능한 방법이다.
resource. 모든 자원에는 고유한 ID가 존재하고 이 자원은 Server에 존재한다.
resource. 자원을 구분하는 ID는 /groups/:group_id 와 같은 HTTP URI이다.
method. GET / POST / PUT /DELTE
Representaion of Resource. JSON, XMS, TEXT, RSS등 다양한 형태로 데이터를 보낼 수 있다.
Representaion of Resource. JSON을 많이 쓴는 추새
moives라는 Resource에 다양한 메소드(GET, POST, PUT, DELETE)로 접근이 가능해짐
우선, 질문에 대한 답변만 드리면 DB 연결의 이유는 트랜젝션과 데이터 안정성이 주요 이유입니다. 실무의 협업은 직접 해 보셔야 알 수 있습니다. API 명세서가 핵심입니다. 실무의 협업은 직접 해 보셔야 한다는 이유는 자전거를 탈 때 아무리 책으로 말로 설명해도 직접 타보지 않으면 절대 배울 수 없습니다. 조향각은 얼마로 해야 하고 페달은 어느정도 힘으로 밟아야 하며... 인 것이죠. 이와 마찬가지로 간단히 frontend, backend 프로그래밍을 해 보시면 알 수 있습니다. 실무 이야기를 그래도 좀 적어보면, 예전에는 SOAP 방식으로 XML로 정보 교환을 했다고 하면 요즘은 RESET API 방식으로 JSON을 통해 서버와 클라이언트 정보 교환을 합니다. 그리고 대부분 REST API 방식으로 프로그래밍을 하고 서버/클라이언트 모델 자체가 서버 구현이 중요한 경우가 많이 때문에 특정 기능은 대부분 서버에 구현하는 경우가 많습니다. 그래서 서버가 먼저 개발이 되어야 합니다. 다만 클라이언트의 경우 UI 작업이 있기 때문에 동시적으로 개발할 때는 클라이언트의 경우 우선 UI 목업부터 만듭니다. 사람마다 또 작업 프로젝트마다 다릅니다만, 저 같은 경우 서버/클라이언트를 모두 해서 REST API 명세서를 만들지 않습니다. 바쁜게 주된 이유입니다. 그러나 작업자가 다른 경우 REST API 명세서는 필수 입니다. 그러나 실무에서는 만들지 않는 경우가 많습니다. PM이 해당 내용을 모르는 경우가 많기 때문입니다.
프론트 엔드 개발자는 UI/UX 에 익숙한 개발자입니다. vue나 react 같은 기술을 많이 사용하고요 백엔드 개발자에게 데이터 수집이나 데이터 조회 할 쿼리를 만들어 달라고 하는게 일반적입니다. 백엔드를 조금 아는 프론트개발자라면 큰 문제가 되지 않겠지만 초급 프론트개발자는 대부분 퍼블리싱에서 넘오오신 분이거나 학원을 마치고 바로 취업한 프론트개발자들은 실무에서 많이 다투기도 합니다. 프론트는 화면 기획자와도 잘 맞추어 일해야 합니다 업무의 컨셉을 잘 파악하고 반영하는것이 주업무 입니다.
