'개발자 원칙'을 읽고

글또 커뮤니티에서 책 ‘개발자 원칙’을 읽고 후기와 자신만의 원칙에 대해 이야기를 나누는 모임에 참여했다. 처음 목적은 내가 원칙이 없기 때문에 다른 사람들의 원칙이나 생각이 궁금해서였는데, 개발 관련 자기계발서를 읽지 않은지가 꽤 되어서인지 책도 생각보다 재미있었고, 반성하게 되는 부분도 많고, 책을 읽고 독후 활동을 같이 하니 책을 좀 밀도 높게 읽은 것 같아서 만족스러웠다.

책을 읽고 + 독후 활동에서 얻은 의견들을 종합해서 내 생각을 정리하고 기록을 남겨보고자 글을 쓴다. 안그래도 요즘 개발자로 일하는 나의 모습이 썩 만족스럽지는 않아서, 내가 어떻게 이 일을 선택했고 어떤 마음가짐으로 일을 했는지 돌아볼 수 있는 계기가 되리라 생각한다. 일부 생각들에는 책에서 나온 GPAM을 사용해서 나만의 작은 GPAM(나.작.G)들을 만들어 액션 플랜을 세워보았다.

 

📌 GPAM: Goal을 정하고, Plan계획을 만들고, Action 실천을 하고, Measure평가를 진행해 결과를 확인

 

 

 

 

 

나는 어떻게 개발자를 시작하게 되었을까?

고1부터 25세까지의 삶을 아우르는 긴 이야기여서.. 최대한 간단하게 풀어 본다.

최초의 계기는 ‘사이버 보안’ 에 대한 관심이었다. 왠지 간지도 나면서 의미도 있었기 때문이다. 마치 게임을 좋아하는 사람들처럼, 나도 인터넷 엄청 좋아하니까 괜찮겠네 라고 생각하며, 그렇게 컴퓨터공학과로 진로를 정했다. 하지만 역시 대학에서 배우는 학문은 차원이 달랐고 나는 공부를 안하고 방황한다 ㅋㅋㅋㅋㅋ

졸업할 쯤엔 아무리 내 대학생활을 돌아봐도 보안은 고사하고 아무것도 모르고, 학점도 안좋고, 해 본 것도 없이 학위만 있는 사람이었다. 그렇게 공기업 전산직을 준비하던 나를 후드려 팬 건..

어떤 모임에서 내가 졸업하면 공기업 전산직을 준비할 거라고 말했는데, 전산직이 뭐냐는 질문을 받았다. (한국어 잘 모르는 분이 물어봄)

그때 옆에 있던 친구가 “창의적이지 않은 직업이죠” 라고 대답을 했는데, 여러가지 생각이 들면서 좀 띵했던 것 같다.

그래서 오기로(?!) 그래 나도 개발자 해보자, 열정에 불타며 개발 직군에 서류접수를 한다. 그런데 지금 생각해보니 만약 이 경험이 없었다면, 나는 개발자를 했을까, 전산직을 했을까 궁금해진다.

 

 

 

딥다이브

기술적으로 딥다이브 하시는 분들을 보면 항상 신기했고 찐 개발자같다고 생각했다. 나는 이렇게 했던 적이 있었나? 나는 할 수 있나?

사실 단순히 흥미 만으로는 못할 것 같다. 결론적으로 드는 생각은, “문제 해결을 위해 필요하다면 해야 한다” 이다.

 

 

 

학습과 성장

많은 학습 관련 책에서 반복되는 내용이 여기에서도 나왔다. 나만의 언어로 요약하면 “어렵게 학습하기”이다.

다시 말하면 나는 이미 알고 있는 학습 방법이다. 그런데 실천을 안하고 있는 와중에 또 이 효율적인 학습 방법에 대해 이야기하니.. 알면서도 안하고 있다는 죄책감이 올라왔다.

📌 Action: 그날 들은 인강에 대해 퀴즈 만들고, 다음에 인강 듣기 전에 그 퀴즈 풀기 (인출 연습)

 

 

 

목표 설정, 방향 확인

목표를 향해가며 내가 어다쯤에 있는지, 방향은 맞는지를 알아야 하는데, 이때 메타인지 라는 개념이 필요하다. (지금은 내게 뚜렷한 장기 목표가 없기에 방향 확인에 대한 내용 위주로 생각해보았다.)

이걸 대체 어떻게 도달하는 것일까 항상 궁금했는데, 책과 독후 활동을 통해 나름의 힌트를 얻었다. 그건 바로 ‘기록’이다! 뭔가 달라진거같다거나, 안하던 걸 한다거나 하면 그렇게 방향을 바꿀 때마다 그 과정과 선택 이유를 기록하는 것!

액션은 비교적 명확한데 내게는 딱히 목표가 없다. 그래서 지금 가진 문제점을 잘개 쪼개어서 이에 대한 액션 플랜을 세워보았다.

