죄책감 없이 자신을 선택하기: 개발자로서 힘들게 배운 교훈

Source: Dev.to

Introduction

나는 좋은 개발자들은 모든 일에 “예”라고 답하고—빠른 해결책이 실제로는 빠르지 않으며, “아니오”라고 말하는 것이 무책임하게 느껴지고, 자신을 선택하는 것이 이기적이라고 생각했다. 번아웃, 마감일 놓침, 그리고 조용히 사라지는 동기부여가 나에게 불편한 진실을 직시하게 만들었다.

The Backstory (Why This Matters)

• 더 빨리 배우고, 더 많은 존경을 받으며, 결국 자신감이 생길 거라 믿었다.
• 그래서 나는 끊임없이 과도하게 약속했다: 추가 티켓, 추가 컨텍스트 스위칭, 추가 감정 노동.

The Core Idea

자신을 선택하는 것은 일을 덜 하는 것이 아니다.

• 우리는 서버를 100 % CPU로 영원히 실행하지 않는다.
• 시스템을 보호하기 위해 레이트 리밋을 추가한다.
• 완벽보다는 실패에 대비해 설계한다.

우리 자신에게도 같은 원칙이 적용된다.

Implementation: What “Choosing Yourself” Looked Like in Practice

Setting Boundaries Like You Set API Contracts

나는 내 시간을 인터페이스처럼 다루기 시작했다:

• 명확한 기대치
• 명시적인 한계
• 숨겨진 부작용 없음

“물론, 나도 그걸 처리할 수 있어” 대신에 “도와줄 수는 있지만 오늘은 안 돼. 현재 용량이 꽉 찼어.” 라고 말했다. 어색했지만 아무것도 깨지지 않았다.

Reducing Context Switching (On Purpose)

나는 다음과 같은 상황을 발견했다:

• 여러 팀을 돕고 있음
• 관련 없는 작업을 동시에 처리함
• 깊은 작업을 끝내지 못함

그래서 나는 “열린 스레드”를 제한하고, 더 적은 수의 고영향 아이템에 집중했다.

Stopping the Hero Mentality

항상 하루를 구하는 사람이 될 필요는 없었다.

• 없어서는 안 될 존재는 깨지기 쉬운 아키텍처다.
• 문서를 더 많이 작성하고, 위임을 늘리며, 다른 사람을 더 신뢰했다.

팀은 무너지지 않았고, 오히려 더 건강해졌다.

What Went Wrong (Lessons Learned)

• 동기가 사라졌다.
• 학습이 무겁게 느껴졌다.
• “쉬운” 작업조차도 지치게 만들었다.

나는 죄책감이 종종 지연 지표라는 것을 깨달았다—마치 장애가 발생한 뒤에야 확인하는 로그처럼.

Best Practices (Developer Edition)

• 에너지를 제한된 자원처럼 다뤄라.
• 당신을 소모시키는 작업에 “타임아웃”을 추가하라.
• 약속을 기술 부채처럼 검토하라.
• 단기 산출량보다 장기 처리량에 최적화하라.

지속 가능한 개발자는 더 좋은 코드를 쓴다.

Common Pitfalls

• 가용성을 가치와 혼동한다.
• 휴식은 “벌어야” 한다고 생각한다.
• “아니오”라고 하면 대체 가능해진다고 믿는다.
• 시간을 보호하기 위해 허가를 기다린다.

이러한 것들은 어느 것도 확장되지 않는다.

Community Discussion

궁금하다:

• 개발자로서 설정해야 했던 가장 어려운 경계는 무엇인가?
• 번아웃을 “그냥 더 열심히 일하면 된다”고 착각한 적이 있는가?
• 후회 없이 자신을 선택하도록 도와준 것은 무엇인가?

댓글에 경험을 남겨 주세요—우리가 충분히 이야기하지 못하는 주제 중 하나이다.

FAQ

What if my team expects constant availability?
명확한 기대치를 설정하고, 현실적인 온콜 또는 응답 창을 협상하며, 지속적인 방해가 전체 생산성에 미치는 영향을 전달한다.

Final Thoughts

자신을 선택한다는 것이 팀에 대한 관심이 줄어든다는 뜻은 아니다. 자신에게도 같은 배려를 해도 괜찮다.