복잡한 nginx 설정 파일, CDN 연동, 그리고 정적 파일 경로 문제로 골머리를 앓으신 적 있으신가요? Go 표준 라이브러리만으로도 정적 파일(CSS, JavaScript, 이미지 등)을 우아하게 서빙할 수 있습니다. 이번 글에서는 Go 웹 애플리케이션에서 static contents를 서빙하는 표준 패턴을 알아보겠습니다. http.FileServer, http.Dir, 그리고 http.StripPrefix의 조합만으로 프로덕션 레벨의 static file serving을 구현할 수 있습니다.

복잡한 리액트(React) 상태 관리, 비대해진 node_modules, 그리고 끝없는 JSON 직렬화/역직렬화에 지치셨나요? 백엔드 개발자에게 가장 편안한 언어인 Go 를 사용하면서도, 현대적인 SPA(Single Page Application) 같은 사용자 경험을 제공하는 GOTH 스택을 소개합니다.

Go 언어의 웹 생태계에서 net/http 와 chi 는 가장 ‘Go스러운(Idiomatic)’’ 선택지로 꼽힙니다. Gin이나 Echo 같은 ‘웹 프레임워크’와 달리, chi는 표준 라이브러리의 인터페이스를 그대로 따르면서 부족한 라우팅 기능을 보강해주는 ‘라우터’이기 때문입니다. 특히 Go 1.22 버전부터 net/http 의 라우팅 기능이 대폭 강화되었기 때문에, 이 둘의 차이를 명확히 이해하는 것이 중요합니다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

오늘날, 기본적인 코딩 기술은 더 많은 AI 토큰을 구매함으로써 채용될 수 있다. 당신은 그것을 기반으로 고용해서는 안 된다.

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다.

이 포스트는 Vertical Slicing Architecture와 Hexagonal Architecture의 개념과 특징을 단순히 나열하는 것을 넘어, 두 아키텍처의 근본적인 설계 철학, 해결하고자 하는 핵심 문제, 그리고 실제 프로젝트에 적용했을 때 발생하는 트레이드오프를 심층적으로 분석하는 것을 목표로 합니다. 각 아키텍처의 태동 배경, 장단점, 이상적인 적용 시나리오를 비교 분석하고, 실제 적용 사례를 통해 이론이 현실에서 어떻게 구현되는지 살펴볼 것입니다. 최종적으로는 독자들이 자신의 프로젝트 맥락과 당면 과제에 가장 적합한 아키텍처를 정보에 입각하여 선택할 수 있도록 실질적인 통찰과 가이드를 제공하고자 합니다.

만약 당신이 과속 운전을 한다면(원인), 당신은 교통 딱지를 받게 될 것입니다(결과).

일반적으로 상태를 변경하지 않는 메서드가 호출되었는지 검증하는 것은 피해야 합니다.

GitHub Spec Kit은 코드와 상호작용하는 AI 에이전트 및 모델 개발자를 위한 명세(spec) 모음입니다. 이 명세들은 AI 에이전트가 파일 시스템과 상호작용하고, 명령을 실행하며, 사용자와 소통하는 방식에 대한 모범 사례(best practice)를 정의합니다.

과도하게 중첩된 코드는 가독성을 해치고 오류를 발생시키기 쉽습니다.

만약 당신이 과속 운전을 한다면(원인), 당신은 교통 딱지를 받게 될 것입니다(결과).

End-to-end(E2E) 테스트는 시스템의 한쪽 끝에서 다른 쪽 끝까지, 그 사이의 모든 것을 블랙박스로 취급하며 전체 시스템을 테스트합니다. E2E 테스트는 시스템 전반에 걸쳐 나타나는 버그를 잡아낼 수 있습니다. 단위 테스트, 통합 테스트와 더불어 E2E 테스트는 균형 잡힌 테스트 식단의 핵심적인 부분이며, 운영 환경과 거의 유사한 상태에서 시스템의 건전성에 대한 확신을 줍니다.

Martin Fowler 의 ‘LLM과 소프트웨어 개발에 대한 몇 가지 생각’ 글을 번역했습니다.

이 글은 Quora 에 올라온 Rust 관련 질문과 답변을 Gemini 를 통해 번역한 것입니다.

본 포스트는 개발자들이 보다 견고하고 적응력 있는 소프트웨어 시스템을 구축할 수 있도록 돕는 것을 목표로 합니다. 이를 위해, 단순한 구문 리팩토링에서부터 정교한 아키텍처 패턴에 이르기까지 if-else를 대체할 수 있는 다양한 해결책을 심도 있게 탐구합니다.

본 연구 보고서는 오스터하우트와 마틴이 제시하는 두 가지 상이한 소프트웨어 설계 철학을 심층적으로 비교 분석하는 것을 목표로 한다. 두 철학은 단순히 기법의 차이를 넘어, 문제의 정의 자체에서부터 근본적인 시각차를 드러낸다. 오스터하우트는 시스템적 복잡성을 주된 적으로 간주하며, 이를 인지 부하(cognitive load)와 변경 증폭(change amplification)이라는 구체적인 지표로 측정한다. 반면, 마틴은 코드의 지역적 불명확성을 가장 경계해야 할 대상으로 보며, 이를 가독성(readability)과 이해 용이성(ease of comprehension)으로 평가한다.

Go 언어 프로젝트의 패키지 구조는 일반적으로 몇 가지 컨벤션을 따르며, pkg와 internal 디렉토리는 그중 핵심적인 역할을 합니다. 단순히 코드를 기능별로 묶는 것을 넘어, 패키지의 가시성(visibility)과 의존성 방향을 명확히 하여 프로젝트의 유지보수성을 높이는 것이 목적입니다.

변경 감지 테스트는 부정적인 가치(- value)를 제공합니다. 테스트가 어떤 결함도 잡아내지 못하면서, 추가적인 유지보수 비용이 개발 속도를 늦추기 때문입니다. 이러한 테스트는 다시 작성되거나 삭제되어야 합니다.