Programming on philipjkim

Hugo 로 바둑판 도해 그리기 Part 2: 이미지 65장을 표기로 옮기기

Wed, 12 Aug 2026 13:21:01 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1 에서 바둑판 도해를 그리는 goban shortcode 를 만들었습니다. ASCII 로 쓰고 SVG 로 렌더링하는 방식입니다.

만들고 나니 다른 시리즈가 눈에 들어왔습니다. 9x9 바둑 교재 리뷰 4편에 PNG 이미지로 된 도해가 65장 있었습니다. 이걸 전부 표기로 옮기기로 했습니다.

Part 2 는 그 작업의 기록입니다. 결론부터 적으면 작업의 90%는 shortcode 와 무관한 일 이었고, 나머지 10% 에서 렌더링은 멀쩡한데 내용만 틀리는 종류의 버그를 하나 만났습니다.

Hugo 로 바둑판 도해 그리기 Part 1: 왜 shortcode 였나

Wed, 12 Aug 2026 13:18:52 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

이 블로그에 바둑 입문 시리즈를 쓰다가 벽에 부딪혔습니다. 바둑 글에는 바둑판 그림이 필요한데, 그릴 방법이 마땅치 않았습니다.

결국 goban 이라는 이름의 Hugo shortcode 를 직접 만들었습니다. 본문에는 이렇게 쓰고,

{{< goban caption="빈 삼각형" >}}
 a b c d e
 1 . X . . .
 2 X O * . .
 3 . . . . .
{{< /goban >}}

렌더링은 SVG 바둑판으로 나가는 방식입니다. 실제 결과는 이렇습니다.

렉시오 CPU 플레이어 만들기 Part 7: 코드 없이 보는 easy 봇과 hard 봇의 차이

Mon, 10 Aug 2026 09:10:46 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 누구를 위한 것인가

Part 1 부터 Part 6 까지는 비트마스크, 동적 계획법, 평가 함수, 확률 모델 같은 이야기로 채워져 있습니다. 렉시오를 좋아하지만 개발자는 아닌 분에게는 읽을 이유가 없는 글입니다.

이번 편은 그 여섯 편의 결론만 을 코드와 수식 없이 옮긴 것입니다. 렉시오 규칙을 아는 분이라면 누구나 읽을 수 있습니다. 다루는 것은 셋입니다.

두 CPU 는 각각 무엇을 보고 수를 고르는가
둘을 어떻게 겨루게 했고, 결과가 어땠는가
그 결과로 무엇은 말할 수 있고, 무엇은 여전히 말할 수 없는가

세 번째가 이 글에서 가장 중요합니다. 숫자를 보여 주는 글은 많지만, 그 숫자가 무엇을 증명하지 못 하는지까지 적는 글은 드뭅니다.

렉시오 CPU 플레이어 만들기 Part 6: 봇이 약한지 어떻게 아는가

Mon, 10 Aug 2026 08:51:18 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

눈으로 한 판 돌려서는 못 보는 것

Part 5 에서 고친 결함은 눈에 보이는 것이었습니다. 봇이 거의 모든 턴을 패스했고, 브라우저에서 5인 게임을 한 판 돌리자 바로 드러났습니다.

그 방법에는 한계가 분명합니다.

봇이 100% 패스한다 → 한 판이면 보입니다
봇이 라운드당 1.4점씩 잃는다 → 몇 판을 돌려도 느낄 수 없습니다

렉시오는 딜 운의 분산이 큽니다. 좋은 패를 받은 판과 나쁜 패를 받은 판의 차이가 정책의 차이보다 훨씬 크기 때문에, 사람이 몇 판 보고 “이 봇이 좀 약한 것 같다"고 말하는 것은 근거가 되지 못합니다. 측정 도구 없이 가중치를 만지면 더 나쁩니다. 고쳤다고 생각한 것이 실은 운이었는지 확인할 방법이 없습니다.

렉시오 CPU 플레이어 만들기 Part 5: 봇이 아무것도 하지 않는 이유

Fri, 07 Aug 2026 07:56:13 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

설계와 구현 사이

Part 1 부터 Part 4 까지는 설계안이었습니다. 타일을 정수로 압축하고, 미공개 집합을 복원하고, 손패 분해를 DP 로 풀고, 목적 함수를 정산식에서 유도해 평가 함수의 항을 나열했습니다. 코드 조각은 있었지만 돌려 본 적은 없었습니다.

이번 편은 그 설계를 실제로 구현해 브라우저에서 5인 게임을 돌려 본 기록입니다. 결과부터 적겠습니다. 봇이 거의 모든 턴을 패스했습니다.

원인을 추적하고 나서 든 생각은 “설계가 틀렸다"가 아니었습니다. 항을 하나씩 뜯어보면 Part 4 가 쓴 대로였고, 개별 함수는 각각 맞는 값을 돌려주고 있었습니다. 틀린 것은 항을 합치는 방식 이었고, 그중 일부는 Part 1~4 가 아예 말하지 않은 자리였습니다.

달무티 CPU 플레이어 만들기 Part 4: 만들어 보니 hard 봇이 더 약했다

Mon, 03 Aug 2026 17:57:55 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

설계안이 검증을 만나면

Part 1에서 공정성 경계와 결정적 easy 봇을 만들었고, Part 2에서 hard 봇의 정보 모델을 세웠고, Part 3에서 수 평가 함수와 전략적 패스로 실제 결정을 내렸습니다. 세 편 모두 “이 글은 설계안이고 코드는 논지를 보이기 위한 발췌"라고 밝혀 두었습니다.

그 설계안을 실제 게임에 구현하고, 시뮬레이터를 붙여 easy 봇과 같은 조건에서 붙여 봤습니다. 결과는 이랬습니다.

최초 hard 봇은 easy 봇보다 평균 종료 순위가 0.6601등 나빴습니다.

8비트의 벽을 넘은 게임들 Part 5: 제약이 사라진 시대에 남은 것

Mon, 03 Aug 2026 09:48:13 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

지금까지의 이야기

네 편에 걸쳐 세 작품을 뜯었습니다. 정리하면 이렇습니다.

	슈퍼 마리오브라더스	엘리트	메탈기어
연도 / 기종	1985 / 패미콤	1984 / BBC Micro	1987 / MSX2
부족했던 자원	ROM 40KB	RAM 32KB	스프라이트, 가로 스크롤
전략	압축	생성	전복
핵심 기법	오브젝트 2바이트 인코딩	트리보나치 씨앗 트위스팅	요구사항 자체를 바꿈
세계 데이터	4,460 바이트	6 바이트	20,246 바이트
치른 대가	표현 가능한 오브젝트가 제한됨	세부를 손댈 수 없음	원래 만들려던 게임을 포기함

이 마지막 편에서는 이 세 가지가 40년 뒤에 어떻게 됐는지 봅니다.

8비트의 벽을 넘은 게임들 Part 4: 메탈기어, 못 그리는 것을 안 그려도 되게 만들다

Mon, 03 Aug 2026 09:43:31 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

세 번째 길

앞의 두 편에서 본 전략을 정리하면 이렇습니다.

Part 2 슈퍼 마리오브라더스: 데이터를 작게 만든다. 레벨 오브젝트 2바이트 인코딩.
Part 3 엘리트: 데이터를 갖지 않는다. 씨앗 6바이트에서 우주 전체를 계산.

둘 다 “요구사항은 그대로 두고 구현을 비튼다” 는 접근입니다. 1987년 코나미의 MSX2 팀은 세 번째 길을 갔습니다. 요구사항 자체를 바꿨습니다.

결과물이 메탈기어이고, 그 결과물이 만든 것은 게임 하나가 아니라 장르 하나 였습니다.

8비트의 벽을 넘은 게임들 Part 3: 엘리트, 우주를 6바이트에 담다

Mon, 03 Aug 2026 09:33:14 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

저장하지 않으면 용량도 들지 않는다

Part 2에서 본 슈퍼 마리오브라더스의 전략은 데이터를 작게 만드는 것 이었습니다. 레벨 오브젝트를 2바이트로 인코딩해 게임 전체의 스테이지 데이터를 4,460바이트에 넣었습니다.

1984년 BBC Micro 로 나온 엘리트는 한 걸음 더 나갑니다. 데이터를 아예 갖지 않습니다.

먼저 규모를 봅시다. 엘리트에는 은하가 8개 있고, 은하마다 항성계가 256개 있습니다. 총 2,048개 입니다. 각 항성계에는 고유한 이름이 있고, 좌표가 있고, 경제 형태, 정부 형태, 기술 수준, 인구, 총생산, 행성 반지름, 지배 종족이 있습니다.

8비트의 벽을 넘은 게임들 Part 2: 슈퍼 마리오브라더스, 레벨을 그리지 않고 서술하다

Mon, 03 Aug 2026 09:24:56 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

4,460바이트짜리 세계

Part 1에서 확인한 제약을 다시 꺼내 놓겠습니다.

슈퍼 마리오브라더스 카트리지는 PRG-ROM 32KB + CHR-ROM 8KB = 40KB 입니다.
한 프레임 중 VRAM 을 만질 수 있는 시간은 2,273 사이클이고, 스프라이트 DMA 를 빼면 배경에 쓸 수 있는 것은 약 220바이트 입니다.
6502 에는 곱셈 명령이 없습니다.

이 세 줄을 지키면서 32개 스테이지가 흐르는 게임을 만들어야 합니다.

8비트의 벽을 넘은 게임들 Part 1: 그 기계들은 무엇을 못 했는가

Mon, 03 Aug 2026 09:06:15 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

스크린샷 한 장보다 작은 게임

슈퍼 마리오브라더스가 담긴 카트리지의 ROM 용량은 40KB 입니다. 프로그램 32KB, 그림 데이터 8KB. 이게 전부입니다.

이 게임의 한 장면을 오늘날의 화면에서 캡처해 PNG 로 저장하면 보통 수백 KB 가 나옵니다. 게임 하나가 그 게임의 스크린샷 한 장보다 작습니다. 32개 스테이지, 여덟 가지 배경음악, 마리오의 물리 엔진, 적 AI, 점수 계산, 타이틀 화면이 전부 저 40KB 안에 있습니다.

렉시오 CPU 플레이어 만들기 Part 4: 수 평가와 정산 기대값

Fri, 31 Jul 2026 09:44:26 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

재료에서 결정으로

Part 2 에서 봇이 무엇을 아는지, Part 3 에서 자기 손패를 어떻게 보는지 만들었습니다. 아직 결정은 하나도 하지 않았습니다. 이번 편에서 전부 합칩니다.

그런데 합치기 전에 답해야 할 질문이 하나 있습니다. 무엇을 최대화할 것인가.

달무티에서는 이 질문이 쉬웠습니다. 등수가 곧 다음 판의 계급이고 점수도 등수에 비례하므로, “평균 등수를 낮춘다"가 그대로 목적 함수였습니다. 렉시오는 다릅니다. 렉시오에는 등수가 없습니다. 금액만 있습니다.

렉시오 CPU 플레이어 만들기 Part 3: 손패 분해 플랜

Fri, 31 Jul 2026 09:37:44 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

좋은 손패는 센 손패가 아니다

Part 2 에서는 봇이 상대에 대해 무엇을 알 수 있는지 정리했습니다. 이번 편은 시선을 안으로 돌립니다. 내 손패는 몇 번 제출하면 비는가.

이 질문이 왜 중요한지는 클라이밍 게임 전략 글에서 이미 짚었습니다. 강한 타일이 많은 손패와 조합이 잘 짜인 손패 중 이기는 쪽은 후자입니다. 강한 타일은 한 번에 한 장씩 나가지만, 잘 짜인 손패는 다섯 장씩 나갑니다.

렉시오 CPU 플레이어 만들기 Part 2: 60비트 카운팅과 확실승수 판정

Fri, 31 Jul 2026 09:30:12 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

hard 봇이 지켜야 할 세 가지

Part 1 에서 만든 easy 봇은 이번 턴에 합법적인 가장 싼 수를 계산할 뿐이었습니다. 이번 편부터 hard 봇을 설계합니다. 다만 시작하기 전에 지켜야 할 선을 못 박아 두겠습니다.

공정성. 봇은 GameView 만 봅니다. 남의 손패는 그 구조체 어디에도 존재하지 않습니다. 봇이 강해지는 이유는 더 많이 보기 때문이 아니라, 같은 것을 보고 더 잘 세기 때문 이어야 합니다.
결정성. 같은 입력에서는 같은 출력이 나와야 합니다. 그래야 봇 로직이 테스트 가능한 코드가 됩니다. 난수를 쓴다면 시드를 게임 상태에서 유도합니다.
실시간성. 봇의 판단은 사람이 기다릴 수 있는 시간 안에 끝나야 합니다. 이 제약이 뒤에서 “몬테카를로를 런타임에 돌리지 않는다"는 설계 결정으로 이어집니다.

이번 편은 hard 봇이 무엇을 아는가 를 다룹니다. 무엇을 결정하는가는 Part 3 과 Part 4 의 몫입니다.

렉시오 CPU 플레이어 만들기 Part 1: 타일 하나를 정수 하나로

Fri, 31 Jul 2026 09:22:31 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

사촌 게임, 전혀 다른 봇

어제 글에서 달무티(The Great Dalmuti)의 CPU 플레이어를 세 편에 걸쳐 설계했습니다. 이번에는 같은 클라이밍 계열의 국산 타일 게임 렉시오(Lexio) 로 넘어갑니다.

두 게임은 클라이밍 게임을 정리한 글에서 봤듯 사촌 사이입니다. 더 센 조합으로 받아 올라가고, 손패를 먼저 비우는 쪽이 이깁니다. 그런데 봇을 짜 보면 알고리즘이 거의 겹치지 않습니다. 달무티 봇 코드를 렉시오로 옮기려 하면 재사용할 수 있는 것은 “공정성 경계를 타입으로 못 박는다” 같은 뼈대뿐이고, 판단 로직은 전부 새로 써야 합니다.

달무티 CPU 플레이어 만들기 Part 3: 수 평가와 전략적 패스

Thu, 30 Jul 2026 15:08:35 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

정정 안내 (2026-08-03): 이 글의 설계안을 실제로 구현해 시뮬레이션으로 검증한 결과, 리드 선택·세금 반환·목적 함수에 대한 일부 결론이 뒤집혔습니다. 특히 “리드 선택도 같은 계산이다” 절과 “rank 12 는 반환 카드로 나쁘다"는 주장은 철회되었습니다. 무엇이 왜 틀렸고 무엇이 살아남았는지는 Part 4: 만들어 보니 hard 봇이 더 약했다에 정리했습니다.

재료에서 결정으로

Part 1에서 공정성 경계와 결정적 easy 봇을 만들었고, Part 2에서 hard 봇의 정보 모델을 세웠습니다. 지금까지 확보한 재료는 셋입니다.

달무티 CPU 플레이어 만들기 Part 2: hard 봇의 정보 모델과 확실승수 판정

Thu, 30 Jul 2026 14:18:37 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

hard 봇이 지켜야 할 세 가지

Part 1에서는 달무티 CPU 플레이어의 뼈대를 잡고, 결정적 규칙만으로 움직이는 easy 봇을 만들었습니다. easy 봇은 합법적이고 예측 가능하지만, “낼 수 있으면 무조건 낸다"는 정책 때문에 사람에게 쉽게 집니다.

이번 편부터 hard 봇을 설계합니다. 설계 제약은 세 가지입니다.

1. 상대의 손패는 절대 볼 수 없습니다. 봇은 Part 1 에서 정의한 GameView 만 받습니다. 난이도를 올리기 위해 정보를 더 주는 것은 설계가 아니라 반칙입니다. 사람이 “저 봇 손패 보는 거 아니야?“라고 의심하는 순간 게임의 신뢰가 무너집니다.

달무티 CPU 플레이어 만들기 Part 1: 규칙 기반 easy 봇

Thu, 30 Jul 2026 14:09:37 +0900

이 글은 Claude Opus 5 를 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

후속 정정 안내 (2026-08-03): 이 시리즈의 설계안을 실제로 구현해 시뮬레이션으로 검증한 결과, 여기서 “easy 봇의 단순화"로 소개한 리드 정책과 세금 반환 규칙이 hard 봇의 복잡한 평가식보다 강했고, 지금은 hard 봇의 guardrail 로 채택돼 있습니다. 자세한 내용은 Part 4: 만들어 보니 hard 봇이 더 약했다에 정리했습니다.

왜 봇부터 만드는가

지난 글에서 대부호·달무티·렉시오를 묶어 클라이밍 게임의 전략을 정리했습니다. 이번에는 그중 달무티(The Great Dalmuti) 를 디지털 게임으로 구현한다고 가정하고, CPU 플레이어를 어떤 전략으로 움직일 것인가 를 파고들겠습니다.

AI 허니문이 끝난 자리: 테크 인력 6,000명을 반으로 가른 것과, 개인이 바꿀 수 있는 것

Wed, 29 Jul 2026 13:30:11 +0900

이 글은 Claude Opus 5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이오플래닛에 소개된 AI 허니문은 끝났다: 테크 인력이 정확히 반으로 갈라졌다 를 읽고, 원 조사를 직접 찾아보았습니다. 출처는 노엄 시걸(Noam Segal)이 레니 라치츠키(Lenny Rachitsky)와 함께 진행한 두 번째 연례 테크 종사자 심리 조사 입니다. 에어비앤비·트위터·메타·재피어·피그마 등에서 리서치를 이끌어 온 사람이 설계했고, 표본은 약 6,000명입니다.

가장 많이 인용되는 문장은 이것입니다. “AI가 당신의 직업 정체성을 어떻게 바꿨습니까"라고 물었더니 절반은 “일이 다시 재미있어졌다” 고 답했고, 나머지 절반에게서는 “내 뇌가 썩어 가는 것 같다” 는 답이 돌아왔다는 것입니다.

번역글: Big Design Up Front — 여전히 나쁜 생각입니다

Tue, 28 Jul 2026 14:23:37 +0900

이 글은 Claude Opus 5 를 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Pragmatic Programmers Newsletter — “Big Design Up Front: Still a Bad Idea”

우리는 1990년대의 소프트웨어 위기를 불러왔던 그 관행을 그대로 되풀이할 위험에 처해 있습니다.

40년 전, 도구와 하드웨어가 발전하면서 우리는 점점 더 큰 시스템을 만들 수 있게 됐습니다. 더 야심 차고, 범위도 넓고, UI도 화려한 시스템들이었습니다. 짜릿한 시절이었습니다.

하지만 문제가 있었습니다. 시스템이 복잡해질수록 프로젝트는 점점 더 실패했습니다. 일정 추정은 웃음이 나올 만큼 빗나갔고, 기능은 잘려나갔고, 버그는 넘쳐났습니다. 프로젝트는 납품되는 만큼이나 자주 취소됐습니다. 2000년 무렵에는 여섯 개 중 하나 정도만 일정과 예산에 근접하게 마무리됐습니다.

Marp: Markdown으로 발표 슬라이드를 만들고 Git으로 관리하기

Thu, 23 Jul 2026 13:03:11 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

발표 자료를 만들 때마다 PowerPoint나 Keynote를 열면서 “코드는 Git으로 관리하는데 슬라이드는 왜 바이너리 파일로 주고받아야 하지?“라는 생각을 해본 개발자라면, 이 글이 도움이 될 것입니다. 이미 README와 기술 문서를 Markdown으로 쓰고 있다면, 슬라이드도 같은 방식으로 만들 수 있습니다. 이 글에서는 Marp (Markdown Presentation Ecosystem)을 소개합니다.

Marp란 무엇인가

Marp은 Markdown 파일을 발표 슬라이드로 변환해주는 오픈소스 도구 모음입니다. 핵심 아이디어는 단순합니다:

번역글: 어느 사랑 이야기

Mon, 20 Jul 2026 15:31:52 +0900

이 글은 Claude Opus 4.8 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “A Love Story”

1990년대, Reddit도 Twitter도 Facebook도 나오기 전, 사실상 그 무엇도 존재하기 전에, 새로운 프로그래밍 언어를 찾아보는 곳은 comp.lang.misc 라는 Usenet 그룹이었습니다.

사람들은 자신의 최신 창작물을 소스 코드 형태로 올렸습니다. 그것은 uuencode로 인코딩되어 여러 조각으로 나뉘어 있었습니다 (게시물에는 최대 크기 제한이 있었기 때문입니다). 어떤 언어를 써보고 싶으면, uuencode된 조각들을 전부 내려받아 이어 붙인 다음 디코딩해야 했습니다. 그러면 tar 파일이 나오고, 그것을 풀면 소스 코드가 나왔습니다. 그다음에는 ./configure를 돌아가게 만드는 즐거움이 기다리고 있었습니다.

HTTP REST(JSON) vs. gRPC(Protocol Buffers): 언제 무엇을 쓸까

Thu, 16 Jul 2026 17:33:09 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

백엔드 서버를 설계할 때 거의 항상 마주치는 갈림길이 있습니다. “이 API 를 JSON 기반 HTTP REST 로 열까, 아니면 gRPC 로 열까?” 하는 질문입니다. 팀 컨벤션에 따라 별생각 없이 한쪽으로 정해지는 경우도 많지만, 두 방식은 성능·개발 경험·운영 부담·클라이언트 호환성 등 여러 축에서 뚜렷하게 다른 트레이드오프를 가집니다.

이 글은 웹 백엔드를 다루는 중급 이상 개발자를 대상으로, 두 방식의 작동 원리와 장단점을 정리하고 “어떤 상황에서 무엇을 고르는 것이 합리적인지” 를 구체적인 예시와 함께 설명합니다. 결론부터 말하면 “무조건 하나가 낫다"는 답은 없으며, 통신의 상대가 누구인지(외부 클라이언트 vs. 내부 서비스) 가 선택의 가장 강력한 기준이 됩니다.

배우는 부분들로 이루어진 배우는 시스템 — Kent Beck × Jessica Kerr 대담 정리

Fri, 26 Jun 2026 09:56:51 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 좋은 리소스를 귀띔해 주신 Luis 님께 감사드립니다. 덕분에 ‘symmathesy’ 를 몇 번이나 소리 내어 발음해 봤는지 모릅니다 — 혀는 여전히 꼬이지만, 개념만큼은 또렷하게 남았습니다.

Kent Beck 이 진행하는 팟캐스트 Still Burning 의 일곱 번째 에피소드 A Learning System Made of Learning Parts 는, “여전히 마음을 쓰고(still care) 여전히 무언가를 하고 있는 괴짜들” 을 위한 자리라는 이 시리즈의 취지에 꼭 맞는 대담입니다. 손님은 Kent 의 오랜 친구이자 시스템 사고(systems thinking)로 잘 알려진 개발자 Jessica Kerr(jessitron) 입니다.

