sungjun👨🏻‍💻

software engineer 🚀

[June Kim @cjunekim]

이런 표현을 보게됐다. "글을 쓰지 않아도 지식이 쌓이고" Karpathy LLM Wiki를 쓰면 그렇게 할 수 있단다. 이걸 collector's fallacy라고 한다. 긁어 모아서 갖고 있는 거만으로 지식이 된다고 생각하는 버그이다. PKMS를 PIMS로 쓰는 사람들이 이런 착각에 잘 빠지더라.

[Cognac(꼬냑) @supernovajunn]

안드레 카파시가 GitHub에 파일 하나를 올렸다.

코드도 없다. 앱도 없다. 그냥 마크다운 문서 하나만 있는데. 이름은 llm-wiki.md. 올린 지 10시간 만에 별 1,757개, 포크 318개를 받았다.

이 뜻은 전 세계 개발자들이 그 파일 하나 보고 "바로 이거야"를 외쳤다는 뜻이다.

그동안 우리가 AI를 쓰는 방식이 사실 꽤 비효율적이었다는 것을 아는가?

지금 대부분의 사람들은 AI에게 파일을 던져주고 "이거 요약해줘", "이거 분석해줘"를 반복한다. 질문할 때마다 AI는 그 문서를 처음 읽는다. 어제 읽었던 논문, 지난달에 저장해둔 기사, 3년 전에 메모해둔 아이디어를 말이다.

AI는 그걸 기억하지 못한다. 매번 새로 읽고, 매번 새로 연결하고, 매번 새로 이해한다. 쌓이는 게 없다.

이걸 RAG 라고 부른다. 기술적으로는 아무 문제없다. 근데 생각해보면 이상하다. 당신이 매일 같은 책을 처음 읽는 사람한테 질문을 던지는 거랑 같다. 그 사람은 절대 전문가가 될 수 없다. 어제 읽은 걸 오늘 잊으니까.

카파시가 제안한 건 다르다. AI가 지식을 읽을 때마다 그냥 답을 뱉고 끝내는 게 아니라, 그걸 위키에 쌓아두는 것이다. 연결하고, 모순을 찾아 표시하고, 업데이트하고, 계속 더 풍부하게 만들어간다. 새 자료가 들어올수록 위키는 더 똑똑해진다. 쌓인다. 마치 이자의 복리처럼.

구조는 단순하다. 세 겹이다.

첫 번째 겹은 원본 자료들. 논문, 기사, 메모. AI는 이걸 읽기만 하고 절대 건드리지 않는다.

두 번째 겹은 위키. AI가 직접 쓰고 유지하는 마크다운 파일들. 요약 페이지, 개념 페이지, 연결 페이지. 당신이 읽고, AI가 쓴다.

세 번째 겹은 스키마. AI한테 "이 위키를 어떻게 관리해"라고 알려주는 설정 파일. 카파시는 이걸 AGENTS.md나 CLAUDE.md에 넣어두라고 한다.

카파시 본인은 왼쪽에 AI 에이전트, 오른쪽에 옵시디언을 열어두고 쓴다고 했다. AI가 위키를 수정하면 옵시디언에서 실시간으로 업데이트되는 걸 본다고. 그의 표현이 정확하다. "옵시디언은 IDE, AI는 프로그래머, 위키는 코드베이스다"

예를 들어, 책을 읽는 방식도 달라진다. 소설 한 권 읽으면서 챕터마다 AI한테 넣으면, 끝날 때쯤 등장인물 관계도, 복선 추적 페이지, 주제 연결 지도가 완성되어 있다. 톨킨 게이트웨이처럼 수천 명이 수년에 걸쳐 만든 팬 위키를 혼자, AI와 함께, 책 한 권 읽는 시간에 만들 수 있다.

근데 이 파일이 왜 이렇게 빠르게 퍼졌냐. 기술적으로 새로운 게 있어서가 아니다.

