소프트웨어를 빠르게 개발하는 나만의 방법

• 완벽함과 속도의 균형은 쉽지 않지만, 상황에 맞는 적정 품질과 기한 준수가 중요함
• 초안(러프 드래프트) 개발을 먼저 진행하고, 이후에 코드 품질을 개선하는 방식이 효과적임
• 요구사항을 완화하거나 과도한 요구를 줄이면 속도와 효율을 높일 수 있음
• 산만함을 피하고 작은 단위로 자주 커밋하며, 핵심에 집중하는 습관이 필요함
• 빠른 개발에 도움이 된 코드 읽기, 데이터 모델링, 스크립팅, 디버깅, 순수 함수 지향 등의 구체적 스킬이 있음

---

“얼마나 좋은 코드여야 하는가?” – 품질 기준과 현실적 선택

• 초창기에는 모든 코드가 완벽하길 원함
  • 모든 함수가 철저히 테스트되고, 변수명이 우아하며, 추상화가 명확하고, 버그가 전혀 없는 코드를 꿈꿨음
• 하지만 시간이 흐르며 “정답은 없다” 는 현실을 배움
  • 상황에 따라 요구되는 코드 품질이 다름
  • 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/커밋으로 분리해서 빠르게 반영
    • 전체 변경의 복잡도를 줄이고, 리뷰/통합 속도를 높임

참고: “코드의 첫 번째 초안은 버려라”, “지금 당장 단순한 시스템이 최고”, “YAGNI(You Aren’t Gonna Need It)”

요구사항을 바꿔보려는 시도

• 덜 하는 것이 더 빠르고 쉽다는 원칙을 강조함
• 실제 업무에서, 주어진 과업의 요구사항을 완화할 수 있는지 항상 고민함
  • 예시 질문:
    • 여러 화면을 하나로 합칠 수 있는가?
    • 까다로운 엣지 케이스를 굳이 다뤄야 하는가?
    • 1000개 입력을 지원해야 한다면 10개만 지원해도 되는가?
    • 완성형 대신 프로토타입으로 대체 가능한가?
    • 이 기능 자체를 빼버려도 되는가?
• 이러한 접근은 개발 속도와 효율을 높임
• 조직 문화 자체도 조금씩 더 느리고 합리적인 페이스로 유도하려고 시도함
  • 갑작스럽고 큰 변화 요구는 잘 먹히지 않음
  • 점진적인 제안, 토론 방식 전환 등으로 조금씩 분위기를 바꿈

코드에서 산만함(Distraction) 피하기

• 외부 환경(알림, 회의) 뿐 아니라, 코드 작업 중 엉뚱한 일로 새는 것도 큰 방해 요인임
• 나도 종종 버그를 고치다 전혀 상관 없는 곳을 뜯고 있고, 결국 원래 과제는 미루어짐
• 두 가지 구체적 실천법:
  • 타이머 설정: 한 작업마다 시간 제한을 두고, 알람이 울리면 현재 진행 상황을 점검
    • 예상보다 시간이 더 걸릴 때 주의 환기 효과 있음
    • 알람과 동시에 git commit 하면 작은 성취감도 생김
    • (이 방법은 시간 추정 연습에도 효과적임)
  • 페어 프로그래밍: 함께 작업하면 쓸데없는 길로 새는 일 감소, 집중력 유지에 도움됨
• 일부 개발자에겐 이런 산만함 회피가 자연스럽지만, 내겐 의식적 집중과 습관화가 필요함

작은 단위의 변경, 작게 쪼개기

• 예전에 큰 단위의 패치, 광범위한 변경을 장려하는 상사가 있었지만
  실제로는 매우 비효율적임을 경험함
• 작고 집중된 diff가 거의 항상 더 낫다고 느낌
  • 코드를 작성하는 데 부담이 적고
  • 코드 리뷰가 더 쉽고 빨라져 동료의 피로감도 줄고, 내 실수도 쉽게 발견됨
  • 문제가 생겼을 때 롤백이 쉽고 안전함
  • 한 번에 바꾸는 범위가 작으므로 신규 버그 발생 위험도 감소함
• 큰 기능/기능 추가도 작은 변경의 축적으로 완성
  • 예: 화면 추가가 필요하다면, 버그 수정/의존성 업그레이드/기능 추가를 각각 별도 패치로 분리
• 작은 단위의 변화가 더 빠르고 높은 품질의 소프트웨어 개발에 도움이 된다고 강조함

