내가 지금까지 거쳐온 회사는 지방의 작은 소기업부터 중소기업, 정부기관 파견, 그리고 판교의 서비스 기업까지 정말 다양하다.
일반적인 관점에서는 판교의 서비스 기업이 성장의 기회와 배울 것이 가장 많을 것이라 생각하기 쉽지만, 내 경험은 조금 달랐다.
어디서 가장 중요한 것을 배웠냐고 묻는다면 한 마디로 대답하기는 어렵지만, 가장 큰 교훈은 성장을 위해 '생각'이 필수적이라는 점이다.
소기업에서의 성장: 시행착오
신입 개발자로서 첫 발을 내딛었던 소기업.
처음에는 단순히 "개발자가 되었다"는 사실만으로도 벅찼고, 내가 만든 코드를 통해 가치를 창출하고 돈을 번다는 것이 큰 자부심이었다.
하지만 첫 번째 큰 프로젝트에서 현실의 벽을 마주쳤다.
팀장이 제시한 요구사항을 맞추기 위해 매일 야근을 했지만 끝이 보이지 않았다.
그러던 중, 고객사 담당자와 직접 대화하며 실제 고객의 요구사항이 내가 작업한 분량의 20%에 불과하다는 것을 알게 되었다.
이때부터 나는 코드만이 아니라, "개발은 문서에서 시작된다"고 생각을 바꾸었다.
정확한 요구사항과 명세가 없다면, 아무리 열심히 개발해도 방향을 잃을 수 있다는 사실을 배운 것이다.
이 경험은 내가 개발자로서 더 나은 방향으로 일하기 위해 환경을 바꿀 필요성을 느끼게 해주었다.끼게 했다.
중소기업에서의 성장: 문서와 근거
이후 중소기업으로 이직하며 "문서"를 배우는 데 집중했다.
WBS 작성, 요구사항 분석, UML 설계 등 다양한 것들을 배우긴 했지만 매번 작성된 결과물에 확신이 들지 않았다.
마찬가지로 자바의 인터페이스를 공부하면서도 이해했다는 확신이 들지 않아, 여러 자료들을 비교하고 재구성하면서 스스로 납득하는 과정을 거쳤다.
이 경험은 근거를 기반으로 사고하는 방법을 배우는 계기가 되었다.
정부기관 파견에서의 성장: 주도적 문제 해결
정부기관 파견에서는 나를 제외한 모든 팀원이 같은 회사 소속이었고, 다른 회사 사람에게는 신경을 쓰지 않았다.
하지만 이런 환경에서 "내가 할 수 있는 일"을 고민하며 해결책을 찾아갔다.
PL이 퇴사하여 PM에게 부하가 생기기 시작하면서, 신입 사원들의 질문을 대신 받아 PM에게 전달하거나, 업무 분담 방식에 변화를 주어 협업의 효율성을 높였다.
또한, 신입 사원들에게 간이로 작성해준 요구사항 명세와, 테스트 케이스는 프로젝트 진행 중 요구 변경이나 팀 간 커뮤니케이션 문제가 줄어드는 효과를 직접 경험했다.
이러한 과정에서 주도적으로 문제를 해결하는 능력과 팀을 이끄는 리더십을 키울 수 있었다.
서비스 기업에서의 성장: 커뮤니케이션과 명확성
판교의 서비스 기업으로 이직하며 새로운 도전에 직면했다.
특히 "근거 없는 주장"에 대한 지적이 많았다. 내가 맡은 업무는 B2B 사업이었기 때문에, 개발자의 말이 사업팀을 거쳐 고객사에까지 영향을 미쳤다.
이곳에서 커뮤니케이션의 중요성과 명확한 근거의 필요성을 절실히 깨달았다.
또한, 예전에 공부했던 문서화 작업이 이곳에서는 자연스럽게 업무에 녹아들어 있었다.
고객의 니즈와 상황에 따라 어떤 부분이 어떻게 달라져야 하는지를 이해하고, 결국 "개발은 사람으로 시작해 사람으로 끝난다"는 것을 알게 되었다.
이런 경험을 통해 현재 회사에서 팀장 역할도 맡을 수 있게 되었다.
성장을 위해선 생각해야 한다.
내가 다양한 환경에서 배운 것은 기술 자체보다 생각하는 힘이었다.
문제의 본질을 고민하고, 근거를 통해 설득하며, 과거의 경험을 현재에 연결짓는 것이 성장의 핵심이었다.
이제는 나의 다음 목표를 고민하고 있다.
지금까지는 부족한 점을 채울 회사를 찾아왔지만, 앞으로는 더 성과를 낼 수 있는 사람이 되고 싶다.
내가 어디서 어떻게 도움을 줄 수 있을지 고민하고 있다.
'생각 정리 > 개발' 카테고리의 다른 글
개발을 할 때는 아무것도 믿지 않는다. (1) | 2025.02.11 |
---|---|
프로그램 설계, 이게 정답입니다. (0) | 2025.02.02 |
개발부하와 업무부하는 비슷하다. (1) | 2025.02.02 |
신입 개발자의 대규모 트래픽 경험? 이런걸 원합니다. (1) | 2025.01.25 |
개발은 완벽하지 않아도 된다. (0) | 2025.01.09 |