번역글: 아웃소싱, AI, 그리고 작은 희망

Thu, 25 Jun 2026 07:45:43 +0900

이 글은 Claude Opus 4.8 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “Outsourcing, AI, and a Little Hope”

1990년대와 2000년대에 이 업계에 몸담았다면, 아웃소싱을 둘러싼 그 소동을 잘 알고 계실 겁니다.

기업들은 미국과 서유럽 바깥의 개발자들에게 대체로 더 적은 임금을 준다는 사실을 깨달았습니다. 그리고 개발자란 그저 자원에 불과하니, 개발 업무를 해외로 보내버리면 돈을 왕창 아낄 수 있다고 생각했습니다.

한동안 미국과 유럽의 개발자들은 공황에 빠졌습니다. “저 멀리 어퍼 호피스탄(Upper Hopistan)에서 하루 1.5달러를 받는 어떤 코더에게 내 일자리를 빼앗기겠구나.”

2021년의 Go를 2026년의 Go로 Part 3: 동시성·런타임·운영 레시피

Wed, 24 Jun 2026 10:15:25 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서 언어와 문법을, Part 2에서 표준 라이브러리를 다뤘습니다. 시리즈의 마지막인 Part 3은 동시성·런타임·툴체인·운영 입니다. 코드 한 줄의 변화라기보다, “서비스를 어떻게 돌리고 어떻게 검증하느냐"에 가까운 영역입니다.

이 영역의 변화는 특히 컨테이너/쿠버네티스 환경에서 Go 서비스를 운영하는 팀에게 의미가 큽니다. 2021년에는 서드파티 라이브러리나 수작업으로 메우던 빈틈을, 이제 표준 런타임이 채워 줍니다.

레시피 1: 수동 취소·타임아웃 관리 대신 `context` 신규 API (1.21)

context 는 1.7부터 있었지만, 실무에서 반복되던 몇 가지 패턴을 표준으로 흡수한 것은 1.21입니다.

2021년의 Go를 2026년의 Go로 Part 2: 표준 라이브러리 레시피

Wed, 24 Jun 2026 10:13:33 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서는 제네릭, 이터레이터, 빌트인 등 언어와 문법 레벨의 변화를 다뤘습니다. Part 2는 일상 코드에서 가장 손이 자주 가는 표준 라이브러리 의 레시피입니다.

2021~22년의 Go 표준 라이브러리는 의외로 빈약했습니다. 슬라이스에서 원소를 찾으려면 for 루프를 직접 돌렸고, 맵의 키를 모으려면 손으로 슬라이스를 채웠으며, 정렬은 sort.Slice 에 비교 함수를 넘겼습니다. 구조적 로깅을 하려면 logrus, zap 같은 서드파티가 사실상 필수였고, HTTP 라우팅에서 메서드와 경로 파라미터를 다루려면 gorilla/mux 를 깔았습니다.

2021년의 Go를 2026년의 Go로 Part 1: 언어와 문법 레시피

Wed, 24 Jun 2026 10:11:05 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 5년 동안 Go에 무슨 일이 있었나

2021~22년에 Go로 서비스를 짜던 시절을 떠올려 봅니다. 그때 우리가 쓰던 버전은 대략 Go 1.16~1.18 언저리였습니다. 제네릭이 없거나(1.18 이전), 갓 도입되어 아직 손에 익지 않았고, interface{} 와 sort.Slice, for _, v := range xs { v := v; ... } 같은 관용구가 일상이었습니다.

그로부터 8개의 메이저 릴리스(1.19부터 1.26까지)가 지났습니다. 2026년 6월 현재 stable 버전은 2026년 2월에 나온 Go 1.26 입니다. 이 5년 사이에 언어 자체, 표준 라이브러리, 런타임, 툴체인이 모두 크게 달라졌습니다. 문제는 코드베이스가 그만큼 따라가지 못한다는 점입니다. 많은 프로덕션 코드가 여전히 “그때 그렇게 짜던 방식"으로 멈춰 있습니다.

개발자를 위한 Discord 완전정복 Part 2: 공짜로 풀어준 대인배 기능들

Fri, 05 Jun 2026 18:07:55 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 Discord가 어떻게 태어나 성장했고 어떤 결정으로 지금의 모습이 되었는지를 살펴봤습니다. 이번 Part 2에서는 개발자 입장에서 Discord가 얼마나 대인배인지 를 이야기합니다.

결론부터 말하면, API·봇·Webhook·Gateway·Interactions·OAuth2·임베드·CDN 첨부·음성 채널·스레드·포럼 채널이 전부 무료입니다. 서버 크기 제한도 없습니다. 흔히 보이는 유료 구독 Nitro는 개인 사용자(엔드유저) 대상이지 개발자 기능이 아닙니다. 봇을 만들고 운영하는 데 Discord에 내는 비용은 0원이며, 드는 비용이 있다면 봇을 돌릴 본인 호스팅 비용뿐입니다.

개발자를 위한 Discord 완전정복 Part 1: 탄생, 성장, 그리고 결정적 순간들

Fri, 05 Jun 2026 18:05:49 +0900

이 글은 Claude Opus 4.8 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

개발자라면 한 번쯤은 Discord 서버에 들어가 본 적이 있을 것입니다. 오픈소스 프로젝트의 커뮤니티, 사내 봇 알림 채널, 혹은 그냥 친구들과 게임하며 떠드는 음성 채널까지. 어느새 Discord는 개발자 생태계의 기본 인프라 중 하나가 되었습니다.

이 시리즈는 Discord라는 서비스를 개발자의 시선으로 뜯어봅니다. 3부작으로 구성했습니다.

Part 1 (이 글): Discord가 어떤 니즈에서 태어났고, 어떻게 성장했으며, 서비스를 지금의 모습으로 만든 결정적 의사결정들을 살펴봅니다. 마지막엔 개발자가 특히 주목할 만한 엔지니어링 의사결정(Elixir, Go→Rust, Cassandra→ScyllaDB)을 다룹니다.
Part 2: Webhook, 봇, 슬래시 커맨드 같은 Discord의 개발자 친화적이고 대인배스러운 무료 기능들을 실전 관점에서 정리합니다.
Part 3: Discord를 원격 control plane으로 활용하는 방법 — AI 코딩 에이전트 원격 제어, ChatOps, 홈랩 모니터링 등 — 과 그 best practice를 다룹니다.

그럼 1편을 시작합니다.

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기

Thu, 28 May 2026 19:03:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1 에서는 2026년 5월 기준 de-facto 가 된 spec 문서들의 지형도와 best practices 를 정리했습니다. 2편에서는 가상의 Go + Templ + HTMX 기반 To-Do 앱 gotodo 를 새로 부트스트래핑한다고 가정하고, 각 문서를 실제로 어떻게 채우는지 발췌 형태로 따라갑니다.

가상 프로젝트: `gotodo`

스택은 다음과 같습니다.

Go 1.23 — 표준 라이브러리 중심
templ — Go 네이티브 SSR 템플릿 (type-safe)
HTMX 2.0 — 클라이언트 JS 최소화
SQLite + modernc.org/sqlite — CGO 없는 순수 Go 드라이버

목표는 단순합니다. 할 일 추가/완료/삭제만 되는 SSR 미니멀 앱. 1인 로컬 사용을 가정합니다.

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 1: AGENTS.md 와 spec 문서 지형도

Thu, 28 May 2026 19:02:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: README 한 장으로 안 되는 시대

신규 서비스를 위한 git repo 를 막 만들었다고 합시다. 2년 전이라면 README.md 한 장에 빌드 명령과 디렉터리 구조를 적고, 나머지는 코드와 머릿속에서 합의된 관행으로 굴러갔습니다. 새 팀원이 들어오면 옆 자리 동료가 30분쯤 설명해 주고, 그걸로 충분했습니다.

지금은 그 “옆 자리 동료” 역할의 절반 이상을 Claude Code, Codex CLI, Gemini CLI, Cursor 같은 에이전트가 맡고 있습니다. 그런데 에이전트는 옆 자리에 앉지 않습니다. 매 세션마다 처음 합류한 신입처럼 repo 에 들어와서, 우리가 적어 둔 텍스트만 읽고 일을 시작합니다. 에이전트에게 “이 프로젝트는 이런 곳이고, 이런 규칙으로 일한다” 를 전달하는 문서가 부실하면, 에이전트가 만드는 결과물의 품질은 운에 좌우됩니다.

Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계

Wed, 20 May 2026 16:58:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편 에서 개요와 설치를, 2편 에서 핵심 워크플로우를, 3편 에서 품질 보증 스킬을 다뤘습니다. 마지막 4편에서는 실전에서 가장 자주 부딪히는 질문에 답합니다.

“이거 그냥 두면 알아서 다 해주는 건가요, 아니면 매번 /superpowers:xxx 로 호출해야 하나요?”

답은 “대부분 자동이지만, 의도적으로 명시 호출해야 더 잘 작동하는 케이스가 있다” 입니다. 이 글에서는 두 모드의 비교 분석, 트러블슈팅, 커스터마이즈 방법, 그리고 Java/Go 백엔드 개발 현장에서의 실용 팁과 한계를 정리합니다.

Superpowers 플러그인 가이드 Part 3: 품질 보증 스킬 — TDD, Systematic Debugging, Verification, Code Review

Wed, 20 May 2026 16:57:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편 에서 Superpowers 의 개요와 설치를, 2편 에서 핵심 워크플로우를 다뤘습니다. 3편은 그 워크플로우 안에서 작동하면서 에이전트의 합리화와 빠져나갈 구멍을 차단 하는 품질 보증 스킬들을 자세히 들여다봅니다.

이 스킬들은 모두 “Iron Law” 라는 이름의 명문화된 규칙을 갖고 있다는 공통점이 있습니다. 그리고 각 스킬의 문서 안에는 “Red Flags” 표 가 들어 있어, 에이전트가 빠져나가려 할 때 흔히 하는 합리화의 패턴들을 그대로 박아두었습니다. 이게 결과적으로 모델의 행동을 바꿉니다.

Superpowers 플러그인 가이드 Part 2: 핵심 워크플로우 — Brainstorming부터 Subagent-driven Development까지

Wed, 20 May 2026 16:56:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

1편 에서는 Superpowers 가 무엇이고 어떻게 자동 트리거되는지를 다뤘습니다. 2편은 가장 핵심이라고 할 수 있는 개발 워크플로우 전체 를 깊게 들여다봅니다.

전체 흐름은 다음과 같습니다.

flowchart LR
 A[brainstorming] --> B[using-git-worktrees]
 B --> C[writing-plans]
 C --> D{독립 태스크?}
 D -->|yes| E[subagent-driven-development]
 D -->|no/사람 체크포인트 선호| F[executing-plans]
 E --> G[finishing-a-development-branch]
 F --> G

 style A fill:#90EE90,color:#000000
 style B fill:#87CEEB,color:#000000
 style C fill:#FFD700,color:#000000
 style D fill:#FFB6C1,color:#000000
 style E fill:#DDA0DD,color:#000000
 style F fill:#DDA0DD,color:#000000
 style G fill:#FFA07A,color:#000000

이 글에서는 각 스킬이 실제로 무엇을 하는지, 그리고 Go 기반 백엔드 서비스에 새 API 엔드포인트를 추가 하는 시나리오를 따라가며 흐름을 체험해 봅니다.

Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학

Wed, 20 May 2026 16:55:00 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Claude Code, Codex CLI, Cursor 등 코딩 에이전트(coding agent)를 매일 쓰는 백엔드 개발자라면 한 번쯤은 이런 경험이 있을 겁니다. “간단한 기능 하나만 추가해줘” 라고 했더니, 요구사항 정리 없이 코드를 우다다 쏟아내다가 절반쯤에서 길을 잃고, 테스트도 빠진 채 “완료했습니다” 라고 보고하는 경우 말입니다. 모델은 똑똑한데, 작업 방식이 들쭉날쭉해서 결과의 품질이 운에 좌우됩니다.

Jesse Vincent 가 만든 Superpowers 는 바로 이 지점을 노린 플러그인입니다. 모델을 더 똑똑하게 만드는 게 아니라, 모델이 언제, 어떤 순서로, 어떤 규율로 일해야 하는지를 강제하는 “방법론(methodology)” 자체를 플러그인 형태로 주입합니다.

Agentic Coding 시대의 개발방법론 — 더 중요해진 5가지, 무용해진 5가지

Tue, 28 Apr 2026 12:40:28 +0900

이 글은 Claude Opus 4.7 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며: 사라진 것이 아니라 재배치되었다

2025년 한 해를 거치면서 백엔드 개발자가 키보드 앞에서 보내는 시간의 모양이 크게 달라졌습니다. Claude Code, Cursor, Codex 같은 에이전트가 대부분의 코드를 직접 작성하고, 사람은 명세를 다듬고, 결과를 검증하고, 다음 작업을 지시하는 시간이 길어졌습니다. Stack Overflow의 2025 Developer Survey는 응답자의 66%가 almost-right AI code 를 고치는 데 더 많은 시간을 쓰고 있다고 답했습니다.

이 변화 앞에서 가장 자주 듣는 잘못된 결론이 “이제 SW 엔지니어링 방법론은 다 의미가 없어졌다” 입니다. 하지만 2025년 하반기에서 2026년 초까지 Kent Beck, Birgitta Böckeler, Simon Willison, Armin Ronacher, Steve Yegge처럼 실제로 에이전트와 매일 일하는 시니어 엔지니어들이 남긴 글을 읽어 보면 정반대 그림이 보입니다. 방법론이 사라진 것이 아니라, 어떤 것은 더 중요해지고 어떤 것은 의미를 잃는 형태로 재배치되었습니다.

2년 후 프로그래밍은 어떤 모습일까 — 아무도 모릅니다

Fri, 10 Apr 2026 12:58:02 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 아래 두 편의 글을 재구성한 것입니다:

Charles Humble, Nobody knows what programming will look like in two years (LeadDev, 2026.02.18)
Tom Johnson, Nobody knows what it will look like in 2 years (I’d Rather Be Writing, 2026.03.03)

“업계를 떠나야 할까요?”

지난 2년간 개발자 멘토링과 컨퍼런스를 다니며, 프로그래머이자 작가이자 작곡가인 Charles Humble은 이전 30년간 한 번도 들어본 적 없는 질문을 반복적으로 듣게 되었습니다.

번역글: AI와 함께 더 빨리 실패하기

Wed, 08 Apr 2026 14:39:54 +0900

이 글은 Claude Opus 4.6 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “Failing Faster With AI”

“모든 거대한 컴퓨팅 재앙은 너무 많은 아이디어를 한곳에 집어넣으려다 생겨났습니다.”

— Gordon Bell

지난 8년쯤 개인 프로젝트를 하나 진행해 왔습니다. 1970년대 중반의 오래된 PIC 언어를 구현하는 것으로 시작했습니다. 셀 수 없이 많은 반복을 거쳤는데, 순수한 PIC 언어로 출발해서 오늘날에는 프로토타입 기반 스크립팅 언어와 애니메이션 기능을 내장한 형태가 되었습니다.

크로스플랫폼 To-Do 앱 만들기 Part 4: UI 다듬기와 빌드/배포

Wed, 01 Apr 2026 09:12:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 목차

Part 1: Flutter 소개와 개발 환경 설정
Part 2: 기본 UI 구성과 상태 관리
Part 3: 로컬 저장소 연동과 CRUD 완성
Part 4: UI 다듬기와 빌드/배포 (이번 글)

Part 3 회고

Part 3까지 진행하면서 할 일의 추가, 수정, 삭제, 완료 토글 기능과 로컬 저장소 연동까지 모두 구현했습니다. 기능적으로는 완성된 상태이지만, 실제로 사용자에게 배포하려면 몇 가지 더 다듬어야 할 부분이 있습니다.

크로스플랫폼 To-Do 앱 만들기 Part 3: 상태 관리와 로컬 데이터 저장

Wed, 01 Apr 2026 09:11:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 2에서는 Flutter 위젯을 활용해 To-Do 앱의 UI를 구성했습니다. 할 일을 추가하고, 완료 처리하고, 삭제하는 기본 기능까지 구현했는데요. 한 가지 치명적인 문제가 있었습니다. 앱을 종료했다가 다시 실행하면 모든 데이터가 사라진다 는 점입니다.

setState로 관리하던 List<Todo> 는 메모리에만 존재하기 때문입니다. 이번 Part 3에서는 Riverpod 을 사용한 상태 관리 리팩토링과 sqflite 를 이용한 로컬 데이터 영구 저장을 구현합니다.

1. setState의 한계

Part 2에서 사용한 setState는 간단한 프로토타입에는 충분하지만, 앱 규모가 커지면 여러 문제가 생깁니다.

크로스플랫폼 To-Do 앱 만들기 Part 2: Flutter 기초와 UI 구현

Wed, 01 Apr 2026 09:10:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서 Flutter SDK 설치, 에디터 설정, 에뮬레이터 구성 등 개발 환경을 갖추었습니다. 이제 본격적으로 코드를 작성할 차례입니다.

이번 Part 2에서는 Dart 언어의 핵심 문법을 빠르게 훑어본 뒤, Flutter의 위젯 시스템을 이해하고, 실제로 동작하는 To-Do 리스트 앱의 UI를 구현합니다. 이 글을 따라 하면 할 일을 추가하고, 완료 표시하고, 삭제하는 기본 기능이 모두 갖춰진 앱을 만들 수 있습니다.

크로스플랫폼 To-Do 앱 만들기 Part 1: 프레임워크 선택과 개발 환경 설정

Wed, 01 Apr 2026 09:09:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 소개

이 시리즈에서는 Flutter 를 사용하여 크로스플랫폼 To-Do 앱을 처음부터 끝까지 만들어 봅니다. 하나의 코드베이스로 Android, iOS, 그리고 웹까지 동작하는 앱을 완성하는 것이 목표입니다.

시리즈는 총 4개의 파트로 구성됩니다.

Part 1 (이번 글) : 프레임워크 선택과 개발 환경 설정
Part 2: UI 구성과 기본 기능 구현
Part 3: 상태 관리와 로컬 데이터 저장
Part 4: 마무리, 테스트, 빌드 및 배포

각 파트는 실습 중심으로 진행됩니다. 따라해 보시면서 자연스럽게 Flutter 개발의 흐름을 익히실 수 있습니다.

번역글: 공중누각 — 여전히 보람찬 일

Thu, 26 Mar 2026 15:05:36 +0900

이 글은 Claude Opus 4.6 을 이용해 번역되었으며, 이후 퇴고를 거쳤습니다.

원문: Dave Thomas, Pragmatic Programmers Newsletter — “Castles in the Air: It’s Still Just as Rewarding”

마지막으로, 이토록 다루기 쉬운 매체에서 일하는 기쁨이 있습니다. 프로그래머는 시인과 마찬가지로, 순수한 사고의 재료에서 겨우 한 발짝 떨어진 곳에서 일합니다. 그는 공중에, 공기로 누각을 짓습니다. 상상력을 발휘하여 창조하는 것입니다. 이처럼 유연하고, 다듬고 고쳐 쓰기 쉬우며, 웅장한 개념적 구조물을 실현하는 데 이토록 적합한 창작 매체는 거의 없습니다.

AI 에이전트 시대의 C 언어 Part 2: AI는 C를 살리는가, 대체하는가

Fri, 20 Mar 2026 14:09:55 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

Part 1에서는 AI 에이전트 등장 이전에 이미 진행되고 있던 C 언어의 위상 변화를 살펴보았습니다. 메모리 안전성 논쟁, 정부 권고, 주요 프로젝트의 탈C 마이그레이션이 그 핵심이었습니다.

Part 2에서는 AI 코딩 에이전트 가 이 흐름에 어떤 영향을 미치고 있는지 분석합니다. 결론부터 말하면, AI는 C를 살리는 동시에 대체하고 있습니다. 이 역설적인 이중 현상 이 이 글의 핵심 주제입니다.

1. AI가 C 개발을 돕는 방식: “더 안전한 C”

Linux 커널의 AI 코드 리뷰

세계 최대 C 코드베이스인 Linux 커널에서도 AI 도구가 활용되기 시작했습니다. Btrfs 개발자 Chris Mason은 2026년 초 review-prompts 프로젝트를 시작했습니다. Claude Code 등 AI 도구를 활용해 커널 패치를 리뷰하는 프롬프트 모음으로, 대형 diff를 작은 단위로 분할해 C 특유의 문제점을 효과적으로 잡아냅니다.

AI 에이전트 시대의 C 언어 Part 1: 흔들리는 위상과 새로운 도전자들

Fri, 20 Mar 2026 14:08:55 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며

C 언어는 1972년 탄생 이래 50년 넘게 시스템 프로그래밍의 근간이었습니다. Linux 커널, Windows, macOS, PostgreSQL, Python 런타임, nginx — 우리가 매일 쓰는 소프트웨어의 토대 상당 부분이 C로 작성되어 있습니다.

그러나 최근 몇 년간 C 언어의 입지에 큰 변화가 일어나고 있습니다. 메모리 안전성 문제를 둘러싼 논쟁이 격화되고, 미국 정부 기관이 공식적으로 C 사용을 자제하라고 권고하며, Rust를 비롯한 대안 언어들이 빠르게 성장하고 있습니다. 여기에 2024년부터 본격화된 AI 코딩 에이전트(Claude Code, Codex, Gemini CLI 등) 의 등장은 이 흐름을 더욱 가속하고 있습니다.

AI 코딩 시대의 그림자, 7개월 후: 무엇이 변했고 무엇이 남았나

Fri, 13 Mar 2026 09:11:11 +0900

이 글은 philipjkim 이 초안을 작성했으며, 이후 Claude Opus 4.6 을 이용한 퇴고를 거쳤습니다.

지난 2025년 8월, AI 코딩 시대의 그림자: LLM 의존이 개발자에게 미치는 잠재적 위험 5가지라는 글을 썼습니다. 당시 vibe-coding이라는 단어가 막 퍼지기 시작하던 때였고, AI 코딩 도구에 대한 기대와 우려가 공존하던 시기였습니다.

7개월이 흘렀습니다. 그 사이 Claude Code, Cursor, Windsurf 같은 AI 코딩 에이전트들은 단순한 코드 생성을 넘어 프로젝트 전체를 자율적으로 다루는 수준에 도달했습니다. 개발자들의 일상에서 AI agent 없이 코딩하는 시간은 점점 줄어들고 있고, 많은 팀에서 AI agent는 이미 팀원 한 명에 준하는 역할을 하고 있습니다.

