왜 “Busywork”가 창의성을 죽이는가, 내가 실험하려고 할 때

Source: Dev.to

The Problem

새로운 아이디어를 실험하거나 개인용으로 작은 무언가를 만들 때, 모멘텀을 가장 빨리 죽이는 것은 버그나 누락된 기능이 아니라 바쁜 일(busywork)이다.

전형적인 바쁜 일에는:

• 같은 폴더 구조를 반복해서 다시 만들기
• “정리된 느낌”을 주기 위해 파일 이름 바꾸기
• 논리 코드를 한 줄도 쓰기 전에 설정에 20분 소비하기

Frameworks vs. Freeform

Flask나 Django 같은 프레임워크는 CLI 스캐폴딩으로 이 문제를 꽤 잘 해결한다. 명령 하나만 실행하면 실제 문제에 집중할 수 있다.

하지만 프레임워크 밖으로 나와 작은 스크립트, 사이드 툴을 만들거나 아이디어를 탐색할 때는 그 안전망이 사라진다. 갑자기 실험 대신 설정 작업을 하게 된다.

My Approach

내게 도움이 된 것은 폴더 구조를 창의적인 작업 자체가 아니라 지원 인프라로 취급하는 것이었다. 유지 보수성은 여전히 중요하지만, 구조 결정이 호기심을 가로막게 하고 싶지는 않다.

실험할 때 나는 다음을 시도한다:

1. 최소하고 예측 가능한 레이아웃으로 시작 – 과도하게 설계하지 않으면서도 충분히 정리된 상태 유지.
2. 한 번만 기록 (문서나 노트에)하고, 처음부터 다시 만들지 않기.
3. 아이디어가 유용하다고 입증된 뒤에 구조 조정 – 실험이 유지 보수가 필요한 수준으로 성장했을 때만 리팩터링한다.

Conclusion

내게는 유지 보수성이 가장 중요한 것은 실험이 끝난 뒤에도 살아남을 때이다. 그때까지 마찰을 줄이는 것이 창의성을 유지하고 설정 작업에 지치지 않게 해준다.

프레임워크 밖에서 작업할 때 다른 사람들은 어떻게 다루는지 궁금합니다.