Growth Developer

Growth Developer - 주니어 개발를 위한 성장 지침서

총평
제법 공감이 많이 되었다. 실제 일하면서 많이 느꼈던 점들... 
약간은 읽으면서도 찔리는 부분들이 좀 있었고.. 작은 위로였던 점도 있던 것 같다. 

나처럼 개발 경력이 많지 않는 사람이 개발에 대한 마음가짐에 대해서 다시 생각해보는 계기가 되었다고 생각한다. 
아래 내용들은 읽으면서 형광펜 친 것들만 좀 적어보았다... 다시 기억해두고 싶었다.

---

Contents

1. 마음가짐

- 문제의 원인은 바로 당신이다.
"하지만... 그럴리가 없는 것이 나는 기존 api를 건드리지는 않앗는걸??? 새로운 api를 추가만 했지"
거의 모든 문제의 원인은 당신 일 것이다. 

문제의 원인을 당신으로부터 출발해서 찾으면 가장 빠르게 근본에 도달할 가능성이 높다.

실제로... 현장에서 일하다보면.. 하.. 이런 저런 생각들이 새록새록 드는데
분명히 누군가 건드렸다. 누군가 건드렸기 때문에 될 것이 안되는 것이다. 또는.. 자신이 만든 결과물의 출력값이 뭔가 이상한 것이다.
왜냐면 컴퓨터는 결국 시키는 대로 하는 것이고, input / output의 결과를 항상 확인해야한다. 결과물을 크로스체크 할 줄 알아야한다.
그래야만 내가 나자신에게도 당당하고 남에게도 당당 할 수 있는 것이다. 

- 당신은 선배보다 낫다

후배들이 선배들로부터 느끼는 격차는 익숙함의 차이에 지나지 않는다.

맞는 말이다. 저들도 곧 익숙해진다.그렇기 때문에 동등하게 대우해야하는 것이다. 아이로 보지말고 동료로 보아야한다.

- 야생에서 살아남으려면

- 더 이상 아이가 아니다

리더십이라는 것의 본질이 사람들로 하여금 같은 목표를 향해 스스로 방향을 정하고 움직이게하는 힘.....

리더쉽과 팔로워십은 같은 것이라고 생각한다. 자기의 주어진 역할을 잘 이해하고 거기에 맞는 긍정적 영향력을 팀과 동료들에게 행사할 수 있다면 지위고하를 떠나서 그 사람이 리더인 것이다. 

리더가 마음에 들지 않으면 결국 다른 사람이 리더가 된다. 보통 그렇게 되는 것 같다. 위에 있던 아래에 있던, 리딩하는 사람이 생긴다. 

바쁜 선배들이 나에게 일을 주지 않는 것 같이 느낀다면 일을 줄때까지 기다리지 말았으면 한다.

자기가 잘 알고 있는 것에 대한 요구를 귀찮아할 선배는 아마 없을 것이다. 이러한 요구를 구태여 내가 먼저 적극적으로 해야하는 이유는 명확하다. 더이상 아이가 아니기 때문이다.

... 이 부분은 실제 그런 사람들이 있다. 
나에게 일을 주지않는다. 나에게 관심이 없다... 그러나 사실은 각자 모두에게 상사가 있고, 각자 일을 하기에 바쁘다. 적극적으로 물어보고 소통해야하는 것이 맞다고 본다. 아니라면... 일에 대한 애정이 식었기때문에 투정을 부리는 것일 수도 있고.. 아무튼 개발자라면 노력해보고 영 아니라면 이직하는 것도 답이라고 본다.

- 성장하지 않는 것 같아요

경험이 늘어날 수록 내가 어떤 문제를 풀었었고 앞으로는 어떤 문제를 푸는 것에 기여할 수 있는지에 더 포커스를 맞추게된다. 본인의 이력을 정리하는 활동은 커리어 생애전반에 걸쳐 지속적인 경력에 대한 회고를 가능하게 해준다.

지금부터라도 내가 참여했던 프로젝트나 풀었던 문제. 나의 역할과 기여했던 부분들, 깨달은 점들을 잘 정리해두는 것을 추천한다.

