Public API 는 수많은 사용자에 의해 호출될 수 있으며, 사용자들은 메서드에 가능한 모든 입력 조합을 전달할 수 있습니다. 여러분은 이 API들이 잘 테스트되었는지 확인하고 싶을 것입니다. 그래야 사용자들이 API를 사용할 때 문제를 겪지 않을 것이기 때문입니다.

Go 언어의 특징을 소개하는 시리즈의 세 번째 글입니다. 이전 글에서는 Go의 단순성과 동시성에 대해 다루었습니다. 이번에는 Go가 ‘건전지 포함(Batteries Included)’ 철학을 어떻게 구현하고 있는지, 즉 강력하고 풍부한 표준 라이브러리에 대해 이야기하고자 합니다.

현대의 컴퓨터는 멀티코어 프로세서를 기반으로 작동하며, 동시성(Concurrency)은 더 이상 선택이 아닌 필수적인 프로그래밍 패러다임이 되었습니다. Go 언어는 설계 초기부터 동시성을 핵심 기능으로 채택했으며, 전통적인 스레드-락(Thread-Lock) 모델의 복잡성을 해결하기 위한 명확한 철학을 제시합니다.

테스트 이름에 시나리오와 예상 결과를 모두 넣는 것은 여러 가지 이점을 가집니다.

이 글에서는 Go의 핵심 철학인 ‘단순함’이 코드 수준에서 어떻게 드러나는지, 그리고 이 철학이 왜 어떤 개발자에게는 최고의 장점이 되고 다른 개발자에게는 답답한 단점으로 여겨지는지 가감 없이 살펴보겠습니다.

진 킴(Gene Kim)과 스티브 예지(Steve Yegge)가 집필중인 책, ‘VIBE CODING: BUILDING PRODUCTION-GRADE SOFTWARE WITH GENAI, CHAT, AGENTS, AND BEYOND’ 의 현재까지 공개된 목차와 서문 내용을 알아봅니다.

바이브 코딩은 요즘 소프트웨어 개발의 시대정신일지 모르지만, AI와 함께 바이브를 타는 것이 늘 좋은 것만은 아닙니다. 다음은 지나치게 낙관적인 바이브 코더들이 실패할 수 있는 9가지 방법입니다.

최근 증강 코딩을 사용하여 B+ 트리 라이브러리를 구축하려는 야심 찬 프로젝트에서 좋은 마무리를 지었습니다. 그 결과물은 BPlusTree3 - Rust 및 Python으로 구현된 성능 경쟁력이 있고, 어쩌면 프로덕션에 즉시 사용 가능한 구현입니다. 저는 친구와 앉아 저의 이야기를 나누고 GenAI 시대의 프로그래밍 미래에 대해 무엇을 시사하는지 생각해 보았습니다.

Claude, Gemini, GitHub Copilot과 같은 LLM(거대 언어 모델) 기반 코딩 도구들은 이제 단순히 코드 스니펫을 자동 완성해주는 수준을 넘어, 우리의 생각을 논리적으로 설명하면 프로젝트 전체의 구조를 짜고 방대한 양의 코드를 순식간에 만들어냅니다. 생산성의 혁신이라 부를 만한 이 변화는 분명 경이롭습니다. 하지만 이 강력한 도구에 과도하게 의존하기 시작하면서, 우리는 이전에 겪어보지 못한 새로운 종류의 문제들에 직면하고 있습니다. 밝은 빛이 강할수록 그림자도 짙어지는 법입니다. 이 글에서는 LLM 기반 코딩에 대한 의존이 개발자 개인과 팀에 미칠 수 있는 5가지 잠재적 위험을 심도 있게 다뤄보고자 합니다.

존 오스터하우트의 ‘소프트웨어 설계의 철학’은 소프트웨어 복잡성을 줄이고 유지 관리가 용이한 코드를 작성하는 방법에 대한 심도 있는 통찰력을 제공합니다. 21개 챕터에 걸쳐 저자는 복잡성의 본질을 분석하고, 효과적인 모듈 설계를 위한 원칙을 제시하며, 코드의 가독성과 명확성을 높이는 구체적인 기법들을 소개합니다.

프로그래밍 언어는 우리에게 많은 표현력을 제공합니다. 연산자와 조건문 같은 개념들은 광범위한 입력을 처리하는 프로그램을 작성할 수 있게 해주는 중요한 도구입니다. 하지만 이러한 유연성은 복잡성 증가라는 대가를 치르게 하여, 우리 프로그램을 이해하기 어렵게 만듭니다.

이 글에서는 LLM을 활용한 Vibe-Coding 시대에 Go 언어가 가지는 장점들을 알아봅니다.

서버가 과부하되었다는 소식이 들려왔습니다. 사람들은 왜 Gemini CLI에 그렇게 열광하는 걸까요? 우리는 이미 웹과 데스크톱에서 사용할 수 있는 ChatGPT와 Claude, 그리고 Cursor와 Windsurf 같은 코딩 AI 도구, 심지어 Lovable과 V0 같은 바이브 코딩 도구까지 가지고 있습니다. 터미널 기반의 새로운 CLI 기반 AI가 이 시장에 어떤 영향을 미칠 수 있을까요?

테스트는 목적을 위한 수단입니다: 프로젝트의 주요 위험을 줄이고, 가장 큰 효과를 얻기 위함입니다. 이 효과는 항상 표준 관행에 따라 작성하는 테스트에서 나오지 않을 수 있으며, 심지어 테스트에서 전혀 나오지 않을 수도 있습니다.

개별 단위 테스트를 작성하든 제품의 전체 테스트 프로세스를 설계하든, 테스트가 코드의 버그를 얼마나 효과적으로 감지하고 보고하는지 다시 한번 생각해보는 것이 중요합니다. 효과적이려면 모든 테스트가 극대화하려고 노력해야 하는 세 가지 중요한 품질이 있습니다.

메서드를 작성한 후 메서드가 수행하는 모든 작업을 확인하는 테스트를 하나만 작성하기 쉽습니다. 그러나 테스트와 public 메서드가 1:1 관계를 가져야 한다고 생각하는 것은 해로울 수 있습니다. 우리가 정말로 테스트하고 싶은 것은 동작이며, 단일 메서드가 여러 동작을 나타낼 수 있고, 단일 동작이 때로는 여러 메서드에 걸쳐 있을 수도 있습니다.

단위 테스트는 코드의 정확성을 확인하는 중요한 도구입니다. 그러나 좋은 테스트를 작성하는 것은 단순히 정확성을 확인하는 것 이상입니다. 좋은 단위 테스트는 읽기 쉽고 유지 보수 가능하도록 여러 다른 속성을 보여야 합니다.

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

단위 테스트가 테스트 중인 코드가 제대로 작동하는지 확인하는 방법은 일반적으로 두 가지가 있습니다: 상태 테스트 또는 상호작용 테스트. 이들의 차이점은 무엇일까요?

단위 테스트가 테스트 중인 코드가 제대로 작동하는지 확인하는 방법은 일반적으로 두 가지가 있습니다: 상태 테스트 또는 상호작용 테스트. 이들의 차이점은 무엇일까요?