�[전호영] 5,6장: 영웅, 선의 그리고 프로페셔널리즘. 동작하는 소프트웨어 (#14)

* 5장 전호영

* 6장 전호영

* 5장 서기

* 6장 서기

5장/서기.md

@@ -0,0 +1,54 @@
+# 서기
+
+---
+
+## 전희수
+
+### 5장
+
+**인상깊은 부분**
+
+- 스터디에서 유일한 기획자인데, 본인도 노력해보겠다라는 말이 어렵단 생각을 해왔음. 기획자입장에선 모든 기능이 구현되는 것이 중요함. 그러나 개발 리소스를 구체적으로 알지못하니까 개발자에게 “되나요?”를 많이 물어봄. 개발자는 “노력해볼게요…!”를 많이 말함. 이런 경우 “된다!”란 생각을 하고 계획을 짜왔음. 개발자가 안될수도 있다.. 라는 말을 하기에 그런 부분도 고려해야하지만 보통 기능이 바뀌면, 기능과 연결된 기능들이 다 바뀌어야 하는 경우가 있음(기획 문서, 디자인 등등등..). 그러다보니 안되는 것을 고려하지 않고 성공할 거란 생각으로 일을 진행해왔음. 기획자는 A 가 안되면 A’, A”는 ? 이렇게 물어봤던 경험이 있음. 이는 개발자에게 압박이 되었을지도… 기획자는 기능을 살리고 싶어하는데 이를 덜 부담스럽게 얘기할 방법이 무엇이 있을까? 고민하게 됨. A 가 안되면 A’, A”는 ? 이렇게 물어보기 전에 큰 틀에서 왜 안되는지를 먼저 알고 그 안에서 답을 찾아가면 더 좋은 커뮤니케이션이 될 듯!
+- 나도 상사와의 관계에서 ‘아니오’란 말을 잘 못했음. 해본 일에 대해선 “네”, “아니오”를 대답했지만, 해본 적 없는 일엔 나도 노력해볼게요! 를 말했던거 같다. 이를 통해 자아성찰도 했다.
+- 큐시즘에서 PM을 하고있는데, 아직도 개발 리소스와 일정을 제대로 파악하는 것이 쉽지 않다. 이럴 땐 개발자의 명확한 아니오와 진척 상황을 빠르게 아는 것이 중요할 것이라 생각함. 자발적으로 진척 상황을 말하고, 아니오를 말하는 것이 쉽지않다는 것을 알고있음. 이럴 땐 짧은 스프린트와 회고를 통해 개발자들의 상황을 자연스레 이끌어 내도록 노력해야겠음.
+
+---
+
+## 한상호
+
+### 5장
+
+**인상깊은 부분**
+
+- 스토리가 재밌었다. 마음 아픈 부분도 있었고 감정 이입도 했었다. 예전에 개발자들이 어떻게 개발했고, 어떤 취급을 받았는지에 마음이 아팠다. 요즘은 처우가 많이 좋아졌다 느낌. 우리나라도 IT가 발전하고 개발자가 창업을 하면서 개발자가 CEO, PM이 되면서 개발자에 대한 인식이 좋아졌음. 그게 아닌 몇십년전부터 이길을 걸어온 선배 개발자들이 많이 힘들었겠다 느낌.
+
+- 나도 취준을 하는 입장이고, 또 주변에 취준생들이 많음. 예전과 다르게 요즘 취업이 쉽지않다며 이렇게 비교하는 사람들이 있다. 그것도 사실이고 경기도 어려운게 맞음. 다른 신입들의 실력이 좋은것도 맞다. 그러나 다 이유가 있다고 생각함. AI, 더 많은 레퍼런스, 더 많은 멘토들이 있기에 다른 신입들의 실력이 올라갔다고 생각함. 중요한 것은 다른 사람들이나 내가 처한 환경보다 내 실력. 내 실력에 집중하는 것이 좋겠다 느낌. 나만의 가치를 만들려고 노력한다면 그 가치를 알아주는 사람이 있을 것이라 생각함. 취업을 한다고 개발자가 끝나는 것이 아니다. 취업을 하나의 과정이라 생각하고 마음을 편하게 먹으려 노력중. 취업해서도 계속 공부하고 스터디하고 그런 과정들이 있기에 길게 보고 준비해야겠다 다짐함.
+
+- 큐시즘 29기를 하면서 개발자로 많이 부족했다. 급급하게 기능을 구현할 생각만 했다. PM이나 기획자가 요청했을 때 의문보단 하겠다! 라고 했었음. 많은 것을 구현했고 이를 통해 한계를 극복하고 실력도 올랐음. 그러나 이 부분이 왜 필요한지 설명하지 못했고, 힘들게 구현한 기능을 실제 사용자가 쓰지 않아 허탈했었음. 이 경험을 통해 나중엔 기획에도 목소리를 내야지 다짐했다. 그 다짐은 30기에서 프로젝트를 진행할 때 기획에 많이 참여하려 노력하며 실천했다. 일정상 안되는 부분들은 안된다 쳐내며 개발을 진행했고, 이를 통해 좋은 프로젝트를 했다고 생각함. 5장의 많은 내용에 공감했고 재밌게 봤음.
+
+---
+
+## 강연주
+
+### 5장
+
+**인상깊은 부분**
+
+- 책을 읽으면서 지금 진행하는 밋업 프로젝트에 대입하게 되었고 반성하게 되었음. 백엔드 개발자로 프로페셔널하지 못했다 느끼는 부분이 많음. 책에서 ‘아니오’라고 말하지만 말고 대안을 제시해라! 라는 것을 읽으면서 느낀 점이 있음. 이번 밋업 도중 기능을 구현할 때 기준이 복잡해서 구현이 어렵다. 라고 기획자에게 전달한 적이 있음. 이때 불가능하다고만 했지 대안을 말하지 않았음. 이때 대안을 제시했으면 어땠을까? 느끼며 기획자에게 미안함을 느낌. 정렬이 불가능하다 얘기한 것도 처음엔 가능하다 말했지만, 개발하다보니 불가능하다는 것을 깨닫고 말한거라 늦은 감이 있었음. 먼저 넓게 볼 수 있는 사람이 되어야겠다 생각함.
+- 책에서 진척 상황 공유에 대한 얘기가 있었는데, 이번 프로젝트를 진행하며 개발 진행상황 공유가 원활히 되고 있지 않다 느낌. 책을 읽고 우리도 제대로 공유를 안하고 있었지! 반성을 하게 됨. 한달 남았는데 진행도를 꾸준히 전달해야겠다! 느낌.
+
+---
+
+## 이은학
+
+### 5장
+
+**인상깊은 부분**
+
+- 기업 프로젝트를 할 때 팀원들이 다 너무 잘했다. 동기들과 했던 프로젝트를 넘어 한 기업의 프로젝트를 맡았던게 조금은 겁도 났다. 기업 프로젝트 개발 3주차에 프론트엔드들은 많이 힘들지 않았을까 생각함. 그러나 지금 생각해보니 그때의 경험들도 좋은 경험이었음. 그때 개발한 부분이 지금 사이트에 적용되어 있어서 좋기도 했음.
+
+- 문제상황에 대한 가설을 세우지 않고 데이터를 그냥 분석했던 과정과 비슷했다. 무작정 분석하지 말고 고객 중심적 사고를 통해 고객에게 실제로 질문을 하거나 , 우리끼리 판단하지 말고 초반에 많은 커뮤니케이션을 통해 대안을 제시하는 것이 중요하다 느낌.
+
+- ‘아니오’라고 말하는 방법 배우기도 와닿았음. 개발자들이 무리하게 일정표를 만들고 우리에게 책임을 밀어붙이는 상급자가 많다.란 표현이 있었는데, 조금은 당연하다 느낄 수 있지만 자신의 의견을 숨기지 않고 말해야 효율과 능률이 오를것이라 생각함. 개인 혹은 팀이 생각하는 타협점을 제시하는 것이 더 좋은 협력을 이끌어낼 수 있을 것이라 생각함. 큐시즘 면접에서 받은 질문 중 하나가 마감 일주일전 디자인 팀에서 절반을 바꿔달라 하면 어떻게 할것이냐 물어봤었는데 난 그때 모든 요구사항을 다 받진 않을거같고 개발팀 안에서 의사결정을 해 기획과 디자인을 설득해 타협점을 찾아야한다라고 대답한 기억이 있음.
+
+- "코드의 품질 수준을 낮추고 야근과 휴일 근무를 연이어 하게 되면 모두가 지쳐 쓰러지고 프로젝트 전체가 위태로워진다." 이러한 문장은 좀 안쓰러웠다. 우리의 모습이 될 수도 있다는 생각이 들어서 마음이 아팠다.

5장/전호영.md

@@ -0,0 +1,60 @@
+# 기억하고 싶은 문장들
+
+p.107 - 108 </br>
+"우리는 일을 잘못하고 있었다. 당시 우리가 어떤 취급을 받았는지 떠올리면 가슴이 아프다. ... .우리는 전혀 프로답지 못했다. 한번도 '아니오'라고 말하지 않았기 때문이다." </br>
+p.108 </br>
+"특히 젊은 개발자들은 그러한 무리한 요구에 굴복하고 일정 안에 해보겠다는 약속을 하고 만다. 상급 관리자에 대항하는 것을 두려워하거나, 아니면 그냥 논쟁자체를 피하려고 한다. 그 모든 기능들을 주어진 일정 안에 완료한다는 것이 불가능함을 알고 있으면서도 상급 관리자의 요구를 그냥 받아들이고 그대로 실행한다." </br>
+
+- 나도 이러고 있는거 같다. 지금 밋업은 매우 좋은 팀원들과 함께 하고 있다. 다들 뛰어난 사람들이기에 그들의 부탁에 '아니오'라고 말하고 싶지 않았다. 그래서 다 '해볼게요!'로 일관한건 아닐까? 내 마음속에선 일정안에 할 수 없다는 것을 알고 있지만 '네'라고 대답을 한거같다. 책에서 나와있듯 프로라면 '아니오'라고 말할 수 있어야 한다.
+
+</br>
+
+p.113 </br>
+"상사에게 대항할 수 없다는 불편함과 전체 상황 자체에 대한 증오 말고도 그렇게 무책임하게 밀고나간 또 다른 원인이 우리 마음 속에 있었다. 마음 깊은 곳에서는 스스로가 얼마나 잘났는지 내보이고 싶었던 것이다. ...스스로 도박을 선택했다." </br>
+p.115 - 116</br>
+"차드 파울러는 저서 열정적인 프로그래머에서 그저 실망시키지 않기 위해 말하는 '네'는 거짓말에 지나지 않는다고 했다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 양의 탈을 쓴 나쁜 습관이다. ... '네'라고 말할 때 사람들은 그말을 믿고 그에 의존해서 계획을 짠다는 것을 반드시 기억해야 한다." </br>
+
+- 나의 마음속에도 영웅이 되고 싶은 욕망이 있었던거 같다. 할 수 없는 기술들이 있지만, 이를 해낼 수 있다는 것을 보여주고 싶었던거 같다. 이러한 마음속의 욕망을 버리고 '아니오'라고 말할 수 있는 사람이 되어야겠다. 내가 해내는 것! 보다 중요한 것은 팀의 목표를 이루는 것이다. 이 길이 아니라면 다른 길로 돌아갈 수 있어야 한다. 팀원들은 내가 한 말을 믿고 일정을 짜기에 내가 못하게 되면 일정이 많이 바뀐다. 쓰잘데기 없는 욕망을 버리자.
+  </br>
+
+p.117 </br>
+"우리가 '아니오'라고 대답해야 하는 상황에서도 항상 '네'라고 말할 방안을 탐색해야 한다." </br>
+
+- 공감한다. 무작정 '아니오'라고 말할 순 없다. 기획자에게 떠넘기는 것이다. '이건 안되니까 너가 다른 기술적 해결방안을 찾아봐!'가 되어버린다. 이는 옳바른 '아니오'가 아닌 무책임한 , 떠넘기는 '아니오'가 돼버린다. 그러기에 '아니오'에 더해 해결 방안을 함께 제시해야 한다. 기획자는 기획만, 개발자는 개발만! 은 아니다. 팀원이고 한 배에 타있기에 함께 해결책을 찾아야한다. 팀의 목표에 책임감을 가져야한다.
+
+</br>
+
+p.118 </br>
+"진척 상황을 가능한 자주 공유하는 것이 할 수 있는 최선의 방법이다." </br>
+
+- 나는 그러고 있었을까? 나는 진척 상황을 자주 공유하지 않았단 생각이 든다. 그저 언제까지 무엇을 해볼게! 는 말했지만 실제 그 안에서 어떻게 일이 진행되고 있는지를 말하지 않았다. 나 역시 다른 파트의 진척 상황을 물어보지 않았다. 그저 백엔드파트니까... 백엔드만 생각했다. 기술의 구현만 집중했다. 기획이 어떻게 되어가고 있는지, 디자인은 어떤 상황인지, 프론트는 어떤 상황인지 알지 못했다. 이는 나의 부족한 부분이다. 팀원들과의 소통이 중요하다. 소통을 잘 할 수 있다 생각했지만 그러지 못했다. 반성하게 된다.
+
+</br>
+
+p.122 </br>
+"팀의 전체의 역량은 그 팀안의 가장 약한 고리에 의해 결정된다." </br>
+
+- 현재 백엔드 팀에선 내가 약한 고리라 느낀다. 그렇다고 실망만 하고 있을 것인가? 이는 상황 공유를 통해 끌어올릴 수 있다고 생각한다. 팀원에게 내가 안되는 부분을 공유하고, 내가 할 수 있는 일들을 처리하고 분업을 해야한다. 애자일하게.... 한번 정해진 rnr이 끝까지 가야한다란 마음을 버리자. 공유하자 공유!
+
+</br>
+
+p.122 </br>
+"그리고 개발자가 다른 의견을 제시하거나 지시사항에 반대할 때도 긍정적으로 받아 들인다. 왜냐하면 문제를 숨기지 않고 드러내는 태도는 모두가 하나의 팀으로서 공동의 목표를 위해 일하고 있다는 징표이기 때문이다." </br>
+
+</br>
+
+p.122 - 123 </br>
+"좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소들을 제거한다. ... . 관리자는 화합의 촉매가 되어야 한다. 팀을 건강하고 행복하고 단결되게 하는 것은 관리자의 직무다." </br>
+
+- 왓에버데이에 pm을 맡게 되었다. 내가 할 수 있는 일들에 대해 고민하게 되었다. 난 기획, 디자인에 대해 잘 모른다. 그렇기에 섣불리 그들의 작업에 참여할 순 없다. 그 대신 내가 할 수 있는 것은 무엇일까? 팀원들의 화합과 의사결정이란 생각이 든다. pm을 맡아 고민도 좀 생겼고, 부담도 조금은 있었는데 위 문장을 통해 내가 해야할 역할을 조금은 알게 되었다.
+
+</br>
+
+p.123 </br>
+"프로페셔널들이 그들의 경험과 지식을 활용해 그 문제를 다룰 방법들에 어떤 것들이 있고 각각의 장단점은 무엇인지를 알려주길 기대한다." </br>
+
+</br>
+
+# 느낀점
+
+밋업 프로젝트와 왓에버데이를 준비하며 느꼈던 고민들이 많이 녹아있었다. 특히 개발자가 가져야 할 태도와 내가 해왔던 잘못된 행동들에 대해 반성하게 되었다. 팀의 성공을 위해 노력한다 했지만 정말 그랬을까? 반성하게 된다. 내가 우리 팀 아이디어, 진척 상황에 많은 관심을 가졌을까?도 생각하게 된다. '아니오'라고 말하는 것의 중요성을 안다고는 했지만 정말 알았을까? 팀 프로젝트의 순항에 가장 중요한 것은 '아니오'란 생각이 든다. 내가 할 수 있는 일과 없는 일, 불확실한 일을 구분할 줄 알아야 한다. 내가 고민하던 부분들을 많이 해결할 수 있었고, 최근 내가 느꼈던 나의 태도에 대해 반성할 수 있었던 챕터였다.

6장/서기.md

@@ -0,0 +1,36 @@
+# 서기
+
+---
+
+## 전희수
+
+### 6장
+
+**인상깊은 부분**
+
+- 협업을 할 땐 각 단계마다 많은 사람이 있으니까 한 단계에서 머무르면 일이 잘 진행되지 않는 경우가 많음. 이때 빨리 끝내는 것과 허술함의 차이를 책을 읽으며 다시 느끼게 되었음.
+- “아무리 한탄하고 불평해도 … 그에 맞는 행동을 취해야한다.” 이 글을 읽고 어제 작업하다 자아성찰 했던 경험이 떠오름. 입만 산 사람이 되고싶지 않기에 부족하고 아쉬운 점들을 봤다면 이를 해결을 하기 위해 행동하는 사람이 되자! 라고 느낌.
+- 밋업을 하면서 느낀 부분인데 한번에 문제를 해결하기 보다 차근차근 문제를 해결해나가는 자세를 가져야겠다! 느낌.
+- 6장은 매우 개발적인 내용. 그래서 기획자 입장에선 좀 읽기 어려웠음. 그러나 레거시와 같은 내용을 기획의 내용에 빗대어 읽다보니 또 즐겁게 읽을 수 있었다!
+
+---
+
+## 한상호
+
+### 6장
+
+**인상깊은 부분**
+
+- 이전에 코드를 짤 땐 돌아가게 하는 것을 목표로 했음. 지금보면 아쉬움이 남음. 이전 코드들에 대한 리팩토링도 하고싶음. 그러나 다시 돌아갔어도 당시 나의 최선이었기에 다르게 개발하진 못했을거 같다. 그러나 지금은 단순 구현에 집중하는 그런 단계를 넘었다고 생각함. 타협할 수 없으니 만드는 것에 초점을 두지 않고 잘 만들어야지!에 집중하게 됨. 지금 밋업엔 기능완성의 기준을 테스트코드까지 다 작성했을 때를 기준으로 잡게됨.
+- 피할 수 없으면 즐겨라! 이 말은 그냥 있는 것이 아님. 크든 작든 문제가 생기면 이를 고통스럽게 여기지말고 재밌게 내가 해결할 문제! 라 생각하는 것이 더 좋은 마인드라 느낌.
+
+---
+
+## 강연주
+
+### 6장
+
+**인상깊은 부분**
+
+- 반성을 하게된 챕터. 밋업 1차 MVP를 빠르게 만들고 리팩토링을 진행했는데, 리팩토링이 개발보다 2배 시간이 더 걸렸음. 개발자는 실행 가능한 코드보다 리팩토링과 테스트코드 구현에 더 많은 노력을 해야하는구나를 몸소 느낌. 2차 기능 개발에 들어가기 전에 코드를 정리할 수 있어서 다행이라 느낌.
+- 아쉬운 것은 모든 케이스에 대해 테스트코드를 짜지 않은것. 아직 모든 API가 정상 응답한단 보장이 없음. 2차 기능 개발 전엔 테스트코드를 다 작성하고 넘어가야겠다 느낌. 사실 어떤 테스트코드를 적어야 하는지 알지만 외면하고 있었음. 2차 전엔 꼭 테스트 코드를 써야겠다 다짐함!

6장/전호영.md

@@ -0,0 +1,27 @@
+# 기억하고 싶은 문장들
+
+p.133 </br>
+"우리는 항상 업무와 일정의 압박 속에 있다는 생각을 가지고 있다. 언제나 급하게 일해야 한다고 느낀다. 비즈니스 팀이 일정에 관해 압박을 할 때도 있지만 스스로 쫓기는 경우가 대부분이다."
+"우리는 압박을 받는다고 느낄 때 중심을 읽고 고만고만해진다. 게으른 탓이 아니다. 더 빨리 해야한다고 느끼기 때문에 그렇게 한다. 비즈니스에서 필요로 하는 기능을 최대한 빨리 끝내는 것이 개발자로서 미덕이라고 느끼고 있다. 상황을 솔직하고 투명하게 밝히고 며칠 더 늦게 안정적인 솔루션을 전달하기보다 버그가 좀 있더라도 일정 안에 전달하는 편이 더 낫다고 느낀다. 빨리 하는 것과 허술한 것은 다르다." </br>
+
+- 나는 일정을 맞추는 것이 가장 중요한 일이라 생각했다. 물론 중요한 것은 맞다. 그러나 이 생각에 너무 사로잡혀 빠른 제품이 아닌 허술한 제품을 제공했던 것이었구나를 느꼈다. 최근 밋업을 할때도 일단 빠르게!! 를 목표로 했다. 문제는 빠르게 개발을 해도 오류가 있었고, 옳지 못한 코드들이 있었다. 이를 고치느라 시간이 더 들어가는 경험을 했다. 빠르게 하는 것이 중요한 것이 아니라 올바르게 하는 것이 중요하다. 이를 명심하고 개발을 해야겠다.
+
+</br>
+
+p.137 </br>
+"첫 번째로, 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다." </br>
+
+</br>
+
+p.141 </br>
+"태도는 큰 차이를 가져올 수 있는 작은 요소다." </br>
+p.144 </br>
+"일을 즐길 수 있느냐 없느냐는 우리의 태도에 달려 있다." </br>
+
+- 생각을 해보면 내가 삶에서 바꿀 수 있는 것은 나의 태도밖에 없다. 다른 사람을 바꿀 수 없다. 날씨가 안좋다고 날씨를 바꿀 순 없다. 내가 할 수 있는 것은 나의 태도를 바꾸는 것 뿐이다. 곧 내가 나의 태도를 바꿀 수 있다면 모든 것을 바꿀 수 있다는 것이라 생각이 든다. 태도가 전부다.
+
+</br>
+
+# 느낀점
+
+최근 나의 고민들과 나의 상황은 5장에서 많이 공감했다. 6장에서 나의 마음에 남는 것은 태도다.'아니오'라고 말하는 것도 '아니오'의 태도가 아닌 문제를 해결해야겠다!의 태도로 접근하는 것이다. '현재 이 방법은 여러 이유로 안될 것 같으니 다른 해결책을 찾아볼게요!' 의 태도를 가지는 것이다. 나의 태도가 나의 삶을 결정한다. 너무 크게 생각하는 것일 수 있지만, 내가 바꿀 수 있는 유일한 것이 나의 태도란 것을 다시 한번 느끼게 된다.