내가 이런 부분이 부족했었다. 그냥 잘 달려가기만 했던 것 같다. 마치... 당나귀 코앞에 있는 당근만 먹으려고 노력했던 점.
당나귀의 주인이 되었어야했는데 말이야.

회사나 선배들이 나를 성장시켜줘야하는 의무가 있는 주체라고 생각하지 말았으면 한다. 성장은 누가 시켜주는 것이 아니라 스스로 하는 것이다..... 더 빠르게 성장하고 싶다면 주어진 프로젝트에 더 적극적이고 열정적으로 참여하길 바란다.

성장하는 방법에 쉬운 지름길은 없다는 것. 책임과 성과는 온전히 나의 몫이라는 것을 항상 잊지 않는 것.

하지만.. 운도 따라줘야겠지. 하지만.. 노력은 해야하지

나를 성장시키는 주체는 바로 나다.

 

2. 문제해결

- 재현 방법을 찾아라

처음부터 신경써서 제대로 접근하면 결국 누구나 풀 수 있는 문제일 텐데 왜 우리는 코드부터 짜려고 할까?

아직도 고쳐지지 않는 습관. 항상 코드 구조화와 생각부터 하고 손을 두드려야한다. 안다..아는데...

어쩌면 문제를 정직하게 다루려고 하는 태도가 천재성의 원천이 아닐까?

문제가 발생 했을때는 그것을 재현할 방법을 찾고, 그 재현 자체를 간단하게 할 수 있는 체계를 구축한다면 뛰어난 문제해결력을 보여줄 수 있을 것이다.

이 소절. 절대 공감된다.
하드웨어에서는 이런 문제를 해결하기가 참 어렵다. 로그가 남는 시스템도 아니었었고.. 추정만으로 해야하는 약간 원시적인 느낌인지라..이런거를 차차해결해야하는 과제이고, 어쨌든... 좀 다른 각도에서 보았을때, 퍼포먼스 테스트도 비슷한 맥락이다.
퍼포먼스 테스트를 위해 한번 제대로 코드를 짜두면..(아주 하드하게 테스트 할 수 있는 코드를 작성) 통신이 제대로 되는지 확인이 가능하다. 

- 문제를 풀기위한 기술

어떤 기술로 문제를 풀었는가?가 아니라 이 문제를 풀기 위해서는 어떤 기술이 필요한가? 이다.

- 서비스 상태에 대한 직감

- 문제를 외면하지 마라

강한 어조로 부르짖건데 문제해결에 관심없는 개발자들은 그냥 이 분야를 떠나는 것이 맞다고 본다.
우리가 가져야할 자세는...... 적극적으로 달려드는 것이다.

나로부터 기인한 문제임을 모두에게 밝힐 수 있어야하고, 남이 내 문제였음을 밝히는 것에 분노하지 않아야한다.

중요한 것은 서로가 서로의 코드에 대해 논의하고 조언할 수 있어야하고 그 속에서 나오는 갈등을 잘 관리할 수 있어야한다.

입장을 바꿔서 내가 들어도 도움을 줄 수 있을 만한 디테일을 담아서 문제해결에 대한 도움을 청하길 바란다. 동료들이 무관심한게 아니라 내가 너무 무성의한 것이다. 

문제 해결은 적극적으로 해야한다. 나도 그랬다. 그리고 빨리 손 떼고 싶어서 더 적극적으로 했다. 그래서 그렇게 되었다.
문제가 있으면 공유했다. 아무래도 한번...두번... 동일한 오류가 나면 사람이 경험적으로 학습되어, "야 이거 그때 그 문제 아니야??" 라면서 나를 또 후벼판다. 그러면 결국 또 확인해보고, 나는 또 대책을 세우고 고치고... 이런 피드백이 결국 나를 강하게한다. 하지만 그런 말을 하기전에 잘 확인해보고 해야한다.  

- 고장률 제로라는 목표의 함정

엔지니어의 이상과 비전으로써 고장이 없게하는 것은 응당 추구할 만한 가치이지만 목표로써는 애초에 달성이 불가능하기 때문에 부적절하다고 생각한다.