빠른 개발에 정말 도움이 된 구체적인 스킬들

위에서 언급한 내용들은 다소 추상적이지만, 실제로 빠른 개발에 효과적인 실전 스킬도 존재함

• 코드 읽기(Reading code) : 지금까지 습득한 가장 중요한 개발자 역량임

  • 기존 코드를 능숙하게 해석할 수 있으면, 디버깅이 훨씬 쉬워지고
  • 오픈소스/서드파티 라이브러리의 버그나 부족한 문서도 크게 두렵지 않게 됨
  • 타인의 코드를 읽으며 배우는 양도 엄청나고, 전반적인 문제 해결 능력 향상에 직접적 도움을 줌

• 데이터 모델링(Data modeling) : 시간이 걸려도 데이터 모델을 제대로 설계하는 것이 중요함

  • 잘못 설계된 데이터베이스 스키마는 나중에 다양한 문제와 복잡한 수정 비용을 초래함
  • 유효하지 않은 상태 자체를 아예 표현할 수 없도록 설계하는 것이 버그를 원천적으로 줄임
  • 데이터가 저장되거나 외부와 주고받는 경우엔 더더욱 신중해야 함

• 스크립팅(Scripting) : Bash, Python 등으로 짧은 스크립트를 빠르게 작성하는 능력은 개발 효율을 극대화함

  • 매주 여러 번씩, 마크다운 정렬, 데이터 정리, 파일 중복 찾기 등 자동화 작업에 활용
  • Bash는 Shellcheck 같은 도구로 문법 오류를 사전에 예방함
  • Robust하지 않아도 되는 작업엔 LLM의 도움을 받아 빠르게 완성 가능

• 디버거(Debuggers) 활용 : 디버거 사용은 print/log만으로는 불가능한 신속한 문제 진단과 코드 흐름 파악에 필수적임

  • 복잡한 버그의 근본 원인 파악이 훨씬 빨라짐

• 적절히 쉬는 타이밍 : 막힐 때는 과감하게 휴식을 취하는 습관

  • 장시간 고생해도 못 푸는 문제가, 5분 쉬었다가 바로 풀리는 경험이 빈번함
  • 집중의 효율성을 위해서도 중요함

• 순수 함수와 불변 데이터 지향 : 함수형 프로그래밍: 순수 함수와 immutable data를 선호하면

  • 버그 감소, 상태 추적 부담 감소, 코드의 명확성/예측성 증가
  • 복잡한 클래스 계층 설계보다 더 단순하고 효과적인 경우가 많음
  • 반드시 항상 가능한 건 아니지만, 기본적으로 이 방식을 먼저 고려함

• LLM(대규모 언어 모델) 활용 : LLM(예: ChatGPT 등) 은 단점도 있지만, 반복적이거나 자동화가 가능한 개발 업무에서 큰 속도 향상을 가져옴

  • 자신의 코드에 LLM을 접목하는 방법과 한계를 충분히 이해한 뒤 적극 활용 중
  • 커뮤니티의 다양한 경험과 팁, 사례도 참고함
    이 모든 스킬들은 오랜 시간 반복적으로 연습해왔고, 실제로 빠른 개발에 큰 자산이 되었음

요약

• 내가 소프트웨어를 빠르게 개발하며 얻은 핵심 교훈은 다음과 같음
  • 과제별로 필요한 코드 품질 기준을 명확히 파악
  • 러프 드래프트(초안)를 빠르게 작성해 전체 윤곽을 잡음
  • 요구사항을 완화할 수 있는 여지를 항상 탐색
  • 산만함에 휘둘리지 않고 집중력을 유지
  • 변경은 작고 자주 커밋하며, 큰 패치는 피함
  • 구체적 실전 스킬(코드 읽기, 데이터 모델링, 디버깅, 스크립팅 등)을 꾸준히 연습
• 모두 너무 당연해 보이지만, 실제로 이 교훈을 얻기까지 오랜 시간이 걸렸음

[nicewook]

공감가는 이야기가 많네요.
댓글들도 좋은데 이렇게 누군가가 정리하여 말하면, 그래서 자리를 깔아주면, 그에 대해 반론과 지지, 보충을 거쳐 더 완성된다 싶습니다.

덧. "지루한 기술" 이라는 표현을 최근에 자주 보는데 영어로는 boring technology 군요.

[GN⁺]

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년 뒤엔 그 모든 게 쓸데 없는 코드가 되고, 그 당시의 계획도 아무도 알지 못해 버리게 됨