신화? “먼저 코드를 알아야 한다” #tenminemail.com

Source: Dev.to

나는 고급 알고리즘을 몰랐다.
시스템 설계를 이해하지 못했다.
인증 흐름이나 배포 파이프라인을 자신 있게 설명할 수 없었다.

하지만 아이디어는 있었다. 한 가지 문제가 계속 나를 괴롭혔다: 가입한 웹사이트—체험판, 다운로드, 커뮤니티, 뉴스레터 등—에서 스팸 메일이 끊임없이 내 inbox를 뒤덮었다. 마치 인터넷이 호기심에 세금을 부과하는 듯했다.

첫 번째 버전은 인상적이지 않았다

내가 개발을 시작했을 때, 모든 것을 처음부터 직접 짜지는 않았다. 도구와 AI 어시스턴트, 그리고 애플리케이션의 일부를 스캐폴딩해 주는 플랫폼을 사용했다. 문서를 끊임없이 참고하고, 말도 안 되는 수많은 질문을 던졌다. 나는 “진짜 개발자”가 아니라, 모든 부품을 완전히 이해하지 못한 채 기계를 조립하려는 사람처럼 느껴졌다.

때때로 문제가 발생했지만 왜 그런지 전혀 알 수 없었다: 이메일 전송이 실패하고, DNS 레코드가 기대대로 전파되지 않으며, 웹훅이 예측 불가능하게 동작하고, 처음엔 의미가 전혀 없어 보이는 오류가 나타났다. 각각의 문제는 맥락 속에서 무언가를 배우게 만들었고, 이론만으로는 얻을 수 없는 차이를 만들어냈다.

문을 지키는 거짓말

기술 분야에는 “도움을 받지 않고 복잡한 시스템을 손코딩할 수 있어야만 빌릴 자격이 있다”는 암묵적인 믿음이 있다.

내가 발견한 것:
빌리는 행위 자체가 당신을 정당하게 만든다. 내 앱이 제대로 설정된 MX 레코드를 통해 처음으로 이메일을 받았을 때, 나는 이메일 인프라에 대해 책으로만 읽었을 때보다 훨씬 더 많이 이해하게 되었다. 실패한 API 요청을 처음 디버깅했을 때, HTTP 동작을 어떤 튜토리얼보다 깊이 파악하게 되었다. 프로덕션에서 뭔가가 처음으로 깨졌을 때, 나는 책임감을 느꼈다. 개발이 추상적인 것이 아니라 실제가 되었다.

도구가 사고를 대체하지는 않는다

도구를 사용하면 기계적인 마찰은 줄어들지만, 의사결정 자체는 사라지지 않는다.

여전히 내가 결정해야 했다:

• 내가 해결하려는 문제는 무엇인가?
• 흐름은 어떻게 설계해야 하는가?
• 무언가 실패했을 때는 어떻게 처리할 것인가?
• 사용자 경험은 어떤 느낌이어야 하는가?
• 남용을 어떻게 방지할 것인가?

이 질문들에 대해 도구가 답을 주지는 않는다. 바로 여기서 개발이 살아 있다.

눈을 뜬 순간

전환점은 앱이 마침내 작동했을 때가 아니라, 미묘한 무언가를 깨달았을 때였다. 나는 더 이상 “코딩을 모르는 사람”이 아니었다— 어제보다 더 많이 알게 된 사람이었다. 그 차이는 곱해진다. 어느 날 갑자기 개발자가 되는 것이 아니라, 불완전한 것을 계속 배포하고 그 결과를 겪으며 서서히 개발자가 된다.

프로그래밍을 모른 채 개발이 가능한가?

가능하지만 nuance(뉘앙스)가 있다. 프로그래밍을 모른 상태에서 시작할 수는 있지만, 배우지 않고는 성장할 수 없다. 차이점은 학습이 먼저일 필요는 없다는 것이다— 구축하는 동안에 배울 수 있다. 꾸준히 만들면 호기심이 지식을 강요한다. 추상화 레이어 뒤에서 무슨 일이 일어나고 있는지 이해하고 싶어지고, 더 좋은 질문을 던지고, 패턴을 인식하며, 아키텍처에 신경 쓰게 된다. 실수가 당신을 신경 쓰게 만들기 때문이다. 어느 순간, 당신은 초보자임에도 불구하고 빌리는 것이 아니라, 개발자가 되기 위해 빌리고 있는 것이다.

지금 내가 믿는 것

• 시작하기 위해 허가를 받을 필요는 없다.
• 학위, 열 개의 인증서, 모든 것을 알 필요도 없다.
• 문제와 끈기, 그리고 잠시 어리석게 보이는 것을 감수할 의지만 있으면 된다.

나는 준비가 되었다고 느낄 때까지 기다리지 않았다. 먼저 무언가를 만들었다. 그리고 그것이 나를 준비시켰다.