Legend Of Imposters: 초보자 프로젝트가 어떻게 나에게 수치심과 싸우는 데 도움이 되었는가
Source: Dev.to
Introduction
내 안에 두 마리의 늑대가 있다 – 하나는 끝없는 개선 욕구와 배우고, 내가 하는 일에 정말 능숙해지고, 스스로를 내보이고 싶어한다. 다른 하나는 – 수치심이다.
- 왜 나는 이걸 더 잘 몰라?
- 이 프로젝트는 별로다.
- 사람들은 “그녀가 어떻게 직장을 구했지?” 라고 생각할 거야.
사실 나는 최근 프로젝트를 정말 즐겼다. 엄청 많이 배웠고, 이게 더 일찍 클릭되지 않았다는 게 조금 부끄럽다. 그래도 나는 여기 있다. 뭔가를 배웠다는 사실에 신이 나기 때문이다. 몇 달 뒤에 돌아보면 내가 얼마나 성장했는지 알게 될 것이다. 몇 년을 해왔든, 스스로를 내보이고 질문을 해라. “별로인 초보자 프로젝트”를 해라. 시도조차 하지 않을 때만이 진짜 패배다.
사람들이 임포스터 신드롬에 대해 얘기하는 걸 자주 들었고, 나는 “음, 하지만 내 경우라면, 그들이 정말 안다면… 내가 진짜 임포스터라면 임포스터 신드롬이 아니겠지!” 라고 생각했다. 그 두려움 때문에 내 여정을 올리기도, 질문을 하기도, 승리를 축하하기도 못했다. 이제 한 걸음 나아간다. 반성과 피드백은 내가 배우는 방법의 일부이니, 여기까지 온 것이다.
Why I Went Back to the Basics
나는 The Legend of Zelda: Breath of the Wild 를 사랑한다. 내가 지금까지 플레이한 게임 중 상위 5위 안에 쉽게 들어간다. 작은, 위험 부담이 적은 프로젝트로 API와 프론트엔드 상호작용을 더 잘 이해하고 싶었을 때, 이 게임의 무료 API를 발견했다… 너무 신났다.
프로젝트의 목적은 두 가지였다:
- API에 더 익숙해지기 – API를 읽고, 속성에 접근하고, 데이터를 사용자가 실제로 상호작용할 수 있는 형태로 변환하는 법을 배우기. 직장에서 이걸 늘 하긴 하지만, 이해가 부족하다고 느낀다. 무엇이 작동하는지는 알지만 왜 작동하는지는 모른다.
- CSS 연습 – 왜 안 해보겠어?
많은 것을 배웠다! 대부분은 내가 목표로 삼았던 것이 아니었다. 기본기를 다지고 API를 “개발자 마법”이 아니라 “내가 풀 수 있는 퍼즐”로 만들고 싶었는데, 대신 아키텍처, 네이밍, 구조가 프로젝트를 이해하는 능력에 얼마나 큰 영향을 미치는지 깨달았다. 그리고 DOM 조작은 프레임워크 안에서 살아온 수년 뒤에야 겸손하게 만든다.
올해 나는 아키텍처와 디자인 원칙 학습에 중점을 두었기에, 작은 무료 API 프로젝트조차도 아키텍처적 사고가 필요하다는 사실에 크게 놀랐다.
Mapping the World: Mental Models & APIs
API는 재미있고 읽기 쉬웠다. 유지보수자를 칭찬한다 – 정말 잘 만들었다. BOTW 데이터를 활용하고 싶은 사람에게 강력히 추천한다.
데이터를 파헤치면서 최근 몇 달 동안만 들어본 멘탈 모델이라는 개념이 드디어 이해되었다. 팟캐스트에서 처음 듣고 구글링했지만 바로 와닿지는 않았다. API와 작업하고 나중에 되돌아보니, 나는 이미 내부 지도를 그리고 있었던 것이다 – 데이터 흐름, 조각들 간 연결, UI가 어떻게 동작해야 하는지를 상상하는 것. Postman으로 엔드포인트를 탐색할 때 나는 적극적으로 멘탈 모델을 구축하고 있었다.
처음엔 훨씬 복잡한 무언가를 상상했지만, 실제로 데이터를 다루면서 방향을 바꿨다. 아이템과 그 위치를 쉽게 찾아볼 수 있는 간단한 컴펜디엄이 최적이었다. 뒤로 가기 버튼이나 여러 뷰가 필요 없었다.
The Combat: Async Tracks and DOM Manipulation
데이터와 응답을 놓치는 속도가 너무 빨라서 충격을 받았다. 나는 일부러 .fetch().then().then().catch() 체인을 사용했는데, 최신 문법 대신 Promises 를 직접 이해하려는 목적이었다.
한 번은 저녁 반을 보내면서 fetch 안의 console.log에서는 데이터가 완벽하게 보였지만 UI에는 전혀 나타나지 않았다. 결국 .then() 체인 중 하나에서 Promise를 반환하지 않았던 것이 원인이었다. 콘솔엔 올바른 값이 찍혔지만 UI는 아무것도 받지 못했다.
데이터가 어디서 사라지는지를 추적하는 것이 프로젝트의 주요 테마가 되었다. 클래스를 적절히 그룹화하면 디버깅이 훨씬 쉬워진다는 것을 빠르게 깨달았다. 깔끔한 구조 덕분에 데이터 흐름을 시작부터 끝까지 따라갈 수 있었다. 대부분의 버그는 데이터 흐름을 놓친 데서 비롯되었다. 이 프로젝트는 내가 개선해야 할 부분을 명확히 보여줬다: fetch에서 프론트엔드까지 데이터 추적.
DOM 조작도 나를 크게 곤란하게 만들었다. Angular만 쓰다 보니 동적으로 요소를 추가하는 것이 낯설었다. 나는 새로운 Anki 카드 열 장을 만들었고, 내장 메서드의 특이점도 더 잘 이해하게 되었다. 내가 주로 사용한 패턴은:
- 작동하는 해결책 찾기 (안녕, StackOverflow).
- 왜 작동하는지 이해하기.
- 내 깨진 버전과 비교하기.
- AI를 고무오리처럼 활용하기 – 답을 주지 말고 질문만 하라고 했기 때문에 더 깊게 생각해야 했다.
New Game Plus: Lessons in Architecture
이제 멘탈 모델이 뭔지 알고, 설계와 아키텍처 경험이 조금 늘었으니, 몇 가지를 다르게 할 것이다:
- 1–3개의 인터랙티브 사용자 흐름을 작성 – 사용자가 무엇을 하려 하고, 어떤 대안을 취할 수 있는지. 이것만으로도 UI 선택과 데이터 기대치를 크게 바꿀 수 있다.
- 모든 것을 클래스에 집어넣는 것을 멈추기 – 클래스는 행동과 상태 를 나타내야 한다. 이것이 초기의 혼란을 정리해 주었고, 헬퍼가 데이터 관리 객체와 별도로 존재할 때 코드가 얼마나 깔끔해지는지 보여줬다.
The Loot: What I Actually Learned
이 프로젝트는 예상치 못한 영역—아키텍처, 비동기 흐름, DOM 조작, 그리고 솔직히 자신감—에서 이해를 열어줬다. 이제 나는 이론적인 수준을 넘어 실제로 Promises 를 “이해한다”는 느낌을 얻었다.
그보다 더 중요한 것은, 작고 위험 부담이 적은 프로젝트가 한 번에 다양한 스킬을 레벨업시킬 수 있다는 점이다. 나는 이미 다음 작은 실험을 만들고 있고, 그것도 곧 공유하고 싶다.
그리고 두 마리의 늑대가 내 프로젝트가 별로인지, 아니면 어쨌든 올려야 하는지 논쟁을 시작할 때… 이제는 호기심 많은 늑대를 먹이는 것이 보상을 가져다준다는 증거가 조금 더 생겼다.