[성장캠프 1기] 2회차 회고: 셀프 브랜딩, 어떤 개발자가 되고싶은지
안녕하세요 K-DEVCON 성장캠프 참여중인 김진주입니다.
성장캠프 2회차에서 나눈 셀프 브랜딩 이야기를 계기로, 어떤 개발자가 되고 싶은지에 대해 회고하고 글을 작성했습니다.
성장캠프 2회차에서 나눈 셀프 브랜딩 이야기를 계기로, 어떤 개발자가 되고 싶은지에 대해 회고하고 글을 작성했습니다.
“당신의 강점은 무엇인가요?”
“당신을 스스로 브랜딩해보세요.”
질문에 답하려니, 그동안 해온 일을 나열하는 것밖에는 떠오르지 않았습니다.
열심히 일합니다. 문제를 찾아 개선하고, 공통 코드와 팀 컨벤션을 정비합니다. 보안 리스크와 버그를 수정하며, 필요한 정보를 공유하고 기획과 소통에도 적극적으로 참여합니다.
하지만 이것만으로는 무엇이 강점인지 명확하게 드러나지 않습니다. 해온 일을 나열했을 뿐, 그것이 어떤 강점을 보여주는지 한 문장으로 정의하지 못했고 이를 뒷받침할 근거도 제시하지 못했기 때문입니다.
“Don’t tell, just show”라는 표현을 좋아하지만, 정작 나의 강점을 무엇으로 어떻게 보여줘야 할지는 막막했습니다.
이번에는 이 질문에 대해 나름의 답을 정리해봤습니다.
강점은 말로 설명하는 데서 끝나는 것이 아니라, 구체적인 근거와 반복해서 쌓아온 행동으로 보여줘야 한다.
셀프 브랜딩을 고민하며, 앞으로 보완하고 꾸준히 실천해야 할 세 가지를 정리해봤습니다.
1. 문제를 감각이 아닌 근거로 설명하기
시스템과 구조를 개선하는 능력과 주도성은 좋은 편이었습니다. 반면 팀의 문제를 코드와 숫자로 실측하고, 상황에 맞는 PoC를 제안하는 능력은 더 보완해야 했습니다.
팀에 변화를 제안하려면 기술적 타당성만큼 실제로 팀에 실용적으로 도움이 되는지가 중요합니다.
“반복되는 컴포넌트를 패키지화하자”는 제안만으로는 그 변화가 팀에 필요한지 함께 판단하기 어렵습니다.
반복은 정확히 어디에서 얼마나 발생하고 있으며, 어떤 오류나 유지보수 비용을 만들고 있는가?해결하지 않았을 때 이후 프로젝트에서 이 비용은 어떻게 누적되는가?패키지화가 이 문제에 가장 적합한 방법인가? 더 작고 저렴한 대안은 없는가?제한된 시간 안에 핵심 가설을 검증할 수 있는 가장 작은 PoC는 무엇인가?변경 전후의 AI 산출물 격차를 어떻게 측정하고, 어느 정도의 개선을 성공으로 판단할 것인가?
이런 구체적인 근거와 검증 기준이 있어야 문제의 우선순위와 제안한 해결책의 적합성을 팀이 함께 판단할 수 있습니다.
이를 실제 프로젝트 회고에 적용해, 막연히 필요하다고 느낀 개선안을 실제 측정값과 유지보수 비용으로 연결해 제안했습니다. 도입에 드는 비용뿐 아니라 도입하지 않았을 때 앞으로 누적될 비용도 함께 살펴보고, 제한된 시간 안에서 가설을 검증할 수 있는 작은 PoC와 성공 기준을 고민했습니다.
이전에는 필요하다고 느낀 개선안을 바로 해결책으로 연결했다면, 이번에는 문제의 타당성과 비용의 트레이드오프를 먼저 확인하고 팀이 함께 판단할 수 있는 근거를 만드는 데 집중했습니다. 이런 구체화 과정이 기술 제안을 더 실용적으로 만드는 방법이라는 것을 배웠습니다.
2. 선명한 목표를 정하고 시간을 쌓기
강점은 단기간에 만들어지지 않습니다. 유의미한 피드백을 받으며 하나의 방향으로 시간을 쌓아가야 비로소 나만의 강점이 됩니다. 하지만 돌아보니 스스로 꾸준히 시간을 투자할 만큼 선명한 방향이 없었습니다.
개발자로서의 목표를 ‘팀이 문제를 올바르게 정의하고, 빠르게 해결할 수 있도록 돕는 개발자’가 되는 것으로 삼았습니다. 이를 위해 문제를 명확히 정의하고, 판단에 필요한 근거와 맥락을 동료들이 이해할 수 있는 언어로 공유하며, 실제 결과까지 확인하는 경험을 꾸준히 쌓아가려 합니다.
개인적으로는 목표 없이 하던 영어 공부에도 ‘영어 선생님이 한국에 놀러 오면 막힘없이 영어로 하루 동안 서울을 가이드해주기’라는 구체적인 목표를 세웠습니다.
3. 반복되는 Glue Work는 문서와 시스템으로 옮기기
Glue Work는 팀이 원활하게 일할 수 있도록 돕는 작업입니다. 꼭 필요한 일이지만 명확한 성과로 드러나지 않는 경우가 많고, 특정한 사람이 반복해서 맡으면 시간과 에너지가 계속 소모됩니다. 저 역시 이런 작업에 시간을 많이 쓰는 편이라 개선 방법을 고민했습니다.
반복해서 설명하거나 챙기던 일을 문서화하고 시스템으로 옮기기 시작했습니다. 개인의 부담을 줄이는 동시에, 업무 지식이 특정한 사람에게 머물지 않고 팀 전체에 공유되도록 한다는 점에서도 의미가 있다고 판단했습니다.
팀 컨벤션은 AI가 참고할 수 있는 규칙과 자동화된 검증 과정으로 옮기고, PR 프로세스는 문서로 정리했습니다. 동료의 PR을 놓치지 않으면서도 제 업무 흐름을 유지할 수 있도록 리뷰 시간을 타임박스로 관리하기 시작했습니다.
한 번의 시도로 오랫동안 굳어진 습관과 일하는 방식이 바로 달라지지는 않을 것입니다. 결국 중요한 것은 목표를 세우고, 시도한 결과를 돌아보며, 다시 교정하는 과정을 이어가는 시간이라고 생각합니다.
아직 나를 한 문장으로 완성해 설명할 수는 없습니다. 다만 강점을 막연한 수식어로 말하기보다, 문제를 구체적으로 정의하고 동료들이 판단할 수 있는 근거를 만들며, 그 과정을 반복해서 쌓아가려 합니다.
언젠가 “당신의 강점은 무엇인가요?”라는 질문을 다시 받았을 때는, 말보다 그동안 쌓아온 행동과 결과로 답할 수 있었으면 좋겠습니다.
남은 회차도 같이 의견과 피드백 주고받으며 성장하는 시간이 되었으면 좋겠습니다. :)
감사합니다.
남은 회차도 같이 의견과 피드백 주고받으며 성장하는 시간이 되었으면 좋겠습니다. :)
감사합니다.