웹서비스 내부 구조 아키텍처 가이드 Part 2: EDA, VSA, Modular Monolith

Thu, 12 Mar 2026 10:07:30 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서는 Layered Architecture, Ports & Adapters 계열(Hexagonal/Onion/Clean), CQRS를 다뤘습니다. Part 2에서는 나머지 세 아키텍처와 전체 비교를 다룹니다.

4. Event-Driven Architecture (EDA)

개요

Event-Driven Architecture는 시스템 구성 요소 간의 통신을 이벤트를 통해 수행 하는 설계 패턴입니다. 컴포넌트가 서로 직접 호출하는 대신, “무언가가 발생했다"는 사실을 이벤트로 발행하면, 관심 있는 컴포넌트가 이를 구독하여 반응합니다.

이 글의 전제가 Kafka/RabbitMQ 같은 메시지 브로커를 포함하는 환경이므로, EDA를 내부 구조 패턴으로 다루는 것은 매우 자연스럽습니다. 메시지 브로커가 있다는 것 자체가 이미 이벤트 기반 통신의 인프라를 갖추고 있다는 뜻이기 때문입니다.

웹서비스 내부 구조 아키텍처 가이드 Part 1: Layered, Ports & Adapters, CQRS

Thu, 12 Mar 2026 10:07:29 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 글은 웹서비스를 전제로 합니다. 구체적으로는 HTML/CSS/JS 프런트엔드, REST/gRPC 기반 백엔드, RDB/Redis/NoSQL 저장소, Kafka/RabbitMQ 같은 메시지 브로커가 있는 환경을 상정합니다.

비교 대상은 “배포 아키텍처"가 아닙니다. 마이크로서비스냐 모놀리스냐의 문제가 아니라, 애플리케이션 내부 코드를 어떻게 나누고, 의존성을 어느 방향으로 흐르게 하며, 변경을 어떤 단위로 흡수할 것인가 에 관한 내부 구조 아키텍처입니다. Microsoft도 논리적 계층(layer)과 물리적 계층(tier)을 구분하며, 논리적 계층 분리가 반드시 별도 서버 분리를 의미하지는 않는다고 설명합니다.

Go 웹 프레임워크 비교: Chi vs. Gin

Sat, 07 Mar 2026 00:21:25 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go로 웹 애플리케이션을 만들 때, 가장 많이 비교되는 두 선택지가 Chi와 Gin입니다. GitHub 스타 기준으로 Gin이 압도적인 인기를 누리고 있지만(Gin ~80k vs Chi ~19k), 실무에서의 선택은 단순한 인기도만으로 결정할 문제가 아닙니다.

이 글에서는 두 라이브러리의 설계 철학부터 시작해서, 실제 코드 레벨에서의 차이를 비교합니다.

설계 철학: 라우터 vs. 프레임워크

Chi와 Gin의 가장 근본적인 차이는 자기 자신을 어떻게 정의하는가에 있습니다.

HTMX와 함께 사용할 Go 템플릿 기술 비교: html/template vs. Templ

Sat, 07 Mar 2026 00:01:56 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go로 SSR 웹 앱을 만들 때 HTMX와 함께 사용할 템플릿 기술로 두 가지 선택지가 있습니다.

Go 표준 html/template + 커스텀 PageRenderer (페이지별 독립 템플릿 세트)
Templ

이 글에서는 두 방식의 장단점을 실무 관점에서 비교합니다.

타입 안전성

가장 큰 갈림길입니다.

html/template은 런타임에 템플릿을 파싱하고 데이터를 바인딩합니다. {{ .Titl }}이라고 써도 빌드는 통과합니다. 런타임에 빈 문자열이 나오거나 에러가 발생하고 나서야 문제를 알 수 있습니다.

AI 시대의 Spring 기술 스택 재정비: 명시성을 되찾기 위한 선택들

Wed, 04 Mar 2026 16:20:43 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Claude Code 같은 AI 코딩 도구를 본격적으로 활용하기 시작하면서, 그동안 당연하게 쓰던 기술 스택에 대해 다시 생각하게 되었습니다. JPA의 dirty checking이 정말 편한 건지, Lombok 없이는 못 사는 건지, RestTemplate과 Retrofit이 뒤섞인 코드베이스가 과연 합리적인 건지.

결론부터 말하면, AI가 생성한 코드를 사람이 빠르게 읽고 검증하려면 “마법(magic)“보다 “명시성(explicitness)“이 훨씬 중요하다는 생각에 도달했습니다. 이 글에서는 그 관점에서 기존 Java/Spring 기술 스택의 각 영역을 하나씩 짚어봅니다.

WELC ver. 2026 Part 5: 의존성 깨기 기법 카탈로그

Wed, 04 Mar 2026 10:03:52 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

원서 Chapter 25는 25가지 의존성 깨기(Dependency-Breaking) 기법을 카탈로그 형태로 제시합니다. 각 기법은 “테스트 하네스에 코드를 넣기 위해 의존성을 어떻게 끊을 것인가"라는 질문에 대한 구체적인 답입니다.

다만 일부 기법은 C/C++ 전용이거나, 현대 Java에서는 불필요합니다. Link Substitution, Text Redefinition, Replace Function with Function Pointer 같은 기법이 대표적입니다. 이 파트에서는 2026년 현재 Java 개발에서 특히 유용한 핵심 기법들을 선별하여 정리합니다.

WELC ver. 2026 Part 4: 대규모 코드 문제 다루기

Wed, 04 Mar 2026 10:03:51 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

레거시 시스템에서 가장 자주 마주치는 문제는 규모의 문제입니다. 한 클래스가 수천 줄, 한 메서드가 수백 줄인 코드는 현업에서 흔히 발견됩니다. 이런 코드는 읽기 어렵고, 테스트하기 어렵고, 변경하면 예상치 못한 곳에서 장애가 발생합니다.

이번 글에서는 Michael Feathers의 Working Effectively with Legacy Code 14~22장을 바탕으로, 대규모 코드 문제를 다루는 전략을 JDK 25 기준의 modern Java 코드로 살펴봅니다. SOLID 원칙 중 SRP, ISP, OCP의 실전 적용이 핵심입니다.

WELC ver. 2026 Part 3: 테스트 하네스에 코드 넣기

Wed, 04 Mar 2026 10:03:50 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

레거시 코드를 변경하려면 먼저 테스트를 작성해야 합니다. 하지만 테스트를 작성하려면 코드의 의존성을 깨야 합니다. 의존성을 깨려면 코드를 변경해야 하는데, 변경의 안전성을 보장해줄 테스트가 아직 없습니다.

이것이 Feathers가 말하는 “레거시 코드의 딜레마"입니다.

In legacy code, the weights work against us. We have to pull out a piece to work with because we can’t easily test it in place. — Michael Feathers, Working Effectively with Legacy Code (2004)

WELC ver. 2026 Part 2: 안전한 코드 변경 패턴 — Sprout와 Wrap

Wed, 04 Mar 2026 10:03:49 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

도입

Part 1에서 다룬 Legacy Code Change Algorithm의 5단계 중, 이번 글은 “변경 및 리팩터링” 단계에 해당하는 실전 패턴들을 다룹니다. Michael Feathers의 Working Effectively with Legacy Code 6~8장에 등장하는 핵심 기법입니다.

레거시 코드에 기능을 추가해야 하는데 시간이 없을 때, 기존 코드를 전면 리팩터링하는 것은 현실적이지 않습니다. 이때 사용할 수 있는 4가지 패턴이 있습니다.

패턴	핵심 아이디어
Sprout Method	새 기능을 별도 메서드로 추출
Sprout Class	새 기능을 별도 클래스로 분리
Wrap Method	기존 메서드를 감싸서 전후 동작 추가
Wrap Class	Decorator 패턴으로 기존 클래스를 감싸기

이 4가지 패턴의 공통점은 기존 코드를 가능한 한 건드리지 않으면서 새 기능을 추가한다는 것입니다.

WELC ver. 2026 Part 1: 레거시 코드의 정의와 변경의 역학

Wed, 04 Mar 2026 10:03:48 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

시리즈 소개

2004년 Michael Feathers가 출판한 Working Effectively with Legacy Code (a.k.a. WELC)는 레거시 코드를 안전하게 변경하는 기법들을 체계적으로 정리한 명저입니다. 출판된 지 20년이 넘었지만, 이 책이 제시하는 원칙과 알고리즘은 여전히 유효합니다. 코드베이스가 노후화되는 속도보다 개발자가 이 책을 읽는 속도가 느린 것이 문제일 뿐입니다.

원서의 예제는 Java 1.4/5, C++, C 시대의 코드입니다. 이 시리즈에서는 JDK 25 (2025년 9월 GA, LTS) 기준의 modern Java로 핵심 기법들을 재현합니다. Sealed class, record, text block, pattern matching 등 최신 언어 기능을 적극 활용하여, 원서의 기법이 오늘날 어떤 형태로 적용되는지 보여드리겠습니다.

AI 시대 엔지니어의 심화 전략: 복리 게임, 거울의 한계, 선제적 AI 활용

Wed, 25 Feb 2026 13:54:39 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.
이 글의 시작이 된 에세이: 코드를 읽지 않는 시대, 엔지니어는 무엇을 읽어야 하는가

1. 복리 게임: 정의, 본질, 그리고 승리 전략

복리 게임이란 무엇인가

Kent Beck이 제시한 복리 게임(The Compounding Game) 은 소프트웨어 개발의 본질을 설명하는 프레임이다. 이를 이해하려면 먼저 그 반대편에 있는 결승선 게임과 대비해야 한다.

결승선 게임(The Finish Line Game) 은 명확한 종료 조건이 있는 게임이다. “X를 하는 소프트웨어가 필요하다 → X를 구현하면 끝.” 일회성 스크립트, PoC, 해커톤 프로젝트가 여기에 해당한다. 가장 빠르게 결승선에 도달하는 사람이 이기고, 결승선을 넘으면 게임이 끝난다. AI 바이브 코딩이 압도적으로 유리한 영역이기도 하다.

The Healthy Programmer (2nd Edition) — Part 3

Thu, 12 Feb 2026 13:11:12 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.
원서: The Healthy Programmer, Second Edition — Joe Kutner (Pragmatic Bookshelf, 2026)

Chapter 9: 큐비클 밖에서 생각하기 (Thinking Outside the Cube)

비타민 D 충전하기

핀란드는 북극권에 위치하여 겨울에는 해가 뜨지 않는 날도 있지만, 여름 축제와 야외 활동으로 충분한 비타민 D를 합성해 왔습니다. 프로그래머의 사무실도 일종의 인공 북극권과 같습니다 — 이른 아침에 출근하여 해질 무렵 퇴근하면 자연광에 노출될 기회가 거의 없습니다.

The Healthy Programmer (2nd Edition) — Part 2

Thu, 12 Feb 2026 13:11:09 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.
원서: The Healthy Programmer, Second Edition — Joe Kutner (Pragmatic Bookshelf, 2026)

Chapter 5: 허리 통증 예방 (Preventing Back Pain)

코어 근육 유닛 테스트하기

1753년 카를 필리프 에마누엘 바흐가 건반 연주의 올바른 자세에 대한 책을 출판하기 전까지, 대부분의 하프시코드 연주자들은 통증을 감수해야 한다고 생각했습니다. 프로그래머도 비슷한 상황입니다. 주당 40시간 이상 키보드 앞에 앉아 있으면서도 올바른 자세 교육을 거의 받지 못합니다. 허리 통증은 미국에서 1차 진료 방문 원인 상위 5위에 들며, 프로그래머에게 해당하는 근육성 허리 통증이 전체의 75%를 차지합니다.

The Healthy Programmer (2nd Edition) — Part 1

Thu, 12 Feb 2026 13:11:06 +0900

이 글은 Claude Opus 4.6 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.
원서: The Healthy Programmer, Second Edition — Joe Kutner (Pragmatic Bookshelf, 2026)

서문 (Preface)

이 책을 읽어야 하는 이유

이 책을 읽어야 하는 첫 번째 이유는 여러분의 생명이 달려 있기 때문입니다. 두 번째 이유는 여러분의 커리어가 달려 있기 때문입니다. 저자는 허리 통증으로 더 이상 책상에 앉을 수 없게 된 프로그래머, 반복적인 키보드 사용으로 손목을 다쳐 일상생활조차 어려워진 프로그래머를 직접 만났다고 합니다. 미국의 사망 원인 1위는 심장 질환이며, 제2형 당뇨와 비만도 꾸준히 증가하고 있습니다. 프로그래머의 생활 방식이 이러한 문제에 기여하지만, 대부분의 경우 운동과 영양 관리를 통해 예방이 가능합니다.

STITCH 스택으로 JavaScript 없이 모던 웹앱 만들기

Wed, 11 Feb 2026 10:24:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java 백엔드 개발자가 프론트엔드 프레임워크 없이도 인터랙티브한 웹 애플리케이션을 만들 수 있다면 어떨까요? 이 글에서는 STITCH 스택으로 JavaScript 로직을 최소화한 To-Do 앱을 처음부터 끝까지 만들어봅니다.

이 글은 GoTHIC 스택 가이드의 Java/Spring 버전입니다. Go 백엔드에 관심이 있다면 GoTHIC 편도 확인해보세요.

STITCH 스택이란

STITCH는 S(pring Boot) + T(hymeleaf) + I(nteractive) + T(ailwindCSS + DaisyUI) + C(omponents) + H(TMX)의 축약어입니다. “꿰매다"라는 뜻 그대로, 서버 사이드 렌더링과 클라이언트 인터랙션을 자연스럽게 이어붙이는 풀스택 조합입니다.

GoTHIC 스택으로 JavaScript 없이 모던 웹앱 만들기

Wed, 11 Feb 2026 09:31:05 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go 백엔드 개발자가 프론트엔드 프레임워크 없이도 인터랙티브한 웹 애플리케이션을 만들 수 있다면 어떨까요? 이 글에서는 GoTHIC 스택으로 JavaScript 로직을 최소화한 To-Do 앱을 처음부터 끝까지 만들어봅니다. 핫 리로드까지 air로 세팅하면 개발 경험도 꽤 쾌적합니다.

GoTHIC 스택이란

GoTHIC은 Go(+Gin) + T(empl) + H(TMX) + Interactive Components(Alpine.js + TailwindCSS + DaisyUI)의 축약어입니다. GoTH(Go + Templ + HTMX) 스택을 확장하여 클라이언트 인터랙션과 스타일링까지 아우르는 풀스택 조합입니다.

Claude Code Compaction 가이드

Wed, 04 Feb 2026 19:28:33 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Claude Code를 하루 종일 사용하다 보면 어느 순간 “Compacting our conversation…” 메시지와 함께 작업 흐름이 끊기는 경험을 하게 됩니다. 이 글에서는 Compaction이 무엇인지, 왜 자주 발생하는지, 그리고 어떻게 줄일 수 있는지 실전 전략을 공유합니다.

Compaction이란?

Claude Code는 대화 내용, 읽은 파일, 명령어 출력 등을 Context Window라는 제한된 공간에 저장합니다. 이 공간이 가득 차면 Claude는 더 이상 새로운 정보를 처리할 수 없게 됩니다.

Mermaid 다이어그램 가이드 Part 4: State Diagram

Wed, 28 Jan 2026 10:37:39 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

State Diagram이란?

상태 다이어그램(State Diagram)은 시스템이나 객체가 가질 수 있는 상태(State)와 상태 간의 전이(Transition)를 시각화합니다. 주문 처리, 사용자 인증, TCP 연결 등 유한 상태 기계(Finite State Machine)를 표현할 때 필수적인 도구입니다.

기본 문법

stateDiagram-v2
 [*] --> Idle
 Idle --> Processing
 Processing --> Completed
 Completed --> [*]

stateDiagram-v2
 [*] --> Idle
 Idle --> Processing
 Processing --> Completed
 Completed --> [*]

stateDiagram-v2를 사용하면 최신 렌더러로 그려집니다. 구버전 stateDiagram도 여전히 사용 가능합니다.

Mermaid 다이어그램 가이드 Part 3: Sequence Diagram

Wed, 28 Jan 2026 10:37:36 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Sequence Diagram이란?

시퀀스 다이어그램은 객체들 간의 메시지 교환을 시간 순서에 따라 보여주는 다이어그램입니다. API 호출 흐름, 인증 과정, 트랜잭션 처리 등을 문서화할 때 특히 유용합니다.

기본 문법

sequenceDiagram
 participant A as 클라이언트
 participant B as 서버
 A->>B: 요청
 B-->>A: 응답

sequenceDiagram
 participant A as 클라이언트
 participant B as 서버
 A->>B: 요청
 B-->>A: 응답

Participant 정의

자동 정의

메시지에서 처음 등장하는 이름이 자동으로 participant가 됩니다.

Mermaid 다이어그램 가이드 Part 2: Flowchart 심화 - Subgraph와 레이아웃 제어

Wed, 28 Jan 2026 10:37:33 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Subgraph 기본

Subgraph는 관련된 노드들을 논리적으로 그룹화하는 기능입니다. 시스템의 계층 구조나 도메인 영역을 시각적으로 구분할 때 유용합니다.

기본 문법

flowchart TB
 subgraph 그룹명
 A --> B
 end
 C --> A

flowchart TB
 subgraph 그룹명
 A --> B
 end
 C --> A

ID와 제목 분리

Subgraph에 별도의 ID를 지정하면 참조가 쉬워집니다.

flowchart TB
 subgraph api[API Layer]
 A[Controller]
 B[Service]
 end
 subgraph db[Data Layer]
 C[(MySQL)]
 D[(Redis)]
 end
 A --> B
 B --> C
 B --> D

flowchart TB
 subgraph api[API Layer]
 A[Controller]
 B[Service]
 end
 subgraph db[Data Layer]
 C[(MySQL)]
 D[(Redis)]
 end
 A --> B
 B --> C
 B --> D

Subgraph 방향 제어

이것이 Mermaid 레이아웃의 핵심입니다. direction 키워드로 각 subgraph 내부의 배치 방향을 개별적으로 지정할 수 있습니다.

Mermaid 다이어그램 가이드 Part 1: Flowchart 기본

Wed, 28 Jan 2026 10:37:30 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Mermaid란?

Mermaid는 마크다운 스타일의 텍스트로 다이어그램을 생성하는 JavaScript 기반 도구입니다. 별도의 드로잉 도구 없이도 Git에서 버전 관리가 가능한 다이어그램을 작성할 수 있어, 개발 문서화에 특히 유용합니다.

GitHub, GitLab, Notion, Obsidian 등 다양한 플랫폼에서 기본 지원되며, VS Code 확장 프로그램을 통해 실시간 미리보기도 가능합니다.

Flowchart 기본 문법

Flowchart는 프로세스의 흐름을 시각화하는 가장 기본적인 다이어그램입니다. 노드(Node)와 엣지(Edge)로 구성됩니다.

다이어그램 선언

flowchart TD
 A --> B

flowchart TD
 A --> B

flowchart 키워드로 시작하며, 바로 뒤에 방향을 지정합니다. graph 키워드도 사용 가능하지만 flowchart가 더 많은 기능을 지원합니다.

Claude Code 완전 정복 가이드 Part 6: 고급 패턴과 Best Practices

Fri, 23 Jan 2026 17:21:06 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

예상 소요 시간: 1시간 30분 난이도: ⭐⭐⭐⭐⭐ 사전 요구사항: Part 1-5 완료 Claude Code 버전: 2.1.x (Opus 4.5)

0. Claude Code 2.1 주요 신기능

본격적인 내용에 앞서, Claude Code 2.1에서 추가된 핵심 기능들을 정리합니다:

기능	설명
Session Teleportation	`/teleport`, `/remote-env`로 로컬↔클라우드 세션 이동
Hot Reload for Skills	Skills 수정 시 재시작 없이 즉시 반영
Setup Hook	`--init`, `--init-only`, `--maintenance` CLI 플래그용 훅
Task Management	의존성 추적이 포함된 태스크 관리 시스템
Language Output	`language` 설정으로 출력 언어 지정
Opus 4.5	Pro 사용자에게 Opus 4.5 모델 제공
respectGitignore	`@-mention` 파일 선택에서 gitignore 적용
showTurnDuration	턴 소요 시간 표시 설정

1. Hooks: 예외 없는 강제 자동화

1.1 CLAUDE.md vs Hooks의 근본적 차이

flowchart TB
 subgraph Comparison["CLAUDE.md vs Hooks"]
 direction TB

 subgraph Advisory["📄 CLAUDE.md = '권고' (Advisory)"]
 A1["'테스트를 실행해주세요'<br/>'린트를 돌려주세요'"]
 A2["→ Claude가 따를 수도 있고, 잊을 수도 있음<br/>→ 복잡한 대화에서 규칙이 희석될 수 있음"]
 end

 subgraph Enforcement["⚡ Hooks = '강제' (Enforcement)"]
 E1["파일 저장 시 → 자동으로 린트 실행<br/>대화 시작 시 → 자동으로 컨텍스트 로드"]
 E2["→ 예외 없이 항상 실행됨<br/>→ Claude의 판단과 무관하게 트리거"]
 end
 end

 style Advisory fill:#fff9c4,color:#000000
 style Enforcement fill:#c8e6c9,color:#000000
 style A1 fill:#fffde7,color:#000000
 style A2 fill:#ffecb3,color:#000000
 style E1 fill:#e8f5e9,color:#000000
 style E2 fill:#a5d6a7,color:#000000

1.2 Hooks 이벤트 종류

이벤트	트리거 시점	사용 예시
`PreToolUse`	도구 실행 직전	위험한 명령 차단, 로깅
`PostToolUse`	도구 실행 직후	린트 자동 실행, 검증
`Notification`	알림 발생 시	외부 시스템 연동
`Stop`	작업 완료/중단 시	정리 작업, 리포트
`Setup`	`--init`, `--init-only`, `--maintenance` 실행 시	저장소 초기화, 유지보수 (2.1+ 신규)

💡 Claude Code 2.1+ 변경사항:

Claude Code 완전 정복 가이드 Part 5: 나만의 Plugin Marketplace 만들기 - 팀/조직 확장

Fri, 23 Jan 2026 17:21:03 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

예상 소요 시간: 1시간 30분 난이도: ⭐⭐⭐⭐ 사전 요구사항: Part 1-4 완료, Git/GitHub 기본 지식 Claude Code 버전: 2.1.x

