신입 개발자의 역량과 성장에 대하여(feat. Done is better than perfect)

신입 개발자에게 필요한 역량을 국어·영어·수학에 비유해 정리한다. 국어는 동료와 명확히 소통하는 힘, 영어는 최신 문서를 읽는 정보 습득력, 수학은 비즈니스 로직을 구조적으로 해석하는 논리적 사고다.

실무에서는 저맥락 소통이 중요하다. “그거 처리해 주세요”처럼 해석의 여지가 큰 말보다, 무엇을 언제까지 어떤 맥락에서 처리해야 하는지 구체적으로 전달해야 시행착오를 줄일 수 있다.

문제를 해결할 때는 한 가지 관점만 보지 않고 여러 경로로 정보를 탐색한다.

• 긍정적 정보와 함께 단점, 주의할 점, pitfall, gotchas도 같이 확인한다.
• site:stackoverflow.com 같은 검색 연산자로 범위를 좁혀 본다.
• GitHub Issues를 확인해 실제 현장에서 반복되는 문제를 파악한다.
• 뉴스레터나 관련 블로그를 구독해 꾸준히 흐름을 따라간다.

배운 내용은 반드시 기록으로 남긴다. 팀 Wiki, 코드 리포지토리, 주석을 활용해 왜 그런 판단을 했는지와 변칙적인 처리 이유를 남기면, 다음 사람의 학습 비용과 재문의 비용을 줄일 수 있다.

특히 주석과 로그는 단순히 “무엇을 하는지”가 아니라 왜 필요한지를 남기는 도구다. 카드번호 마스킹, Luhn 알고리즘 검증, 새벽 2시 배치 실행처럼 도메인과 시간 의존성이 있는 부분은 맥락을 함께 적어야 나중에 다시 이해하기 쉽다. 예외 처리도 마찬가지로, 실패 시 카드번호·금액·PG사·오류코드·메시지처럼 문제 해결에 필요한 정보를 충분히 남겨야 한다.

질문은 피해야 할 행동이 아니라, 제대로 하면 가장 빠른 학습 수단이다. 다만 질문 전에 Wiki, 메신저, 코드, 검색을 먼저 확인하고, 질문할 때는 시도한 것과 상황을 함께 정리해야 답을 빨리 받을 수 있다. 답을 들은 뒤에는 그 내용을 다시 문서화해 다음 사람에게 남기는 것이 중요하다.

마지막으로 완벽한 구현을 목표로 하기보다 MVP를 먼저 만들고 점진적으로 개선한다. 먼저 동작하는 기능을 만들고, 이어서 예외 처리와 로깅, 그다음 성능 최적화와 아키텍처 개선, 테스트를 순차적으로 더해 가는 방식이 현실적이다. 결국 Done is better than perfect는 대충 하자는 뜻이 아니라, 학습과 개선이 계속 이어지는 속도를 확보하자는 전략이다.