▲

대규모 기술 프로젝트를 구축하는 나만의 접근법 (2023)

 (mitchellh.com)
4P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 대규모 기술 프로젝트를 진행하면서 동기 부여를 유지하고 완주하는 데에는 일상적인 가시적 결과가 중요함
  • 프로젝트를 크고 모호한 단위가 아닌, 눈에 보이는 작은 단위로 쪼개고, 각 단계마다 실질적인 진행 상황을 확인할 수 있는 방법을 선택함
  • 초기 단계에서는 긴밀한 피드백 루프로 빠르게 데모를 만드는 것이 몰입과 자기 동기 부여에 큰 도움이 됨
  • 자신만을 위해 필요한 기능 위주로 먼저 개발하고, 실제 사용을 통해 계속 보완해나가는 방식이 효과적임
  • 완벽함보다 진전을 중시하며, 작게 성공하는 경험을 반복적으로 확보하는 것이 긴 프로젝트의 완주로 이어짐

시작점에서

  • 대규모 프로젝트를 시작할 때 가장 큰 고비는 어디서부터 시작하는지 결정하는 부분임
  • 모든 구성 요소를 한 번에 고려하면 너무 막연해 흥미를 잃기 쉬움
  • 실질적으로 빠른 결과를 볼 수 있는 작은 단위부터 착수하는 것이 중요함
  • 각 서브 프로젝트는 독립적이며, 뚜렷한 완료의 징후를 제공해야 함
  • 경험이 많을수록 프로젝트의 대략적인 모양새와 서브컴포넌트를 더 잘 파악할 수 있음

초기 결과 만들기

  • 초기 작업은 겉으로 드러나는 부분이 적어 진척이 보이지 않을 수 있음
  • 이럴 때 자동화된 테스트(예: 유닛 테스트) 를 적절히 활용해 가시적인 결과를 얻는 것이 중요함
  • 예를 들어 터미널 파서를 만들 때, 입력 문자열에 대한 파싱 결과를 테스트로 바로 확인함
  • 반복적으로 테스트가 통과하는 경험 자체가 성취감을 줌
  • 이러한 작은 성공을 통해 전체 프로젝트 진행에 대한 객관적 증거를 계속 쌓을 수 있음

빠르게 데모 만들기

  • 초기 목표는 완벽한 서브컴포넌트가 아니라 데모를 위한 충분한 구현임
  • 장기적으로 필요한 복잡성(예: 데이터베이스, 고급 자료구조 등)은 일단 미뤄두고 간단한 구현으로 빠른 전진을 최우선 함
  • '완벽은 진전을 방해하는 적이 될 수 있음' 을 항상 유념함
  • 일주일에 한두 번씩 간단한 데모 제작을 목표로 함
  • 불완전한 데모라도 직접 확인하며 직관적 피드백을 받을 수 있고, 이는 동기 부여에 크게 기여함

나 자신을 위한 개발

  • 특히 개인 프로젝트에서는 본인이 필요로 하는 기능부터 구현하며, 이를 스스로 채택해 사용해보는 과정을 중요시함
  • 직접 쓰면서 부족한 점을 체감하고, 실제로 필요한 기능에 집중하여 개선하며 진짜 사용자 입장에서 프로젝트를 발전시킴
  • 사용 초기에는 불편이나 버그가 드러나지만, 이는 다음 할 일을 명확하게 알려줌
  • 본인이 쓴 소프트웨어를 사용하는 자부심이 프로젝트 지속을 돕는 요인이 됨
  • 처음엔 불필요한 기능(스크롤, 마우스 선택, 탭 등)을 모두 생략함

프로젝트 전체를 패키징하는 방법

  • 전체 문제를 눈에 보이는 작은 문제로 쪼갬. 각 문제는 실질적인 결과를 확인할 수 있어야 함
  • 각 작은 문제는 데모 제작을 위한 충분한 수준까지만 해결하고 다음 문제로 넘어감
  • 가능한 빨리 작동하는 데모를 만들고, 이후 기능을 반복적으로 추가함
  • 우선적으로 본인 사용에 의미 있는 기능을 구현함
  • 필요시 각 컴포넌트를 반복적으로 개선하며 이 과정을 순환함

결론

  • 위의 방식을 통해 개인, 그룹, 업무, 학업 등 다양한 프로젝트에서 스스로 동기를 부여하며 완주함
  • 배포나 툴링보다는 실제로 어떤 방식이 지속적인 동기 유지를 가능하게 하는지에 초점을 둠
  • 모든 사람에게 같은 방법이 맞지는 않지만, 눈에 보이는 진행 결과가 장기 프로젝트 완주에 가장 큰 힘이 됨
  • 본인의 흥미와 동기 부여 방식을 이해하고 그에 맞는 작업 프로세스를 구축하는 것이 중요함
▲
GN⁺ 3일전  [-]
Hacker News 의견
  • 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도 분명 대형 프로젝트에 해당함
  • 나에게 있어서는 그냥 시작하는 게 최고의 방법임
    큰 프로젝트를 보면서 분석 마비에 빠지는 사람들이 정말 많음
    • 일단 시작은 쉬움
      정말 어려운 건 끝내는 것임
  • 이전 글: My approach to building large technical projects (2023년 6월, 27개 댓글)
  • 특히 'Build for Yourself' 부분이 인상적임
    직접 사용할 소프트웨어를 만들면 내 문제를 스스로 해결할 수 있음
    내가 직접 써보면서 소프트웨어 버그도 발견할 수 있음
    실제로 웹 서버를 직접 만들며 사용하다 여러 버그를 찾았음
  • 이게 바로 애자일이 지향해야 하는 방식임
    집중적이고, 반복적이며, 항상 동작하는 결과물을 지향하는 개발 문화임
답변달기