# 소프트웨어를 빠르게 개발하는 나만의 방법 > Clean Markdown view of GeekNews topic #21995. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=21995](https://news.hada.io/topic?id=21995) - GeekNews Markdown: [https://news.hada.io/topic/21995.md](https://news.hada.io/topic/21995.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-07-15T11:08:14+09:00 - Updated: 2025-07-15T11:08:14+09:00 - Original source: [evanhahn.com](https://evanhahn.com/how-i-build-software-quickly/) - Points: 80 - Comments: 2 ## Summary 소프트웨어 개발에서 **빠른 개발**과 **적정 품질**의 균형은 현실적으로 중요하며, 이를 위해 **러프 드래프트**로 전체 구조를 신속히 잡은 뒤, 점진적으로 다듬는 접근이 효과적임을 강조합니다. 개발 속도를 높이려면 **요구사항 완화**와 산만함을 피하는 **작은 단위의 커밋**, 그리고 팀의 ‘충분히 괜찮다’는 기준을 명확히 설정해야 함을 짚습니다. 특히 **코드 읽기**, **데이터 모델링**, **스크립팅** 같은 실전 스킬, 그리고 **디버거 활용**과 **LLM(대규모 언어 모델)** 등 도구의 적극적 사용이 실제 생산성 향상에 중요한 역할을 합니다. 이러한 접근법과 습관은 개발자에게 목표 내 **빠른 납기와 합리적 품질**을 동시에 달성하는 데 실질적 도움이 됩니다. ## Topic Body - **완벽함**과 **속도**의 균형은 쉽지 않지만, 상황에 맞는 **적정 품질**과 **기한 준수**가 중요함 - 초안(러프 드래프트) 개발을 먼저 진행하고, 이후에 코드 품질을 개선하는 방식이 효과적임 - **요구사항을 완화**하거나 과도한 요구를 줄이면 속도와 효율을 높일 수 있음 - **산만함을 피하고 작은 단위로 자주 커밋**하며, 핵심에 집중하는 습관이 필요함 - 빠른 개발에 도움이 된 **코드 읽기, 데이터 모델링, 스크립팅, 디버깅, 순수 함수 지향** 등의 구체적 스킬이 있음 --- ### “얼마나 좋은 코드여야 하는가?” – 품질 기준과 현실적 선택 - 초창기에는 **모든 코드가 완벽하길 원함** - 모든 함수가 철저히 테스트되고, 변수명이 우아하며, 추상화가 명확하고, **버그가 전혀 없는 코드**를 꿈꿨음 - 하지만 시간이 흐르며 **“정답은 없다”** 는 현실을 배움 - **상황에 따라 요구되는 코드 품질이 다름** - **24시간 게임잼**: 완성된 코드가 꼭 깔끔하거나 버그가 없어야 할 필요 없음 - 제한된 시간 내에 동작하는 결과물을 만드는 것이 더 중요함 - **심장박동기 소프트웨어**: 실수 하나가 사람의 생명을 위협할 수 있으므로 - **최고 수준의 신뢰성과 안전성**이 필수임 - 대부분의 프로젝트는 **이 두 극단 사이**에 존재함 - 어떤 회사는 **빠른 납기**를 요구해 약간의 버그는 허용함 - 어떤 프로젝트는 **높은 품질**을 요구하지만 일정이 넉넉함 - 실제 업무에서는 이 균형을 파악하는 능력이 중요함 - **팀의 ‘충분히 괜찮음(good enough)’ 기준이 무엇인지**를 먼저 파악함 - 허용 가능한 버그의 범위, 완벽하지 않아도 괜찮은 부분 등 실질적 기준을 함께 점검함 - 본인의 **개인적 기준**은 - **“10점 만점에 8점 품질을, 기한 내에 달성”** 하는 것 - 코드는 목적을 충실히 수행하고, 치명적인 문제는 없지만 사소한 이슈는 남아 있을 수 있음 - 가장 중요한 건 **기한 내에 제출**하는 것임 - 단, 이 기준도 **프로젝트의 맥락에 따라 유연하게 조정** - 때로는 완벽을 추구해 일정이 밀려도 괜찮고, - 때로는 완성도는 낮아도 일단 빠르게 끝내는 편이 더 가치 있을 때가 있음 ### Rough drafts – 러프 드래프트, 프로토타이핑의 실제적인 활용과 장점 - 소프트웨어 개발도 글쓰기처럼 **초안(rough draft, spike, walking skeleton)** 작성이 매우 유용함 - **최대한 빠르게 러프 드래프트를 구현**하고, 이후에 이를 다듬어 완성형 솔루션으로 발전시킴 - 나의 러프 드래프트 코드는 **버그 투성이**이고, 테스트 실패, TODO 주석 남발, 예외 미처리, print/log 남용, 성능 고려 없음, WIP 커밋 메시지, 불필요한 패키지 추가, 반복 코드, 하드코딩, 린터 경고 등 **엉망**임 - 이 과정이 비효율적으로 보이지만, **“최소한 문제의 본질을 파악할 수 있는 상태”** 에 도달하는 것이 목적임 - 당연히, 이런 초안 상태의 코드를 최종 배포로 내보내지 않으며, 실제 배포 전에는 반드시 정제함 (팀에서 초안 코드를 그대로 내보내자고 압박할 때도 있지만 최대한 저항함) - # 러프 드래프트 접근법의 주요 장점 - **“알려지지 않은 문제(unknown unknowns)”를 빨리 드러냄** - 완성된 후 버려지는 코드보다, 초기에 프로토타입 단계에서 미지의 장애물을 찾는 것이 훨씬 유리함 - **프로토타입 작성 중 자연스럽게 사라지는 문제들이 많음** - 느린 함수나 잘못된 구조도, 나중에 아예 필요 없게 되는 경우가 많아 시간 낭비를 막을 수 있음 - 지나치게 일찍 최적화나 테스트에 힘 쏟을 필요 없음 - **집중력을 높여줌** - 불필요한 리팩터링, 네이밍 고민, 다른 코드베이스 고치기 등 산만함을 방지하고 오직 현재 해결해야 하는 문제에 몰입할 수 있음 - **불필요한 조기 추상화 방지** - 일단 동작하는 해답을 빠르게 만드는 과정에서는 미래를 위한 불필요한 추상화를 덜 시도하게 됨 - 당장의 문제에만 집중하여, 불필요하게 복잡한 설계를 피함 - **진척 상황의 명확한 소통** - 러프 드래프트를 통해 앞으로 얼마나 남았는지 정확한 예측이 가능해짐 - 무엇이든 동작하는 것을 먼저 보여주며, 이해관계자의 피드백과 방향성 변경이 빠르게 이뤄짐 - # 러프 드래프트 실전 운영법 - **되돌리기 어려운 결정(biding decision)은 초안 단계에서 반드시 실험** - 예: 언어, 프레임워크, DB스키마 등 큰 방향성은 초기에 확인 - **모든 임시방편/핵(hack)은 반드시 TODO 주석 등으로 기록** - polish(정제) 단계에서 `git grep TODO` 등으로 전수 조사해 보완함 - **Top-Down(상위-하위) 순서로 개발** - UI, API 등 사용 방식부터 scaffold(뼈대) 작성, 내부 로직은 하드코딩/임시 구현도 허용 - 실제로는 UI/사용 경험이 정해지면서 하위 로직이 바뀌는 일이 많으므로, 상위 레이어부터 구현이 유리함 - 하위부터 완벽히 구현 후 상위에 맞추는 방식은 비효율적임 - **작은 변화는 따로 패치 분리** - 러프 드래프트 도중 코드베이스 개선이나 의존성 업데이트 필요성을 발견하면, 해당 부분만 별도 PR/커밋으로 분리해서 빠르게 반영 - 전체 변경의 복잡도를 줄이고, 리뷰/통합 속도를 높임 > _참고: “[코드의 첫 번째 초안은 버려라](https://ntietz.com/blog/throw-away-your-first-draft/)”, “[지금 당장 단순한 시스템이 최고](https://dannorth.net/best-simple-system-for-now/)”, “[YAGNI(You Aren’t Gonna Need It)](https://martinfowler.com/bliki/Yagni.html)”_ ### 요구사항을 바꿔보려는 시도 - **덜 하는 것이 더 빠르고 쉽다**는 원칙을 강조함 - 실제 업무에서, 주어진 과업의 **요구사항을 완화할 수 있는지 항상 고민**함 - 예시 질문: - 여러 화면을 하나로 합칠 수 있는가? - 까다로운 엣지 케이스를 굳이 다뤄야 하는가? - 1000개 입력을 지원해야 한다면 10개만 지원해도 되는가? - 완성형 대신 프로토타입으로 대체 가능한가? - _이 기능 자체를 빼버려도 되는가?_ - 이러한 접근은 개발 속도와 효율을 높임 - 조직 문화 자체도 **조금씩 더 느리고 합리적인 페이스로 유도**하려고 시도함 - 갑작스럽고 큰 변화 요구는 잘 먹히지 않음 - 점진적인 제안, 토론 방식 전환 등으로 조금씩 분위기를 바꿈 ### 코드에서 산만함(Distraction) 피하기 - 외부 환경(알림, 회의) 뿐 아니라, **코드 작업 중 엉뚱한 일로 새는 것**도 큰 방해 요인임 - 나도 종종 버그를 고치다 전혀 상관 없는 곳을 뜯고 있고, 결국 원래 과제는 미루어짐 - 두 가지 구체적 실천법: - **타이머 설정**: 한 작업마다 시간 제한을 두고, 알람이 울리면 현재 진행 상황을 점검 - 예상보다 시간이 더 걸릴 때 주의 환기 효과 있음 - 알람과 동시에 git commit 하면 작은 성취감도 생김 - (이 방법은 시간 추정 연습에도 효과적임) - **페어 프로그래밍**: 함께 작업하면 쓸데없는 길로 새는 일 감소, 집중력 유지에 도움됨 - 일부 개발자에겐 이런 산만함 회피가 자연스럽지만, 내겐 **의식적 집중과 습관화**가 필요함 ### 작은 단위의 변경, 작게 쪼개기 - 예전에 **큰 단위의 패치, 광범위한 변경**을 장려하는 상사가 있었지만 실제로는 매우 비효율적임을 경험함 - **작고 집중된 diff**가 거의 항상 더 낫다고 느낌 - 코드를 작성하는 데 부담이 적고 - 코드 리뷰가 더 쉽고 빨라져 동료의 피로감도 줄고, 내 실수도 쉽게 발견됨 - 문제가 생겼을 때 롤백이 쉽고 안전함 - 한 번에 바꾸는 범위가 작으므로 신규 버그 발생 위험도 감소함 - **큰 기능/기능 추가도 작은 변경의 축적으로 완성** - 예: 화면 추가가 필요하다면, 버그 수정/의존성 업그레이드/기능 추가를 각각 별도 패치로 분리 - **작은 단위의 변화**가 더 빠르고 높은 품질의 소프트웨어 개발에 도움이 된다고 강조함 ### 빠른 개발에 정말 도움이 된 구체적인 스킬들 위에서 언급한 내용들은 다소 추상적이지만, **실제로 빠른 개발에 효과적인 실전 스킬**도 존재함 - # 코드 읽기(Reading code) : 지금까지 습득한 **가장 중요한 개발자 역량**임 - 기존 코드를 능숙하게 해석할 수 있으면, **디버깅**이 훨씬 쉬워지고 - 오픈소스/서드파티 라이브러리의 버그나 부족한 문서도 크게 두렵지 않게 됨 - 타인의 코드를 읽으며 배우는 양도 엄청나고, 전반적인 문제 해결 능력 향상에 직접적 도움을 줌 - # 데이터 모델링(Data modeling) : 시간이 걸려도 **데이터 모델을 제대로 설계**하는 것이 중요함 - 잘못 설계된 데이터베이스 스키마는 나중에 다양한 문제와 복잡한 수정 비용을 초래함 - **유효하지 않은 상태 자체를 아예 표현할 수 없도록** 설계하는 것이 버그를 원천적으로 줄임 - 데이터가 저장되거나 외부와 주고받는 경우엔 더더욱 신중해야 함 - # 스크립팅(Scripting) : Bash, Python 등으로 **짧은 스크립트를 빠르게 작성하는 능력**은 개발 효율을 극대화함 - 매주 여러 번씩, 마크다운 정렬, 데이터 정리, 파일 중복 찾기 등 자동화 작업에 활용 - Bash는 [Shellcheck](https://www.shellcheck.net/) 같은 도구로 문법 오류를 사전에 예방함 - Robust하지 않아도 되는 작업엔 LLM의 도움을 받아 빠르게 완성 가능 - # 디버거(Debuggers) 활용 : **디버거 사용**은 print/log만으로는 불가능한 신속한 문제 진단과 코드 흐름 파악에 필수적임 - 복잡한 버그의 근본 원인 파악이 훨씬 빨라짐 - # 적절히 쉬는 타이밍 : **막힐 때는 과감하게 휴식**을 취하는 습관 - 장시간 고생해도 못 푸는 문제가, 5분 쉬었다가 바로 풀리는 경험이 빈번함 - 집중의 효율성을 위해서도 중요함 - # 순수 함수와 불변 데이터 지향 : **함수형 프로그래밍**: 순수 함수와 immutable data를 선호하면 - 버그 감소, 상태 추적 부담 감소, 코드의 명확성/예측성 증가 - 복잡한 클래스 계층 설계보다 더 단순하고 효과적인 경우가 많음 - 반드시 항상 가능한 건 아니지만, 기본적으로 이 방식을 먼저 고려함 - # LLM(대규모 언어 모델) 활용 : **LLM(예: ChatGPT 등)** 은 단점도 있지만, 반복적이거나 자동화가 가능한 개발 업무에서 큰 속도 향상을 가져옴 - 자신의 코드에 LLM을 접목하는 방법과 한계를 충분히 이해한 뒤 적극 활용 중 - 커뮤니티의 다양한 경험과 팁, 사례도 참고함 **이 모든 스킬들은 오랜 시간 반복적으로 연습해왔고, 실제로 빠른 개발에 큰 자산이 되었음** ### 요약 - 내가 소프트웨어를 빠르게 개발하며 얻은 핵심 교훈은 다음과 같음 - **과제별로 필요한 코드 품질 기준을 명확히 파악** - **러프 드래프트(초안)를 빠르게 작성**해 전체 윤곽을 잡음 - **요구사항을 완화**할 수 있는 여지를 항상 탐색 - **산만함에 휘둘리지 않고** 집중력을 유지 - **변경은 작고 자주** 커밋하며, 큰 패치는 피함 - **구체적 실전 스킬**(코드 읽기, 데이터 모델링, 디버깅, 스크립팅 등)을 꾸준히 연습 - 모두 너무 당연해 보이지만, 실제로 이 교훈을 얻기까지 오랜 시간이 걸렸음 ## Comments ### Comment 41438 - Author: nicewook - Created: 2025-07-15T17:05:05+09:00 - Points: 1 공감가는 이야기가 많네요. 댓글들도 좋은데 이렇게 누군가가 정리하여 말하면, 그래서 자리를 깔아주면, 그에 대해 반론과 지지, 보충을 거쳐 더 완성된다 싶습니다. 덧. "지루한 기술" 이라는 표현을 최근에 자주 보는데 영어로는 boring technology 군요. ### Comment 41417 - Author: neo - Created: 2025-07-15T11:08:14+09:00 - Points: 3 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44557115) - 최근 몇 년간 빠르고 충분히 견고한 시스템을 구축하는 방법을 터득함 - 한 가지 도구를 깊이 익히는 것이 중요함을 배움. 표면적으로 더 적합해 보이는 도구보다 내가 잘 아는 것이 훨씬 효율적임. 실제로 대부분의 프로젝트에서 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](https://github.com/RiftValleySoftware/RVS_Checkbox), [ambiamara](https://github.com/RiftValleySoftware/ambiamara), [RVS_Generic_Swift_Toolbox](https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...) 등임 - 질문이 있는데, 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’ 기준을 명확히 문서로 기록해서 팀 내에 공유하는 것이 유익할 것임 - 이게 바로 팀 차터, 즉 ‘우리가 일하는 방식’ 문서임 - [팀 차터 샘플](https://asana.com/resources/team-charter-template) 참고 가능함 - 글에서 언급되지 않은 중요한 요소 중 하나는 시간에 따른 개발 속도 저하임 - 프로젝트와 팀 규모가 커지면 개발 속도는 자연스럽게 느려짐 - 즉각적인 개발 속도에 조금 손해를 보더라도 장기적으로 개발 속도가 덜 저하되도록 초기에 테스트, 문서화, 결정 로그, Agile 미팅 등 준비가 필요함 - 관찰성(observability) 같은 기능이나 테스트하기 쉬운 코드 구조를 미리 안 준비하면 나중에 엄청난 악영향이 남음 - 솔로 개발자지만, 결정 로그·테스트·문서화 세 가지의 중요성을 체감함 - 나는 “랩 노트북”이라고 부르는 실시간 설계 기록을 작성하는데, 이게 나중에 테스트와 문서화의 밑바탕이 됨 - 랩 노트북 있으면 늦게 시작해도 더 좋은 문서를 빠르게 쓸 수 있음. 테스트는 설계가 변하지 않았는지 검증에도 도움이 됨 - 아주 짧게 쓸 일회성 도구는 그냥 막 시작해도 되지만, 오래 쓸 시스템은 천천히라도 기초를 단단히 쌓는 게 결국 합리적이고 유지보수 가능한 결과를 줌 - 별로 인기 없는 의견이지만, 설계는 먼저 종이에서 해보고 그 다음에 디지털로 옮기는 게 효과적임 - 나에게도 익숙한 패턴임. rough draft, 혹은 아이디어 검증용으로 다른 스크립트 언어나 수동 실행을 묶은 작은 코드로 시작함 - 이런 과정을 거쳐 오히려 “우리가 원하던 걸 만들 필요가 없겠다”는 결론에 도달할 때도 많았음 - 코딩하다 집중이 흐트러지는 부분에 정말 공감함. 정리하다보면 토끼굴에 빠져 커밋 단위가 커져 동료들이 리뷰하기 힘든 상태가 됨. 결국엔 작업을 모두 폐기하고 다시 작게, 목적에 집중해서 진행하는 경우가 많음 - 때로는 쓸 만한 조각만 따로 빼서 다른 PR로 올릴 수 있음 - 비즈니스는 결과물을 빠르게 원하고, 코드의 트레이드오프를 debt가 산더미처럼 쌓여 아주 느린 개발 속도를 경험하기 전까지는 이해하지 못함 - 중요한 것은 균형이고, 프로젝트마다 다른 기준이 적용될 수 있음 - 그래서 작은, 집중된, 간단한 변경만 자주 하는 것이 도움이 됨 - 하지만 큰 해결책을 작은 조각으로 나누는 게 생각만큼 쉽지 않음 - 아무 관련 없는, 쓰이지도 않는 코드를 ‘나중에 필요할 것’이라는 이유로 커밋하는 경우를 자주 보는데, 결국 우선순위 변경·사람 이동 등으로 1년 뒤엔 그 모든 게 쓸데 없는 코드가 되고, 그 당시의 계획도 아무도 알지 못해 버리게 됨