조직에서의 목표란 바로 성과평가로 이어지는 것을 감안 할때, 만약 고장이 난 횟수 자체로 개발자의 성과에 페널티를 주는 목표가 있다면..개발자들을 빠른 문제 해결보다 문제발생 원인과 관련 없음을 증명하는데 온 힘을 쏟을 것이다.

<고장률 제로> 라는 목표가 그 원인이었을지도 모른다. 오히려 문제가 발생한 상황을 빠르게 파악할 수 있는 체계를 갖추는 것과 유관조직에 전파하며 가시화시키는 것이 우선시되는 목표와 환경이 장려되어야한다.

진짜 필요한 목표
1.신속한 장애감지
2.수준높은 장애의 극복
3.동일한 유형의 장애가 재발하지 않는 것

프로젝트가 진행되면서 문제해결은 적극적으로 하게된다.
좀 더 시간이 지나면 "조금 문제가 있어도 빠른 대응을 해주면되겠지"라고 덤덤하게 생각하게된다.
좀 더 시간이 지나면 "야 이거 저쪽 팀 문제 아니냐? 원인 찾아봐" 원인이 나오면 팀 간에 말이 격해진다.
진정한 목표를 서로 인식하는 것. 그리고 개발자들간에 대화를 유하게 할 줄 아는 것. 대화를 할 줄 아는 법. 적을 만들지 않는 것.
하지만 위에 다 맞는 말인데, 현실 환경도 좀 고려해야한다. 원체 이 korea에서는 프로젝트기간이 넉넉하지 않으니까...
시간이 부족한데 자꾸 막히고, 뭐가 안되는데 원인도 안나와. 팀들간에 격해진다.
프로젝트 기간과 인원배치, 역할 배분... 정말 세심하게 계획해야 프로젝트가 잘되지 않을까? 목표 설정이라는 건 참 어렵다. 

3. 개발

- 할당만큼 중요한 해제

의도대로 동작하지 않은 경우.. 오히려 메모리 관리를 제대로 하지 못해서 문제가 발생할 가능성이 크다.
빌게이츠가 1981년에 "640kb의 메모리면 모두에게 충분하다" 라고 말했던 시절을 떠올려보면...

모든 할당(allocation)에는 해제(deallocation) 전략이 함께 수립되어야한다.

- 생명유지활동과 리팩토링

리팩토링이란 것도 우리가 건강을 유지하기위해 하는 활동과 비슷한 것이라고 생각한다. 프로그램 자체를 생명으로 본다면 그 생명이 최적의 상태를 유지할 수 있도록 끊없이 개선활동을 해야하는 것이다.

개발자들이 할애하는 리팩토링시간을 충분히 인정하고 존중하는 것이다.

- 고장지점은 분산하고 관리지점은 집중하라

- 하나의 프로세스에서 출발하라

아주 커질 가능성이 있는 제품을 만들 예정이라면 하나의 프로세스에서 돌아가는 것부터 출발하는 것이 좋은 접근법이 될 것이다.

- 표준화를 위해서는 사례를 공부하라

핵심적인 부분만 추출하여 문제를 간결하고 이해하기 쉽게 만드는 추상화(abstraction)능력이 요구된다. 

자동차 사고도 한번 당해보면 그다음부터 사고를 안낸다는 말처럼 큰 서비스 장애를 겪고 나니 마음가짐아나 생각하는 방식이 달라지는 계기가 되었던 것 같다.

비슷한 기능을 계속반복해서 쓰고 있었다.... 코드 작성없이 운영툴만으로 설정할 수 잇는 체계를 만들었다.(표준화를 달성했다)

어떤 일을 표준화하고 싶다면 과거와 현재의 많은 사례를 수집하고 공부하길 바란다. 결국 지배적이고 핵심적인 문제가 무엇인지 보일 것이다.

 

4. 협업

-눈높이에 맞게 단어를 선택하라

엔지니어들은 자신이 알고있는 기술에 대해 늘어놓기를 좋아한다.

상대방은 이해하지 못하는 어려운 기술 용어를 남발하면서 스스로 만족해하며 자신의 자신의 가치를 증명하려고하는 것이 그것에 대한 안좋은 예가 되겠다.

