Mitchell을 정말 존경함, 그가 이룬 성과에 감탄함
글에서 제시한 모든 의견에 동의함과 동시에 하나를 추가하고 싶음: 빠른 피드백 루프의 중요성임
변경을 하고 즉시 그 결과를 볼 수 있으면 정말 동기부여가 됨
코드를 장난스럽게 수정하고 그 효과를 관찰하면 많은 문제가 사라지거나 쉽게 해결 가능한 형태로 바뀌는 경험임
나의 경험과 완벽하게 일치함
거대한 프로젝트들에서는 설정과 실행이 얼마나 쉬운지와 프로젝트 문제(버그, 마감 미달 등)의 양이 확실히 연관이 있었음
시간이 된다면 Bret Victor의 'Inventing on Principal' 강연을 추천함
이 강연은 피드백 루프에 대해 이야기함 유튜브 링크
테스트 케이스도 이런 데 도움이 될지 궁금함
발견한 버그에 대해 e2e 테스트를 적용해서 확실히 고쳐졌는지 확인하려 고민 중임
정말로 빠른 피드백이 필수라고 생각함, 이 주제로 따로 글을 쓸 가치가 있을 정도임
무언가를 시도하거나 고치고 싶을 때, 셋업 자체에 몇 시간이 걸리면 의욕이 사라지고 결국 미루게 됨
그래서 lisp처럼 쓸만한 REPL이 있는 언어를 좋아함
즉석에서 결과를 볼 수 있는 즉각적인 만족감이 있음
특히 개인 프로젝트에서는 더욱 중요함
의욕을 잃는 순간 그 프로젝트는 증발함
그래서 개발 자체가 즐거운 경험이 되도록 하는 게 거의 가장 중요한 요소임
이 부분에 깊이 공감함
경험이 오히려 방해가 되는 부분이라 봄
시니어 엔지니어들이 완벽한 걸 만들기 위해 깊이 파고들다가, 막상 데모를 하려고 보면 결과물이 별로인 경우를 자주 봄
구현 자체는 잘됐어도, 기능이나 제품 자체가 완전히 별로임
가끔은 뇌를 꺼놓고 허접한 코드를 막 쓰고 싶음
예전에는 장난 프로젝트들을 많이 만들었고, 모든 소스코드를 한 파일에 때려넣기도 했었음
모듈화 따위 신경 안 썼어도 재미있었고 동작함
근데 이제는 장난 프로젝트 하나 완성하는 게 정말 힘들어짐
이게 바로 '세컨드 시스템 문제'라고 불리는 현상 아님?
한 번 해본 경험이 있으니까 쓸데없는 부가기능을 다 넣으려는 경향 때문인 것 같음
이런 걸 연습으로 극복할 수 있다고 봄
예를 들어 Advent of Code 같은 코딩 챌린지에 참여하다 보면, 초반 문제들은 간단하고 나중에만 최적화나 복잡한 알고리즘이 필요함
아니면 pico-8처럼 제한된 여건에서 장시간 코딩이 불가능함
혹은 해커톤이나 게임잼처럼 시간제한된 환경에서 해보는 것도 도움이 됨
신생 언어가 초기에 많이 하이프되는 것도 이 때문이라 생각함
경험이 적은 사람들이 예전 언어에서 지겨웠던 '베스트 프랙티스'를 다 잊고 자유롭게 시도할 수 있기 때문임
LLMs(Cursor)가 이 문제를 거의 해결해줌
DB 테이블은 직접 설계하고, 구현 부분은 LLM에 좀 자유롭게 맡김
글 정말 재미있게 읽었음
초기 서브 프로젝트의 목적이 '완성된 서브 컴포넌트'를 만드는 게 아니라, 다음 단계로 이동할 수 있을 만큼 '충분히 괜찮은' 서브 컴포넌트를 만드는 것이라는 점이 인상적임
이런 방식을 실천하려면 무언가를 '생략'해야 한다는 걸 깨달음
다른 사람들은 이런 모드에서 코드 모듈화를 무시한다고 했지만, 나는 코드를 깔끔하게 관리하는 게 오히려 만족감과 동기부여를 줌
그래서 나는 알고리즘, 자료구조, 성능 같은 부분은 '생략'할 예정임
결국 포인트는, 분명히 무언가는 건너 뛰어야 하지만, 그 무언가가 나에게 동기를 주는 요소라면 생략하지 않아야 한다는 것임
개발에서 데모를 만드는 것이 핵심적이라고 믿음
데모는 소프트웨어를 개발(프로그래밍)하는 것과 글로 설명하는 것(문서화)의 중간 단계 역할을 해줌
데모를 통해 나 자신의 프로젝트가 무엇을 해야 하는지에 대한 가설을 계속 검증할 수 있고, 일종의 피드백 메커니즘이 되어줌
데모는 오래 남아서 기능을 깨뜨렸을 때 바로 확인하고 고치는 반복 루프를 계속할 수 있음
개인적으로 개발 중인 게임 엔진에서 이런 방식으로 작업하고 있음 데모 예시 github 링크
이건 XP(Extreme Programming, 공식사이트)를 1인 개발자 방식으로 적용한 것임
이런 방식이 일반 상식이 되었으면 좋겠음
글이 기대와 달라 약간 놀랐음
개인 프로젝트에 초점이 맞춰져 있는 느낌임
나는 대규모 테크니컬 팀 프로젝트에서 모두가 한 목표를 향해 일하고, 일들을 제대로 끝내는 좋은 방법이 궁금함
15년 가까이 일하면서 예산 초과, 일정 초과, 기능 미달, 번아웃 없는 기술 프로젝트는 못 봤음
반대로 이런 대형 프로젝트를 성공적으로 잘 끌어가는 사례가 있다면, 추가 읽을 만한 링크나 추천 자료를 공유해주면 좋겠음
'예산 초과', '일정 초과', '기능 미달' 등이 문제라고는 생각하지 않음
예산 초과는 진짜 돈이 다 떨어지지 않는 한 흔히 있는 일임
대부분은 그냥 누군가가 견적이 틀렸다고 투덜대는 수준임
일정 초과도 마찬가지로, 진짜로 꼭 지켜야 하는 마감이 있는 게 아니라면 심각한 문제는 아님
사실 큰 홍보 캠페인 등 일정 연동 이벤트는 프로젝트가 거의 끝날 때까지 계획하지 않는 게 좋음
기능 미달도 결국 기대치의 문제임
진짜 문제는 '완전히 방전되어 사람들이 번아웃되는 것'임
이 점만큼은 최소한 확실히 피해야 함
혹시 욕을 먹을지 모르겠지만, 다양한 규모의 소프트웨어 프로젝트를 직접 관리하고 성공적으로 완료한 입장에서 이야기해보고 싶음
개인적으로는 Scaled Agile Framework에 점점 호감을 갖게 되었음
이걸 프레임워크, 즉 상황에 맞게 변형해 쓰는 일종의 '허수아비'로 활용함
덕분에 더 깊은 원자료를 탐구하고 스스로 결론을 내리게 되었음
진정한 성공은 '왜 이걸 만드는지 명확하게 이해하는 것'에서 시작하는 걸 배웠음
목표가 분명하지 않으면 우선순위도 못 세우고 어디서부터 시작해야 할지도 모르게 됨
이런 명확함이 '무엇을 언제 만들지'에 훨씬 도움이 되고, 때로는 '아예 안 만드는 결단'도 가능하게 해줌
그다음 중요한 것은 '공감능력'임
고객 입장에서 제대로 그들의 문제를 완전히 이해하고 해결책을 제시해야 함
단순히 고객이 원하는 걸 다 들어주는 게 아니라, 핵심 고통을 정확히 이해해 진짜로 가치 있는 것을 전달하는 것임
대부분 프로젝트가 실패하는 진짜 이유는 팀이 '잘못된 것'을 만드는데 너무 많은 시간을 쓰기 때문임
계속해서 필요한, 사람들이 진짜 원하거나 비용을 지불할 만한 가치 있는 기능에 집중한다면, 훨씬 더 많은 프로젝트가 성공적으로 완성될 것임
참고로, 해당 글에서 다루는 프로젝트 Ghostty도 분명 대형 프로젝트에 해당함
나에게 있어서는 그냥 시작하는 게 최고의 방법임
큰 프로젝트를 보면서 분석 마비에 빠지는 사람들이 정말 많음
Hacker News 의견
글에서 제시한 모든 의견에 동의함과 동시에 하나를 추가하고 싶음: 빠른 피드백 루프의 중요성임
변경을 하고 즉시 그 결과를 볼 수 있으면 정말 동기부여가 됨
코드를 장난스럽게 수정하고 그 효과를 관찰하면 많은 문제가 사라지거나 쉽게 해결 가능한 형태로 바뀌는 경험임
거대한 프로젝트들에서는 설정과 실행이 얼마나 쉬운지와 프로젝트 문제(버그, 마감 미달 등)의 양이 확실히 연관이 있었음
이 강연은 피드백 루프에 대해 이야기함
유튜브 링크
발견한 버그에 대해 e2e 테스트를 적용해서 확실히 고쳐졌는지 확인하려 고민 중임
무언가를 시도하거나 고치고 싶을 때, 셋업 자체에 몇 시간이 걸리면 의욕이 사라지고 결국 미루게 됨
그래서 lisp처럼 쓸만한 REPL이 있는 언어를 좋아함
즉석에서 결과를 볼 수 있는 즉각적인 만족감이 있음
의욕을 잃는 순간 그 프로젝트는 증발함
그래서 개발 자체가 즐거운 경험이 되도록 하는 게 거의 가장 중요한 요소임
경험이 오히려 방해가 되는 부분이라 봄
시니어 엔지니어들이 완벽한 걸 만들기 위해 깊이 파고들다가, 막상 데모를 하려고 보면 결과물이 별로인 경우를 자주 봄
구현 자체는 잘됐어도, 기능이나 제품 자체가 완전히 별로임
가끔은 뇌를 꺼놓고 허접한 코드를 막 쓰고 싶음
예전에는 장난 프로젝트들을 많이 만들었고, 모든 소스코드를 한 파일에 때려넣기도 했었음
모듈화 따위 신경 안 썼어도 재미있었고 동작함
근데 이제는 장난 프로젝트 하나 완성하는 게 정말 힘들어짐
한 번 해본 경험이 있으니까 쓸데없는 부가기능을 다 넣으려는 경향 때문인 것 같음
예를 들어 Advent of Code 같은 코딩 챌린지에 참여하다 보면, 초반 문제들은 간단하고 나중에만 최적화나 복잡한 알고리즘이 필요함
아니면 pico-8처럼 제한된 여건에서 장시간 코딩이 불가능함
혹은 해커톤이나 게임잼처럼 시간제한된 환경에서 해보는 것도 도움이 됨
경험이 적은 사람들이 예전 언어에서 지겨웠던 '베스트 프랙티스'를 다 잊고 자유롭게 시도할 수 있기 때문임
DB 테이블은 직접 설계하고, 구현 부분은 LLM에 좀 자유롭게 맡김
초기 서브 프로젝트의 목적이 '완성된 서브 컴포넌트'를 만드는 게 아니라, 다음 단계로 이동할 수 있을 만큼 '충분히 괜찮은' 서브 컴포넌트를 만드는 것이라는 점이 인상적임
이런 방식을 실천하려면 무언가를 '생략'해야 한다는 걸 깨달음
다른 사람들은 이런 모드에서 코드 모듈화를 무시한다고 했지만, 나는 코드를 깔끔하게 관리하는 게 오히려 만족감과 동기부여를 줌
그래서 나는 알고리즘, 자료구조, 성능 같은 부분은 '생략'할 예정임
결국 포인트는, 분명히 무언가는 건너 뛰어야 하지만, 그 무언가가 나에게 동기를 주는 요소라면 생략하지 않아야 한다는 것임
데모는 소프트웨어를 개발(프로그래밍)하는 것과 글로 설명하는 것(문서화)의 중간 단계 역할을 해줌
데모를 통해 나 자신의 프로젝트가 무엇을 해야 하는지에 대한 가설을 계속 검증할 수 있고, 일종의 피드백 메커니즘이 되어줌
데모는 오래 남아서 기능을 깨뜨렸을 때 바로 확인하고 고치는 반복 루프를 계속할 수 있음
개인적으로 개발 중인 게임 엔진에서 이런 방식으로 작업하고 있음
데모 예시 github 링크
이런 방식이 일반 상식이 되었으면 좋겠음
개인 프로젝트에 초점이 맞춰져 있는 느낌임
나는 대규모 테크니컬 팀 프로젝트에서 모두가 한 목표를 향해 일하고, 일들을 제대로 끝내는 좋은 방법이 궁금함
15년 가까이 일하면서 예산 초과, 일정 초과, 기능 미달, 번아웃 없는 기술 프로젝트는 못 봤음
반대로 이런 대형 프로젝트를 성공적으로 잘 끌어가는 사례가 있다면, 추가 읽을 만한 링크나 추천 자료를 공유해주면 좋겠음
예산 초과는 진짜 돈이 다 떨어지지 않는 한 흔히 있는 일임
대부분은 그냥 누군가가 견적이 틀렸다고 투덜대는 수준임
일정 초과도 마찬가지로, 진짜로 꼭 지켜야 하는 마감이 있는 게 아니라면 심각한 문제는 아님
사실 큰 홍보 캠페인 등 일정 연동 이벤트는 프로젝트가 거의 끝날 때까지 계획하지 않는 게 좋음
기능 미달도 결국 기대치의 문제임
진짜 문제는 '완전히 방전되어 사람들이 번아웃되는 것'임
이 점만큼은 최소한 확실히 피해야 함
개인적으로는 Scaled Agile Framework에 점점 호감을 갖게 되었음
이걸 프레임워크, 즉 상황에 맞게 변형해 쓰는 일종의 '허수아비'로 활용함
덕분에 더 깊은 원자료를 탐구하고 스스로 결론을 내리게 되었음
진정한 성공은 '왜 이걸 만드는지 명확하게 이해하는 것'에서 시작하는 걸 배웠음
목표가 분명하지 않으면 우선순위도 못 세우고 어디서부터 시작해야 할지도 모르게 됨
이런 명확함이 '무엇을 언제 만들지'에 훨씬 도움이 되고, 때로는 '아예 안 만드는 결단'도 가능하게 해줌
그다음 중요한 것은 '공감능력'임
고객 입장에서 제대로 그들의 문제를 완전히 이해하고 해결책을 제시해야 함
단순히 고객이 원하는 걸 다 들어주는 게 아니라, 핵심 고통을 정확히 이해해 진짜로 가치 있는 것을 전달하는 것임
대부분 프로젝트가 실패하는 진짜 이유는 팀이 '잘못된 것'을 만드는데 너무 많은 시간을 쓰기 때문임
계속해서 필요한, 사람들이 진짜 원하거나 비용을 지불할 만한 가치 있는 기능에 집중한다면, 훨씬 더 많은 프로젝트가 성공적으로 완성될 것임
큰 프로젝트를 보면서 분석 마비에 빠지는 사람들이 정말 많음
정말 어려운 건 끝내는 것임
직접 사용할 소프트웨어를 만들면 내 문제를 스스로 해결할 수 있음
내가 직접 써보면서 소프트웨어 버그도 발견할 수 있음
실제로 웹 서버를 직접 만들며 사용하다 여러 버그를 찾았음
집중적이고, 반복적이며, 항상 동작하는 결과물을 지향하는 개발 문화임