Lee Jae-yeol (👨‍💻 [email protected])

#main_twt twitter.com/kodingwarrior/…

간만에 한국 연합우주 개발자 모임 스프린트, 4월 11일 튜링의 사과에서 어셈블!!! moim.live/events/4ca6681…

AI쓰는법중에 젤 공감 안 되는거 몇 년차 뭐시기야 이런 디렉션임 몇 년차인게 뭔 상관임 연차 쌓인 폐급이 세상에 얼마나 널렸는디-,.-

요새 얘가 입만 열면 남조선 전국민 비문학독해 시작됨

내 생에 김정은이 이렇게나 마물로부터 경계를 지키는 로판 북부대공처럼 느껴진 적은 없었다... "안 보이는 곳에서 너희를 지키고 있었다고" 김주애가 로판 클리셰로 나오는 햇살여주처럼 보일 지경임

자신은 개발속도에 자신있다는 사람을 몇 번 봤었는데... 암만 빨리 개발해도 개발자테스트랑 QA, 배포 후에 수정사항이 계속 나오면 그건 그걸 수정 완료하는 때 까지가 본인의 개발속도라는걸 모르더라

배우들 냉동캡슐에 가두고 촬영할 때만 해동하자 윈터솔져처럼

왜냐면사람들이바닥에똥쌈

🍕 Two-pizza? Two-slice Team!! > 2026년 엔지니어링 팀 구조의 새로운 모델 - 2인 전용 - 해적 한 명과 건축가 한 명 해적의 임무는 바이브 코딩을 통해 가치 있고 출시 가능한 제품 기능을 최대한 빠르게 개발하는 것. 건축가의 임무는 해적이 발견한 제품 표면을 신뢰할 수 있고 구조화된 기계로 바꾸는 것. 이 역시 바이브 코딩을 통해 이루어지지만, 더 느리고 논리적인 속도로 진행됩니다. 모든 제품에는 해적같은 개발자가 필요하지만, 대부분의 제품은 PMF 형태를 갖춘 후에야 아키텍트가 필요하고, 그마저도 정규직까지는 필요하지 않은 경우가 많습니다. 아키텍트는 여러 코드베이스를 넘나들며 흥미로운 기술적 과제를 해결할 수 있는 반면, 해적 같은 개발자는 자신이 처음부터 끝까지 책임지는 제품에 모든 역량을 집중합니다. ↓ "소통이 부족한 게 아니라, 소통 자체가 끔찍한 거예요!" 2002년, 아마존 리트릿에서 매니저들이 "더 많은 커뮤니케이션이 필요하다"고 말했을 때, 제프 베조스가 던진 한마디입니다. 그리고 몇 주 뒤, 그는 회사 전체를 작은 자율 팀으로 재편했죠. 'Two-pizza rule'.. 피자 두 판으로 먹일 수 있는 인원, 대략 10명 이하. 이 규칙이 24년간 테크 업계의 골든 스탠다드였죠. 그런데 지금, 그마저도 너무 크다는 이야기가 나오고 있어요. ↓ 피자 두 판에서 피자 두 조각으로 Every라는 미디어/소프트웨어 회사의 CEO Dan Shipper는 새로운 법칙을 제안합니다. 'Two-slice team'.. 뉴욕 스타일 피자 두 조각, 딱 한 사람이 서서 먹을 분량입니다. Every에는 4개의 소프트웨어 프로덕트가 있고, 각각을 단 한 명이 운영합니다. 코드의 99%는 AI 에이전트가 작성하고요. 전체 6개 사업부에 정규직은 겨우 20명. 놀라운 건 이게 데모 수준이 아니라는 점이에요. 예를 들어 Monologue라는 스마트 받아쓰기 앱은 하루 약 3만 건이 사용되고, 매일 150만 단어를 처리합니다. 코드베이스가 14만 3천 줄인데, 한 사람이 Codex와 Opus의 도움을 받아 거의 전부 혼자 작성했어요. ↓ 한 사람이지만, 혼자가 아닌 구조 오해하면 안 되는 게 있어요. Two-slice team이 완전한 고립을 의미하지는 않아요. Every의 디자인, 그로스, 마케팅 팀은 내부 에이전시처럼 작동합니다. 한 디자이너가 월요일에는 Monologue의 화면을 디자인하고, 화요일에는 Spiral의 프로모션 배너를, 수요일에는 Cora의 이메일 템플릿을 만드는 식이죠. 필요하면 외부 프리랜서도 투입됩니다. Cora를 운영하는 Kieran은 시니어 풀스택 엔지니어를 주 며칠씩 고용해서, AI가 아직 한 번에 잘 못 푸는 까다로운 인프라 문제를 함께 해결합니다. 핵심은.. 이 유연한 구조가 가능한 이유도 AI 덕분이라는 거예요. 프리랜서가 낯선 코드베이스를 AI로 몇 분 만에 파악할 수 있으니, 온보딩에 시간을 뺏기지 않습니다. ↓ 이게 진짜로 작동하는 이유? CEO Dan 본인도 직접 증명하고 있어요. 그는 최근 몇 주간 'Proof'라는 에이전트 네이티브 마크다운 에디터를 만들었습니다. 여러 사람과 AI 에이전트가 함께 마크다운 문서를 편집하고, 누가 뭘 썼는지 출처를 추적하는 도구죠. 이전이었다면 엔지니어 3~4명이 6개월은 걸렸을 프로젝트를, 그는 본업 틈틈이 혼자 만들었습니다. ↓ 저는 여기에서 단순히 "AI가 대단하다"는 메시지보다, 조직 설계의 패러다임이 바뀌고 있다는 점에 더 주목했어요. 당시 Two-pizza rule은 "소통 비용을 줄여라"는 통찰이었죠. 그런데 Two-slice team은 한 발 더 나아가 "소통 비용 자체를 거의 없앨 수 있다면, 팀이라는 개념을 재정의하라"는 이야기예요. GM.. 제너럴 매니저는 극도의 자율성을 갖고, 지원 팀은 유연하게 드나들며, AI가 그 사이의 마찰을 녹여줍니다. 물론 모든 제품, 모든 조직에 적용될 수는 없겠죠. 하지만 적어도 소프트웨어 프로덕트 영역에서, "한 사람 + AI"가 이전의 소규모 팀만큼의 결과물을 낼 수 있다는 건 이미 현실이 되고 있어요. 피자 한 판을 나눠 먹던 시대에서, 피자 두 조각을 혼자 서서 먹는 시대로.. 그렇게 규모의 단위가 달라지고 있습니다.

