개발자는 고객을 위한 상품을 만드는 사람

스타트업의 주니어 개발자로서의 고민

 

개발자로 커리어를 시작하며 기술적 전문성에 대해서 많이 고민하게 되었다.

부트캠프에서 교육을 받으며 개발자들끼리는 프로그래밍 기술에 초점을 맞추며 성장하고자 했다.

 

그런데 입사 후 실무에서는 그것과 괴리가 있었다.

코딩이나 기술 외에 도메인 지식 및 문서 작업에도 시간을 할애해야 했다.

경우에 따라 기술적으로 최선의 방법을 찾는 것보다 빠르게 개발하여 일정을 맞추는 것이 더 중요시 되기도 했다.

 

회사를 다니며 들었던 고민들

 

회사에서는 백엔드와 프론트엔드를 모두 하길 원하는데, 한 분야에만 집중하는 것이 전문성을 키우기에는 좋지 않을까?

기술 공부를 하기에도 바쁜데 왜 대표님은 나에게 논문을 읽고 다양한 지식을 습득하라고 하는걸까?

문서 작업에 너무 많은 시간을 쓰는 것이 비효율적인 것이 아닐까?

 

 

인식의 전환 - 개발자는 고객을 위한 상품을 만드는 사람

 

개발자인 나 자신을 '기술' 분야에만 한정하여 프로그래밍을 하는 사람으로 정의했었다.

그러나 관점을 바꾸어 개발자를 '고객을 위한 상품을 만드는 사람'으로 재정의했다.

프로그래밍은 그 수단으로서 하는 것이다.

 

생각을 바꾸자 단순히 기술을 넘어서 고객과 비즈니스 가치에 더 집중할 수 있게 되었다.

고객을 만족시키기 위해 내가 알아야 할 것과 해야할 일이 너무 많았다.

직무에 대한 본질을 깨닫고 시야가 더 넓어진 느낌이 들었다.

 

이렇게 내 업무를 돌아보니 단순히 프론트엔드 기술만 알아서는 고객을 만족시키는 제품을 만들 수 없었다.

먼저 고객의 니즈와 요구사항을 파악해야 했다.

또한 해당 개발 분야의 도메인 지식과 타 상품 사례를 찾아보아야 했다.

그리고 그것을 위한 코어 기술을 찾아보고 학습해야 했다. (비록 프론트엔드 개발 관련 지식이 아니더라도)

 

'면접에서 특정 기술을 사용했다고 하는 사람보다 어떤 상품을 만들기 위해 설명했다고 하는 사람을 채용하겠다.' 라고 했던 이전 부장님,

'비즈니스 관점을 가지고 프로그래밍을 해야 한다'고 조언해주셨던 이사님,

'코더가 되면 안 된다.'고 조언해주셨던 대표님,

'개발자라고 한다면 스스로 코딩하는 사람으로 정의하지 말자. 비즈니스 문제를 해결하는 사람으로 정의하자'던 우아한 형제들 김범준 CEO님

등등 다 비슷한 말씀을 하고 계신다고 느꼈다.

 

 

이를 적용하여 현재 하고 있는 일

현재 챗봇 플랫폼 프로젝트와 제조 데이터 공유 플랫폼 프로젝트에 참여중이다.

 

챗봇 프로젝트에서는 PM과 함께 RFP를 통한 고객 요구사항을 정의했다.

관리자 통계 기능 기획을 위해 다른 상품을 찾아보며 화면과 Flow Chart를 구상중이다.

또한 핵심 기능인 Dialog Manager를 이해하기 위해 자연어처리, DST, Intent, Slot 등의 지식을 학습했다.

이를 바탕으로 PM과 함께 기획이 완료되면 코딩을 시작할 예정이다.

 

제조 데이터 공유 플랫폼 프로젝트를 이해하기 위해 해외 사례인 Gaia-X, Catena-X를 먼저 스터디했다.

그리고 전무님, PM 이사님, 연구소 수석님과 프로젝트 방향성을 논의하고 RFP를 통해 고객의 요구사항을 정의했다.

고객의 비즈와 도메인 지식 덕분에 개발 우선순위를 정할 수 있었고, 그에 따라 현실적인 개발 범위를 정의할 수 있었다.