1. Plugin 구조 이해

1.1 Plugin 디렉토리 구조

💡 주의: 2026년 기준, marketplace.json에서 Skills를 로드하려면 skills 필드가 필수입니다. 이 필드가 없으면 Skills가 로드되지 않습니다.

my-plugin/
├── .claude-plugin/
│ └── plugin.json # 필수: 플러그인 메타데이터
├── skills/ # 선택: Skills
│ └── my-skill/
│ └── SKILL.md
├── commands/ # 선택: Slash Commands
│ └── my-command.md
├── agents/ # 선택: Subagents
│ └── my-agent.md
├── hooks/ # 선택: Hooks 설정
│ └── hooks.json
├── .mcp.json # 선택: MCP 서버 설정
└── README.md # 권장: 문서화

1.2 plugin.json 필수 필드

{
 "name": "my-awesome-plugin",
 "version": "1.0.0",
 "description": "플러그인 설명",
 "author": "Your Name",
 "homepage": "https://github.com/you/my-plugin"
}

1.3 plugin.json 전체 스키마

{
 "name": "my-awesome-plugin",
 "version": "1.0.0",
 "description": "이 플러그인이 무엇을 하는지 간단히 설명",
 "author": "Your Name <you@example.com>",
 "homepage": "https://github.com/you/my-plugin",
 "repository": {
 "type": "git",
 "url": "https://github.com/you/my-plugin.git"
 },
 "license": "MIT",
 "keywords": ["go", "testing", "conventions"],
 "engines": {
 "claude-code": ">=2.0.0"
 },
 "dependencies": {
 "plugins": ["other-plugin@marketplace"]
 }
}

2. 첫 번째 Plugin 만들기

2.1 시나리오

Java/Kotlin 개발팀을 위한 Plugin을 만들어봅시다. 다음을 포함합니다:

Claude Code 완전 정복 가이드 Part 4: Plugins & Marketplace - 재사용 가능한 확장 패키지

Fri, 23 Jan 2026 17:21:00 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

예상 소요 시간: 1시간 난이도: ⭐⭐⭐ 사전 요구사항: Part 1, 2, 3 완료 Claude Code 버전: 2.1.x (VSCode Native Plugin Management 지원)

1. Plugin이란 무엇인가?

1.1 Skills vs Commands vs Plugins vs Subagents 개념 정리

Claude Code의 확장 시스템은 여러 요소로 구성됩니다. 각각의 역할을 명확히 이해해야 합니다:

💡 Claude Code 2.1+ 업데이트:

VSCode Native Plugin Management: VS Code 확장에서 플러그인을 직접 탐색하고 관리할 수 있습니다.
Task Management System: 의존성 추적이 포함된 새로운 태스크 관리 시스템이 추가되었습니다.
Anthropic 공식 Marketplace: anthropics/claude-code 저장소에 공식 플러그인 마켓플레이스가 포함되어 있습니다.

flowchart TB
 subgraph ExtSystem["Claude Code 확장 시스템 전체 구조"]
 direction TB

 subgraph Components["구성 요소"]
 direction LR
 Skills["🧠 Skills"]
 Commands["⌨️ Commands"]
 Subagents["👨‍💼 Subagents"]
 Plugins["📦 Plugins"]
 end

 subgraph Features["특징"]
 direction LR
 SK_F["자동 호출<br/>참조 지식<br/><br/>'레시피북'"]
 CMD_F["수동 호출<br/>/command<br/><br/>'단축키'"]
 SA_F["위임 실행<br/>격리 컨텍스트<br/><br/>'전문가'"]
 PL_F["배포 패키지<br/>(컨테이너)<br/><br/>'도구상자'"]
 end

 Skills --> SK_F
 Commands --> CMD_F
 Subagents --> SA_F
 Plugins --> PL_F

 subgraph PluginContents["Plugin이 포함할 수 있는 것"]
 direction LR
 P_Skills["Skills"]
 P_Commands["Commands"]
 P_Subagent["Subagent"]
 P_Hooks["Hooks"]
 P_MCP["MCP"]
 end
 end

 style Skills fill:#c8e6c9,color:#000000
 style Commands fill:#bbdefb,color:#000000
 style Subagents fill:#fff9c4,color:#000000
 style Plugins fill:#ffccbc,color:#000000
 style SK_F fill:#e8f5e9,color:#000000
 style CMD_F fill:#e3f2fd,color:#000000
 style SA_F fill:#fffde7,color:#000000
 style PL_F fill:#fbe9e7,color:#000000
 style PluginContents fill:#f5f5f5,color:#000000

1.2 각 요소 상세 비교

요소	호출 방식	컨텍스트	주요 용도	저장 위치
Skills	자동 (description 매칭)	메인에 주입	참조 지식, 패턴	`.claude/skills/`
Commands	수동 (`/command`)	메인에서 실행	반복 작업 자동화	`.claude/commands/`
Subagents	명시적 위임	격리된 윈도우	독립적 작업 처리	`.claude/agents/`
Plugins	설치 후 내부 요소 사용	해당 없음	배포/공유 패키지	Marketplace
Hooks	이벤트 트리거	자동 실행	강제 자동화	`.claude/settings.json`
MCP	외부 도구 연결	도구로 사용	외부 시스템 통합	`.mcp.json`

1.3 Plugin이 해결하는 문제

flowchart TB
 subgraph Before["❌ Plugin 등장 이전"]
 Q["'팀원 A의 Claude Code 설정을<br/>팀원 B에게 공유하려면?'"]
 B1["1. Skills 폴더 복사<br/>2. Commands 폴더 복사<br/>3. Agents 폴더 복사<br/>4. 설정 파일 수정<br/>5. 버전 관리 별도<br/>6. 업데이트 수동 반영"]
 BR["→ 복잡하고 오류 발생 가능성 높음"]
 end

 subgraph After["✅ Plugin 등장 이후"]
 A1["/plugin marketplace add my-team/our-plugins"]
 A2["/plugin install our-coding-standards@our-plugins"]
 AR["→ 버전 관리, 자동 업데이트,<br/>의존성 해결 모두 자동"]
 end

 Before --> After

 style Before fill:#ffcdd2,color:#000000
 style After fill:#c8e6c9,color:#000000
 style Q fill:#ef9a9a,color:#000000
 style BR fill:#ef9a9a,color:#000000
 style A1 fill:#a5d6a7,color:#000000
 style A2 fill:#a5d6a7,color:#000000
 style AR fill:#a5d6a7,color:#000000

2. Marketplace 시스템 이해

2.1 Marketplace란?

Marketplace는 Plugin들의 카탈로그입니다. Plugin을 검색하고 설치할 수 있는 저장소입니다.

Claude Code 완전 정복 가이드 Part 3: Skills 시스템 - 온디맨드 전문가 활용하기

Fri, 23 Jan 2026 17:20:57 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

예상 소요 시간: 1시간 난이도: ⭐⭐⭐ 사전 요구사항: Part 1, 2 완료 Claude Code 버전: 2.1.x (Hot Reload 지원)

1. Skills란 무엇인가?

1.1 CLAUDE.md vs Skills의 핵심 차이

CLAUDE.md는 항상 로드되는 “기본 매뉴얼"입니다. 반면 Skills는 필요할 때만 로드되는 “전문 레시피북"입니다.

💡 Claude Code 2.1+ 새 기능: Hot Reload - Skills를 수정하면 Claude Code를 재시작하지 않아도 즉시 반영됩니다. ~/.claude/skills/ 또는 .claude/skills/ 디렉토리의 변경사항이 실시간으로 적용됩니다.

Claude Code 완전 정복 가이드 Part 2: CLAUDE.md 최적화 - 비대해지는 것을 막아라

Fri, 23 Jan 2026 17:20:54 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

예상 소요 시간: 45분 난이도: ⭐⭐ 사전 요구사항: Part 1 완료, CLAUDE.md 사용 경험 Claude Code 버전: 2.1.x

1. 왜 CLAUDE.md는 간결해야 하는가?

1.1 LLM의 Instruction-following 한계

연구에 따르면 프론티어 LLM도 약 150-200개의 지시사항만 일관되게 따를 수 있습니다. Claude Code의 시스템 프롬프트 자체가 이미 ~50개의 지시를 포함하고 있어, CLAUDE.md에 사용할 수 있는 “지시 예산"은 제한적입니다.

flowchart TB
 subgraph Capacity["LLM 지시 따르기 용량"]
 direction TB
 Title["📊 총 용량: ~150-200개 지시"]

 subgraph Components["구성 요소"]
 direction LR
 A["🤖 Claude Code<br/>시스템 프롬프트<br/>(~50개)"]
 B["📄 CLAUDE.md<br/><br/>(당신의 몫)"]
 C["🧠 Skills/Rules<br/><br/>(추가 지시)"]
 end

 Warning["⚠️ 초과 시 → 균일하게 모든 지시를 무시하기 시작"]
 end

 Title --> Components
 Components --> Warning

 style Title fill:#e3f2fd,color:#000000
 style A fill:#bbdefb,color:#000000
 style B fill:#c8e6c9,color:#000000
 style C fill:#fff9c4,color:#000000
 style Warning fill:#ffcdd2,color:#000000

1.2 토큰 비용과 Context Window

CLAUDE.md는 모든 대화에서 항상 로드됩니다. 파일이 커질수록:

Claude Code 완전 정복 가이드 Part 1: CLAUDE.md 기초 - 첫 발을 내딛다

Fri, 23 Jan 2026 17:20:51 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

예상 소요 시간: 30분 난이도: ⭐ 사전 요구사항: Claude Code 설치 완료 (v2.1.x)

1. Claude Code란 무엇인가?

1.1 Agentic Coding의 개념

Claude Code는 단순한 코드 자동완성 도구가 아닙니다. Agentic Coding Assistant로서, 터미널에서 직접 코드베이스를 읽고, 파일을 생성/수정하고, 테스트를 실행하고, Git 작업까지 수행할 수 있습니다. 2025년 2월 첫 출시 이후 빠르게 발전하여, 현재 버전 2.1.x에서는 Opus 4.5 모델을 지원하며 더욱 강력한 기능을 제공합니다.

Claude Code 완전 정복 가이드 Part 0: Overview

Fri, 23 Jan 2026 17:20:48 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

버전: 2026년 1월 기준 (Claude Code 2.1.17 / Opus 4.5)
대상 독자: Claude Code를 처음 시작하거나, 이미 사용 중이지만 더 효율적으로 활용하고 싶은 개발자

🎯 이 가이드의 목표

이 가이드는 Claude Code 초보 사용자가 CLAUDE.md 파일 하나 만드는 것에서 시작해서, Skills와 Plugins를 활용한 고급 워크플로우까지 단계별로 성장할 수 있도록 구성되어 있습니다.

flowchart TD
 A["📝 CLAUDE.md<br/>생성"] --> B["⚡ 최적화<br/>전략"]
 B --> C["🧠 Skills<br/>분리"]
 C --> D["🔌 Plugins<br/>활용"]
 D --> E["🏪 Marketplace<br/>구축"]
 E --> F["🎯 고급 패턴<br/>통합"]
 
 style A fill:#bbdefb,color:#000000
 style B fill:#c8e6c9,color:#000000
 style C fill:#fff9c4,color:#000000
 style D fill:#ffccbc,color:#000000
 style E fill:#d1c4e9,color:#000000
 style F fill:#f8bbd0,color:#000000

📚 가이드 구성

Part 1: CLAUDE.md 기초 - 첫 발을 내딛다

예상 소요 시간: 30분 | 난이도: ⭐

Java: JEP 444, 485, 506, 519 설명

Thu, 22 Jan 2026 14:06:58 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

JEP 444: Virtual Threads (Java 21 - 정식 릴리스)

개요: 경량 스레드를 제공하여 수십만~수백만 개의 동시 작업을 효율적으로 처리할 수 있게 합니다. 플랫폼 스레드와 달리 OS 스레드를 1:1로 매핑하지 않습니다.

예제 1: 대량의 HTTP 요청 처리

Before (Platform Threads):

// 스레드 풀 사용 (제한된 스레드 수)
ExecutorService executor = Executors.newFixedThreadPool(100);

List<String> urls = IntStream.range(0, 10_000)
 .mapToObj(i -> "https://api.example.com/data/" + i)
 .toList();

List<Future<String>> futures = new ArrayList<>();
for (String url : urls) {
 futures.add(executor.submit(() -> {
 // HTTP 요청 시뮬레이션
 Thread.sleep(100);
 return fetchData(url);
 }));
}

// 결과 수집
List<String> results = new ArrayList<>();
for (Future<String> future : futures) {
 results.add(future.get());
}

executor.shutdown();
// 100개 스레드로 10,000개 요청 처리 → 느림

After (Virtual Threads):

AI-Native 아키텍처: Java 25와 Spring Boot 4.0 시대의 에이전트 중심 개발 패러다임

Thu, 22 Jan 2026 09:30:28 +0900

이 글은 Google Gemini Pro Deep Research 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

서론: 소프트웨어 개발의 새로운 지평

2026년을 맞이하며 엔터프라이즈 소프트웨어 개발 생태계는 전례 없는 전환점을 맞이하고 있습니다. 인공지능(AI), 특히 대규모 언어 모델(LLM)이 단순한 코딩 보조 도구를 넘어 자율적으로 소프트웨어를 설계, 구현, 수정하는 ‘에이전트(Agent)‘로 진화함에 따라, 우리가 코드를 작성하는 방식과 시스템을 아키텍처링하는 원칙 자체가 근본적으로 재평가되고 있습니다. 과거 10년이 마이크로서비스와 클라우드 네이티브의 시대였다면, 향후 10년은 인간 개발자와 AI 에이전트가 공존하며 협업하는 ‘AI-Native’ 시대가 될 것입니다.

Java to Go: #5. 프로젝트 구조와 생태계

Wed, 21 Jan 2026 12:28:40 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

지금까지 Go의 철학, 문법, 에러 처리, 동시성을 살펴봤다. 이제 실제 프로젝트를 시작하는 데 필요한 것들을 다룬다. Maven/Gradle에서 Go Modules로, JUnit에서 testing 패키지로, Spring에서 Go 라이브러리 조합으로 전환하는 방법을 알아보자.

1. Go Modules 기초

go.mod와 go.sum

Go 1.11부터 도입된 Go Modules가 공식 의존성 관리 시스템이다.

# 새 모듈 초기화
mkdir myproject && cd myproject
go mod init github.com/username/myproject

생성된 go.mod:

module github.com/username/myproject

go 1.21

의존성을 추가하면:

Java to Go: #4. 동시성: Goroutine과 Channel

Wed, 21 Jan 2026 12:28:36 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go의 동시성 모델은 Java와 근본적으로 다르다. Thread, synchronized, ExecutorService에 익숙한 개발자라면 처음엔 낯설겠지만, Go의 방식이 얼마나 우아한지 금방 알게 될 것이다. “공유 메모리로 통신하지 말고, 통신으로 메모리를 공유하라"는 Go의 철학을 이해해보자.

1. Goroutine: 경량 스레드

go 키워드 하나로 시작하는 동시성

Java에서 새 스레드를 만들려면:

new Thread(() -> {
 System.out.println("Hello from thread");
}).start();

// 또는 ExecutorService
ExecutorService executor = Executors.newFixedThreadPool(10);
executor.submit(() -> {
 System.out.println("Hello from thread pool");
});

Go에서는 go 키워드 하나면 된다:

Java to Go: #3. 에러 처리와 Null 안전성

Wed, 21 Jan 2026 12:28:33 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java 개발자가 Go를 배울 때 가장 큰 패러다임 전환이 필요한 부분이 에러 처리다. try-catch에 익숙한 우리에게 if err != nil의 반복은 처음엔 원시적으로 느껴진다. 하지만 이 방식에는 명확한 철학이 있다. 이번 편에서 그 철학을 이해하고, Go 방식의 에러 처리에 익숙해져 보자.

1. Java의 Exception vs Go의 error

근본적인 차이

Java: 예외는 “특별한 상황"이다. 정상 흐름과 분리되어 throw/catch로 처리된다.

Java to Go: #2. 문법 전환 가이드: Java 코드를 Go로 옮기기

Wed, 21 Jan 2026 12:28:30 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Part 1에서 Go의 철학과 언제 Go를 선택해야 하는지 살펴봤다. 이제 실제 코드 레벨에서 Java와 Go가 어떻게 다른지 1:1로 비교해보자. Java 문법에 익숙한 개발자가 Go 코드를 읽고 쓸 수 있도록 핵심 차이점을 정리한다.

1. 변수 선언과 타입 시스템

기본 변수 선언

Java:

String name = "Alice";
int age = 30;
final double PI = 3.14159;

Go:

var name string = "Alice"
var age int = 30
const PI = 3.14159

Go에서는 타입이 변수명 뒤에 온다. 처음엔 어색하지만, 복잡한 타입 선언에서는 오히려 읽기 쉽다.

Java to Go: #1. Go 첫인상: 철학과 패러다임의 차이

Wed, 21 Jan 2026 12:28:27 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Java를 수년간 써온 개발자가 Go를 처음 접하면 당혹스럽다. “왜 이렇게 만들었지?“라는 생각이 끊이지 않는다. 이 글에서는 Go의 설계 철학을 이해하고, Java에서 Go로의 전환이 언제 적절한지 판단할 수 있는 기준을 제시한다.

1. Go의 설계 철학: “Less is more”

Go는 2009년 Google에서 Robert Griesemer, Rob Pike, Ken Thompson이 만들었다. 세 사람 모두 수십 년 경력의 시스템 프로그래머로, C++의 복잡성에 지쳐 있었다. Go의 탄생 배경 자체가 “복잡함에 대한 반발"이다.

Go to Rust: #10. 프로젝트 관리와 실전 패턴

Mon, 19 Jan 2026 16:10:08 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 마지막 섹션에서는 실제 Rust 프로젝트를 구성하고 관리하는 방법을 학습합니다. Cargo 심화, 모듈 시스템, 테스트, 그리고 Go 코드를 Rust로 포팅할 때 유용한 패턴들을 다룹니다.

10.1 Cargo 심화

Cargo.toml 상세 설정

