맨먼스 미신, 50년 전 그 책을 다시 읽고 깨달은 현대 개발의 진실

"맨먼스 미신"의 교훈이 현대 소프트웨어 개발에 어떻게 적용되는지 심층 분석합니다. 50년 전 프레데릭 브룩스의 통찰이 오늘날 복잡한 프로젝트를 성공으로 이끄는 핵심 전략이 될 수 있음을 시니어 개발자의 관점에서 재조명합니다.

촉박한 마감, 늘어나는 인력, 반복되는 실패: 현대 소프트웨어 개발 팀의 고질적인 문제 상황은 과연 해결책이 없는가? 수많은 프로젝트가 예산과 일정을 초과하고, 결국 기대에 미치지 못하는 결과물을 내놓는 현실은 개발 업계에 만연한 현상으로 인식된다. 특히, 프로젝트가 지연될 때 인력을 추가 투입하는 방식은 단기적인 해결책처럼 보이지만, 실제로는 더 큰 혼란과 지연을 초래하는 경우가 허다하다.

이러한 문제의 근원을 탐색하고자 할 때, 우리는 50년 전 프레데릭 브룩스(Frederick Brooks Jr.)가 저술한 명저 맨먼스 미신(The Mythical Man-Month)으로 회귀하게 된다. 이 책은 소프트웨어 공학 분야의 고전으로, 오늘날에도 여전히 유효한 깊은 통찰을 제공한다. 본 글에서는 이 고전이 제시하는 핵심 교훈들을 재조명하고, 현대 소프트웨어 개발 환경에서 겪는 문제 상황에 어떻게 적용하여 해결책을 모색할 수 있는지 시니어 개발자의 관점에서 심층적으로 분석하고자 한다.

📑 목차

• 맨먼스 미신의 핵심 통찰 재확인: '사람과 시간'의 비선형성
• 브룩스의 법칙과 분산 시스템의 복잡성
• 의사소통 비용의 증대와 팀 규모의 한계
• 현대 소프트웨어 개발의 고질적인 문제 상황: '늦은 프로젝트에 사람 더 투입'의 함정
• 문제 해결을 위한 전략적 접근 1: 초기 단계의 철저한 개념화와 일정 관리
• 문제 해결을 위한 전략적 접근 2: 팀 구성과 커뮤니케이션 효율 극대화
• 작은 자율 팀의 중요성: 'Two-Pizza Team'을 넘어서
• 구조화된 커뮤니케이션 채널과 문서화의 역할
• 문제 해결을 위한 전략적 접근 3: 기술적 부채 관리와 개발 환경 최적화
• 결론: 50년 전 교훈, 현대 소프트웨어 개발의 나침반

Image by StockSnap on Pixabay

맨먼스 미신의 핵심 통찰 재확인: '사람과 시간'의 비선형성