우리의 가치는 문제를 해결해 내는 성과를 통해서만 증명된다.

누군가에게 무엇을 설명을 할 수 잇다는 것은 그것보다 10배를 더 알고 있다는 뜻과 같다는 말이 있을 정도로 내가 알고있는 내용을 남에게 명하는 것은 결코 쉬운 일이 아니다.

지식의 완성도는 누군가에게 나누어 줄 때마다 견고해진다.

서로의 눈높이를 맞춰가며 함께 일한 사람들끼리 대화를 나누게 되면 기술과 무관한 직무에 있는 사람의 수준도 점점 높아져서 어느 순간에는 노력을 덜 들여도 충분히 소통할 수 있게 된다. 그리고 그들은 당신에 대해 개발자 치고는 드물게 대화라는 것이 가능한 실력있는 엔지니어라고 생각 할 것이다.

- 일정은 협의하는 것이다.

사람들이 시간이라는 귀중한 자원을 두고 흥정을 한다. 개발자가 선언하는 개발일정에는 무게감과 신뢰가 있어야한다.

같이 일하는 사람들이 내가 제시하는 일정을 믿지 못하는 것 같다면 의심해보자.
1) 나는 정말 제대로 된 일정을 산정 할 수 있는가? (역량의 문제)
2) 나는 내가 약속한 일정을 잘 지켰는가?(마인드셋)

비즈니스 세계에서 일어나는 모든 개발활동은 투자이다. 시간에 대한 투자이기도 하고 돈에 대한 투자이기도 하다. 

신뢰를 단번에 잃게 만드는 가장 최악의 대답은 "나도 모른다. 해봐야안다" 이다.
정말로 모를때는 "선행기술 조사 후 반드시 피드백을 준다" 라고 해야한다. 

프로는 일정을 산출할 수 있어야한다. 모든 개발활동은 투자이기 때문이다.

난... 일정산출에 있어서는 아직 멀었네.

- 누구나 빌드할 수 있어야한다.

다른 PC환경에서 테스트해봐야한다.

gitignore 처리하는 것을 습관화하자.

코드베이스를 빌드가능한 상태로 유지하는 것은 꽤 정성이 필요한 작업이다.

맞아... 너무 귀찮지만.. 최신화하기위해서는 어쩔 수 없다. 나를 위해서. 또 새로 올 사람들을 위해서.

프로젝트의 크고 작으므이 여하에 관계없이 빌드 머신은 꼭 도입해 보았으면 좋겠다. (CI/CD 솔루션 :Continuous integration, deployment)

새로운 프로그래머가 팀에 합류했다면 오전에 환경 구축후 소스를 받고, 오후에는 작업한 내용을 빌드, 테스트, 배포까지 할 수 있어야한다.

- 동기식으로 일할 것인가? 비동기식으로 일할 것인가?

인간의 대표적인 출력기관인 입과 손은 아주 느리다. 엄청난 프로세싱 하드웨어를 가지고있음에도 불구하고, 정보공유하는 필요한 I/O작업 때문에 무지막지한 병목현상을 겪게되고, 사람이 많아질 수록 정보의 불균형이 가속되면서 개발이 산으로 가게되는 이상한 현상을 맞이하게된다. (맨먼스 미신: The mythical Man-Month)

느려터진 신체 I/O를 감안할때 적절한 상태동기화 기법이 요구된다. (Asynchronous vs Synchronous)

-좋은 개발팀에서 일하고 싶다면

개발팀의 존재목적은 쓸 수 있는 소프트웨어를 만드는 팀이다.

결과를 내지못한다면 우리의 소중한 시간은 하수구에 흘려보내는 폐수처럼 방류되고있는 것과 같다.

좋은 팀의 조건
1) 절제된 통제속에 주어지는 자율적인 참여를 통해 나의 잠재력을 끌어내는 곳
2) 핵심가치에 전념할 수 있게 해주는 것
3) 누구든 반대의견을 낼 수 있는 곳으로 가야한다.
4) 의사결정은 의사결정자만 하는 것이 차라리 낫다.
5) 만들고 있는 제품에 대해 구성원 모두가 애정이 있어야한다.
6) 팀의 모든 부문에서 미래 지향적 상승의지가 느껴져야한다.