[package]
name = "myapp"
version = "0.1.0"
edition = "2021"
authors = ["Your Name <you@example.com>"]
description = "A sample Rust application"
license = "MIT"
repository = "https://github.com/you/myapp"
keywords = ["cli", "tool"]
categories = ["command-line-utilities"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1", features = ["full"] }

[dev-dependencies]
criterion = "0.5" # 벤치마크용

[build-dependencies]
cc = "1.0" # 빌드 스크립트용

[features]
default = ["json"]
json = ["serde_json"]
full = ["json", "yaml"]

[[bin]]
name = "myapp"
path = "src/main.rs"

[[bin]]
name = "mytool"
path = "src/bin/mytool.rs"

[profile.release]
opt-level = 3
lto = true

의존성 관리

[dependencies]
# 버전 지정
serde = "1.0" # ^1.0.0 (1.x.x)
serde = "=1.0.104" # 정확히 1.0.104
serde = ">=1.0, <2.0" # 범위

# Git 의존성
mylib = { git = "https://github.com/user/mylib" }
mylib = { git = "https://github.com/user/mylib", branch = "dev" }
mylib = { git = "https://github.com/user/mylib", tag = "v1.0.0" }
mylib = { git = "https://github.com/user/mylib", rev = "abc123" }

# 로컬 경로
mylib = { path = "../mylib" }

# 선택적 의존성
serde_json = { version = "1.0", optional = true }

# 피처 플래그
tokio = { version = "1", features = ["rt-multi-thread", "macros"] }

Go modules와 비교

# Go: go.mod
module github.com/user/myapp

go 1.21

require (
 github.com/gin-gonic/gin v1.9.0
 github.com/lib/pq v1.10.0
)

# Rust: Cargo.toml
[package]
name = "myapp"
version = "0.1.0"
edition = "2021"

[dependencies]
axum = "0.7"
sqlx = { version = "0.7", features = ["postgres"] }

측면	Go	Cargo
의존성 파일	go.mod	Cargo.toml
락 파일	go.sum	Cargo.lock
저장소	분산 (GitHub 등)	중앙 (crates.io)
버전 관리	Git 태그	SemVer

피처 플래그

[features]
default = ["std"]
std = []
alloc = []
json = ["serde", "serde_json"]
full = ["json", "yaml", "toml"]

// 조건부 컴파일
#[cfg(feature = "json")]
pub mod json {
 pub fn parse_json(s: &str) -> Value { /* ... */ }
}

#[cfg(feature = "std")]
use std::collections::HashMap;

#[cfg(not(feature = "std"))]
use alloc::collections::BTreeMap as HashMap;

10.2 모듈 시스템

파일 시스템과 모듈 구조

myapp/
├── Cargo.toml
└── src/
 ├── main.rs # 바이너리 루트
 ├── lib.rs # 라이브러리 루트
 ├── config.rs # config 모듈
 ├── utils/
 │ ├── mod.rs # utils 모듈
 │ ├── helpers.rs # utils::helpers
 │ └── format.rs # utils::format
 └── handlers/
 ├── mod.rs
 ├── user.rs
 └── post.rs

lib.rs:

Go to Rust: #9. 비동기 프로그래밍

Mon, 19 Jan 2026 16:09:59 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 async/await는 Go의 goroutine과 근본적으로 다른 접근 방식입니다. Go는 런타임이 모든 것을 관리하지만, Rust는 명시적인 비동기 모델을 사용합니다. 이 섹션에서는 Rust의 비동기 생태계와 Tokio 런타임을 학습합니다.

9.1 비동기의 필요성

동기 vs 비동기

동기 (Synchronous):

// 순차적 실행, 블로킹
fn fetch_data() -> Data {
 let response = http_get("https://api.example.com"); // 대기
 parse(response)
}

비동기 (Asynchronous):

// 대기 중 다른 작업 가능
async fn fetch_data() -> Data {
 let response = http_get("https://api.example.com").await; // 양보
 parse(response)
}

Go의 goroutine 모델

Go는 런타임이 내장되어 있어 동기 코드처럼 보이지만 비동기로 동작합니다:

Go to Rust: #8. 동시성 프로그래밍

Mon, 19 Jan 2026 16:09:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 “Fearless Concurrency"는 컴파일 타임에 데이터 레이스를 방지합니다. Go의 고루틴과 채널에 익숙하다면, Rust의 동시성 모델이 어떻게 다른지 이해하는 것이 중요합니다.

8.1 Rust의 동시성 철학

“Fearless Concurrency"란?

Go의 철학: “Don’t communicate by sharing memory; share memory by communicating.” Rust의 철학: “Fearless Concurrency through ownership.”

Go	Rust
런타임에 데이터 레이스 감지 (`-race`)	컴파일 타임에 데이터 레이스 방지
고루틴 + 채널 권장	소유권 + 타입 시스템으로 안전성 보장
공유 메모리도 가능 (주의 필요)	공유 메모리도 안전하게 사용 가능

데이터 레이스의 세 가지 조건

두 스레드가 같은 데이터에 접근
적어도 하나가 쓰기 작업
접근이 동기화되지 않음

Rust는 소유권 규칙으로 이를 컴파일 타임에 방지합니다:

Go to Rust: #7. 컬렉션과 이터레이터

Mon, 19 Jan 2026 16:09:42 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 컬렉션은 Go와 유사한 기능을 제공하지만, 소유권 시스템과 결합되어 더 안전합니다. 특히 이터레이터 시스템은 Go의 range보다 훨씬 강력하며, 함수형 프로그래밍 스타일을 지원합니다.

7.1 표준 컬렉션 개요

Go와 Rust 컬렉션 매핑

Go	Rust	설명
`[]T` (slice)	`Vec<T>`	동적 배열
`[N]T` (array)	`[T; N]`	고정 배열
`string`	`String`	소유된 문자열
`string` (리터럴)	`&str`	문자열 슬라이스
`map[K]V`	`HashMap<K, V>`	해시 맵
-	`HashSet<T>`	해시 셋
-	`BTreeMap<K, V>`	정렬된 맵
-	`BTreeSet<T>`	정렬된 셋
-	`VecDeque<T>`	양방향 큐
`container/list`	`LinkedList<T>`	이중 연결 리스트

7.2 Vec 심화

생성 방법들

// 빈 벡터
let v: Vec<i32> = Vec::new();

// vec! 매크로 (가장 흔함)
let v = vec![1, 2, 3, 4, 5];

// 같은 값으로 초기화
let v = vec![0; 10]; // [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

// 용량 미리 할당
let mut v = Vec::with_capacity(100);

// 이터레이터에서 수집
let v: Vec<i32> = (1..=5).collect();

// from_iter
let v = Vec::from_iter([1, 2, 3]);

기본 연산

let mut v = vec![1, 2, 3];

// 추가
v.push(4); // 끝에 추가
v.insert(0, 0); // 인덱스에 삽입: [0, 1, 2, 3, 4]

// 제거
let last = v.pop(); // 끝에서 제거, Option<T>
let removed = v.remove(0); // 인덱스에서 제거, T
v.retain(|&x| x > 2); // 조건에 맞는 것만 유지

// 접근
let first = v[0]; // 패닉 가능
let first = v.get(0); // Option<&T>
let first = v.first(); // Option<&T>
let last = v.last(); // Option<&T>

// 수정
v[0] = 10;
if let Some(first) = v.first_mut() {
 *first = 20;
}

Go의 append vs Rust의 push

// Go: append는 새 슬라이스 반환 가능
slice := []int{1, 2, 3}
slice = append(slice, 4) // 재할당 가능

// 용량 확인
cap(slice)

// Rust: push는 in-place 수정
let mut v = vec![1, 2, 3];
v.push(4); // v가 mut이어야 함

// 용량
v.capacity();
v.reserve(100); // 추가 용량 확보
v.shrink_to_fit(); // 불필요한 용량 해제

소유권과 Vec

let v = vec![String::from("a"), String::from("b")];

// 인덱스 접근은 빌림
let first: &String = &v[0]; // 불변 빌림

// for 루프는 소유권 이동 또는 빌림 선택 가능
for s in v { // v의 소유권 이동, s: String
 println!("{}", s);
}
// v는 더 이상 사용 불가

let v = vec![String::from("a"), String::from("b")];
for s in &v { // v 빌림, s: &String
 println!("{}", s);
}
// v 여전히 사용 가능

for s in &mut v { // 가변 빌림, s: &mut String
 s.push_str("!");
}

슬라이싱

let v = vec![1, 2, 3, 4, 5];

// 슬라이스 참조
let slice: &[i32] = &v[1..4]; // [2, 3, 4]
let slice: &[i32] = &v[..]; // 전체

// 가변 슬라이스
let mut v = vec![1, 2, 3, 4, 5];
let slice: &mut [i32] = &mut v[1..4];
slice[0] = 20; // v는 [1, 20, 3, 4, 5]

7.3 문자열 처리

String vs &str

// String: 힙에 할당된 소유 문자열
let owned: String = String::from("hello");
let owned: String = "hello".to_string();
let owned: String = "hello".to_owned();

// &str: 문자열 슬라이스 (빌림)
let borrowed: &str = "hello"; // 정적 문자열
let borrowed: &str = &owned; // String에서 빌림
let borrowed: &str = &owned[0..3]; // 부분 슬라이스

특성	`String`	`&str`
소유권	있음	없음 (빌림)
힙 할당	예	아니오
가변	가능	불가능
크기	가변	고정 (뷰)
함수 인자	소유권 필요시	대부분

UTF-8 인코딩

Rust 문자열은 항상 유효한 UTF-8입니다:

Go to Rust: #6. 에러 처리

Mon, 19 Jan 2026 16:09:35 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Rust의 에러 처리는 Go와 철학적으로 유사합니다. 두 언어 모두 예외(exception)를 사용하지 않고 명시적인 에러 반환을 선호합니다. 하지만 Rust는 타입 시스템을 통해 에러 처리를 강제하여, Go에서 흔히 발생하는 “에러 무시” 문제를 원천 차단합니다.

6.1 Rust의 에러 처리 철학

복구 가능한 에러 vs 복구 불가능한 에러

Rust는 에러를 두 가지로 구분합니다:

복구 가능한 에러 (Recoverable): Result<T, E>

파일을 찾을 수 없음
네트워크 연결 실패
잘못된 사용자 입력

복구 불가능한 에러 (Unrecoverable): panic!

Go to Rust: #5. 트레이트와 제네릭

Mon, 19 Jan 2026 09:56:15 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

트레이트(Trait)는 Rust의 다형성 메커니즘입니다. Go의 인터페이스와 비슷한 역할을 하지만, 구현 방식과 기능에서 큰 차이가 있습니다. 이 섹션에서는 트레이트와 제네릭을 Go와 비교하며 깊이 있게 학습합니다.

5.1 트레이트 기초

트레이트란?

트레이트는 타입이 구현해야 하는 메서드 집합을 정의합니다:

// 트레이트 정의
trait Summary {
 fn summarize(&self) -> String;
}

// 타입 정의
struct Article {
 title: String,
 author: String,
 content: String,
}

// 트레이트 구현
impl Summary for Article {
 fn summarize(&self) -> String {
 format!("{} by {}", self.title, self.author)
 }
}

Go interface vs Rust trait

가장 큰 차이: 암묵적 vs 명시적

Go to Rust: #4. 구조체, 열거형, 패턴 매칭

Mon, 19 Jan 2026 09:56:10 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 섹션에서는 Rust에서 데이터를 구조화하는 방법을 학습합니다. Go 개발자에게 구조체는 익숙하겠지만, Rust의 열거형(enum)은 Go의 const/iota보다 훨씬 강력하며, 패턴 매칭은 switch문을 완전히 새로운 수준으로 끌어올립니다.

4.1 구조체 (Struct)

구조체 정의와 인스턴스 생성

// 구조체 정의
struct User {
 username: String,
 email: String,
 sign_in_count: u64,
 active: bool,
}

// 인스턴스 생성
fn main() {
 let user = User {
 username: String::from("alice"),
 email: String::from("alice@example.com"),
 sign_in_count: 1,
 active: true,
 };
 
 // 필드 접근
 println!("Username: {}", user.username);
}

Go struct와의 문법 비교:

Go to Rust: #3. 소유권과 빌림 (Ownership & Borrowing)

Mon, 19 Jan 2026 09:56:03 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

소유권(Ownership)은 Rust의 가장 독특하고 중요한 개념입니다. Go의 가비지 컬렉션과 완전히 다른 접근 방식으로, 컴파일 타임에 메모리 안전성을 보장합니다. 이 섹션은 Rust 학습에서 가장 중요한 부분이므로 충분한 시간을 들여 이해하시기 바랍니다.

3.1 소유권이란 무엇인가?

메모리 관리의 세 가지 방식

프로그래밍 언어들은 메모리를 관리하는 방식이 다릅니다:

1. 가비지 컬렉션 (Go, Java, Python, JavaScript)

// Go: GC가 알아서 정리
func example() {
 slice := make([]int, 1000000)
 // 함수 종료 후 GC가 언젠가 정리
}

장점: 개발자가 메모리 관리 신경 안 써도 됨
단점: GC 일시 정지, 예측 불가능한 지연, 메모리 오버헤드

2. 수동 관리 (C, C++)

Go to Rust: #2. 기본 문법과 타입 시스템

Mon, 19 Jan 2026 09:55:56 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

이 섹션에서는 Rust의 기본 문법을 Go와 비교하며 학습합니다. Go 개발자에게 익숙한 개념들이 Rust에서 어떻게 표현되는지, 그리고 Rust만의 독특한 특징은 무엇인지 알아봅니다.

2.1 변수와 가변성

let vs var: 불변이 기본인 이유

Go에서는 변수가 기본적으로 가변(mutable)입니다:

// Go: 기본이 가변
x := 10
x = 20 // OK

Rust에서는 불변(immutable)이 기본입니다:

// Rust: 기본이 불변
let x = 10;
x = 20; // 컴파일 에러!

왜 불변이 기본일까요?

Go to Rust: #1. 시작하기 - Rust 소개와 환경 설정

Mon, 19 Jan 2026 09:55:50 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

Go 개발자로서 새로운 언어를 배우려면 먼저 그 언어가 왜 존재하는지, 어떤 문제를 해결하려고 하는지 이해하는 것이 중요합니다. 이 섹션에서는 Rust의 설계 철학을 Go와 비교하며 이해하고, 개발 환경을 설정한 뒤 첫 프로젝트를 생성해봅니다.

1.1 Rust는 왜 배워야 하는가?

Rust의 설계 철학

Rust는 Mozilla Research에서 시작되어 2015년에 1.0이 릴리스된 시스템 프로그래밍 언어입니다. Rust의 핵심 목표는 세 가지입니다:

안전성(Safety): 메모리 안전성을 컴파일 타임에 보장
속도(Speed): C/C++에 필적하는 성능
동시성(Concurrency): 데이터 레이스 없는 동시성 프로그래밍

Go도 비슷한 시기(2009년)에 등장했지만, 설계 목표가 다릅니다:

Go to Rust: #0. Overview

Mon, 19 Jan 2026 08:36:02 +0900

이 글은 Claude Opus 4.5 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

From Go to Rust: A Comprehensive Guide for Go Developers

Go 언어에 익숙한 개발자가 Rust를 체계적으로 학습할 수 있도록 구성된 가이드입니다. Go와의 비교를 통해 새로운 개념을 빠르게 이해하고, 실무에서 바로 적용할 수 있는 실용적인 내용을 담았습니다.

가이드의 특징

Go 개발자 관점: 모든 개념을 Go와 비교하여 설명, 익숙한 개념에서 출발
실용적 접근: 이론보다 실제 코드 예제 중심
점진적 난이도: 기초부터 고급까지 체계적 진행
실전 지향: 각 섹션에 Go ↔ Rust 코드 변환 예제 포함
함정 주의: Go 개발자가 흔히 하는 실수와 해결법 명시

섹션별 상세 목차

Section 1: 시작하기 - Rust 소개와 환경 설정

Rust의 설계 철학을 이해하고, Go와의 포지셔닝 차이를 명확히 합니다. 개발 환경을 설정하고 첫 프로젝트를 생성합니다.

르네상스 개발자: AWS CTO Werner Vogels 가 제시하는 AI 시대 개발자의 5가지 자질

Fri, 19 Dec 2025 13:47:59 +0900

Claude Opus 4.5 을 활용해 작성한 글입니다.

서론: 왜 ‘르네상스 개발자’인가?

“AI가 내 직업을 빼앗을까? 아마도, 그럴 것이다. 하지만, 이 질문을 재구성하는 게 좋겠다. AI가 개발자를 쓸모없게 만들까? 절대로 아니다. 진화한다면.”

— Werner Vogels, AWS CTO

보겔스 박사는 개발자가 어셈블리어, 구조적 프로그래밍, 객체 지향 언어, 클라우드 도입 등 시대에 따라 등장했던 새로운 도구를 통해 더 훌륭한 엔지니어로 진화해왔다고 강조합니다. AI 역시 마찬가지입니다.

제프 베조스의 말을 인용하며, 보겔스 박사는 현재를 “우주 여행, 인공지능, 로봇공학 등 여러 황금기가 동시에 만나는 시대"라고 정의했습니다. 이러한 돌파구들이 서로를 강화하며 발전하는 모습이 바로 르네상스 시대와 닮아있다는 것입니다.

TotT: 도메인 객체로 변경에 유연한 코드 작성하기

Thu, 04 Dec 2025 10:12:26 +0900

원문: https://testing.googleblog.com/2024/09/write-change-resilient-code-with-domain.html (Translated by Google Gemini)

제품의 요구사항은 자주 바뀔 수 있지만, 그 근본적인 아이디어는 보통 천천히 변합니다. 이는 흥미로운 통찰로 이어집니다. 만약 우리가 제품의 근본적인 아이디어와 일치하는 코드를 작성한다면, 그 코드는 미래의 제품 변경에도 살아남을 가능성이 더 높습니다.

도메인 객체(Domain objects) 는 우리 코드 안에서 제품의 근본적인 아이디어와 일치하는 구성 요소(클래스나 인터페이스 같은)입니다. 제품 요구사항에 따른 원하는 행동(“텍스트를 흰색으로 설정”)에 맞춰 코드를 작성하는 대신, 우리는 기저에 깔린 아이디어(“텍스트 색상 설정”)에 맞춥니다.

TotT: SMURF - 테스트 피라미드를 넘어서

Wed, 03 Dec 2025 07:56:35 +0900

원문: https://testing.googleblog.com/2023/09/else-nuances.html (Translated by Google Gemini)

테스트 피라미드는 테스트 스위트의 발전을 안내하는 정석적인 경험 법칙(heuristic)입니다. 이는 단순한 메시지를 전달합니다. 통합 테스트보다 더 많은 단위 테스트를 선호하고, 엔드 투 엔드(end-to-end) 테스트보다 더 많은 통합 테스트를 선호하라는 것입니다.

테스트 피라미드는 유용하지만, 테스트 스위트가 커지고 어려운 트레이드오프(trade-off) 상황에 직면했을 때 필요한 세부 정보가 부족합니다. 테스트 스위트를 확장하려면 테스트 피라미드 그 이상이 필요합니다.

SMURF 는 테스트 스위트의 균형을 잡을 때 고려해야 할 트레이드오프들을 기억하기 쉬운 약어입니다:

TotT: Else 문의 미묘한 차이

Wed, 03 Dec 2025 07:49:25 +0900

원문: https://testing.googleblog.com/2023/09/else-nuances.html (Translated by Google Gemini)

함수가 if 문에서 일찍 종료(return)되는 경우, else 절을 사용하는 것과 사용하지 않는 것은 동작상으로는 동일합니다. 하지만 else 절과 가드 절(guard clause, else가 없는 형태)을 적절히 사용하면 코드를 읽는 사람에게 의도를 더 명확하게 전달할 수 있습니다.

함수 구조를 잡는 데 도움이 될 만한 다음 가이드라인들을 고려해 보세요:

특수한 케이스를 미리 처리하기 위해 가드 절(Guard clause)을 사용하세요. 이렇게 하면 나머지 코드는 핵심 로직에 집중할 수 있습니다. 가드 절은 조건을 확인하고 충족되지 않을 경우 빠르게 실패하거나 일찍 반환하여 중첩(nesting)을 줄여줍니다.

Go 웹 애플리케이션에서 static contents를 서빙하는 표준 패턴

Wed, 26 Nov 2025 08:07:14 +0900

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

이 글은 GOTH Stack 웹 애플리케이션 개발 과정에서 발견한 패턴을 Claude Sonnet 을 이용해 정리한 것입니다.

문제 상황: URL과 파일 시스템 경로의 불일치

웹 애플리케이션을 개발하다 보면 다음과 같은 구조를 자주 마주치게 됩니다:

Go 웹 개발의 새로운 파도: GOTH 스택 (Go, Templ, HTMX) 시작하기

Mon, 24 Nov 2025 18:12:06 +0900

복잡한 리액트(React) 상태 관리, 비대해진 node_modules, 그리고 끝없는 JSON 직렬화/역직렬화에 지치셨나요? 백엔드 개발자에게 가장 편안한 언어인 Go를 사용하면서도, 현대적인 SPA(Single Page Application) 같은 사용자 경험을 제공하는 GOTH 스택을 소개합니다. GOTH(Go + Templ + HTMX) 스택은 최근 Go 커뮤니티에서 “다시 재미있게 웹 개발을 하자(Make Web Dev Fun Again)” 는 흐름과 함께 큰 주목을 받고 있습니다. 복잡한 JS 프레임워크 없이 Go의 강점인 단순함과 성능을 그대로 살릴 수 있는 것이 특징입니다.

이 글은 요청에 대한 Gemini 3 Pro 의 답변입니다.

Go: `net/http` vs. `chi`

Mon, 24 Nov 2025 17:49:44 +0900

Go 언어의 웹 생태계에서 net/http (표준 라이브러리) 와 chi 는 가장 “Go스러운(Idiomatic)” 선택지로 꼽힙니다. Gin이나 Echo 같은 “웹 프레임워크"와 달리, chi는 표준 라이브러리의 인터페이스를 그대로 따르면서 부족한 라우팅 기능을 보강해주는 “라우터"이기 때문입니다.

특히 Go 1.22 버전부터 net/http의 라우팅 기능이 대폭 강화되었기 때문에, 이 둘의 차이를 명확히 이해하는 것이 중요합니다.

이 글은 요청에 대한 Gemini 3 Pro 의 답변입니다.

1. `net/http` vs `chi` 요약 비교

특징	`net/http` (Go 1.22+)	`chi`
외부 의존성	없음 (Zero dependency)	있음 (But 매우 가벼움)
인터페이스	`http.Handler`	`http.Handler` (100% 호환)
라우팅 (Path)	지원 (`/items/{id}`)	강력하게 지원 (Regex 등 포함)
메서드 매칭	지원 (`POST /items`)	지원 (`r.Post("/items", ...)`)
미들웨어 관리	직접 구현 필요 (복잡함)	매우 강력하고 간편함 (`Use`)
라우팅 그룹	직접 구현 필요	기본 지원 (`Group`)
속도	빠름	매우 빠름 (Radix Tree 기반)

2. 왜 앱이 커질수록 `chi`가 유리한가?

앱이 복잡해진다는 것은 엔드포인트가 많아지고, 공통 로직(인증, 로깅, CORS 등)이 복잡해진다는 뜻입니다. 이 지점에서 chi가 net/http보다 압도적인 강점을 가집니다.

TotT: 함수 가독성 향상을 위해 추상화를 활용하세요

Mon, 24 Nov 2025 10:02:42 +0900

원문: https://testing.googleblog.com/2023/09/use-abstraction-to-improve-function.html (Translated by Google Gemini)

아래에 있는 두 가지 createPizza 함수 버전 중 어느 쪽이 이해하기 더 쉬울까요?

A. 추상화 수준이 혼재된 버전 (나쁜 예)

func createPizza(order *Order) *Pizza {
 pizza := &Pizza{Base: order.Size, Sauce: order.Sauce, Cheese: "Mozzarella"}
 if order.kind == "Veg" {
 pizza.Toppings = vegToppings
 } else if order.kind == "Meat" {
 pizza.Toppings = meatToppings
 }

 oven := oven.New()
 if oven.Temp != cookingTemp {
 for (oven.Temp < cookingTemp) {
 time.Sleep(checkOvenInterval)
 oven.Temp = getOvenTemp(oven)
 }
 }

 if !pizza.Baked {
 oven.Insert(pizza)
 time.Sleep(cookTime)
 oven.Remove(pizza)
 pizza.Baked = true
 }

 box := box.New()
 pizza.Boxed = box.PutIn(pizza)
 pizza.Sliced = box.SlicePizza(order.Size)
 pizza.Ready = box.Close()
 return pizza
}

B. 일관된 추상화 수준을 가진 버전 (좋은 예)

func createPizza(order *Order) *Pizza {
 pizza := prepare(order)
 bake(pizza)
 box(pizza)
 return pizza
}

func prepare(order *Order) *Pizza {
 pizza := &Pizza{Base: order.Size, Sauce: order.Sauce, Cheese: "Mozzarella"}
 addToppings(pizza, order.kind)
 return pizza
}

func addToppings(pizza *Pizza, kind string) {
 if kind == "Veg" {
 pizza.Toppings = vegToppings
 } else if kind == "Meat" {
 pizza.Toppings = meatToppings
 }
}

func bake(pizza *Pizza) {
 oven := oven.New()
 heatOven(oven)
 bakePizza(pizza, oven)
}

func heatOven(oven *Oven) { … }

func bakePizza(pizza *Pizza, oven *Oven) { … }

func box(pizza *Pizza) { … }

추상화 수준을 일치시켜야 하는 이유

여러분은 아마 오른쪽(좋은 예)이 더 쉽다고 답했을 것입니다. 하지만 그 이유는 무엇일까요?

TotT: 관심사 분리? 끝!

Mon, 20 Oct 2025 13:17:31 +0900

원문: https://testing.googleblog.com/2020/12/testing-on-toilet-separation-of.html (Translated by Google Gemini)

다음 함수는 SpeedyImg라는 API를 사용하여 바이트 배열을 이미지로 디코딩합니다. 다른 팀이 소유한 API를 참조할 때 어떤 유지보수 문제가 발생할 수 있을까요?

SpeedyImgImage decodeImage(List<SpeedyImgDecoder> decoders, byte[] data) {
 SpeedyImgOptions options = getDefaultConvertOptions();
 for (SpeedyImgDecoder decoder : decoders) {
 SpeedyImgResult decodeResult = decoder.decode(decoder.formatBytes(data));
 SpeedyImgImage image = decodeResult.getImage(options);
 if (validateGoodImage(image)) { return image; }
 }
 throw new RuntimeException();
}

API 호출에 대한 세부 정보가 도메인 로직과 혼합되어 있어 코드를 이해하기 어렵게 만들 수 있습니다. 예를 들어, decoder.formatBytes() 호출은 API에서 필요하지만 바이트가 어떻게 포맷되는지는 도메인 로직과 관련이 없습니다.

번역글: 섣부른 최적화, 아니면... 내가 한 말은 나부터 지켜야 했는데

Fri, 10 Oct 2025 11:09:21 +0900

원문: Pragmatic Programmers Newsletter (Translated by Google Gemini)

저는 제 자신의 조언을 무시했고, 하루를 꼬박 날렸으며, 제가 저 자신의 최악의 고객임을 다시 한번 증명하고 말았습니다. (하지만 절망하지 마세요. 글 마지막에 쿠폰 코드가 있습니다.)

저희의 새로운 유통사는 요금을 청구할 항목들을 만들어내는 데 특별한 재능이 있습니다. 그런 항목이 수십 가지나 되죠. 저희는 순수익에 대해 로열티를 지급하기 때문에, 모든 청구 항목을 하나하나 맞춰봐야 합니다. 간단하죠, 안 그런가요?

문제는 “권당” 발생하는 비용은 한 정산서에 나오고, “총액 공제” 항목은 다른 정산서에 나온다는 겁니다. 게다가 각 총액 항목 안에는 어떤 이름표도 없이 뒤죽박죽 섞인 비용들이 숨어있곤 합니다. 저희가 받는 것이라고는 날짜 두어 개와 무작위로 보이는 총액 하나가 전부입니다. 그러면 저희는 그 총액을 특정 비용들의 어떤 조합과 맞춰봐야 하는 것이죠.

TotT: 당신이 소유하지 않은 타입은 목킹(Mock)하지 마세요

Tue, 23 Sep 2025 13:36:30 +0900

원문: https://testing.googleblog.com/2020/07/testing-on-toilet-dont-mock-types-you.html (Translated by Google Gemini)

단위 테스트를 작성할 때, 테스트 대상 코드가 의존하는 타입을 목(mock) 처리하는 것은 일반적인 관행입니다. 하지만, 당신이 소유하지 않은 타입(types you don’t own)을 목 처리하는 것은 거의 항상 피해야 합니다. 여기서 “소유하지 않은 타입"이란 당신의 팀이 작성하거나 관리하지 않는 모든 클래스나 인터페이스를 의미합니다. 여기에는 자바 표준 라이브러리의 URL이나 서드파티 라이브러리의 JSONObject와 같은 타입들이 포함됩니다.

예를 들어, java.net.HttpURLConnection을 직접 목 처리하는 테스트를 생각해 봅시다.

@Test
public void testProcessUrl_connectionFailed() throws Exception {
 HttpURLConnection mockConnection = mock(HttpURLConnection.class);
 when(mockConnection.getResponseCode()).thenThrow(new IOException());

 Processor processor = new Processor();
 assertFalse(processor.processUrl(mockConnection));
}

이 테스트에는 몇 가지 심각한 문제가 있습니다.

아키텍처 비교: VSA vs. Hexagonal Architecture

Mon, 22 Sep 2025 14:14:05 +0900

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

TotT: 테스트 데이터를 깔끔하게 만드세요

Mon, 22 Sep 2025 09:29:50 +0900

원문: https://testing.googleblog.com/2018/02/testing-on-toilet-cleanly-create-test.html (Translated by Google Gemini)

테스트를 작성할 때, 우리는 종종 테스트 대상 코드가 소비할 객체들을 만들어야 합니다. 이 객체들은 진짜 객체일 수도 있고, 페이크(fake)나 목(mock) 객체일 수도 있습니다. 이러한 객체들을 생성하는 코드는 빠르게 지저분해지고, 테스트의 가독성을 해치며, 유지보수를 어렵게 만들 수 있습니다.

다음 예제를 살펴보겠습니다.

@Test
public void testWriteSecureMessage() {
 // 테스트를 위한 설정
 Message message = new Message();
 message.setId("42");
 message.setBody("Four score and seven years ago...");
 message.setSignature("1a2b3c4d5e");

 User sender = new User();
 sender.setId("Abc.123");
 sender.setName("Abraham Lincoln");

 // 테스트 실행
 writer.writeSecureMessage(message, sender);

 // 상태 검증
 assertEquals("Sent secure message with signature 1a2b3c4d5e", logger.getInfo());
}

이 테스트에서 객체 생성은 꽤 장황합니다. 테스트의 핵심 로직을 이해하기 어렵게 만들고, 테스트가 실제로 무엇을 검증하려는지 불분명하게 만듭니다.

TotT: 상태를 변경하는 메서드 호출만 검증하세요

Fri, 19 Sep 2025 15:26:56 +0900

원문: https://testing.googleblog.com/2017/01/testing-on-toilet-keep-cause-and-effect.html (Translated by Google Gemini)

이 테스트에서 어떤 라인을 안전하게 제거할 수 있을까요?

@Test
public void addPermissionToDatabase() {
 new UserAuthorizer(mockUserService, mockPermissionDb).grantPermission(USER, READ_ACCESS);

 // 이 메서드 중 하나라도 호출되지 않으면 테스트는 실패합니다.
 verify(mockUserService).isUserActive(USER);
 verify(mockPermissionDb).getPermissions(USER);
 verify(mockPermissionDb).isValidPermission(READ_ACCESS);
 verify(mockPermissionDb).addPermission(USER, READ_ACCESS);
}

정답은 상태를 변경하지 않는 메서드를 검증하는 호출들을 제거할 수 있다는 것입니다.

다른 객체에 대한 메서드 호출은 다음 두 가지 범주 중 하나에 속합니다.

상태 변경(State-changing): 부작용(side effects)이 있고 테스트 대상 코드 외부의 세상을 바꾸는 메서드. 예: sendEmail(), saveRecord(), logAccess().
비-상태 변경(Non-state-changing): 테스트 대상 코드 외부 세상에 대한 정보를 반환하고 아무것도 수정하지 않는 메서드. 예: getUser(), findResults(), readFile().

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

AI 툴 소개: GitHub Spec Kit: AI 에이전트 개발을 위한 명세서

Wed, 17 Sep 2025 10:02:47 +0900

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

이러한 표준을 채택함으로써, 우리는 AI 에이전트 개발 생태계가 더욱 강력하고 상호 운용 가능하도록 만들 수 있습니다.

원문: https://github.com/github/spec-kit (Translated by Google Gemini) (2025-09-17 기준)

🤔 명세 기반 개발이란 무엇입니까?

명세 기반 개발은 전통적인 소프트웨어 개발의 판도를 뒤집습니다. 수십 년 동안 코드가 왕이었습니다 — 명세는 코딩이라는 “진짜 작업"이 시작되면 만들어졌다가 버려지는 비계(scaffolding)에 불과했습니다. 명세 기반 개발은 이를 변화시킵니다: 명세가 실행 가능해지며, 단지 구현을 안내하는 것을 넘어 직접 작동하는 구현체를 생성합니다.

TotT: 중첩 줄이기, 복잡도 낮추기

Wed, 17 Sep 2025 09:49:08 +0900

원문: https://testing.googleblog.com/2017/06/code-health-reduce-nesting-reduce.html (Translated by Google Gemini)

과도하게 중첩된 코드는 가독성을 해치고 오류를 발생시키기 쉽습니다. 아래 두 버전의 코드에서 버그를 찾아보세요.

과도하게 중첩된 코드:

response = server.Call(request)
 
if response.GetStatus() == RPC.OK:
 if response.GetAuthorizedUser():
 if response.GetEnc() == 'utf-8':
 if response.GetRows():
 vals = [ParseRow(r) for r in 
 response.GetRows()]
 avg = sum(vals) / len(vals)
 return avg, vals
 else:
 raise EmptyError()
 else:
 raise AuthError('unauthorized')
 else:
 raise ValueError('wrong encoding')
else:
 raise RpcError(response.GetStatus())

중첩이 적은 코드:

response = server.Call(request)
 
if response.GetStatus() != RPC.OK:
 raise RpcError(response.GetStatus())

if not response.GetAuthorizedUser():
 raise ValueError('wrong encoding')

if response.GetEnc() != 'utf-8':
 raise AuthError('unauthorized')
 
if not response.GetRows():
 raise EmptyError()

vals = [ParseRow(r) for r in 
 response.GetRows()]
avg = sum(vals) / len(vals)
return avg, vals

정답: “wrong encoding"과 “unauthorized” 에러가 서로 바뀌었습니다. 이 버그는 리팩터링된 버전에서 더 쉽게 발견할 수 있는데, 그 이유는 검사가 에러를 처리하는 부분 바로 옆에서 일어나기 때문입니다.

TotT: 원인과 결과를 명확하게 유지하세요

Fri, 12 Sep 2025 12:33:09 +0900

원문: https://testing.googleblog.com/2017/01/testing-on-toilet-keep-cause-and-effect.html (Translated by Google Gemini)

이 테스트가 올바른지 판단할 수 있나요?

@Test
public void testIncrement_existingKey() {
 assertEquals(9, tally.get("key1"));
}

tally 객체가 어떻게 설정되었는지 보지 않고는 알아내는 것이 불가능합니다.

private final Tally tally = new Tally();
@Before
public void setUp() {
 tally.increment("key1", 8);
 tally.increment("key2", 100);
 tally.increment("key1", 0);
 tally.increment("key1", 1);
}

// 200줄 떨어져 있음
@Test 
public void testIncrement_existingKey() {
 assertEquals(9, tally.get("key1"));
}

문제는 key1의 값을 수정하는 부분이 검증(assertion)으로부터 200줄 이상 떨어져 있다는 점입니다. 다시 말해, ‘원인’이 ‘결과’로부터 너무 멀리 숨겨져 있습니다.

TotT: 무엇이 좋은 End-to-End 테스트를 만드는가?

Thu, 11 Sep 2025 10:33:09 +0900

원문: https://testing.googleblog.com/2016/09/testing-on-toilet-what-makes-good-end.html (Translated by Google Gemini)

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

하지만 안타깝게도, E2E 테스트는 단위 테스트나 통합 테스트보다 느리고, 불안정하며(flaky), 유지보수 비용이 더 비쌉니다. E2E 테스트가 필요한지, 만약 그렇다면 어떻게 작성하는 것이 최선일지 신중하게 고려해야 합니다.

번역글: LLM과 소프트웨어 개발에 대한 몇 가지 생각

Mon, 08 Sep 2025 14:10:40 +0900

원문: https://martinfowler.com/articles/202508-ai-thoughts.html (translated by Gemini)

저는 몇 주간 이 사이트 관리를 잠시 떠나려 합니다 (일부 휴가, 일부 업무). 일상적인 루틴에서 벗어나 몇 주를 보낼 생각을 하니, LLM과 AI의 현재 상태에 대한 산발적인 생각들을 나누고 싶은 충동을 느낍니다.

AI가 소프트웨어 개발에 어떤 영향을 미치는지에 대한 초기 설문조사들을 몇 가지 봤습니다. 과연 개발 속도를 높여주고 있는지, 코드 품질을 향상시키는지 아니면 망치고 있는지에 대한 내용들이죠. 이런 설문조사들의 큰 문제점 중 하나는 사람들이 LLM을 어떻게 사용하고 있는지 고려하지 않는다는 점입니다. 제가 아는 바로는 LLM 사용의 대다수가 코파일럿(Co-pilot)을 이용하는 것과 같은 단순한 자동 완성에 그치고 있습니다. 하지만 LLM으로부터 가장 큰 가치를 얻는다고 말하는 사람들은 자동 완성이 그다지 유용하지 않다고 생각하며, LLM이 소스 코드 파일을 직접 읽고 편집하여 작업을 수행하는 방식을 선호합니다. LLM을 사용하는 다양한 워크플로우를 무시하는 설문조사는 사람들을 잘못된 길로 이끌 수 있는 데이터를 만들어낼까 봐 걱정됩니다. (또 다른 복잡한 문제는 모델마다 기능이 다르다는 점입니다.)

번역글: Rust 의 목적성에 대한 질문과 답변

Mon, 08 Sep 2025 11:28:08 +0900

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

Q: Rust는 ‘메모리 안전성’보다는 Rust를 사용해 경력 있는 시니어 개발자들의 일을 값싼 주니어들이 해낼 수 있을 거라는 희망을 품고 그들을 고용하는 것과 더 관련이 있는 것 아닌가요? 제가 틀렸나요? Rust가 새로운 Ruby인가요?

A1 (Matt Laine의 답변):

어떤 프로그래밍 언어의 기능이든 홍보되는 데는 이유가 있습니다. 어떤 기능들은 언어 설계자가 멋지다고 생각해서 홍보되죠. 또 다른 기능들은 개발 속도를 높여준다거나, 특정 관리자들이 골치 아프다고 여기는 종류의 오류들을 제거해준다거나, 비즈니스에 도움이 되는 어떤 지표를 향상시켜 준다는 약속을 하는 것으로 해석될 수 있기 때문에 홍보됩니다. 또 어떤 기능들은 그저 과대광고를 철석같이 믿고 다른 사람들도 그렇게 해주기를 바라는 ‘언어 전도사들’에 의해 홍보되기도 합니다.

개발 팁: 읽기 쉽고 확장 가능한 if 구문 리팩토링 가이드

Fri, 05 Sep 2025 13:02:51 +0900

프로그래밍에서 if 를 사용하는 조건부 로직을 대체할 수 있는 방법들에 대해 gemini 2.5 pro 에게 요청한 연구 결과입니다.
모든 예제 코드는 Go 로 작성되었으나, 다른 프로그래밍 언어에 공통적으로 적용할 수 있는 내용들입니다.

서론: 조건문의 확산과 기술 부채의 축적

소프트웨어 개발에서 if-else 문은 제어 흐름을 구성하는 가장 기본적인 도구 중 하나입니다. 그러나 이 근본적인 구조는 종종 오용되어, 시간이 지남에 따라 시스템의 건강을 심각하게 해치는 주범이 되기도 합니다. 복잡하게 중첩되거나 끝없이 이어지는 if-else 체인은 가독성을 저해하고 유지보수를 악몽으로 만들며, 이는 소프트웨어 공학에서 “코드 스멜(code smell)“이라 불리는 명백한 위험 신호입니다. [1, 2, 3]

깊은 모듈 대 작은 함수: 오스터하우트와 마틴의 소프트웨어 설계 철학 및 커뮤니티 수용에 대한 비교 분석

Mon, 01 Sep 2025 15:49:15 +0900

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

Ousterhout 와 Martin 의 소프트웨어 설계 철학의 공통점, 차이점 및 충돌 부분에 대한 여러 의견과 관점들에 대해 gemini 2.5 pro 에게 요청한 연구 결과입니다.

Go 패키지 구조 컨벤션: Standard Go Project Layout

Tue, 26 Aug 2025 19:34:33 +0900

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

이 글은 Gemini 2.5 Pro 모델이 제 Go package convention 에 대한 질문에 답변한 내용입니다.

Go 커뮤니티에서 널리 통용되는 표준 프로젝트 레이아웃(golang-standards/project-layout)을 기반으로 각 디렉토리의 역할과 베스트 프랙티스를 자세히 설명해 드리겠습니다.

📦 `pkg` 디렉토리: 공개 라이브러리 (Public Library)

pkg 디렉토리에는 외부 프로젝트에서 가져다 쓸 수 있는(importable) 공개 라이브러리 성격의 코드를 위치시킵니다.

TotT: 변경 감지 테스트는 악몽입니다

Thu, 21 Aug 2025 15:09:05 +0900

원문: https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html (Translated by Google Gemini)

당신은 방금 코드의 동작을 수정하지 않고 리팩토링을 마쳤습니다. 그리고 커밋하기 전에 테스트를 실행했는데… 수많은 단위 테스트가 실패합니다. 실패한 테스트들을 고치면서, 당신은 여러 테스트에 동일한 변환 작업을 기계적으로 적용하며 시간을 낭비하고 있다는 느낌을 받습니다. 아마도 당신은 어떤 메서드에 파라미터를 하나 추가했고, 이제 테스트 코드에 있는 100개의 해당 메서드 호출부에 빈 문자열을 전달하도록 업데이트해야 하는 상황일 겁니다.

테스트를 기계적으로 작성한다는 것은 어떤 모습일까요? 여기 터무니없지만 명확한 예시가 있습니다:

TotT: 구현 세부사항보다 Public API를 테스트하세요

Wed, 20 Aug 2025 16:29:38 +0900

원문: https://testing.googleblog.com/2015/01/testing-on-toilet-prefer-testing-public.html (Translated by Google Gemini)

아래 클래스는 테스트가 필요할까요?

class UserInfoValidator {
 public void validate(UserInfo info) {
 if (info.getDateOfBirth().isInFuture()) {
 throw new ValidationException();
 }
 }
}

이 클래스의 메서드에는 로직이 포함되어 있으니 테스트하는 것이 좋을 수 있습니다. 하지만 이 클래스를 사용하는 유일한 코드가 아래와 같다면 어떨까요?

public class UserInfoService {
 private UserInfoValidator validator;
 public void save(UserInfo info) {
 validator.validate(info); // 값이 유효하지 않으면 예외를 던짐
 writeToDatabase(info);
 }
}

답은 다음과 같습니다: 아마도 UserInfoValidator는 테스트가 필요 없을 것입니다. 왜냐하면 모든 경로를 UserInfoService를 통해 테스트할 수 있기 때문입니다. 여기서 핵심적인 구분은 **이 클래스가 Public API가 아니라 구현 세부사항(implementation detail)**이라는 점입니다.

Go 언어의 풍부한 표준 라이브러리 (Batteries Included)

Tue, 19 Aug 2025 12:55:41 +0900

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

(이 글은 Gemini 2.5 Pro 모델에 의해 작성되었으며, 커버하고 있는 세부 항목들과 글의 톤/매너에 대한 요구사항들은 제가 정리해서 Gemini 에 요청했습니다. 내용에 잘못된 부분이 있을 수 있는데, 그런 경우 잘못된 정보에 대한 댓글을 남겨주시면 감사하겠습니다.)

Go 창시자들의 철학: 실용성과 안정성

Go 언어의 설계 철학은 구글의 대규모 프로덕션 환경에서 마주친 문제들을 해결하는 데서 출발했습니다. 언어의 창시자들인 로버트 그리즈머(Robert Griesemer), 롭 파이크(Rob Pike), 켄 톰슨(Ken Thompson) 은 복잡한 외부 의존성 없이도 당장 현장에서 필요한 대부분의 기능을 수행할 수 있는 언어를 원했습니다.

Go 의 동시성 (concurrency) 더 들여다보기

Mon, 11 Aug 2025 13:39:08 +0900

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

이 글에서는 Go의 동시성 모델이 어떠한 철학 위에서 탄생했는지 살펴보고, 다른 주류 언어들과의 접근 방식을 비교 분석합니다. 이를 통해 Go의 동시성이 갖는 장점과 현실적인 트레이드오프를 가감 없이 설명하고자 합니다.

TotT: 서술적인 테스트 이름 작성하기

Mon, 11 Aug 2025 12:05:33 +0900

원문: https://testing.googleblog.com/2014/10/testing-on-toilet-writing-descriptive.html (Translated by Google Gemini)

여러분은 테스트 이름을 어떻게 짓나요? 아래 코드 샘플을 한번 보세요. 이 테스트가 무엇을 하는지, 어떤 동작을 검증하는지 즉시 파악할 수 있나요?

public void testLogin() {
 // ...
}

이 테스트는 사용자가 성공적으로 로그인하는 시나리오를 테스트할 수도 있고, 잘못된 비밀번호를 입력했을 때의 시나리오를 테스트할 수도 있습니다. 테스트가 무엇을 하는지 이해하려면 테스트의 본문을 읽어야만 합니다. 이제 아래의 다른 테스트 이름을 보세요.

isUserLockedOut_lockOutUserAfterThreeInvalidLoginAttempts

이제 여러분은 테스트 본문을 읽지 않고도, 단지 테스트 이름만 읽는 것만으로 어떤 동작이 테스트되고 있는지 이해할 수 있어야 합니다.

Go 의 단순함(simplicity) 더 들여다보기

Thu, 07 Aug 2025 08:08:20 +0900

Go 언어의 철학을 관통하는 가장 중요한 단어는 바로 ‘단순함(Simplicity)’ 입니다. 이는 단순히 기능이 적다는 의미가 아니라, 복잡한 문제를 명료하고 예측 가능하게 해결하기 위한 의도적인 설계 철학입니다. Go의 창시자 중 한 명인 롭 파이크(Rob Pike)는 “단순함은 복잡하다(Simplicity is Complicated)“고 말했습니다. 최고의 단순함을 성취하기 위해 수많은 고민과 트레이드오프가 있었음을 암시하는 말이죠.

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

책 소개: VIBE CODING by Gene Kim and Steve Yegge

Thu, 07 Aug 2025 07:44:08 +0900

이 책의 존재를 알려준 r@rsl.kr 에게 감사를 표합니다.

이 책의 공개된 일부 내용은 https://go.itrevolution.net/e/Xys/U3oak/7Qm/R2mkNon98 에서 다운로드할 수 있습니다.
이 글은 제가 pdf 원문을 읽기 전 맥락을 먼저 갖기 위해 Gemini 에 번역/요약을 요청한 결과입니다.

책 소개: “VIBE CODING” - 무엇을 다루는가?

이 책은 “바이브 코딩(Vibe Coding)” 이라는 새로운 소프트웨어 개발 패러다임을 중심으로, 생성형 AI(GenAI), 챗(Chat), 에이전트(Agent)를 활용하여 실제 상용 수준의 소프트웨어를 구축하는 방법을 다룹니다. 저자들은 바이브 코딩이 단순히 코드를 빨리 짜는 기술을 넘어, 소프트웨어를 누가, 어떤 속도로, 얼마나 큰 야망을 가지고 만들 수 있는지에 대한 근본적인 정의를 바꾸고 있다고 주장합니다.

번역글: 형편없는 바이브 코더의 9가지 습관

Wed, 06 Aug 2025 15:28:31 +0900

원문: https://www.infoworld.com/article/4029093/9-habits-of-the-highly-ineffective-vibe-coder.html (Translated by Google Gemini)

바이브 코딩이 정말 그렇게 쉽다고요? AI의 현실 세계적 등가물인 집사를 생각해 보세요. 새로운 집사에게 아침 식사를 제공하거나 완벽한 마티니를 만드는 방법과 같은 기술을 가르치는 전문 학교가 있습니다. 하지만 이 학교들이 부자들에게 집사와 잘 지내는 방법을 가르치는 병행 과정도 있다는 것을 알고 계셨나요? 맞습니다. 부자들은 찻잔을 올바르게 잡는 방법을 배워서 집사가 우아하게 차를 채울 수 있도록 합니다. 심지어 어떤 종류의 요청이 적절하고 어떤 것이 그렇지 않은지도 배웁니다. 이것은 2분짜리 틱톡 비디오에서는 가르칠 수 없는 종류의 일입니다.

번역글: 증강 코딩: 바이브를 넘어

Wed, 06 Aug 2025 09:22:00 +0900

원문: https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes (Translated by Google Gemini)

이 글의 존재를 알려준 r@rsl.kr 에게 감사를 표합니다.

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

무엇이 당신을 B+ 트리를 먼저 구현하게 만들었나요?

증강 코딩의 놀라운 힘을 깨닫기 시작했을 때, 저는 과거에 기술적으로 접근하기 어려웠던 프로젝트들을 떠올리기 시작했습니다. 그중 하나는 특수 목적 데이터베이스였습니다. 지금 그 데이터베이스 프로젝트를 구현하면서 B+ 트리 데이터 구조를 충분히 이해하지 못했다는 것을 깨달았고 그래서 목표를 바꿨습니다.

AI 코딩 시대의 그림자: LLM 의존이 개발자에게 미치는 잠재적 위험 5가지

Tue, 05 Aug 2025 16:12:15 +0900

vibe-coding, agent-coding 이라는 말이 어색하지 않은 시대입니다. Claude, Gemini, GitHub Copilot과 같은 LLM(거대 언어 모델) 기반 코딩 도구들은 이제 단순히 코드 스니펫을 자동 완성해주는 수준을 넘어, 우리의 생각을 논리적으로 설명하면 프로젝트 전체의 구조를 짜고 방대한 양의 코드를 순식간에 만들어냅니다. 생산성의 혁신이라 부를 만한 이 변화는 분명 경이롭습니다.

하지만 이 강력한 도구에 과도하게 의존하기 시작하면서, 우리는 이전에 겪어보지 못한 새로운 종류의 문제들에 직면하고 있습니다. 밝은 빛이 강할수록 그림자도 짙어지는 법입니다. 지난 주말 바이브코딩을 직접 경험해 보며 그런 그림자의 영역을 빠르게 체감할 수 있었습니다. 이 글에서는 LLM 기반 코딩에 대한 의존이 개발자 개인과 팀에 미칠 수 있는 5가지 잠재적 위험을 심도 있게 다뤄보고자 합니다.

책 소개: 소프트웨어 설계의 철학

Mon, 04 Aug 2025 18:13:51 +0900

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

아래 내용은 Gemini 의 연구 결과에 약간의 퇴고를 거친 것입니다.

서론: 복잡성과의 전쟁

존 오스터하우트의 저서 “소프트웨어 설계의 철학(A Philosophy of Software Design)“은 소프트웨어 개발의 가장 근본적인 한계가 성능이나 기능이 아니라, 우리가 만든 시스템을 우리 스스로 이해하는 능력에 있다는 주장으로 시작합니다.[1, 2] 이 책의 전체 철학은 단 하나의 적, 즉 복잡성(complexity) 에 맞서기 위한 일련의 전략들로 구성되어 있습니다.[3, 4, 5, 6]

TotT: 테스트에 로직을 넣지 마세요

Mon, 04 Aug 2025 09:20:41 +0900

원문: https://testing.googleblog.com/2014/07/testing-on-toilet-dont-put-logic-in.html (Translated by Google Gemini)

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

프로덕션 코드와 달리, 테스트에서는 유연성보다 단순성이 더 중요합니다. 대부분의 단위 테스트는 단일의, 알려진 입력이 단일의, 알려진 출력을 생성하는지 검증합니다. 테스트는 입력과 출력을 계산하는 대신 직접 명시함으로써 복잡성을 피할 수 있습니다. 그렇지 않으면 테스트 자체에 버그가 생기기 쉽습니다.

Go 는 왜 LLM 기반 Vibe-Coding에 적합한 언어인가?

Thu, 31 Jul 2025 11:55:18 +0900

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

(영문 글을 번역했던 블로그 대부분의 포스트와는 달리 이 글은 제가 초안을 작성하고, Gemini 의 도움을 받아 개선된 originality 가 있는 글입니다.)

1. 강력한 정적 타입 시스템과 컴파일 단계

Go는 정적 타입 언어이며 컴파일을 통해 실행 파일을 만듭니다. 이는 코드가 실행되기 전, 즉 컴파일 시점에 타입 불일치, 함수 인자 오류, 존재하지 않는 변수 참조 등 수많은 오류를 미리 잡아낼 수 있음을 의미합니다.

번역글: Gemini CLI: 소개 및 그 진정한 가치

Wed, 30 Jul 2025 09:08:43 +0900

원문: https://medium.com/@terrycho/gemini-cli-an-introduction-and-its-real-value-15bd070fb011 (translated by Google Gemini)

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

무료 서비스 발표가 상당한 인기를 얻었지만, Gemini CLI는 전체 소프트웨어 개발 수명 주기(SDLC)를 아우르는 오케스트레이터로서 새로운 입지를 확립했습니다. 이는 소프트웨어 개발 전체를 포괄하려는 야심 찬 계획을 엿볼 수 있게 합니다. 이 글에서는 Gemini CLI가 왜 그렇게 인기 있는지, 그 특징과 차별점, 숨겨진 가치, 그리고 미래 개발 가능성에 대해 논의할 것입니다.

TotT: 위험 중심 테스트 (Risk-Driven Test)

Tue, 29 Jul 2025 10:35:40 +0900

원문: https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html (Translated by Google Gemini)

우리는 모두 코드를 작성할 때 테스트를 작성하도록 길들여져 있습니다 : 단위, 기능, UI 등 모든 것을 말이죠. 우리는 결국 전문가입니다. 우리 중 많은 사람들은 작은 테스트가 작업을 빠르게 진행하게 하고, 더 큰 테스트가 안전과 마무리에 영감을 주는 것을 좋아합니다. 아니면 단순히 검토 중에 비난을 예상할 수도 있습니다. 우리는 이러한 테스트에 너무 익숙해져서 왜 테스트를 작성하는지 더 이상 질문하지 않는 경우가 많습니다. 이것은 낭비적이고 위험할 수 있습니다.

TotT: 효과적인 테스트

Mon, 28 Jul 2025 10:24:47 +0900

원문: https://testing.googleblog.com/2014/05/testing-on-toilet-effective-testing.html (Translated by Google Gemini)

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

충실도 (Fidelity)

테스트 대상 코드가 손상되면 테스트는 실패합니다. 고충실도 테스트는 테스트 대상 코드의 결함에 매우 민감하여 버그가 코드에 침투하는 것을 방지하는 데 도움이 됩니다.

테스트가 코드의 모든 경로를 다루고 예상 상태에 대한 모든 관련 assertions 을 포함하는지 확인하여 충실도를 극대화하십시오.

TotT: 메서드가 아닌 동작을 테스트하라

Fri, 25 Jul 2025 09:17:03 +0900

원문: https://testing.googleblog.com/2014/04/testing-on-toilet-test-behaviors-not.html (Translated by Google Gemini)

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

전체 메서드를 확인하는 나쁜 테스트를 살펴보겠습니다.

@Test
public void testProcessTransaction() {
 User user = newUserWithBalance(LOW_BALANCE_THRESHOLD.plus(dollars(2)));
 transactionProcessor.processTransaction(
 user,
 new Transaction("Pile of Beanie Babies", dollars(3)));
 assertContains("You bought a Pile of Beanie Babies", ui.getText());
 assertEquals(1, user.getEmails().size());
 assertEquals("Your balance is low", user.getEmails().get(0).getSubject());
}

구매한 품목의 이름을 표시하고 잔액이 부족하다는 이메일을 보내는 것은 두 가지 별개의 동작이지만, 이 테스트는 동일한 메서드에 의해 트리거된다는 이유만으로 이 두 동작을 함께 살펴봅니다. 이러한 테스트는 추가 동작이 계속 추가됨에 따라 시간이 지남에 따라 매우 커지고 유지 관리가 어려워지는 경우가 많습니다. 결국에는 어떤 입력 부분이 어떤 단정(assertion)에 대한 책임이 있는지 파악하기가 매우 어려워질 것입니다. 테스트 이름이 메서드 이름을 직접적으로 반영한다는 사실 자체가 나쁜 징조입니다.

TotT: 좋은 테스트란 무엇인가?

Thu, 24 Jul 2025 10:02:23 +0900

원문: https://testing.googleblog.com/2014/03/testing-on-toilet-what-makes-good-test.html (Translated by Google Gemini)

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

좋은 테스트의 한 가지 속성은 명확성입니다. 명확성이란 테스트가 사람들에게 읽기 쉬운 문서 역할을 해야 하며, 테스트 중인 코드를 해당 public API 측면에서 설명해야 함을 의미합니다. 테스트는 구현 세부 사항을 직접 참조해서는 안 됩니다. 클래스의 테스트 이름은 클래스가 하는 모든 것을 말해야 하며, 테스트 자체는 클래스 사용 방법에 대한 예시가 되어야 합니다.

번역글: 원하는 기술을 갖춘 사람을 고용하라

Wed, 23 Jul 2025 07:42:17 +0900

원문: Pragmatic Programmers Newsletter (Translated by Google Gemini)

제인은 12번째 면접에 나타난다. 면접관은 그녀에게 마커를 건네고 화이트보드를 가리킨다. “연결되고 가중치가 있으며 무방향 그래프의 최소 신장 트리의 가중치를 계산하는 코드를 작성해 보세요.” 제인은 한숨을 쉬었다. 이달 들어 벌써 세 번째였다. 그녀는 작업을 시작했다.

내 생각에, 그녀는 아무리 답변 연습을 했더라도 그 직업을 가져서는 안 된다.

나에게 좋은 지원자라면 펜을 내려놓고 이렇게 물었을 것이다. “이것에 대한 맥락을 알려주시겠어요? 왜냐하면 프로그래머가 이런 종류의 문제를 처리하기 위해 AI(또는 라이브러리)를 사용하기를 원하실 테니까요. 저는 귀사의 AI가 할 수 없는 일을 할 수 있게 해주는 직업을 찾고 있었습니다.”

TotT: 구현이 아닌 동작을 테스트하세요

Tue, 22 Jul 2025 16:50:17 +0900

원문: https://testing.googleblog.com/2013/08/testing-on-toilet-test-behavior-not.html (Translated by Google Gemini)

여러분의 신뢰할 수 있는 Calculator 클래스는 많은 행복한 사용자를 보유한 가장 인기 있는 오픈소스 프로젝트 중 하나입니다:

public class Calculator {
 public int add(int a, int b) {
 return a + b; 
 }
}

또한 제대로 작동하는지 확인하는 테스트도 있습니다:

public void testAdd() {
 assertEquals(3, calculator.add(2, 1));
 assertEquals(2, calculator.add(2, 0));
 assertEquals(1, calculator.add(2, -1));
}

그러나 새로운 멋진 라이브러리는 덧셈 연산자 대신 사용하면 코드에서 몇 배의 속도 향상을 약속합니다. 여러분은 이 라이브러리를 사용하기 위해 들뜬 마음으로 코드를 변경합니다:

TotT: 상태 테스트 vs. 상호작용 테스트

Tue, 22 Jul 2025 13:11:07 +0900

원문: https://testing.googleblog.com/2013/03/testing-on-toilet-testing-state-vs.html (Translated by Google Gemini)

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

상태 테스트는 테스트 중인 코드가 올바른 결과를 반환하는지 확인하는 것을 의미합니다.

public void testSortNumbers() {
 NumberSorter numberSorter = new NumberSorter(quicksort, bubbleSort);
 // 반환된 목록이 정렬되었는지 확인합니다. 어떤 정렬 알고리즘이 사용되었는지는 중요하지 않으며,
 // 올바른 결과가 반환되기만 하면 됩니다.
 assertEquals(
 new ArrayList(1, 2, 3),
 numberSorter.sortNumbers(new ArrayList(3, 1, 2)));
}

상호작용 테스트는 테스트 중인 코드가 특정 메서드를 올바르게 호출하는지 확인하는 것을 의미합니다.

TotT: GUI 테스팅의 MVP 되기

Tue, 22 Jul 2025 10:49:31 +0900

원문: https://testing.googleblog.com/2009/02/with-all-sport-drug-scandals-of-late.html (Translated by Google Gemini)

최근의 모든 스포츠 약물 스캔들로 인해 요즘 좋은 롤 모델을 찾기가 어렵습니다. 하지만 롤 모델이 도메인 모델(비즈니스 엔티티의 객체 모델)이라면 MVP가 되기 위해 속임수를 쓸 필요가 없습니다. Model-View-Presenter를 사용하세요!

MVP는 MVC(Model-View-Controller)와 매우 유사합니다.

MVC에서는 아래 다이어그램과 같이 프레젠테이션 로직이 Controller와 View에 의해 공유됩니다. View는 일반적으로 가시적인 GUI 프레임워크 구성 요소에서 직접 파생되며, 모델을 관찰하고 사용자에게 시각적으로 보여줍니다. Controller는 사용자 이벤트를 모델 변경으로 변환하는 방법을 결정하는 역할을 합니다. MVP에서는 프레젠테이션 로직이 Presenter라고도 알려진 Supervising Controller에 의해 전적으로 처리됩니다.

TotT: 인터페이스 테스트하기

Mon, 21 Jul 2025 10:01:35 +0900

원문: https://testing.googleblog.com/2008/07/tott-testing-against-interfaces.html (Translated by Google Gemini)

부족함에 대한 지속적인 느낌을 억누르기 위해, 당신은 공학 분야의 진정한 통과 의례인 자신만의 행성 파괴 광선총을 만드는 데 시간을 들였습니다. 축하합니다. 그리고 당신은 매우 자랑스러워했지만, 그 다음 주말에 이워크¹ 해설이 포함된 한정판 스타워즈 3부작을 구매하여 데스스타²가 알데라안³을 파괴하는 것을 보고 잘못된 결정을 내렸다는 것을 깨달았습니다. 당신의 행성 파괴 광선총은 파란색 레이저를 가지고 있지만, 녹색 레이저가 훨씬 더 멋있어 보입니다. 하지만 라디오셱⁴에 가서 기존의 파괴 광선총에 끼울 수 있는 녹색 레이저를 사는 것은 간단한 문제가 아닙니다. 녹색 레이저를 가지려면 처음부터 다른 행성 파괴 광선총을 만들어야 할 것입니다. 두 개의 파괴 광선총을 소유하는 것이 하나보다 이웃들의 질투심을 더 자극할 것이므로 당신에게는 괜찮습니다.

TotT: "Static Cling" 퇴치하기

Thu, 17 Jul 2025 17:03:43 +0900

원문: https://testing.googleblog.com/2008/06/defeat-static-cling.html (Translated by Google Gemini)

당신은 페어 프로그래밍을 하고 있고, 많은 뛰어난 사람들이 그렇듯이 소리 내어 말하고 있습니다. “목을 만들고, 주입하고, 테스트를 다시 실행할 거야. 통과해야 하는데… 젠장!” 당신의 파트너는 예외 "ConnectionFactory not initialized"를 발견합니다. “뭐?” 그녀는 말합니다. “뭔가가 데이터베이스를 사용하고 있어? 젠장, 이건 작은 테스트여야 했는데.”

검사해보니 당신의 클래스가 다른 클래스의 정적 메서드를 호출하고 있다는 것을 발견했습니다. Static Cling¹이 발생한 것입니다! 만약 정적 메서드에 의존하는 코드를 생성하는 데이터 지속성 레이어를 (잘못) 사용하고, 주의를 기울이지 않았다면, 당신의 코드는 다음과 같을 수 있습니다.

TotT: 의지할 수 있는 친구들

Wed, 16 Jul 2025 10:47:04 +0900

원문: https://testing.googleblog.com/2008/06/tott-friends-you-can-depend-on.html (Translated by Google Gemini)

테스트 환경에서 사용하기 너무 어렵거나 느린 것에 의존하는 코드를 테스트하고 싶을 때는, 의존성 대신 테스트 더블을 사용하세요. 더미(Dummy)는 API를 만족시키기 위해 가짜 입력 값을 전달합니다.

Item item = new Item(ITEM_NAME);
ShoppingCart cart = new ShoppingCart();
cart.add(item, QUANTITY);
assertEquals(QUANTITY, cart.getItem(ITEM_NAME));

스텁(Stub) 은 실제 객체를 오버라이드하고 하드코딩된 값을 반환합니다. 스텁만을 사용한 테스트는 상태 기반 테스트입니다. 시스템을 실행한 다음 시스템이 예상된 상태인지 확인합니다.

ItemPricer pricer = new ItemPricer() {
 public BigDecimal getPrice(String name){ return PRICE; }
};
ShoppingCart cart = new ShoppingCart(pricer);
cart.add(dummyItem, QUANTITY);
assertEquals(QUANTITY*PRICE, cart.getCost(ITEM_NAME));

목(Mock) 은 값을 반환할 수 있지만, 메서드가 호출되는 방식에도 신경을 씁니다. (“엄격한 목(strict mocks)” 은 메서드 호출 순서에 신경을 쓰는 반면, “유연한 목(lenient mocks)” 은 그렇지 않습니다.) 목을 사용한 테스트는 상호작용 기반 테스트입니다. 목에 기대값을 설정하고, 목은 실행될 때 기대값을 검증합니다. 이 예시는 JMock을 사용하여 목을 생성합니다(EasyMock, Mockito 도 유사합니다):

TotT: 싱글턴을 피하기 위한 의존성 주입 사용하기

Tue, 15 Jul 2025 14:06:34 +0900

원문: https://testing.googleblog.com/2008/05/tott-using-dependancy-injection-to.html (Translated by Google Gemini)

싱글턴을 사용하는 코드를 테스트하기는 어렵습니다. 일반적으로 테스트하려는 코드는 싱글턴 인스턴스와 강력하게 결합되어 있습니다. 싱글턴 객체가 종종 정적 생성자나 정적 메서드에서 생성되기 때문에 싱글턴 객체의 생성을 제어할 수 없습니다. 결과적으로 싱글턴 인스턴스의 동작을 시뮬레이션할 수도 없습니다.

싱글턴 클래스의 구현 변경이 불가능하지만, 싱글턴 클라이언트는 변경이 가능하다면 간단한 리팩터링으로 테스트를 더 쉽게 만들 수 있습니다. 싱글턴 인스턴스로 Server를 사용하는 메서드가 있다고 가정해 봅시다.

public class Client {
 public int process(Params params) {
 Server server = Server.getInstance();
 Data data = server.retrieveData(params);
 ...
 }
}

Client를 리팩터링하여 의존성 주입을 사용하고 싱글턴 패턴의 사용을 완전히 피할 수 있습니다. 어떤 기능도 잃지 않았고, Server의 싱글턴 인스턴스만 존재해야 한다는 요구 사항도 잃지 않았습니다. 유일한 차이점은 Server 인스턴스를 정적 getInstance 메서드에서 가져오는 대신, Client가 생성자에서 받는다는 것입니다. 클래스를 테스트하기 더 쉽게 만들었습니다!

TotT: 시간은 무작위

Mon, 14 Jul 2025 10:30:17 +0900

원문: https://testing.googleblog.com/2008/04/tott-time-is-random.html (Translated by Google Gemini)

메서드의 입력값을 명확하게 식별할 수 없을 때 어떻게 제대로 테스트할 수 있을까요? 다음 Java 메서드를 살펴보세요.

/** 현재 시간으로부터 다음 분의 시작을 나타내는 Date 객체를 반환합니다. */
public Date nextMinuteFromNow() {
 long nowAsMillis = System.currentTimeMillis();
 Date then = new Date(nowAsMillis + 60000);
 then.setSeconds(0);
 then.setMilliseconds(0);
 return then;
}

이 메서드를 효과적으로 테스트하는 데에는 두 가지 장벽이 있습니다.

코너 케이스¹를 테스트하기 쉽지 않습니다. 시스템 클럭이 입력 조건을 제공하는 데에 좌우됩니다.
nextMinuteFromNow() 가 반환될 때, 시간이 변경됩니다. 이는 테스트가 단언이 아니라 추측이 될 것이며, 재현하기 어려운 저빈도 실패를 생성할 수 있습니다… 불안정성입니다! 예를 들어 클래스 로딩 및 가비지 컬렉션 일시 중지가 이에 영향을 미칠 수 있습니다.

System.currentTimeMillis() 가 무작위 숫자 제공자처럼 보이기 시작하나요? 맞습니다! 현재 시간은 *비결정성 (non-determinism)*의 또 다른 원천입니다. nextMinuteFromNow() 의 결과는 입력으로부터 쉽게 결정될 수 없습니다. 다행히도 이것은 쉽게 해결할 수 있습니다. 현재 시간을 제어할 수 있는 입력 매개변수로 만드세요.

TotT: 너무 많은 테스트

Mon, 14 Jul 2025 10:20:26 +0900

원문: https://testing.googleblog.com/2008/02/in-movie-amadeus-austrian-emperor.html (Translated by Google Gemini)

영화 아마데우스에서 오스트리아 황제는 모차르트의 음악에 “음표가 너무 많다”고 비판합니다. 하나의 기능을 테스트하는 데 “너무 많은” 테스트는 몇 개일까요?

메서드 decide를 고려해 봅시다.

public void decide(int a, int b, int c, int d, int e, int f) {
 if (a > b || c > d || e > f) {
 DoOneThing();
 } else {
 DoAnother();
 } // 공간 제약 때문에 한 글자 변수 이름을 사용했습니다.
} // 더 나은 이름을 사용해야 합니다. 제가 하는 대로 하지 말고, 제가 시키는 대로 하세요. :-)

얼마나 많은 테스트를 작성할 수 있을까요? 각 변수에 대해 int 값의 전체 범위를 실행하려면 2^192개의 테스트가 필요할 것입니다. 이렇게 계속한다면 구골 개수의 테스트를 하게 될 것입니다! 너무 많은 테스트입니다.

TotT: 스트룹 효과

Fri, 11 Jul 2025 10:49:44 +0900

원문: https://testing.googleblog.com/2008/02/tott-stroop-effect.html (Translated by Google Gemini)

아래 두 행동을 얼마나 빨리 할 수 있나요?

…25개 단어를 모두 소리 내어 읽기: 빨강, 초록, 파랑, … (지금 시도해 보세요!)
…25가지 색깔을 모두 소리 내어 말하기: 초록, 노랑, 하양… (지금 시도해 보세요!)

두 번째 작업이 더 많은 시간과 노력을 필요로 했나요? 그렇다면, 여러분은 스트룹 효과를 경험하고 있는 것입니다. 스트룹 효과는 대략적으로 레이블(이 경우 단어)이 내용(색깔)과 같은 영역에 있고 의미가 충돌할 때, 레이블이 내용을 이해하는 능력에 방해가 된다는 것을 의미합니다.

TotT: 스텁이 단위 테스트 속도를 높여줍니다

Thu, 10 Jul 2025 16:01:59 +0900

원문: https://testing.googleblog.com/2007/04/tott-stubs-speed-up-your-unit-tests.html (Translated by Google Gemini)

Michael Feathers는 좋은 단위 테스트의 특징을 “빠르게 실행되고 문제 위치를 파악하는 데 도움이 된다"고 정의합니다. 코드에 데이터베이스 액세스, 다른 서버와의 통신, 시간 의존성 등이 있을 때는 이를 달성하기 어렵습니다.

모듈의 일부 종속성에 커스텀 객체를 대체하여 코드를 철저히 테스트하고, 커버리지를 높이며, 1초 이내에 실행할 수 있습니다. 데이터베이스 오류와 같은 드문 시나리오도 시뮬레이션하여 오류 처리 코드를 테스트할 수도 있습니다.

이러한 “커스텀 객체"를 지칭하는 다양한 용어가 사용됩니다. 용어를 명확히 하기 위해 Gerard Meszaros는 다음 정의를 제공합니다.

번역글: ExecutorService invokeAll 과 가상 스레드 사용하기

Thu, 10 Jul 2025 09:41:55 +0900

원문: https://davidvlijmincx.com/posts/loom/invoke-all-with-virtual-threads/ (Translated by Google Gemini)

서론

invokeAll 은 ExecutorService 의 메서드로, 여러 제출된 작업을 동시에 시작합니다. ExecutorService 는 스레드 풀에서 플랫폼 스레드를 사용하여 제출된 작업을 실행합니다. 이 비싸고 리소스 집약적인 플랫폼 스레드를 사용하는 대신, 가상 스레드를 사용하여 ExecutorService 에 제출된 작업을 실행할 수도 있습니다. 이 글에서는 invokeAll 메서드를 가상 스레드 (virtual threads), 구조화된 동시성 (structured concurrency) 및 플랫폼 스레드 (platform threads) 와 함께 구현하는 모든 방법을 다룰 것입니다.

가상 스레드를 사용한 `invokeAll`

우리가 살펴볼 첫 번째 예제는 가상 스레드 (virtual threads) 를 사용합니다. 각 작업에 대해 가상 스레드를 생성하는 Executor 를 생성하는 try-with-resources 문이 있습니다. 7행에서 invokeAll 메서드가 작업 목록과 함께 호출됩니다.

TotT: 화장실에서 테스팅 (Testing on the Toilet) 소개

Tue, 08 Jul 2025 10:31:22 +0900

원문: https://testing.googleblog.com/2007/01/introducing-testing-on-toilet.html (Translated by Google Gemini)

업데이트 - 2024년 12월: TotT 의 의미는 화장실에서 테스팅 (Testing on the Toilet) 에서 이제 *화장실에서 기술 (Tech on the Toilet)*로 변경되었습니다. 자세한 내용은 다음 게시물을 읽어보세요: 화장실에서 기술: 한 번의 화장실 휴식으로 소프트웨어 우수성 향상. 아래는 2007년의 원본 게시물입니다.

블로거 커멘트: 앞으로 TotT 시리즈를 시간이 날 때마다 하나씩 번역해서 포스팅할 예정입니다. (이미 먼저 포스팅된 글들도 있습니다.)

저희는 여러분이 더 많은 테스트를 작성하기를 바랍니다. 네, 바로 여러분입니다. 테스트는 코드를 리팩토링해야 할 때나 다른 개발자가 기능을 추가할 때 여러분을 보호하는 안전망이라는 말을 이미 들었을 것입니다. 심지어 테스트가 코드 디자인에 도움이 될 수 있다는 것도 알고 있을 것입니다.

번역글: Go의 동시성: 심층 분석

Mon, 07 Jul 2025 13:43:14 +0900

원문: https://medium.com/hprog99/concurrency-in-go-a-deep-dive-2abbb4838984 (Translated by Google Gemini)

서론

동시성이란 무엇인가?

동시성은 독립적인 활동들의 구성으로 느슨하게 정의될 수 있습니다. 반드시 병렬 실행을 필요로 하지는 않지만, 여러 태스크가 겹치는 시간 동안 진행되도록 허용합니다. 컴퓨팅의 맥락에서 동시 프로그래밍은 여러 태스크가 실행에서 인터리브(interleave - 여러 대상을 번갈아 가며 실행하거나 배치) 될 수 있도록 보장하며, 이는 특히 I/O 바운드 태스크나 수많은 이벤트를 동시에 처리해야 하는 애플리케이션(예: 웹 서버에서 여러 클라이언트 연결 처리)에서 중요합니다.

동시성 vs. 병렬성

비공식적인 대화에서 종종 혼용되지만, 동시성과 병렬성은 다른 개념입니다.

TotT: 더 나은 테스트를 위한 가짜(Fake) 사용하기

Mon, 07 Jul 2025 13:23:12 +0900

원문: https://testing.googleblog.com/2013/06/testing-on-toilet-fake-your-way-to.html (Translated by Google Gemini)

수년간 블로그를 운영한 후, 블로그 플랫폼의 API를 사용해보기로 결정했습니다. 이리저리 사용해보다가 문득 깨닫습니다: 원격 블로그 서버와 통신하지 않고도 코드가 작동하는지 어떻게 알 수 있을까요?

public void deletePostsWithTag(Tag tag) {
 for (Post post : blogService.getAllPosts()) {
 if (post.getTags().contains(tag)) { blogService.deletePost(post.getId()); }
 }
}

가짜(Fakes)가 해결책입니다! 가짜는 실제 구현체처럼 작동하지만, 프로덕션 환경에 적합하지 않은 API의 가벼운 구현체입니다. 블로그 서비스의 경우, 중요한 것은 게시물을 가져오고 삭제하는 기능뿐입니다. 실제 블로그 서비스는 데이터베이스와 여러 프런트엔드 서버가 필요하겠지만, 코드를 테스트하는 데는 그런 것이 필요 없습니다. 필요한 것은 블로그 서비스 API의 어떤 구현체든 상관없습니다. 간단한 인메모리 구현체로 이를 달성할 수 있습니다.

번역글: 헤르메틱 서버 (Hermetic Servers)

Mon, 07 Jul 2025 13:08:09 +0900

원문: https://testing.googleblog.com/2012/10/hermetic-servers.html (Translated by Google Gemini)

“종단 간” 테스트

Google 테스트 세계에서 종단 간 테스트는 사용자 요청부터 응답까지 전체 서버 스택을 실행하는 테스트입니다. 다음은 종단 간 테스트가 검증할 시스템 테스트 대상(SUT)의 간략한 모습입니다. SUT의 프런트엔드 서버가 특정 사용자 요청에 필요하지 않은 세 번째 백엔드에 연결된다는 점에 유의하십시오.

이러한 시스템에 대한 빠르고 신뢰할 수 있는 종단 간 테스트를 작성하는 데 있어 한 가지 과제는 네트워크 액세스를 피하는 것입니다. 네트워크 액세스가 포함된 테스트는 로컬 리소스만 액세스하는 테스트보다 느리며, 외부 서버에 액세스하면 비결정성 또는 외부 서버의 가용성 부족으로 인해 불확실성이 발생할 수 있습니다.

TotT: 목(Mock)을 과도하게 사용하지 마세요

Mon, 07 Jul 2025 10:53:23 +0900

원문: https://testing.googleblog.com/2013/05/testing-on-toilet-dont-overuse-mocks.html (Translated by Google Gemini)

코드를 테스트할 때, 코드의 의존성을 목으로 처리하여 무시하는 것이 쉬워 보일 수 있습니다.

public void testCreditCardIsCharged() {
 paymentProcessor = new PaymentProcessor(mockCreditCardServer);
 when(mockCreditCardServer.isServerAvailable()).thenReturn(true);
 when(mockCreditCardServer.beginTransaction()).thenReturn(mockTransactionManager);
 when(mockTransactionManager.getTransaction()).thenReturn(transaction);
 when(mockCreditCardServer.pay(transaction, creditCard, 500)).thenReturn(mockPayment);
 when(mockPayment.isOverMaxBalance()).thenReturn(false);
 paymentProcessor.processPayment(creditCard, Money.dollars(500));
 verify(mockCreditCardServer).pay(transaction, creditCard, 500);
}

하지만 목을 사용하지 않으면 때로는 더 간단하고 유용한 테스트를 만들 수 있습니다.

public void testCreditCardIsCharged() {
 paymentProcessor = new PaymentProcessor(creditCardServer);
 paymentProcessor.processPayment(creditCard, Money.dollars(500));
 assertEquals(500, creditCardServer.getMostRecentCharge(creditCard));
}

목을 과도하게 사용하면 몇 가지 문제가 발생할 수 있습니다.

번역글: Golang 공동 창시자 Rob Pike: Go가 잘한 것과 잘못한 것

Wed, 02 Jul 2025 10:28:40 +0900

원문: https://thenewstack.io/golang-co-creator-rob-pike-what-go-got-right-and-wrong/ (Translated by Google Gemini)

GopherCon AU 참석자들은 Go의 사양이 처음 작성된 도시인 호주 시드니에서 특별한 대접을 받았습니다. Go의 공동 설계자 중 한 명인 Rob Pike는 Go 프로그래밍 언어가 출시된 지 14주년이 되는 날을 기념하며 “무엇을 제대로 했고, 무엇을 잘못했는지” 돌아보는 강연을 했습니다.

Pike는 2009년 11월 10일 웹사이트가 처음 공개되던 순간을 기억하며 “세상이 우리가 무엇을 해왔는지 알게 되었다”고 말했습니다.

“14년이 지난 지금, 돌아볼 것이 많습니다.”라고 Pike는 청중에게 말하며 “더 큰 교훈들”을 탐구하겠다고 약속했습니다.

번역글: 분산 시스템 개발자를 위한 기도

Tue, 01 Jul 2025 13:55:13 +0900

원문: https://philipotoole.com/a-prayer-for-distributed-systems-developers/ (Translated by Google Gemini)

16년이 넘는 시간 동안 저는 전체 스택을 오르내리며 소프트웨어를 작성했습니다. 제 경력 초기에 저는 특수 임베디드 장치를 위한 부트 ROM 소프트웨어를 작성했습니다. 이런 종류의 프로그래밍은 컴퓨터가 정말로 어떻게 작동하는지에 대해 많은 것을 가르쳐주었습니다.

대부분의 프로그래머는 컴퓨터가 어떻게 작동하는지 안다고 생각하지만, 그들은 단지 소프트웨어가 어떻게 작동하는지 알 뿐입니다. 이 프로그래머들은 인터럽트 서비스 루틴이 어떻게 호출되는지, 컴퓨터가 두 숫자를 어떻게 더하는지, 마이크로프로세서가 다음 명령어를 RAM에 어떻게 로드하는지 정말로 알지 못합니다. 하지만 괜찮습니다. 그럴 필요도 없고, 관심도 없습니다.

번역글: Java 23: 성능 및 생산성 향상 (2024년 9월)

Wed, 25 Jun 2025 15:27:23 +0900

원문: https://www.hungrycoders.com/blog/java-9-23-unleashed-the-developers-cheat-sheet-to-modern-java (Translated by Google Gemini)

주요 기능

패턴, instanceof, switch에서의 Primitive Types (미리보기): 패턴 매칭을 기본 타입으로 확장하여 상용구 코드(boilerplate code)를 줄입니다.
Scoped Values (세 번째 미리보기): 제한된 수명을 가진 변수를 도입하여 메모리 관리를 개선합니다.
Structured Concurrency (세 번째 미리보기): 구조화된 API를 통해 스레드 관리를 강화하여 동시성 처리를 단순화합니다.
Markdown Documentation Comments: Javadoc에 Markdown 지원을 추가하여 문서의 가독성을 향상시킵니다.
ZGC를 기본 가비지 컬렉터로: 세대별 Z Garbage Collector (ZGC)가 기본값으로 설정되어 성능과 응답성을 향상시킵니다.

개요 요약

Java 23은 성능 및 개발자 생산성 향상 추세를 이어갑니다. 기본 타입을 지원하는 패턴 매칭을 개선하고, 더 안전한 메모리 관리를 위해 Scoped Values를 도입하며, 구조화된 API를 통해 동시성을 단순화합니다. Markdown 문서화는 개발자 경험을 개선하고, ZGC가 기본 컬렉터가 되어 더 나은 성능과 낮은 지연 시간을 보장합니다.

번역글: AI를 이용한 게임 디컴파일 개발 여정

Wed, 25 Jun 2025 14:35:23 +0900

원문: https://macabeus.medium.com/game-decompilation-using-ai-4d47b65f8852 (Translated by Google Gemini)

안녕하세요, 저는 Macabeus입니다. 이 글에서는 제가 오래된 게임을 디컴파일하기 위해 AI를 사용한 개발 여정을 공유하고, 이 재미있는 분야에서의 개인적인 연구를 탐색해 보려고 합니다!

게임 디컴파일이란?

간단히 말해, 디컴파일은 저수준 코드를 고수준 코드로 변환하는 과정입니다. 예를 들어, 어셈블리에서 C로 변환하는 것입니다.

IDA Pro나 Ghidra와 같은 유명한 리버스 엔지니어링 도구들을 통해 이를 알고 계실 수도 있습니다. 하지만 이 글에서 제가 디컴파일이라고 언급할 때는, 일치하는 디컴파일(matching decompilation) 에 대해 이야기하는 것입니다. 이 더 구체적인 용어는 컴파일했을 때 대상 어셈블리와 정확히 일치하면서도, 인간이 읽을 수 있는(human-readable) 고수준 코드를 작성하고자 함을 의미합니다.

번역글: 지금 바로 사용할 수 있는 최고의 AI 코딩 도구

Tue, 24 Jun 2025 19:52:16 +0900

원문: https://spectrum.ieee.org/best-ai-coding-tools (Translated by Google Gemini)

AI 기반 소프트웨어 개발 도구는 빠르게 발전하고 있습니다. 향상된 자동 완성으로 시작했던 것이 애플리케이션을 작성하고, 문제를 디버깅하고, 전체 코드베이스를 관리할 수 있는(또는 적어도 시도할 수 있는) AI 에이전트로 확장되었습니다.

소프트웨어 개발 회사 Frescher Southern LTD의 설립자이자 수석 엔지니어인 Josh Knowles는 “이것은 놀라울 정도로 빨랐습니다. 우리는 지금 위상 변화와 같은 것을 겪고 있습니다.”라고 말합니다.

이러한 변화는 이 새로운 분야의 왕이 되기 위해 경쟁하는 AI 기반 코딩 도구들을 낳았습니다. 선도적인 도구 중 일부는 불과 몇 년 전에는 존재하지도 않던 스타트업에서 나왔습니다. 그러나 거대 기술 기업들도 가만히 있지 않습니다. 다른 최고의 옵션들은 Microsoft와 같은 기존 플레이어와 Anthropic과 같은 자금력 있는 AI 연구소에서 제공됩니다.

번역글: 현재 나의 LLM 코드 생성 워크플로우

Mon, 23 Jun 2025 17:33:07 +0900

원문: https://harper.blog/2025/02/16/my-llm-codegen-workflow-atm/ (translated by Google Gemini)

요약: 스펙을 브레인스토밍하고, 계획을 계획한 다음, LLM 코드 생성을 사용하여 실행합니다. 개별적인 루프. 그리고 마법

저는 LLM을 사용하여 아주 많은 소규모 제품을 만들어 왔습니다. 재미있고 유용했지만, 엄청난 시간을 낭비할 수 있는 함정들이 있습니다.

얼마 전 한 친구가 제가 LLM을 어떻게 사용하여 소프트웨어를 작성하는지 물었습니다. 저는 “이런. 시간이 얼마나 있으신데요!“라고 생각했고, 그래서 이 글을 쓰게 되었습니다.

(추신: AI를 싫어하는 분이라면 맨 끝으로 스크롤하세요)

저는 많은 개발자 친구들과 이 주제에 대해 이야기하는데, 우리 모두는 어느 방향으로든 약간의 변형을 가미한 비슷한 접근 방식을 가지고 있습니다. 여기 저의 워크플로우가 있습니다. 이것은 저 자신의 작업, 친구들과의 대화(Nikete, Kanno, Obra, Kris, Erik 고마워요), 그리고 여러 끔찍한 인터넷 나쁜 곳들에서 공유된 많은 모범 사례들을 바탕으로 만들어졌습니다.

Programming on philipjkim

Hugo 로 바둑판 도해 그리기 Part 2: 이미지 65장을 표기로 옮기기

들어가며

Hugo 로 바둑판 도해 그리기 Part 1: 왜 shortcode 였나

들어가며

렉시오 CPU 플레이어 만들기 Part 7: 코드 없이 보는 easy 봇과 hard 봇의 차이

이 글은 누구를 위한 것인가

렉시오 CPU 플레이어 만들기 Part 6: 봇이 약한지 어떻게 아는가

눈으로 한 판 돌려서는 못 보는 것

렉시오 CPU 플레이어 만들기 Part 5: 봇이 아무것도 하지 않는 이유

설계와 구현 사이

달무티 CPU 플레이어 만들기 Part 4: 만들어 보니 hard 봇이 더 약했다

설계안이 검증을 만나면

8비트의 벽을 넘은 게임들 Part 5: 제약이 사라진 시대에 남은 것

지금까지의 이야기

8비트의 벽을 넘은 게임들 Part 4: 메탈기어, 못 그리는 것을 안 그려도 되게 만들다

세 번째 길

8비트의 벽을 넘은 게임들 Part 3: 엘리트, 우주를 6바이트에 담다

저장하지 않으면 용량도 들지 않는다

8비트의 벽을 넘은 게임들 Part 2: 슈퍼 마리오브라더스, 레벨을 그리지 않고 서술하다

4,460바이트짜리 세계

8비트의 벽을 넘은 게임들 Part 1: 그 기계들은 무엇을 못 했는가

스크린샷 한 장보다 작은 게임

렉시오 CPU 플레이어 만들기 Part 4: 수 평가와 정산 기대값

재료에서 결정으로

렉시오 CPU 플레이어 만들기 Part 3: 손패 분해 플랜

좋은 손패는 센 손패가 아니다

렉시오 CPU 플레이어 만들기 Part 2: 60비트 카운팅과 확실승수 판정

hard 봇이 지켜야 할 세 가지

렉시오 CPU 플레이어 만들기 Part 1: 타일 하나를 정수 하나로

사촌 게임, 전혀 다른 봇

달무티 CPU 플레이어 만들기 Part 3: 수 평가와 전략적 패스

재료에서 결정으로

달무티 CPU 플레이어 만들기 Part 2: hard 봇의 정보 모델과 확실승수 판정

hard 봇이 지켜야 할 세 가지

달무티 CPU 플레이어 만들기 Part 1: 규칙 기반 easy 봇

왜 봇부터 만드는가

AI 허니문이 끝난 자리: 테크 인력 6,000명을 반으로 가른 것과, 개인이 바꿀 수 있는 것

번역글: Big Design Up Front — 여전히 나쁜 생각입니다

Marp: Markdown으로 발표 슬라이드를 만들고 Git으로 관리하기

Marp란 무엇인가

번역글: 어느 사랑 이야기

HTTP REST(JSON) vs. gRPC(Protocol Buffers): 언제 무엇을 쓸까

배우는 부분들로 이루어진 배우는 시스템 — Kent Beck × Jessica Kerr 대담 정리

번역글: 아웃소싱, AI, 그리고 작은 희망

2021년의 Go를 2026년의 Go로 Part 3: 동시성·런타임·운영 레시피

들어가며

레시피 1: 수동 취소·타임아웃 관리 대신 context 신규 API (1.21)

2021년의 Go를 2026년의 Go로 Part 2: 표준 라이브러리 레시피

들어가며

2021년의 Go를 2026년의 Go로 Part 1: 언어와 문법 레시피

들어가며: 5년 동안 Go에 무슨 일이 있었나

개발자를 위한 Discord 완전정복 Part 2: 공짜로 풀어준 대인배 기능들

개발자를 위한 Discord 완전정복 Part 1: 탄생, 성장, 그리고 결정적 순간들

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 2: Go + Templ + HTMX To-Do 앱으로 직접 만들어 보기

가상 프로젝트: gotodo

Agentic Coding 시대의 Repo 부트스트래핑 가이드 Part 1: AGENTS.md 와 spec 문서 지형도

들어가며: README 한 장으로 안 되는 시대

Superpowers 플러그인 가이드 Part 4: 명시 호출 vs 자동 트리거 — 실전 가이드와 한계

Superpowers 플러그인 가이드 Part 3: 품질 보증 스킬 — TDD, Systematic Debugging, Verification, Code Review

Superpowers 플러그인 가이드 Part 2: 핵심 워크플로우 — Brainstorming부터 Subagent-driven Development까지

Superpowers 플러그인 가이드 Part 1: 소개, 설치, 그리고 철학

들어가며

Agentic Coding 시대의 개발방법론 — 더 중요해진 5가지, 무용해진 5가지

들어가며: 사라진 것이 아니라 재배치되었다

2년 후 프로그래밍은 어떤 모습일까 — 아무도 모릅니다

“업계를 떠나야 할까요?”

번역글: AI와 함께 더 빨리 실패하기

크로스플랫폼 To-Do 앱 만들기 Part 4: UI 다듬기와 빌드/배포

시리즈 목차

Part 3 회고

크로스플랫폼 To-Do 앱 만들기 Part 3: 상태 관리와 로컬 데이터 저장

들어가며

1. setState의 한계

크로스플랫폼 To-Do 앱 만들기 Part 2: Flutter 기초와 UI 구현

들어가며

크로스플랫폼 To-Do 앱 만들기 Part 1: 프레임워크 선택과 개발 환경 설정

시리즈 소개

번역글: 공중누각 — 여전히 보람찬 일

AI 에이전트 시대의 C 언어 Part 2: AI는 C를 살리는가, 대체하는가

레시피 1: 수동 취소·타임아웃 관리 대신 `context` 신규 API (1.21)

가상 프로젝트: `gotodo`