맨먼스 미신의 가장 핵심적인 메시지는 브룩스의 법칙(Brooks's Law)으로 집약된다. 이는 "늦어진 소프트웨어 프로젝트에 인력을 추가하면 프로젝트는 더 늦어진다"는 명제이다. 이 법칙은 소프트웨어 개발 프로젝트의 특수성을 명확히 보여준다. 제조업과 달리, 소프트웨어 개발은 단순히 인력을 늘린다고 해서 생산량이 비례하여 증가하지 않는 비선형적인 특성을 지니기 때문이다.

브룩스는 이를 맨먼스(man-month)라는 개념의 허구성을 지적하며 설명한다. 한 사람이 한 달 동안 할 수 있는 작업량을 의미하는 맨먼스는, 작업이 개별적으로 독립적이고 분할 가능할 때만 유효하다. 그러나 소프트웨어 개발은 본질적으로 복잡하고 상호의존적인 작업의 연속이다. 새로운 인력이 투입되면, 기존 팀원들은 그들을 교육하고, 프로젝트의 복잡한 맥락을 설명하며, 의사소통 채널을 추가로 관리해야 하는 커뮤니케이션 오버헤드(Communication Overhead)가 발생한다. 이 오버헤드는 팀 규모가 커질수록 기하급수적으로 증가하며, 결과적으로 팀 전체의 생산성을 저해하는 요인이 된다.

브룩스의 법칙과 분산 시스템의 복잡성

현대 소프트웨어 개발은 마이크로서비스 아키텍처, 클라우드 기반 시스템, 분산 팀 등 더욱 복잡한 환경에서 이루어진다. 이러한 환경은 맨먼스 미신이 지적하는 문제들을 더욱 증폭시킨다. 예를 들어, 여러 서비스 간의 의존성 관리, 분산 트랜잭션 처리, 일관성 유지 등은 그 자체로 상당한 복잡성을 내포한다. 여기에 뒤늦게 인력을 투입할 경우, 각 서비스의 비즈니스 로직과 기술 스택을 이해하는 데 필요한 시간은 상상을 초월한다. 이는 단순히 코드 라인을 추가하는 작업을 넘어, 시스템 전체의 아키텍처적 이해와 동기화가 필수적이기 때문이다.

브룩스는 이 책에서 "개념적 통합(Conceptual Integrity)"의 중요성을 강조한다. 이는 시스템의 설계 원칙과 아키텍처가 일관성을 유지해야 한다는 의미인데, 불필요한 인력 증가는 이러한 개념적 통합을 해치고 시스템 전체의 복잡도를 높이는 결과를 초래한다.

의사소통 비용의 증대와 팀 규모의 한계

팀 규모가 N명일 때, 가능한 의사소통 채널의 수는 N*(N-1)/2로 계산된다. 즉, 5명일 때는 10개, 10명일 때는 45개로 급증한다. 새로운 인원이 추가될 때마다 기존 팀원들은 더 많은 사람과 정보를 공유하고 동기화해야 한다. 이러한 의사소통 비용은 프로젝트의 진행 속도를 늦추고, 중요한 결정이 지연되며, 심지어는 오류 발생 가능성을 높이는 주범으로 작용한다.

이러한 현상은 특히 원격 근무나 하이브리드 근무 환경에서 더욱 두드러질 수 있다. 비동기식 커뮤니케이션이 주를 이루는 환경에서는 정보의 불균형이 발생하기 쉽고, 이는 다시 동기화를 위한 추가적인 노력과 시간을 요구하게 된다. 따라서 맨먼스 미신은 단순히 과거의 이야기가 아니라, 현대의 복잡한 팀 환경을 이해하고 관리하는 데 필수적인 지침을 제공한다.

현대 소프트웨어 개발의 고질적인 문제 상황: '늦은 프로젝트에 사람 더 투입'의 함정

소프트웨어 개발 프로젝트에서 "늦어진 프로젝트에 사람을 더 투입"하는 결정은 종종 경영진이나 프로젝트 관리자가 직면하는 가장 흔한 유혹 중 하나이다. 이는 겉으로는 가장 직관적이고 효과적인 해결책처럼 보이지만, 실제로는 프로젝트를 더 깊은 수렁에 빠뜨리는 악순환의 시작이 될 수 있다.

이러한 접근 방식이 실패로 이어지는 주요 원인은 다음과 같다:

• 새로운 인력의 생산성 기여까지의 시간 지연 (Ramp-up Time): 새로운 개발자는 프로젝트의 코드베이스, 아키텍처, 비즈니스 로직, 팀 문화 및 도구에 익숙해지는 데 상당한 시간이 필요하다. 이 기간 동안 기존 팀원들은 새로운 인력을 온보딩하고 교육하는 데 귀중한 시간을 할애해야 한다.
• 증가하는 의사소통 오버헤드: 앞서 언급했듯이, 팀 규모가 커질수록 팀원 간의 의사소통 경로는 기하급수적으로 증가한다. 이는 회의 시간 증가, 문서화 및 정보 공유 노력 증대, 그리고 오해와 충돌 가능성 증대로 이어진다.
• 작업 분할의 어려움: 소프트웨어 개발 작업은 종종 긴밀하게 연결되어 있어, 독립적인 단위로 쉽게 분할하기 어렵다. 새로운 인력이 투입되더라도, 이미 진행 중인 복잡한 작업에 의미 있게 기여하기는 쉽지 않으며, 오히려 기존 작업의 흐름을 방해할 수 있다.
• 기술 부채의 심화: 촉박한 일정 속에서 새로운 인력이 투입되면, 단기적인 기능 구현에만 집중하게 되어 코드 품질 저하, 부실한 설계, 불충분한 테스트 등으로 이어질 수 있다. 이는 장기적으로 기술 부채를 증가시키고 유지보수 비용을 상승시키는 결과를 초래한다.

다음 표는 늦어진 프로젝트에 인력을 추가 투입했을 때 기대되는 효과와 실제 발생하는 결과 사이의 간극을 보여준다.

기대되는 효과	실제 발생하는 결과
프로젝트 완료 시간 단축	새 인력 온보딩 및 커뮤니케이션 오버헤드로 인한 지연 심화
작업 병렬 처리로 생산성 증대	작업 분할의 어려움과 복잡성 증가, 충돌 발생 가능성 증대
팀원 부담 감소 및 사기 진작	기존 팀원의 온보딩 부담 가중, 스트레스 증가 및 사기 저하
더 많은 리소스 투입으로 문제 해결	근본적인 문제(설계 결함, 비현실적 일정) 해결되지 않고 표면화

이러한 함정을 피하기 위해서는 문제 발생 시 단순히 인력 증원에 의존하기보다, 근본적인 원인을 파악하고 구조적인 해결책을 모색하는 것이 필수적이다.

문제 해결을 위한 전략적 접근 1: 초기 단계의 철저한 개념화와 일정 관리

맨먼스 미신은 소프트웨어 개발의 초기 단계, 즉 개념화(Conceptualization)와 설계(Design)의 중요성을 강력하게 역설한다. 브룩스는 "프로젝트 수명의 1/3을 설계에 할애하라"고 조언하며, 이는 현대의 애자일(Agile) 방법론 맥락에서도 여전히 유효한 원칙으로 해석될 수 있다.

계획 오류(Planning Fallacy)는 인간의 인지적 편향으로, 미래의 과업을 완료하는 데 필요한 시간을 과소평가하는 경향을 말한다. 시니어 개발자는 이러한 편향을 인지하고, 초기 단계에서 충분한 시간을 들여 다음 요소들을 고려해야 한다.

• 요구사항 명확화: 모호한 요구사항은 프로젝트 후반에 재작업의 주된 원인이 된다. 시니어 개발자는 비즈니스 이해관계자와 긴밀히 협력하여 요구사항을 명확하고, 측정 가능하며, 달성 가능하고, 관련성 있으며, 시간 제한이 있는(SMART) 형태로 정의해야 한다. 사용자 스토리(User Story)나 유스케이스(Use Case)를 통해 구체적인 시나리오를 정의하고, 예외 상황까지 고려하는 것이 중요하다.
• 현실적인 예측과 견적: 과거 프로젝트 데이터, 전문가 판단, 다양한 예측 기법(예: 와이드밴드 델파이, 플래닝 포커)을 활용하여 현실적인 개발 일정을 수립해야 한다. 특히, 불확실성이 높은 작업에 대해서는 스파이크(Spike)나 프로토타입(Prototype)을 통해 미리 탐색하고 리스크를 줄이는 노력이 필요하다.
• 설계 검토와 피드백: 초기 설계 단계에서 아키텍처 검토(Architecture Review)를 통해 잠재적인 문제점을 사전에 발견하고 해결해야 한다. 다양한 관점의 피드백을 수렴하여 설계의 견고성을 확보하는 것이 중요하다. 이는 나중에 코드를 재작성하는 것보다 훨씬 효율적이다.

애자일 방법론에서는 전체 프로젝트의 상세한 계획보다는 짧은 주기의 스프린트(Sprint) 계획을 강조하지만, 이는 '계획의 부재'를 의미하지 않는다. 오히려 각 스프린트 내에서 "완료의 정의(Definition of Done)"를 명확히 하고, 스프린트 백로그(Sprint Backlog)를 상세하게 정의하며, 스파이크(Spike)를 통해 기술적 불확실성을 해소하는 과정 자체가 초기 단계의 철저한 개념화와 일정 관리의 현대적 적용이라 할 수 있다.

다음 표는 전통적인 워터폴(Waterfall) 방식과 애자일 방식에서 브룩스의 법칙을 피하기 위한 초기 계획 접근 방식의 차이를 보여준다.

특징	워터폴 방식 (전통적)	애자일 방식 (현대적 적용)
계획의 범위	프로젝트 전체의 상세 계획	짧은 스프린트 단위의 상세 계획 및 전체 로드맵
요구사항 정의	초기에 모든 요구사항을 완벽히 정의	지속적인 발견 및 개선, 백로그 정제를 통해 발전
리스크 관리	초기 단계에서 광범위한 리스크 분석	스프린트마다 리스크 재평가, 스파이크를 통한 불확실성 해소
시니어 개발자의 역할	아키텍처 설계 및 기술 리딩	백로그 정제, 기술 리딩, 멘토링, 복잡성 예측

결론적으로, 초기 단계의 신중한 접근과 지속적인 검토는 프로젝트 후반에 발생할 수 있는 대규모 지연을 예방하는 가장 효과적인 방법이며, 이는 맨먼스 미신이 강조하는 핵심 교훈 중 하나이다.

Image by pixelcreatures on Pixabay

문제 해결을 위한 전략적 접근 2: 팀 구성과 커뮤니케이션 효율 극대화

맨먼스 미신은 수술 팀(Surgical Team) 개념을 제시하며, 작은 규모의 전문가 팀이 대규모 팀보다 더 효율적일 수 있음을 시사한다. 이는 현대의 두 피자 팀(Two-Pizza Team) 개념, 즉 피자 두 판으로 먹을 수 있을 정도의 소규모 팀이 가장 효과적이라는 아마존(Amazon)의 철학과도 맥을 같이 한다.

팀 규모의 최적화는 커뮤니케이션 오버헤드를 줄이고, 각 팀원의 책임감을 높이며, 의사결정 속도를 빠르게 하는 핵심 요소이다. 일반적으로 5~9명 정도의 팀 규모가 가장 효율적인 것으로 알려져 있다. 이러한 소규모 팀은 다음과 같은 방식으로 효율성을 극대화할 수 있다.

• 명확한 역할과 책임: 각 팀원이 자신의 역할과 책임을 명확히 인지하고, 중복되거나 누락되는 작업 없이 효율적으로 협업할 수 있도록 한다. 풀스택 개발자나 T자형 인재를 육성하여 팀 내 기술적 다양성과 유연성을 확보하는 것도 중요하다.
• 높은 응집력과 낮은 결합도: 팀은 특정 비즈니스 도메인이나 서비스에 대한 깊은 이해를 바탕으로 높은 응집력을 가져야 한다. 동시에 다른 팀과의 의존성은 낮추어(낮은 결합도) 자율적으로 의사결정하고 개발을 진행할 수 있도록 한다. 마이크로서비스 아키텍처는 이러한 팀 구성 원칙을 기술적으로 뒷받침하는 좋은 예시이다.
• 효율적인 커뮤니케이션 도구와 문화: 슬랙(Slack), 마이크로소프트 팀즈(Microsoft Teams)와 같은 협업 도구를 활용하여 비동기식 커뮤니케이션의 효율성을 높이고, 필요한 경우 화상 회의를 통해 실시간 소통을 보완한다. 또한, 솔직하고 투명한 피드백 문화와 지식 공유를 장려하여 팀 전체의 학습 곡선을 가속화한다.

작은 자율 팀의 중요성: 'Two-Pizza Team'을 넘어서

두 피자 팀 모델은 단순히 팀 규모를 줄이는 것을 넘어, 팀에게 높은 자율성과 책임감을 부여하는 데 초점을 맞춘다. 팀 스스로가 제품의 생명주기 전체를 책임지고, 필요한 결정을 내릴 수 있도록 권한을 위임하는 것이다. 이는 팀원들의 동기 부여를 높이고, 혁신을 장려하며, 시장 변화에 더욱 빠르게 대응할 수 있게 한다.

예를 들어, 특정 마이크로서비스를 전담하는 팀은 해당 서비스의 설계, 개발, 배포, 운영, 모니터링까지 모든 과정을 책임진다. 이 팀은 다른 팀의 승인 없이도 서비스 개선을 위한 결정을 내릴 수 있으며, 이는 전반적인 개발 속도와 품질 향상에 기여한다.

구조화된 커뮤니케이션 채널과 문서화의 역할

팀 규모가 작더라도, 효과적인 커뮤니케이션은 여전히 중요하다. 맨먼스 미신은 문서화의 중요성을 강조하며, 이는 단순히 코드 주석을 넘어 아키텍처 문서, 설계 명세, API 문서 등 다양한 형태의 문서화를 포함한다. 문서화는 팀원 간의 지식 공유를 용이하게 하고, 새로운 인력이 빠르게 프로젝트에 적응하도록 돕는 중요한 도구이다.

또한, 정기적인 스탠드업 미팅, 스프린트 리뷰, 회고와 같은 구조화된 커뮤니케이션 채널을 통해 팀원 간의 진행 상황을 공유하고, 문제점을 조기에 식별하며, 지속적인 개선을 위한 논의를 진행할 수 있다. 이러한 노력은 커뮤니케이션 오버헤드를 최소화하면서도, 팀의 응집력과 생산성을 극대화하는 데 기여한다.

Image by crisnzeta5 on Pixabay

문제 해결을 위한 전략적 접근 3: 기술적 부채 관리와 개발 환경 최적화

브룩스는 "은총알은 없다(No Silver Bullet)"고 단언하며, 소프트웨어 개발의 본질적인 복잡성을 해결할 마법 같은 단일 솔루션은 존재하지 않는다고 강조했다. 이는 현대 개발에서도 여전히 유효한 통찰이다. 대신, 우리는 복잡성을 관리하고 생산성을 높이기 위한 지속적인 노력과 다양한 기술적 접근 방식을 결합해야 한다.

이러한 맥락에서 기술 부채(Technical Debt)의 효과적인 관리와 개발 환경의 지속적인 최적화는 프로젝트 지연을 방지하고 개발 효율성을 높이는 데 필수적인 전략이다.

• 기술 부채의 적극적인 관리: 기술 부채는 단기적인 이점을 위해 장기적인 유지보수 비용을 감수하는 결정에서 발생한다. 시니어 개발자는 기술 부채를 명확히 인지하고, 이를 주기적으로 리팩토링(Refactoring)하며 해결하는 시간을 확보해야 한다. 누적된 기술 부채는 코드 변경의 어려움을 가중시키고, 버그 발생률을 높이며, 새로운 기능 추가를 지연시키는 주된 원인이 된다. 이는 마치 '빨리 가기 위해 빚을 내는 것'과 같아서, 결국 이자 부담(유지보수 비용)이 원금(개발 시간)을 초과하게 된다.
• 자동화와 CI/CD 파이프라인 구축: 반복적이고 오류 발생 가능성이 높은 작업은 최대한 자동화해야 한다. 지속적 통합(CI/Continuous Integration)과 지속적 배포(CD/Continuous Deployment) 파이프라인은 코드 변경이 발생할 때마다 자동으로 빌드, 테스트, 배포를 수행하여 개발 속도를 높이고 수동 작업에서 발생하는 오류를 줄인다. 이는 개발자들이 핵심적인 문제 해결에 집중할 수 있도록 돕는다.
• 강력한 테스트 전략 수립: 단위 테스트, 통합 테스트, 시스템 테스트 등 다양한 수준의 테스트를 효과적으로 구축하고 유지하는 것은 소프트웨어 품질을 보장하고 버그를 조기에 발견하는 데 필수적이다. 잘 정의된 테스트 스위트(Test Suite)는 코드 변경에 대한 안전망 역할을 하며, 개발자들이 자신감을 가지고 리팩토링 및 기능 추가를 할 수 있도록 지원한다.
• 개발 환경 및 도구 최적화: 개발자들이 사용하는 IDE, 버전 관리 시스템, 협업 도구 등 모든 개발 환경과 도구가 최적의 상태로 유지되어야 한다. 예를 들어, 최신 버전의 개발 도구를 사용하고, 공통적인 개발 스택을 표준화하며, 온프레미스(On-premise) 환경에서 클라우드(Cloud) 환경으로의 전환을 통해 인프라 관리 부담을 줄이는 등의 노력이 포함된다.

기술 부채는 프로젝트를 늦추는 잠재적 요인이며, 여기에 인력을 추가 투입하더라도 기존의 복잡성과 비효율성은 사라지지 않는다. 오히려 새로운 인력은 난해한 코드베이스와 부실한 인프라에 적응하는 데 더 많은 시간을 소모하게 되어, 브룩스의 법칙이 더욱 강력하게 작용하는 결과를 초래한다.

다음은 간단한 예시로, 자동화된 테스트를 통해 기술 부채를 줄이고 개발 효율성을 높이는 방법을 보여준다. (Python 예시)

# product_service.py
class ProductService:
    def get_product_details(self, product_id):
        # 복잡한 비즈니스 로직 및 DB 호출
        if product_id == "P001":
            return {"id": "P001", "name": "Laptop", "price": 1200}
        elif product_id == "P002":
            return {"id": "P002", "name": "Mouse", "price": 25}
        else:
            return None

# test_product_service.py (테스트 코드)
import unittest
from product_service import ProductService

class TestProductService(unittest.TestCase):
    def setUp(self):
        self.service = ProductService()

    def test_get_existing_product(self):
        product = self.service.get_product_details("P001")
        self.assertIsNotNone(product)
        self.assertEqual(product["name"], "Laptop")

    def test_get_non_existing_product(self):
        product = self.service.get_product_details("P999")
        self.assertIsNone(product)

    def test_product_price_type(self):
        product = self.service.get_product_details("P001")
        self.assertIsInstance(product["price"], (int, float))

if __name__ == '__main__':
    unittest.main()

이러한 테스트 코드는 리팩토링이나 기능 변경 시 기존 로직이 손상되지 않았음을 빠르게 검증할 수 있게 하여, 기술 부채의 발생을 억제하고 개발자의 자신감을 높인다. 지속적인 테스트 커버리지 확보는 맨먼스 미신이 강조하는 '설계에 충분한 시간 투자'와 '오류 조기 발견'의 현대적 구현이라 할 수 있다.

결론: 50년 전 교훈, 현대 소프트웨어 개발의 나침반

프레데릭 브룩스의 맨먼스 미신은 50년이라는 시간을 뛰어넘어 현대 소프트웨어 개발의 복잡한 문제 상황에 여전히 깊은 통찰을 제공하는 살아있는 고전이다. "늦어진 프로젝트에 인력을 추가하면 더 늦어진다"는 브룩스의 법칙은 단순히 과거의 경고가 아니라, 오늘날에도 우리가 직면하는 수많은 프로젝트 실패의 근본 원인을 설명하는 핵심 원리이다.

우리는 이 책의 교훈을 통해 다음과 같은 현대적 해결책을 도출하고 적용할 수 있다.

1. 초기 단계의 철저한 개념화와 현실적인 일정 관리: 요구사항을 명확히 하고, 현실적인 예측을 수립하며, 초기 설계에 충분한 시간을 투자하는 것이 프로젝트 후반의 재앙을 막는 가장 효과적인 방법이다. 애자일 환경에서는 백로그 정제, 스파이크 등을 통해 이를 구현한다.
2. 팀 구성의 최적화와 커뮤니케이션 효율 극대화: 두 피자 팀과 같은 소규모, 자율적인 팀 구성을 통해 커뮤니케이션 오버헤드를 최소화하고, 팀 응집력을 높여 생산성을 극대화한다. 명확한 역할 정의와 효율적인 문서화는 이를 뒷받침한다.
3. 기술 부채 관리와 개발 환경 최적화: 은총알은 없다는 원칙을 이해하고, 기술 부채를 적극적으로 관리하며, 자동화된 CI/CD 파이프라인, 강력한 테스트 전략, 최적화된 개발 도구를 통해 개발 효율성을 지속적으로 개선해야 한다.

맨먼스 미신은 기술적 해결책보다 인간과 시스템의 본질적인 복잡성에 대한 이해를 강조한다. 시니어 개발자라면 이 책을 단순한 고전으로 치부할 것이 아니라, 현재 자신이 이끄는 프로젝트와 팀에 어떤 시사점을 주는지 끊임없이 재고해야 한다. 50년 전의 교훈은 여전히 우리의 개발 여정을 성공으로 이끄는 강력한 나침반이 될 수 있기 때문이다.

여러분은 맨먼스 미신의 어떤 교훈이 현대 개발에 가장 중요하다고 생각하시나요? 혹은 이 책의 원칙들을 실제 프로젝트에 적용하며 어떤 경험을 하셨는지 댓글로 공유해 주시면 감사하겠습니다.

📌 함께 읽으면 좋은 글

• [튜토리얼] 다양한 기기 이미지 업로드, 방향/크기 불일치 문제 깔끔하게 해결하는 법
• [이슈 분석] 조직 내 개발 효율을 극대화하는 InnerSource 도입 전략
• [개발 도구] Go 애플리케이션 메모리 누수, pprof만으로 부족했던 심층 진단 직접 해보니

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.