5. 차별화

- 고객과 사용자의 차이를 아는 것

고객은 그 가치를 사용하기위해 비용을 지불하는 사람이다.
사용자는 단어 그대로 소프트웨어를 사용하는 사람이다.
결국 돈을 받고 일하는 개발자들이 만족시켜야할 대상은 본질적으로는 고객인것이다.
(결국 일반 사용자들을 만족시켜야 하는 것이 되겠지만..)

고객을 정확하게 파악하지 않으면 요구사항이라는 이름의 탈을 쓴 쓰나미에 휩쓸려 다닐 가능성이 높다. 

나라는 존재가 단순히 고용주의 만족만을 위해 돈을 받고 일하는 노동자에 불과하다는 느낌이 든다면, 불편하다고 해도 그것은 진실이다. 

사용자의 의견은 소중하지만, 사용자들이 우리가 무엇을 해야 할지 결정하게 하는 것이 절대 아니다.

중요한 메세지는 고객과 사용자를 분리해서 생각할 수 있어야한다는 것과 그들이 당신의 할 일을 결정하게 하지 말라는 것이다.

운영을 하다보면.. 아무래도 주객(?)까지는 아니지만, 사용자의 의견이 개발이슈가 되는 케이스가 가끔 있는 것 같다. "~~ 가 불편하데... 이거 고쳐야할 거 같아.." 라고 하는 건 좋은데, "~~가 불편하데!!!! 와... 야 이거 빨리 개발해야해!!" 는 아니라는 거지.. (공감된다)

- 취미개발자

스스로 나의 고객이 되어본다면 새로운 재미를 느낄 수 있게 된다. 

취미로 시작하고 나서 어떤 지점까지 도달할 때 비로소 취미 개발로 얻을 수 있는 이점을 극대화 할 수 있다.
이런 소수의 산출물이 나의 인생과 커리어에 가장 많은 도움이 되었다.

-인터페이스를 중요시하라

적어도 성공한 프로젝트들에서 사용자 경험(UX)이 뛰어난 유저 인터페이스를 가졌다는 점이 공통적으로 관찰된다.

예쁘게 설계된 인터페이스를 보면 굳이 개별 구현체 코드를 자세히 들여다보지 않더라도, 함께 일하고 싶은 개발자라는 인상을 강하게 줄 수 있다. 

인터페이스 설계가 중요한 이유는 개발된 이후에는 스펙을 변경하기가 아주 힘들다는 것이다. 설계단계에서 깊은 고민이 필요하다.

 

- 제안서를 써라

글을 쓰는 것은 싫어하는 개발자들이 많다. 코드 작성 전에 글로 표현할 수 있는 사람이 있다면 어떤 조직에 가나 인정받는 개발자가 될 수 있다.

의사결정을 하는 사람들은 모든 것을 한눈에 보고 결정하고 싶어한다. 결정해야할 것들이 너무 많기 때문이다. 
주어진 시간내에 판단을 내릴 수 있는 종합적인 근거들을 제시하지못하면 의사결정과 실행으로 이어지기 힘들다.

제안서를 작성해서 선배나 팀장에게 건내보자. 당신을 특별하게 생각할 것이다. 

생각에서 머무는 것과 실질적인 행동을 끌어내는 것은 완전히 다르다.

정성들여 계획서나 제안서로 만들어보면, 작게는 내 생각을 정리할 수 있고, 크게는 다른 사람의 생각을 바꾸고, 행동을 이끌어내는 효과를 거둘 수 있을 것이다. 

---

너무 구구절절 맞는 말들이다. 

최근에 읽은 책 중 가장 많이 공감이 갔으며, 책의 분량도 적어서 마음에 들었다. 

그리고 나를 다시 한번 더 돌아보게된다. 내가 분명 잘 수행한 것도 있고, 생각하지 못했던 것도 있었다.

초보 개발자라면 한번 일독을 권한다.