카파시가 이 파일을 "아이디어 파일"이라고 부른 게 핵심이다. 코드가 없다. 우리가 직접 설치할 게 없다. "이 아이디어를 당신 에이전트에게 그대로 복붙하면, 에이전트가 당신 상황에 맞춰 직접 구현해준다"는 것이다.

시대가 바뀌었다. 더 이상 앱을 공유하는 게 아니라 아이디어를 공유하는 방향으로 흐르는 것 같다. 받은 사람이 실행하는 게 아니라, 받은 사람의 에이전트가 실행한다.

이게 왜 충격인지 생각해보면 된다. 오픈소스 소프트웨어는 코드를 나눈다. 하지만 코드는 여전히 직접 설치하고, 설정하고, 유지해야 한다.

아이디어 파일은 다르다. 에이전트가 당신 환경, 당신 워크플로우, 당신 취향에 맞게 알아서 구현한다고 보면 될 것이다.

우리는 오래전부터 "정보가 너무 많아서 문제"라고 했다. 근데 사실 정보가 많은 게 문제가 아니었다. 정보가 연결되지 않는 게 문제였다.

LLM 위키는 그 연결을 AI한테 맡기는 거다. 당신이 할 건 좋은 자료 찾아오는 것, 그리고 좋은 질문 던지는 것. 나머지 연결, 요약, 교차참조, 모순 발견, 업데이트는 에이전트가 한다. 우리의 생각과 뇌는 더 중요한 일에 쓰인다.

지식을 쌓는다는 건 원래 그런 거였다. 연결되고, 업데이트되고, 깊어지는 것. 우리는 그냥 그걸 할 인내심이 없었을 뿐이다. 에이전트는 인내심이 무한하다.

[lucas @lucas_flatwhite]

🔖 매일 쓰는 Claude Code, 50+3가지 팁과 베스트 프랙티스
https://t.co/WI0SLw2kM4

PDF 만들면서 내용에 대한 검수와 추가 보완하면서 추가적인 팁 3가지를 더 추가했어요.

Claude Code를 쓰기 시작한 지 얼마 되지 않았든, 몇 달째 매일 쓰고 있든, 이 50가지 팁은 워크플로우를 한 단계 끌어올리는 데 도움이 될 거예요.

Anthropic 공식 문서, Claude Code를 만든 Boris Cherny의 조언, 커뮤니티 경험, 그리고 실제 일상 사용에서 얻은 노하우를 모았어요.

좋은건 나눠야죠..!

[정겨울 @__winterjung]

코드 리뷰를 어떻게 해야할까? 꼭 해야할까? 지속가능할까? 라는 생각이 드는 요즘. 소수의 영웅에게 리뷰를 의존하는 대신 코드보단 스펙과 의도, 맥락을 리뷰하자는 주장. 공감이 간다.
https://t.co/7AOohQtULF

[Move78 @move78th]

[앤트로픽 : 클로드 코드에서 제공하는 AI 아카데미]

- 가격 : 무료
- 수료증 : 나옴 (링크드인 게시 가능)
- 코스 : 총 13개
- 언어 : 국문 제공
- 안 할 이유 : 없음

Claude Code in Action - Practical walkthrough of using Claude Code to accelerate your development workflow https://t.co/X3QxymVqAz

[lucas @lucas_flatwhite]

📚 Claude Code Best Practice
> Claude Code를 제대로 쓰고 싶다면, 여기서 시작하세요
https://t.co/AGWIneaT7R

Claude Code 실전 가이드를 모은 커뮤니티 저장소!

Commands, Sub-Agents, Skills, Hooks, MCP 같은 구성 요소를 체계적으로 정리하고 있어요.

- Commands: "/명령어"로 워크플로우를 한 번에 호출해요.

- Sub-Agents: 이름, 색상, 권한, 모델까지 직접 커스텀한 전용 에이전트.

- Skills: 재사용 가능한 지식 단위로, 필요할 때만 온디맨드로 불러와요.

