개발자로서 고민하는 후배님들께...
안녕하세요. 커뮤니티를 자주 눈팅하며 후배님들의 고민을 자주 접하는 10년차따리 개발자입니다.
신입에서 4년 차 정도의 후배님들이 올리는 질문과 걱정 글들을 보며, 작은 도움이라도 드리고자 몇 가지 생각을 공유합니다.
제 생각이 정답은 아니지만, 저 또한 이렇게 고민하며 지금까지 나아왔기에 도움이 되었으면 합니다.
1. 과연 내가 지금 개발자라고 부를 수 있는 단계인가?
기획과 설계에 맞춰 코드만 짜는 현재의 모습에서 스스로를 "개발자"라고 부를 수 있을까요?
그냥 주어진 대로 코드를 작성하는 건 "단순 코더"에 가까울 수 있습니다.
하지만 진짜 개발자는 기획과 설계의 이유를 고민하고, 이를 더 나은 방식으로 구현하려는 노력을 합니다.
다음과 같은 점들을 끊임없이 생각해야 합니다:왜 이렇게 기획되었는가?
어떻게 하면 더 효율적이고 오류 없이 구현할 수 있을까?
이러한 고민은 기획/설계 담당자와의 지속적인 소통을 통해 더 나은 결과로 이어질 수 있습니다.
2. 프로그램 언어에 너무 구애받지 마세요. (상황에 따라 다를 수 있음)
물론 Low-Level 언어(C, Assembly 등)는 진입 장벽이 높을 수 있습니다.
하지만 OOP(객체지향 프로그래밍) 언어를 사용하는 경우, 언어 전환의 어려움은 생각만큼 크지 않습니다.현재 사용하고 있는 언어에 대한 불안감이 느껴지시더라도, 너무 걱정하지 마세요.
하나의 언어를 일정 수준 이상 익히면 새로운 언어를 배우는 데 기본적인 알고리즘과 자료구조에 대한 경험이 큰 도움이 됩니다.
중요한 것은 지금 다루고 있는 언어와 기술에 집중하고, 이를 통해 성장하는 것입니다.3. 남의 소스코드를 욕하기 전에 내가 이걸 짰다면?
레거시 코드를 볼 때 "도대체 왜 이렇게 짰지?"라는 의문이 드는 경우가 많으실 겁니다.
하지만 그 코드를 작성한 사람도 당시의 상황에서 최선을 다했을 가능성이 큽니다.일정 부족, 인력 부족 같은 환경적 요인.
당시 알 수 없던 요구사항 변경이나 이슈가 있었을 수도 있습니다.
그렇기에 단순히 욕하기보다는, *내가 이걸 짰다면 어떻게 했을까?*라는 관점에서 고민해 보세요.
심지어 간단한 부분이라면 직접 개선해보는 것도 좋습니다.
더 나은 방법을 발견하면, 이를 위로 보고하여 프로젝트 개선에 기여할 수도 있겠지요.4. 소스코드는 곧 문서입니다.
소스코드는 단순히 기계가 이해하는 코드가 아닙니다.
누군가가 읽었을 때 다음을 명확히 할 수 있어야 합니다:코드의 가독성: 코드를 읽는 사람이 쉽게 이해할 수 있어야 합니다.
추상화의 이유: 왜 이렇게 설계했는지 명확해야 합니다.
로직의 표현: 어떤 문제를 해결하려는 코드인지 드러나야 합니다.
이것이 제가 생각하는 개발자의 역량입니다. 가독성과 명확성을 갖춘 코드가 곧 좋은 코드입니다.
2024년의 연말이 얼마 남지 않았습니다.
한 해 잘 마무리하시고, 2025년에는 더 큰 성장과 평안이 있기를 기원합니다.
저는 이렇게 생각하며 연차를 쌓아왔고 지금도 나아가고 있습니다.
부디 제 생각이 후배님들께 조금이라도 도움이 되었으면 좋겠습니다.감사합니다.