@hellodhlyn ㅜㅜㅜㅜㅜㅜㅜㅜ

으악 연합우주 도메인 만료된거 모르고 있었네

이런 교수님 밑에서 배워야 제대로 배운다 역시 한국버츄얼대하꾜 창립자 교수님은 보법이 다르다

@utilforever 오!! 완전 축하드립니다!

4월부터 한양대학교에서 Visiting Senior Researcher로 일하게 되었습니다. 모두들 고맙습니다. 🙇‍♀️🙇🙇‍♂️

@GameDevLeone 그래도 커뮤니티 레벨에서 선긋냐랑 아니냐가 또 다르잖아요

@kodingwarrior 실상은 게임회사도 프로그래머만 개발자라 부르는 현실...

아까전에 RT한 내용과는 별개로... 개인적으로는 개발자라는 표현을 쓸 때, 게임업계 사람들이 프로그래머도 아티스트도 기획자도 선 안 긋고 다 같이 개발자라고 연대의식을 가지는 문화가 좋았던 것 같음. 게임개발이라는 행위에서 같은 팀이 되어서 작업해야 비로소 완성이 되기 때문이던가

(자기가 만든 게임 해보지도 않을 거면 대체 왜 게임을 만드는 건지 궁금해지지만요) 예전 프로그래머들은 뭐 시간이 나서 만화 보고 영화 보고 책 읽고 게임 해보고 그랬을까요....?

개발자는 프로그래머를 뜻하는 말이 아닙니다... 그리고 프로그래머들 중에 자기가 만드는 게임 해보지도 않는 사람 널린 거 같은 개발자들이 더 잘 압니다

번역 업계가 이미 겪고 있는 그 상황이 SI 업계로 그대로 번지겠구만. 원래도 쉽지 않은 시장인데 저 명분으로 가격 후려치면 어딘가 터지지 않을까?

[PSA] 어쩌다 보니 여기서는 코딩 이야기를 거의 안 하게 됐습니다. 연합우주에 있는 Hacker's Pub에서 가끔가다 찔끔찔끔 뭔가 올리게 될 것 같습니다. "이 사람 더이상 내가 알던 그런 사람이 아닌 것 같은데..."싶으신 분들은 이쪽으로 ➡️ @dalgona" target="_blank" rel="nofollow noopener">hackers.pub/@dalgona

📋 Claude Code /init 명령어가 새롭게 바뀌고 있네요! 기존에도 /init은 프로젝트에 CLAUDE.md를 생성하고 기본 설정을 잡아주는 역할을 했는데요, 이번 새 버전은 한 단계 더 나아가서 사용자를 인터뷰하며 설정을 구성해주네요. Skills, Hooks 등 Claude Code의 고급 기능까지 대화를 통해 세팅할 수 있게 된 거죠. 현재 플래그를 통해 테스트할 수 있어요! > CLAUDE_CODE_NEW_INIT=1 claude 이렇게 Claude를 실행한 뒤, 원하는 레포에서 /init을 입력하면 됩니다요! ↓ /init이 하는 일?? /init은 새 레포든 기존 레포든 상관없이 Claude Code 설정을 잡아주는 명령어예요. - CLAUDE.md 생성 및 구성 > 프로젝트별 지침, 코딩 컨벤션, 빌드 명령어 등을 담는 핵심 설정 파일 - Hooks 설정 > 특정 이벤트(파일 저장, 커밋 등)에 자동으로 실행되는 셸 명령어 - Skills 연결 > 반복적인 워크플로우를 재사용 가능한 프롬프트로 정의 이런 것들을 일일이 문서를 읽고 수동으로 설정하는 대신, /init이 대화를 통해 "어떤 프로젝트인지", "어떤 워크플로우를 쓰는지" 물어보면서 알아서 구성해주는 방식이에요. ↓ 왜 인터뷰 방식이죠? Claude Code는 기능이 점점 많아지고 있어요. CLAUDE.md, hooks, skills, MCP 서버, memory 시스템, worktree 등등... 강력하지만 처음 접하는 사람에게는 어디서부터 시작해야 할지 막막할 수 있죠. 인터뷰 방식의 /init은 이 진입 장벽을 낮추려는 시도라고 볼 수 있어요. 사용자가 모든 기능을 미리 알 필요 없이, 대화를 통해 자연스럽게 자신에게 필요한 설정을 발견하고 적용하게 되는 거죠. 기존 사용자에게도 의미가 있습니다! 새로운 기능이 추가될 때마다 changelog를 뒤지는 대신, /init을 다시 실행하면 최신 기능을 기반으로 설정을 업데이트할 수 있으니까요.