조기 최적화(Premature Optimization)의 함정

인디 해커로서 서비스를 빌드할 때 가장 경계해야 할 것 중 하나가 바로 ‘조기 최적화’입니다. 제품이 시장에 나오기도 전에 완벽한 아키텍처를 설계하고, 모든 기능을 자동화하려고 들면 정작 중요한 ‘비즈니스 로직’을 놓치게 됩니다.

저는 최근 디스코드 알림 봇 기능을 구현하며 다시 한번 이 진리를 깨달았습니다. 초기 설계 단계에서 저는 모든 알림 형식을 아우르는 거대한 추상화 인터페이스를 만들지 않았습니다. 대신, 필요한 순간마다 함수를 하나씩 ‘복제’해서 사용했습니다.

경험적 설계: 4번의 반복이 주는 데이터

다양한 포맷의 디스코드 전송 함수를 작성하며 저는 일종의 ‘수동 반복 테스트’를 진행한 셈이 되었습니다.

• Type A: 단순 텍스트 알림
• Type B: 필드(Field)가 포함된 임베드(Embed) 알림
• Type C: 이미지와 링크가 포함된 리포트형 알림
• Type D: 에러 트래킹용 긴급 알림

이렇게 4개째 함수를 만들고 나서야 저는 공통된 패턴을 발견했습니다. 어떤 부분이 변수(Variable)이고 어떤 부분이 상수(Constant)인지가 명확해진 것이죠. 만약 제가 1번째 함수를 만들 때부터 자동화를 고민했다면, 나중에 추가될 Type D의 요구사항을 반영하지 못해 코드를 갈아엎어야 했을 겁니다.

효율에 대한 갈망은 결핍에서 나온다

인간은 본능적으로 에너지를 아끼려는 성향이 있습니다. 그리고 이 성향은 ‘결핍’과 ‘고통’을 느낄 때 극대화됩니다.

코드를 복사해서 붙여넣고, 오타를 수정하고, API 엔드포인트를 다시 확인하는 그 비효율적인 과정이 반복될 때, 빌더의 뇌에서는 강력한 ‘효율에 대한 갈망’이 발생합니다. “이대로는 안 되겠다”라는 절박함이 생길 때 나오는 코드가 진짜 살아있는 코드이고, 유지보수가 쉬운 코드입니다.

비효율적인 과정을 미리 찾아내려고 애쓰지 마십시오. 오히려 비효율적으로 일을 많이 해보십시오. 그것이 효율적인 시스템을 만드는 가장 빠른 길입니다.

빌더를 위한 리팩토링 원칙

• Rule of Three (or Four): 같은 일을 3번까지는 수동으로 하되, 4번째에는 반드시 자동화하거나 함수를 분리하십시오.
• 비효율의 가치: 수동 작업은 시스템의 요구사항을 가장 정확하게 파악하게 해주는 ‘리서치’ 기간입니다.
• 고통을 지표로 삼기: “아, 진짜 하기 싫다”라는 생각이 드는 지점이 바로 자동화가 필요한 포인트입니다.

💡 Tip: 코드를 분리할 때는 먼저 ‘변하지 않는 것’부터 묶으세요. 디스코드 전송의 경우 웹훅 URL과 Axios 설정이 그 첫 번째 대상입니다.