꿈은 당신이 움직이지 않으면 작동하지 않는다: 개발자로서 힘들게 배운 교훈

발행: 1시간 전 (2025년 12월 26일 오전 01:35 GMT+9)

8 min read

I’m happy to translate the article for you, but I need the text you’d like translated. Could you please paste the content of the article (excluding the source line you already provided) here? Once I have the full text, I’ll translate it into Korean while preserving the original formatting and markdown.

Introduction

몇 년 전, 나는 깔끔한 GitHub 프로필과 수십 개의 즐겨찾기 튜토리얼, 그리고 “탄탄한 엔지니어”가 되겠다는 큰 꿈을 가지고 있었다.
내게 없던 것은? 나는 계속해서 “준비 중이다”라고 스스로에게 말하고 있었다.

진실은 불편했다: 꿈은 당신이 행동하지 않으면 이루어지지 않는다 — 그리고 소프트웨어 엔지니어링에서 행동한다는 것은 완벽하지 않은 코드를 작성하고, 문제를 일으키며, 꾸준히 나타나는 것을 의미한다. 이 글은 결국 나에게 깨달음을 준 것이 무엇인지, 그리고 왜 이 사고방식이 지금 배우고 있는 어떤 프레임워크보다도 더 중요한지를 다룬다.

백스토리 (왜 이것이 중요한가)

내가 만나는 대부분의 개발자들은 게으르지 않다. 그들은 종종:

과도하게 준비함
잘못된 것을 만들까 두려워함
준비가 되었다고 느낄 때까지 기다림

나도 마찬가지였다. 나는 이렇게 믿었다:

“이 코스를 끝내면 바로 만들기 시작할 거야.”
“모든 것을 이해하면 구직 신청을 할 거야.”
“자신감이 생기면 내 작업을 공유할 거야.”

그 순간은 오지 않았다. 내 궤도를 바꾼 것은 동기가 아니었다.

핵심 아이디어

“Dreams don’t work unless you do”(꿈은 당신이 행동하지 않으면 이루어지지 않는다)는 동기 부여 문구처럼 들리지만, 개발자에게는 경력에 대한 시스템 설계 원칙입니다. 실제로는 다음을 의미합니다:

학습은 구현 후에 일어나며, 사전에 일어나지 않습니다.
명확성은 끝없는 고민이 아니라 피드백을 통해 얻어집니다.
자신감은 반복의 부수 효과입니다.

코드를 계획함으로써 더 나은 개발자가 되는 것이 아니라 실행함으로써 더 나은 개발자가 됩니다.

Implementation: What “Doing the Work” Looked Like for Me

Building Before Feeling Ready

나는 “이걸 만들 준비가 되었나요?” 라는 질문을 그만하고 “가장 작은 깨진 버전을 언제 배포할 수 있을까?” 라는 질문을 하게 되었다.
그 결과는 다음과 같다:

보기 흉한 UI
하드코딩된 값들
놓친 엣지 케이스

하지만 이것이 모멘텀을 만들기도 했다.

Treating Side Projects Like Production

내 사이드 프로젝트에 실제 규칙을 적용했다:

적절한 README
명확한 문제 정의
어딘가에 배포 (완벽하지 않아도)

이 변화만으로도 몇 달간의 튜토리얼보다 더 많은 것을 배웠다.

Learning Through Bugs (Not Courses)

한 번의 프로덕션 버그가 다섯 개의 블로그 포스트보다 더 많은 것을 가르쳐 주었다. 아래는 실패에 대해 깊게 고민하지 않고 만든 재시도 함수이다:

export async function retry(fn, attempts = 3) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await fn();
    } catch (err) {
      if (i === attempts - 1) throw err;
    }
  }
}

프로덕션 환경에서 이 코드는 실제 질문들을 떠올리게 했다:

재시도에 지수 백오프를 적용해야 할까?
어떤 오류를 재시도해야 할까?
언제 재시도가 오히려 상황을 악화시킬까?

👉 일을 직접 해보면서 격차를 발견하게 되었다.

무엇이 잘못됐는가 (교훈)

필요 없는 프로젝트를 만들었다
초기 기능을 과도하게 설계했다
트렌드를 쫓으며 기본을 무시했다

모든 실수에는 숨은 이점이 있었다: 맥락을 만들었다. 맥락이 없으면 조언은 지속되지 않는다.

모든 개발자에게 공유하고 싶은 모범 사례

일관성이 강도보다 우선한다
공개적으로 구축하기 (불완전해도)
작은 일을 끝내기
학습을 반복적인 과정으로 여기기

흔한 함정

튜토리얼을 독점하기
시작하기 전에 자신감을 기다리기
자신의 1장을 다른 사람의 20장과 비교하기
결과보다 도구를 최적화하기

이것이 개인적인 것처럼 느껴진다면 — 저도 그랬어요.

커뮤니티 토론

I’d love to hear from you:

당신이 계획했지만 결코 출시하지 못한 프로젝트는 무엇인가요?
학습에서 실천으로 전환하게 만든 결정적인 요인은 무엇인가요?
현재 당신을 방해하고 있는 것은 무엇인가요?

👇 댓글에 생각을 남겨 주세요 — 이것은 함께하는 여정입니다.

FAQ

Q: 시스템과 습관이 동기부여보다 더 효과적인가요?
A: 네. 시스템과 습관은 매번 동기부여보다 더 효과적입니다.

Q: 무엇을 만들어야 할지 모르면 어떻게 해야 하나요?
A: 지루한 것을 만들어 보세요. 실제 문제는 실제 기술을 가르칩니다.

Q: 이것이 시니어 개발자에게도 적용되나요?
A: 물론입니다. 도구는 바뀔 수 있지만 실행이 여전히 중요합니다.

최종 생각

꿈은 중요하지만, 소프트웨어 엔지니어링에서는 실행이 배가 효과입니다. 더 많은 영감이 필요한 것이 아니라, 당신에게 필요한 것은:

풀 리퀘스트
배포된 앱
스스로 고친 깨진 기능

왜냐하면 결국 — 꿈은 당신이 행동하지 않으면 이루어지지 않는다.