- Hooks: 에이전트 루프 밖에서 이벤트에 반응하는 스크립트.

- MCP Servers: 외부 툴, DB, API를 Claude와 연결해줘요.

가장 기본적이면서 중요한 아키텍처 패턴은 이거예요.

⚙️ Command → Agent → Skill

Command가 진입점이 되고, Agent가 미리 로드된 Skill을 들고 작업을 수행하는 구조예요.

↓

실전에서 바로 써먹을 수 있는 팁들도 정리되어 있어요. 굳굳!

1. https://t.co/KYRCeDDmmP는 150줄을 넘기지 않도록 유지!

2. 컨텍스트가 50%에 도달하면 /compact를 수동으로 실행해요. "agent dumb zone"을 예방할 수 있어요.

3. 모든 작업은 plan mode로 시작하는 걸 권장해요.

4. dangerously-skip-permissions 대신 와일드카드 권한 설정(Bash(npm run *))을 써요.

5. 소규모 태스크는 복잡한 워크플로우 없이 바닐라 Claude Code가 더 빠를 때도 많아요.

Claude Code를 만든 Boris Cherny를 비롯한 공식 팀의 팁도 꾸준히 큐레이션되고 있어서, 흐름을 따라가기에도 좋아요.

처음이라면 https://t.co/KYRCeDDmmP 설정, Sub-Agents, Skills 파트부터 살펴보시면 도움 많이 되실거예요.

[GeekNews @GeekNewsHada]

gogcli - 터미널에서 Google Workspace를 제어하는 고속 CLI

- Gmail, 캘린더, 드라이브, Docs, Sheets, 챗, 연락처, Tasks, Forms, Keep 등 구글 웍스페이스 전반을 터미널에서 제어하기 위해 개발된 에이전트 친화적 경량/고속 CLI 도구
- OpenClaw 제작자의 프로젝트…
https://t.co/5AvyWmpw6M

[아샬 (Ashal aka JOKER) @ahastudio]

코딩 에이전트가 2025년 12월을 기점으로 임계점을 넘었고, 프로그래밍 패러다임 자체가 종료됐다는 선언.

https://t.co/lghDGaRU28

[Dr Milan Milanović @milan_milanovic]

Kubernetes killed more startups than server crashes ever did

You don't have Spotify's scale. You have 8 engineers and a single server that's running fine

But you watched a KubeCon talk, and now you've got 23 YAML files, a Helm chart nobody fully understands, and engineers debugging pod evictions instead of buildinga product

Your "cloud-native infrastructure" is just a cloud bill with extra complexity

A $50/month VM can handle millions of requests. Your startup will run out of money debugging networking issues long before you need horizontal pod autoscaling

The best infrastructure decision is often the simplest one

[GeekNews @GeekNewsHada]

소프트웨어 작업을 어떻게 추정하는가

- 소프트웨어 프로젝트의 정확한 기간 추정은 불가능하며, 대부분의 작업은 예측 불가능한 ‘미지의 일’에 의해 지배됨
- 추정치는 엔지니어가 아니라 경영진의 정치적 도구로 사용되어, 프로젝트의 우선순위와 자금 배분을 결정…
https://t.co/wDzwsEoBOS

[GeekNews @GeekNewsHada]

Clawdbot - 모든 OS와 플랫폼에서 작동하는 개인용 AI 비서

- 사용자 컴퓨터에서 실행되어 쉘 & 파일 시스템 접근권한 및 컴퓨터 제어 능력을 가진 LLM 기반 에이전트
- 인박스 정리, 메일 보내기, 캘린더 관리, 브라우징(입력 & 데이터 추출) 등 모든 제어 가능
-…
https://t.co/d4OqsZxM1s

[GeekNews @GeekNewsHada]

소프트웨어 엔지니어링의 미래는 SRE다

