주니어 개발자로서 알았으면 좋았던 것들
Source: Dev.to
첫 코드를 작성했을 때, 나는 좋은 개발자가 되려면 더 많은 언어, 더 많은 프레임워크, 그리고 더 많은 단축키를 알아야 한다고 생각했다. 나는 “충분히 배우면” 자신감이 생길 거라고 믿었다. 그 자신감은 내가 기대한 방식으로 오지 않았다.
돌아보면, 누군가 일찍 말해줬다면 좋았을 것 같은 것들이 많이 있다—시간과 스트레스, 그리고 자기 의심을 줄여줄 것들. 이 글은 압도당하거나, 막히거나, 제대로 하고 있는지 확신이 서지 않는 주니어 개발자(그리고 여정 초반에 있는 모든 사람)를 위한 것이다.
1. 정상적으로 길을 잃은 느낌을 받아도 괜찮아요 (사실 잘하고 있을 때도)
주니어 개발자로서 나는 끊임없이 뒤처진 느낌을 받았습니다. 다른 사람들은 모두 더 똑똑하고, 더 빠르고, 더 자신감 있어 보였습니다. 나는 기본적인 오류를 구글링하거나 문서를 여러 번 다시 읽는 것이 나만의 일이라고 생각했죠.
내가 몰랐던 점: 길을 잃은 느낌은 업무의 일부라는 것입니다. 시니어 개발자조차도:
- 구문을 구글링한다
- 이전에 사용했던 것을 잊어버린다
- 새로운 코드베이스에서 작업할 때 불확실함을 느낀다
혼란스러워도 코딩을 못한다는 뜻이 아니라, 배우고 있다는 뜻입니다.
2. 기본이 프레임워크보다 더 중요하다
나는 트렌드를 쫓는 데 많은 시간을 보냈다:
- “이 새로운 프레임워크를 배워야 할까?”
- “이 언어는 아직도 유효한가?”
- “내가 잘못된 스택을 배우고 있다면 어떡하지?”
내가 일찍 알았으면 좋았을 것: 프레임워크는 변한다. 기본은 변하지 않는다. 강력한 기본은 다음과 같다:
- 프로그래밍 기본
- 자료 구조
- 문제 해결
- Git
- 웹이 작동하는 방식(HTTP, API, 데이터베이스)
…새로운 도구를 배우는 것이 훨씬 쉬워진다. 프레임워크는 왔다가 가지만, 개념을 이해하는 것은 당신과 함께 남는다.
3. 모든 것을 알 필요는 없습니다
초기에는 내가 알아야 한다고 생각했습니다:
- 전체 코드베이스
- 스택에 있는 모든 도구
- 모든 모범 사례
그 압박감은 지치게 했습니다.
현실 점검: 주니어에게 모든 것을 알라고 기대하는 사람은 없습니다. 더 중요한 것은:
- 좋은 질문을 하는 것
- 이해하지 못할 때 솔직히 말하는 것
- 시간이 지남에 따라 진전을 보여주는 것
- 배우려는 자세를 갖는 것
팀은 “모두를 아는 것”보다 호기심과 신뢰성을 훨씬 더 가치 있게 여깁니다.
4. 코드를 읽는 것은 코드를 작성하는 것만큼 중요합니다
I used to focus only on writing new code. Reading existing code felt slow and frustrating. But most real‑world development involves:
- Understanding legacy code
- Debugging unfamiliar logic
- Modifying someone else’s work
Once I started intentionally reading code—open‑source projects, teammates’ pull requests, older parts of the codebase—everything improved:
- My code became cleaner
- I learned patterns naturally
- Debugging got easier
Good developers are good code readers.
5. 질문하기는 약점이 아니라 기술이다
나는 무능해 보이고 싶지 않아서 질문을 피했다. 그 때문에 오히려 속도가 느려졌다.
효과적으로 질문하는 방법:
- 시도한 내용을 설명한다
- 오류나 현상을 공유한다
- 이해하지 못한 부분을 구체적으로 밝힌다
대부분의 개발자는 사려 깊은 질문을 환영한다. 침묵과 추측은 호기심보다 더 많은 문제를 일으킨다.
6. 첫 번째 코드는 최고의 코드가 아닐 거예요 (괜찮아요)
예전 프로젝트를 볼 때마다 움찔하곤 했어요. 복잡한 로직, 부적절한 네이밍, 의심스러운 결정들을 보았죠. 이제는 그 속에서 성장한 모습을 봐요. 옛 코드가 불편하게 느껴진다면, 그것은 좋은 신호입니다—성장했음을 의미하니까요.
완벽을 기다리지 말고 바로 만들기 시작하세요. 나쁜 코드를 작성하고, 거기서 배우고, 나중에 리팩터링하면 됩니다. 진행이 언제나 완벽보다 앞섭니다.
7. 디버깅은 핵심 기술이며 사후 생각이 아니다
처음에는 디버깅이 나중에 더 잘하게 되는 것이라고 생각했습니다. 틀렸습니다. 디버깅은 개발 자체입니다. 다음을 배우면:
- 오류 메시지를 주의 깊게 읽기
- 로그를 효과적으로 활용하기
- 문제를 일관되게 재현하기
- 문제를 더 작은 부분으로 나누기
…구문을 외우는 것보다 더 빠르고 자신감 있게 만들 것입니다.
8. 소프트 스킬이 예상보다 더 중요하다
I underestimated:
- 커뮤니케이션
- 경청
- 명확한 메시지 작성
- 피드백 주고받기
Being a good developer isn’t just about code—it’s about working with people. Clear communication can:
- 버그 예방
- 재작업 시간을 절감
- 팀원과의 신뢰 구축
Your ability to explain your thinking is just as important as your ability to implement it.
9. 학습은 멈추지 않는다 (그리고 그것은 나쁜 일이 아니다)
나는 “학습을 끝내고” 마침내 자신감을 가질 수 있는 순간이 올 거라고 생각했어요. 그런 순간은 오지 않아요. 기술은 계속 진화하지만, 당신도 마찬가지예요.
- 꾸준히 배우기
- 실제로 무언가 만들기
- 실수를 되돌아보기
- 매주 조금씩 개선하기
그러한 사고방식은 여정을 지속 가능하게 합니다.
10. 당신은 생각보다 더 잘하고 있습니다
If you’re:
- 코드를 정기적으로 작성하고 있다면
- 실수로부터 배우고 있다면
- 도전을 느끼고 있다면
당신은 올바른 길을 가고 있습니다—아직 그렇게 느껴지지 않더라도. 자신감은 모든 것을 미리 아는 것이 아니라 경험에서 비롯됩니다.