안녕하세요! 그로스로그 입니다!😊 🌱
무료 할당량을 다 써버려서 서버를 직접 만들기로 한 이야기, 그리고 백엔드가 잘게 쪼개질수록 프론트엔드가 무거워지는 문제. 3기 4회차입니다.
성장일지는 멤버들이 2주에 한 번씩 자신의 성장을 기록하는 활동이에요. 매 회차 운영진이 모든 글을 읽고, 그중 특히 마음에 남은 글을 함께 골라 큐레이션합니다.
이번 두 편은 기술을 고르는 판단에 대한 기록입니다. 그리고 공교롭게도 둘 다 "더 좋아 보이는 쪽을 안 고를 수도 있다"는 결론에 닿아요.
01
📡 [프로젝트] MQTT VS HTTP 무엇을 사용하는 게 좋을까?
윤창훈 님
센서 데이터를 올리던 ThingSpeak의 1년치 무료 할당량을 3개월 만에 다 써버립니다. 관찰하던 센서 값을 더 못 보게 됐죠.
그래서 서버를 직접 관리하기로 합니다. 그 김에 IoT에서 많이 쓰인다는 MQTT를 알아봐요.
그런데 결론이 흥미롭습니다. 알아보고 나서 HTTP를 고릅니다. 왜 그랬는지가 이 글의 내용이에요.
짧은 글입니다. 그런데 안에 담긴 판단이 깔끔합니다.
조금 더 들어가 보면
먼저 상황이 좋습니다. 필요가 먼저 생겼어요.
무료 서비스를 쓰다가 한도를 넘겼고, 센서 값을 못 보게 됐습니다. 글의 표현이 재미있어요. "있다 없으니까~ 너무 불편한 거 아니겠습니까!" 그래서 직접 만들기로 합니다.
그리고 이 문장이 이어집니다. "역시 직접 배우는 것이 장기적으로 보면 싸게 먹히는 것 아닐까요..!" 남의 서비스에 얹혀 있다가 한도에 막힌 경험이 직접 다뤄보자는 결정으로 이어진 거죠.
🔀 두 프로토콜의 방향 차이
글이 MQTT를 요약한 한 줄이 정확합니다. "양방향 통신이다."
HTTP는 구조가 정해져 있습니다. 클라이언트가 물어야 서버가 답합니다. 서버가 먼저 말을 걸 수 없어요. 글의 표현대로 "이는 구조상 변할 수 없어요."
그래서 IoT에서 문제가 생깁니다. 서버가 센서에게 "지금 값 좀 보내봐"라고 하거나, "밸브를 잠가"라고 명령하고 싶어도 방법이 없거든요. 센서가 물어볼 때까지 기다려야 합니다.
MQTT는 Publisher(발행자)와 Subscriber(구독자) 구조입니다. 중간에 브로커를 두고, 발행자가 특정 주제(topic)에 메시지를 던지면 그 주제를 구독하는 쪽이 받아요.
핵심은 누가 발행자이고 누가 구독자인지가 고정이 아니라는 것입니다. 글이 짚은 대로 "원한다면 요청하고 응답하는 역할을 바꿀 수 있어요." 센서가 값을 발행하면서 동시에 명령 주제를 구독할 수 있죠. 그러면 양쪽에서 말을 걸 수 있게 됩니다.
🧭 그런데 왜 HTTP를 골랐나
여기가 이 글의 핵심입니다. 글이 던진 질문이 좋아요. "MQTT가 IoT에 무조건 유리할까?"
답은 "아니요...!"입니다. 그리고 이유를 세 가지로 듭니다.
HTTP는 틀이 정해져 있어 단순하고, 배우기 쉽고, 많은 사람이 이미 이해하고 있습니다. 반면 MQTT는 양방향이 되는 만큼 다뤄줘야 할 부분이 늘어납니다.
이 마지막 문장이 실무의 핵심을 짚습니다. 브로커를 띄워 관리해야 하고, 연결이 끊겼을 때 재접속을 처리해야 하고, 메시지 전달 보장 수준(QoS)을 정해야 하고, 토픽 구조를 설계해야 합니다. 전부 HTTP에서는 안 해도 되는 일이에요.
그래서 결론이 이렇게 납니다.
"내 상황에서는"이 붙어 있는 게 중요합니다. MQTT가 나쁘다는 게 아니라, 지금 자기가 풀려는 문제에는 그 기능이 필요 없다는 판단이에요.
센서 값을 주기적으로 올리기만 하는 구조라면 양방향이 필요 없습니다. 그런데 나중에 원격으로 기기를 제어하고 싶어지면 그때 MQTT가 답이 되겠죠. 필요가 생겼을 때 옮겨가면 됩니다.
큐레이터 노트
"알아보고 안 쓰기로 한" 기록이라 뽑았습니다.
기술 글은 대개 도입기입니다. "새 기술을 써봤더니 좋더라"요. 그런데 알아보고 나서 기존 것을 유지하기로 한 판단도 똑같이 값집니다. 오히려 더 어려운 결정이에요. 새 걸 배웠는데 안 쓰기로 하는 거니까요.
그리고 판단 기준이 자기 상황에 붙어 있습니다. "MQTT가 더 좋다/나쁘다"가 아니라 "내 프로젝트엔 양방향이 필요 없다"예요. 기술 선택은 원래 이렇게 하는 겁니다.
출발점이 실제 문제였던 것도 좋았습니다. 무료 할당량이 떨어져서 불편해졌고, 그래서 직접 만들기로 했어요. 필요가 먼저 있고 기술이 뒤에 오는 순서입니다.
글이 짧다고 아쉬워하지 않으셔도 됩니다. 결정 하나와 그 근거가 분명하게 남아 있으면 그것으로 충분한 기록이에요.
02
🌉 Backend For Frontend (a.k.a. BFF)
이종경 님
BFF(Backend For Frontend) 패턴을 개념부터 등장 배경, 구조, 동작 흐름, 장단점, 코드 비교까지 정리한 글입니다.
핵심 문제의식이 명확해요. 백엔드가 마이크로서비스로 잘게 쪼개질수록, 그 복잡함이 프론트엔드로 떠넘겨진다는 것.
그리고 모놀리식 방식과 BFF 방식의 프론트엔드 코드를 나란히 놓아 차이를 보여줍니다. 마지막엔 "모든 프로젝트에 BFF가 정답은 아니다"로 마무리해요.
프론트엔드 최적화 시리즈의 두 번째 글입니다. 정리의 밀도가 상당합니다.
조금 더 들어가 보면
BFF가 왜 나왔는지를 이해하려면 원칙 하나가 깨진 상황을 봐야 합니다. 글이 그 원칙을 정확히 인용해요.
좋은 API 설계의 기본입니다. 그런데 마이크로서비스로 넘어가며 이게 깨졌습니다.
백엔드를 잘게 쪼개면 각 서비스는 단순해집니다. 사용자 서비스, 주문 서비스, 결제 서비스가 따로 있고 각자 자기 일만 하죠. 백엔드 팀 입장에선 좋습니다.
그런데 프론트엔드는 화면 하나를 만들려고 세 곳에 물어봐야 합니다. 받아온 결과를 합치는 로직도 직접 짜야 하고요. 글의 표현대로 "백엔드가 잘게 분리될수록 그 복잡성이 프론트엔드로 전가되는 양상"입니다.
여기에 클라이언트 종류의 다양화가 겹칩니다. 모바일은 데이터를 적게 받고 싶고, 데스크톱은 한 번에 많이 받아도 됩니다. 하나의 API로 둘 다 만족시키려면 어느 쪽에도 최적이 아닌 절충안이 나오죠.
BFF는 이 두 문제를 한 번에 답합니다. 클라이언트마다 전용 백엔드를 하나씩 두는 거예요. 2013년경 SoundCloud에서 시작된 이름이라는 것까지 글에 나옵니다.
📝 원문에서는 이렇게 비교합니다
이 글의 백미는 코드 두 개를 나란히 놓은 부분입니다. "사용자 프로필 화면에 최근 주문 내역을 함께 표시"하는 같은 기능을요.
먼저 BFF가 없을 때입니다.
// BFF 없이 두 개의 API를 호출하여 데이터 통합
useEffect(() => {
async function loadData() {
// 1. 사용자 정보 API 호출
const userRes = await fetch('/api/user/123');
const userData = await userRes.json();
// 2. 주문 목록 API 호출
const ordersRes = await fetch(`/api/orders?userId=123`);
const ordersData = await ordersRes.json();
// 3. 데이터 합성: 사용자 객체에 최근 주문 목록 추가
userData.recentOrders = ordersData.slice(0, 5);
setUserProfile(userData);
}
loadData();
}, []);
그리고 BFF가 있을 때입니다.
// BFF를 통해 하나의 엔드포인트에서 통합 데이터 받기
useEffect(() => {
async function loadData() {
// BFF 서버가 통합된 사용자+주문 데이터를 제공
const res = await fetch('/api/bff/user-dashboard/123');
const dashboardData = await res.json();
setUserProfile(dashboardData);
}
loadData();
}, []);
줄 수만 줄어든 게 아닙니다. 사라진 것이 무엇인지를 봐야 해요.
.slice(0, 5)가 없어졌습니다. "최근 주문은 5개만 보여준다"는 규칙이었어요. 그게 프론트엔드 코드 안에 숨어 있었던 겁니다. 안드로이드 앱에서도 같은 화면을 만들면 거기에도 똑같이 slice(0, 5)를 써야 하고, 규칙이 3개로 바뀌면 여러 곳을 다 찾아 고쳐야 합니다.
그리고 await가 두 번에서 한 번으로 줄었습니다. 위 코드는 사용자 정보를 받고 나서야 주문을 부릅니다. 네트워크 왕복이 두 번이에요. 느린 모바일 네트워크에서 이 차이는 체감됩니다.
BFF는 코드를 줄이는 게 아니라 로직을 제자리로 옮기는 일입니다. 화면에 필요한 데이터를 만드는 책임이 클라이언트에서 서버로 간 거예요.
🧭 그리고 "정답은 아니다"
이 글이 좋은 이유는 단점을 분명히 적었다는 점입니다.
중복 구현 — BFF를 여러 개 두면 인증, 캐싱 같은 공통 로직이 각각에 복사됩니다.
리소스 부담 — 서버가 늘어나니 비용도 늘어납니다.
과설계 위험 — 글의 표현이 정확합니다. "클라이언트가 하나뿐이거나 백엔드가 이미 충분히 단순한 경우, BFF를 추가하면 복잡성만 늘어나고 실익은 적을 수 있습니다."
그리고 운용상의 경고도 붙입니다. BFF에 로직을 너무 많이 넣으면 여러 BFF 사이에 비즈니스 기능이 중복되고 유지보수가 어려워진다고요. 그래서 공통 비즈니스 로직은 마이크로서비스가 담당하고, BFF는 클라이언트별 조율에 집중하는 경량 레이어로 유지하라는 겁니다.
"이 패턴을 쓰면 좋다"에서 끝나지 않고 "언제 쓰면 안 되는가"와 "쓰더라도 어디까지만"을 적은 것 — 이게 이 정리를 실전용으로 만듭니다.
큐레이터 노트
패턴을 소개하면서 도입 판단까지 준 글이라 뽑았습니다.
아키텍처 패턴 정리는 자칫 소개서가 되기 쉽습니다. 좋은 점만 나열하면 읽는 사람은 "우리도 해야 하나" 싶어지죠. 이 글은 과설계 위험을 명시적으로 경고합니다. 클라이언트가 하나면 오히려 손해라고요.
코드 비교가 결정적이었습니다. 개념 설명 열 문단보다 두 개의 useEffect를 나란히 놓은 게 훨씬 명확해요. 무엇이 사라지는지가 눈에 바로 들어옵니다.
그리고 이 저자는 3기 내내 프론트엔드의 여러 층을 다루고 있습니다. 2회차 자바스크립트 런타임, 이번엔 아키텍처 패턴. 언어에서 시작해 구조로 올라가는 흐름이 보여요.
💡 두 편을 겹쳐 읽으며
한 편은 IoT 프로토콜, 한 편은 웹 아키텍처입니다. 규모도 다르고 분야도 다릅니다.
그런데 두 글의 결론이 놀랍도록 닮았습니다. 둘 다 "더 좋아 보이는 것이 내 상황에는 아닐 수 있다"고 말합니다.
윤창훈 님은 MQTT를 알아보고 "양방향이 필요 없으니 HTTP"로 결론 냈습니다. 이종경 님은 BFF를 정리하고 "클라이언트가 하나면 복잡성만 는다"고 경고했고요.
두 글 모두 새 기술의 장점을 충분히 이해한 뒤에 그 결론에 닿았다는 게 중요합니다. 몰라서 안 쓰는 것과, 알고 나서 안 쓰기로 하는 건 완전히 다른 일이니까요.
기술 선택에서 가장 자주 생기는 실수가 "좋다더라"로 결정하는 것입니다. 그런데 좋은 기술에는 대개 그 좋음을 감당할 조건이 붙어 있어요. MQTT의 양방향에는 브로커 운영이, BFF의 맞춤 API에는 서버 한 대와 중복 로직이 따라옵니다.
그 조건을 지불할 만한 문제가 지금 있는가 — 두 글이 각자의 자리에서 물은 질문이 이겁니다.
그리고 답이 "아니오"여도 괜찮습니다. 필요가 생겼을 때 옮겨가면 되니까요. 그때는 이미 알아둔 상태일 테고요.
이번 회차에서 가져갈 것
1. 프로토콜은 "방향"으로 먼저 나누기. HTTP는 클라이언트가 물어야 답합니다. 서버가 먼저 말을 걸어야 하는 상황이면 MQTT나 웹소켓이 필요해요. 이 한 가지만 확인해도 선택이 반은 정해집니다.
2. 새 기술의 비용을 같이 세기. MQTT는 브로커 운영·재접속 처리·QoS 설계가 따라옵니다. 기능만 보지 말고 딸려오는 일까지 세어보세요.
3. 프론트엔드에 숨은 규칙이 있는지 보기. .slice(0, 5) 같은 코드는 비즈니스 규칙이 클라이언트에 새어 나온 흔적입니다. 클라이언트가 여러 개면 그만큼 복사되고 있다는 뜻이에요.
4. 왕복 횟수를 세어보기. await가 순서대로 두 번이면 네트워크를 두 번 왕복합니다. 모바일에서는 이 차이가 체감돼요. 합칠 수 있는지 확인해보세요.
5. "안 쓰기로 했다"도 기록하기. 검토했지만 도입하지 않은 결정은 6개월 뒤 같은 논의가 반복될 때 시간을 아껴줍니다. 근거와 함께 남겨두세요.
좋은 글 남겨주신 윤창훈 님, 이종경 님께 감사드립니다! 😊
다음 큐레이션으로 다시 찾아오겠습니다! 🌱
- 에디터 · 성장일지 큐레이터 -
※ 본 큐레이션은 각 저자가 공개한 글을 소개하는 것이며, 모든 원문의 저작권은 저자에게 있습니다. 저자 본인의 요청이 있을 경우 즉시 수정 또는 삭제합니다.