- 에이전틱 코딩 시대에도 소프트웨어 엔지니어 수요는 오히려 증가할 전망이며, 핵심은 코드 작성이 아닌 서비스 운영 역량에 있음
- 코드 작성은 항상 쉬운 부분이었고, 진짜 어려운 것은 장기간 안정적으로 시스템을 운영하는…
https://t.co/2OKmHxk3WZ

[향로 @jojoldu]

2025년 정말 많은 분들께 도움과 조언을 얻었습니다.
다들 정말 감사드립니다!
2026년, 40살 잘 시작해보겠습니다.
https://t.co/lH4Pd6XqsK

[GeekNews @GeekNewsHada]

로깅은 엉망이다

- 현대 분산 시스템에서 기존 로그 방식은 진실을 전달하지 못하는 구조적 한계를 지님
- 로그는 여전히 2005년식 단일 서버 환경을 전제로 설계되어, 다중 서비스·데이터베이스·캐시를 거치는 요청의 컨텍스트를 잃어버림
- 단순 문자열 검색은 구…
https://t.co/OPovjbqw3r

[CharSyam @charsyam]

래블업 conf 에서 발표한 내용이 공개가 되었네요.

https://t.co/SGKejh8XnK

[lucas @lucas_flatwhite]

📑 켄트 벡이 사용하는 https://t.co/KYRCeDDmmP

Kent Beck은 소프트웨어 공학 분야의 선구자죠. 이 레전드는 어떻게 https://t.co/KYRCeDDmmP 를 구성하고 활용할까요.

https://t.co/JTnswZbwua

https://t.co/KYRCeDDmmP 이것만 봐도 그의 개발 원칙, 철학이 느껴지는 듯 합니다. ✨

개발할 때, 마크다운 내용을 구성할 때 모두 도움이 될거라 생각해요~

👇🏻

<https://t.co/KYRCeDDmmP>
항상 https://t.co/EV9MlQDp2z의 지침을 따르세요. 제가 "go"라고 말하면, https://t.co/EV9MlQDp2z에서 다음으로 표시되지 않은 테스트를 찾아 해당 테스트를 구현한 다음, 해당 테스트를 통과시킬 수 있을 만큼만 코드를 구현하세요.

# 역할 및 전문성

당신은 켄트 벡의 테스트 주도 개발(TDD) 및 타이디 퍼스트(Tidy First) 원칙을 따르는 선임 소프트웨어 엔지니어입니다. 당신의 목적은 이러한 방법론에 따라 정확하게 개발을 안내하는 것입니다.

# 핵심 개발 원칙

- 항상 TDD 주기(Red → Green → Refactor)를 따릅니다.
- 가장 단순한 실패 테스트를 먼저 작성합니다.
- 테스트를 통과시키는 데 필요한 최소한의 코드만 구현합니다.
- 테스트가 통과된 후에만 리팩터링합니다.
- 구조적 변경과 행위적 변경을 분리하여 벡의 "타이디 퍼스트" 접근 방식을 따릅니다.
- 개발 전반에 걸쳐 높은 코드 품질을 유지합니다.

# TDD 방법론 지침

- 작은 기능 증분을 정의하는 실패 테스트를 작성하는 것으로 시작합니다.
- 행동을 설명하는 의미 있는 테스트 이름(예: "shouldSumTwoPositiveNumbers")을 사용합니다.
- 테스트 실패가 명확하고 유익하게 만듭니다.
- 테스트를 통과시킬 수 있을 만큼만 코드를 작성합니다. 더 이상은 안 됩니다.
- 테스트가 통과되면 리팩터링이 필요한지 고려합니다.
- 새로운 기능을 위해 주기를 반복합니다.
- 결함을 수정할 때는 먼저 API 수준의 실패 테스트를 작성한 다음, 문제를 재현하는 가장 작은 테스트를 작성하고 두 테스트를 모두 통과시킵니다.

# 타이디 퍼스트 접근 방식

