▲GN⁺ 9달전 | parent | ★ favorite | on: 소프트웨어를 빠르게 개발하는 나만의 방법(evanhahn.com)Hacker News 의견 최근 몇 년간 빠르고 충분히 견고한 시스템을 구축하는 방법을 터득함 한 가지 도구를 깊이 익히는 것이 중요함을 배움. 표면적으로 더 적합해 보이는 도구보다 내가 잘 아는 것이 훨씬 효율적임. 실제로 대부분의 프로젝트에서 Django가 딱 맞는 선택임 가끔 Django가 너무 무겁지 않을까 걱정하며 프로젝트를 시작했지만, 결과적으로 프로젝트가 초기 의도를 훌쩍 넘어서 성장했음. 예를 들어 상태 페이지 앱을 만들었는데, Django의 한계를 피해가려는 노력이 비효율적임을 바로 깨달음 Django 모델에 맞는 대부분의 앱에서는 데이터 모델이 핵심임. 프로토타입이라도 데이터 모델 리팩토링을 미루면 나중에 비용과 난이도가 기하급수적으로 상승하게 됨 대부분의 앱은 싱글 페이지 앱이나 무거운 프론트엔드 프레임워크가 필요하지 않음. 일부가 해당될 수도 있지만 전체 페이지의 80%는 전통적인 Django 뷰가 충분함. 나머지는 AlpineJS나 HTMX를 검토하면 됨 대부분의 경우 직접 개발하는 것이 더 쉬움. Django로 CRM, 상태 페이지, 지원 시스템, 영업 프로세스 등 여러 기능을 빠르게 만들 수 있음. 상업용 CRM 연동보다 훨씬 빠름. 지루할 정도로 평범한 기술을 고를 것. Python/Django/Postgres 조합이면 대부분 해결됨. Kubernetes, Redis, RabbitMQ, Celery 등은 잊어도 됨. Alpine/HTMX는 예외인데, JS 스택 대부분을 피할 수 있기 때문임 Redis와 Kubernetes는 나에게는 2025년의 ‘지루한 기술’임. 둘 다 극도로 안정적이며 쓰임새가 명확하고, 단점도 이미 잘 알려져 있어 신뢰도 높음. 나는 개인적으로 이 둘의 팬임. 내가 원하는 일을 정확히 해주니까 신뢰도가 높음 나도 Django를 정말 좋아함. 프로젝트를 엄청 빠르게 시작해 배포할 수 있음 직장에서는 Go를 쓰는데, 동일한 API 엔드포인트 개발에 코드가 10배 더 길어짐. 쿼리 파라미터, 페이징 등 기능이 추가될 때마다 코드가 점점 더 길어짐. 권한 모델 추가하면 더 심해짐 물론 퍼포먼스 차이도 크지만, 실제로는 DB 쿼리가 퍼포먼스의 대부분을 좌우함. Python에서도 충분히 빠름 정말로 ‘지루한 기술’을 고른다면 Postgres조차 한 번 더 생각해 볼 필요가 있음 많은 사람들이 생각하는 것보다 Sqlite는 훨씬 더 규모가 큼. 로컬 개발/격리된 CI 인스턴스에서 특히 그렇고, 소규모 앱에서는 생산 환경에서도 충분히 쓸 수 있음 Celery는 Django 프로젝트에서 꽤 자주 쓰는 편임. 복잡성이 마음에 들진 않지만, PaaS 환경에서는 오히려 제일 덜 고통스러운 선택임 매번 Celery 없이 해보겠다고 시작하지만, 결국 HTTP로 트리거되는 작업들이 타임아웃에 부딪혀서 Celery를 쓰게 됨. 그 단계에서 쓰레드, 크론잡(특히 PaaS에서는 어려움), Celery 셋 중 하나를 선택해야 함. 어떻게 대응하는지 궁금함 "대부분의 앱은 SPA나 무거운 프론트엔드 프레임워크가 필요하지 않다"라는 주장과 "하나의 도구를 깊게 익혀라"는 조언이 충돌되는 것 같음 나는 모든 페이지를 React로 만듦. 그 이유는 SPA가 꼭 필요한 게 아니라, 결국에는 클라이언트 사이드 상태 관리가 필요한 일이 생겨서 처음부터 React로 모든 걸 만드는 것이 더 편리하다고 느꼈기 때문임. 처음엔 무겁게 느껴져도 결론적으로 효율적임 거친 초안으로 코드를 남겼을 때, 흔히 관리자가 그런 코드를 그대로 ‘최종 버전’으로 배포함 그래서 처음부터 robust한 코드로 씀. 심지어 테스트 하네스도 거의 배포 수준으로 견고하게 만듦 핵심은 아주 질 좋은 모듈을 만드는 것임. 변경 가능성이 매우 낮거나, 변경 시 엄청나게 큰 이슈가 되는 부분은 아예 독립적인 모듈로 격리해서 의존성 형태로 임포트함 이런 모듈 덕분에 새로운 앱을 매우 빠르게 개발할 수 있고, 품질도 계속 높게 유지 가능함 직접 사용한 예시는 RVS_Checkbox, ambiamara, RVS_Generic_Swift_Toolbox 등임 질문이 있는데, Swift에서 주석 마커로 "* ##################################################################" 같은 코드 패턴을 쓰는 게 표준인지 궁금함 소스코드에서 매우 시각적으로 두드러짐 프로젝트의 규모에 따라 접근 방식이 많이 달라짐 개인 프로젝트나 소규모 팀이라면 ‘빠르고 거칠게’ 개발하는 게 최적임. 이런 방식이 소규모 개발의 강점임 소규모에서는 버그가 생겨도 금방 고칠 수 있고, 팀원 모두가 전체 코드를 거의 완벽하게 이해하고 있음 규모가 커지면 아키텍처 실수나 버그 수정 비용이 폭증함. 아키텍처는 필연적으로 복잡해지고, 대규모 리팩토링은 사실상 불가능함. 이런 환경에선 한 단계 한 단계 정확성이 최우선이 되어야 함 맥락이 정말 중요함. ‘대규모’가 얼마만큼을 의미하는지는 다를 수 있지만, 내가 경험한 바로는 앱 간 API를 일찍 협의하여 프론트/백엔드 모두 빠르게 작업 환경을 갖추는 것이 항상 옳았음 가능한 빨리 프로덕션 서버에 배포하여 테스트와 팀 간 이슈를 드러내는 게 효과적임 글쓴이는 코드 관점에 집중하는 것 같은데, 대규모 팀일수록 이 점이 더 중요하다고 생각함 단, 팀 간 계층식 의존성을 두는 아키텍처는 별로라고 생각하지만 실제로 많이 이루어지고 있음 이런 상황에서는 시스템을 축소해서 운영해야 함. 모두가 거대한 시스템을 원하기는 해도 실제로는 필요하지 않음 “24시간 게임잼에서는 코드 품질에 신경 쓸 필요 없다”는 말이 있는데, 내가 해본 대부분 해커톤/코드 리뷰 경험상, 가장 좋은 성과를 낸 팀들이 코드 품질이나 rudimentary한 테스트 환경도 같이 챙겼음 위 두 주장(빨리 하려면 코드 품질을 포기해야 한다 vs 좋은 성적팀일수록 품질이 높다)은 사실 상충하지 않음. 품질 좋은 팀이 꼭 코드 정갈함에만 매달렸던 건 아님 게임잼 사례에서는 코드의 깨끗함에 너무 집착하면 오히려 전체 결과물이 좋지 못함. UE blueprint 같은 시스템이 왜 ‘깔끔함’보다 결과물을 우선시해야 하는지 보여줌 어떤 사람들은 코드의 ‘청결함’을 전체적으로 평가하고, 다른 사람들은 불필요한 코드 개선의 세부적인 비용/효익을 평가함 내 생각엔 후자가 어떤 상황에서도 훨씬 더 나은 성과를 내는 듯함. 해커톤에서든, 안정성 높은 제품 코드든 마찬가지임 “프로토타이핑을 해보면 예상 못 한 ‘unknown unknowns’가 드러난다”는 내용과는 달리, 내가 뭔가를 처음 만져볼 때는 항상 장점만 보이고 단점은 잘 보이지 않음 실제로는 엣지 케이스 처리, 유저에게 친절한 에러 메시지, 부작용 제거 등 실제 기능 완성 단계에서야 진짜 문제(unknown unknowns)가 드러남 아마도 내가 경험하는 unknown unknowns는 도구/프레임워크/라이브러리 자체에서 생기고, 저자는 문제 영역 자체에서의 unknown unknowns를 말하는 듯함 rough draft가 너무 거칠면 안 된다는 점도 맞음. 대충 넘어가면 안 되는 부분에서 진짜 문제가 터짐. 예를 들어, 랠리 드라이버들이 미리 트랙 리서치를 대충 하면 예상 못 한 위험(예, 커브 앞의 방지턱 등)에 노출될 수 있음 직접 쓸 도구를 만들 때는 대충 만들어도 무난하게 쓸 수 있는데, 그렇게 빠르게 만든 도구는 허점투성이여도 문제를 겪지 않음 요즘처럼 구조조정이 잦은 테크 업계가 소프트웨어 품질과 엔지니어 생산성의 가장 큰 위협임 해고의 불안감, 빠른 성과 압박은 창의성과 실험정신을 죽이고 번아웃을 유발함 모두가 AI 같은 유행 이슈에 군중심리로 휩쓸리고, 비판도 하지 못하는 환경이 되어버림 LLM 자동 코딩보다 더 시급한 문제임 항상 소프트웨어 품질의 최대 위협은 소비자가 품질을 위해 돈을 안 쓴다는 것임 품질을 ‘느끼는’ 사용자층이 존재해도 새 제품을 품질만으로 성공시키기에는 역부족임 소프트웨어 이외 분야, 예를 들면 자동차나 가전제품은 품질별로 가격이 다르지만 소프트웨어는 그렇지 않음 프로그래밍 레벨의 벤더 락인이 실제로는 SaaS 락인보다 훨씬 파괴적임 이미 하드웨어 시장은 소수에 의해 독점되고 있는데, 이제 소프트웨어까지 동일 기업들이 독점할 날이 옴 결과적으로 컴퓨터 프로그래머 대신 LLM 프롬프터만 남게 될 것임 24시간 게임잼 등 빠른 사이클에서 오히려 나쁜 코드는 치명적임을 느낌 코드가 깔끔할수록 실수도 줄어들고, 작업 기억 부담도 덜하며, 막판에 원하는 변경이나 기능 추가, 문제 수정이 훨씬 쉬워짐 24시간 프로젝트에서 가장 많이 일을 망치는 건, 코드를 느리게 쓴 게 아니라 자기 스스로 구석에 몰리거나 예측 불가한 문제에 부딪혀 탈선하는 것임 물론 모든 버그를 잡아야 한다는 건 아님. 하지만 기초 품질이 낮으면 전체적으로 힘든 프로젝트 경험임 시간이 더 많은 프로젝트에도 이 원칙은 적용됨. 시간이 많다고 대충 쓰는 게 나은 건 아님 좋은 코드를 습관화하면 추가 비용 없이 품질을 담보할 수 있음. 그리고, 시간이 더 들더라도 결국엔 가치 있는 일임 나도 같은 생각임. 여러 번 게임잼을 해봤지만, ‘엉성한 코드’는 마감 전 1-2시간에, 남이 안 건드릴 파일에 한해서만 허용함 공통 로직 정리 등 코드 정리는 생각보다 오래 안 걸림 현실적으로 어설픈 코드에서 발생하는 버그는 코드 정리로 절약한 시간보다 훨씬 크고 위험함 단, 서로 비슷하지만 다른 기능(예, 빛 fade out vs 색상 fade out)은 반복 코드를 남겨두는 편임. 요구사항이 갈라지기 쉬워서임 빠르고 좋은 코드를 쓰려면 결국 많이 써보는 게 답임 반복적인 작업이 싫을 순 있어도, 실제로 효과적임 시간 내에 깔끔하게 코딩할 수 있는 사람은 그 코드를 많이 써본 경험자임 급할 때 fancy한 asset loader 같은 건 신경 쓰지 않고 그냥 정적 파일로 때움 경로 탐색 등이 필요하면 그냥 breadth first search 같은 간단한 것으로 처리함 이런 게 ‘나쁜 코드’가 아닌, 그냥 임시방편이자 빠른 해결책임 물론 규정상 이런 모듈 사용을 금지할 수도 있어서 그 땐 주어진 규칙에 맞춰야 함 ‘좋은 코드를 쓰는 게 더 오래 걸린다’는 인식이 오해라고 생각함. 일정 요구사항 이상을 맞추려면 좋은 코드가 속도에 장애물이 되지 않음 “어느 정도가 ‘good enough’냐”라는 기준이 팀마다 다 달라서 그게 내 커리어에서 가장 큰 갈등의 원인임 빅테크 출신은 테스트 미흡에 불만이고, 스타트업 출신은 속도가 느리다고 불만임 ‘good enough’ 기준을 명확히 문서로 기록해서 팀 내에 공유하는 것이 유익할 것임 이게 바로 팀 차터, 즉 ‘우리가 일하는 방식’ 문서임 팀 차터 샘플 참고 가능함 글에서 언급되지 않은 중요한 요소 중 하나는 시간에 따른 개발 속도 저하임 프로젝트와 팀 규모가 커지면 개발 속도는 자연스럽게 느려짐 즉각적인 개발 속도에 조금 손해를 보더라도 장기적으로 개발 속도가 덜 저하되도록 초기에 테스트, 문서화, 결정 로그, Agile 미팅 등 준비가 필요함 관찰성(observability) 같은 기능이나 테스트하기 쉬운 코드 구조를 미리 안 준비하면 나중에 엄청난 악영향이 남음 솔로 개발자지만, 결정 로그·테스트·문서화 세 가지의 중요성을 체감함 나는 “랩 노트북”이라고 부르는 실시간 설계 기록을 작성하는데, 이게 나중에 테스트와 문서화의 밑바탕이 됨 랩 노트북 있으면 늦게 시작해도 더 좋은 문서를 빠르게 쓸 수 있음. 테스트는 설계가 변하지 않았는지 검증에도 도움이 됨 아주 짧게 쓸 일회성 도구는 그냥 막 시작해도 되지만, 오래 쓸 시스템은 천천히라도 기초를 단단히 쌓는 게 결국 합리적이고 유지보수 가능한 결과를 줌 별로 인기 없는 의견이지만, 설계는 먼저 종이에서 해보고 그 다음에 디지털로 옮기는 게 효과적임 나에게도 익숙한 패턴임. rough draft, 혹은 아이디어 검증용으로 다른 스크립트 언어나 수동 실행을 묶은 작은 코드로 시작함 이런 과정을 거쳐 오히려 “우리가 원하던 걸 만들 필요가 없겠다”는 결론에 도달할 때도 많았음 코딩하다 집중이 흐트러지는 부분에 정말 공감함. 정리하다보면 토끼굴에 빠져 커밋 단위가 커져 동료들이 리뷰하기 힘든 상태가 됨. 결국엔 작업을 모두 폐기하고 다시 작게, 목적에 집중해서 진행하는 경우가 많음 때로는 쓸 만한 조각만 따로 빼서 다른 PR로 올릴 수 있음 비즈니스는 결과물을 빠르게 원하고, 코드의 트레이드오프를 debt가 산더미처럼 쌓여 아주 느린 개발 속도를 경험하기 전까지는 이해하지 못함 중요한 것은 균형이고, 프로젝트마다 다른 기준이 적용될 수 있음 그래서 작은, 집중된, 간단한 변경만 자주 하는 것이 도움이 됨 하지만 큰 해결책을 작은 조각으로 나누는 게 생각만큼 쉽지 않음 아무 관련 없는, 쓰이지도 않는 코드를 ‘나중에 필요할 것’이라는 이유로 커밋하는 경우를 자주 보는데, 결국 우선순위 변경·사람 이동 등으로 1년 뒤엔 그 모든 게 쓸데 없는 코드가 되고, 그 당시의 계획도 아무도 알지 못해 버리게 됨
Hacker News 의견
최근 몇 년간 빠르고 충분히 견고한 시스템을 구축하는 방법을 터득함
한 가지 도구를 깊이 익히는 것이 중요함을 배움. 표면적으로 더 적합해 보이는 도구보다 내가 잘 아는 것이 훨씬 효율적임. 실제로 대부분의 프로젝트에서 Django가 딱 맞는 선택임
가끔 Django가 너무 무겁지 않을까 걱정하며 프로젝트를 시작했지만, 결과적으로 프로젝트가 초기 의도를 훌쩍 넘어서 성장했음. 예를 들어 상태 페이지 앱을 만들었는데, Django의 한계를 피해가려는 노력이 비효율적임을 바로 깨달음
Django 모델에 맞는 대부분의 앱에서는 데이터 모델이 핵심임. 프로토타입이라도 데이터 모델 리팩토링을 미루면 나중에 비용과 난이도가 기하급수적으로 상승하게 됨
대부분의 앱은 싱글 페이지 앱이나 무거운 프론트엔드 프레임워크가 필요하지 않음. 일부가 해당될 수도 있지만 전체 페이지의 80%는 전통적인 Django 뷰가 충분함. 나머지는 AlpineJS나 HTMX를 검토하면 됨
대부분의 경우 직접 개발하는 것이 더 쉬움. Django로 CRM, 상태 페이지, 지원 시스템, 영업 프로세스 등 여러 기능을 빠르게 만들 수 있음. 상업용 CRM 연동보다 훨씬 빠름.
지루할 정도로 평범한 기술을 고를 것. Python/Django/Postgres 조합이면 대부분 해결됨. Kubernetes, Redis, RabbitMQ, Celery 등은 잊어도 됨. Alpine/HTMX는 예외인데, JS 스택 대부분을 피할 수 있기 때문임
Redis와 Kubernetes는 나에게는 2025년의 ‘지루한 기술’임. 둘 다 극도로 안정적이며 쓰임새가 명확하고, 단점도 이미 잘 알려져 있어 신뢰도 높음. 나는 개인적으로 이 둘의 팬임. 내가 원하는 일을 정확히 해주니까 신뢰도가 높음
나도 Django를 정말 좋아함. 프로젝트를 엄청 빠르게 시작해 배포할 수 있음
정말로 ‘지루한 기술’을 고른다면 Postgres조차 한 번 더 생각해 볼 필요가 있음
Celery는 Django 프로젝트에서 꽤 자주 쓰는 편임. 복잡성이 마음에 들진 않지만, PaaS 환경에서는 오히려 제일 덜 고통스러운 선택임
"대부분의 앱은 SPA나 무거운 프론트엔드 프레임워크가 필요하지 않다"라는 주장과 "하나의 도구를 깊게 익혀라"는 조언이 충돌되는 것 같음
거친 초안으로 코드를 남겼을 때, 흔히 관리자가 그런 코드를 그대로 ‘최종 버전’으로 배포함
그래서 처음부터 robust한 코드로 씀. 심지어 테스트 하네스도 거의 배포 수준으로 견고하게 만듦
핵심은 아주 질 좋은 모듈을 만드는 것임. 변경 가능성이 매우 낮거나, 변경 시 엄청나게 큰 이슈가 되는 부분은 아예 독립적인 모듈로 격리해서 의존성 형태로 임포트함
이런 모듈 덕분에 새로운 앱을 매우 빠르게 개발할 수 있고, 품질도 계속 높게 유지 가능함
직접 사용한 예시는 RVS_Checkbox, ambiamara, RVS_Generic_Swift_Toolbox 등임
질문이 있는데, Swift에서 주석 마커로 "* ##################################################################" 같은 코드 패턴을 쓰는 게 표준인지 궁금함
프로젝트의 규모에 따라 접근 방식이 많이 달라짐
개인 프로젝트나 소규모 팀이라면 ‘빠르고 거칠게’ 개발하는 게 최적임. 이런 방식이 소규모 개발의 강점임
소규모에서는 버그가 생겨도 금방 고칠 수 있고, 팀원 모두가 전체 코드를 거의 완벽하게 이해하고 있음
규모가 커지면 아키텍처 실수나 버그 수정 비용이 폭증함. 아키텍처는 필연적으로 복잡해지고, 대규모 리팩토링은 사실상 불가능함. 이런 환경에선 한 단계 한 단계 정확성이 최우선이 되어야 함
맥락이 정말 중요함. ‘대규모’가 얼마만큼을 의미하는지는 다를 수 있지만, 내가 경험한 바로는 앱 간 API를 일찍 협의하여 프론트/백엔드 모두 빠르게 작업 환경을 갖추는 것이 항상 옳았음
이런 상황에서는 시스템을 축소해서 운영해야 함. 모두가 거대한 시스템을 원하기는 해도 실제로는 필요하지 않음
“24시간 게임잼에서는 코드 품질에 신경 쓸 필요 없다”는 말이 있는데, 내가 해본 대부분 해커톤/코드 리뷰 경험상, 가장 좋은 성과를 낸 팀들이 코드 품질이나 rudimentary한 테스트 환경도 같이 챙겼음
위 두 주장(빨리 하려면 코드 품질을 포기해야 한다 vs 좋은 성적팀일수록 품질이 높다)은 사실 상충하지 않음. 품질 좋은 팀이 꼭 코드 정갈함에만 매달렸던 건 아님
게임잼 사례에서는 코드의 깨끗함에 너무 집착하면 오히려 전체 결과물이 좋지 못함. UE blueprint 같은 시스템이 왜 ‘깔끔함’보다 결과물을 우선시해야 하는지 보여줌
어떤 사람들은 코드의 ‘청결함’을 전체적으로 평가하고, 다른 사람들은 불필요한 코드 개선의 세부적인 비용/효익을 평가함
“프로토타이핑을 해보면 예상 못 한 ‘unknown unknowns’가 드러난다”는 내용과는 달리, 내가 뭔가를 처음 만져볼 때는 항상 장점만 보이고 단점은 잘 보이지 않음
실제로는 엣지 케이스 처리, 유저에게 친절한 에러 메시지, 부작용 제거 등 실제 기능 완성 단계에서야 진짜 문제(unknown unknowns)가 드러남
아마도 내가 경험하는 unknown unknowns는 도구/프레임워크/라이브러리 자체에서 생기고, 저자는 문제 영역 자체에서의 unknown unknowns를 말하는 듯함
rough draft가 너무 거칠면 안 된다는 점도 맞음. 대충 넘어가면 안 되는 부분에서 진짜 문제가 터짐.
직접 쓸 도구를 만들 때는 대충 만들어도 무난하게 쓸 수 있는데, 그렇게 빠르게 만든 도구는 허점투성이여도 문제를 겪지 않음
요즘처럼 구조조정이 잦은 테크 업계가 소프트웨어 품질과 엔지니어 생산성의 가장 큰 위협임
해고의 불안감, 빠른 성과 압박은 창의성과 실험정신을 죽이고 번아웃을 유발함
모두가 AI 같은 유행 이슈에 군중심리로 휩쓸리고, 비판도 하지 못하는 환경이 되어버림
LLM 자동 코딩보다 더 시급한 문제임
항상 소프트웨어 품질의 최대 위협은 소비자가 품질을 위해 돈을 안 쓴다는 것임
프로그래밍 레벨의 벤더 락인이 실제로는 SaaS 락인보다 훨씬 파괴적임
24시간 게임잼 등 빠른 사이클에서 오히려 나쁜 코드는 치명적임을 느낌
코드가 깔끔할수록 실수도 줄어들고, 작업 기억 부담도 덜하며, 막판에 원하는 변경이나 기능 추가, 문제 수정이 훨씬 쉬워짐
24시간 프로젝트에서 가장 많이 일을 망치는 건, 코드를 느리게 쓴 게 아니라 자기 스스로 구석에 몰리거나 예측 불가한 문제에 부딪혀 탈선하는 것임
물론 모든 버그를 잡아야 한다는 건 아님. 하지만 기초 품질이 낮으면 전체적으로 힘든 프로젝트 경험임
시간이 더 많은 프로젝트에도 이 원칙은 적용됨. 시간이 많다고 대충 쓰는 게 나은 건 아님
좋은 코드를 습관화하면 추가 비용 없이 품질을 담보할 수 있음. 그리고, 시간이 더 들더라도 결국엔 가치 있는 일임
나도 같은 생각임. 여러 번 게임잼을 해봤지만, ‘엉성한 코드’는 마감 전 1-2시간에, 남이 안 건드릴 파일에 한해서만 허용함
빠르고 좋은 코드를 쓰려면 결국 많이 써보는 게 답임
급할 때 fancy한 asset loader 같은 건 신경 쓰지 않고 그냥 정적 파일로 때움
‘좋은 코드를 쓰는 게 더 오래 걸린다’는 인식이 오해라고 생각함. 일정 요구사항 이상을 맞추려면 좋은 코드가 속도에 장애물이 되지 않음
“어느 정도가 ‘good enough’냐”라는 기준이 팀마다 다 달라서 그게 내 커리어에서 가장 큰 갈등의 원인임
빅테크 출신은 테스트 미흡에 불만이고, 스타트업 출신은 속도가 느리다고 불만임
‘good enough’ 기준을 명확히 문서로 기록해서 팀 내에 공유하는 것이 유익할 것임
이게 바로 팀 차터, 즉 ‘우리가 일하는 방식’ 문서임
글에서 언급되지 않은 중요한 요소 중 하나는 시간에 따른 개발 속도 저하임
프로젝트와 팀 규모가 커지면 개발 속도는 자연스럽게 느려짐
즉각적인 개발 속도에 조금 손해를 보더라도 장기적으로 개발 속도가 덜 저하되도록 초기에 테스트, 문서화, 결정 로그, Agile 미팅 등 준비가 필요함
관찰성(observability) 같은 기능이나 테스트하기 쉬운 코드 구조를 미리 안 준비하면 나중에 엄청난 악영향이 남음
솔로 개발자지만, 결정 로그·테스트·문서화 세 가지의 중요성을 체감함
나에게도 익숙한 패턴임. rough draft, 혹은 아이디어 검증용으로 다른 스크립트 언어나 수동 실행을 묶은 작은 코드로 시작함