📌 Goal: 회사에서 일할때 컨텍스트 스위칭 줄이기

📌 Plan & Action: 해결할 문제가 생기면 잘게 쪼개고, 과정을 기록한다. 괜히 노션같은거 쓰면 다른 노션 기록 보고싶고 그럴 수 있으니 메모장에 한다.

📌 Measure: 기록물이 얼마나 나왔는지 보고, Task 당 시간을 한번 측정해본다..? 이건 어떻게 할 지 좀 생각해봐야할거같긴하다.

 

 

 

지금의 목표 (단기)

하고싶은 것을 하기.

여기에서 하고싶은 것은, ‘아프리카 가서 기린보기’ 라던가 ‘스카이다이빙하기’ 와 같은 활동이 아니다.

‘인강 듣기’, ‘알고리즘 공부하기’ 와 같이, 내 능력을 키우려면 당연히 해야 하는 고통스러운 활동들이다.

지금까지는 이 고통을 참지 못해서 많은 일들을 미루고, 안하고, 대충했다.

해야 한다는 것을 안다면, 고통을 참고 할 줄 아는 사람이 되고 싶다.

📌 Action: 플래너에 ‘고통’ 카테고리를 만들어서 하루에 하나는 처리하기!

 

 

 

프로덕트 중심

그동안 내가 기술적으로 부족하다는 사실에만 매몰되어 있었던 게 아닌가 싶다.

소규모이지만 프로젝트는 많은 (^^) 스타트업에 일하면서 나는 꽤 많은 프로젝트를 처음부터 끝까지 알고 있고, 개발 외에도 관여해야 하는 부분이 있다. 사실 나는 이것에 대해 불만이 많았다. 모르는 것(기획, 디자인)을 해야 하고, 관심없는 도메인에 빙의해서 생각해야 하고, 관련 산업을 학습해야 하고.. 내 본업인 개발도 제대로 못하는 상황에서 이것들을 하는 것이 나와 서비스 모두의 lose-lose 전략인 것만 같았다.

하지만 결국 관점의 차이라고 느꼈다. 어쨌든 맡은 일은 제대로 해야 하고, 잘 해야 회사에 어필할 내용도 있다. 제품을 만드는 사람으로서 제품에 대해서는 알면 알수록 좋은 것이다. 단순히 내가 재미있고 재미없고를 떠나서 어느정도는 자부심을 갖고 내가 만든 프로덕트를 대하는 태도가 필요해 보인다.

 

 

 

“일정을 지키고자 버그가 많은 소프트웨어를 출시하는 것이 마음에 들지 않습니다”

관련해서 크게 스트레스를 받은 적이 있어서 회사에서도 동료들에게 급발진을 한 적이 있다. 그떄 받은 대답은, “버그는 찾으면 계속 나올건데 그럼 영원히 출시 못하는 것인가”라는 맥락의 내용이었던 것 같다. 인정은 했지만 뭔가 부족한 느낌이 들었는데, 이 책에서 말하는 내용이 부족함을 채워주었고, 급발진한 나를 반성하는 계기가 되었다.

"프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그 램을 기한 내에 완성하는 일이다." “일정과 퀄리티는 어느 한쪽 을 포기해야 한다와 같은 시소 관계가 아니라, 어떻게 하면 아무리 급해도 항상 80~90점짜리 소프트웨어를 개발할 수 있는지가 중요하다"

남에게 돈을 받는 개발자는, 프로다. 프로는 비즈니스 요구사항을 만족시켜야 한다. 비즈니스의 세계는 완벽한 것보다는 일정이 더 중요할 수도 있다. 아이폰을 처음 발표할 때에도 버그가 많이 남아있어서, 앱이 종료되지 않을까 노심초사하며 발표했었다는 썰이 있다!

 

2007년 아이폰 나올때…스티브 잡스도 떨었다

 

 

결론: 내 원칙은 뭘까?

서론에서도 썼듯이 나는 원칙도 없고 목표도 없다고 생각했다. 그런 내가 그나마 신경쓴 게 있다면 “사용자들이 서비스를 편리하게, 재미있게 사용했으면 좋겠다” 였다. 하지만 이건 참 추상적인 원칙으로 보였고, 내가 프론트라서 그거에 맞춰서 무의식이 만들어낸것만 같은 원칙 같기도 했다.

그래서 일단 지금은 모방한 원칙을 내 원칙으로 삼아보려고 한다. 그동안 내가 오만했음을 나타내는, 아마존의 원칙이다.

 

 

고객 최우선.

이 원칙을 지킨다면 “일정 맞추기 위해 버그 있는 제품 출시”가 가능하고, “일단 동작하게 만들고 나중에 고치기”가 가능하다.

또 고객이 컴플레인하는 내용에 대해 화나는 게 아니라 나를 겸허히 돌아볼 수도 있지 않을까..? 하는 부수적인 효과도 기대해본다.