개발자 원칙
왕초보 개발자는 어떤 원칙이 필요할까?
개발자 원칙 : 테크리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학
/박성철, 강대명, 공용준, 김정, 박미정, 박종천, 이동욱(네피림), 이동욱(향로), 장동수
/GOLEDN RABIT
로봇 소프트웨어 개발을 시작한 지 한 달,
나는 "왕초보 개발자"
구현하고 싶은 기술들은 많은데 구현이 쉽지 않고
가이드라인이 없다 보니 더욱 어려움을 느낀다.
나보다 먼저, 그리고 더 오랜 기간 개발을 하고 있는
9명의 이야기를 통해 인사이트를 얻어보자!
왕초보 개발자가 당면한 고민
자율주행을 구현하고 싶은데 어떻게 할까?
카메라, 라이다, 초음파 센서등 센서 종류도 많고
카메라만 해도 해상도, RGBD, RGB, stereo 등
신경 쓸 것들이 너무 많다. 눈 역할을 하는 센서가
어찌하여 선정이 되었다고 해도 뇌 역할을 하는
인식 방법에 대해서도 6D pose estimation,
3D Structure From Motion 등 적용하는 방법이
달라질 것이고, 뇌 역할을 마무리 지었다고 해도
움직이는 역할인 제어부에 대한 고민도 해야 된다.
무엇보다 계획과 다르게 마주치는 문제도
동시에 해결해 나가야 된다.
당장 의욕과 에너지는 넘쳐나는데 머릿속에서는
우왕좌왕하니 하나의 스텝을 밟기까지
너무 오랜 시간이 걸리는 게 느껴진다.
공부하는 학생과는 다르게 어떤 마인드셋을
장착해야 내가 가지고 있는 에너지를 효율적으로
사용하며 매끄럽게 성장할 수 있을지 찾아본다.
개발자를 위한 세 가지 키워드
우선 9명의 개발자는 모두 최소 3개 이상의 회사를
다니며 성장한 쌓은 사람들이다. 그들이 말하는
원칙은 그간의 경험을 바탕으로 만들어져 마음으로
와닿지 않는 부분들이 많이 있었다. 어쩌면 이 책은
개발에 숙련된 사람이 본인의 원칙과 9명의 원칙을
비교하며 읽는 자료에 더 적합할지도 모르겠다.
하지만 그렇다고 해서 나에게 필요한 인사이트를
얻지 못한 것은 아니다. 그저 문장으로는 이해가
되지만 체화하기까지 오랜 시간이 걸릴 것 같다는
의미이며 실마리를 잡는 데에는 도움이 되었다.
각자의 원칙이 다르고 중요하게 생각하는 것들도
조금씩 차이가 나지만, 그들의 짧은 이야기 안에서
공통적인 내용이 보였다. 키워드로 정리해 본다면
성장, 타협 그리고 측정이다.
1. 성장
본인의 성장하고 싶은 욕구가 기본 원동력이 된다.
보편적인 말을 하는 것 같지만 개발자라는 특성상
성장에 대한 욕구가 강하지 않다면 개발자로서
생존하는 것 자체가 불가능에 가깝다고 느껴졌다.
코드 구성을 잘하고 싶다는 생각
기술 고도화나 신기술을 적용하고 싶다는 생각
A부터 Z까지 프로젝트를 전부 진행하고 싶은 생각
거대한 프로젝트에서 한 분야를 담당하고 싶은 생각
이렇게 성장의 욕구에는 다양한 종류가 있고 각각에
대해서는 최적화에 대한 원칙, 하이프 사이클,
이직에 대한 장단점 등 다양한 원칙들을 통해
어떻게 성장을 실현시키는지 소개가 되어 있었다.
하지만 이제 막 개발을 시작한 나에게는 우선
눈앞에 놓인 하나의 프로젝트를 실현시키고 싶다는
생각이 강력하여 성장에 대한 원칙은 어느 정도
중간 레벨 이상이 되었을 때 다시 살펴보자.
2. 타협
성장하고 싶은 욕구가 충분하다면 타협을 할 줄
알아야 된다. 개발이라는 것은 하나를 만들고 끝이
아니라 항상 유지 보수가 필요하다. 특히 버전을
업그레이드할수록 이전 기능과의 충돌과
기술부채 등의 문제는 불가피하다. 그렇기에
90점짜리 결과물을 내기보다는 80점짜리
결과물을 먼저 만들어내는 것이 더 중요하다.
책에 적힌 비유가 찰떡같다.
"달리는 기차의 바퀴를 갈아 끼우기"
기차는 계속해서 달려 나가 가고 바퀴를 고치는
속도보다 객실이 늘어나는 속도가 더 빠른 것이
일상이다. 기차가 멈추지 않게 새로운 바퀴를
계속 달아주고 동시에 기존 바퀴에 너무 많은
시간을 쓰지 않는 타협이 필요하다는 것이다.
무엇보다도 지금 당장 되는 기능을 만드는 것이
가장 중요한 원칙이라고 언급되어 있다.
12월 26일에 열리는 완벽한 크리스마스 이벤트보다
12월 25일에 열리는 적당한 크리스마스 이벤트가
훨씬 의미 있는 일이고, 완벽하게 만들어
내년을 기다릴까 싶지만 개발의 세계에서 내년에는
기회가 없을 수도 있는 점을 명심하자.
약간의 실마리가 잡히기 시작한다. 개발을 시작하고
한 달 동안은 내가 구현할 수 있는 기능들을 빠르게
만들어 보았다. 큰 목표를 완벽하게 만들자는
욕심을 버리고 적당히 타협하며 작은 목표로 쪼개는
현재의 진행은 괜찮은 방식이라는 안도감을 얻었다.
단계를 쪼개어 나아가보자는 회사의 팀장님처럼
이 책에서도 GPAM이라는 하나의 원칙을 소개한다.
G : Goal, P : Plan, A: Action, M : Measure
목표를 정하고 계획을 세워 실천하고 측정하기.
원칙이라고 받아들이기 민망할 정도로 자명하지만
여기서 나는 세 번째 키워드를 찾았다.
3. 측정
GPAM 원칙 이외에도 측정에 관해서 다른 분들의
언급이 있었다. 예를 들어 기능을 구현했을 때
점수를 매겨 알아볼 수 있게 항목별로 표시하는
것이 중요하다는 내용이나, 다른 개발자들이 있는
커뮤니티나 활동에서 나 또는 내가 속한 회사의
위치를 파악하는 것이 중요하다는 것 등이 있었다.
나의 레벨이나 회사의 위치 측정은 당장 나에게
필요한 측정은 아니다. 나에게 필요한 것은 지금
하고 있는 프로젝트의 진행도를 알아내는 것이다.
학교 같은 교육기관에서는 시험이나 퀴즈라는
이벤트로 측정을 해준다. 하지만 내가 지금 하는
일에 대해서는 측정을 해주는 이벤트가 없다.
진도가 얼마나 나갔는지, 앞으로 얼마나 남았는지
알 수 없고 지금까지의 작업이 어느 정도 진행된 것
인지도 추상적으로만 알 뿐이다.
어떻게 보면 측정을 한다는 것 자체가 모순적이고
불가능한 일이며 굳이 불가능한 측정을 가시화하는
것에 대해 시간과 노력을 기울여야 되나 싶었다.
하지만, 그래도 해보자는 마음에 노력을 기울이니
다른 것들이 보였다. 아직은 가시화하여 알아보기
어렵지만, 내가 할 수 있는 것, 시간 활용 방식,
나만의 집중 스타일 등을 알게 되었다.
그러니까 나를 돌아보게 되었다.
자연스럽게 개선의 여지가 보이기 시작하고
우왕좌왕하던 머릿속은 나름 깔끔하게 정리되며
비효율적이라 생각한 나의 모습에서 느껴진 실망은
다음 단계를 위한 준비였다는 기대로 바뀌었다.
GCM cycle
내가 만들어본 원칙이다.
G: grow C: compromise M: measurement
성장하고 타협하며 측정하고 다시 반복한다.
초보를 벗어나기 위해서는 성장해야 된다.
하지만 무작정 욕심만 가지고 나아가다가는
브레이크가 쉽게 걸린다. 적당히 타협을 하며
급하지 않게 나아간다. 할 수 있는 것부터 하나씩
하지만 종종 내가 잘하고 있는지 의문이 들며
의욕이 떨어질 수 있다. 그럴 때는 스스로를 측정해
재정비하고 다시 성장의 욕구를 이용해 나아간다.
당분간은 이 원칙을 고수해 보자.