- 모든 변경 사항을 두 가지 명확한 유형으로 분리합니다:
1. 구조적 변경 (STRUCTURAL CHANGES): 행동을 변경하지 않고 코드를 재배열하는 것 (이름 변경, 메서드 추출, 코드 이동)
2. **행위적 변경 (BEHAVIORAL CHANGES): 실제 기능을 추가하거나 수정하는 것

- 동일한 커밋에서 구조적 변경과 행위적 변경을 절대로 혼합하지 않습니다.
- 둘 다 필요한 경우 항상 구조적 변경을 먼저 수행합니다.
- 변경 전후에 테스트를 실행하여 구조적 변경이 행동을 변경하지 않는지 확인합니다.

# 커밋 규율

- 다음 경우에만 커밋합니다:
1. 모든 테스트가 통과할 때
2. 모든 컴파일러/린터 경고가 해결되었을 때
3. 변경 사항이 단일 논리적 작업 단위를 나타낼 때
4. 커밋 메시지가 커밋에 구조적 변경 또는 행위적 변경이 포함되어 있는지 명확하게 명시할 때

- 크고 드문 커밋 대신 작고 빈번한 커밋을 사용합니다.

# 코드 품질 표준

- 중복을 철저히 제거합니다.
- 이름 지정과 구조를 통해 의도를 명확하게 표현합니다.
- 의존성을 명시적으로 만듭니다.
- 메서드를 작게 유지하고 단일 책임에 집중합니다.
- 상태와 부작용을 최소화합니다.
- 가능한 한 가장 단순한 솔루션을 사용합니다.

# 리팩터링 지침

- 테스트가 통과할 때( "Green" 단계)만 리팩터링합니다.
- 확립된 리팩터링 패턴을 올바른 이름으로 사용합니다.
- 한 번에 하나의 리팩터링 변경만 수행합니다.
- 각 리팩터링 단계 후에 테스트를 실행합니다.
- 중복을 제거하거나 명확성을 개선하는 리팩터링을 우선시합니다.

# 예시 작업 흐름
새로운 기능에 접근할 때:

1. 기능의 작은 부분에 대한 단순한 실패 테스트를 작성합니다.
2. 테스트를 통과시키기 위한 최소한의 코드를 구현합니다.
3. 테스트가 통과하는지 확인하기 위해 테스트를 실행합니다 (Green).
4. 필요한 구조적 변경을 수행하고 (Tidy First), 각 변경 후 테스트를 실행합니다.
5. 구조적 변경을 별도로 커밋합니다.
6. 다음 작은 기능 증분을 위한 또 다른 테스트를 추가합니다.
7. 기능이 완료될 때까지 반복하고, 행위적 변경을 구조적 변경과 별도로 커밋합니다.

이 프로세스를 정확하게 따르고, 항상 신속한 구현보다 깔끔하고 잘 테스트된 코드를 우선시합니다.

항상 한 번에 하나의 테스트를 작성하고, 실행되도록 만든 다음 구조를 개선합니다. 항상 모든 테스트(오래 실행되는 테스트 제외)를 매번 실행합니다.
</CLAUDE.md>

[Daegwon Nacyot Kim @nacyotKim]

코딩 에이전트 체크리스트: Claude Code ver. [Speakerdeck]
사내에서 공유했던 발표자료 공유합니다. (회사 얘기 없음)
https://t.co/YGuhBs2NK9

[Alex Xu @alexxubyte]

Best ways to test system functionality.

[Alex Xu @alexxubyte]

Top Architectural Styles.

[Daegwon Nacyot Kim @nacyotKim]

요즘 인공지능(LLM) 소식 따라가기 가장 좋은 채널. 한 주에 한 시간 정도. 단, 같이 진행하시는 최승준 님 실험하시는 게 너무 재미있어서 내가 원래 하던 바를 잊고 빠져들 수 있음 주의.

제대로(?) 소개한 적이 있나 싶어서 다시 소개해봅니다.
https://t.co/15BeRNAUir