# 메시지 큐 기반 아키텍처가 요즘 인기가 떨어지는 이유는 뭔가요?

> Clean Markdown view of GeekNews topic #15456. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15456](https://news.hada.io/topic?id=15456)
- GeekNews Markdown: [https://news.hada.io/topic/15456.md](https://news.hada.io/topic/15456.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-06-21T11:03:01+09:00
- Updated: 2024-06-21T11:03:01+09:00
- Original source: [news.ycombinator.com](https://news.ycombinator.com/item?id=40723302)
- Points: 49
- Comments: 11

## Summary

MQ 기술이 성숙기에 접어들어서, 관련 글과 기사가 많이 안 나오지만 실제로는 많이 이용되고 있습니다. 물론 간단한 기능들은 Redis/DB 같은 것으로도 처리가 가능해져서 실제로 케이스가 줄어들기도 했습니다만, 그렇다고 없어지진 않았다는 것.

## Topic Body

- 2010년초까지만 해도 MQ기반 분산 시스템 구축 얘기가 많았는데 요즘은 글들이 별로 없음   
- 생각하는 몇가지 이론들은 다음과 같은데, 이중 하나일지 다른 분들 생각은 어떤지 궁금함  
  - Redis가 대부분의 케이스 및 캐싱까지 처리해서 더 이상 별도의 메시지 브로커 운영이 쓸모없어짐. Kafka는 정말 대규모로 가버림.  
  - DB(광범위하게 봤을때)가 대규모 처리를 훨씬 잘하게 되면서, "일시적인"처리들을 메인 저장소에서 처리하게 됨   
  - MQ 기반 아키텍처가 기대만큼 잘 작동하지 않는 다는 것을 알아버려서 이제 다른 방식을 사용함   
  - 사실은 이제 MQ 기술이 성숙기에 접어들어서, 사람들이 관련 글을 쓸만큼 흥미롭지는 않음. 하지만 여전히 널리 사용되고 있음   
  
### hnthrowaway_99   
- 2000년대 후반부터 2010년 초반의 많은 "인기" 아키텍처가 결국 "**당신은 구글이 아님. 당신 회사는 구글이 절대 될 수 없음**" 사실을 깨닳고 사라졌음   
- 그 시기에는 "성공한 대기업이 구축한 방식으로 구축" 하려는 열망이 컸음   
- 하지만 그 이후로 많은 사람들이 99%의 기업에게는 복잡성이 필요하지 않다는 것을 깨달았음   
- 하드웨어와 표준 데이터베이스가 훨씬 더 좋아지면서 이러한 "Scalability Trick"이 필요한 기업은 점점 더 줄어들고 있음   
- "**이 모든걸 Postgres로 하면 안 되는 이유가 있을까요?**"의 내 기준은 10년전 보다 훨씬 높아졌음   
- 이 댓글에 달린 댓글들   
  - 이제 적절한 비용으로 사용가능한 훨씬 큰 싱글 머신이 생김. 예전엔 소규모 클러스터가 필요했지만, 이제 싱글 시스템으로도 다양한 워크로드를 많이 수용 가능   
  - 솔직히 말하면, 난 구글에서 큐를 제거하는 여러개의 프로젝트에 참여했었음. 그러니 아마 그 이상일지도(인기가 떨어진 것 이상)  
  
### biglain   
- 냉소적이지만, 내 생각에 MQ 아키텍처와 이에 대한 블로깅은 "**Resume Driven Development**"였음. 실제로는 모노리스를 넘어 확장할 필요없이 단일 노트북에서 실행가능한 일을 하는.  
- 이 사람들이 아마도 한달에 수천만원씩 AWS 비용을 내는 악몽같은 Microservice 재앙을 구축하는 사람들이었고   
- "실제 비즈니스 문제를 실용적인 방식으로 해결하는 것보다, 기술적인 업적을 쌓는 것을 경력의 우선순위로 삼는 사람들"이 요즘은 AI에 대해 Hyping하며 블로그에 글을 올리고 있음   
  
### tuckerconnelly   
- 최근 마이크로서비스가 너무 복잡하고 중복 코드가 많아서 모놀리스로 전환했음. 마이크로서비스가 없으면 메시지 큐의 필요성이 줄어듦   
- 비동기 작업의 경우 한 프로젝트에 RabbitMQ를 사용했는데, **너무 오래되고 과도하게 설계된 느낌**이 들었음  
- 그리고 그 주변의 많은 도구(Celery)는 redis(bullmq)를 중심으로 구축된 최신 도구만큼 좋지도 않았음   
- 다단계의 DAG 스타일 프로세스의 경우, 나는 가능하면 하나의 큰 작업에서 모든 것을 처리하거나 작은 수의 작업으로 나누어서 처리하는 것을 선호  
- 정말 DAG가 필요하다면 이를 위해 특별히 제작된 도구(Airflow)가 있음. 하지만 문제를 디버깅하기 어렵다고 들었기 때문에 가급적 피하는 것이 좋음   
- 나는 Redis의 멀티노드 아키텍처가 터무니없이 지나치게 복잡해서 확장에 문제가 있어 단일 노드를 고수중. 하지만 수작업으로 샤딩하는 것은 나한테는 괜찮고 잘 작동함   
- 이글에 대한 kypro의 댓글  
  - 내 경험상 **모놀리스는 복잡성을 줄이는 것이 아니라 복잡성을 이동시킬 뿐**  
  - 모놀리스의 가장 큰 문제점은 도메인 간의 관심사가 명확하고 명시적으로 분리되어 있지 않기 때문에 시간이 지나면 모놀리스 코드베이스가 고도로 상호 연결된 스파게티 코드의 난장판으로 변하기 쉽다는 점  
  - 특히 많은 개발자와 함께 대규모 프로젝트를 구축하는 경우, 자신이 다루는 코드의 도메인 복잡성을 모두 이해하지 못하는 개발자가 많다면 더욱 그러함   
  - 모놀리스는 개발자가 적은 소규모 프로젝트에 적합하지만, 그렇지 않은 경우에는 몇 년 안에 대부분 모놀리스를 구축한 것을 후회하게 될 것  
  - 또한 중복된 코드 포인트에 대해서도 동의하지 않음. 같은 언어를 사용하고 프로젝트 간에 패키지를 공유한다고 가정할 때 왜 그것이 큰 문제가 되는지 모르겠음   
  - 어쨌든 마이크로 서비스 작업을 하면서 이런 문제는 제가 겪어본 적이 없음   
  - 또한 마이크로서비스가 평균적으로 모놀리스보다 더 복잡한지에 대해서도 의문을 제기하고 싶음  
  - 내가 마이크로서비스 아키텍처에서 가장 좋아하는 점은 개별 마이크로서비스를 이해하고 기여하기가 얼마나 간단한가 하는 점  
  - 마이크로서비스의 아키텍처와 프로비저닝은 더 복잡할 수 있지만, 마이크로서비스를 작업하는 개발자의 입장에서는 모노리스에 비해 훨씬 더 간단하게 작업할 수 있음   
  
### democracy   
- 이 생각이 맞는 것 같음 : "**MQ 기술은 이제 막 성숙해져서 글을 쓸 만큼 흥미롭지는 않지만 여전히 널리 사용되고 있음**"  
- **메시징 기반 아키텍처는 매우 인기 있음**   
- 이 글에 대한 댓글들   
  - casper14 : 동의함. **그냥 하나의 도구가 되었음**. 더 이상 클라우드에서 가상 머신을 사용하는 방법에 대해 글을 쓰는 사람이 아무도 없는 것처럼  
  - bwhaley : 이게 바로 정답. **대규모로 실행되는 거의 모든 분산 시스템은 어느 정도 용량으로 메시지 큐를 사용한다고 장담**할 수 있음   
  - ipsum2 : 이게 유력함. 예전에는 앵귤러를 리액트로 다시 작성하는 것에 대한 포스팅이 인기가 있었지만, 지금은 모두들 그냥 리액트를 사용하거나 리액트를 vue로 리라이팅하는 것에 대한 글을 씀   
  
### busterarm  
- 인기 없는 답변을 주려고 해  
- 큐, 스트림 및 Pub/Sub는 대부분의 엔지니어가 잘 이해하지 못하는 개념  
  - 언제 필요한지 모르고, 제대로 사용하는 방법도 모르며, 엉뚱한 용도로 사용함   
  - 나는 여전히 위의 모든 것(SQS/SNS/RabbitMQ/Kafka/Google Pub/Sub)으로 작업하고 있음   
- 나는 북미의 상위 3~4개 학교 출신의 가장 "뛰어난" 엔지니어들만 고용하는 회사에서 일하고 있으며, 거의 모든 엔지니어에게 이것이 첫 직장임   
- 우리 엔지니어들은 다음과 같은 미친 짓을 해왔음:   
  - RabbitMQ에서 수만 개의 100MB 메시지를 순식간에 큐에 올려놓고 왜 폭파되는지 궁금해함  
  - 이렇게 하지 말라는 모든 경고에도 불구하고 일반적으로 RabbitMQ에서 상당히 큰 용량의 메시지를 보냄  
  - 2024년 최신 RabbitMQ 버전에서 새 프로젝트를 시작하고 클래식 큐를 사용하려고 함   
  - 복제 정책 없이 쿼럼 대기열을 만들거나 말 그대로 HA를 만들기 위해 아무 것도 하지 않음   
  - 관리 사용자가 게스트/게스트인 상태에서 인터넷에 클러스터를 노출함   
  - 조직의 가장 고위급 아키텍트가 새로운 아키텍처 패턴을 선언하고, 조직 전체 회의를 개최하고 데모를 함   
    - 메시지를 대기열에 집어넣은 다음 백채널을 만들어 두 번째 소비자가 대기열에 있는 메시지를 온디맨드 처리할 수 있도록 하는 새로운 미덕/패턴을 찬양함 (그리고 더 이상 대기열이 아니게 함)  
    - 그리고 나를 제외하고는 아무도 "왜 순서대로 처리해야 하는 메시지를 대기열에 넣는가?"라고 말하지 않았고, 그 '패턴'이 자리를 잡았음!  
  - Kafka를 기본 메시지 큐로 사용하기  
  - 중앙 데이터센터에서 전 세계에 분산된 데이터센터로 데이터를 전송하고, 각 대상 데이터센터가 업데이트된 객체를 수신했음을 확인할 때까지 객체에 대한 글로벌 잠금과 모든 작업을 수행. 데이터가 AJAX 요청과 함께 전송되었으므로 이 프로세스는 비동기식이라고 주장  
- 결과적으로 사람들은 그다지 대단한 일을 할 필요가 없는데도 여전히 잘 해내고 있음. 따라서 도구는 오용, 남용, 과소 사용되기도 함   
- 잘 사용되고 있는 곳에서는 아마 그런 얘기를 듣지 못할 것  
- 중요한 사실: 우리 조직에는 엔지니어 1명당 30개가 넘는 마이크로서비스가 있음. 제발 날 죽여줘. 거대한 모노레포에 수천 개의 마이크로서비스가 있는 다른 조직에서 일하느니 말 그대로 커트 코베인이 되고 싶음  
- 이 글에 대한 댓글들   
  - zug_zug : 실제 데이터를 통해 이 이론을 뒷받침해 보면  
    - 뉴욕 에서 Akka(스칼라의 이벤트 기반 큐잉)를 사용하는 스타트업에 근무 했었음   
    - 왜 그랬을까? 이전 직장의 관리자가 이 방법으로 "모든 것이 느렸을 때" 회사를 "구했다"고 해서 새 직장에서 이를 의무화했기 때문일까?  
    - 큐잉이 필요했던 업무는 무엇이었을까? 웹사이트를 통해 직원들의 401k를 보여주고, 자산 구성을 조정하도록 하고, 하루에 수백 통의 이메일을 발송한 것이 전부  
    - 예상대로 사람들은 401k 웹사이트에 로그인하는 경우가 거의 없었음   
    - 그곳에서 일한 지 1년 정도 지나서 나는 서버가 계속 잘못 구성되어 있었고 기본적으로 웹 요청에 대한 동시성이 0이라는 사실을 깨달았음  
    - (2개의 프로덕션 서버가 항상 필요한 모든 트래픽을 처리하고 있었기 때문에 이를 인지하지 못함)  
    - 결국 불필요하고 불필요한 복잡성을 가중시킨다는 이유로 Akka를 제거  
    - 지난 달에 이 회사는 현금 회수 옵션으로 또 다른 펀딩 라운드를 진행했는데, 분명히 가치가 올라갔고 여전히 잘하고 있는 것 같음   
  - scary-size : 이건 정말 "뛰어난" 엔지니어만 고용하는 것 같지는 않은데?   
  - roncesvalles : 디자인 리뷰 프로세스가 없는 것 같아. 그리고 나라면 유명 대학 졸업자보다, 이름 없는 대학교 출신 2-5년차 개발자를 뽑을 것 같아. 소프트웨어 엔지니어가 커리어의 첫 5년 동안 배우고 성장하는 양은 엄청나며, 아마도 나머지 커리어를 합친 것보다 더 많을 것.   
  
### burutthrow   
- **MQ는 꽤나 상품화(commoditized)되었다고 생각**함   
- Confluent나 RedPanda 또는 MSK를 서비스로 구매하면 Kafka를 직접 관리할 필요가 없음   
- **변경 데이터 캡처(CDC)도 매우 훌륭하고 메인스트림이 되었음**. RDBMS에 데이터를 쓴 다음 변경 데이터를 캡처하여 다른 시스템으로 전파하는 것은 비교적 쉬움   
- 예를 들어, 메시지 큐는 CDC 시스템이 메시지를 전달하는 데 사용하는 백본에 불과하기 때문에 이러한 패턴은 사람들이 카프카에 대해 쓰지 않는다는 것을 의미  
- 이러한 아키텍처는 분명히 여전히 존재하며 대부분 조직의 제약 조건을 충족함  
- Kafka와 같이 한번 쓰고 여러 번 읽는 큐가 있는 경우 조직의 다른 부분에 API를 노출하는 것. 많은 회사에서 이 패턴을 사용하여 여러 팀 간에 데이터를 섞어 사용  
- 많은 마이크로서비스를 소유하고 있는 소규모 팀은 이력서 중심의 개발자처럼 느껴지지만, 하지만 **엔지니어가 100명 이상인 회사에서는 이 패턴이 합리적**  
  
### angarg12   
- **MQ는 분산 시스템 도구 상자에 있는 도구임. 적절할 때는 훌륭하게 작동**  
- 당신의 이론이 정말 맞다면 난 이거라고 생각함 "**사람들은 보통 새롭고 반짝이는 것에 대해 블로그 포스팅을 작성함**"  
- 나는 개인적으로 디자인에 항상 큐를 사용하며, 특히 디커플링이 높은 서로 다른 시스템 간에 데이터를 전송할 때 큐를 사용  
- 내가 겪은 유일한 고통은 업스트림 시스템에서 7일 동안의 데이터를 다시 채워서 오래된 요청으로 큐가 막혔을 때였음   
  - 정상적으로 실행했다면 모든 데이터를 처리하는 데 100시간 이상이 걸렸을 것이고, 새로운 데이터의 지연 시간도 엄청나게 늘어났을 것  
  - 해결책은 큐를 수동으로 제거하고 누락된 최신 데이터를 수동으로 다시 채우는 것이었음   
- **바인딩되지 않은 큐 크기에 주의해야 하지만 여전히 훌륭한 도구라고 생각**  
  
### rossdavidh   
- **MQ는 Gartner Hype Cycle** 에서   
  - '**부풀려진 기대의 정점(Peak of inflated expectations)**'을 지나고   
  - '**환멸의 골짜기(trough of disillusinment)**'를 지나   
  - '**깨달음의 비탈길(Slope of Enlightment)**' 심지어는 '**생산성의 고원(plateau of productivity)**'으로 향해가고 있음   
  
### robertclaus   
- "**분명히 우리 모두는 여전히 메시지 큐와 워커를 사용하고 있으며, 단지 그것에 대해 글을 쓰지 않을 뿐**"이라는 댓글이 마이크로서비스와 실질적인 확장성에 대한 논쟁 때문에 뒤쪽에 묻혀 있다는 점이 매우 흥미로움   
- 이 댓글을 읽는 주니어 엔지니어는 더 이상 웹 서버의 과중한 연산을 워커에 떠넘겨서는 안 된다는 잘못된 인상을 받을 수 있음   
  
### pm90   
- 그 **기술이 지루해졌기에 관련 블로그 글이 줄어들었음**   
- 이건 좋은 것임. 예를 들어 RabbitMQ 공식 문서가 훨씬 더 좋고 매우 유용함  
- 사람들은 Postgres/MySQL을 사용하는 것처럼 이를 주력으로 사용함   
- 아키텍처 등을 설계하는 데 놀라운 기술도 필요하지 않음   
- 난 지루한 소프트웨어를 사랑함 "**I love boring software**"  
  
### slowmovintarget  
- 이러한 아키텍처의 대부분은 기업 데이터 센터에서 실행되었음  
- 클라우드로 전환 후 소규모 상태 비저장 서비스를 만들면서(SPA의 등장) 복잡한 단계별 이벤트 중심 시스템이 덜 필요해짐  
- 예를 들어 AWS에서는 SQS와 약간의 SNS를 사용하거나 몇 가지에 Kinesis를 사용하면 충분. 여기서는 MQ가 더 이상 설계의 중심이 되지 않음   
- MQ 기반 아키텍처는 데이터 처리에는 좋지만 대화형 웹 사이트에는 적합하지 않으며, 대부분의 사람들이 대화형 웹 사이트를 구축한다면 선택의 여지가 없어 보임   
- 나는 여전히 데이터 처리를 위한 이벤트 시스템을 설계함(특히 새로운 사실이 있지만 "틀렸거나" 이전 시점에 다른 정보를 알고 있어야 하는 불변의 비즈니스 데이터의 경우)  
- 하지만 대부분의 앱에서는... 필요하지 않음   
  
### mannyv   
- **우리 전체 백엔드는 큐 기반**임   
- 비동기식이고 빠른 응답 시간이 필요하지 않은 경우 큐를 사용할 것. 쉽고 안정적이며 큐가 람다를 구동할 수 있음   
- 또한 큐를 사용하면 메트릭과 성능 데이터를 더 쉽게 수집 가능.   
  - 부하가 많을 때는 큐에 최대 수백만 개의 메시지까지 부풀어 올랐다가 시간이 지나면서 줄어들게 되고,   
  - 또는 원하는 대로 수백 개의 람다를 생성하여 모든 메시지를 처리할 수도 있음   
  
### vishnugupta   
- 내 경험에 비추어 볼 때 **MQ는 추상화 되어 버린거지, 사라지지는 않았음**   
- 예를 들어 SQS + 폴링에 대한 대기열은 서버를 적게 호출하는 프로세스가 되었음. 어딘가에 메시지 큐가 있지만 노출되지 않았을 뿐  
- SQS보다 한 단계 더 추상화된 AWS SNS는 기능이 매우 풍부해져서 사실상 SQS를 대체할 수 있게 되었음   
- 또한 **스트리밍은 매우 안정적인 기술이 되었기 때문**에 **큐를 스트리밍 파이프**로 사용하던 사용 사례는 **스트리밍 전용으로 마이그레이션** 되었음   
  
### memset   
- 람다(클라우드 펑션)이 더 대중화되고 여러 플랫폼에서 지원되기 때문 일 수 있음   
- 무언가를 큐에 추가하면 결국 큐에서 빼내고 처리해야 함. 람다는 한 번의 호출로 이 작업을 수행. 또한 워커를 실행하거나 확장할 필요가 없음   
- Kafka는 임시 데이터 저장소로 사용되고, 스트림에서 수집하는 데 큰 생태계가 있기 때문에 계속 인기를 누리고 있다고 생각  
- 나는 개인적으로 큐를 많이 사용하며 오픈 소스 SQS 대안을 구축하고 있음. 오픈 소스 람다 대체도 유용할지 궁금  
  
### liampulles   
- "**이제 MQ 기술이 성숙기에 접어들어서, 사람들이 관련 글을 쓸만큼 흥미롭지는 않음. 하지만 여전히 널리 사용되고 있음**"  
  - 이게 맞음. 간단한 Pub/Sub 메시징을 사용하는 비동기 통신의 간단한 사용 사례는 매우 유용하고 사용하기가 너무 어렵지 않다고 생각  
- 우리(개발자 커뮤니티로서)는 이벤트 소싱, 복잡한 네트워크 및 불필요한 규모 구축을 극복했음. 즉, 우리는 과대광고 주기를 지났음   
- 우리 팀은 비동기 Pub/Sub 및 동기 Request/Response에 NATS를 사용  
  - 이는 명령 기반 모델이며 우리가 보낸 모든 메시지가 포함된 거대한 로그 테이블을 가지고 있음  
  - 스키마와 이러한 메시지의 사용은 우리 팀 내부적이며, 사용 후 NATS에서 삭제됨  
  - 우리는 at-least-once delivery를 하며 메시지 핸들러는 멱등성을 가질 것으로 예상함   
- NATS의 잘못된 구성으로 인해 메시지가 재생되거나 메시지가 누락되는 문제가 한두 가지 있었지만 대체로 매우 성공적이었고, 우리는 3명으로 구성된 개발팀이었음  
- **내 생각에는 Kubernetes와 같은 것임. 핵심만 지키고 영리하게 노력하지 않으면 잘 작동함**

## Comments



### Comment 26601

- Author: finnchoi
- Created: 2024-06-25T21:35:05+09:00
- Points: 1

큐가 필요한 적절한 상황이 있습니다. 그러나 대부분의 규모와 사용 형태에서는 큐를 사용하거나 클러스터를 구성해서 동작시키는 것이 복잡도 상승과 성능면에서는 크게 장점이 없는 경우가 많습니다. 확장성과 대규모 데이터를 고려하여 구성된 큰 기업들이 자랑하는 복잡한 구조가 나의 시스템에 적절해질 시점은 도래하지 않을 수 있습니다.  
  
기술적으로 매력도가 높은 신기술과 멋진 구조도 현실적인 문제를 고민하여 적절한 솔루션을 선택하는 것이 필요합니다. 대부분의 경우에는 처리할 큰 데이터도 없고, PostgreSQL로 처리 가능한 경우도 많습니다.  
  
저희는 이런 문제를 인식하고 단순한 구조에서 TB 단위의 데이터를 단일 노드에서 처리 가능한 DB를 개발하고 있습니다. 조금은 조심스럽지만, 또 다른 옵션으로 살펴보시는 것을 권해 드립니다.  
[판례 데이터를 빠르게 검색 가능한 상태로 만들기](https://www.aeca.ai/ko/blog/posts/2024-06-21-demo-law)

### Comment 26521

- Author: dakbutfly
- Created: 2024-06-24T09:07:14+09:00
- Points: 1

대중적으로 절차지향은 이해하기 쉬우나 MQ 방식은 바로 와 닿지 않거나, 구조를 이해 하는데 어려움이 있다고 생각 합니다. 회사는 일반적으로 지식 수준이 동일 하지 않은 경우가 더러 있는데, 이때 잘못된 지식으로 MQ 를 쓰면 지옥이 되는 것 같습니다.   
  
이거는 MQ 뿐만 아니라 대부분 어느 정도 지식을 요구 하는 기술들이 전반적인 교육 없이 적용 했을 때 늘 발생하는 문제라고 생각 합니다.

### Comment 26466

- Author: nemorize
- Created: 2024-06-21T19:31:14+09:00
- Points: 1

PHP는 MQ가 사실상 필수...

### Comment 26463

- Author: halfenif
- Created: 2024-06-21T18:00:04+09:00
- Points: 1

뜨끔!  
  
지금 Toy Project로 Quee라는 이름이 들어간 것을 진행하고 있는데 말입니다.

### Comment 26459

- Author: kandk
- Created: 2024-06-21T13:23:14+09:00
- Points: 1

솔직히 99%의 우리나라 내에서만 서비스할꺼면 다 필요없다고 봅니다..

### Comment 26462

- Author: superwoou
- Created: 2024-06-21T17:17:31+09:00
- Points: 1
- Parent comment: 26459
- Depth: 1

서비스 범위 보다는 서비스 성질/얼마나 비용 효율을 따져야 하느냐가 중요하지 않을까요?

### Comment 26467

- Author: [hidden]
- Created: 2024-06-21T19:49:44+09:00
- Points: 1
- Parent comment: 26462
- Depth: 2

[숨김 처리된 댓글입니다]

### Comment 26472

- Author: bus710
- Created: 2024-06-22T00:07:47+09:00
- Points: 1
- Parent comment: 26467
- Depth: 3

아무래도 결정을 내리는 절차가 수직적이기 때문에 “절차지향적”인 것이 더 선호 되거나 적합하게 여겨지는 것일까요?  
만약 각 부서와 팀이 느슨하게 조직되어 있다면 절차지향적이지 않은 아키텍쳐가 좀 더 원활히 동작하고, 그래서 이런 큐들의 응용이 더 잘 동작할 수 있는 것일지 궁금하네요.

### Comment 26457

- Author: savvykang
- Created: 2024-06-21T12:04:56+09:00
- Points: 1

이력서 주도 개발이 이런 유행 현상을 관통하는 키워드인 것 같네요

### Comment 26487

- Author: hyeonseokoh94
- Created: 2024-06-22T15:40:16+09:00
- Points: 1
- Parent comment: 26457
- Depth: 1

이야 명언이네요 이력서 주도 개발이라..

### Comment 26509

- Author: savvykang
- Created: 2024-06-23T12:22:55+09:00
- Points: 1
- Parent comment: 26487
- Depth: 2

자매품으로 [설레발 주도 개발](https://lazygyu.net/blog/hype_driven_development)도 있습니다