try anything chris!

커피 세계사

뭐든창하 — Sun, 10 May 2026 16:17:43 +0900

커피란 무엇인가!?@_@

# 최초의 커피 이야기 '염소치기 칼디' 발견설
칼디라는 이름의 염소치기 소년이 키우던 염소를 산으로 데려갔을 때, 염소들이 지나치게 흥분한 모습에 신기한 나머지 지켜보니, 염소들이 풀섶에 열린 빨간 열매를 먹고 있었음. 소년도 따라 먹어 보았더니 왠지 기분이 좋아져서 염소들과 춤추며 놀았다는 이야기

# 커피의 전파
차는 5000년, 카카오는 4000년의 역사를 가지고 있지만, 커피는 10~11세기경 잠깐 드러냈으나 400년간 문헌에서 사라졌다가 15세기경부터 다시 등장되었다. 이슬람 지역에서 수피가 디크르(창념)의 졸음 방지를 위해 마셨던것이, 이슬람 학자와 학생들의 학업과 업무 능률향상에서부터, 일반 시민에까지 기호 식품으로 전파됨.

이후 대항해 시대, 지중해를 통해 유럽전역에 전파됨. 예멘의 항구 아덴과 모카를 통해 주로 유럽에 이동되었으나 아덴의 내란으로 모카가 중심지가 됨. 이때부터 '모카' 라는 이름이 커피의 대명사로 유럽 사람들에게 알려짐.
유럽의 국가(네덜란드, 영국, 프랑스, 독일, 오스트리 등등)들 별로 커피의 유행은 너무 길고 복잡한 이야기라 생략.
미국에서는 영국의 영향으로 차를 즐겨마셨으나, '보스턴 차' 사건을 계기로 미국 독립전쟁이 발발하고 미합중국이 탄생하고
차에서 커피로 대체되는 계기로 작용하면서 커피 소비 증가가 이뤄짐.

이후로 커피 소비가 증가하면서 커피 나무에 대한 재배에 관심이 집중됨.
종자와 묘목 반출에 대한 경계 심화. 기후와 품종에 대한 전문화.
인도네시아 자바 섬을 중심으로 모카에서 '자바' 산지의 커피가 시작됨.

커피 묘목이 유럽에서 중요한 외교가 됨.
유럽은 2차 백년전쟁이 한창일때 해외 식민지 국가들을 이용해 노예들을 혹사시켜 수익을 올리기 위해 커피 나무를 재배함.
이 시기에 훗날 세계 최대 커피 대국을로 성장하는 브라질에 커피 나무가 첫 뿌리를 내림.

# 1차 커피붐(1820~1840년대)
유럽의 대륙봉쇄가 풀어지고, 유럽 전체적으로 소비 확대가 일어남. 브라질의 커피 증산에 따른 가격 인하도 뒷받침함.
커피붐의 중심은 중산층 시민과 지식인들. 이 시기에 '맛있는' 커피의 요구가 시작되었고, 커피콩의 산지와 추출방법에 대한 다양한 연구와 방식이 생겨났다. 이 당시에 '드 벨루아의 포트'라는 현재의 드립식의 원류에 해당하는 추출기구가 최고의 평가를 받음.
모카포트, 커피 사이폰, 커피프레스 등 지금도 많이 볼 수 있는 추출기구들 대부분이 이 시대에 기원을 두고 있음.

# 2차 커피붐(1870~1880년대)
유럽에서는 영구의 산업혁명과 크림전쟁으로 노동자 계급의 커피 소비가 확대되었음.
미국에서는 1857년 경제공황과 1860년대 남북전쟁으로 커피 소비가 잠시 정체되었으나, 전쟁당시 보급으로 음용하던 커피를 전쟁이 끝나고 고향에 돌아간 병사들이 계속 구매하면서 미국이 세계 최대 소비국으로 발돋음함.
미국과 독일의 공업화가 급격하게 진행되면서 공업 노동자가 급증하고 이들의 커피 소비가 계속 증가하면서 2차 커피붐이 찾아옴.
이 시대에 대량소비를 용이하기 위한 대량 배전 기술이 발전함.

카리브해의 안정적인 커피 생산
영국령 자메이카에서 18세기 후반, '블루마운틴'의 원조 커피를 재배함으로 2차 커피붐당시 최고급 커피로 분류됨.

18세기말, 커피 녹병이 발생하여 스리랑카와 인도의 커피를 괴멸시킴.
중앙아프리카 콩고에서 녹병에 완전 내성을 지닌 신종을 발견하고 '로부스타종'이라는 이름을 붙임.

# 모카와 아이티의 쇠퇴와 중남미의 부흥
19세기 중반, 브라질의 리우외에 상파울루등 새로운 개척지로 커피 농장이 생겨남.
상파울루에는 '테라로사'라 불리는 적자색 비옥한 토양으로 많은 농원을 만들 수 있었음.
브라질외에 코스타리카, 베네수엘라, 콜롬비아, 과테말라, 엘살바도르, 니카라과 등도 가세하여 가격이 폭락하고, 이 가격 폭락으로 커피붐을 더 가속화 시킴.

2차 커피붐 이후 공급량이 수요를 웃돌아 커피 가격이 계속 하락함.
커피왕 '허먼 질켄'의 매점매석으로 유통량을 조작하여 커피 가격을 올려 폭리를 취함.
하지만 1차 세계대전으로 유럽으로 커피 수출이 막혀 다시 커피 가격이 폭락하지만, 한편 미국은 갈길을 잃은 중미산 고급 커피가 저렴하게 미국으로 유입되는 수혜를 받음. 또한 미국은 이 커피를 북유럽으로 재수출하면서 새로운 벌이를 창출함.
이 시기에 미국에서 연합군으로 파병된 병사들에게 인스턴트가 개발되어 보급되었음.

1939년 2차 세계대전으로 중남미의 커피 수출길이 막혀 커피 가격이 더 폭락함.
미국은 미국이 일정가격으로 매입할 수 있는 '환미커피협정'을 통해 중남미와 결속을 강화하고, 독일 이민자가 많은 생산국들이 파시즘화 하는 것을 막고, 커피가 추축국으로 유입되는 상황을 방지함.
당시에 전시에 전선의 병사에게 우선 지급함에 따라 시중에 커피가 절대적으로 부족해짐.
이 당시에 옅게 마시던 습관이 일반화되어 흐리고 약한 '아메리카노'가 정착되어 오늘날까지 이어지고 있음.

2차 세계대전이 끝나고 커피가 시장으로 돌아왔으나, 브라질에서는 생산 제한과 인플페이션 속에서도 미국의 일정 가격 매입으로 수지타산이 맞지 않아 커피 생산자들의 '커피 이탈'로 커피 재고가 바닥남.
공급이 부족해 가격이 급등했지만, 저렴한 가격에 익숙한 미국 소비자들은 받아들이기 쉽지 않아 묽은 아메리카노를 마시거나 커피 대신 콜라같은 청량음료를 마심. 종전 후 독립한 아프리카 국가들에서 계속 재배했던 로부스타가 미국에 유입되기 시작함.

쿠바 혁명의 발발로 카리브해의 사회국가 탄생으로 미국에 반세력이 생겨나자, 중남미에서 '제2의 쿠바' 가 생겨나지 않도록
1962년 세계 규모의 커피 경제동맹체를 만들기로 하여 국제커피협정(ICA)가 생겨남.
수출국은 사전에 수출 할당량이 정해지면, 수입국에서는 비가맹 생산국으로부터 수입하는 것이 금지됨.
아라비카종은 주로 뉴욕, 로부스타는 주로 런던의 커피거래소에서 선물 거래됨.

# 제2차 녹병 판데믹
100년의 세월이 지나 1970년대 녹병이 중남미 전역으로 확산됨.
하지만 100년 사이 과학 발전으로, 아라비카종과 로부스타종의 교배로 신품종을 만들어냄.
또한 각 지역에서 품질까지 높이는 독자적인 내병 품종을 개발함.

# 스페셜티
스페셜티 커피의 아버지 '에르나 크누첸', 1974년 <티&커피 트레이드 저널> 에서 스페셜티 커피라는 이름을 처음 쓴 후, 1978년 국제커피회의 강연에서 이를 다시 사용. 그녀가 정의한 스페셜티 커피는 '특별한 지리적 조건에서 만들어진, 특별한 풍미의 커피'
에티오피아 예가체프, 예멘 모카, 인도네시아 슬라웨시 섬의 카로시 등
1982년 수입업자가 중심이 되어 미국스페셜티커피협회(SCAA)가 발족함.
- 거래량을 모아 수입량을 확보하기 위함
- 국제커피협정에서 관리하는 수출량 할당제도가 1975년 브라질 대서리 이후 일시폐지되었으나, 다시 신협정이 체결될거라는 소식에 제한 완화를 위한 로비를 위한 연대가 필요했음
- 스페셜티 인지도 향상
SCAA 에서 주관하는 커피 콘테스트가 흥행하기 시작했고, 그중 가장 파격적인 것은 2004년 파나마에 혜성처럼 나타난 '게이샤' 품종임.
원래 이 품종은 1930년대 에티오피아 서남부 게이샤라는 마을에서 발견된 야생종이었으나 당시에는 혹평을 받아 다른 품종으로 교체되었음.
그러던 2004년 피터슨 가족이 새로 매입한 농장 한쪽에 남아 있던 오래된 나무에서 수확한 생두를 '배스트 오브 파나마'에 출품했고, 이 독특한 향미를 지닌 커피가 1등을 하고 최고가를 경신하면서, 게이샤 재배지는 파나마에서 세계 각지로 퍼져 나감.

# 일본의 커피
1970년대 후반 일본에서는 2nd Wave 로 생두를 받아 자가배전점 커피 문화가 꽃피우고 심화됨.
1980년대 후반 일본은 커피업계의 불황. 버블경제로 부동산 가격이 폭등하자 치솟는 임대료를 감당하기에는 전체 매출이 그리 높지 않음. 버블경제로 좀 더 고급스런 식품으로 몰려 커피의 인기가 시들해짐.
1998년대 버블시대로 해외의 커피 문화를 경험한 세대들중 새롭게 개업하려는 사람들이 나타남. 트렌드 메뉴와 세련된 인테리어로 객단가를 높이는 방식을 취함.

# 동아시아로 확산
국제커피협정이 파기된 후 21세기 접어들면서 비가맹국 대상으로 수출이 활발해짐.
일본의 커피 소비가 가장 많았고, 서구화가 빨리 진행된 대만이 그 뒤를 이음. 반면 한국과 중국의 커피 보급은 더딘 편이었음.
1976년 동서식품이 개발한 '커피믹스'가 많이 애용되었고, 1997년 외환위기 때 한국기업들이 경비 절감을 위해 사무실에 상비하면서 폭넓게 인기를 끌었음.
1999년, 스타벅스가 한국에 1호점을 냄. 같은 해에 베이징에도 스타벅스가 중국에 1호점을 냈지만 인기를 끌지 못해 2007년 철수함. 2008년 리먼 사태 이후, 중국 정보의 경기 부양책이 실시되면서 중국의 버블 시대가 돌입하고 소비자들의 고급 지향성으로 스페셜티 등 고급 커피 붐이 일어남.

# 3rd Wave
21세기 들어 미국에서 3d Wave 가 본격적으로 도래함.
- 자동화, 획일화된 스페셜티(스타벅스 등)와는 다른 유형의 카페
- 자신의 손으로 한 잔씩 정성스럽게 커피를 내림
- 저 콩 혹은 이 콩은 아니라는 식의 선입관에 얾매이지 않음
그러면서 2000년대 후반부터 일본의 커피에 주목하면서 일본제 커피 추출기구를 사용하기 시작함.
차문화로 시작한 일본에서는 페이퍼 드립에 다도의 문화가 깔려있으나, 미국의 경우 '푸어 오버'라고 불리우는 한꺼번에 물을 붓는 방식으로 심지어 추출 중 드리퍼 안을 스푼으로 휘젖기도 함.
2012년 메리 화이트가 'Coffee Life in Japan' 에서 일본 고유의 커피 문화와 킷사텐을 소개하면서 일본의 커피가 뜨거운 관심을 받게 된다. 특히 이 책에 소개된 더치커피(적하식 워터드립)은 '쿄토 커피' 또는 '콜드 브루' 라는 이름으로 2015년경 미국에서 크게 유행하면서 새로운 트렌드로 전 세계에 확산되었다.

마녀사냥

뭐든창하 — Sat, 9 May 2026 15:13:22 +0900

도서감상 나누기에 아주 좋은 책이었던것 같다.

마녀로 몰렸던 어머니의 삶.

마녀로 몰아갔던 도움받았던 이웃의 삶과 시선.

그 자녀의 삶.

그 아이의 아픔을 회복시키는 또 다른 어른과 희생.

우리는 겉으로는 차이와 다양성을 외치면서도, 저도 모르게 힘센 다수의 편에 서서 폭력을 행사하곤 한다.

만약 네가 선택할 수 있었더라면 말이다. 너는 어디에 있는 어머니를 보는 것이 나았겠느냐?
다른 사람들에게 에워싸여 괴롭힘을 당하고 있는 어머니냐,
아니면 그 바깥, 괴롭히는 사람들의 무리 속에 있어 있는 어머니냐?

thick data, 빅데이터도 모르는 인간의 숨은 욕망

뭐든창하 — Wed, 18 Feb 2026 15:29:21 +0900

주변에 책을 읽을 수 있게 만드는 환경이 있다는 것에 감사하자. 도서모임도 있고 도서관도 가깝다!!

주요 내용은 기업에서 소비자를 위해 어떤 관점에서 데이터를 활용하고 의사결정을 내려야 하는지에 대한 내용이다.

이런 관점을 업무에 직접적으로 활용하는 일은 아니지만, 대상을 소비자가 아니라 협업하는 동료를 대상으로 전환해볼때 적용해도 도움이 많이 되는 내용이었다. 개인 기여자로써도 업무를 해야 하지만 짬바가 있으니 전체를 아우를 수도 있어야 하고, 누군가를 도와주거나 이끌어야 하는 업무도 꽤 비중이 높다. 이때 동료의 행동보다 그 행동안에 있는 맥락을 이해하고, 공감하고, 뭐가 필요한지 찾아보는 시야를 생각해보게 된 것 같다.

Part 1. 소비자를 이해하는 정교한 렌즈, 인류학

#01. 비즈니스 이면을 들여다보는 인류한적 시각
인류학이 여타 사회과학과 어떻게 다른지, 동시에 컨설팅과는 어떤 연결고리가 있는지를 인류학의 철학적 배경인 문화 상대주의(cultural relativisim), 문제접근법인 총체적 접근(holistic approach), 연구방법론인 참여관찰(participant observation) 세가지에 주목

* 문화 상대주의(cultural relativisim)
각각의 문화는 그 우열을 가릴 수 없고, 자문화를 중심으로 타문화를 평가해선 안 되며, 그 구성원들이 처한 환경과 역사적ㆍ사회적 상황, 가치관에 따라 이해해야 한다는 견해다. 문화 상대주의의 관점으로 우리는 자문화뿐 아니라 타문화에도 공감할 수 있으며, 이를 통해 우리 자신의 문화를 되돌아보고 더 깊이 이해할 수 있다. 컨설팅 기업에 이러한 관점을 적용하면, 고객사의 입장에서 문제를 깊이 있게 파악하고 해결책을 발견할 수 있게 된다.

* 총체적 접근(holistic approach)
현실을 통합된 전체로 보고 살피려는 자세다. 인류학적 시각으로 보면 정치, 경제, 종교, 생태 환경, 기술 발전, 가족제도 등 인간 사회를 이루는 모든 요소는 총체적으로 연결되어 각기 분리하기 어렵다. 따라서 연구하고자 하는 대상 또한 이러한 요소들과의 관계와 맥락 안에서 파악해야 그 본질에 다가갈 수 있다. 컨설팅 기업에 적용하며, 고객사의 비즈니스 이슈를 재무뿐 아니라 조직, 리더십, 경쟁사, 고객, 세일즈, 마케팅 등 다양한 측면에서 살필 수 있게 된다.

* 참여관찰(participant observation)
참여관찰은 현지조사(fieldwork)와 함께 설명돼야 하는 개념이다. 현지조사란 연구자가 연구 대상자의 일상적인 공간으로 들어가 그들의 언어와 관습을 배우고 익히며 가까이에서 그들의 일원으로 참여하면서 관찰하는 방법론이다. 이 과정에서 연구자는 연구 대상자들의 일상과 사회문화적 맥락을 함께 경험헌다. 참여관찰 방법론을 컨설팅에 적용하면 고객사에서 그 직원들과 함께 근무하면서 해당 기업의 비즈니스 이슈를 내부인이자 외부인의 시선으로 파악하고 해결할 수 있다.

Part 2. Big data 가 모르는 진실을 Thick data 는 안다.

#01. 비즈니스 통찰은 Big data 가 아닌 Thick data 에서 나온다.
big data 는 전력망, 물류, 유전 암호처럼 변동 없고 안정적인 체계를 수량화하는 데는 유용하지만, 유동적이고 불안정한 체계, 가령 인간과 관련한 문제에는 그렇지 못하기 때문이다. big data 를 제대로 활용하려면 인문학적 이해를 바탕으로 한 새로운 종류의 데이터가 필요하다고 말한다. 그것이 바로 thick data 다.

트리시아 왕은 'thick data'라는 개념을 인류학자 클리퍼드 기어츠의 'thick description'에서 가져왔다고 밝힌다.
두 명의 소년이 오른쪽 눈의 눈꺼풀을 빠르게 수축시키고 있다고 하자. 한 명은 본인 뜻과 무관하게 일어난 일이라 하고, 다른 한 명은 친구에게 보내는 신호라고 한다. 두 소년의 동작은 그 자체로는 완전히 똑깥아서 어떤 쪽이 윙크이고, 어떤 쪽이 경련인지 구별할 수 없다. 그러나 의미 면에서는 눈의 경련과 윙크는 엄청난 차이가 있다. 경련에는 아무런 의미가 없지만, 윙크는 아주 정확하고 특별한 방식으로 의사를 전달하는 수단이다. 여기서 더 나아가서 세 번째 소년이 나타나 친구들을 즐겁게 해 줄 요량으로 첫 번째 소년을 흉내 낸다면? 이 소년이 완벽하게 흉내 내기 위해 집에서 거울을 보며 연습한다면? 또 친구에게 신호를 보내려 윙크했다는 소년이 거짓말을 했꼬, 그 소년의 눈꺼풀 수축에 실은 아무런 의미가 없다면? 이런 경우 소년의 동작이 의미하는 바는 또 달라질 것이다. 눈꺼풀 수축은 그 자체로 독립적으로 존재할 수 없고, 반드시 맥락 안에, 그 의미를 해석할 의미망 안에 있다.

thick description 은 인류학을 포함한 모든 학문 영역에서 인간 행위를 파악할 때 행위 자체뿐 아니라 그 맥락까지 설명하는 것을 가리킨다. 연구자가 현장에서 관찰한 일을 기술하면서 그 고유한 맥락과 상황 조건을 함께 밝힘으로써 연구 대상이 드러내지 않았거나 드러내지 못한 의도나 전제를 생생하고 구체적이며 치밀하고 풍부하게 묘사하는 것이다. 이를 통해 연구자는 현장에서 일어난 일의 의미가 무엇인지 심층적으로 해석할 수 있게 된다.

이렇듯 사람들의 행위에는 반드시 맥락이 있고, 그것을 파악해야만 비로소 숨겨진 의미가 드러난다. 트리시아 왕이 big data 에 해당하는 thick data 라는 용어를 제안한 이유다. thick data 를 분석하려면 모든 프로세스를 정규화, 표준화해야 한다. thick data 는 이 과정에서 필연적으로 유실되는 사람과 그의 실제 경험, 맥락과 의미를 복원하는 가장 유용하고 중요한 도구가 될 수 있다.

thick data 의 의미를 더 깊게 이해하려면 big data 와 비교하는 방법이 가장 효과적일 것이다. big data 는 정량적(quantitative)이고 thick data 는 정성적(qualitative)이다. big data 가 머신 러닝에 의존한다면 thick data 는 인간 학습에 의존한다. big data 는 패턴 식별을 위해 변수를 제거하지만, thick data 는 복잡성을 수용한다. big data 는 해상도(resolution)가 떨어지고, thick data 는 확장성(scalability) 이 떨어진다. 이런 차이 덕분에 오히려 big data 와 thick data 는 서로를 보완할 수 있다. 정량적인 정보인 big data 로는 '무엇을 얼마나'에 관해 알 수 있고, 정성적인 정보인 thick data 로는 '왜, 어떠한 맥락에서'에 대해 통찰할 수 있다. 머신 러닝에 의존하는 big data 로는 정확성을, 인간 학습에 의존하는 thick data 로는 보편적인 진실을 추구할 수 있다.

#03. Thick data 를 얻기 위한 THICK 프레임워크
* Tolerance : 문화 상대주의에 입각해 낯섦에 관대해지지
흔하고 친숙한 것일수록 잘 안다는 착각을 일으키기 쉽다. 그러나 그 물건이나 현상을 세심히 관찰하면 우리 예상이 틀렸다는 걸 알게 된다. 무언가에 대한 통찰을 얻고자 한다면 선입견 없는 눈으로, 아무런 가정이나 예측 없이 실제를 볼 준비가 돼야 한다.

* Hidden Desire : 관찰을 통해 소비자의 숨은 욕구 찾기
관찰은 질문과 달리 소비자의 말과 실제 행동과의 불일치를 드러냄으로써 소비자가 의식하지도 못했던 잠재적 욕구를 발견하게 한다.
thick data 는 big data 와 달리 '왜'를 설명하는 근거가 되지만, 실제 참여관찰 현장에서 소비자에게 "왜?"라고 질문할 때는 매우 신중해야 한다 .이런 질문은 자칫 자기방어 심리를 자극해 변명이나 거짓말을 유도할 수 있기 때문이다. 오히려 묻지 않고 관찰하는 편이 오히려 '왜?'라는 질문에 대한 올바른 답을 얻는 방법이 될 수도 있음을 잘 보여 준다.

* Informants : 극단적인 소비자 및 나만의 자문단을 적극 활용하기
때로는 전형적인 소비자 집단이 아닌, 제품을 이상한 방법으로 사용한다거나 극단적으로 적게 또는 많이 쓰는 소비자에 주목함으로써 유의미한 통찰을 얻을 수 있따. 이들의 과정된 욕구나 사용 패턴이 이제 막 태동하기 시작한 새로운 욕구를 의미할 수도 있기 때문이다.
극잔적인 소비자와 더불어 주목해야 할 집단이 바로 나만의 자문단이다. 자문단을 잘 활용하기만 해도 해당 제품을 직접 사용하는 만큼의, 어쩌면 그 이상의 통찰력을 얻을 수 있다. 중요한 건 그 제품을 실제로 경험한 사용자냐 아니냐가 아니라, 사용자 중심적인 시각으로 thick data 를 모으고 활용할 의지와 인내심이 있느냐, 없느냐다.

* Context : 소비자의 말이 아닌, 총체적인 맥락에 집중하기
우리가 같은 사람의 같은 표정에서 서로 다른 감정을 유추하는 이유는 무엇일까. 맥락이 달라졌기 때문이다. 감정을 유추하려면 그 표정이 만들어진 맥락을 이해해야 하는데, 인공지능은 그러지 못한다는 것이다. 참여관찰이나 심층 인터뷰를 할 때도 소비자가 겉으로 드러내는 말과 행동이 아닌, 수면에 잠긴 맥락을 세밀하게 살펴야 한다.

* Kindred Spirit : 참여를 통해 소비자에게 공감하기
소비자의 민낯을 보고자 할 때도 공감과 감정 이입은 필수적이다. 인류학자 그랜트 맥크랙켄이 "인류학은 곧 공감이다"라고 말하나 이유도 이 때문일 것이다. 시청자가 드라마 캐릭터에 깊이 공감하면 굳이 대사로 설명하지 않아도 그 캐릭터의 사소한 행동에 담긴 의미를 이해할 수 있다. 마찬가지로 고객사나 소비자에게 깊이 감정 이입하고 공감하면 그들이 왜 그런 결정을 내리고 왜 그런 행동을 했는지 이해하게 되고, 직접적으로 말하지 않은(또는 말하지 못한) 숨은 욕망까지 들여다볼 수 있게 된다. 바로 이때가 감정이 내재된 스토리가 나오는 순간이며, 통찰로 이어지는 thick data 가 모이는 순간이다.

#04. Thick data 를 넘어 Smart data 로
thick data 로 통찰하고 big data 로 증명하고 smart data 로 실행하라.
사용자에 관한 구체성과 보편성, 모두를 담보함으로써 드러나지 않은 진실을 밝히고 가장 합리적인 의사 결정에 이르려면 어떻게 해야 할까.

첫 번째, 정성적인 리서치로 수집한 thick data 로 깊은 통찰을 하고 이를 토대로 가설을 세울 수 있어야 한다.
쓸모없는 데이터를 입력하면 쓸모없는 데이터가 출력된다. 대개는 출력 데이터의 양에 주목하지만, 입력 데이터의 질도 중요하다. 제아무리 뛰어난 big data 기술을 보유하고 있어도 입력 데이터의 질을 충분히 고민하고 검토하지 않으면 의미 있는 출력 데이터를 얻을 수 없다.

두 번째, 통찰을 통해 세운 가설을 big data 로 검증해야 한다.
요즘은 비즈니스 의사 결정에 다수가 참여하는 만큼 이들을 설득하기 위해 big data 로 검증하는 과정이 꼭 필요하다. 이 때 big data 로 검증한다는 것은 이미 갖고 있는 데이터를 활용한다는 의미가 아니다. 소비자의 인적 사항, 구매 내용과 패턴 등의 데이터를 모았다는 이유로 big data 를 충분히 보유하고 있다고 착각하는 기업이 많다. 그러나 이것만으로는 첫 번째 단계에서 만들어진 가설을 증명하기 어려운 경우가 많다. 보유하고 있는 big data 에만 매달릴 게 아니라 가설을 증명할 수 있는 데이터를 적극적으로 모으는 작업을 수행할 수 있어야 한다.

세 번째, 검증을 마친 가설이 실질적으로 어떤 의미를 지니는지 해석해 '왜'라는 질문의 답을 얻은 후, 이에 근거해 소비자의 욕구를 소비자가 원하는 순간에, 원하는 장소에서, 원하는 방식으로 충족시킬 방법을 알려 주는 smart data 를 도출한다.
smart data 는 단순히 분석에만 그치는 ㄷ네이터가 아니라, 기업의 실질 적인 의사 결정을 도출하고 구체적인 실행으로 전환된다는 점에서 매우 중요하다.

thick data 로 통찰하고 big data 로 증명하며 smart data 로 실행하는 이 일련의 과정이 우리에게 어떤 이익을 안겨 줄까?
첫째, 기업이 자신의 존재 이유이자 존재를 가능하게 하는 소비자를 더 잘 이해할 수 있게 한다.
둘째, 소비자에 대한 이해를 바탕으로 기업과 그 구성원, 그리고 그들의 상품 및 서비스를 더 깊게 파악할 수 있도록 돕는다.
셋째, 급변하는 기업 환경에서 미래를 예측하는 데 도움이 된다. big data 는 무슨일이 벌어지고 있는지 보여 줄 순 있어도 그 일이 '왜' 벌어졌는지는 알려 주지 못한다. 미래를 예측할 힌트는 언제나 '무엇'이 아닌 '왜'에 있다.

Part 3. Thick data 로 어떻게 비즈니스 기회를 발견하는가

#01. 소비자는 진실을 말하지 않는다.
혁신하려면 고객 경험에 집중하라.
소비자 조사를 통해 혁신적인 아이디어를 얻을 수 없는 이유는 소비자가 자신의 잠재된 욕구를 제대로 알지 못하기 때문이다. 우리는 누가 일깨워 주기 전까지 특정 상황에서 어떤 필요성이나 불편함을 느끼고 있음을 잘 깨닫지 못한다.

'소비자의 숨은 욕구'란 새롭고 혁신적인 제품에만 국한된 말이 아니다. 제품을 쓰면서 느끼는 크고 작은 불편함이 해소됐으면 하는 욕구 또한 포함하는 말이다. 이런 불만 해소의 욕구는 혁신적인 제품을 향한 욕구만큼이나 소비자 스스로가 인지하지 못하는 경우가 많다. 따라서 소비자가 불만을 표출하지 않는 것을 제품이 완벽하다는 증거로 받아들여서는 곤란하다. 일상의 불편함을 해소하고 삶의 질이 향상할 수 있으리라는 기대 자체가 없어 기업에 불만을 표하지 않는 소비자도 많다. 소비자가 진실을 말하지 않는다면(또는 말하지 못한다면) 우리가 먼저 발견해야 한다. 소비자 조사에만 의존하지 말고, 소비자의 일상으로 들어가 그들의 경험에 주목해야 한다. 혁신의 단서는 소비자의 말이 아니라 소비자의 무의식적인 습관과 행동에서 발견된다.

#02. 최종 소비자를 만나면 새로운 기회가 보인다.
제품은 개발자 의도대로만 쓰이지 않는다.
사용자가 애초에 의도된 대로만 제품을 사용하리라 믿는 것은 개발자나 마케터가 흔히 저지르는 실수다. 자신들의 기술에 지나치게 몰두하고 심취한 나머지 메뉴얼이 아닌 다른 방식으로 제품을 사용할 수 있다는 가능성 자체를 떠올리지 못하는 것이다. 그러나 사용자가 제품을 사용하는 방식은 그들이 처한 사회 문화적 맥락, 생활 습관 및 기호에 따라 천차만별일 수 있다. 애초 의도한 대로 제품이 사용되지 못한다면 그것은 사용자가 어리석은 게 아니라 개발자가 최종 사용자를 더 세심하게 배려하지 못한 것이다. 제품이나 서비스를 개발한 뒤에는 반드시 사용자가 어떻게 쓰는지 참여관찰을 통해 알아봐야 하는 이유다.

소비자가 제품을 어떻게 사용하는지에 주목하라.
누가 어떤 의도로 제품을 개발했는지는 중요하지 않다. 사용자가 그 제품을 어떻게 사용하는지에 주목해야 한다. 아무리 훌륭한 제품이라도 실제 사용자들이 일상에서 그 제품과 어떻게 상호작용하는지 관찰하지 않는다면 완벽해질 수 없다.

#03. 소비자는 물건이 아니라 자부심을 산다.
"단골은 떠나도 팬은 떠나지 않는다."
단골이 습관적으로 또는 나름의 합리적인 이유로 특정 브랜드나 제품을 선호하여 반복 구매하는 집단이라면 팬은 브랜드의 신념과 가치에 공감하고 이를 철저히 내면화한 집단이다. 단골이 품질이나 가격의 변화, 경쟁사 프로모션 등 다양한 이유로 선호 제품을 갈아치운다면 팬은 때때로 실망하고 불만을 느끼더라도 브랜드와의 끈끈한 유대를 잃지 않는다. 팬에게 브랜드란 같은 취향과 신념을 공유하는 공동체이자 내가 어떤 사람인지를 보여 주고 표현하는 수단이기 때문이다.

할리데이비슨은 오토바이가 아니라 체험을 판다.
과거의 마케팅이 사용자 확대에만 몰두했다면 이제는 하드코어 사용자들을 대상으로 하는 팬덤 형성에 주력할 때다. 제품력이 전반적으로 상향 평준화한 요즘, 기술력이나 품질만으로는 타 브랜드와 차별점을 만들기 어렵다. 인간에게는 특정 무리에 속해 안정감을 얻고자 하는 강한 본능이 있다. 브랜드 팬덤을 형성하려면 인간이라는 종이 지닌, 소속감에 대한 열망을 잘 이해해야 한다. 그리고 소비자가 브랜드에 강한 소속감과 유대감을 느낄 수 있게 하려면 할리데이비슨처럼 해당 브랜드의 소비자만이 독점적으로 누리는 특별한 경험과 스토리를 제공할 수 있어야 한다.

거래는 단골을 만들지만, 관계는 팬덤을 만든다.
핵심은 소비자와 거래를 하느냐, 관계를 맺느냐에 있따. 브랜드 로고를 몸에 새긴다는 행위 자체는 같을지 몰라도 모 브랜드의 경우에 그 행위는 '거래'고, 할리의 경우에는 '관계'다. 많은 브랜드가 소비자의 충성도를 높인답시고 이런 실수를 한다. 제품 후기를 작성하면 포인트를 준다거나 자사의 SNS 계정을 팔로우하면 할인 쿠폰을 제공한다는 방식으로는 팬덤을 형성하지 못한다. 소비자와 관계를 맺는 것이 아니라 거래를 하는 방식이기 때문이다. 이를 '거래'가 아닌 '관계'로 만들려면 쿠폰 한 장이라도 손수 작성한 메모와 함께 건네는 방식으로 소비자 한 사람, 한 사람에게 '나는 특별한 사람'이라는 감동을 안겨 줄 필요가 있다.

#04. 소비자 중심의 마인드셋은 기업문화에서 시작된다.
기업이 익숙함에서 벗어나 혁신과 변화를 과감하게 받아들이려면 조직문화가 어떻게 달라져야 할까. 어떤 조직문화를 정착시켜야 thick data 를 제대로 수집하고, 이를 통해 얻은 소비자에 대한 이해를 상품과 서비스의 개선에 반영할 수 있을까.
첫째, 수평적 의사소통 체계가 마련돼야 한다.
둘째, 모든 직원이 창의적인 아이디어를 도출할 수 있어야 하고, 경영진은 이를 독려하고 수용해야 한다.
셋째, 다양성을 받아들일 수 있는 조직이어야 한다.

#06. 다양성을 받아들여야 미래가 나의 것이 된다.
기업이 찾아야 하는 인재는 전문가가 아니라 주변인이다.
다양성에 주목하게 된 오늘날의 기업들이 애타게 찾아야 하는 인재도 결국은 주변인이다. 우리는 흔히 한 조직에 깊이 연루한 '완벽한 내부인'만이 그 조직의 문제를 가장 잘 해결할 거라 믿는다. 그러나 문화인류학자 에드워드 홀은 "문화는 드러내는 것보다 감추는 것이 훨씬 많으며 묘하게도 그 문화에 속한 사랃믈이 감춰진 바를 가장 모른다"라고 했다. 이 말처럼 특정 산업 분야에 완전히 적응한 내부인은 조직의 문제를 파악하거나 새로운 발상을 하기가 오히려 더 어려운 면이 있다. 그렇다고 그 분야와 동떨어진 외부인이 더 유리한 것도 아니다. 외부인은 내부의 사정이나 정보를 알지 못하므로 실효성과 실현 가능성이 떨어지는 아이디어를 내기 십상이다. 그러나 외부인이 그 분야에 뛰어들어 내부인의 시선을 이해하고 주변인의 정체성을 갖게 되면 조직이 당면한 이슈를 새로이 파악하고 해결하는 창의성을 발휘할 수 있게 된다. 누구나 동의하겠지만 창의성이 무에서 유를 창조하는 능력을 가리키는 시대는 이미 지났다. 스티브 잡스는 창의성을 연결(connecting things)로 정의했다. 이미 존재하는 무언가를 서로 연결하고 재배치하며 편집하는 능력이 창의성이라는 말이다. 그렇다면 누가 이런 일을 할 수 있을까. 이미 존재하는 무언가를 당연하게 여기지 않는 사람, 이쪽과 저쪽의 경계에서 선입견 없이 둘 사이를 오가며 연결 지을 수 있는 사람, 바로 주변인이다.

#07. ChatGPT 시대에도 우리는 여전히 원시인이다.
재택근무에는 '우연한 충돌'이 없다.
기업들이 재택근무를 종료하고 사무실 복귀를 서두른 이유는 무엇일까. 일을 열심히 하고 있는지 감시하기 위해서가 아니다. 업무 효율과 생산성에 대면 상호작용이 중요하다는 사실을 재택근무를 통해 절감했기 때문이다.
'우연한 충돌(casual collisions)', 우연히 마주친 직원들은 서로 가벼운 대화를 나누며 새로운 아이디어를 공유한다. 많은 직원을 한 공간에서 만나게 함으로써 '우연한 충돌' 효과가 발생하길 기대한 것이다. 이러한 우연한 충돌과 협업은 재택근무를 통해서는 거의 불가능하다. 처음 만나거나 갓 입사한 직원과 원격으로 협업하기란 생각보다 쉽지 않다. 대면 미팅을 통해 상대방에 대한 이런 사소한 정보를 알게 되면 이후의 비대면 회의에서도 감정 단서를 훨씬 잘 포착하게 된다. 우리 뇌는 대면을 통해 사회하하고 의사소통하도록 진화했다. 우리는 언어 요소뿐 아니라 표정, 시선, 몸짓의 미묘한 변화, 공간을 활용하는 방식 등의 비언어적 요소까지 고려해 총체적으로 상대의 의중을 파악한다. 그러나 비대면 회의로는 이런 모든 요소를 고려하기가 매우 어렵다.

2025년도 회고

뭐든창하 — Thu, 1 Jan 2026 17:50:28 +0900

매년 5가지의 큰 주제를 가지고 계획을 짜보는데, 각 항목마다 욕심 그득하게 채워넣지만 회고때 결과를 보면 반성하게 된다.
하지막 한단계 더 성장하기 위해서는, 계획을 적당한 정도보다는 조금 과하게 잡아야 하니까 올해도 욕심 그득하게 채워본다.

우선 작년 회고를 해보자.
2025년의 가장 큰일을 뽑으라면 "이직" 이라고 할수 있겠다.

40대 중후반의 나이에다가 적지 않은 몸값을 가지고 여기서 한번 더 이동할 수 있을까 걱정을 가지고 시작했는데, 그래도 잘 이직하게 되었고, 이 모든 과정가운데 인도해주신 하나님께 감사와 영광을 올려드린다.
직장생활이 거의 20년이 되어가지만 이번이 3번째 회사라 많은 이직을 한건 아니었고, 이전 이직도 소개를 받아 비교적 자연스럽게 이직을 한거라서, 이번에도 소개를 받은 기회도 있었으나, 완전히 서류부터 준비해서 이직시장이 뛰어든건 첫 직장 입사 이후에는 처음이라고 볼 수 있겠다.
지원자에게 요구하는 주된 관심사도 그 사이 많이 변했음을 느낄 수 있었다.
그 옛날에는 열정과 패기였고, 코로나 이전에 한창 개발자 몸값 붐이었을때는 능력과 실력이 위주였다면, 이번 이직시장을 통해서는 컬처핏을 주요하게 확인함을 피부로 느낄 수 있었다.
주위의 후배들에게 이직시에 어떤것들을 준비해야 하는지 아주 도움이 되는 소중한 경험이라고 생각이 든다.

[말씀.us] https://bible.malsseum.us

그 다음으로는 평소 생각만하던 웹서비스를 오픈한 일이다.
조금 솔직하자면, 내가 필요해서 만들었고 함께하면 더 좋을 것 같아 오픈했다.
그렇지만 서비스 운영비용면으로는 조금 더 후원이 필요하다.
2026년에는 여러가지 기능 추가와 매출에도 신경써보자.

그리고 꼬따오를 가는 과정자체가 쉬운일은 아니아서 크게 기대하지 않았던 다이빙을, 우연치않게 동생들과 일정맞춰서 함께 하게되서 너무나 즐거운 시간이었다.
그 모든 여행일정안에서 그래도 형이라고 나에게 많이 배려해주고 즐겁게 참여해줘서 재밌는 여행을 경험하게 해준 동생들에게 감사를 전하고 싶다.
2026년에도 또한 기대하기는 어렵겠지만, 이번에는 어드밴스를 수료한 넷이서 함께 가면 좋겠다.

그 다음으로는 해파랑길 750km 완주를 이루어냈다.
2023년도에 중간에 멈추었던 해파랑길을 올해 5월 황금연휴 기간을 통해 모두 마무리했다.
아직 우리나라에는 서해랑길, 남파랑길 등의 수 많은 걷기코스가 남아있지만 국내보다는 언젠가 산티아고 순례길을 꼭 완주해보고 싶다.

새로운 운동으로는 테니스를 시작했다.
좀 더 일찍 시작할껄 하는 후회가 좀 있다. 너무 재미있다!!

이러고 보니 경험이라는 측면에서는 많은 것들을 이루어냈는데 성장이라는 측면에서는 조금 부진한것 같다.
책도 많이 못 읽었고, 개발자로서의 소양을 한 단계 높였다는 결과도 별로 없던것 같다.
다행이라고 해야 하는지 걱정이라고 해야 하는지 모르겠지만, 2026년도에는 새로운 직장에서 새로운 기술스택으로 도전을 해야만 하는 환경이 주어졌다. 이 또한 하나님의 인도하심이라고 생각하고 주어진 환경에서 성장해보자.

KODE VICIOUS 개발지옥

뭐든창하 — Wed, 17 Dec 2025 21:26:05 +0900

Chapter 1. 손 안의 코드

# 자원 관리
소프트웨어 엔지니어링에서 당신과 저에게 한없는 좌절감을 안겨주는 부분이 트레이드오프를 알아가는 과정입니다. 엔지니어들이 그들이 당시에 가정했던 사항들을 매년 또는 격년 주기로 다시 살펴보는 것은 중요합니다. 우리가 작업하고 있는 시스템은 매우 빠르게 변화하니까요.

메모리 같은 자원을 아무런 자각 없이 낭비하는 건 당연히 어리석은 행동입니다. 이런 경우는 엔지니어링 관점의 트레이드오프조차 아닙니다. 프로그래머가 그들이 사용하는 장치가 그냥 동작만 하면 된다고 생각한다면 그건 프로그래밍이 아닙니다. 그런 건 그저 타이핑에 불과한 겁니다. 소프트웨어 엔지니어가 좋은 의자에 앉고 비싼 급여를 받는 이유는 그들이 자원 낭비를 원치 않는 이들이기 때문입니다. 따라서 그들은 최고, 최악의 시나리오로 시스템의 다른 사용자들에게 줄 영향에 대해서 알아내야 합니다.

# 친절한 코드
만약 사람들이 당신의 라이브러리를 사용하고자 한다면, 왜 그들이 자꾸 접근하는지 알아내야 하고 그들의 요구사항을 충족시켜야 합니다. 라이브러리는 당신을 위한 것이 아니라 바로 그들을 위한 것이기 때문이죠.

# 코드 남용
이제 작성한 API 의 적절한 사용을 명확하게 문서화했다고 했지만 문서화를 통한 경고는 뉴욕의 무단횡단자들에게 보내는 노란색 주의 테이프 정도에 불과합니다. 앞을 가로막는 불타는 해자가 없는 이상 이들은 몸을 숙여 이 경고테이프를 무시하고 넘어갈 겁니다.

당신이 처음에 무엇을 의도했든지와 상관없이, 그 API 가 범용적 쓰임이 가능한 것처럼 표현되어 있고 다른 코더들이 별 생각 없이 어둠 속을 헤매다 그것을 조우할 수 있게 방치해 둔다면, 그 이후에 다시 보게 되었을 때 당신조차 못 알아볼 지경으로 사용되고 있을지도 모릅니다.

# 질식할 것만 같은 변경사항들
커다란 커밋을 쪼개야 하는 마지막 이유는 그래야지 누군가가 당신의 작업에서 작은 문제점을 찾았을 때 그에 해당하는 작은 변경만 롤백하고 나머지 당신의 작업은 보존할 수 있기 때문이다.

# 강요된 예외
규칙에 대한 집착은 경우에 따라 좋을 수도, 나쁠 수도 있지만 검증되지 않은 것에 대한 집착이 문제를 유발하곤 합니다.

대부분의 사람들이 '코드'라는 것을 동작하는 부분으로만 오해하고 있습니다. 심지어 누군가가 이런 편협한 시야를 요구하는 것도 아닌데 말입니다. 그 이유는 에러를 취급하는 부분이 코드를 작성하는 사람이 원하는 결과를 얻는 부분에서 주된 관심사가 아니기 때문입니다.

# 로그 남기기
디버거가 여러분의 프로그램의 어느 곳에서 충돌이 발생하는지 알려 준다면, 로그 출력물은 충돌 직전에 무슨 일이 벌어졌는지를 보여 줍니다. 좋은 로깅 시스템은 단순히 어느 지점에서 충돌이 발생했는지 알려 주는 것에 그치지 않고 한발 더 나아가 좋은 시스템 대시보드를 구성하는 데 필요한 초석이 되기도 합니다. 반면 나쁜 로깅 시스템은(대부분이 이쪽이죠.) 거기에 못 미치거나, 아니면 아예 로그 자체를 남기지 않는 편이 더 나을 정도입니다. 그런 시스템은 여러분을 잘못된 장소로 이끌어 여러분이 시스템의 진정한 이슈를 찾느라 시간을 낭비하게 만들기도 합니다.

로그 출력을 업데이트할때에는 아주 그럴싸한 이유가 있는 편이 아니라면, 새로운 정보는 항상 마지막에 추가하는 편이 좋습니다. 또 다른 조금 덜 공격적인 수단이 있습니다. 로그 출력에 완전히 새로운 정보를 제공하는 별도의 라인을 추가해서 기존 스크립트가 과거의 로그를 가능한 한 오랫동안 그대로 사용할 수 있게 하는 방법입니다.

# 복사하기
문제는 사람들이 코드나 문서를 복사하면서 그들의 이름이나 회사 이름을 강제로 때려 넣을 때 발생합니다. 만약 여러분의 코드나 아이디어의 출처를 모른다면, 여러분의 작업은 여러분 자신과 그 서비스를 사용하는 이들에게 심각한 불안을 야기할 수 있습니다.

"복사하고 붙여넣기 전에 생각부터 하세요!"

복사의 편리함은 두 개의 전혀 다른 문제를 유발하게 되었습니다. 첫 번째 문제는 복제된 버그 문제로, 문제의 코드가 제품의 코드 열 군데 이상에 존재하게 되어 중복 관리하게 된 것입니다. 그리고 두 번째 문제는 이 제품 코드를 전체 복사해 가며 만든 새로운 제품에도 버그가 포함된 문제입니다. 두 제품에서 발생하는 버그는 연관은 있지만 미묘하게 달라서 이제 다른 쪽의 버그를 고치려면 하나씩 고쳐나가는 수밖에 없습니다.

# 코딩할때 짜증나는 다섯 가지
코드는 항상 현재 시스템이 어떠한지 보여 주어야 하는 것이지 과거에 어떠했는지를 보여 주는 것이 아닙니다.
명심하세요. 정말, 정말, 정말 필요할 때만 전역 변수를 사용하는 겁니다.

# 언어들 속에서 길을 잃다
쉘 스크립트, 때론 영리하고 유용한 수단이지만 관리하기는 매우 까다롭습니다. 이 녀석들로 100줄 넘어가는 코드는 절대로 작성하지 않습니다. 대부분의 사람은 '1회성 작업(또는 2회성 작업인데, 처음에는 절대로 동작하기 않기 때문)'을 '그저 무언가 동작하게끔' 하려고 작성합니다. 불행하게도 이런 스크립트들은 프로젝트 집안의 천덕꾸러기들입니다. 이것들은 한번 레포지터리에 추가되고 나서 문제가 생기기 전까지는 무시당하다가 문제가 한번 벌어지면 소리가 날 정도로 두드려 맞고 비명을 지르고 절뚝거릴 때까지 놔두지 않습니다.

# 체크인 주석
체크인 주석은 코드에 남기는 주석과 같은 제약을 받습니다. 첫째, 실제로 주석이 있어야 합니다. 둘째, 주석은 유용해야 합니다.

Chapter 2. 코딩 수수께끼

# 캐시 미스가 뭐죠?
코드의 명료성과 소소한 최적화의 경쟁에선 명료성이 거의 항상 이깁니다. 명료성이 부족한 코드는 버그의 온상이 되는데, 굳이 그런 빠르지만 잘못된 코드를 가질 이유는 없기 때문입니다. 코드에서 중요한 건 일단 틀리지 않는 게 먼저고 그 다음이 성능 보장인데, 이는 제정신인 개발자라면 당연히 따르는 우선순위입니다.

# 입력 검증
사용자 입력을 제어하는 첫 번째 규칙은 '아무도 믿지 말 것!' 이고, 특히 사용자는 더더욱 믿어서는 안 됩니다.
두 번째 규칙은 '당신 스스로도 믿지 말 것!' 입니다. 이 말은 당신이 한 작업의 결과에서 놓친 게 없는지 꼭 확인해야 한다는 말입니다.

만약 당신이 사용자에게 보낸 웹 폼에서 데이터를 받아오는 거라면, 모든 폼을 검사하는 편이 좋습니다. 다만 검사를 위해 블랙리스트의 문제는 관리가 어렵다는 점입니다. 그래서 가급적 화이트리스트를 이용하는 편이 좋습니다. 화이트리스트를 사용하는 방식으로 변경해 사용자가 제공 가능한 입력 항목을 매우 제한적으로 하는 것입니다. 좀 가혹해 보이겠지만, 당신의 코드를 사용자들과 스파게티 코드로 변모하는 것에서 지키는 가장 좋은 수단임에는 분명합니다.

# 문서화 흥정하기
사람들이 자신의 코드나 디자인을 문서화하는 데 어려움을 느끼는 이유는 좋은 글귀나 소설과 수필, 함수 블록, 하드웨어 기능에까지 내러티브가 필수라는 사실을 받아들이지 못했기 때문입니다. 내러티브 없이는 독자들에게 아무런 정보도 제공 못하고 그저 글귀를 흩뿌리는 것에 불과합니다.
여러분들이 하나의 함수에 대해서 문서화를 시도할 때 다음 네 가지 질문에 답변을 하면 좋은 문서화가 될 겁니다.
* 입력은 무엇인가?
* 입력은 어떠한 변화를 겪게 되는가?
* 어떠한 형태로 출력이 나오는가?
* 적절하거나 부적절한 경우 어떠한 (에러) 반환 값이 있는가?

문서화 실패의 주요 원인은 독자가 그들이 모르는 지식들을 알고 있을 거라 섣불리 전제하는 것에 있습니다. 요컨대, 문서를 작성할 때는 여러분이 어떠한 전제를 하고 있는지를 고려해야 합니다.

많은 프로그래머가 코드는 그 자체만으로 해석할 수 있어야 한다고 주장하지만, 스스로 의미를 명확하게 전달하는 코드는 몹시 드뭅니다.

API 문서가 한데 모여, '전체 시스템이 어떻게 구성되어 있는지', '어떻게 사용하면 되는지와 안 되는지'를 다루는 것이 좋은 문서의 두 가지 중요한 특징입니다.

# Foo 필드에는 뭔가 있는 거야?
대부분의 엔지니어가 소프트웨어나 하드웨어에 대한 문서를 작성할 때 그들이 설득해야 하는 대상인 사람들이 글을 읽기 시작할 때 이미 전체적인 수준의 컨텍스트를 가지고 있다고 가정하는 것 같습니다. 그런 경우에 문서는 레퍼런스(참조) 문서이지 가이드 문서는 아닙니다.
모든 소프트웨어와 하드웨어 개발자는 시스템을 개발할 때 다음과 같은 질문에 답해야 합니다.
1. 이것을 왜 추가했는가? (필드, 기능, API)
2. 이 필드, 기능, API 는 어떻게 사용하는가? 예시를 제공하시오.
3. 당신이 제공하는 것으로 인해 다른 필드, 기능, API 가 어떠한 영향을 받는가?

# 성깔 있는 테스터
테스트하는 것에서 가장 중요한 것은 사고방식 아니면 태도와 관련된 것일 겁니다. 첫 단계로 좋은 습관은 테스트를 과학적 방법으로 접근하는 것입니다. 그 다음 단계는, 아마 대부분 이게 가장 어려울 텐데, 바로 코드에 대한 당신의 섣부른 가정을 내려놓는 것입니다.

어리석은 테스트 증후군
무엇이 퇴스트되어야 하는지, 어떤 것이 중대한 위험인지를 저울질하지 않고 전부 테스트할 것을 요구하는 문제.
어테증을 예방하려면 몇 가지가 필요합니다. 먼저 두뇌가 필요합니다. 두 번째로 필요한 것은 시스템을 디자인하고 구현하는 사람들과의 관계입니다. 가장 위험한 영역에 대한 질문은 당신 스스로 직접 물어볼 수 있어야 합니다. 단순하고 쉽게 이해되는 작업을 수행하는 라이브러리의 인터페이스를 테스트하는 것은 큰 의미가 없습니다. 반면에 10,000줄이 넘는 실험적인 코드나 그냥 봐도 이상한 코드, 또는 회사의 매우 중요한 영업 비밀 같은 코드들은 꼭 테스트해 봐야 합니다. 제 경험상 좋은 테스트를 작성하는 기술은 서로 조금 다르긴 해도 좋은 코드를 작성하는데 필요한 기술만큼이나 값어치가 있습니다.

# 테스트 방법
어떤 종류의 테스트이건 체득하려면 적절성과 반복성이라는 두 가지 선행조건을 충족시켜야 합니다. 문제를 포착하는 테스트를 작성하기 위해 테스트 개발자는 소프트웨어가 동작하는 테스트와 실패하는 테스트를 고안할 수 있도록 도메인에 익숙해져야 합니다.

# 유지보수 모드
리팩토링이란 건 작은 변경으로 다른 프로그램에서 함수나 클래스를 사용할 수 있음을 의미합니다.
당신이 유지보수하는 동안, 아니 제 말은 리팩토링하는 동안, 뭐를 바꾸건 간에 테스트를 꼭 하세요. 당신이 비록 'API 의 정말 자그마한 필드 하나를 추가' 했을지라도 변경에 대한 테스트를 하지 않은 것에 대한 변명이 되지 않습니다. 만약 당신이 테스트를 하지 않는다면, 제가 장담하건대 옛날 방식의 소프트웨어 유지보수를 하고 있는 거라고 말할 수 있습니다.(버그 수정이요)

# 일찍 머지하기
먼저 당신이 하려는 작업을 완료하고 메인 브랜치의 고통을 당신 것으로 받아들이세요. 저는 제 작업을 먼저 완료해서 기분이 좋아진 다음에 이런 종류의 머지를 하는 것을 선호합니다. 그러면 적어도 기분 좋은 상태에서 시작할 수 있을 테니까요. 그러고 나서 제 브랜치에 발생하는 문제를 고치다 보면 다시 중립적인 상태에 접어들 수 있습니다.

언제 머지된 코드를 트리에 반영하는 게 최선의 선택일까요? 그건 당신이 무엇을 머지하느냐에 따라 다릅니다. 버그를 고치는 것이라면 다른 사람들이 그 영향을 받을 수도 있으니 테스트가 끝나는 대로 가능한 한 빠르게 반영해야 합니다. 기능 추가라면, 테스트가 다 끝나고 나서 사용하는 데 지장이 없을 때 머지하는 게 좋습니다.

Chapter 3. 시스템 디자인

# 추상화
프로그래밍 기술은 많은 경우의 수를 정복하고 끔찍한 혼란을 가능한 한 효율적으로 회피하는 것을 통해 복잡성을 정리하는 기술이기도 합니다.

적절한 추상화는 좋은 시스템 디자인의 핵심입니다. 추상화를 올바르게 하지 않으면 두 컴포넌트 사이에 오해가 생기게 됩니다. 그리고 오해는 버그를 유발하고, 버그는 시스템 실패를 유발합니다. 그렇지만 추상화를 향한 시도가 계속해서 작게 쪼개는 작업으로 되다 보면 제논의 역설처럼 추상화가 쓸모없어지게 되는 상황이 생깁니다.
우리가 코드나 데이터 관점의 추상화를 살펴본다면, 반드시 다음 세 가지 질문에 답해야 합니다. 이 추상화가 다른 프로그래머들에게 사용성이 있는가? 이 추상화가 스스로 테스트할 수 있는가? 이 추상화를 사용하는 코드를 유지보수하게 된다면 간접적인 영향이 어디까지 발생되는가?

# 가역적 변경(Changative Changes)
한 가지 제안하고 싶은 건 버전 번호의 의미를 조금 더 엄밀하게 하라는 것입니다. 메이저 번호는 완전히 호환성이 깨질 때만 증가시키고, 마이너 번호는 하위 호환성이 깨질 때 증가시키고, 마지막 숫자인 패치 번호는 각 패치나 사소한 변경이 있을 때 증가시키는 겁니다.

# 크로스 사이트 스크립트
입력의 유효성 검사 메타 문제는 사용자 입력을 처리할 때 시스템 디자인에서 세 가지 중요한 점을 제공합니다.
* 입력을 실행하는 영역에 사용자 입력을 그대로 전달하지 마세요.
* 모든 사용자 입력은 알려진 양호한 패턴과 일치시키세요.
* 당신이 사용하는 언어에 내재된 위생 절차를 준수하세요.

# UI 디자인
시스템 구성 초기에 프로그래머나 소프트웨어 아키텍트에게 가장 중요한 것을 하나 꼽자면, 사용자 인터페이스에 표시되는 정보와 핵심 시스템에서 데이터가 저장되고 취급되는 방법을 분리해 여기저기 질질 끌려다니지 않도록 만드는 것입니다. 사용자 인터페이스를 수정하는 것이 무언가를 컴파일하게 해서는 안 됩니다.

Chapter 5. 사람과 사람

# 무슨 색깔이게...?
당신이 목격한 건 불행하게도 코드베이스를 수정할 때 종종 발생하는 일상적인 반응입니다. 혹시 누군가가 복잡하거나 때론 끔찍하기까지 한 코드를 올렸는데도 다들 침묵하는 경우를 본 적이 있나요? 이건 단순히 사람들이 해당 코드를 리뷰할 시간이 없어서 그럴 수도 있습니다만, 불행하게도 대부분의 사람들은 10줄에서 50줄 정도의 변경만 리뷰하는 데 시간을 할애하고, 커다란 코드에서 결점을 찾지 않으면 죄책감이 드는지 작은 거라도 찾아서 트집 잡게 됩니다.

<파킨슨의 법칙> 만약 당신이 복잡한 것을 만들고 있다면 소수의 사람들만이 당신이 무엇을 하고 있는지 이해할 수 있기 때문에 당신과 논쟁할 것이라고 했습니다. 반대로 당신이 단순한 것을 만들다면(이를테면 자전거 창고 같은 것들) 아마 누구라도 만들 수 있을 것이기에 많은 이들이 저마다의 의견을 가질 겁니다.

# 디자인 리뷰(설계 리뷰)
개인에 대한 리뷰와 객관화된 리뷰를 구별하는 명확한 방법은 다음과 같은 표현들입니다.
"무엇이 당신으로 하여금 x라고 생각하게 하였나요", "왜 당신이 y를 구현하였나요?" 는 명백하게 개인적이고 비난하는 표현입니다.
디자인 자체에 관심을 보이는 문장은 "이 두 컴포넌트 간의 결합이 더 효율적이라는 것을 보여 줄 데이터가 무엇입니까?", "이 시스템의 확장은 어떻게 할 계획입니까?" 의 형태에 가깝습니다.

디자인 리뷰(설계리뷰)를 할 때 주의사항은 코드 리뷰로 변질되면 안 된다는 점입니다. 목표는 큰 틀에서의 그림을 이해하는 것이지 상세한 내용을 이해하는 것이 아님을 명심해야 합니다.
불쾌감을 주지 않으려면 다음 몇 가지 유용한 규칙에 따라 실행하는 것이 좋습니다. 첫째로 끝없는 질문으로 사람을 망치지 마세요. 당신이 하려는 일은 디자인 영역을 협동적인 자세로 탐험하려는 것임을 잊어서는 안 됩니다. 이건 취조가 아니란 걸 기억하세요. 둘째로, 함께 일하는 사람들이 생각할 수 있게 여유를 두어야 합니다. 침묵은 그들이 모른다는 걸 의미하지 않습니다.

# 면접 진행
어떤 면접이건 면접의 목표는 면접관과 지원자 양쪽 모두가 조직문화 안에서 서로 융화될 수 있는지 확인하는데 있습니다. 아무리 훌륭한 프로그래머여도 제가 절대로 채용하지 않는 사람들이 여럿 있습니다. 그들의 인간적 결함이 다른 팀원들에게 미치는 해로운 영향이 코더로서의 능력보다 더 큰 사람들이죠.

직무에 필요한 기초 지식이 있다고 확인된다면, 그 다음에는 지원자가 어떻게 상위의 문제를 해결했는지를 알아보는 겁니다. 지원자에게 그들에게 친숙한 시스템에 대해서 프로그래밍 작업을 블록 다이어그램의 형태로 표현해 보라고 하는데, 만족스럽게 느낄 정도로 잘 표현해 냈다면, 그 뒤에 "만약 시간이 더 있었다면 어디를 고치거나 어떤 기능을 더 했을까요? 와 같은 열린 결말의 질문을 합니다. 이 질문에 대해 답할 수 없는 사람은 단순히 다른 사람의 의지를 따르는 수동적 태도를 취할 가능성이 매우 높습니다.

또 다른 방법은 어떤 이유에서건 동작하지 않는 코드를 제공하고 그들에게 버그를 찾아내게 하는 것입니다. 많은 프로그래머들의 일과시간은 디버깅으로 소요됩니다. 따라서 저는 버그가 없는 코드를 작성하는 능력만큼이나 그 능력을 높게 평가합니다. 비록 프로그래머들이 버그가 없는 코드를 작성할지라도 그건 매우 드문 일일 것이고, 다른 사람들의 코드와 함께 협업하기 때문에, 그들이 작성한 코드가 아닐지라도 빠르게 코드를 분석하는 능력은 중요합니다.

# 구닥다리 코더
일단 프로그래머로 일을 시작한다면, 의도된 경우보다 우연히 새로운 기술을 습득해야 하는 경우가 더 많을 겁니다. 우리는 어떻게 우리 분야에서 전문성을 유지할 수 있을까요? 전문성을 유지하는 건 평생의 과업입니다. 당신이 전문성을 유지하고자 노력을 제대로 하고 있다면, 그 노력은 영원히 끝마칠 수 없을 겁니다.

어떻게 당신이 과잉 전문화의 늪에 빠졌는지 알 수 있을까요? 가장 쉬운 식별법은 당신의 작업이 끝없이 반복적으로 같은 일만 하며, 그 할 일이 다른 누군가에 의해 설계되는지 확인하는 겁니다. 만약 당신이 의사결정을 할 수 있을 만큼 광범위한 식견을 갖지 못한다면 다른 사람들이 사용하는 도구로 전락할 것이고, 도구는 언젠간 대체되기 마련입니다.

당신이 조직에서 가치가 있는 사람이라는 걸 어떻게 증명해야 하는지 말해보겠습니다.
원할한 운영을 책임지는 시스템 관리자나 이 분야에 속한 모든 이들은 다음과 같은 심각한 두 가지 장애물로 인해 고통받고 있습니다.
첫 번째 장애물은 사람들이 일련의 시스템들이 정상 작동하기 위해 필요한 것들은 이해하지 못한 채 '그냥 되는' 걸 기대한다는 겁니다.
두 번째 고통스러운 장애물은 대부분의 비즈니스에 속한 사람들이 당신 노동의 가치를 알아차리지 못한다는 점입니다.
이 장애물들을 거의 같은 방식으로 다뤄져야 합니다. 바로 대화를 통해서 말이죠. 당신의 사용자들에게 그들의 업무가 조금 더 쉬워졌다고 알리기만 하면 되고, 거기에는 무엇이 더 나아졌는지 명확하게 설명하는 한 페이지 분량의 이메일만 있으면 됩니다. 광범위한 주제에 관심을 두고 계속해서 지식을 쌓으면서 자신의 역할을 정의하며, 사용자들에게 당신이 하는 일과 그것이 왜 일상 생활에 중대한 영향을 미치는지 소통할 수 있다면, 당신이 구닥다리가 될 위험은 확실히 낮아질 겁니다.

성경타자통독 - 말씀.us 서비스 이야기

뭐든창하 — Sun, 28 Sep 2025 20:53:05 +0900

국내에 있는 다양한 성경타자통독 사이트들도 훌륭하지만, 개인적으로 불필요하다 생각한 것들은 제거하고 담백하게 사용하기 위해 만든 말씀.us 성경타자통독 서비스입니다.

https://bible.malsseum.us

말씀.us | 말씀과 우리 - 성경타자통독

말씀.us(말씀과 우리)는 성경 구절을 타이핑하면서 자연스럽게 말씀을 묵상할 수 있는 온라인 서비스입니다.

bible.malsseum.us

가장 불필요하게 생각했던 부분은 경쟁입니다.

어느순간부터 순위에 신경이 쓰이기 시작하면서 말씀 자체에 대한 묵상보다 멍하니 치기만 하고 있게 되는 걸 돌아보게 되었습니다.

성경타자통독 말씀.us 에서는 순위라는게 없습니다.

다만 스스로 꾸준하게 묵상하고 있는지를 확인할 수 있게 도와주고, 매일매일 조금씩 한구절이라도 묵상하면서 타이핑 하는데 도움이 될 기능을 계속 고민하고 있습니다.

모임기능을 기획하고 있는데, 모임기능에서도 서로간에 경쟁이 아닌 격려와 응원이 위주가 되도록 어떻게 해야 할까 고민중입니다.

제 나이도 그렇고 주위에서 함께 통독할 분들의 연령대가 노안이 대부분인지라, 명료한 여러가지 글꼴과 크기도 잘 보일수 있도록 변경 기능을 제공합니다.

모바일로도 가능하니, 잠깐 시간날때 짬내서 한구절이라도 묵상이 가능합니다.

나만의 성경타자통독 말씀.us 묵상 프로필을 공유할 수 있습니다.

내가 좋아하는 구절을 등록할 수 있고, 묵상 과정을 공유하고 주위로부터 격려와 응원을 받아볼 수 있습니다.

https://bible.malsseum.us/track/chris

지금부터 1구절씩이라도 일상속에서 하나님의 말씀을 묵상하는데 말씀.us 성경타자통독과 함께 시작해 보세요.

자바 개발자를 위한 97가지 제안

뭐든창하 — Mon, 22 Sep 2025 22:30:36 +0900

이 책은 학습을 하기 위해서라기 보다는 그래도 자바개발자로 밥먹고 사는데 97지의 제안중에 내가 어느정도를 알고 지키고 있는지가 궁금해서 보게 된 책이다.
참고로 5년정도는 지난 책이라, 그 이후로 바뀐 경향도 있기도 하고, 무엇보다 업무환경이나 동료들의 성향이 모두 다른 개발자들이 그 상황속에서만 겪은 경험으로 얘기하는 제안이기 때문에, 이것이 꼭 정답이라고는 할 수 없음을 감안하고 보았고 그래도 그 중에서 보편적인 제안들은 동의하기도 하고 배울점이라고 생각이 들었다.

01. 자바만으로도 충분하다

많은 개발자가 재사용성을 극대화하기 위해 범용 비즈니스 로직 프레임워크의 개발에 착수했다. 하지만 범용 비즈니스 문제랑 사실상 존재하지 않았으므로 대부분 실패로 돌아갔다. 뭔가 특별한 것을 특별한 방법으로 실행하는 것이야말로 어떤 한 비즈니스를 다른 비즈니스와 차별화하는 것 아닌가. 그러므로 프로젝트마다 새로운 비즈니스 로직을 작성할 일이 있는 것이다.

02. 확인 테스트

JUnit 같은 단위 테스트 프레임워크를 사용하면 함수의 리턴 문자열이 변경될 때 테스트를 수정하기가 어려울 수 있다. 결국 소스 코드 여기저기서 변경된 기댓값을 복사해 붙여넣게 된다. 하지만 확인 테스트 도구를 사용하면 확인한 문자열이 파일에 대신 저장된다. 이 방법은 새로운 가능성을 열어준다. 예를 들면 비교 도구를 열어 변경 사항을 확인한 후 하나씩 머지하면 된다. JSON 문자열 같은 것을 다를 때는 문법 강조 지원도 받을 수 있다. 게다가 각기 다른 클래스에 대한 여러 테스트를 찾아 바꾸기 기능으로 한 번에 수정할 수도 있다.

04. 컨테이너를 제대로 이해하자

오래된 버전의 JVM 까지 컨테이너에 욱여넣게 되면 JVM 어거노믹스(ergonomics)로 인한 여러 위험 요소에 맞닥뜨리게 된다.
JVM 어거노믹스(ergonomics) : CPU의 개수와 가용 메모릴라는 두 가지 핵심 요소를 기준으로 JVM 을 직접 튜닝. JVM 은 이 두 가지 지표를 이용해 어떤 garbage collector 를 이용할지, 어떻게 설정할지, 힙 메모리 크기는 얼마로 할지, ForkJoinPool 의 크기는 얼마로 결정할지 등 중요한 매개변수를 결정한다.
JVM 1.8.191 이전의 JVM 은 자신이 컨테이너 안에서 실행 중이라는 점을 인지하지 못해서 컨테이너가 아닌 호스트OS 의 지표를 측정하려 하고, JVM 이 잘못된 지표를 사용해 스스로 튜닝하려고 시도한다.
최신버전이면서 안전한 런타임을 제공하는 버전의 JVM 을 이용하자.

05. 행위를 구현하는 것은 쉽지만 상태를 관리하는 것은 어렵다

유효성 검사(validation) 프레임워크를 이용해 사용자가 제공하는 입력값은 확인하지만 모든 코드가 '순전히 내부 상태의 값만 변경하는' setter 를 호출할 수 있다.
코드에 setter 가 정말 필요한가? setter 를 자동으로 생성하지 말자.

07. 아키텍처의 품질을 체계화하고 검증하는 방법의 장점

ArchUnit(https://www.archunit.org)은 JUnit 이나 TestNG 같은 자바 단위 테스트 프레임워크를 사용해 자바 코드의 아키텍처를 확인하는 확장 가능한 오픈로스 라이브러리다. ArchUnit 은 순환 의존성은 물론 패키지 및 클래스, 계층과 코드 조각 사이의 의존성을 검사한다.

08. 문제와 업무를 더 작은 단위로 나누기

큰 문제는 해결하는 데 더 오래 걸린다.
좋은 방법은 문제를 더 작은 조각으로 나누는 것이다. 더 작게 나눌수록 더 좋다. 일단 작은 문제를 하나 해결하면 더는 그 문제를 고민할 필요 없이 다른 문제로 넘어가면 된다.

09. 다양성을 인정하는 팀 만들기

협업의 핵심은 팀 내 심리적 안정성과 신뢰를 쌓는 것이다.
심리적으로 안정된 팀에서는 사람들이 커뮤니케이션은 그 비용보다 장점이 더 크다고 생각하는 경향이 있다. 참여를 통해 변화에 대한 저항이 줄어들고, 사람들이 더 자주 참여할수록 더 참신한 아이디어가 떠오른다.
개인의 성향도 무시할 수 없다. 개인의 성향은 다른 성향의 사람을 신뢰할 수 있는 환경을 만드는 것만큼이나 중요하다.
새로운 프로세스, 코딩 스타일, 커밋 메시지 형식을 정립하길 좋아하고 적절한 절차를 따르지 않으면 한 번 더 설명해 주는 사람도 있다. 함께 일하는 팀원 중에는 약속은 보수적으로 하면서 기대를 웃도는 결과물을 내놓는 사람도 있고, 의존성 갱신, 패치 설치, 보안 위험 등 뭐든지 잘못될 수 있다고 생각하는 사람도 있다. 모두의 다양성을 존중하고 너무 심하게 몰아붙이진 말자.

13. 코드 복원전문가

최고의 코드는 나중에 그 코드를 보게 될 프로그래머를 생각하며 작성한 코드다.
기업은 그저 또 하루, 다음 전력질주, 그 다음 주기를 살아가기에 급급하다. 더 안타까운 점은 누구도 이런 현상에 대해 우려하지 않는 것 같다는 점이다.
처음부터 영원히 지속될 것을 만들려면 비용이 크게 증가하므로 그럴 가치가 없지만 반대로 단기 이익만을 생각하고 코드를 만들면 결국 그 자체의 무게를 견지지 못하고 무너질 것이다. 그렇기에 '(모두가 바라지만 거의 항상 실패하는)같은 것을 더 나은 방법으로 다시 만드는' 일이 아니라 기존 코드를 천천히 다음어 다시 관리할 수 있는 상태로 재창조하는 코드 복원전문가가 필요하다. 여기에 테스트를 조금 더 추가하고, 말도 안되는 클래스를 잘게 나누고, 사용하지 않는 기능은 과감히 제거해서 더 나아진 코드를 다시 내놓는 그런 사람이 필요하다.

14. JVM의 동시성

자바는 분산 메모리를 지원하지 않으므로 멀티스레드 프로그램을 여러 머신에 수평적으로 확장하는 것이 불가능하다.
공유 메모리 제한을 극복하는 가장 간단한 방법은 Lock 대신 분산 큐(distributed queue)를 이용해 스레드를 조율하는 것이다.

16. 선언전 표현식은 병렬성으로 가는 지름길이다

선언적(declarative)프로그래밍은 목적을 달성하기 위한 방법에 대한 목표 추상화를 표현하는 코드를 작성하는 것이다.


  // 명령형 코드
  List<Integer> squareImperative(final List<Intenger> datum) {
    var result = new ArrayList<Integer>();
    for (var i = 0; i < datum.size(); i++) {
      result.add(i.datum.get(i) * datum.get(i));
    }
    return result;
  }
  
  // 선언적 코드
  List<Integer> squareDeclarative(final List<Intenger> datum) {
  	return datum.stream().map(i -> i * i).collect(Collectors.toList());
  }
  
  // 선언적 코드(병렬)
  List<Integer> squareDeclarativeParallel(final List<Intenger> datum) {
    return datum.parallelStream().map(i -> i * i).collect(Collectors.toList());
  }

17. 더 나은 소프트웨어를 더 빨리 전달하기

여러분은 코드를 작성하고 대가를 받는 것이 아니라 사용자가 뭔가 가치 있는 것을 더 쉽게 할 수 있도록 만듦으로써 대가를 받는 것이며, 여러분이 작성한 코드가 프로덕션 환경에서 동작하기 전까지는 아무리 열심히 일한들 소용이 없다.
실제 구현에 앞서 모호한 요구 사항을 명확하게 이해하려 하지 않고 자의적인 해석으로 업무를 수행하는 등 절차를 무시하지 않는다.
여러분이 작성한 코드가 요구 사항에 부합하는지를 확인하는 자동화된 테스트를 작성하고 실행하는 등 절차를 더 빠르게 수행하기 위해 노력한다.
더 나은 소프트웨어란 '올바른 기능을 구현'하는 것과 '올바르게 기능을 구현'하는 두 가지 개념을 짧게 표현한 것이다.
'올바른 기능을 구현'하는 것은 항상 요구 사항과 수용 조건을 만족하는 코드를 작성한다는 뜻.
'올바르게 기능을 구현'하는 것은 다른 프로그래머도 버그를 성공적으로 수정하거나 새로운 기능을 추가할 수 있도록 이해하기 쉬운 코드를 작성한다는 뜻.
문제가 발생할 확률을 낮추고 사용자들이 더 신속하게 여러분이 업데이트한 시스템을 사용할 수 있도록 더 작은 변경 내역을 프로덕션 환경에 더 자주 배포하는 것을 권장한다.

18. 지금 몇 시에요?

LocalDateTime 은 2019년 10월 13일 오후 1시 15분의 개념을 의미한다. 이 시간은 여러 시간선(timeline)에 걸쳐 존재할 수 있다. Instant 는 이 시간선의 특정 지점을 가리킨다 이 지점은 보스턴이든 베이징이든 모두 같다. LocalDateTime 부터 Instant 를 얻으려면 특정 시간에 대한 협정 세계시(UTC) 오프셋과 일광 절약 시간(DST) 규칙을 가진 TimeZone 이 필요하다. ZonedDateTime 은 TimeZone 정보를 가진 LocalDataTime 이다.

19. 기본 도구의 사용에 충실하자

진저어한 기술을 손에 넣으려면 기본 도구를 이해하고 충분히 활용하자.

22. 자바 컴포넌트 간의 이벤트

자바의 모든 클래스를 컴포넌트로 간주할 수 있다. 자반의 이벤트는 컴포넌트의 상태를 변경하는 행위다.
Oven 컴포넌트와 Person 컴포넌트를 가지고 있다고 가정해보자. 이 두 컴포넌트는 병렬로 존재하며 각자 독립적으로 동작한다. Person 을 Oven 의 일부로 선언해서도 안 되고 반대로 Oven 을 Person 의 일부로 만들어서도 안된다. Person 컴포넌트가 배고픔을 느끼면 Oven 컴포넌트가 음식을 준비하도록 하는 기능을 구현해보자.
1. Oven 컴포넌트에서 짧은 간격으로 Person 컴포넌트를 확인한다. 이 방법은 Person 컴포넌트를 귀찮게 할 뿐 아니라 여러 Person 인스턴스를 확인해야 한다면 Oven 컴포넌트 자체에도 부담이 된다.
2. Person 컴포넌트가 공개 이벤트 Hungry 를 발생하고 Oven 컴포넌트가 이를 구독해서, 이벤트가 발생하면 이를 알아채고 음식을 준비한다. 이 방법은 두 컴포넌트 간에 직접 결합 없이도 서로를 리스닝(listening)하고 통신할 수 있는 이벤트 아키텍처를 사용하는 방법이다.

23. 피드백 루프

제대로 만드는 것을 고민하지 말고 잘못된 것을 어떻게 알아낼지, 잘못된 것을 찾았을 때 얼마나 쉽게 수정할 수 있는지를 고민하자. 왜냐하면 분명 뭔가 잘못될 것이기 때문이다.

24. 불꽃 그래프를 이용한 성능 확인

보편적인 자바 프로파일러(profiler)는 바이트 코드 계측(byte code instrumemtation)이나 샘플링 기법(짧은 주기로 stack trace 를 수집하는 방법)을 이용해 실행 시간이 긴 구간을 찾는다.
거의 모든 시스템으로부터 stack tace 를 수집해 기발한 형태의 다이어그램으로 보여주는 불꽃 그래프(flame graphs, https://oreil.ly/2kCDd)
trace 를 각 stack 수준으로 정렬해 집계한 것, 각 스택 수준별 카운트는 코드의 각 부분의 총 실행 시간의 백분율을 의미.
불꽃은 아래에서 위로 향하며 프로그램이나 thread(main 또는 event loop)의 진입점부터 코드가 실행되는 과정을 거쳐, 불꽃의 끝에서는 코드 실행이 완료되는 지점을 표시한다.
중요한 것은 각 블록의 너비와 스택의 깊이(depth). 그래프의 높이가 높을수록 더 많은 시간을 허비한 것. 특히 꼭대기 부분에서 매우 넓은 블록을 본다는 것은 해당 부분에서 병목이 발생하고 있다는 뜻.

26. 자주 릴리스하면 위험을 줄일 수 있다

자주 릴리스하면 위험을 줄일 수 있다.
위험이란 장애가 발생했을 때 받을 수 있는 최악의 영향과 장애가 발생할 가능성을 결합한 요소.
실패할 시나리오에 대한 자동화 테스트를 구축하자. 그리고 새로운 실패를 발견할 때마다 테스트에 추가하자. 회귀 테스트를 계속 늘리되, 가볍고 빠르며 반복할 수 있게 유지하다.

27. 퍼즐에서 제품까지

'내 직업은 코드를 바꾸는 일이 아니라 변화를 설계하는 일'이라고 생각한다. 코드는 그저 세부 사항일 뿐이다.
기능 플래그, 사용이 금지된 deprecated 메서드, 하위 호환성을 처리하기 위해 if 문으로 도배한다고 해서 잘못된 코드라고 볼 수 없다. 이런 if 문은 변화를 표현하는 것뿐이다. 그리고 중요한 것은 변화이지 코드의 어떤 특정 상태가 아니다.
변화를 디자인한다는 것은 관측성(observability)을 구축해서 누가 금지된 기능을 여전히 사용하는지, 누가 새로운 기능에서 값을 얻어가는지 확인할 수 있음을 의미한다.
'올바른' 제품은 한 가지로 정의할 수 없다. 분명 많은 것이 올바르지 않기에 '오동작'하지 않도록 주의해야 한다. 그 외에는 '더 나은 것'에 초점을 맞춘다.

29. 가비지 컬렉션은 나의 친구

현대의 가비지 컬렉션은 메모리 할당/해제보다 더 빠르게 동작하며 GC가 실행되는 시간에도 속도를 높일 수 있다. 가비지 컬렉터는 메모리 해제 외에 다른 작업도 수행하기 때문이다. 즉 메모리의 할당과 메모리상의 객체 재정렬도 실행한다.
어째서 메모리상의 객체 위치가 애플리케이션 성능에 영향을 주는 걸까? 프로세서의 캐시에서 객체를 불러오면(fetch) 이웃한 데이터도 함께 가져오게 된다. 그래서 다음 작업에서 이웃한 데이터에 접근하면 빠르게 실행된다. 이렇게 동시에 사용하는 객체를 메모리상에 서로 가깝게 배치하는 것을 객체 지역성(object locality)라고 하며 성능 향상에 도움이 된다.
힙 메모리가 파편화되어 있으면 프로그램이 객체를 생성할 때 충분한 크기의 빈 메모리 공간을 찾는 시간이 오래 걸린다. 실험 삼아 강제로 GC가 더 자주 실행되게 하면 GC 오버헤드는 많이 증가하지만 애플리케이션 성능이 향상된다.
성능을 측정할 때는 비즈니스 가치와 관련 있어야 한다. 초당 트랜잭션, 평균 서비스 시간 또는 최악의 응답 지연을 최적화하자. GC가 소비하는 시간을 너무 세세히 최적화할 필요는 없다. GC가 소비하는 시간은 실질적으로 프로그램의 속도에 도움이 되기 때문이다.

30. 이름 짖기를 잘 하자

먼저 무의미한 이름(foo), 너무 추상적인 이름(data), 중복된 이름(data2), 모호한 이름(DataManager), 약자나 줄인 이름(dat), 한 글자(d) 등은 피하는 것이 좋다. 이렇게 모호한 이름을 사용하면 프로그래머가 시간을 들여 코드를 읽은 후에야 코드를 작성할 수 있으므로 모든 사람의 업무 속도가 저하된다.
이름을 지을 때 단어를 최대 4개 사용(id 나 문제 도메인에 적용된 것을 제외하고)하고 약어는 사용하지 말자. 한 단어만으로 충분한 경우는 드물다. 네 단어 이상 사용하는 것은 어설프며 더는 의미를 부여하지 않는다.
복수형은 집합 명사로(예를 들면 appointment_list 대신 calendar로) 대체하자.
엔티티 쌍의 이름은 관계의 이름으로(예를 들면 company_person 은 employee, owner, shareholder 등으로) 대체하자.
클래스와 객체 이름을 혼합하지 말자. 날짜 필드인 dateCreated 는 created 로 바꾸고 Boolean 타입의 필드 isValid 는 valid 로 바꾸자. 그러면 객체 이름에 타입이 중복되는 상황을 방지할 수 있다.
결국, 이름 짓기를 마스터한다는 것은 구시대의 규칙 중 어떤 것을 지키지 않을지 선택하는 것이다.

32. null 을 피하는 방법

어떤 값을 저장할지 결정하기 전에 변수를 선언하는 것은 대부분 좋은 생각이 아니다. 초기화가 복잡하다면 초기화 로직을 메서드로 옮기자.
변수를 null 값으로 초기화하면 에러 처리 코드를 제대로 작성하지 않을 경우 의도치 않게 널 값을 노출하게 된다.
null 값을 리턴하기 보다 Optional 를 리턴하는 것이 코드를 더욱 명확하게 만드는 방법이다.
null 값 매개변수를 전달하거나 받지 말자. T 객체가 필요하다면 이 객체를 전달해 달라고 요구하자. 이 객체가 없어도 된다면 아예 요구하지 말자.

38. 일은 끝났어요. 그런데...

첫 번째 작업을 완전히 끝내지 못한 상태에서 다른 작업을 시작했다고 생각해 보자. 바로 이 시점에 기술 부채가 생겨나는 것이다! 경우에 따라서는 선택에 의해 기술 부채를 남기기도 한다. 하지만 여러분이 끝내지 않은 일을 끝냈다고 말하는 바람에 기술 부채가 생기는 것보다는 논의를 거쳐 기술 부채를 남기도록 결정하는 것이 훨씬 올바른 선택이다.
반드시 기억하자. 실제로 끝내기 전까지는 절대 끝냈다고 말하지 말자.

45. 최신 동향을 파악하자

최신 동향을 파악하는 것은 시장에 있는 모든 기술을 알아야 한다는 의미가 아니다. 그저 계속 동향을 파악하면서 공통 키워드에 주목하고 기술 트렌드를 이해하면 된다. 더 깊이 공부하는 것은 현재 수행 중인 업무와 관련이 있거나 개인적으로 흥미가 있을 때(이상적으로는 둘 다 해당할 때) 해도 늦지 않다.

46. 주석의 종류

자바독(Java Doc) 주석(/** ... */ 형식)은 클래스, 인터페이스, 필드, 메서드에만 사용하며 이들을 선언한 코드 바로 위에 작성한다. 자바독 주석은 계약(contract) 이다. 이 주석으로 API 사용자에게 구현의 상세는 숨기고 타입이 추상화하는 동작을 설명한다. 그와 동시에 이 메서드를 실제로 구현할 개발자에게도 어떤 동작을 구현해야 하는지를 설명한다.
블록(Block) 주석은 /* ... */ 로 둘러싼다. 이 주석은 어느 자리에 작성ㅎ래도 무관하며 개발 도구는 거의 이 주석을 무시한다. 이 주석은 주로 클래스나 메서드의 시작 지점에서 그 구현 내용을 설명할 때 사용한다. 기술적인 상세 내용을 작성할 수도 있지만 코드를 작성하게 된 시점의 주변 상황(코드는 어떤 동작을 하는지 설명한다면 주석은 왜 이 동작이 필요한지를 설명한다)을 설명하거나 또는 현재 코드가 고려하지 않는 코드 실행 경로 등을 설명하기 위한 용도로도 사용한다. 보편적으로는 여러분이 처음 구현한 솔루션이 완전히 마무리되지 않았을 때, 상황에 의해 어떤 절충안을 채택했을 때, 요구 사항이 이상하거나 의존하는 API 가 형편없어서 코드가 볼썽사나울 때 당시 상황을 주석으로 남기는 용도로 사용하자. 나중에 본인이나 다른 동료가 이 코드를 읽어보면 주석에 고마움을 느낄 것이다.
줄 단위 주석은 코드 동작을 설명하기 위해 주로 사용하는데 이는 사실 좋은 방법이 아니다. 하지만 코드가 굉장히 특이한 언어의 기능을 사용하거나 조금만 바꿔도 코드에 문제가 생기는(예를 들면 동시성 문제) 등 몇몇 상황에서는 여전히 유용한다.

48. 컬렉션을 제대로 이해하자

컬렉션은 순서가 있는(ordered) 것과 순서가 없는(unordered) 것으로 구분할 수 있다.
또 다른 방법은 정렬된(sorted) 것과 정렬되지 않은(unsorted) 것으로 나눌 수 있다.
가장 중요한 차이점은 순서가 있는 컬렉션에는 아이템이 항상 같은 순서로 저장되지만 정렬되지는 않는다. 정렬된 컬렉션은 정렬 순서를 예측할 수 있으므로 아이템의 순서 역시 예측이 가능하다. 모든 정렬된 컬렉션은 순서가 있는 컬렉션이지만, 순서가 있는 컬렉션이라고 해서 모두 정렬된 컬렉션은 아니라는 점을 기억하자. JDK 는 순서가 있는 컬렉션, 순서가 없는 컬렉션, 정렬된 컬렉션, 정렬되지 않은 컬렉션을 구현한 여러 클래스를 제공한다.
List 는 안정적인 인덱스를 기반으로 순서가 있는 컬렉션을 구현한 인터페이스다. 구현체(ArrayList, LinkedList)
Map 은 키와 값의 관계를 유지하며 유일한 키 값만 보관하는 인터페이스다. 구현체(HashMap, LinkedHashMap, TreeMap)
Set 은 유일한 아이템의 컬렉션을 정의하는 인터페이스다. 구현체(HashSet, LinkedHashSet, TreeSet). 내부적으로는 Map 을 사용한다.

51. 카타를 하기 위해 학습하고 카타를 이용해 학습하자

코드 카타는 실습으로 특정한 기술을 연마하는 실천적인 프로그래밍 기법이다.
코드 카타를 직접 만들어보고 싶다면 다음 절차를 따라 해보자.
1. 학습하려는 주제를 선정한다.
2. 원하는 지식을 설명할 수 있으며 성공하는 단위 테스트를 작성한다.
3. 최종 솔루션에 만족할 때까지 반복해서 코드를 리팩토링한다. 리팩토링 과정에서 단위 테스트가 실패하지 않는지 확인한다.
4. 테스트가 실패하도록 실습한 솔루션을 삭제한다.
5. 실패하는 테스트와 관련 코드 그리고 빌드 결과물을 버전 관리 시스템에 커밋한다.

52. 레거시 코드를 사랑하는 방법

레거시 시스템을 유지보수 해야 한다면 어떨까?
첫 번째 해결책은 테이프로 감는 것이다. 숨을 꾹 참고 결함을 수정한다. 오랜 시간이 지나도 별로 훼손되지 않았을 수도 있지만 깨진 유리 하나만 있어도 순식간에 나머지 유리도 모조리 박살이 날 것이다.
두 번째 해결책은 새로운 시스템을 바닥부터 다시 개발하는 것이다. 대부분 재개발은 제대로 진행되지 않거나 끝이 나지 않는다. 예전 코드가 형편없이 보이겠지만 그 코드는 이미 수많은 전투에서 살아남은 코드다. 시스템을 새로 개발하기 시작하는 여러분은 그동안 어떤 전투가 있었는지 모를뿐더러 그 비즈니스 도메인에 대한 지식의 상당 부분을 잃는 셈이다.
그럼 어떻게 해야 할까? 제대로 된 방법으로 수정하는 방법을 배워야 한다. 교살자 패턴(https://oreil.ly/SWJFc)을 이용하면 간단한다. 좋지 않은 코드를 깔끔하고 철저히 테스트한 새 코드로 교체하는 것부터 시작하고 이 작업을 반복해서 예전 애플리케이션 위에 새로운 애플리케이션을 만들어 가는 것이다. 설령 완전히 끝내지는 못하더라도 오래된 코드가 계속 썩어가도록 두는 것보다는 새로운 코드와 오래된 코드가 섞여 있는 편이 낫다.

55. 자바 API를 디자인하는 기술

우리는 모두 API 디자이너다. 소프트웨어는 그 자체로는 아무 의미가 없다. 다른 개발자가 작성한 다른 소프트웨어와 함께 동작할 때 비로소 의미를 가질 수 있다.
처음부터 제대로 된 API를 작성할 수 있다고 생각하지 말자. API를 디자인하는 것은 반복 작업이며, API를 개선할 유일한 방법은 개밥 먹기(dogfooding, 자신이 만든 제품이나 서비스를 직접 사용해 보며 문제나 버그를 찾는 방법)뿐이다. API 에 대한 테스트와 예제를 작성하고 동료 및 사용자와 끊임없이 소통하자. 몇 버너이고 반복해서 불분명한 의도, 불필요한 코드, 미처 추상화되지 않은 부분을 개선하자.

56. 간결하고 가독성이 좋은 코드

코드는 한 줄 한 줄 모두 최대한 명확해야 한다. 모든 코드는 필요한 것이어야 한다. 가독성이 좋고 간결한 코드를 작성하려면 형식(format)과 내용(content)에 주의를 기울여야 한다.
* 들여쓰기를 이용해 코드를 정리하자.
* 변수와 메서드에 의미 있는 이름을 채택하자.
* 필요한 경우에는 코드에 주석을 작성하자.
* 주석처리한 코드는 커밋하지 말자. 머뭇거리지 말고 그냥 지우자.
* 혹시 나중에 필요할지도 모를 코드까지 작성하는 오버엔지니어링의 우를 범하지 말자. 필요 이상의 코드는 버그나 유지보수 오버헤드를 야기할 뿐이다.
* 장황한 코드를 작성하지 말자. 개발자가 얼마나 많은 양의 코드를 작성했는지보다 얼마나 깔끔하게 가독성이 좋은 코드를 작성했는지로 평가하자.
* 아직 시도해 본 적이 없다면 함수형 프로그래밍을 공부하자.
* 짝 프로그래밍(pair programming)을 도입하자. 코드를 작성하는 동안 다른 사람에게 스스로의 선택과 그 이유를 설명해야 하므로 더욱 의미 있는 코드를 작성하는 방법이기도 한다.
코드가 복잡할수록 버그도 늘어난다. 쉽게 이해할 수 없는 코드는 더 많은 버그를 내포하고 있다.

60. 업계의 발전에 기여하는 기술의 필요성

현실 세계의 문제를 해결하기 위한 차세대 장난감 따위는 필요하지 않다.
자바는 이런 며에서 훌륭한 기술이다. 현대식 언어 기능을 아우를 정도로 새로운 언어지만 신뢰할 수 있을 정도로 성숙해 있다. 대규모 코드도 잘 정리할 수 있으며, 순수한 기술적인 문제에서 벗어나 실질적인 비즈니스 문제에 집중하는 데 도움을 주는 제품, 도구, 생태계의 지원도 훌륭하다. 환경과 시스템을 분리할 수 있는 강력한 스택이며 숙력된 직원을 찾을 수 있을 정도로 표준화되었다.
자바는 적어도 수십 년은 지속할 수 있는 시스템을 구현할 정도로 신뢰할 수 있으며 안정적인 플랫폼이다.
엔지니어링은 유행을 따라서는 안 된다. 소프트웨어 개발은 지식과 조직이 습득한 것이다. 어떤 부품이 어떻게 동작하는지 모른다면 전체가 어떻게 동작할지 모른다는 뜻이다. 어느 정도 동작하는 코드를 서로 주고받는 것이 재미있을지는 모르지만, 어려운 현식을 여유롭게 감당할 수 있는 뭔가를 개발하는 것이 바로 프로의 자세다.

64. 기본 접근 한정자를 가진 기능 단위 패키지


  // 계층별 패키지 구조
  tld.domain.project.model.Company
  tld.domain.project.model.User
  tld.domain.project.controllers.CompanyController
  tld.domain.project.controllers.UserController
  tld.domain.project.storage.CompanyRepository
  tld.domain.project.storage.UserRepository
  tld.domain.project.service.CompanyService
  tld.domain.project.service.UserService

이러허게 클래스를 계층별 패키지 구조로 정리하면 너무 많은 메서드를 공개(public) 메서드로 선언해야 한다. UserService 는 User 클래스를 저장소로 부터 읽고 쓸 수 있어야 한다. 그런데 UserRepository 가 다른 패키지에 있으므로 UserRepository 의 거의 모든 메서드를 공개해야 한다.


  // 기능 단위 패키지 구조
  tld.domain.project.company.Company
  tld.domain.project.company.CompanyController
  tld.domain.project.company.CompanyService
  tld.domain.project.company.CompanyRepository
  tld.domain.project.user.User
  tld.domain.project.user.UserController
  tld.domain.project.user.UserService
  tld.domain.project.user.UserRepository

클래스를 이렇게 정리하면 UserRepository 의 어떤 메서드도 공개할 필요가 없다. 모든 매서드를 패키지 비공개로 선언해도 UserService 클래스가 얼마든지 사용할 수 있다. 그래서 필요에 따라 UserService 클래스의 메서드만 공개하면 된다.

66. 좋은 단위 테스트에 기반한 프로그래밍

@Test 애노테이션이 이미 이 코드가 테스트 코드임을 말해 주고 있다. 코드를 읽는 사람에게 지금 보는 코드가 테스트 코드임을 알려주는 것보다는 정확히 뭘 테스트하는지 알려줘야 한다.
테스트 중인 메서드 이름을 따서 테스트의 이름을 붙이라는 것이 아니다. 어떤 동작, 속성, 기능 등을 테스트하는지 알려주라는 뜻이다.
테스트의 목적이 무엇이냐고 묻고 싶다. '이 코드가 동작하는지' 테스트하는 것이 목적인가? 그렇다면 테스트의 목적 중 절반만 달성한 것이다. 코드를 작성하는 데 어려움은 '이 코드가 동작하는지'를 결정하는 것이 아니라 '이 코드가 동작한다'의 의미가 무엇인지를 결정하는 것이다.
예를 들면, 언더스코어(_) 문자를 이용해 가독성을 개선해서 Addition_of_item_with_unique_key_is_retained() 가 적합하다. @DisplayNameGeneration(DisplayNameGenerator.ReplaceUnderscored) 를 사용하면 'Addition of item with unique key is retained' 처럼 예쁘게 출력된다.
테스트가 성공한다고 해서 그 코드가 동작한다는 점을 보장하지는 않는다. 하지만 좋은 단위 테스트를 작성하려면 실패의 의미가 명확해야 한다. 즉 코드가 동작하지 않음을 의미해야 한다. '프로그램의 테스트는 버그가 있음은 보여줄 수 있지만 버그가 없음은 절대 보여주지 못한다!'
단위 테스트는 테스트가 제어할 수 없는 것에 의존해서는 안 된다는 것을 의미한다. 파일시스템, 네트워크, 데이터베이스, 비동기 코드의 실행 순서 등에 영향을 받을 수는 있지만 제어할 수 없다. 테스트 중인 단위는 올바른 코드가 실패를 유발할 수 있는 것에 의존해서는 안 된다.

69. 자바의 재탄생

자바 9 이후부터는 매년 3월과 9월에 자바의 새로운 메이저 버전이 릴리스된다.

72. 속독을 위한 리팩토링

코드의 구조는 코드를 읽는 사람을 도와줘야 한다.
코드를 작성할 때는 스스로 빨리 읽을 수 있는지 확인해 보자. 시각적 고정과 메타 가이딩을 염두에 두고 코드를 작성하자. 관련 정보를 눈으로 확인할 수 있는 논리적인 느낌을 줄 수 있도록 코드 구조를 갖추자. 그러면 코드를 빨리 읽을 수 있음 뿐만 아니라 흐름도 더 잘 파악할 수 있다.

78. 테스트 주도 개발

보편적으로 고품질의 소프트웨어란 다음과 같은 속서어을 갖는 코드를 의미한다.
* 모듈성(Modularity)
* 낮은 결합(Loose coupliing)
* 응집력(Cohesion)
* 적절한 관심사 분리(Good separation of concerns)
* 정보 은폐(Information hiding)
테스트 가능한 코드는 이런 속성을 가지고 있다. 코드 커버리지는 그다지 좋은 지표가 아니다.
TDD는 형편없는 개발자를 훌륭한 개발자로 바꾸지는 않지만 더 나은 프로그래머를 양산한다.
TDD는 매우 간단해서 '레드, 그린, 리팩터(Red, Green, Refactor)'의 순서만 지키면 된다.
* Red : 이 단계에서는 코드의 행위적 의도를 표현하는 것에 집중한다.
* Green : 테스트를 통과하기 위한 최소한의 작업만 수행한다. 그 방법이 설령 너무 소박해 보이더라도 그렇게 해야 한다.
* Refactor : 일단 Green 상태로 돌아왔다면 안전하게 리팩토링이 가능하다. 그러면 잘못된 방향으로 빠지지 않고 올곧게 작업을 진행할 수 있다. 작고 간단한 단계를 만들고 테스트를 다시 실행해서 모든 것이 제대로 동작하는지 확인한다.

79. bin 디렉터리에는 좋은 도구가 너무나 많다

* jps : 실행 중인 모든 JVM 의 목록
ex) jps -m : main 메서드에 전달된 매개변수
ex) jps -v : JVM 자체에 전달된 모든 매개변수
* jmap : JVM 프로세스의 메모리 공간에 대한 요약 정보
ex) jmap -heap {processId}
* jhat : jmap 명령으로 생성한 파일을 이용해 로컬 웹서버를 실행하여 정보를 확인
ex) jhat {heap dump file}
* jinfo : JVM 명령줄 플래그와 JVM이 로드한 모든 시스템 속성 확인
ex) jinfo {processId}
* jstack : JVM 안의 모든 자바 thread 의 stack trace 출력
ex) jstack {processId}

82. 스레드는 인프라스트럭처로 취급해야 한다

만일 코드가 동기화 구문, lock, mutex 등(모두 운영체제를 위한 것이다)을 사용한다면 뭔가 잘못하고 있을 가능성이 크다.

83. 정말 좋은 개발자의 세 가지 특징

첫 번째이자 가장 중요한 특징은 호기심이다.
두번째와 세 번째 특징은 공감과 상상력이다.

84. 마이크로서비스 아키텍처의 트레이드 오프

측정 가능한 트레이드오프를 설명하는 CAP 이론, 이 이론은 실행 중인 데이터베이스는 일관성(consistency), 가용성(availability), 파티션 내구서어(partition tolerance) 등 세 가지 특성 중 두 가지만 보장할 수 있다는 이론이다. 애플리케이션이 네트워크 경계를 넘어서 상태를 공유한다면 일관성과 가용성 중 하나를 선택해야 하며 둘 다 보장할 수는 없다고 주장한다.
소프트웨어 개발의 세계에 발을 들이다 보면, 결국 올바른 선택 따위는 없다는 것을 알게 된다. 최선의 선택이 있다고 믿으며 그 선택에 엄청난 논쟁을 벌인다.

85. 예외를 확인하지 말자

확인된 예외(Checked Exception)의 의도는 메서드가 성공적으로 실행될 때의 입력과 출력의 타입이 중요한 만큼, 메서드가 실패하는 경우도 예외의 타입으로 표현해서 두 가지 시나리오 모두 같은 수준의 타입 중요성을 갖도록 하자는 것이다. 기반 코드가 작고 폐쇄적이라면 일부 예외를 간과하지 않도록 하는 이런 타입 중요성은 달성하기 쉬운 목표다. 그리고 일단 달성하면 코드의 완성도에 어느 정도(아주) 기본적인 보상도 얻을 수 있다. 하지만 이는 기반 코드의 크기가 작을 때나 동작할 법한 사례로, 규모가 커지면 제대로 동작하지 않는다.
원래 의도가 무엇이든 확인된 예외는 이제 일상에서 그저 장애물로 취급되고 있다. 확인된 예외는 문법적으로 부담이 될 뿐이고 실질적인 문제는 그보다 더 크다. 단순히 프로그래머의 학습을 요구하거나 구문이 장황해지는 문제가 아니다. 프레임워크 개발이나 확장 가능한 코드의 측면에서 볼 때 확인된 예외는 애당초 결함이었던 것이다.
인터페이스를 정의한다는 것은 메서드 시그니처를 이용해 계약을 표현한다는 것이다. 인터페이스는 안정적으로 정의하기도 어렵고 나중에 개선하기도 어렵다. 여기에 throws 까지 추가하면 일은 더 어려워진다.
확인되지 않은 예외(Unchecked Exception)를 사용하는 방법이 그나마 가장 가볍고, 가장 안정적이며, 가장 열린 접근법이다.

87. 퍼즈 테스트의 어마무시한 효과

프로그래머는 대부분 잘못된 입력이 주어졌을 때 소프트웨어가 얼마나 견고하게 동작하는지를 테스트하는 것보다 유효한 입력이 주어졌을 때 소프트웨어가 올바르게 동작하는지를 테스트한다는 뜻이다.
퍼즈 테스팅(Fuzz Testing)은 이미 존재하는 테스트 슈트(suite)에 쉽게 부정적 테스트(negative testing)를 추가할 수 있는 엄청나게 효율적인 기법이다.
* 변형 기반 퍼저(mutation-based fuzzer)는 유효한 입력의 예시를 변경해서 유효하지 않은 테스트 입력을 생성한다.
* 생성 기반 퍼저(generation-based fuzzer)는 문법 같은 형식화된 입력을 생성한다. 이 입력은 유효한 이렵의 구조를 정의한다.

88. 커버리지를 이용해 단위 테스트 개선하기

만일 커버리지를 높이기 위한 목표만으로 테스트를 작성한다면 테스트와 실제 구현 코드의 결합이 높아질 수 있다.
전체 코드베이스의 테스트 커버리지를 주기적으로 측정한다면 절대적 숫자보다는 트렌드에 집중하라고 권하고 싶다. 커버리지 대상이 일관적이지 않다면 대부분 테스트하기 쉬운것만 테스트하려 한다는 사실을 목격했기 때문이다.

89. 사용자 정의 아이덴티티 애노테이션을 자유롭게 사용하자

아이덴티티 애노테이션(identity annotation)의 차이점은 어떤 기능도 갖지 않는다는 점이다. 이 애노테이션은 단지 코드나 아키텍처의 어떤 관점을 다루고 분석하거나 문서화하기 위해 사용하는 프로그래밍적 정보를 제공할 뿐이다. 아이텐티티 애노테이션을 사용하면 트랜잭션 경계나 도메인, 서브도메인을 특정하고 서비스의 분류, 프레임워크 토드의 표시 등 여러 방법으로 활용할 수 있다.

90. 테스트를 이용해 더 나은 소프트웨어를 더 빨리 개발하자

테스트는 안정적이어야 하며 자신감을 향상할 수 있어야 한다. 테스트를 믿을 수 없다면 수정하거나 차라리 지워버리자. 절대 무시해서는 안 된다. 테스트를 무시하면 나중에 그 이유를 알기 위해 더 많은 시간을 낭비하게 될 것이다. 더는 가치가 없다면 테스트를 지워버리자.

91. 커뮤니티의 힘을 빌려 경력을 개발하자

여러분의 경력과 관련한 결정을 내리는 사람은 여러분이 작성한 코드를 보지 않는 경우가 태반이기 때문이다. 그러므로 그런 사람이 여러분의 이름을 듣고 볼 수 있도록 해야 한다.

95. 주석은 한 문장으로 작성하라

대규모 애플리케이션에서 주석을 올바르게 작성하는 방법은 다음 절차에 따라 한 문장으로 작성하는 것이다.
1. 최선의 코드를 작성한다.
2. 모든 공개(public) 클래스와 메서드/함수에 한 문장 주석을 작성한다.
3. 코드를 리팩토링한다.
4. 필요 없는 주석을 제거한다.
5. 코드를 잘 설명하지 못하는 주석은 다시 작성한다.
6. 정말 필요한 곳에만 상세 주석을 추가한다.
이 방법은 코드가 스스로의 존재 이유를 설명하지 못해서든 아니면 미처 코드를 리팩토링할 시간이 어벗어서든 어떤 주석을 남겨둬야 하는지 확인하는 데 도움이 된다. 직접 한 문장 주석을 작성해 보면 알게 될 것이다. 만약, 좋은 주석을 작성하는데 몇 분이 걸린다면 그 주석은 정말 필요한 주석이며, 나중에는 이 주석 덕분에 코드를 파악하는 시간을 절약할 수 있다. 그 이후에 그 코드가 주석이 필요하지 않는 '명확한' 코드임을 알았다면 그 자리에서 주석을 삭제해야 한다.
항상 코드만으로 설명할 수 없는 것만 언급하라. 왜라는 질문에 코드로 답할 수 없는 것만 설명하기 위한 주석을 최소한으로 유지해야 한다.

이펙티브 엔지니어

뭐든창하 — Fri, 14 Feb 2025 22:48:00 +0900

알라딘 중고서점에서 우연히 찾은 책인데, 우연히라고 하기에는 유명했고 좋은 내용이 가득있어서 왜 이제서야 발견했나 싶은 책이다.

훌륭한 엔지니어로써 어떻게 해야 하는지, 어떻게 성장해야 하는지 시중에 나와있는 책들을 어느정도 봐서 그런지 특별할껀 없지만, 그렇기에 대부분의 책에서 공통적으로 얘기하는 부분들만 잘 내것으로 만든다면 나도 꽤 좋은 엔지니어가 될 수 있지 않을까 한다. 물론 글로 접하는 말은 쉬워 보이기도 하고 읽는 것만으로 내 것 인것 같지만, 실제로 수행하고 그것을 계속 일관되게 유지하는것은 쉬운 일은 아니니까...그리고 한편으로 꽤 많은 연차를 보냈음에도 부족하다고 생각되는 면에 대해서도 부끄럽기도 하다.

정말 좋은 말이고 공감되는 내용들만 정리했는데도 분량이 많은데, 이 책에 아직 남아있는 내용이 많으니 꼭 읽어보길 추천한다.

레버리지가 높은 활동에 집중하라

# 멘토가 해야 할 일
코드 리뷰해주기, 배워야 할 기술 개괄적으로 알려주기, 페어 프로그래밍 세션 진행하기, 기술의 트레이드오프 알려주기, 업무 우선순위를 잘 설정하는 방법 설명해주기, 필요한 팀원 소개하기, 다른 팀원들과 원만하게 협업하는 방법 지도하기 등 온갖 항목이 포함된다.
신입 개발자가 회사 시스템에 익숙해지도록 초반에 해야 할 업무와 프로젝트의 순서를 계획해주는 것도 멘토의 몫이다.

# 레버리지를 효과성의 측정 기준으로 삼아라
레버리지는 투입한 노력에 대한 투자 자본 수익률(ROI)이다. 이펙티브 엔지니어는 더 오랜 시간을 일해서 더 많은 일을 하려는 사람이 아니다. 업무를 효율적으로 완수하고, 제한된 시간에 더 많은 가치를 생산한다. 공식의 분모를 낮게 유지하면서 분자를 높이려고 노력하는 것이다. 즉, 레버리지는 여러분의 활동이 얼마나 효과적인지를 측정하는 기준이다.
레버리지가 매우 중요한 이유는 시간이 가장 제한적인 자원이기 때문이다. 시간은 다른 자원과 달리 저장, 확장, 대체가 불가능하다.

# 레버리지를 늘리는 세 가지 방법
1. 특정 활동을 완료하는데 드는 시간 줄이기
- 이 활동을 더 짧은 시간에 완료하려면 어떻게 해야 할까?
2. 특정 활동의 생산량 늘리기
- 이 활동으로 생산되는 가치를 증가시키려면 어떻게 해야 할까?
3. 레버리지가 높은 활동으로 전환하기
- 이 시간을 투자해 더 큰 가치를 생산할 수 있는 다른 활동이 있을까?

근무 환경의 핵심요소

# 성장 마인드셋을 갖춰라
성장 마인드셋을 가진 이들은 자신의 지능과 기술을 노력으로 기르고 성장시킬 수 있다고 믿는다.

# 자신의 학습률에 투자하라
매일 딱 1% 발전하고 이를 다음 성장의 기반으로 삼는다고 생각해보라. 이는 극적인 효과를 보이며 1년 후 우리를 365%(3.65배)가 아닌 37배 성장시킬 것이다.

# 학습에 도움이 되는 근무 환경을 찾아라
1. 빠른 성장
- 로켓에 탈 기회가 생긴다면 어떤 자리인지 묻지 말고 일단 타라
* 핵심 사업 지표(활성 사용자, 연간 고정 매출, 제품 판매량 등)의 주간 또는 월간 성장률은 얼마인가?
* 회사는 여러분이 맡은 프로젝트를 성장시키기 위해 충분히 지원해 주는가? 
  맡은 프로젝트가 회사로부터 지원받는 우선순위가 높은 프로젝트인가?
* 지난해 회사나 팀이 얼마나 적극적으로 인력을 충원했는가?
* 뛰어난 팀원이 얼마나 빨리 리더의 자리에 오르는가?
2. 교육
- 훌륭한 온보딩 프로그램이 있다는 건 조직이 신입 개발자 교육을 중요하게 생각한다는 증거다.
* 신입 개발자가 스스로 문제를 해결해야 하는가? 아니면 공식적인 신입 개발자 온보딩 절차가 준비되어 있는가?
* 공식적인 또는 비공식적인 멘토링이 존재하는가?
* 회사는 팀원이 계속 학습하고 성장하는 것을 보장하기 위해 어떤 조치를 하는가?
* 팀원들이 최근 새롭게 배운 것은 무엇인가?
3. 개방성
- 질문을 장려하는 호기심의 문화, 피드백과 정보를 사전에 공유하는 개방적인 문화를 추구하라. 실패한 프로젝트 반성하기, 서비스를 중단한 원인 알아내기, 제품별 투자 자본 수익률 검토하기는 모두 올바른 교훈을 체득하는 데 도움이 된다.
* 직원들은 다른 팀이 집중하고 있는 우선 과제가 무엇인지 알고 있는가?
* 팀끼리 만나서 과거에 수행한 제품을 수정하거나 기능을 출시하는 일이 수고할 만한 가치가 있었는지 재검토하는가? 
  서비스 중단 이후에는 사후 분석을 실시하는가?
* 회사 내에서 지식이 어떻게 기록되고 공유되는가?
* 팀이 배운 교훈의 예는 무엇인가?
4. 속도
- 최선을 다하되 장기적으로 지속 가능한 속도를 찾아야 한다.
* 빠른 속도가 회사의 가치나 엔지니어링 가치로 인정받는가?
* 개발 주기 속도를 높이기 위해 팀에서는 어떤 도구를 쓰는가?
* 아이디어 구상부터 출시 승인까지 시간이 얼마나 걸리는가?
* 새로운 제품과 기능을 개발하는 시간과 유지 보수하는 시간의 비율은 어느 정도인가?
5. 사람
- 경력 성장과 업무 만족도 면에서 볼 때 어떤 사람과 일하느냐가 무슨 일을 하느냐보다 더 중요할 수 있다.
* 면접관이 여러분보다 똑똑해 보이는가?
* 그들에게 배울 만한 기술이 있는가?
* 면접이 엄격하고 포괄적이었는가? 면접관과 잘 지낼 만한 사람들과 함께 일하고 싶은가?
* 1인 프로젝트가 많은가? 아니면 팀워크와 협력을 중요시하는가?
6. 자율성
- 우리의 학습 능력은 어떤 일을 어떻게 할지 선택할 수 있는 자유가 주어지고, 자유를 효과적으로 활용하는 데 필요한 지원이 뒷받침될 때 발휘된다. 업계에 입문한 초기에는 온보딩과 멘토링이 더 중요하고, 나중에는 자율성이 더 중요해진다.
* 직원들은 어떤 일을 어떻게 할지 자율적으로 선택할 수 있는가?
* 직원들이 팀이나 프로젝트를 얼마나 자주 바꾸는가?
* 한 직원이 1년간 작업할 수 있는 코드베이스의 규모는 어느 정도인가?
* 개발자들이 제품 설계 관련 논의에 참여하고 제품 방향에 영향을 미치는가?
# 근무 시간을 활용해서 새로운 기술을 발전시켜라
자신의 성장에 투자하려면 스스로 20%의 시간을 개척해야 한다. 20%의 시간이 생겼다면 무엇을 해야 할까? 이미 작업 중인 분야나 사용중인 도구에 대해 더 깊이 이해하면 좋다
* 회사에서 가장 뛰어난 개발자가 작성한 코어 추상화 코드를 연구하라
* 더 많은 코드를 작성하라
* 내부에서 제공되는 기술 교육 자료를 꼼꼼히 살펴보라
* 자신이 사용하는 프로그래밍 언어를 마스터하라
* 코드 리뷰는 가장 혹독한 리뷰어에게 부탁하라
* 발전하고 싶은 분야에 관한 수업을 수강하라
* 관심 있는 프로젝트 설계 논의에 참여하라
* 다양한 프로젝트에 참여하라
* 보고 배울 만한 것이 있는 시니어 개발자가 최소한 몇 명 이상 되는 팀에 머물러라
* 모르는 코드에 용감하게 뛰어들어라
# 항상 배워라
* 새로운 프로그래밍 언어와 프레임워크를 배워라
* 수요가 많은 기술에 투자하라
* 책을 읽어라
* 토론 그룹에 참여하라
* 강연, 컨퍼런스, 모임에 참여하라
* 강력한 인맥 네트워크를 구축하고 유지하라
* 엔지니어링 정보를 공유하는 블로그를 팔로우하라
* 블로그를 개설해 설명하고 가르쳐라
* 사이드 프로젝트를 하라
* 좋아하는 것을 추구하라

우선순위를 정기적으로 점검하라

# 할 일 목록의 우선순위
할 일 목록이 갖춰야 할 주요 속성은 두가지다. 자신의 업무를 정식으로 대표하는 목록이어야 하고, 쉽게 접근할 수 있어야 한다. 해야 할 일을 일관되게 목록에 적으면 기억해야 할 일은 단 한가지, 마스터 목록 확인하기 뿐이다.
레버리지를 정확히 계산할 수 있다면 레버리지에 따라 정렬하면 끝이다. 그러나 안타깝게도 각 업무에 필요한 시간과 업무가 생산할 가치는 예측하기 매우 어렵다. 결국 우선순위를 매긴 목록을 만들기 위해 추정에 쏟아부은 그 많은 시간이 낭비된 셈이다. 100번째 업무의 레버리지가 101번째 업무보다 높다는 것을 알아내는건 실제로 그다지 유용하지 않다.
현재 수행중인 일과 할 일 목록에 있는 다른 일을 쌍으로 비교하는 것이 훨씬 더 쉽고 효율적이다.
자신에게 레버리지가 더 높은 다른 할 일이 있을지 반복해서 물어라. 답이 '없다'라면 가던 경로를 계속 가면 된다. '있다'라면 지금 하고 있는 일을 다시 생각해야 하는 순간이다.
목표는 모든 우선 과제를 완벽한 순서로 정렬하는 것이 아니다. 그 대신 가지고 있는 정보를 바탕으로 최우선 과제를 레버리지가 가장 높은 업무로 끊임없이 전환하라.

# 직접적으로 가치를 생산하는 일에 집중하라
레버리지가 높은 활동을 우선 과제로 삼기 위한 첫 번째 휴리스틱은, 직접적으로 가치를 생산하는 일에 집중하는 것이다. 무엇이든 결과로 이어지는 일을 하라.
거절하는 법을 배워라. 요청 받은 모든 일을 의무라고 생각하지 마라. 우선순위를 높일 이유가 없다면 거기에 시간을 쓸 이유 또한 없다.
모든 것을 하려고 하지 마라. 중요한 것에 집중하라. 가치를 생산하는 것이 중요하다.

# 중요하지만 급하지 않은 일에 집중하라
직업적 목표 계획하기, 강력한 인맥 구축하기, 전문성 향상을 위해 책과 기사 읽기, 생산성과 효율성을 높이는 새로운 습과 기르기, 작업 흐름을 개선할 도구 만들기, 유용한 추상화에 투자하기, 인프라 꾸준히 확장하기, 새로운 프로그래밍 언어 배우기, 컨퍼런스에서 발표하기, 팀원들의 생산성 증진을 위해 멘토링하기 등이다.

# 생산자의 일정을 보호하라
개발자는 다른 직종에 비해 더 길고 연속적인 시간 블록(몰입)이 확보되어야 생산성이 높아진다. 가능하면 일정에 집중하는 시간 블록의 길이를 최대한 길게 유지하라. 참석하지 않아도 되는 회의, 우선순위가 낮은 약속처럼 자신의 일정을 짧게 쪼개 놓을 수 있는, 중요하지 않은 활동을 거절하는 법을 배워라. 자신의 일정, 그리고 자신과 함께하는 생산자의 일정을 보호하라.

# 동시에 진행할 작업의 양을 제한하라
끊임업는 맥락의 전환은 어느 하나의 활동에도 제대로 집중하지 못하게 방해하고 전체적인 성공 가능성을 감소시킨다. 소규모 그룹 사람들의 노력이 너무 많은 업무에 걸쳐 흩어지면 설계 논의나 코드 리뷰에 있어서 동일한 맥락이 공유되지 않는다.

# 우선순위를 정하는 자신만의 루틴을 만들어라
회고를 통해 우선순위를 재정비하는 습관을 길러라. 우선순위를 정하는 '최고'의 작업 흐름은 없다.
자신에게 잘 맞는 방법을 찾을 때까지 시행착오를 반복하여 자신만의 시스템을 만들어야 한다. 고유한 시스템을 갖추지 못했다면 생산성 관련 도서를 참고하거나 다른 개발자의 시스템을 활용하는 것이 출발점이 될 수 있다. 어떤 메커니즘을 써서 우선순위를 검토하는지보다 우선순위를 검토하는 습관을 들이는 것이 더 중요하다.

반복 속도에 투자하라

# 지속적 배포
지속적 배포라는 도구가 이토록 강력한 이유는 무엇일까? 근본적인 변화가 일어나기 때문이다. 지속적 배포 시스템을 갖추면 일괄적인 대규모 변경을 꾀하는 일반적인 회사와 달리 점진적으로 소규모로 변경을 수행하고 배치할 수 있다. 접근법이 달라지면 전통적인 배포 프로세스에 드는 상당한 간접 비용이 사라질 뿐 아니라 변경사항에 대한 추론이 더 쉬워지고 개발주기 반복 속도도 훨씬 빨라진다.
변경사항이 더 작은 작업 단위로 이루어지면 문제를 발견하고 디버깅하는 것도 쉬워진다.

# 빨리 배우려면 빨리 움직여라
개발 주기를 빠르게 반복할수록 무엇이 더 효과적인지 더 많이 배울 수 있다. 개발 주기의 반복 속도에 대한 투자가 왜 그토록 레버지리가 높은 결정인지 보여준다. 빠르게 움직이면 더 많은 것을 만들고 더 빨리 배울 수 있습니다. 하지만 대부분의 회사는 성장과 함께 너무 느려집니다. 너무 느리게 움직이느라 기회를 잃는 것보다 실수를 저지르는 것을 더 두려워하기 때문입니다. 실수가 하나도 없다는 건 움직이는 속도가 느리다는 뜻일 수 있습니다.

# 시간 절약 도구에 투자하라
만약 수동으로 두 번 이상으로 해야 하는 일이 생기면 세 번째에는 도구를 작성하라.
작게 시작하라. 도구로 시간을 절약할 수 있는 영역을 찾아서 도구를 만들고 그 가치를 증명하라. 조금 더 도전적인 길을 탐색해볼 자율권이 생길 것이고, 그 도구로 인해 앞으로 조금 더 효율적으로 일하게 될 것이다.

# 디버깅과 검증 과정을 단축하라
버그를 수정하거나 기능을 개발하는 중인데 문득 똑같은 동작을 반복하고 있다는 것을 깨달았다면 잠시 멈춰라. 그리고 테스트 과정을 더 짧게 만들 수 없을지 잠시 생각할 시간을 가져라. 이렇게 하면 장기적으로 시간이 절약될 것이다.

# 프로그래밍 환경을 마스터하라
좋아하는 텍스트 에디터와 IDE를 능숙하게 다뤄라.
생산적이고 수준 높은 프로그래밍 언어를 적어도 하나는 배워라.
유닉스나 윈도우의 쉘 명령에 익숙해져라.
마우스보다 키보드를 우선 사용하라.
수동 작업 흐름을 자동화하라.
변경사항과 관련 있는 단위 테스트를 빠르게 쉽게 실행할 수 있게 하라.

# 엔지니어링 외적인 병목을 무시하지 마라
이펙티브 엔지니어는 가장 큰 병목이 코드 작성과 관련이 없거나 안전지대를 벗어난 영역에 있더라도 이를 찾아내서 해결한다. 병목이 흔히 발생하는 지점은 타인에게 의존하는 부분이다. 소통은 사람과 관련 있는 병목을 개선할 때 대단히 중요하다. 프로젝트는 소통이 지나칠 때가 아니라 부족할 때 실패한다.
또 다른 병목 유형은 리뷰 프로세스로, QA 팀의 검증, 성능 팀의 확장성이나 안전성 리뷰, 보안 팀의 감사 등 어떤 프로젝트에나 수반되는 것들이다. 출시 체크리스트 요구사항을 충실히 지키고 리뷰 일정을 마지막까지 미루지 마라. 다시 말하지만 리뷰 프로세스가 병목이 되지 않게 막는 열쇠는 소통이다.
자신의 개발 주기에서 가장 중대한 병목이 어디인지 알아내라. 엔지니어링 도구인가, 다른 팀에 대한 의존성인가, 의사 결정권자의 승인인가? 알아내서 그 부분을 최적화하라.

개선하려는 사항을 측정하라

# 지표를 활용해서 발전을 주도하라
좋은 지표는 여러 면에서 도움이 된다.
첫째, 올바른 대상에 집중하게 해준다. 변경사항과 이를 위해 쏟아부은 모든 노력이 목표 달성에 실제로 도움이 되는지 확인해준다. 목표와 관련한 지표를 정의하고, 변경사항이 미친 영향을 측정하는 것이다.
둘째, 좋은 지표를 시간 경과에 따라 시각화하면 향후 발생할 회귀 버그를 방지하는 데 도움이 된다.
셋째, 좋은 지표는 발전을 주도한다.
넷째, 좋은 지표는 시간이 흐르는 동안 효율성을 측정하고, 현재 하는 활동과 그 대신 할 수 있었던 활동을 비교할 수 있게 해준다.

# 원하는 행동을 장려하려면 올바른 지표를 골라라
측정할 대상을 선택하는 건 측정 자체만큼이나 중요하다. 어떤 지표를 선택하느냐가 어떤 작업을 할지에 큰 영향을 미친다는 것을 명심하자. 올바른 지표는 팀의 노력을 공통의 목표에 맞추는 북극성 역할을 한다.
* 주당 근무 시간 vs 주당 생산성
주당 근무 시간을 늘려서 생산량을 늘리려는 시도는 지속가능하지 않다. 
관심 영역에서의 생산성을 제품 품질, 사이트 속도, 사용자 성장 같은 요소로 측정하고, 
주당 생산성에 맞춰서 지표를 정하는 것이 훨씬 더 합리적이다.

* 평균 응답 시간 vs 95 또는 99 백분위수 응답 시간
평균을 낮추려면 모든 요청의 응답 시간을 1/1000초 단축하도록 일반적인 인프라 개선에 더 집중해야 한다. 
전체 연산 시간을 줄여서 서버 비용을 낮추는 것이 목표라면 평균이 적절한 지표다. 
그러나 95 또는 99 백분위수 응답을 줄이려면 가장 나쁜 동작을 시스템에서 찾아내야 한다. 
즉, 이 경우에는 가장 느린 응답에 집중해야 한다. 
가장 느린 응답은 파워 유저의 경험을 반영하는 경향이 있기 때문이다.

* 등록한 사용자 수 vs 등록한 사용자의 수의 주간 성장률
주간 성장률(예를 들면 등록한 전체 사용자 대비 일주일 간 새로 등록한 사용자 비율)로 성장을 측정하면 
성장 속도가 둔화되고 있는지 여부를 확인할 수 있다.

* 주간 활성 사용자 vs 가입 기간별 주간 활성 사용자
가입 후 n주차에도 여전히 활성화된 사용자를 주 단위로 측정하는 것이다. 
이 지표는 제품의 변화가 기존 사용자 집단에 비해 
새로운 사용자 집단의 참여에 어떤 영향을 미쳤는지, 보다 실행 가능한 통찰을 제공한다.
제품과 목표가 복잡할수록 무엇을 측정하고 무엇을 측정하지 말아야 할지 선택지가 늘어나고, 어디에 노력을 기울일지 어떤 결과를 생산할지 고민할 범위가 넓어진다. 지표는 1) 가장 큰 효과를 내고, 2) 실행하기 좋으며, 3) 즉각 반응하되 견고한 것으로 정해야 한다.
허무 지표가 증가하면 제품이 발전했다는 뜻일 수는 있으나 그렇다고 해서 팀이 꼭 일을 잘했다는 뜻은 아니다.

# 현재 상황을 파악하려면 모든 것을 계측하라
목표를 세울 때는 어떤 핵심 지표를 측정하고(또는 측정하지 않고) 최적화할지 신중하게 고르는 것이 중요하다. 그러나 일상적인 업무에 관해서라면 대상을 가리지 않고 최대한 많이 측정하고 계측하는 것이 좋다. 이 두가지 원칙이 서로 모순되는 것처럼 보일지 모르나 실제로는 서로를 보완하는 역할을 한다. 첫 번째 원칙은 높은 수준에서 전체 활동을 설명하는 데 필요하고, 두 번째 원칙은 자신이 만든 시스템의 현재 상황을 통찰하는 데 필요하다.
핵심 지표를 효과적으로 최적화하려면 이를 뒷받침하는 다른 많은 지표를 체계적으로 측정해야 한다.

# 데이터 무결성을 의심하라
사람들은 데이터를 해석하고 싶은대로 해석한다.
지표에 관한 한 자신의 직감이 수치와 일치하는지 비교하라. 다른 방향에서도 똑같은 데이터에 이를 수 있는지 시도해보고 그때도 그 지표가 여전히 타당한지 확인하라. 지표에서 다른 속성이 엿보인다면 해당 속성을 측정해서 결론에 일관성이 있는지 확인하라.
데이터를 신뢰할 수 있게 만들라. 데이터가 없는 것보다 데이터가 올바르다는 착각이 더 나쁘다.

아이디어는 일찌 그리고 자주 검증하라

자신의 작업을 적는 노력으로 검증할 방법을 찾아라
발전을 방해하는 위험한 문제를 더 일찍 제대로 파악할수록 더 빨리 문제를 해결해서 성공 가능성을 높이거나 조금 더 유망한 경로로 방향을 전환할 수 있다. 최소 기능 제품(MVP, Minimum Viable Product)을 만들 때는 최소의 노력으로 제품의 성공 가능성을 최대로 높일 수 있게 사용자에 관한 가정을 가능한 한 많이 검증할 수 있는, 레버리지가 높은 활동에 집중해야 한다. 적은 노력을 투자해서 프로젝트 가정과 목표를 검증할 데이터를 모아라.

A/B 테스트로 제품 변경사항을 꾸준히 검증하라
A/B 테스트라는 실험은 이러한 효과를 구분하고 효과를 낸 요인이 무엇인지 검증하는 강력한 도구다. A/B 테스트는 출시할 변경사항을 정할 때만 도움이 되는 것이 아니다. 특정 변경사항이 지표를 개선할 거라고 절대적으로 확신하는 상황에서도 유용하다. 그 변형이 실제 얼마나 더 나은지 알려주기 때문이다. 얼마나 개선될지 정량화하면 같은 분야에 계속 투자하는 것이 합리적인지 확인할 수 있다.
A/B 테스트는 이론을 검증하고 개발 주기를 반복하면서 효과를 내는 변경사항을 찾아가는 반복적인 제품 개발 방식을 장려한다.
A/B 테스트 대상을 정할 때는 시간이 가장 제한적인 자원이라는 점을 기억하라. 레버리지가 높고 실질적으로 큰 의미를 지니며, 자기 회사에 실제로 중요한 차이를 내는지 파악하라. A/B 테스트는 제대로 수행하면 제품 아이디어를 검증하고, 있는 그대로는 이해할 수 없는 사용자 행동 데이터라는 블랙박스를 이해하고 실행할 수 있는 지식으로 변환하는 데 도움이 된다. 제품 변경사항을 반복해서 검증하게 해줄 뿐 아니라 시간과 노력을 효과적으로 소비하며 목표 달성을 향해 올바른 경로로 가고 있는지도 확인시켜 준다.

1인 팀을 주의하라
* 피드백을 개방적으로 수용하라.
피드백과 비판을 개인적인 공격이 아닌 발전의 기회로 보라.

* 코드를 일찍, 자주 커밋하라.

* 코드 리뷰를 철저한 비평가에게 부탁하라.
무언가 제대로 작동하지 않는다는 혹독한 비평은 사용자보다 동료에게 미리 받는 것이 낫다.

* 팀원들에게 아이디어에 대한 반응을 요청하라

* 새로운 시스템의 인터페이스나 API부터 설계하라.

* 코드에 에너지를 쏟기 전에 설계 문서를 공유하라.

* 최대한 팀원들과 맥락을 공유할 수 있게 프로젝트를 구조화하라.

* 논란의 여지가 있는 기능이라면 너무 많은 시간을 투자하기 전에 승인을 요청하라.
해당 도메인을 이해하고 있는 사람들에게 승인을 얻지 못한다면 잘못된 경로로 가고 있다는 뜻일지 모른다.
의사 결정을 위한 피드백 과정을 구축하라
개발자의 직급이 올라갈수록(특히 관리직을 맡을수록) 의사 결정이 점점 더 어려워지고 모호해진다. 팀의 업무를 어떻게 조직해야 할까? 팀의 기술 부채를 줄이기 위해 기능 개발을 잠시 멈출(또는 멈추지 않음) 여력이 있을까? 업무 평가와 피드백은 어떻게 이루어져야 할까? 익명으로, 직접적으로, 아니면 공개적으로? 직원 채용이나 유지를 개선하려면 보상구조를 어떻게 조절해야 할까?
업무의 모든 측면에 피드백 과정을 만들어야 한다. 피드백 과정이 없으면 그냥... 추측하는 것이다.

프로젝트 추정 기술을 향상시켜라

프로젝트 추정 기술
프로젝트 추정은 이펙티브 엔지니어가 익혀야 할 어려운 기술 중 하나다. 그러나 숙달하는 것이 중요하다. 기업이 제품에 대해 장기적인 계획을 세우려면 정확한 추정이 필요하다. 언제 자원을 확보하여 다음 기능 작업에 돌입할 수 있는지 또는 요청받은 기능의 완료 계획을 고객에게 언제 알려줄 수 있는지 알아야 한다. 기한에 맞춰 배포해야 한다는 압박이 없을 때도 프로젝트에 얼마의 시간이 들어가느냐는 어떤 작업을 할지 결정하는 데 영향을 미친다.

정확한 추정치를 활용하여 프로젝트 계획을 추진하라
목표에 맞춰 추정을 수정하다가 프로젝트 일정이 지연되기도 한다.
추정을 반복해서 수정하면 프로젝트 결과물이 나아질 수 있다.
* 프로젝트를 더 작은 작업으로 분해하라.

* 자신 또는 누군가가 원하는 작업 시간 말고, 작업에 실제로 드는 시간을 기준으로 추정하라.

* 추정을 최상의 시나리오가 아닌 확률 분포로 생각하라.
제품 관리자를 비롯한 다른 이해관계자에게 어떤 기능을 6주 이내에 완성하겠다고 말하기보다 
"이 기능을 지금부터 4주 이내에 완성할 가능성이 50%이고, 8주 이내에 완성할 가능성은 90%입니다" 라고 말하는 것이 좋다.

* 실제 업무 담당자가 추정하게 하라.

* 기준점 편향에 주의하라
낮은 추정치가 초기에 기준점으로 자리 잡으면 나중에 더 정확한 추정치를 설정하기 어려우므로 
관련 작업의 윤곽을 짜기 전에는 수치를 이야기하지 마라.

* 하나의 업무를 여러 방법을 사용해 추정하라.

* 이상적인 인월을 조심하라
사람과 시간을 호환할 수 있다는 근거 없는 믿음이 생긴다. 
한 여성이 아홉 달 안에 아이를 낳을 수 있다고 해서 9명의 여성이 한 달 안에 아이를 낳을 수 있는 것은 아니다. 
새로운 팀원이 프로젝트에 적응해서 생산성을 내기까지는 시간이 걸리므로 인원을 추가한다고 해서
프로젝트 타임라인이 단축된다고 생각하지 마라.

* 기존 데이터로 추정치를 검증하라

* 범위가 커질 수 있는 작업을 타임 박스(time box)로 제한하라
조사에 3일 정도 걸린다고 추정하지 말고, 3일 이내에 찾은 데이터를 기반으로 최선의 결정을 내리려고 노력하라.

* 다른 이들이 추정에 이의를 제기하도록 허용하라
미지의 변수를 고려하라
추정한 작업 시간을 달력상의 시간과 분리하는 것이다.
'작업을 완료하기까지 1개월이 걸릴 것이다'라는 말을 '한 달 이내에 완료될 것이다'라는 뜻으로 해석하면 안된다.
이상적인 1일 치 엔지니어링 업무를 일상적인 방해 요소를 감안해서 근무일 2일로 계산한다.

구체적인 프로젝트 목표와 측정 가능한 마일스톤을 정의하라
명확한 문제를 바탕으로 명확한 목표를 표현하는 것.
첫번째 혜택, 잘 정의해둔 목표는 작업 목록에서 꼭 해야 할 일과 하면 좋은 일을 구분하는 중요한 필터.
두번째 혜택, 핵심 이해 관계자들 사이에 명확성과 공통의 이해가 형성된다는 것.
구체적인 목표를 정의하는 것보다 더 효과적인 것은 목표 달성을 위해 측정할 수 있는 마일스톤을 세우는 것이다.

위험은 초반에 감소시켜라
프로젝트를 효과적으로 실행한다는 것은 기한을 늦출 만한 위험을 최소화하고 예상치 못한 문제를 최대한 초반에 알아낸다는 뜻이다.
문제가 예상보다 어렵다는 것이 뒤늦게 밝혀지는 것보다는 차라리 일찌감치 문제를 찾아내서 목표 기한을 조정하는 것이 낫다.
통합 위험을 줄이는 방법) 초기에 종단 간 테스트를 위한 틀을 만들고 시스템을 테스트. 불완전한 기능과 모듈을 제거하고 최대한 빨리 종단 간 시스템을 구성해서 테스트하라.

재작성 프로젝트는 매우 조심스럽게 접근하라
무언가를 바닥부터 재작성하려는 욕구는 소프트웨어 개발자의 아주 일반적인 특징이다. "두 번째 시스템은 인간이 설계한 가장 위험한 시스템이다."
시스템을 점진적으로 재작성하는 것은 레버리지가 높은 활동이다. 점진적인 방법을 활용하면 전체 작업량이 늘어날 수 있으나, 위험이 많이 감소하는 것을 고려하면 이런 단점을 감수할 만한 가치가 있다.

마라톤 중간에 전력 질주하지 마라
초과 근무한다고 해서 출시일이 지켜질지 보장할 수 없는 이유
* 근무 시간이 늘어나면 시간당 생산성이 떨어진다.
* 생각보다 일정이 더 지연됐을 수 있다.
* 추가 근무 시간으로 인해 팀원들이 번아웃을 경험할 수 있다.
* 추가 근무는 팀 내 역학 관계를 망가뜨릴 수 있다.
* 마감 기한이 다가올수록 의사소통 간접 비용이 늘어난다.
  * 기한을 향한 전력 질주 때문에 기술 부채가 유발된다.
추가 근무해서 실제로 출시일을 지킬 현식적인 계획이 없는 한, 장기적으로 볼 때 최고의 전략은 목표 기한 내에 얼마나 완성할 수 있는지를 가늠해서 출시할 내용을 재정의하거나 더 현실적인 날짜로 기한을 미루는 것이다.
  * 지금까지 타임라인이 지연된 주요 원인을 모두가 이해하고 공유하라
  * 프로젝트 계획과 타임라인을 현실적으로 수정하라.
  * 프로젝트가 수정한 타임라인보다 더 지연된다면 전력 질주를 포기하라

품질과 실용주의 사이에서 균형을 유지하라

소프트웨어 품질
소프트웨어 품질은 결국 균형의 문제로 귀결되며, 어떻게 해야 한다고 규정된 하나의 보편적인 원칙은 존재하지 않는다. "옳고 그름의 관점에서 생각하는 것은 세상을 바라보기에 매우 정확하거나 유용한 프레임워크가 아니다. 나는 옳고 그름 대신에 효과가 있느냐 없느냐의 관점에서 대상을 보는 것을 선호한다. 그렇게 할 때 더욱 명확하고 효과적으로 의사 결정할 수 있다."

지속 가능한 코드 리뷰 프로세스를 만들어라
* 설계 결함이나 버그를 초기에 포착한다.
* 코드 변경사항에 대한 책임감이 강해진다.
* 좋은 코드 작성법을 배우는 모델로써 도움이 된다.
* 코드베이스에 관한 실용적 지식을 공유한다.
* 장기적인 작업 속도가 향상된다.

추상화를 통해 복잡성을 관리하라
올바른 추상화를 선택하면 프로그래밍이 설계부터 자연스럽게 흘러간다. 모듈 인터페이스는 작고 간단할 것이고 광범위한 개편이 없어도 새로운 기능이 잘 안착할 것이다. 잘못된 추상화를 선택하면 프로그래밍하는 동안 예상 밖의 문제가 줄줄이 일어난다. 인터페이스는 예상치 못한 인터랙션을 억지로 수용하기 위해 찌그러지거나 투박해질것이고 아주 간단한 변경조차 하기 어려워진다.
* 원래 문제의 복잡성을 이해하기 쉬운 원시 형태로 분해해준다.
* 애플리케이션 유지 보수에 드는 수고가 줄고 개선사항을 적용하기 쉬워진다.
* 어려운 문제를 한 번 해결하면 그 해결책을 여러 번 사용할 수 있다.
강력한 엔지니어링 팀은 추상화에 투자를 많이 한다. 특정 문제에 대한 추상화를 만들면 트레이드오프가 따른다. 일반적인 해결책을 만들려면 특정 문제에만 맞는 해결책을 만드는 것보다 더 많은 시간이 든다. 손해를 보지 않으려면 추상화를 제작하는 데 든 시간보다 추상화로 인해 절약되는 시간이 더 많아야 한다. 팀원들이 크게 의존하는 소프트웨어(로그 라이브러리나 사용자 인증 라이브러리 등)를 만들 때 그렇게 될 확률이 높으므로 코어 추상화를 훌륭하게 만드는 데 에너지를 집중하라.

좋은 추상화의 속성
* 배우기 쉽다.
* 문서가 없어도 사용하기 쉽다.
* 잘못 사용하기 어렵다.
* 요구 조건을 충족시킬 정도로 충분히 강력하다.
* 확장하기 쉽다.
* 대상 사용자에게 적합하다.

테스트를 자동화하라
엄격한 자동 테스트가 없다면 수동 테스트를 철저히 수행하는 데 드는 시간이 엄두도 못 낼 정도로 길어질 수 있다. 통합 테스트는 작성하고 유지 보수하기 어렵지만, 몇 개만 작성한다면 레버리지가 높은 투자다.
보통 첫 번째 테스트를 작성하는 게 가장 어렵다. 테스트를 작성하는 습관을 들일 효과적인 방법은 레버리지가 높은 테스트, 즉 작성하는 데 든 시간에 비해 많은 시간을 절약해주는 테스트에 집중하는 것이다. 가장 가치 있는 테스트부터 시작하여 한 걸음씩 전진하라.

기술 부채를 상환하라
분기를 마칠 때마다 관련 부채를 상환하는 'Polish Week' 일정과 내부 도구 관련 부채를 상환하는 'Grease Week' 일정을 잡아둔다.
안타깝게도 기술부채는 정량화하기 어려울 때가 종종 있다. 재작성에 드는 시간이 얼마이고 이를 통해 절약되는 시간이 얼마인지에 대한 확신이 부족하다면 작게 시작해서 점진적으로 풀어나가는 것이 좋다. 그러면 작업이 너무 복잡해질 위험이 줄어들고, 기술 부채는 상환할 가치가 있다는 것을 자신과 다른 사람에게 증명할 기회가 된다.

운영 부담을 최소화하라

운영 부담
매력적이거나 도발적인 신기술 대신 가능한 확고히 검증된 기술을 선택하라. 새롭게 추가하는 기술은 시간이 지나면서 조금씩 문제를 발생시키는 게 당연하다. 어느 순간 정신을 차리고 보면 팀 전체가 운영에 매달리고 있을 것이다.

단순하게 운영하라
엔지니어링 팀이 간단한 일부터 하는 데 집중하지 않으면 유지 보수 비용이 많이 드는 활동에 에너지를 쏟느라 시간이 지남에 따라 효율이 점점 떨어지거나, 운영 부담이 너무 커져서 아키텍처를 단순화할 수밖에 없는 상황에 처한다.
* 다양한 시스템에 관한 엔지니어링 전문 지식을 습득해야 한다.
* 복잡성이 증가하면 잠재적 단일 장애점(single point of failure)이 늘어난다.
* 신입 개발자가 새 시스템을 익히고 이해하기 어려워진다.
* 추상화, 라이브러리, 도구를 개선하는 데 드는 노력이 여러 시스템으로 분산되어 희석된다.

빨리 실패하는 시스템을 만들어라
시스템이 느리게 실패하면 코드 오류의 원인이 불분명해져서 어떤 문제가 일어난 것인지 알아내기 어려워진다. 버그와 소프트웨어 구성 오류는 불가피하게 발생하므로 문제를 재현하고 오류의 원인을 정확히 알아내는 데 시간을 투자해야 한다. 문제나 오류가 원인에 가까울수록 문제를 더 빨리 재현하고 해결할 수 있다. 빨리 실패하면 더 빠르고 효과적으로 문제를 드러내고 해결할 수 있다.
빠른 실패라고 해서 반드시 사용자가 사용 중인 프로그램을 종료시켜야 하는 건 아니다. 빨리 실패하기 기법을 활용하여 최대한 빨리 문제를 드러내고 오류의 실제 원인에 가깝게 접근하고, 사용자 측에서는 우아하게 실패하는 동안 개발자에게 오류를 보고하는 방안으로 보완이 가능하다.

기계적인 작업을 꾸준히 자동화하라
자동화해야 할지 결정할 때는 이렇게 자문하라.
이 작업을 수동으로 하는 것, 이 작업을 자동화하기 위한 비용을 선불로 내는 것, 둘 중 어느 쪽을 택했을 때 전체적으로 시간이 더 절약될까?
자동화가 필요한 만큼 이루어지지 않는 몇 가지 이유
* 지금 당장 시간이 없다.
* 공유지의 비극이 일어난다. (자동화를 위해 나설 동기나 의지가 감소)
* 자동화 도구에 익숙하지 않다.
* 향후 작업 빈도를 과소평가한다.
* 장기적으로 볼 때 시간이 얼마나 절약되는지 체감하지 못한다.

일괄 처리를 멱등성 있게 만들어라
일괄 처리를 '유지 보수하기 쉽고 실패 회복력이 더 뛰어나게' 만드는 한가지 기법은 이를 멱등성(idempotent) 있게 만드는 것이다.

팀의 성장에 투자하라

팀워크
강력한 팀과 긍정적인 문화를 구축하는 것이 상당히 레버리지가 높은 활동임을 인식하는 것이 중요하다.
업계에 입문한 초기부터 동료의 성공을 돕는 방법을 고민한다면 후일 스스로 성공을 거머쥘 올바른 습관을 기르는 셈이다.
직업적 성공은 회사와 팀의 성공에 크게 좌우되며 개인적인 기여만으로는 회사나 팀이 성공할 수 없다. 주변에 있는 이들이 우호적인 태도로 여러분과 뜻을 함께할 때 훨씬 더 많은 것을 성취할 수 있는데 그런 환경을 조성하는 열쇠는 그들의 성공에 투자하는 것이다.

여러 직위가 지니는 의미
그 사람의 존재로 인해 팀이 전체적으로 나아진다면 책임 개발자다.
그 사람의 존재로 인해 회사가 전체적으로 나아진다면 수석 개발자다.
그 사람의 존재로 인해 업계가 더 발전한다면 최고 개발자다

채용을 모두의 책임으로 만들어라
좋은 면접 절차는 두 가지 목표를 달성한다.
1. 회사에 잘 적응할 것 같은 유형의 지원자를 선별한다.
2. 지워낮가 회사, 회사에서 맡을 임무, 회사의 문화에 매력을 느끼게 한다.
면접관의 목표는 신호 대 잡음 비율이 높아지도록 질문을 최적화하는 것이다. 소비한 시간에 비해 관련 없거나 쓸모 없는 데이터(잡음)가 거의 없이 지원자에 관한 유용한 정보(신호)를 많이 밝혀내는 질문을 던진다는 뜻이다. 가장 많은 신호를 생성하는 질문의 유형은 해당 팀의 성공과 가장 관련있는 자질이 무엇이냐에 따라 달라진다.
모든 기술이 그렇듯이 면접과 채용을 더 효과적으로 진행할 수 있는 방법도 반복과 연습뿐이다.

온보딩 절차를 훌륭하게 설계하라
팀의 성공을 향한 투자가 자신의 성공 가능성도 높여준다. 신입 개발자의 성장을 효과적으로 도우면 궁극적으로 레버리지가 더 높은 활동을 선택할 수 있는 유연성이 생긴다.
온보딩 절차를 통해 달성할 네가지 목표
1. 최대한 빠르게 신입 개발자 적응시키기
2. 팀의 문화와 가치 전달하기
3. 신입 개발자가 성공에 필요한 폭넓은 기초 지식 접하게 하기
4. 신입 개발자를 사회적으로 통합시키기

코드 소유권을 공유하라
소유권을 더 많이 공유하려면 자신이 작성한 코드나 도구를 다른 팀원들이 탐색하고 이해하고 수정할 때 발생하는 마찰을 줄여야 한다.
* 1인 팀을 피하라
* 서로의 코드와 소프트웨어 설계를 리뷰하라.
* 팀 내에서 여러 유형의 업무와 책임을 돌아가며 맡아보라.
* 코드의 가독성과 품질을 높게 유지하라.
* 소프트웨어 의사 결정과 아키텍처에 관한 기술 강연을 열어라.
* 자신이 만든 소프트웨어를 문서화하라. 높은 수준의 설계 문서도 좋고, 코드 수준의 주석도 좋다.
* 업무를 완수하는 데 필요한 복잡한 작업 흐름, 명확하지 않은 우회로를 문서화하라.
* 다른 팀원의 교육과 멘터링에 시간을 투자하라.

사후 분석으로 집단 지성을 구축하라
팀이 얻은 교훈을 기록하려면 솔직한 대화가 바탕이 되어야 하는데, 프로젝트에 관해 솔직하게 대화하는 것이 불편할 수 있다. 몇 개월간의 노력이 실패로 돌아갔을지 모른다는 것을 인정하고 실패를 성장의 기회로 보아야 한다. 책임 소재를 따지는 데 집중하지 말고 제품과 팀으르 발전시키겠다는 공동의 목표에 대한 공감대가 형성되어야 한다. 무엇이 잘못됐고 무엇을 더 잘할 수 있었는지 집단 지성을 구축하겠다는 목표를 가지고 열린 자세로 피드백을 수용해야 한다. 한 시간 동안 나눈 힘겨운 대화가 다음 한 달간 진행할 팀 프로젝트의 성공 가능성을 높인다면 시간과 감정을 투자할 가치가 있는 레버리지가 높은 활동이라고 볼 수 있다.

훌륭한 엔지니어링 문화를 구축하라
최고의 개발자는 탄탄한 엔지니어링 문화를 갖춘 조직을 찾으므로 뛰어난 인재를 채용하는 데 도움이 되는 유용한 도구이기도 하다. 뛰어난 개발자가 입사하면 문화가 더욱 강화되는 선순환 구조가 만들어진다.
최고의 개발자가 장래의 회사에 기대하는 점
* 개발 주기 반복 속도를 최적화한다.
* 끊임없이 자동화를 추구한다.
* 올바른 소프트웨어 추상화를 구축한다.
* 코드 리뷰를 활용해서 높은 코드 품질을 유지하는 데 집중한다.
* 서로 존중하는 근무 환경을 유지한다.
* 코드 소유권을 공유한다.
* 자동 테스트에 투자한다.
* 20%의 시간이나 해커톤을 통해 실험할 시간을 준다.
* 학습하고 꾸준히 발전하는 문화를 조성한다.
* 최고의 개발자를 고용한다.

엔지니어를 위한 문장의 기술

뭐든창하 — Fri, 3 Jan 2025 23:27:50 +0900

이 책의 주요 요점들을 기억하기 쉽게 정리해 놓긴 했지만, 이 책의 가장 큰 장점은 각 주제별로 안좋은 글과 개선된 글의 사례를 하나씩 보여주면서 쉽게 이해할 수 있도록 도와준다는 점이다. 사실 이 책은 사례가 가장 유용하게 쓰일것 같은데, 사례를 옮겨 적기엔 너무 많은 것을 공개하는것 같기에 요약 요점만 정리해본다.

좋은 문장이란 말이 안 되는 문장을 쓰지 않는 것

누가봐도 이해가 되지 않는 문장을 쓰지 않는 것 = 좋은 문장을 쓸 수 있다
좋은 문장을 쓰는 요령은 '말이 안 되는 문장을 쓰지 않는' 것입니다. '좋은 문장'이라고 느끼는 것은 어디까지나 개인마다 해석하는 방법이나 사고 방식에 의존하는 부분이 많아 매우 주관적입니다. 그러나 적어도 읽을 때 '무슨 말이람?'이라고 생각하지 않으면 비즈니스적으로 일단 충분한 문장입니다.

피해야할 문장
사실 많은 사람들이 자신의 관점에서 글을 쓰고 있으며, 상대방의 관점에서 글을 쓰는 사람은 매우 적습니다.
요점은 상대방의 관점에서 생각하지 않는 것이 문제입니다. 좋은 문장을 쓰려면, 작성자의 관점이 아니라 독자의 관점에서 작성해야 합니다. 즉, 상대의 관심 사항에 초점을 맞춰서 써야 한다는 의미입니다.

문장을 읽을 대상과 목적을 파악하는 것

설득력이 있는 문장의 요소
이유, 일관성, 근거
문장을 작성하는 사람은 반론을 수 차례 제기할 만한 사람들이 '더 이상 반론을 제기하지 못하도록' 문장을 작성해야 합니다. 그것이 바로 설득력 있는 제안서를 작성할 수 있는 포인트입니다.

상위관리자에게 보고시 (경영층이 선호하는 요소)
* 바쁘기 때문에 읽지마자 포인트를 이해할 수 있어야 한다.
* 완결성이 있고 간단할 것. 문자 수가 적을 것. 한마디로 말할 수 있을 것. 결론부터 눈에 들어올 것.
* 기획이 필요한 이유가 명확하고, 기획이 성공할 논리적인 근거가 충분해야 한다.

상대에게 의도를 능숙하게 전달하려면
* 자신의 관점이 아니라 반드시 상대방의 입장에서 설명해야 한다.
* 상대의 관심 사항에 포커스를 맞춘다. 관심 사항이 아닌 내용을 설명할 때는 알기 쉽게 설명할 수 있도록 많은 노력과 준비를 해야 한다.

#기술1 : 논점을 명확하게 쓰기

좋은 문장은 '무엇을 말하는지, 왜 그런 것인지, 구체적으로 어떤 것인지', '어떻게 하면 되는 것인지' 논점이 명확합니다. 문장 구조에서 가장 중요한 것은 '하고 싶은 말을 잘 걸러내는 것'입니다.
1. 전달하고 싶은 내용을 요약한다.
2. 전달하고 싶은 논점은 맨 앞에 쓴다.
3. 논점과 보충 정보를 분리한다.
4. 관계없는 내용은 쓰지 않는다.

#기술2 : 납득할 수 있게 쓰기

좋은 문장은 '주장'이 명확하고 주장에 납득될 만한 이유나 근거가 명확합니다. 이유가 명확하고 사실에 근거해야 강력한 신뢰감을 줄 수 있습니다.
1. 맨 앞에 주장과 주장한 이유를 쓴다.
2. 이유는 납득할 수 있도록 쓴다.
3. 이유는 사실에 근거하고 수치 등을 사용하여 객관적으로 쓴다.
4. 사실과 의견을 분리한다.
5. 수동적인 표현과 복잡한 표현을 사용하지 않는다.

#기술3 : 한 눈에 파악되게 쓰기

좋은 문장은 알기 쉽게 문장이 구조화되어 있습니다. 문장의 구조화란 같은 주제의 내용들을 한데 묶고, 문장 간의 상하관계를 정의하여 재배치하는 것을 말합니다.
1. 문장의 성격과 그룹을 도출한다.
2. 결론과 그 이유를 맨 앞에 쓴다.
3. 개요와 상세는 분리한다.
4. 소, 중, 대 항목의 계층을 설정한다.
5. 너무 상세한 내용은 본문에 쓰지 않고 별첨에 쓴다.

#기술4 : 이해하기 쉽게 쓰기

좋은 문장은 '무슨 말을 하는지' 상대가 확실하게 이해할 수 있어야 합니다. 이러한 문장에 필요한 스킬은 최대한 알기 쉽게 표현하는 것입니다.
1. 한마디로 요약한다.
2. 어려운 단어를 바꾼다.
3. 용어를 정의한다.
4. 각주나 괄호를 사용한다.
5. 구체적인 예시를 열거한다.

#기술5 : 생략 없이 정확하게 쓰기

알기 쉬운 문장을 쓸 때는 함부로 생략하지 않아야 합니다. 생략이란 써야 할 내용을 '쓰지 않는' 것입니다.
1. 생략하지 않는다.
2. 주어나 주체를 명확히 쓴다.
3. 무의미한 정보나 불명확한 정보를 기재하지 않는다.
4. 애매한 내용을 쓰지 않는다.
5. 미결, 기결, 액션 플랜을 명확히 한다.

#기술6 : 단문으로 쓰기

좋은 문장은 짧은 시간에 직관적으로 내용을 이해할 수 있어야 합니다. 이를 위해서는 쓸데없는 수식어나 내포된 문장들을 과감히 제거하고 의역이나 기호, 도표 등을 사용합니다. 끝없이 긴 문장은 이해하기 어려울 뿐만 아니라 논점까지 흐리게 합니다.
1. 조사, 형용사, 수식어 등을 배제한다.
2. 기호화한다.
3. 각주로 처리하고 본문으로 제외한다.
4. 수동 표현을 능동 표현으로 바꾼다.
5. 그림이나 표로 치환한다.

#기술7 : 감정에 호소해서 쓰기

좋은 문장은 쓰려면 읽는 사람의 감정에 호소하는 등 심리적인 접근도 필요합니다. 특히 '설득', '의뢰', '거절', '어필'과 같은 문장에서는 논리성과 이해도는 물론 감정을 배려한 내용도 필요합니다. 사람은 감정을 가지고 있기 때문에 한 줄 문장이 상대의 마음을 움직여 목적을 달성할 때도 많습니다.
1. 감정을 자극하는 칭찬을 한다.
2. 의욕을 보인다.
3. 비란, 반론을 먼저 스스로 언급한다.
4. 선택 효과를 사용한다.
5. 대비 효과를 사용한다.

사내의 기본적인 커뮤니케이션

조사 결과를 보고한다
* 요청 받은 내용과 조사 방법을 쓴다.
* 자신의 생각과 제안 등을 쓴다.
* 주의사항 등이 있으면 쓴다.

결함 현황을 보고한다
* 결함의 상황 및 경향을 분석해서 쓴다.
* 결함의 발생 원인은 객관적으로 쓴다.
* 재발 방지 대책은 구체적으로 쓴다.

진척 지연을 보고한다
* 지연 규모를 명확하게 쓴다.
* 지연 원인을 명확하게 쓴다.
* 지연 회복 가능 여부를 명확하게 쓴다.

회의 개최를 통지한다
목적에 따라 회의의 종류도 다양하지만 공통적인 사항은 어떤 회의이든 효율적으로 진행되어야 한다는 점입니다.
즉, 회의의 효과를 높이기 위해서는 회의의 목적을 명확히 인식시키고 회의에 늦는 일이 없도록 해야 하며, 모든 사람이 회의에서 자유롭게 의견을 낼 수 있는 구조를 만들어야 합니다.
* 회의의 기본 정보를 쓴다.
* 회의 목적과 안건을 명확하게 쓴다.
* 사전에 준비해 올 작업을 명확하게 쓴다.

회의 결과를 보고한다
회의록은 회의 참석자에게 공유하는 것뿐만 아니라 회의에 참석하지 않은 사람에게도 정보를 공유해야 하는 경우도 있습니다. 그래서 회의에 참가하지 않은 사람도 이해하기 쉽게, 명확하게 기재해야 됩니다. 참석자가 발언한 내용을 정확하게 남기려면 '누가, 어떤 안건으로, 어떠한 발언을 했는지'를 상세하게 기재하는 것도 중요합니다. 회의록은 상위관리자에게 회람하는 경우도 있으므로, 회의의 목적이나 주제, 안건을 잘 모르는 경우를 대비하여 각주를 달아 설명을 추가하는 등의 세심한 배려도 필요합니다.
* 회의의 안건, 참석자 등의 기본정보를 쓴다.
* 기결사항과 누가 담당할 것인지를 쓴다.
* 미결사항과 언제까지 결정할 것인지를 쓴다.

고객이나 사외 인원과 문서 주고 받기

고객을 인터뷰한다
* 물어보고 싶은 내용을 세분화한다.
* 대답하기 쉽게 예시를 기입한다.
* 애로사항을 듣는다.

시스템 도입을 위한 정보나 제안을 의뢰한다
* 요건, 요구사항을 명확하게 쓴다.
* 언제까지 무엇을 해 줄 것인지 구체적으로 쓴다.
* 타사와의 경쟁 정보를 쓴다.

고객과 해결 방안을 논의한다
* 검토 방법, 절차를 명확하게 쓴다.
* 진행 방식의 이점을 쓴다.
* 참석자의 조건을 쓴다.

고객의 결정을 유도한다
* 조건에 충족하지 않는 부분을 명확히 한다.
* 남은 있는 과제를 명확히 한다.
* 다음 단계를 명확히 한다.

고객의 의뢰를 거절한다
일을 원활하게 진행시키기 위해 능숙하게 잘 거절할 수 있어야 합니다. 거절하는 문장에서는 '거절하는 이유'가 중요합니다.
고객을 화나게 하지 않게 하기 위해서는 고객의 입장에서 생각해 보고, 고객에게 오히려 단점이 되기 때문에 어쩔 수 없어 거절할 수 밖에 없을을 어필하는 것이 좋습니다.
* 상대도 '작업이 필요하고 귀찮은 일'이 될 만한 사항을 쓴다.
* 거절하기 위한 '고객 측의 대의명분'을 쓴다.
* 상대가 판단할 수 있도록 쓴다.

아이디어나 기획을 검토하고 제안한다

기획에 필요한 정보를 사외로부터 수집한다
* 평소에 정보를 수집할 수 있는 협력 관계를 구축한다.
* 정보를 제공했을 때 상대에게 부여핼 줄 수 있는 혜택을 제시한다.
* 정보원으로부터 제공 받을 정보와 전문 분야를 파악해 둔다.

업무 개선 기획을 검토한다
* 타사 사례나 전문가 등의 의견을 제시한다.
* 실증 실험 결과를 제시한다.
* 이해관계자의 목소리를 제시한다.

상사를 설득시킨다
상사는 자신의 입장에서 다음과 같은 '반론을 제기할만한 논점'들을 이미 가지고 있습니다. 반대하는 상사에게는 그만한 '이유'가 있기 때문에 이유를 분석하여 상사가 납득할 만한 대책을 작성해야 합니다.
* 상사가 반대하고 있는 논점을 명확히 한다.
* 구체적인 대책을 쓴다.
* 열의를 보인다.

새로운 비즈니스를 기획한다
* 비즈니스 아이디어의 차별화 포인트를 명확히 쓴다.
* 사업성을 판단할 수 있는 근거를 쓴다.
* 사업 개시 시 필요한 준비 사항을 쓴다.

브레인스토밍, 아이디어를 함께 도출한다
아이디어를 낼 때의 기본 규칙
1. 타인의 아이디어를 비판하지 않는다.
2. 타인의 아이디어에 탑승하지 않는다.
3. 소비자의 시점에서 재미있다고 생각되는 사항을 찾아본다. 회사의 시점에서 생각하지 않는다.
4. 타인의 아이디어로 좋다고 생각되면 '좋네'라고 적극적으로 반응한다.
5. 다른 기사 등을 적극적으로 인용한다.
* 기본 규칙을 쓴다.
* 계기가 될 만한 기사나 의견을 쓴다.
* 다른 사람이 낸 의견이나 아이디어에 빠르게 반응한다.

상대방을 배려한 사내 커뮤니케이션

다른 부문의 사람에게 의뢰한다
* 협력해 주었으면 하는 이유를 쓴다.
* 상대의 마음에 호소한다.
* 혜택을 어필한다.

후배나 부하를 칭찬해서 의욕을 불어 넣어 준다
업무를 원할히 진행하기 위해서는 '칭찬'이 중요합니다. 칭찬을 잘하는 방법은 왜 좋았는지를 구체적으로 칭찬하는 것입니다.
사람은 누구나 앞으로 기대된다고 하면 기분이 좋아집니다. 무엇인가 기대를 한다고 하면 그대로 행동하게 되는 것을 심리학에서는 '피그말리온 효과'라고 합니다. 기대하고 있다고 계속해서 말하면 공부를 하거나 정보를 수집하는 등 상대방의 행동이 바뀔 가능성이 높아집니다.
* 칭찬할 내용은 구체적으로 쓴다.
* 왜 좋았는지 이유를 쓴다.
* 기대하고 있다는 것을 쓴다.

감사의 마음을 전달한다
감사 문장에서 중요한 것은 '또 다시 협력하고 싶다', '또 돕고 싶다'는 생각이 들도록 작성하는 것입니다. 무엇이 도움이 되었고 어떻게 도움이 되었는지를 구체적으로 적어 감사하고 감격하고 있음을 문장으로 표현해야 합니다.
* 감사의 마음을 정중하게 쓴다.
* 도움이 된 내용을 구체적으로 쓴다.
* '또 협력하고 싶다'는 생각이 들도록 쓴다.

업무를 지시한다
지시는 가능한 한 구체적으로 명확하게 하는것이 기본입니다.
* 업무의 목적과 배경을 명확하게 쓴다.
* 구체적인 지시 내용을 쓴다.
* 완료일과 이후의 업무 절차를 쓴다.

같은 목적과 생각이 있는 동료를 만든다
동료를 만들기 위해서는 자신의 생각을 자주 공유해야 합니다.
* 무엇을 하고 싶은지 목적과 생각을 쓴다.
* 동료가 되면 어떠한 혜택이 있는지를 쓴다.
* 부담 정도를 쓴다.

2024년도 회고

뭐든창하 — Mon, 30 Dec 2024 16:19:36 +0900

북한산을 바라보며 야심차게 욕심만 많았던 2024년도 회고...

계획의 30%정도만 완료했는데, 계획엔 없었지만 나머지 70%를 못했어도 아쉬움 없을 정도로 올안해의 가장 큰 결과는 미국여행이었던것 같다.

동남아와 일본은 그대로 몇번 가봤으니 마음이 편하지만, 미국이라는 나라는 처음인데다가 워낙 흉흉한 기사거리도 많이 나오는 나라이고, 20일이 넘는 장기일정이니 그 만큼 변수도 많을 수 밖에 없어서 어쨌든 가족을 데리고 가는 가장의 입장에서 설레임과 기대감보다는 두려움과 걱정이 좀 더 있었던 편이었다.

하지만 여행동안 마주했던 광활한 자연과 미국이라는 곳의 경험, 그곳에서 함께한 우리 가족간의 사랑이 그 어떤 계획보다 나를 더 성장하고 성숙하게 해 준게 아닌가 싶다.

2024년은 능력의 성장보다 삶을 대하는 생각이나 태도측면에서 성장한 한 해로 마무리하고, 못다한 계획들은 2025년도에 차근히 이룰 수 있도록 노력해야 겠다.

그리고 2025년도에는 주위의 다른 사람들과 함께 성장하는 한 해가 될 수 있도록 주변도 챙기는 한 해의 계획을 세워야 겠다.

사무실의 도른자들

뭐든창하 — Wed, 21 Aug 2024 20:59:06 +0900

이런 유형의 책들을 보다보면, 두가지정도 단점이 있는 것 같다.

첫째는 주변 사람들에 대입하기도 하지만.. 그보다 내 스스로가 안좋은 측에 속하는 대상이 되지 않도록 노력하는 것에 더욱 압박감을 느끼곤 한다. 사실상 주변에서 여기 나오는 유형의 어느 한쪽으로만 치우친 도른자들은 보기가 쉽지 않다. 적당하게 좋은 점도 있고 적당하게 안좋은 점도 있다. 그렇다고 그런 사람들이 계속해서 같이 일하기 어렵다고 하냐면 그건 또 아니다. 어쩔때는 답답할때도 있지만 평균적으로는 일할때 그렇게 심각하게 느껴지지 않는다. 아마 그들이 보기에 나도 그런 정도의 동료일 수 있고 그 정도로도 무리없이 직장 생활할 수 있다고 생각이 드는데... 내가 평소의 능력이나 태도가 최저 1에서 최고 10까지 중 5~6이었다면, 이런 유형의 책을 보고 가장 좋은 것들이 무엇인지를 알아갈수록 나를 9~10까지 가야한다고 계속 압박하게 된다. 어떤 선택의 상황이 왔을때 지금정도로도 안되는건 아니지만 알게 되니 안할수가 없게 만드는 압박감이다.

두번째는 주변 사람들의 단점만 더 부각되어 보여서 부정적인 감정만 커져간다. '그들이 하고 있는 안좋은 사례들이 이렇고 이걸 좋은 방향으로 가기 위한 이런 좋은 정보들이 있는데 왜 그들은 이걸 모르고 노력을 안하는 걸까' 이런 답답함이 커져가다보니 불만이 되고 그들에 대한 부정적인 감정만 커져가게 되는 것 같다. 나도 그렇지만 모든 사람들이 다 이 책에 나오는 최선의 방향으로 항상 선택하고 살아갈 수 있는것도 아닌데 말이다. 그냥 안좋았던 것들이 조금 더 부정적인 감정으로 다가오게 되는 것 같은 건데...극히 드물지만 어쩔때는 그냥 그 사람 자체가 싫다고 느껴질 정도로 가기도 한다;;

'그들'은 어디에나 있다. 당연히 당신 옆에도

대부분의 사람들은 일하다가 만난 사람 때문에 평정심이 크게 흔들리는 경험을 한 적이 있다. 그에게 대처하려고 몇 가지 전솔을 시도해보기도 했을 것이다. 그중 제일 대담한 이들은 정면 승부를 시도해봤을지도 모른다. 그러나 면전에서 자기 결점을 지적당하는 걸 좋아하는 사람은 없으니만큼, 이런 시도는 십중팔구 더 큰 갈등을 불러왔을 것이다. 정면 승부가 실패하면 '가급적 회피' 전략으로 돌아서게 된다.
좋은 소식은 꼭 그렇게까지 할 필요는 없다는 것이다. 여러분의 영혼을 파괴하는 돌아이들, 그들이 여러분의 인생에 들이붓는 혼돈을 감내하며 살지 않아도 된다. 이 책을 통해 '그들'이 어떤 동기로 그렇게 행동하는지 이해하고, 대응 전략을 적용해보자. 그럼으로써, 여러분의 에너지를 바닥내고 정서 건강을 해치며 결국에는 마음의 평화를 깨뜨리는 돌아이들에게 대처할 능력을 장착하게 될 것이다.

'사무실의 도른자들', 그들은 누구인가

강약약강형
성과 도둑
불도저
무임승차자
통제광
불성실한 상사
가스라이팅형

'사무실의 도른자들'에 관한 진실 혹은 거짓

첫번째 오해: 그들에게 당하는 건 사회 초년생뿐이다.
학력이 어떠하든, 직책이 어떠하든, 누구나 돌아이의 희생자가 될 수 있다. 일터에서 시간을 많이 보냈다고 갈등 관리 능력이 저절로 쑥쑥 자라는 건 아니다.

두번째 오해: 돌아이들은 실무 능력이 없는 '무쓸모 직원'이다.
능력은 있으나, 그 능력을 악독한 방향으로 발휘하는 사람이 회사마다 평균적으로 한 사람씩은 있다. 대부분의 돌아이들은 사회적 인지능력이 뛰어나며 인맥도 많다.

세번째 오해: 상사가 돌아이를 내버려두는 건 관심이 없기 때문이다.
슬픈 현실은, 대부분의 관리자가 사람을 관리할 줄 알아서 그 자리에 올라간 게 아니라는 거다. 그들은 그냥 하던 일을 잘해서 승진했을 뿐이다. 돌아이 문제의 근본적 원인이 형편없는 리더십인 경우도 허다하다. 돕고 싶은 마음은 굴뚝같은데 돌아이를 어떻게 다루어야 할지 모르는 상사도 많다.

강약약강형 (툭하면 선 넘는 사람들과 안전거리를 유지하는 법)

그들의 목표는 오직 하나, 성공이다
단 하나의 목표를 향해 움직인다. 수단과 방법을 가리지 않고 정상으로 올라가는 것.
사회 비교 지향성(social comparison orentation, 자연스럽게 자신을 다른 사람과 비교하는 정도)의 스위치를 끄지 못한다.
지위 예민성(status acuity, 분위기를 읽는 능력)이 높아서, 직장 내 사람들의 서열을 쉽게 간파한다.

대체 왜 그런 짓을 하는 걸까?
목적(성공) 달성을 위한 버젓한 수단이 된다.
* 여러분이 잘 보여야 하는 사람 앞에서 여러분을 깎아내린다.
* 제일 못된 행동은 일대일 상황을 위해 아껴둔다.
* 할일이 산처럼 쌓여서 넋이 나간 상사에게 호의를 베푼다.
* 직책이 높은 사람에게 업무 외적으로 접근한다.

그들은 순식간에 권력을 쟁취한다, 하지만 시야가 좁다
재빠르게 권력을 손에 쥐고, 귀신같이 권력자들과 자신의 공통점을 찾아내지만 근시안적(저 사람이 지금 당장 내게 뭘 해줄 수 있지?)이다. 오늘날 많은 기업들은 전통적 업무 환경과 다르게 로테이션 프로그램이라는 선택지를 제공한다. 지금 괴롭히는 상대가 훗날 그들이 기대야 하거나 심지어 상사로 모셔야 하는 인물일지도 모른다.

안전거리를 유지하는 다섯 가지 방법
첫째, 인맥왕을 아군으로 확보하라.
둘째, 그들의 다른 먹잇감을 찾아보라.
셋째, 물리적, 정신적 완충 장치를 마련하라.
넷째, 구체적인 행동을 지적하라.
다섯째, 이제 기다려라.

만약 여러분이 상사라면,
모두에게 평등한 기회를 주는 규칙을 만들어라. 그러면 누구든 혼자 앞서나가려고 강약약강으로 행동할 가능성이 줄어든다.

성과 도둑 (양의 탈을 쓴 늑대로부터 내 것을 지키는 법)

그들은 주로 '양의 탈'을 쓰고 있다
* 성과 도둑은 기회주의자다.
* 성과 도둑은 여러분이 잘 아는 사람이다.
* 성과 도둑은 약한 상사를 이용한다.
* 성과 도둑이 전부 의도적으로 훔친 건 아니다.

성과를 가로채는 사람들의 두 가지 유형
* 친구인 척하는 적
* 꿀빠는 상사

더 큰 목소리를 가진다는 것
문자 그대로의 목소리도 커야 하고, 비유적인 표현으로서의 목소리도 커야 한다. 목소리를 지닌다는 건, 입을 열면 다른 사람들이 하던 얘기를 멈추고 집중한다는 뜻이다. 중요한 말을 하고 나서 오랜 시간이 지난 뒤에도 사람들이 그 말을 누가 했는지 기억해준다는 뜻이다.
목소리를 얻으려면, 실제로 목소리를 낼 일이 생기기 전에 동료와 상사에게 존중을 얻어야 한다.
목소리를 얻게 해주는 가장 예측 가능한 요소는 '핵심 조언자'가 되는 것이고, 핵심 조언자가 되는 비법은 다른 사람의 조언에서 배우는 것이다.

조언자는 친구와 다르다
개인적 호감을 사는데 기운을 빼지 마라. 직장에서 사교를 그만두라는 이야기는 아니다. 일과 관련 없는 수다는 사무실 밖에서 떨면 되다. 조언자도 많이 사귀면서 친구도 많을 수 있다. 중요한 건 언제 누구를 찾아가야 할지 아는 것이다.
* 문제를 제기하거나, 해법을 제안하거나
* 다른 사람들에게도 목소리를 줘야 한다.

'내 것'을 지키기 위한 2단계 전략
1단계, 입장을 말하라
2단계, 각자 무얼 했는지 정확히 알아보라

그들은 주로 여기서 활동한다
* 생각이 비슷한 사람들이 모인 팀
* 아이디어가 '공중에 마구 떠나니는' 생산적인 팀
* 대부분의 업무가 개인적으로 이루어지는 팀

조직 내에서 성과를 공정히 나누는 법
* 일하기 전에 누가 무엇을 할지 결정한다
* 성공적 결과 vs 노력의 과정
* 불평은 분노로 번지기 쉽다

불도저 (막무가내인 사람들을 여유롭게 상대하는 법)

절이 싫으면 중이 떠나라?
* 집단 의사결정을 자기 뜻대로 끌고 가려 한다.
- 재빠르게, 자주 권력을 행사한다.
- 자신의 전문적 능력 없이 돌아가지 못하는 팀을 찾는다.
- 직위 높은 친구들을 알고 그들을 거리낌없이 이용한다.
* 상사에게서 자신을 저지할 힘을 빼앗는다.
- 약한 상사를 노려서 복종시킨다.
여러 돌아이 유형 중, 불도저는 유일하게 겉과 속이 똑같은 유형이다. 자기 행동을 굳이 위장하려는 시도조차 하지 않는다. 그들에게 이미지 관리는 우선순위가 아니다. 중요한건 수단과 방법을 가리지 않고 자기가 원하는 무언가를 얻어내는 것이다.

한마디로 그들은 '트러블 메이커'다
불도저는 트로이 목마와 같다. 팀이 돌아가는 데 꼭 필요한 사람이 되어 입지를 굳히고, 그 다음 본색을 드러내니까.
* 첫날부터 조직에 꼭 필요한 사람이 된다.
* 이간질을 통해 관리자들을 무력화한다.

'싸울 가치가 있을까?'라는 질문에 대한 답
답하는 기준은 하나다. 여러분이 상대하고 있는 불도저가 일상적 단기 결정(회의 일정, 면담 시간, 회식 장소 등)에 관여하고 있는가, 아니면 장래 커리어에 영향을 미치는 장기적 결정(채용, 연봉 인상과 승진, 신규 지도자 훈련 프로그램 신청법과 같은)에 관려하고 있는가

말에는 말로, 현명하게 대응하기
* 재빨리 입을 열고, 발언권을 사수하고, 간략하게 요점만 말한다
* '느낌'이 아니라 '팩트'가 중요하다
* 불도저의 문제는 불도저가 풀게 하자

장기적으로 스스로를 보호하는 법
* 한 사람에게 의존하지 않는다
* 불도저의 천적은 소문이다
* 연맹을 맺는다
* 규칙을 정할 때는 모든 수단을 활용한다
* 시간 지킴이를 정한다
* 스포트라이트를 활용하라

무임승차자 (하는 일 없이 꿀 빠는 사람 퇴치하기)

사회적 태만(social loafing) 이라는 용어로 널리 알려진 링겔만 효과는 심리학에서 가장 잘 검증된 현상의 하나이다.
사람들은 팀의 인원수가 많을수록 업무에 쏟는 노력을 줄인다. 이 현상은 모든 산업, 모든 문화권, 조직의 모든 층위에서 일어난다. 팀에 소속되어 일하는 사람은 커리어의 어느 시점엔가 반드시 링겔만 효과를 맞닥뜨릴 것이다.

그들은 생각한다, 네 것이 내 것!
* 허울은 그럴듯하지만 실제 노력은 거의 들지 않는 일을 귀신같이 찾아낸다.
* 개인의 기여도를 따져 공로를 인정하기가 어려운 팀에 들어가려 한다.
* 커리어 초반에 슈퍼스타로 등극하고, 과한 보상을 받은 뒤, 빈둥거린다.
* 강약약강형처럼, 상사가 보는 자리에선 훌륭한 팀원 행세를 하지만 상사가 떠나면 바로 게으름을 피운다.

3C, 강한 팀워크가 무임승차를 부른다
* 성실한 팀원이 그들의 몫까지 일하기 때문에
* 친한 사람을 지적하기는 쉽지 않다
* 누가 무엇을 했는지 속속들이 알긴 어렵기에

우리 내면의 게으름뱅이
최고의 인재 확보를 목표로 이직하지 않도록 거액의 연봉을 준다. 인재가 하루종일 빈둥거리더라도, 기업은 그저 이들을 빼앗기지 않기 위해 큰돈을 쓴다. 이걸 '쉬면서 꿀 빨기(rest and vest)' 라고 한다. 기업은 그들이 애지중지하는 천재를 만족시키면 그 천재가 끊임없이 추동력을 발휘하고 아이디어를 생산할 거라고 믿는다. 다시 말해 이런 정책은 뛰어나 사람이 앞으로도 계속 뛰어나리라는 믿음에서 태어났으나 불행히도 우리 모두는 내면의 게으름뱅이가 잠재돼 있으며 이는 천재들도 예외가 아니다.
일을 계속 열심히 하게 만드는 장치 없이 그저 자리를 지키는 것만으로 과한 보상을 주는 건, 아이에게 숙제를 끝내기 전에 초콜릿을 주는 것과 같다. 뱃속에 이미 초콜릿이 들어 있는데 숙제를 할 동기가 생기겠는가?

싫다고 하라!
1. 무임승차자가 밀린 일 처리를 부탁하면서 '우리끼리'의 일로 해달라고 하면, 싫다고 하라! 비밀리에 일해준 공로는 인정받지 못한다.
2. 무임승차자가 사교 모임을 계획하느라 고생한 공로를 인정해달라고 하면 싫다고 하라! 감사할 일이긴 하지만 팀을 발전시키는 데는 도움이 되지 않았으니까
3. 무임승차자가 본인은 잘나가는 인물이니 일을 더 해서 '스스로를 증명할' 필요는 없다고 주장하면, 그건 아니라고 하라! 얼마나 잘났든 상관없다. 팀원이라면 업무에 기여해야 하는 게 순리다.
4. 성실한 팀원이 와서 '우리가 일을 나누는게 낫겠어요. 일을 시키느니 우리끼리 나눠서 해요'라고 말하면, 싫다고 해라! 그랬다간 팀원들을 쉽게 부려먹을 수 있다는 걸 알려주게 된다. 분명히 같은 일이 재발할 것이다.
5. 상사가 '각자 업무에 얼마나 기여했는지는 걱정마라, 보너스는 모두에게 동등하게 줄꺼다' 라고 말하면

무임승차를 예방하는 4단계 전략
1단계. 정기적으로 공정성을 검사한다
2단계. 일이 정신없이 돌아갈수록 팩트 체크가 중요하다
3단계. 비교와 경쟁을 활용하라
4단계. 직장 내 '콘트라프리로딩' 찾기

팀 내 무임승차자 하차시키기
무임승차자와 대화를 하는 목표는 무임승차자가 일을 하지 못하게 만드는 걸림돌을 넘을지 여부를 알아내는 게 아니다. 걸림돌을 어떻게 넘을지를 알아내는 것이다.

시간 도둑 vs 시간 다이어트
시간 도둑 : 핑거 프린세스(스스로 해결법을 찾아봐도 될 것을 곧장 도와달라고 이메일을 보내는), 욕심쟁이(성공한 지인 모두에게 손을 내밀어보는)
시간 다이어트 : 시간 다이어트를 유지하는 데 제일 큰 걸림돌은 죄책감이다. 내가 아니면 누가 이 사람들을 도울까? 알고 보면 도울 사람은 많다.

통제광 (일 못하는 완벽주의자와 일하는 법)

그들은 대게 한 번에 한 사람만 집중 공략한다
수면 위에서 과잉 통제하는 상사가 수면 아래에서는 불성실한 상사다. 통제광은 부하의 일상적 안녕에 영향을 미치지만, 불성실한 상사는 부하의 커리어 자체에 영향을 미친다.
* 업무를 지시하는데 마감 시간이 비합리적이다. 모든 사안이 하나같이 긴급하다. 모든 걸 당장 해내야 한다.
* 끊임없는 통제 폭격에 익숙해질 무렵 갑자기 사라진다.
* 오직 상대를 바쁘게 하려고 지루하고도 쓸데없는 업무를 던져준다.
* 부하가 하고 있는 일이 얼마나 중요한지 알려주는 법이 없다. 자신의 일이 대형 프로젝트의 작지만 중요한 부분에 해당한다는 것을 부하는 절대 모른다.

일은 잘하지만 관리는 못하는 관리자?
쉼 없이 감독하면, 결과물 하나하나가 조금이라도 나아진다고 생각한다. 통제광은 이 논리를 업무의 모든 부분에 적용한다.
대부분의 관리자들은 남을 관리하는 능력이 좋아서 관리자가 된게 아니다. 원래 하던 직무를 잘해서 진급한 것뿐이다.

맙소사, 쓸데없이 성실하기까지!
과잉 통제는 신뢰와는 무관하다. 과잉 통제에 영향을 미치는 건 '더 많은 감독이 더 나은 성과를 낳는다', '아무 일도 하지 않는 것보다는 무의미한 일이라도 하는 게 낫다' 같은 잘못된 믿음이다.

부드럽고도 생산적인 대화를 위한 여섯 가지 지침
첫째, 맞불 작전은 통하지 않는다.
둘째, 거시적 관점에서 목표에 대해 대화한다.
셋째, 기대 목표는 상호 합의로 정한다.
넷째, 상사에게 맞설 때는 일반화를 피한다.
다섯째, 주기적으로 업무를 확인한다.
여섯째, 근무시간에 명확한 경계를 설정한다. 일과 삶의 경계를 설정하는 기준(저는 종종 남들이 일하지 않는 시간에 일하지만, 당신도 그러길 기대하지 않습니다. 이 이메일을 주말에 받았다면 월요일까지 회신하지 않아도 좋습니다.)

불성실한 상사 (혼자만 여유로운 그들을 일하게 만드는 법)

'근무 태만'이라는 최신 트렌드
* 내내 무관심하다가 갑자기 끼어들어 통제하려 든다.
* 정작 꼼꼼한 감독이 필요한 단계에서는 나서지 않는다.
* 경보는 일찍 울린다. 상사가 면접 자리에서 앞으로 대단한 멘토링을 경험하게 될 거라고 호언장담하면 주의하라.
* 남들에게 여러분에 대해 놀랄 정도로 좋게 말한다. 스타 직원을 키워낼 줄 아는 좋은 멘토라는 인상을 주기 위해서다.

그들은 우리에게 쓸 시간이 없다?
과잉 통제하느라 너무 바쁘다.
자기 상사의 요구를 따라가느라 벅차다.
업무에 필요한 적절한 도구를 받지 못했다.
악마는 디테일이 있다고 하는데, 디테일을 모른다.
스타 직원을 알아보고 아낀다. 하지만 그게 다다.
시간 도둑에게 산 채로 잡아먹히고 있다.

불성실함이 부각되는 네 번의 순간
사무실에 붙어 있는 법이 없다.
늦게 등장하거나, 아예 등장하지 않거나
불성실하게 태어나는 게 아니다. 만들어지는 것이다.
'좋은 멘토'인 척을 한다.

그들을 제대로 일하도록 만드는 네 가지 방법
주기적으로 '찔러보기'
상사의 업무를 나눠 받으라고?
다른 전문가의 도움을 청하라
스스로 태만을 깨닫게 도와라

가스라이팅형 (거짓말로 무장한 사람들에게 맞서 싸우는 법)

가스라이팅형의 특징
* 둘만 공유하는 특별한 것에 속한 느낌을 줘서 상대를 고립시킨다.
* 상대의 자아존중감을 파괴하여 상대를 고립시킨다.
* 작은 것에서부터 큰 것으로 거짓말을 키워가며 간을 본다.
* 상대가 인식하는 현실에, 특히 기억에 의문을 품게 한다.

티가 나는 거짓말
1. '나'보다 '우리'라는 표현을 더 많이 사용해서 개인의 책임을 줄인다.
2. '톰이 말하기를' 같은 구체적인 표현 대신, '그 사람들이 말하기를' 또는 '누구나 알다시피' 같은 일반적인 표현을 사용한다.
3. 상황이 악화되는 게 확실할 때 오히려 과도하게 긍정적인 언어를 사용한다.

거짓말을 주입당한다는 느낌이 들면, 진실을 찾아내라
일반적이었으나 구체성이 부족할때, 그 구체적인 것들을 물어라.
"다들 그러는데"라는 표현에, '다들'이 누구인지 정확히 말해줄래요?라고 물어라.

'어디'보다 '언제'가 중요하다
개인적으로 긴밀한 사이일 때, 남들의 눈과 귀가 닿지 않는 먼 곳에서 일어나는 것들을 꼼꼼히 기록하고 공유해라.
가스라이팅형은 자기가 이용할 수 있는 약점은 무엇이든 이용한다. 실현되기 어려울 정도로 이상적인 미래를 속삭이는 상사를 주의하라.

그들의 손아귀에서 벗어나는 법
기록으로 증거를 남긴다.
조금씩 인맥을 쌓아나간다. 사람들이 당연히 여러분의 편에 서줄 거라고 가정하지 마라.
사회적 참고인을 찾아라.
사람들에게 의견을 구하라.
정면 대결을 하고 싶으면, 기다려라.

속수무책 당하고 있는 동료, 구출하기
* 동료의 사회적 참고인이 되어주거나, 동료를 다른 사회적 참고인과 연결해준다.
* 동료와 가스라이팅하는 사람의 사이에 물리적, 사회적 거리를 만들어줌으로써 완충 장치를 더한다.
* 동료가 여러분에게 털어놓기를 꺼리는 것처럼 보이면, 비밀을 유지할 공식적 책임이 있는 사람과 연결해줘라.

육각형 개발자

뭐든창하 — Sun, 28 Jul 2024 17:06:15 +0900

주니어를 벗어나려는 후배님들에게 내 경험담을 기반으로 조언을 해주는게 충분하지 않을 것 같고, 그래도 공통적인 사항이라던가 정리가 일목요연하게 된 내용들을 가지고 얘기해줘야 도움이 될 것 같아서 보게 되었다.

목적은 그렇게 다른 이들에게 도움이 될 만한 내용을 전달하고자 읽기 시작했지만, 개인적으로도 많은 부분에서 도움이 되었다. 그전에는 글로써 명확하게 전달하기 어려운, 나만의 언어로 나만이 가지고 있던 개념이나 생각들을 잘 정리된 개념적인 용어와 문장으로 표현된 부분들을 볼 때마다 가려운 곳을 긁어주는 듯 했고 이제 어떻게 표현해야 잘 전달 될 수 있을지 도움이 많이 되었다. 이 글에도 나오는 내용이지만 계속 시간을 내서 글을 써봐야 실력이 느는것 처럼, 책도 계속 봐야 단어나 표현에 써먹을 재료들이 많아지고 개념들이 잘 머리속에 정립되서 입에서 술술 나오게 되는 것 같다.

후배님들에게 전해줄 좋은 내용들을 잘 정리하긴 했지만...내가 못지키고 있는 것들도 있어 약간은 부끄러운 부분들도 있었다.

그래도 후배님들이 나보다 더 좋은 개발자가 되고 더 좋은 시니어의 길을 걷길 바라는 마음에 정리한 것들 중 일부분은 이곳에 남겨놓고 나머지는 잘 전달해볼 예정이다.

구현 기술 적용

어떤 기술을 도입할 때는 보수적으로 고민하고 다음과 같은 내용을 신경 써야 한다.
# 신뢰 구축
먼저 동료한테 신뢰받아야 하며, 구성원의 공감을 얻기 위해서는 자신의 역량을 증명해야 한다. 먼저 기존 시스템을 이해하고 주어진 일을 제대로 수행해야 동료에게 신뢰를 얻을 수 있고, 신뢰가 쌓여야 내 주장에 힘이 실린다.

# 함께 할 동료
새로 적용하고자 하는 기술에 대해 함께 논의하고 공감대를 형상할 수 있는 동료가 꼭 필요하다. 내가 맞는다고 생각하는 의견에 같이 공감해 줄 동료가 없다면 내 제안은 그저 고집일 수도 있다.

# 타당성
이유가 타당해야 한다. 구현 기술로 해결하고자 하는 문제가 분명해야 한다. 명확한 목적이 없다면 그저 빛 좋은 개살구일 뿐이다. 조직이 처한 상황고 조건이 부합할 때 새로운 기술을 적용해야 그 기술의 장점이 빛을 발한다. 단순히 개인의 욕구 충족을 위해 구현 기술을 적용하려 한다면 새로운 기술 사용에 따른 비용과 시간 그리고 부담만 증가할 뿐이다.

# 점진적 적용
한 번에 다 바꾸겠다는 생각은 위험하다. 비핵심 영역에서 먼저 검증한 뒤 핵심 영역에 적용해도 늦지 않다.

# 시장 상황
시장 상황을 고려해야 한다. 도입하려는 기술에 능숙한 인력을 원활히 채용할 수 있어야 서비스를 지속할 수 있다. 함께 일하는 동료의 이력도 고려해야 한다.

☻ 먼저 동료에게 신뢰를 받아야 한다! 이 말에 격하게 공감한다...

응집도

좋은 코드, 좋은 설계, 패턴, 아키텍처는 높은 응집도와 낮은 결합도를 추구한다.

응집도란, 모듈 안에 있는 요소가 함께 모여 있는 정도를 나타낸다.
왜 응집도를 높여야 할까? 결국 수정비용과 관련이 있다. 코드 분석 시간을 줄여주고, 기능을 변경할 때 수정할 범위도 줄어든다.
응집도는 역할 또는 책임과 관련이 있다. 응집도가 높아지면 구성 요소가 역할에 따라 알맞게 분리될 가능성이 커진다. 구성 요소가 역할에 따라 분리될수록 소프트웨어를 수정해야 할 때 변경 범위가 좁아진다. 또한 응집도가 높아질수록 구성 요소를 수정하려는 이유도 하나로 줄어든다.
단일 책임 원칙(Single Responsibility Principle)은 각 구성 요소는 하나의 책임만 가져야 한다는 원칙이다. 다르게 표현하면 구성 요소를 수정할 이유는 하나여야 한다.

# 캡슐화를 통한 응집도 높이기
/***************
 * before
 ***************/
Member m = getMember(id);
if (m.getExpiry().isBefore(LocalDate.now()) { // 만료여부 판단
    ...
}

// 만약 만료여부에 null 조건이 체크 추가 필요하면, 이 변경을 모두 찾아다니면서 수정 필요
if (m.getExpiry() != null && m.getExpiry().isBefore(LocalDate.now()) { // 만료여부 판단
    ...
}

/***************
 * after
 ***************/
Member m = getMember(id);
if (m.isExpired()) { // 만료여부 판단, null 체크 조건이 추가되어도 변경되지 않음
    ...
}

public class Member {
    ...

    public boolean isExpired() {
        return expiry.isBeofre(LocalData.now());
        
        // 만약 null 체크 조건이 추가되는 경우, 아래와 같이 한 곳에서만 변경
        // return expiry != null && expiry.isBeofre(LocalData.now());
    }   
}

결합도

소프트웨어 모듈이 서로 의존하는 정도(얼마나 밀접하게 연결되어 있는지 모듈 간 관계 정도를 나타냄)
한 요소를 수정할 때 다른 요소도 함께 수정해야 하면 두 요소 간 결합도가 높다고 표현한다. 결합도가 높아지면 유지보수 비용이 증가한다. 따라서 수정 비용을 낮추기 위해서는 응집도는 높이고 결합도는 낮춰야 한다. 응집도가 높다고 해서 반드시 결합도가 낮아지는 것이 아니다. 응집도를 높이려면 코드를 역할에 따라 분리해야 한다. 그러나 분리된 요소 간에 의존이 발생하게 되고, 서로 의존하는 정도가 올라갈수록 결합도가 증가한다. 캡슐화는 구현을 감춤으로써 두 구성 요소 간의 상호 작용을 줄여주어 응집도를 높이는 동시에 결합도를 낮춰준다.

# 추상화 타입과 결합도
/***************
 * before
 ***************/
public class MemberRegister {
    private JdbcTemplate jdbcTemplate;
    ....

    public void register(RegisterRequest req) {
        validate(req);
        Member m = createPendingMember(req);
        saveMember(m);
        sendNotiSms(m);
    }

    ...

    private void sendNotiSms(Member m) {
        String content = "...";
        jdbcTemplate.update(
        "insert into SMS_SEND(PHONE, CONTENT) values (?,?)", m.getPhone(), content
        );
    }
}
 
/***************
 * after
 ***************/
public class MemberRegister {
    // 구현채가 아닌 추상화 타입에 의존, Notifier 구현을 변경해도 MemberRegister 는 수정하지 않는다.
    private Notifier notifier; 
    ....

    public void register(RegisterRequest req) {
        validate(req);
        Member m = createPendingMember(req);
        saveMember(m);
        sendNotiSms(m);
    }

    ...

    private void sendNotiSms(Member m) {
        notifier.notifyTo(m);
    }
}
# 이벤트과 결합도
public class MemberRegister {
    public void register(RegisterRequest req) {
        validate(req);
        Member m = createPendingMember(req);
        saveMember(m);

        // 이벤트 발생
        // 이벤트를 사용한 코드에서 MemberRegister 클래스가 더 이상 통지에 대한 코드에 의존하지 않음
        Events.raise(new MemberRegisteredEvent(m));
    }
    ...
}
# 추상화.이벤트와 코드 추적
결합도를 낮추기 위해 추상화 타입을 중간에 위치시키거나 이벤트를 사용하면 두 코드를 직접 연결하지 않고 간접적으로 연결하게 된다. 두 코드가 간접적으로 연결되어 있기 때문에 직접 연결된 코드에 비해 코드를 분석하는 데 더 많은 노력이 들어간다. 따라서 추상화나 이벤트를 적용할 때는 결합도 감소, 응집도 증가, 변경 비용 감소, 테스트 가능성 등 얻을 수 있는 이점을 따져봐야 한다. 이점이 별로 없다면 추상화 타입을 사용하지 않고 구현만 분리해서 응집도를 높이는 것도 좋은 선택이 될 수 있다.

# 결합 유형
* 공통 결합(common coupling)
여러 모듈이 동일한 글로벌 데이터에 접근할 때 발생. 글로벌 데이터에서 변경이 발생하면 예측하기 힘든 문제가 생길 수 있다.

* 제어 결합(control coupling)
파라미터로 전달받은 값에 따라 동작이 달라진다. 무엇을 할지를 전달하는 형태로 흐름을 제어하는데 보통 파라미터를 사용해서 정보를 전달한다. 제어 결합은 내부 동작 방식을 외부에 노출해서 결합도를 높인다.

* 하위 클래스 결합
하위 클래스와 상위 클래스 간의 관계. 상위 클래스 기능을 사용하는 하위 클래스가 많을 수록 상위 클래스를 수정하기 어려워진다.
상속보다는 조립 원칙(Composition over inheritance)을 통해 결합도를 낮출 수 있다.

* 시간적 결합(temporal coupling)
단지 함께 실행해야 하므로 두 기능을 한 모듈에 묶을 때 발생한다. 예로 회원가입시 데이터의 저장과 문자 전송 기능을 함께 실행하기 위해 회원 가입 기능에 묶여 있다. 지켜야 하는 실행 순서도 시간적 결합에 해당한다.

* 논리적 결합(logical coupling) 또는 변경 결합(change coupling)
두 모듈 간의 변경 패턴이 존재할 때 발생한다. 모듈/시스템 데이터를 변경할 때 다른 모듈/시스템 데이터도 함께 변경해야 한다면 논리 결합이 발생한다. 예로 회원시스템의 회원 이메일 주소를 변경했을 때, 포인트 시스템의 이메일 주소도 함께 변경해야 하면 논리적으로 결합하고 있다고 할 수 있다.

리팩토링

# 수정 공포와 변경 비용
레거시는 수정하기 어렵다. 개발자는 왜 레거시에 부담을 느낄까?
* 긴 클래스, 긴 메서드, 복잡한 코드, 이상한 이름, 많은 중복, 테스트 코드 없음..
* 레거시 코드 수정과 악순환
- 레거시 코드를 이해하는데 많은 노력 필요
- 이해 부족 상태에서 코드 수정해야 함
- 변경에 대한 두려움
- 코드 덧데기로 두려움 회피 → (다시 코드 이해부터 반복)

레거시는 폄하 대상이 아니다.
레거시가 있었기에 서비스가 굴러가고 수익이 난 것이다. 그리고 모든 코드에는 나름의 사정이 있다. 그러니 불평하지 말고 개선할 거리를 긍정적으로 찾아보자.

코드 수정 비용을 낮추려면 결국 코드를 수정하기 쉬운 구조로 바꿔야 하고, 그 방법 중 하나가 리팩터링(refactoring)이다.
리팩터링은 새로운 기능을 추가하거나 기존 기능을 개선하지 않는다. 그래서 겉으로 드러나는 이점이 없다. 하지만 리팩터링을 하고 나면 장기적 관점에서 이점이 생긴다. 코드 가독성이 높아지고 리팩터링 이전보다 구현 변경과 확장이 용이해진다. 이러한 변화는 단기적으로는 수정 비용을 낮춰주고 장기적으로는 개발 비용을 줄여준다.

# 미사용 코드 삭제
삭제하기 두렵다면 해당 코드에 TODO 주석을 추가하자.
메서드와 클래스를 삭제할 때는 리플렉션으로 접근하는 코드인지 확인해 봐야 한다.

# 매직 넘버
매직 넘버는 그 값이 무엇을 의미하는지 유추하기 어렵기 때문에 정확하게 코드 의미를 이해하려면 여러 다른 요소를 함께 분석해야 한다.
실제 값은 상수로 정의해서 사용하거나, ENUM 타입을 사용해서 이름에 코드 값을 함께 포함하는 방식으로 변경해보자.
/***************
 * before
 ***************/
if (NumberUtils.anyMatch(boilerType, 19, 20)) {
    return true;
}
 
/***************
 * after
 ***************/
public static final GAS_BOILER = 19;
public static final INDUSTRIAL_BOILER = 20;
if (NumberUtils.anyMatch(boilerType, GAS_BOILDER, INDUSTRIAL_BOILER)) {
    return true;
}

// or
public enum BoilerType {
    GAS_19(19), INDUSTRIAL_BOILER_20(20);
}
if (NumberUtils.anyMatch(boilerType, BoilerType.GAS_19, BoilerType.INDUSTRIAL_BOILER_20)) {
    return true;
}
# 이름 변경
이름 변경은 가장 쉬우면서도 개발 도구가 가장 잘 지원하는 리팩터링이기도 한다.
단어를 고르는 데 어려움이 있다면 시간을 많이 낭비하지 말고 일단 당장 생각나는 단어를 사용해서 구현하자. 대신 주석으로 어떤 의미인지 적어 놓으면 된다. 이후 더 나은 단어가 떠오르면 그때 이름을 바꾸는 리팩터링을 하자.

# 메서드 추출
메서드 추출은 논리적으로 하나의 작업을 수행하는 코드를 대상으로 한다. 추출한 메서드에 알맞은 이름을 부여함으로써 가독성이 좋아지고, 관련 코드가 한 메서드에 모이면서 코드도 더 응집된다.
메서드를 추출하기 좋은 대상은 if-else 의 각 블록에 있는 코드이다. 무턱대고 메서드를 추출하면 안된다. 가독성이나 응집도가 좋아지는 방향으로 메서드를 추출해야 한다. 메서드 추출을 잘못하면 오히려 코드를 탐색하는 데 부담이 증가하고 가독성이 떨어지며 코드를 추적하기가 어려워질 수 있다. 이런 증상이 나타나는 주된 이유는 메서드로 추출한 코드 블록이 개념적으로 구분되는 로직이 아니기 때문이다.

# 클래스 추출
메서드 추출로 코드를 정리했지만 파라미터 전달 관계가 복잡해지는 경우, 메서드 추출 대신 클래스 추출을 고려해 볼 수 있다.
로직을 클래스로 추출하면 해당 로직만 따로 테스트할 수 있는 이점도 생긴다.

# 클래스 분리
한 클래스에 많은 기능이 모여 있으면 각 기능을 별도 클래스로 분리하고, 기능을 분리할 때는 한 번에 다 하기보다는 한 기능씩 점진적으로 진행한다.

# 메서드 분리
서로 다른 기능을 한 메서드에 구현하면 유사한 if-else 가 곳곳에 생겨 코드가 복잡해지고 실행 흐름 추적이 어려워진다. 이 상태에서 메서드 추출 같은 리팩터링을 하면 가독성은 개선되지 않고 구조만 더 복잡해질 수 있다. 메서드가 완전히 구분되는 기능을 구현하고 있는 경우에는 각 기능을 구현하는 메서드를 따로 만들고 분리해서 기능별로 응집도를 높여야 한다.
* 메서드 분리 순서
1. 두 기능 중 한 기능을 위한 메서드를 추가. 이 메서드는 내부에서 기존 메서드를 호출한다.
2. 기존 메서드를 호출하는 코드가 새 메서드를 호출하도록 변경한다.
3. 기존 메서드의 코드를 새 메서드로 이동한다.
4. 기존 메서드 이름 변경한다.
5. 코드를 정리한다.

# 파라미터값 정리
메서드에서 사용하지 않는 파라미터 데이터는 코드 분석을 어렵게 만들기 때문에 제거해야 한다. 한 타입을 여러 메서드에서 파라미터로 사용하거나, 같은 파라미터 타입이 메서드 호출 흐름대로 전파될수록 어떤 값을 사용하는지 확인하는 과정이 배로 어려워진다.
문제는 여러 메서드에서 한 타입을 파라미터로 사용할 때 발생한다. 여러 메서드가 한 타입을 파라미터로 사용하면 자연스럽게 특정 메서드에서만 필요로 하는 값이 타입에 추가된다. 나머지 메서드에서는 사용하지 않는 값이 파라미터에 추가되는 것이다.

# for 에서 하는 2가지 일 분리
for 문에서 여러 가지 작업을 실행하면 서로 다른 목적을 가진 코드가 뒤섞일 수 있다. for 루프가 1개의 일만 하도록 논리적이 단위로 분리하면 다음과 같은 이점이 생긴다.
* 코드가 복잡해지지 않고 논리적인 단위로 구분된다.
* 논리적인 단위로 구분되어 코드를 이해하기가 쉽다.
* 메서드 추출과 같은 리팩터링이 용이하다.
* 다른 로직을 추가하기가 용이하다.
루프를 한 번만 돌면 되는데 여러 번 돌게 되면 성능이 느려진다고 걱정하는 개발자도 있다. 하지만 미리 걱정할 필요는 없다. 대부분 성능에 문제가 없다. 정말로 문제가 될 때만 측정해서 개선하면 된다. 그리고 복잡한 코드보다 이해하기 좋은 코드가 주는 이점이 훨씬 크다.

☻ 모든 코드에는 나름의 사정이 있다. 그리고 그 사정은 그때는 맞고 지금은 다를 수도 있다.

그 코드의 과거를 들추는건 비난을 위해서가 아닌, 앞으로의 개선을 위해서 임을 잊지말자.

그러니 왜 그렇게 되어 있냐만 물어보고 끝내지말고 개선안에 대한 피드백 한마디라도 해달라.

테스트

# 자동화된 테스트·회귀 테스트·안정감
테스트를 수작업으로 진행하면 테스트를 아예 하지 않는 것보다는 낫지만 아무래도 다양한 경우의 수를 확인하기 어렵다. 현실적으로 모든 경우의 수를 테스트할 수는 없기 때문에 버그를 놓칠 수 있다. 운이 좋아 버그가 빨리 발견되어 바로 대응할 수도 있고 버그가 한참 뒤에 발견되어 원인을 분석하는 데 어려움을 겪기도 한다.
개발자는 항상 압박 속에 산다. 테스크 코드가 검증하는 범위가 넓어질수록 내가 만든 코드가 문제를 일으키지 않는다는 확신이 커지고 코드를 수정할 때 안정감을 느끼게 된다. 코드 변경에 대한 스트레스도 감소한다.

# 테스트 커버리지에 직찹하지 말기
테스트 커버리지가 높다고 해서 완벽하게 모든 문제를 없앨 수는 없다. 하지만 적어도 테스트를 통과한 코드는 문제가 없다는 것을 확신할 수 있다. 그래서 테스트가 검증하는 범위, 즉 테스트 커버리지(coverage)가 중요하다.
테스트 커버리지는 70~80% 수준이면 적당하다. 90% 이상을 목표로 하면 만들지 않아도 될 테스트 코드를 작성하는 일이 벌어지기 때문이다. 이 경우 테스트 커버리지를 높일 수는 있지만 실제로 테스트 코드를 작성해서 얻을 수 있는 가치가 없다. 가치 없는 코드를 만드느라 시간 낭비하지 말자.

# 테스트 주도 개발과 회귀 테스트
TDD를 진행할 때 예외적인 상황에서의 테스트를 먼저 작성하고 그다음 정상적인 상황에서의 테스트를 작성하는게 좋다. 많은 기능은 정상적인 상황뿐 아니라 예외적인 상황에 대한 대처가 필요한데 TDD는 테스트 코드를 작성할 때부터 이 점을 고려한다.

# 테스트 주도 개발과 설계
TDD가 기능을 설계하는 데 도움을 주기도 한다. 테스트 코드에서 테스트할 대상의 기능을 실행하려면 다음과 같은 것들(클래스 타입·이름, 메서드 이름, 메서드 파라미터 타입, 리턴 타입, 익셉션 타입, 의존 대상·역할)을 정해야 하는데 이것은 기능을 설계하는 과정과 같다. 클래스·메서드가 제공하는 기능이 이름에 잘 표현되어야 하는데 테스트 코드를 작성하려면 바로 클래스·메서드 이름부터 결정해야 한다.

# 테스트 주도 개발과 생산성
상황에 따라 변경하려고 하는 코드는 간단하지만 테스트 코드를 작성하는데 더 많은 노력이 들기도 한다. 테스트 코드를 작성하면 처음에는 개발 시간이 늘어나는 것처럼 느껴지지만 시간이 갈수록 반복되는 테스트 시간을 줄여줘서 오히려 개발 시간이 줄어든다는 것을 알 수 있다. 즉 미래의 디버깅 시간과 코딩 시간을 줄여준다.

# 테스트 가능성
테스트를 먼저 만들던, 나중에 만들던 중요한 것은 테스트 가능성(testability)을 높이는 데 있다.
코드를 만들 때 테스트 가능성을 염두에 두면 개발 생산성과 설계 품질을 높일 수 있다.

# 리팩터링을 위한 테스트 작성하기
리팩터링을 할 때는 리팩터링 전과 후의 코드가 동일하게 동작하는지 보장할 수 있어야 한다. 그러기 위해 리팩터링 전에 테스트 코드를 먼저 작성해야 한다. 기존 코드에 테스트 코드를 먼저 만들고 그 다음 리팩터링을 진행하면 리팩터링 후에 코드가 동일하게 동작하는지 검증할 수 있다.
기존 코드를 검증하는 테스트 코드를 작성하기 쉽지 않은 경우, 일부 코드만 분리하고 테스트를 작성하면서 리팩터링 해보자.

아키텍처

# 아키텍처를 결정하는 요인
아키텍처는 그냥 결정하는 것이 아니다. 요즘 특정 아키텍처가 유행한다고 선택해서는 안 된다. 아키텍처를 결정할 때는 크게 2가지를 고려해야 한다. 하나는 기능 요구 사항이고 다른 하나는 품질 속성 또는 비기능 요구 사항이다.

# 트레이드 오프
품질 속성을 높이면 시스템의 복잡도와 비용이 증가하고 서로 상충하는 품질 속성도 존재하기 때문에 아키텍처를 선택할 때 높이고자 하는 품질 속성 간의 절충이 필요하다. 절충하는 과정에서 하나를 얻으면 하나를 잃게 된다. 감당할 수 있는 수준의 복잡도, 사용자 규모 대비 적절한 인프라 비용, 시스템에 기대하는 최소 품질을 고려해서 아키텍처를 결정해야 한다. 아키텍처를 설계할 때 모든 면에서 최고인 아키텍처를 추구하면 안 된다. 모든 게 완벽한 아키텍처가 아닌 가장 나쁘지 않은 아키텍처를 선택해야 한다.

# 주요 아키텍처 품질 속성
* 가용성(availability) : 시스템이 얼마나 오랫동안 사용할 수 있는지를 나타내는 속성. 99.99%와 같이 사용 가능 시간/전체 시간 비율로 표시.
* 성능(performance) : 시스템의 최대 처리량, 평균 응답 시간 등을 포함하는 속성.
* 확장성(scalability) : 자원을 추가해서 증가한 사용자나 트래픽을 처리할 수 있는 시스템의 속성.
* 탄력성(elasticity) : 필요에 따라 자원을 추가하거나 반환하는 능력.
* 견고성(robustness) : 실행 중에 발생하는 에러나 잘못된 입력을 다루는 능력.
* 결함 허용(fault tolerance) : 일부 기능에 장애가 발생해도 시스템이 운영을 지속할 수 있는 능력.
* 신뢰성/안정성(reliability/safety) : 시스템 고장에 대비한 안전장치가 필요한지 또는 생명에 영향을 주는 중요한 시스템인지를 나타내는 속성.
* 유지보수성(maintainability) : 얼마나 쉽게 시스템을 변경하고 향상할 수 있는지를 나타내는 속성.
* 지역화(localization) : 다양한 언어에 대한 지원을 표현하는 속성.
* 테스트 가능성(testability) : 소프트웨어 결과물이 주어진 테스트 환경에서 얼마나 테스트할 수 있는지를 나타냄.
* 합법성(legal) : 시스템이 지켜야 할 법적 규제나 요건.
* 보안(security) : 데이터베이스에 암호화해서 저장해야 할 데이터, 통신 구간의 암호화 등을 나타내는 속성.
* 배포 가능성(deployability) : 개발한 결과물을 제품에 쉽게 반영할 수 있는 정도를 표현.
* 추적성(traceability) : 무언가를 추적할 수 있는 능력.

# 아키텍처가 중요한 이유
시스템이 커질수록 전체 시스템 설계가 개별 구현보다 중요해진다.
* 아키텍처는 시스템의 골격 역할을 한다.
만들려는 시스템에 따라 적합한 아키텍처가 존재한다.
* 아키텍처는 품질 속성에 영향을 미친다.
선택한 아키텍처에 따라 높일 수 있는 품질 속성이 있고 높이기 어려운 품질 속성이 있다. MSA 를 선택하면 탄력성, 배포 가능성(독립적 배포)이 커지지만 데이터 무결성을 위한 구조는 더 복잡해진다.
* 아키텍처는 기능과 직교한다.
API 서버를 비동기 프레임워크로 구현하면 일부 성능 지표를 높일 수 있지만, 관리자를 위한 백오피스 기능이나 CPU 연산이 많은 작업에는 적합하지 않다.
* 아키텍처는 시스템을 제한한다.
인증·인가를 위한 선택한 구조에 따라 관리할 수 있는 인가 범위가 달라지거나, 가비지 컬렉터를 사용하는 시스템은 가비지 컬렉터가 동작하면서 발생하는 지연 시간을 막을 수 없다. 필수로 사용해야 하는 외부 라이브러리가 특정 버전의 프레임워크에서만 동작할 수도 있다.

# 아키텍처 변경
시간이 흐르면서 요구되는 품질 속성이 달라졌으므로 그것에 맞게 아키텍처도 변해야 한다.
아키텍처 변경은 흥미롭지만 단순히 재미 삼아 할 일이 아니다. 또한 요즘 유행하는 방식 또는 최근에 학습한 내용을 적용하고 싶다고 해서 아키텍처를 변경하면 안 된다. 아키텍처 변경은 반드시 필요성에 기반해 이루어져야 한다. 요구되는 품질 속성의 변화가 없다면 아키텍처를 함부로 변경하면 안 된다. 아키텍처 변경에는 많은 시간과 노력이 따르기 때문에 신중하게 고려해야 한다.
아키텍처를 변경할 때는 확실하게 얻는 이점과 소요될 개발 비용을 고려해야 한다.

# 본질적 복잡성과 우발적 복잡성
해결해야 할 문제와 상관없는 복잡함을 우발적 복잡성(accidental complexity)이라고 부른다.
반대로 해결해야 할 문제 자체가 복잡해서 생기는 복잡함을 본질적 복잡성(essential complexity)이라고 한다.
개발자는 우발적 복잡성에 빠지지 않도록 경계해야 한다. 물론, 흥미로운 기술을 만나면 사용해 보고 싶고, 유명한 회사에서 썼다는 기술도 써 보고 싶기 마련이다. 심할 때는 어떤 기술을 쓰지 못하게 막는 상사한테 화가 날 때도 있다. 하지만 그럴수록 우발적 복잡성의 유혹에 빠지지는 않았는지 곱씹어보자. 당장 마주한 문제 또는 곧 닥칠 문제를 해결하기 위해 어쩔 수 없이 복잡성이 동반되어야 한다면 지속해서 설득하는 시간을 가져야 한다. 같은 문제를 해결하려 한다면 복잡한 구조보다 단순한 구조가 더 좋다는 사실을 항상 명심하자.

# 패턴 익히기
특정 맥락에서 반복되는 문제 해결법을 패턴(pattern)이라고 부른다. 상황에 맞는 패턴을 사용하면 설계 시간을 단축할 수 있기에, 여러 가지 설계 패턴을 알고 있으면 설계 품질과 유지보수성을 높이는 데 도움이 된다.
* 아키텍처 패턴
아키텍처 수준에서의 패턴. 예를 들어 이벤트 기반 아키텍처를 사용하면 탄력성과 성능에는 장점이 있지만 트랜잭션 처리가 복잡해지고 테스트도 어려워진다. 요구하는 성능이 낮거나 규모가 작다면 계층 아키텍처를 기반으로 한 모놀리식 구조를 사용하는 게 나을 수 있다.
* 디자인 패턴
유명한 GoF의 디자인 패턴
* 기업 통합 패턴
시스템간 통합을 위한 패턴
* 결함 허용 패턴
에러 처리에 충분히 신경 쓰면 오류를 줄일 수 있지만 완전히 장애를 없앨수는 없다. 제아무리 완벽하게 구현해도 어딘가에 구멍은 있기 마련이고, 설사 내가 만든 시스템이 완벽하더라도 연동하는 다른 시스템에 문제가 생길 때도 있다. 따라서 문제를 완전히 없애기보다는 문제가 생겼을 때 알맞게 대처하는 방법을 찾아야 하는데 이때 사용할 수 있는 패턴이 결합 허용(fault tolerance)패턴이다. 결함 허용 패턴은 에러 발견, 에러 복구, 에러 완화 등 어떻게 처리할지에 대한 패턴을 포함하는 개념이다. Heartbeat, Restart, limit Retires, Circuit Breaker 등이 결함 허용과 관련된 패턴이다.

# 패턴이 유용한 이유
패턴은 2가지 측면에서 유용하다.
첫 번째는 설계 시간을 단축해준다. 패턴은 맥락을 포함한다. 어떤 상황일 때 이런 패턴을 사용하라는 식이다.
두 번째는 원활하게 소통할 수 있게 해준다. 패턴은 이름을 갖고 있다. 상황, 구조, 동작 방식 등을 구구절절 설명할 필요 없이 이름만 말하면 모든 정보가 전달된다. 짧은 이름만으로도 다양한 정보가 전달되니 소통 효율이 높아진다.

업무관리

# 처음부터 끝까지
하나의 일을 주면 처음부터 끝까지 책임지는 것이 기본. 개발자는 요구 사항 분석부터 구현, 출시까지 이어지는 일련의 과정을 관리하고 마무리해야 한다. 여기서 책임은 혼자서 모든 일을 다 해야 한다는 뜻이 아니다. 일이 진행될 수 있게 관리해야 한다는 뜻이다.

# 업무 나누기
개발 규모가 커졌을 때 흔히 하는 실수 중 하나가 생각나는 대로 개발하는 것이다. 작은 일을 맡아서 할 때는 체계적으로 진행하지 않아도 일을 완료할 수 있다. 일을 진행하기 위한 정리 작업은 필요하지만 생각나는 대로 해도 잘못될 가능성이 크지 않다.
반면 일의 규모가 커지면 그냥 생각나는 대로 하면 안 된다. 즉흥적으로 일을 하면 제대로 끝내지 못할 가능성이 높다. 업무의 크기에 따라 일하는 방식을 배워야 한다.

일은 하루에 수일 이내에 끝낼 수 있는 크기로 나눈다.
* 요구 사항 분석, 기능 전반 이해 → 기획자 리뷰,현업 리뷰
* 개발 계획 → 규모 파악, 계획 초안
* 설계 초안
* 개발
* QA

일의 규모가 커지면 개발 계획도 세워야 한다. 어차피 예정대로 일이 진행되지 않으니 굳이 개발 계획을 짜는 데 시간을 들일 필요가 없다고 생각할 수도 있따. 하지만 일의 규모가 커지면 개발 계획은 반드시 세워야 한다. 물론 계획은 말 그대로 계획이므로 완벽하게 계획한 일정에 맞춰 일을 진행하기는 어렵지만, 계획이 있어야 진행 상태를 파악하고 변화에 대응하며 조정할 수 있다.
계획을 세우려면 일의 규모를 파악해야 한다. 규모를 파악하려면 해야 할 작업 목록이 필요하다. 작업 목록에 넣어야 하는 항목 중 하나가 개발할 기능 목록이다. 기능 목록은 시스템 사용자 입장에서 구분되는 단위로 작성하면 좋다. 명확하게 구분되는 기능 단위로 작업 목록에 추가한다. 모호한 표현을 사용하면 안된다. 기능 목록 외에 개발 자체에 대한 업무도 작업 목록에 넣어야 한다. 작업 목록을 작성했다면 작업마다 대략 얼마나 시간이 걸릴지(일단위 또는 주단위) 추정해본다. 어느 정도 규모인지 파악할 수 있는 수치를 도출할 수 있다는 것에 중요한 의미가 있다.

# 위험 관리
본인이 느끼기에 뭔가 잘 진행되지 않거나 모르는게 있을 때 또는 명확하지 않은 점이 생겼다면 위험 신호라고 여겨야 한다. 위험 신호를 감지하면 빠르게 공유해야 한다. 어떻게 개발해야 할지 감을 못 잡고 있으면서 어떡해서든 혼자 해보겠다고 발버둥 치면 안 된다. 오히려 문제를 더 키울 뿐이다. 따라서 스스로 위험 신호를 감지하면 즉시 공유해야 한다. 관리자에게 위험에 대비할 수 있는 시간을 주지 않으면, 위험을 피하고자 무리수를 두게 되고 자칫 잘못하면 조직에서 신뢰를 잃을 수도 있다.
위험 상황을 관리하기 위해 미리 위험 목록을 작성해보자. 위험 요소는 어떤게 있는지 검토해보고 5개 이상 찾아서 목록을 만들어보자.
위험 목록을 만들 때 등급을 함께 정리하면 더 좋다. 등급이 높을 수록 일에 주는 영향이 크니 신경 써서 관리해야 한다.

# 요구사항은 바뀐다.
이런저런 이유로 요구사항은 바뀌게 되어 있다.
요구 사항이 바뀌다는 사실을 인정하고 요구 사항을 대하는 방식을 바꿔야 한다. 초반에 요구 사항을 고정하기 위해 많은 노력을 기울이기보다는 요구 사항의 변동 폭을 줄이는 데 초점을 맞춰야 한다. 요구 사항의 변동 폭을 줄이려면 왜 이런 요구 사항을 원하는지 이해하려는 노력이 필요하다. 요구 사항은 주로 개발자가 아닌 비개발자가 요구한다. 비개발자는 본인이 이해하는 수준에서 요구 사항을 말한다. 이런 요구 사항은 현재 시스템의 한계로 구현이 어려울 수 있다. 또는 반대로 요구 사항이 논리적으로 이해 안 될 때도 있다. 이럴 때 개발자는 그저 해달라는 대로 해주면 안 된다. 왜 그런 요구를 했는지 이유를 들어봐야 한다. 특정 기능을 요구한 이유를 듣다보면 더 나은 방식이나 다른 대안이 떠오르기도 한다.
요구 사항의 변동 폭을 줄이는 또 다른 방법은 요구 사항을 나워서 분석하는 것이다. 초반에 모든 요구 사항을 세세하게 분석해서 협의하지 말고 개략적으로 분석한다. 전체 요구사항 중 절반가량을 초반에 집중해서 개발하고, 개발이 30~40% 정도 진행된 다음에 나머지 요구 사항을 정리하는 식이다.
오픈 시점에 포함하지 않아도 되는 기능은 우선순위를 조정해서 오픈 이후에 개발하는 형태로 이견을 조율할 수 있다. 보통 어떤 기능을 넣기 위해 오픈 시점을 미루는 것보다 빠르게 오픈하는 게 더 중요하기 때문이다.

결국 우선순위 문제다. 모든 요구 사항이 중요하다고 하지만 일정과 비용을 맞닥뜨리면 얘기가 달라진다. 구현 비용이 커지거나 원하는 일정 내에 구현이 어려워진다면 우선순위가 낮아지는 요구 사항이 생긴다. 관계자가 반드시 넣어야 한다고 말했던 기능이 꼭 구현하지 않아도 되는 기능으로 바뀌거나 요구 조건의 복잡도가 단순해지기도 한다. 일정과 비용은 개발 범위를 결정할 때 강력한 기준이 될 수 있다.
개발자는 소프트웨어를 만들어 요구 사항을 해결해주는 사람이다. 당연히 요구를 최대한 들어주기 위해 노력해야 한다. 하지만 그렇다고 모든 요구 사항을 수용하고 해결해주는 사람은 아니다. 처음부터 일정과 비용 얘기를 꺼내지는 말자. 일단 왜 그런 요구를 하는지 들어보자. 그리고 대안이나 우선순위에 대해 논의하자. 이런 과정을 거쳤음에도 요구 사항이 협의가 안된다면 그때 일정과 비용을 언급하자.

# 점진적·반복적 개발
점진적 개발(incremental development)은 결과물을 구분되는 조각으로 나누고 각 조각을 점진적으로 완성하는 방식이다.
점진적 개발의 핵심은 작업을 분할해서 더 빨리 가치를 제공한다는 데 있다. 점진적으로 사용자가 요구하는 기능을 제공함으로써 빠르게 사용자 만족도를 높일 수 있고 사용자 피드백을 신속히 얻을 수 있다.
반복적 개발(iterative development)은 사용자 요구 사항 또는 제품 일부분을 반복해서 개발하여 목표로 하는 결과를 만드는 방식이다.
난이도가 높은 개발을 진행할 때 주료 사용하며, 연속된 활동으로 원하는 목표에 도달하는 방식이 반복적 개발이다.
덩어리가 큰일이 있다면 관리할 수 있는 단위로 작게 나눌 뿐만 아니라 점진적이고 반복적으로 개발할 수 있도록 계획을 세워야 한다. 한 번에 모든 일을 다 진행하기보다는 조기에 가치를 제공할 수 있도록 점진적으로 기능을 출시하고, 난이도가 높은 일은 반복적으로 완성해서 위험을 낮출 수 있다.

# 안 된다고 말하기·대안 제시하기
개발자는 "안 된다"라고 말할 수 있어야 한다. 일단 약속하면 지키기 위해서 노력해야 하지만 노력만으로 할 수 없는 일은 분명히 못 한다고 해야 한다. 지키지 못할 약속을 하면 신뢰가 깎일 뿐 아니라 같이 일하는 사람도 힘들어진다. 안 된다고 말할 때는 할 수 없는 이유도 함께 전달해야 한다.
어려운 요구가 들어온다면 안 된다고만 하지 말고 대안을 찾아보자. 요구하는 이유가 무엇인지 들어보고 함께 고민하다 보면 해결할 다른 방안이 떠오를 때가 많다. 요구를 있는 그대로만 생각해서 못 한다고 하기보다 요구를 충족할 수 있는 대안을 찾아 제공하는 게 더 가치 있다고 생각한다. 또한 대안을 찾기 위해 함께 협업하는 과정에서 동료 간 신뢰도 높일 수 있다. 이후에는 협의가 더 부드럽게 진행된다.

# 수작업 줄이기
주기적으로 반복해서 해야 하는 수작업이 있다면 자동화해야 한다.

# 이유와 목적 생각하기
경력이 쌓이고 지위가 올라가면 단순히 시키는 일만 하면 안 된다. 반대로 누군가에게 일을 맡길 때도 단순히 어떻게 하라고 지시만 하면 안 된다. 일에는 이유와 목적이 있기 때문이다. 상급자로부터 업무 지시를 받으면 어떤 이유 또는 어떤 목적으로 그 일을 줬는지 알아내야 한다. 단지 결과만 만들면 되는 게 아니다. 이유와 목적은 올바른 결과를 만들었는지 판단할 수 있는 기준이 된다. 이유와 목적을 모른 채 어떻게 일을 할지만 고민하면 엉뚱한 결과를 만들게 된다.

☻ 개인적으로 일하는 방법은 주니어때부터 좋은 사수에게 잘 배워야 한다고 생각한다.

머리도 좋고 개발도 잘 하지만, 일 하는 방법의 센스가 없어 고생시키는 사람들이 의외로 많기도 하고 이 경우 안타깝기도 하다.

정리하고 공유하기

# 글로 정리해서 공유하기
좋은 글을 쓰는 건 어렵지만 연습으로 나쁘지 않은 글, 잘 읽히는 글을 쓸 수는 있다.
글을 잘 못 쓰는 개발자는 일단 글부터 쓰려고 한다. 짧지 않은 글을 쓸 때는 일단 글에 담을 내용부터 정리해야 한다. 글의 주제와 전달하고 싶은 내용이 무엇인지 그리고 어떤 목적으로 글을 쓰는지를 생각해야 한다. 글을 읽을 대상도 중요하다.
글의 주제, 개요, 목적, 대상을 결정했다면 내용을 어떤 순서로 풀어갈지 고민하자. 내용희 흐름은 자연스럽게 목차로 연결된다. 내용 흐름을 고민하면 자연스럽게 목차가 도출되고, 목차를 잡고 나면 그 안에 담을 내용을 고민한다.

# SCQA 프레임워크로 시작하기
설득을 위한 자료를 작성한다면 SCAQ 프레임워크를 활용하자.
* Situation(상황) : 현재 상태와 문맥을 제공한다.
* Complication(문제점) : 현 상황에서 무엇이 문제 되는지 기술한다.
* Question(의문점) : 문제점에서 도출되는 의문 사항이다.
* Answer(해결) : 의문점에 대한 해결책을 제시한다.

# 정확하게 전달하려고 노력하기
글로 정보를 전달할 때는 내용을 정확하게 표현하려는 노력이 필요하다. 먼저 모호한 표현이나 애매한 단어 사용을 줄이도록 노력해야 한다.
또한 정보를 정확하게 전달하려면 문서를 이해하는 데 필요한 정보를 함께 제공해야 한다. 글이 길어지거나 글만으로 부족하다면 적절한 그림이나 표를 제공해서 보완해야 한다. 시간이 걸리더라도 정리가 잘 된 문서를 만들면 문서를 읽는 많은 사람의 시간을 아낄 수 있다. 읽는 사람이 내용을 파악하는 데 들이는 노력을 줄여주는 것만으로도 문서 작성에 들어간 노력보다 몇 배 이상의 정보 전달 효과를 얻을 수 있다. 마치 코드와 같다. 하나 더, 비개발자를 대상으로 할 때는 개발 용어 사용을 최대한 아끼자.

# 5가지 글쓰기 팁
우리는 정보 전달이 목적인 글을 쓴다.
* 문장 짧게 쓰기 : 문장이 길어진다 싶으면 문장을 둘 또는 그 이상으로 나눠야 한다.
* 글머리 기호 목록·번호 목록 사용하기 : 여러 내용을 나열해야 할 때는 글머리 기호 목록이나 번호 목록을 활용하면 유용하다.
* 표나 그래프 사용하기
* 그림 사용하기
* 시각적 효과 사용하기 : 특정 단어나 문장을 강조해서 더 효과적으로 전달할 수 있다.

# 시간을 내서 글쓰기 연습하기
1주일에 한두 번이라도 글 쓰는 시간을 가져보자. 일단 쓰는 게 중요하다. 자꾸 써야 실력이 는다.

# 발표하기
발표의 핵심은 내용 전달이다. 발표 자료를 만들 때는 먼저 내용에 집중하자. 내용 초안을 만들고 말로 발표 연습을 충분히 하자. 자료를 포장하느라 말하는 연습을 놓치면 안 된다. 내요이 완성되면 그 때 발표 자료에 금칠을 해도 늦지 않다.
청중을 웃기려는 목적으로 개발자 짤 또는 밈이라 불리는 그림이나 유머를 무리해서 사용할 필요는 없다. 내가 먼저 발표 내용과 이야기를 전개하는 데 집중하면 청중도 내 발표에 집중한다. 물론 모든 청중을 집중시킬 수는 없지만 내 이야기에 관심을 가진 청중은 자연스레 발표에 집중하게 된다.

# 외래어 남용하지 않기
발표는 내가 아니라 듣는 사람을 위해서 하는 것이다.

☻ 의외로 고연차분들중에서 정리하기, 발표하기 등 정보 전달이 미숙한 분들이 있다.

이 부분은 스스로 노력도 필요하지만, 주위 여건이 발표를 많이 할 수 밖에 없는 환경등으로 주어져야 하는 요인도 못지않게 필요하다.

나 같은 경우에, 처음 외부고객 지원 엔지니어로 일하면서 다양한 사람들과 소통해야 했던 점과

회사에서 많은 발표 기회를 통해 꾸준히 연습할 수 있었던 점이 많은 영향을 끼쳤던것 같다.

그런 면에서 주니어에서 중니어로 가는 과정에서 이 부분의 능력을 잘 키워놓으면,

시니어를 넘어서까지 오랫동안 유용한 능력중 하나가 될 수 있다고 확신한다.

리더

# 리더 연습하기
서로에게 주는 영향력을 생각해봤을 때 우리 모두 리더가 될 수 있다. 좋든 싫든, 의식하든 의식하지 않든 간에 우리는 주변에 영향을 주기 때문이다. 리더십이 반드시 상사와 부하 직원 사이에서만 형성되는 게 아니다. 주변에 영향을 주고 있다면 그게 바로 리더십이다. 타고난 리더십을 가진 사람도 있다지만 대부분은 성장하는 과정에서 리더십을 배운다. 탁월한 리더는 아무나 될 수 없겠지만 리더십을 향상할 수는 있다. 리더십을 향상하는 데 경험이 정말 중요하지만, 경험만으로는 부족하다. 경험은 제한된 상황에서 이뤄지기 때문에 경험하지 못하는 상황이 훨씬 많다. 경험에서 부족한 부분을 책과 강의로 채워 나가야 한다.

# 문제 해결 리더십
개발자는 기술로 문제를 해결한다. 이런 관점에서 보면 개발자에게 필요한 리더십이 문제 해결 리더십인 것은 당연해 보인다.
뛰어나 기술 리더는 혁신, 즉 '더 좋은 방법으로 무언가를 한다'는 가치로 사람들의 능력을 발휘하게 하고 혁시을 위해 다음 3가지 활동에 힘들 준다.
* 문제 이해하기 : 문제를 올바르게 해결하려면 당연히 어떤 문제인지 제대로 이해해야 한다.
* 아이디어 흐름 관리하기 : 문제를 해결할 아이디어도 관리해야 한다. 내가 제시한 아이디어가 최고라는 자만에 빠지지 않도록 주의해야 한다. 다양한 의견을 청취하고 수용하려는 노력이 필요하다.
* 품질 유지하기 : 문제를 해결하는 뛰어난 아이디어가 있다고 하더라도 결과물의 품질이 떨어지면 아무 소용이 없다. 문제 해결 리더는 품질을 일정 수준 이상으로 유지하기 위해 노력해야 한다.

# 사람이 아닌 프로세스·시스템 변화시키기
사람은 쉽게 바뀌지 않는다. 변화는 결국 본인 스스로 해야 한다. 다른 사람이 변화할 때 내가 촉매제가 될 수는 있지만 본인의 의지가 없다면 변화는 일어나지 않는다. 그러니 사람을 변화시키려고 애쓰지는 말자. 변화가 필요하다면 사람이 아닌 프로세스와 시스템에 집중하자. 프로세스와 시스템을 바꾸고 사람들이 그 프로세스와 시스템을 따르도록 만들자. 이런 과정에서 변화가 자연스럽게 생긴다. 프로세스와 시스템 변경이 쉽다는 뜻이 아니다. 사람을 변화시키는 것보다는 조금이나마 수월하다는 의미다.

# 기술력 상실의 두려움 없애기
넓은 시야와 깊은 수준으로 시스템을 바라보고 아키텍처를 설계하는 역량은 구현 못지 않게 중요한 기술 역량이다. 복잡한 시스템을 알맞은 단위로 분해하고 진행 계획을 세우는 역량 역시 시니어 개발자가 가져야 할 중요 역량이다. 동료가 제시한 구현 기술 후보 중에서 현재 상황에 맞는 기술을 선택할 수 있는 기준을 갖추는 것도 중요한다. 자의든 타의든 리더나 관리자 역할을 맡게 될 때 그동안 쌓아 올린 기술력을 상싱하게 된다는 두려움을 갖지 말자. 대신 고참 개발자로 성장하는 데 필요한 여러 역량을 골고루 높일 기회로 생각하자.

# 대신하지 않기
직원을 돕겠다는 마음으로 직원이 할 일을 리더가 대신하기도 한다. 직원이 맡은 기능을 구현하는 식으로 말이다. 내가 가진 역량을 발휘해서 직원을 도왔다는 생각에 뿌듯할 수도 있다. 하지만 직원을 도왔다고 볼 수 없다. 오히려 직원이 성장할 기회를 훔친 것이다.
직원의 성장을 바란다면 일을 대신하지 말고 마음의 여유를 갖자. 위기 순간에는 빠른 조치를 위해 직접 나서야 할 때도 있지만 위험한 상황이 아니면 대신 하고 싶다는 유혹을 견뎌야 한다. 돕고 싶다면 구현 안을 함께 검토하거나 짝코딩을 사용해서 지식을 전파하는 식의 다른 형태로 지원하자.

# 자율성
일을 맡겨 놓고 작은 것까지 하나하나 지시하는 마이크로 매니저는 직원의 자율성을 뺏는다. 자율성이 없는 직원은 주도성을 잃는다. 직원에게 동기 부여를 해주고 주도적으로 참여하도록 유도하고 싶다면 자율성을 최대한 보장해줘야 한다. 간섭할수록 주도성은 떨어진다. 일단 맡겼다면 간섭을 최소화하고 기다리자.
자율성에도 어느 정도의 통제가 필요하다. 통제는 하나하나 작은 것까지 지시하는 관리가 아니고, 진척 상황을 확인하고 위험 요소를 검토한 다음 샛길로 빠지지 않게 막아주는 역할을 의미한다.

# 도움 요청하기
리더가 가져야 할 책임은 일을 제대로 끝내는 것이다. 그저 열심히만 해서는 안 된다. 힘든 일이 있거나 도움이 필요하면 상위 직급자한테 지원 요청을 하거나 함께하는 직원에게 도움을 구하자. 제때 도움을 구하지 않아 일이 엉망이 되는 것 보다 제때 도움을 구해 일이 제대로 진행되는 것이 낫다.

# 규모의 비경제 이해하기
프로젝트가 지연되면 개발자를 추가로 투입하는 것을 검토하는 리더가 많다. 인력을 더 투입하면 개발이 더 빨리 끝날 것 같은 느낌이 들기 때문이다. 하지만 잘못하면 정반대의 결과가 벌어진다. 소프트웨어 프로젝트는 규모가 커질수록 경제성이 떨어질 가능성이 높다.
지연된 프로젝트에 개발자를 추가로 투입하면 일정이 더 늦어진다는 것이다. 이것을 브룩스의 법칙(Brook's low)이라고도 한다. 이 법칙에 따르면 진행 중인 프로젝트에 인력을 추가로 투입하면 소통 비용과 부하가 늘어나면서 개발 시간이 줄기는커녕 오히려 증가한다.
소프트웨어 개발에서 규모의 비경제를 이겨내는 방법은 대규모 프로젝트를 여러 개의 작은 프로젝트로 나누는 것이다. 프로젝트를 나누고 각 프로젝트에 소규모 팀을 할당하면 개발자 생산성도 높아지고 프로젝트 성공 가능성도 올라간다.
프로젝트를 나눌 때는 독립성을 중점에 둬야 한다. 각 프로젝트가 최대한 독립적으로 진행되어야 규모에서 오는 비경제성이 줄어든다. 결합도를 낮추는 방식으로 아키텍처를 구성하면 독립적으로 프로젝트를 진행하는데 도움이 된다.

팔로워

리더십만큼이나 팔로워십도 중요하다. 팔로워십은 단순히 리더를 따르는 것을 의미하지 않는다. 팔로워십은 리더와 조화를 이루고 능동적으로 일을 수행하면서 리더가 성공할 수 있도록 지원하는 것을 말한다. 팔로워가 없다면 리더는 아무것도 할 수 없다. 반대로 리더가 조직 내에서 성과를 내지 못하면 팔로워 역시 성과를 내기 어렵다. 리더와 팔로워는 공생 관계이다. 팔로워는 리더와 소통하고 공감하며 문제를 발견하고 의견을 제시해서 리더와 함께 조직의 목표를 달성하는 데 기여한다.

# 팔로워십과 영향력
리더 역시 사람이고 잘못된 결정을 하기 마련이다. 이때 팔로워십이 필요하다. 좋은 팔로워는 리더가 제시하는 방향을 잘 지원하고 따르는 것뿐 아니라 리더가 잘못된 의사 결정을 내렸을 때 리더가 올바른 방향으로 이끌어갈 수 있도록 노력한다. 즉 팔로워는 리더에게 영향력을 행사한다. 리더가 불합리해 보이는 의사 결정을 내린 이유는 조직적인 이유 때문일 수도 있다. 또는 내가 미처 생각하지 못한 문제 때문일 수도 있다. 그러니 리더가 왜 그런 결정을 했는지 맥락을 파악해야 한다.
팔로워십을 발휘하려면 상향 관리가 중요하다. 관리자와 관계를 유지하는 방법으로 다음 3가지를 제시한다.
* 관리자를 놀라게 하지 말자. 관리자를 놀라게 하면 신뢰가 사라질 수 있다.
* 관리자에게 놀라지 말자. 관리자가 모든 세세한 사항을 챙길 것이라고 기대하지 말자. 대신 관리자와 적극적으로 소통해서 정보·피드백을 얻자.
* 관리자에게 관련 정보를 제공하자. 유용하다고 생각하는 정보가 있다면 관리자에게 전달한다.

# 나쁜 팔로워 되지 않기
나쁜 팔로워에 대한 정의
* 아무것도 하지 않기(전혀 관여하지 않기)
* 나쁜 리더(비효율적이거나 비도덕적인)를 지지하기
* 좋은 리더(효율적이고 도덕적인)를 반대하기
나쁜 리더를 막을 만큼 영향력을 행사하지 못하더라도 나쁜 리더의 방향을 지지하지 않는 방법으로 나쁜 팔로워가 되지 않을 수는 있다. 나쁜 리더가 있다고 해서 나쁜 팔로워가 되지는 말자.

# 이끌거나 따르거나 비켜서라
여러 사람과 함 께 일한다면 둘 중 하나는 해야 한다. 리더가 되어 누군가를 이끌거나, 팔로워가 되어 누군가를 따라야 한다. 이도 저도 싫다면 그들이 나아갈 수 있게 비켜서야 한다. 경력이 쌓이면 누구나 팔로워이면서 동시에 리더가 된다. 팀장을 따르면서 나보다 경험이 부족한 동료를 이끌어야 한다. 이때 좋은 리더가 되려면 먼저 좋은 팔로워가 되어야 한다. 좋은 팔로워는 리더가 의사 결정하는 과정에 참여하고 좋은 결정을 내릴 수 있게 함께 고민한다. 이런 경험이 좋은 리더가 되는 씨앗이 된다.

# 겸손·존중·신뢰
리더와 팔로워, 동료는 한 팀으로 협업해야 한다.
함께 일하고 싶은 리더, 팔로워, 동료가 되려면 겸손이 필요하다.
겸손·존중·신뢰 중에 가장 가지기 힘든 것이 신뢰다. 신뢰를 주는 것과 동시에 신뢰받기 위해 노력해야 한다. 신뢰는 역량과 성품을 기반으로 이루어진다고 했다. 즉 태도가 좋아도 역량이 없으면 신뢰가 생기지 않는다. 반대로 역량이 좋아도 태도가 나쁘면 신뢰하기 어렵다. 신뢰를 만들기 위해서는 좋은 태도를 유지하면서 역량을 높이는 노력이 필요하다. 한 번 맺은 관계는 프로젝트보다 더 오래 간다. 그러니 관계의 힘을 무시하지 말자. 지금 얻은 신뢰가 앞으로 큰 도움이 될 것이다.

다양한 역량을 보고 배울 수 있는 리더와 동료가 있다면 큰 도움이 된다. 이런 리더와 동료가 주변에 있다면 운이 좋은 것이다. 하지만 운이 좋다고 실력이 늘지는 않는다. 주변에 배울 만한 사람이 있다고 해서 내 실력이 절로 늘지는 않는다는 얘기다. "자신의 교육은 스스로 책임진다" 결국 역량 향상은 스스로 책임져야 한다. 스스로 노력하지 않으면 역량은 늘지 않는다.

개발 7년차, 매니저 1일차

뭐든창하 — Sun, 16 Jun 2024 00:04:51 +0900

개발 7년차, 매니저 1일차

저자의 영문 원제목은 "The Manager's Path" 인데, 그대로 쓰기에는 번역본의 제목보다는 확실히 좀 눈에 덜 띄긴 하다.

책의 흐름이 중니어를 벗어나 시니어로 들어선 때부터 CTO 까지, 각 직책에서 필요한 역량들에 대해 잘 정리해서 알려주고 있어서 좋았다. 물론 회사마다 직책에서 요구하는 역량들이 다르긴 하겠지만, 책을 읽을 때 특별히 직책을 고려하지 않고 전반적으로 어떤 역량을 필요할때 어떻게 하면 좋다라는 가이드라고 생각하고 읽으면, 오히려 앞으로 필요한 역량을 미리 준비하는데 도움이 되지 않을까 한다.

하지만 반대로, 현재 내 주변에 같은 직책의 분들이 이 책에 나오는 만큼 왜 못하는 있는걸까 하고 답답함이 느껴지기도 하는 역효과도 있을 수 있으니 감안하고 읽으면 좋겠다.

책의 내용중 팀장 이후부터 CTO 까지의 주요 글귀는 아직 발췌하지 않았다. 그 시기가 오면 다시 천천히 정독해볼 셈이라서...

원온원 미팅

팀원에게 매니저와 하는 원온원(1:1) 미팅은 좋은 업무 관계를 맺는 데 꼭 필요하다. 그러나 많은 매니저가 원온원 미팅을 소홀히 하거나 시간 낭비라고 생각한다.
원온원 미팅에는 두 가지 목적이 있다.
첫 번째는 팀원과 매니저 사이의 인간적인 연결이다. 훌륭한 매니저라면 팀원의 컨디션을 눈치채고 왜 그런지 물어볼 정도로 팀원을 챙길 줄 알아야 한다. 신뢰가 바탕이 된 인간적인 연결은 좋은 팀의 뼈대다. 신뢰, 특히 진실한 신뢰를 쌓으려면 상대 앞에서 기꺼이 약해질 수 있는 능력과 의지가 필요하다. 그러니 매니저라면 팀원을 직장 밖에서 삶이 있는 사람으로 대하고 팀원의 삶을 주제로 몇 분쯤은 이야기할 수 있어야 한다.
두 번째 목적은 어떤 주제라도 개인적으로 이야기하는 것이다. 원온원 미팅 주제를 정하는 것은 팀원의 몫이다. 만약 매니저가 먼저 요청하는 경우 팀원이 주제를 준비할 시간이 부족할 수 있다. 좋은 원온원 미팅은 상황을 보고하는 미팅과 다르다. 원온원 미팅이 프로젝트 상황을 확인하는 시간이 된다면 미팅은 금세 지루해진다.

☻ 원온원 미팅을 요청받는 입장에서 미리 경험해봤으면 좋았겠지만 현재는 정기적인 미팅이 체계화되어 있지 않아 아쉽다.

그래도 미리 연습해본다 생각하고 후배님들에게 요청해보는 것도 좋을 것 같은데, 한편으로는 걱정도 된다.

개인의 삶이라고 해도 어느정도 선이 있을테니 그 선을 넘지 않게끔 잘 기준을 잡아봐야겠다.

피드백과 직장 가이드

팀원이 매니저에게 기대하는 두 번째는 피드백이다.
피드백에서 칭찬은 공개로, 비판은 비공개로 하는게 이상적이다. 팀원을 공개 칭찬하는 것은 모범 사례(Best Practice)가 주는 긍정적인 효과가 크다.
팀원이 매니저에게 피드백을 요청하는 경우, 매니저에게 조언을 구하는 것은 존경을 표현하기에 좋은 방법이다. 누구나 꼭 필요한 사람이라고 인정받는 것을 좋아하며 매니저라고 해서 결코 다르지 않다.
시니어가 될수록 좋든 나쁘든 피드백의 수는 줄어든다. 시니어가 될수록 개인적인 피드백보다는 팀 또는 전략과 관련된 피드백이 늘어난다. 원온원 미팅을 주도하고 논의할 주제를 준비하고 매니저에게 피드백을 받는 일이 더욱 중요해지는데, 이를 소홀히 하면 매니저는 당신에게 성과 평가말고 무엇에도 많은 시간을 쓰지 않으려 할 것이다.

☻ 좋든 나쁘든 피드백도 했을때 받아들이는 태도가 되야 해주는 리소스가 아깝지 않다!

사회 어딜가나 귓등으로 듣거나 알겠다고 해도 고쳐지지 않는 사람들은 반드시 있다!

교육과 경력 성장

매니저는 구성원과 회사라는 관료제 사이의 주요 연결 고리이므로 팀원의 경력 개발을 돕는 교육을 찾아 제공할 책임이 있다.
시니어 업무일수록 승진 기회는 줄어든다. 따라서 매니저는 팀원이 다음 단계로 승진하는 데 필요한 자격을 증명해줄 성과가 무엇인지 찾고 알려줘야 한다.

☻ 꼭 승진에 결부시키지 않아도, 후배들이 한단계 더 성장할 수 있는데 도움이 되는 포인트를 찾고

관련 능력을 성장시킬 수 있는 교육과정을 잘 찾아주는것도 필요할 것 같다.

매니저에게 휴식을 주자

경력을 쌓아 시니어가 될수록 매니저는 풀어야 할 문제보다는 해결책을 기대한다. 원온원 미팅 때마다 필요한 것, 잘못된 것, 더 원하는 것을 말하지는 말자. 매니저가 문제를 해결해주길 바라는 대신 매니저에게 문제 접근 방식에 대한 조언을 구하자. 조언을 구하는 것은 존중과 신뢰를 표현하는 좋은 방법이기도 한다.

☻ 문제를 해결해주길 바라는 대신, 문제 접근 방식에 대한 조언을 구하자!

매니저를 현명하게 선택하자

실력 있는 매니저는 '사내 정치'를 하는 방법을 알고 있다. 뛰어난 매니저와 친구 같은 매니저, 개발자로서 존경받는 매니저 사이에는 차이가 있다. 많은 개발자는 조직에서 리더십과 관련된 정치적 맥락을 알지 못하고 알려고도 하지 않기 때문에 무능한 매니저로 전락하고 만다. 뛰어난 개발자가 주니어 팀원에게는 훌륭한 멘토형 매니저(Mentor-Manager)일 수 있지만, 시니어 개발자에게는 그저 자기 주장만 강한 변호사형(Advocate-Manager)일지도 모른다.

☻ 음...제일 하기 싫은게 '사내 정치'인데..확실히 무능한 매니저가 될수 있겠다 싶다.

성과를 잘 내도 회사에 아무것도 못 받아내는 거에 비해,

어느 정도 성과에도 '사내 정치'가 뒷받침 되어 잘 받아내는 매니저가 부러울때도 있다.

인턴을 위한 멘토링

실무 경험이 거의 없는 대학생을 멘토링한다는 것. 인턴이 의미 있는 경험을 하려면 어떻게 해야 할까? 먼저 인턴이 회사가 찾는 인재가 아니어도 멘토를 좋아하게 만들어야 한다. 그래야 인턴 기간이 끝나고 학교로 돌아가 친구에게 인턴 경험을 좋게 전달하고, 멘토에 대한 좋은 인상은 인재 채용에 막대한 영향을 미친다. 인턴을 뽑는다는 것은 그 회사가 그 학교의 졸업생을 채용하는 데 관심이 있다는 의미이기도 하다. 인턴과 함께하는 과정이 장차 매니저가 되는 데 필요한 기술을 연습하는 과정이 된다. 이때 필요한 기술은 경청, 의사소통하기, 적절한 피드백 주기 등이다.

☻ 인턴에게만 초점을 두고 하나라도 배워가게 해주면 좋겠다고만 생각했었는데,

그에 더해 인턴이 학교로 돌아가서 주변에 전파하는 회사의 좋은 인상들이 더 영향을 미칠 수 있을거라 생각해본적 없었던 것 같다.

경청하기

경청은 사람 관리의 시작이자 기본이다. 경청은 좋은 매니저의 핵심 기술 중 하나인 공감의 전 단계다.
멘티가 말할 때 자신의 행동에 주의를 기울이자. 멘티가 말할 때 뭐라고 말을 할지 미리 생각하지 않는가? 눈앞에 닥친 업무를 고민하지 않는가? 상대방이 하는 말에 귀기울이지 않고 다른 일을 하지는 않는가? 만약 그렇다면 이것은 경청이 아니다.

리더십을 배울 때 초반에 느끼는 깨우침 중 하나는 직접적이든 간접적이든 모든 사람은 자신의 의도를 상대방이 정확히 이해하게 말하지 못한다는 점이다.
멘토는 복잡한 설명을 몇 번이나 다른 방법으로 말할 수 있어야 한다. 멘티의 질문이 이해되지 않으면 다른 방식으로 거듭 질문을 한다. 멘티가 이해할 때까지 시간을 쓰는 것이다. 기억하자. 멘티의 눈에는 멘토가 큰 힘이 있는 위치의 사람이다. 멘티는 힘들게 잡은 기회를 망칠까 봐 또는 멘토를 기쁘게 해야 한다는 생각에서 멍청하게 보이지 않으려 노력하기 때문에 긴장한다. 멘토가 질문에 답을 하기 위해 많은 시간을 쓰는 확률보다 멘티가 충분히 질문하지 않아 일이 전혀 다른 방향으로 잘못 진행될 가능성이 더 높다.

☻ 나는 어느정도 부담감과 긴장감을 가지는건 나쁘지 않다고 본다. 그만큼 집중할 수 있고 집중하고 있다는 거니까.

다만 시간을 뺏어서 미안해하거나 바쁜데 방해해서 죄송하다는 생각은 안했으면 좋겠다.

후배님들의 업무에 방향성을 잡아주고, 성장시키고 조언을 해주라고 회사에서의 내 시간은 그러려고 있는거니까...

명확하게 의사소통하기

인턴이 스스로 해결 방법을 찾지 않고 멘토의 도움에만 기댈 수도 있다. 이럴 경우 다른 관리 방법이 필요하다. 인턴에게 이정표가 될 프로젝트의 첫 마일스톤을 알려주고 하루나 이틀 동안 혼자 작업할 시간을 준다. 인턴이 작업을 하고 있는 중간에 프로젝트를 중단하거나 교체하는 것은 부득이한 경우를 제외하고는 피해야 한다. 인턴이 기대보다 빠르게 모든 작업을 끝내 놀라게 할 수도 있으나 대부분은 행복한 상상에 불과하다. 대개 인턴이 올바른 방향을 유지하도록 약간의 방향성과 명확한 작업 방법을 알려줘야 한다.

☻ 인턴이라면 실력을 뽑내고 성과를 내는데 주안을 두기보다는 일하는 법을 배워간다고 생각하면 좋을 것 같다.

신입 사원 멘토링하기

효율적으로 일하는 팀에는 신입 사원 교육 문서가 잘 갖춰져 있다. 이를테면 개발 환경을 구축하고, 트래킹 시스템 동작을 이해하고, 필수 업무 도구를 단계별로 설명한 문서 등을 말한다. 이런 문서는 업무 환경의 변화에 따라 내용이 갱신되어야 한다. 멘토는 이 문서를 통해 신입 사원이 잘 적응하도록 돕고, 신입 사원은 교육 과정에서 겪은 문제를 기록해 팀에 헌실할 수 있음을 보여주는 것이 좋다.

☻ 처음 환경 적용하면서 한번 업데이트, 3개월 OJT 끝날때 다시 한번 업데이트!

기술과 경력 멘토링

매니저나 동료로서 반드시 해야 하는 솔직한 충고나 조언을 자신 있게 할 정도의 전문성을 갖추고 있지 않다면 멘토로 나서는 것은 의미가 없다. 그런 경우라면 멘토링을 거절해도 괜찮다. 자신의 시간은 소중하며, 멘토와 멘티에게 가치 있는 일이 아니라면 의무감에 "알겠다"라고 대답하는 것은 의미가 없다.

☻ 그렇긴한데...너무 다 자신있는 사람만 시키고 준비만 하다보면 언제 경험을 쌓아볼 수 있을지 걱정되기도 한다.

완벽한 준비는 아니더라도 해보자. 멘토도 해보면서 어디가 부족한지도 느끼고 전문성도 갖춰가는거니까.

다만, 멘티에게 미안함을 느낄정도로 준비가 덜 되었다면 안하는게 좋겠다.

좋은 매니저, 나쁜 매니저 : 알파 긱

팀이나 외부 사람과 멘토링을 하다 보면 '알파 긱(Alpha geek)'을 만날 때가 많다. 알파 긱은 팀에서 인정받는 최고의 개발자로, 늘 정답을 말하며 어떤 문제도 풀어내는 사람이다. 이들은 뭐든 뛰어나야 하는 '탁월함의 문화'를 만들려고 하지만 결국에는 '두려움의 문화'를 만드는 경향이 있다.
알파 긱이 좋은 매니저일 경우에는, 두려운 존재이기도 하지만 젊은 개발자에게 많은 영감을 주기도 하지만, 팀원이 그의 하대를 견디며 실력을 존경하기도 한다.
나쁜 매니저의 경우라면, 자기 의견이 반영되지 않은 결과는 아무도 가져갈 수 없게 하거나, 자기가 아는 것을 주위 사람이 모르면 즐거워하며 무지를 지적하기도 한다. 자신이 개발한 시스템에 대해 사람들이 불평하거나 기술적 결정을 비판하면 매우 공격적으로 반응한다.
알파 긱 성향은 대개 개발자가 처음 멘토 역할을 맡을 때쯤에 드러나기 시작한다. 만약 기술적인 부분이 뛰어난 데도 사람이 다가와서 도움을 부탁하지 않는다면, 자신에게 알파 긱 성향이 없는지 스스로 물어보자.

☻ 겪어보니 이런 사람들은 시간이 지날수록 스스로 외톨이가 되더라...

이런 부류의 사람들은 본인들이 무슨 잘못이 있는지 모른고 상대방 걱정따위는 신경도 안쓴다.

그러니 이런 부류의 사람들 때문에 내 스스로를 망가뜨리거나 낭비하지 마라.

멘토를 위한 핵심 요약

1. 호기심과 열린 마음 갖기
멘토링은 호기심을 키우고 새로운 눈으로 세상을 바라볼 좋은 기회다. 멘티의 질문은 새로운 사람의 눈을 통해 조직의 명확치 않은 것들을 관찰하는 시작점이 된다. 이해했다 여겼던 것에서 명확하지 않은 부분을 찾고, 일하는 동안 가치 있는 것이 무엇인지 다시 의문을 던질 기회를 준다.
2. 상대방의 언어를 듣고 말하기
멘토링은 경청을 연습할 좋은 기회다. 질문을 잘 듣지 않으면 좋은 대답을 할 수 없다. 신입 사원, 주니어 팀원과 업무를 잘 수행하려면, 몇 번이나 시간을 들여 노력을 쏟더라도 그들이 이해하는 방식으로 경청하고 소통해야 한다.
3. 인맥 관리하기
멘토링은 인맥을 쌓는 좋은 방법이다. 멘토 중 누군가가 직장을 소개해줄 수도, 미래에 함께 일을 할 수도 있다.

☻ 연차가 이제 구인공고에도 안나올 연차다 보니 확실히 인맥이 중요하다;

테크리드

테크리드는 매니저는 아니지만, 리더십이 필요한 자리다.
테크리드의 역할은 회사마다, 심지어 같은 회사에서도 팀마다 다를 수 있다. 그러나 테크와 리더의 합성어란 직함에서 알 수 있듯이 태크리드는 기술과 리더십이 모두 필요하며, 지속되는 직책이 아니라 일시적으로 부여되는 책임이다.
테크리드의 역할은 경력 사다리에서 특정한 지점이 아니라 모든 개발자가 시니어 수준이 되면 맡을 수 있는 몇 가지 책무라고 정의할 수 있다.
* 정기적인 원온원 미팅(주 1회)
* 경력 성장, 목표 진행, 개선된 영역 및 명시적인 칭찬 등에 대한 정기적 피드백
* 프로젝트 업무, 외부 교육 또는 멘토링 등을 통해서 팀원의 성장을 돕는 교육과 지원 보고서 작업

테크리드는 팀 전체의 성장을 위해 기술 프로젝트 리더로 활동하면서, 대규모 프로젝트에서 자신의 전문성을 살려 팀에 기여한다. 독립적인 결정을 할 수 있으며, 기술 팀과 비기술 팀 사이의 협력에서 중요한 역할을 한다. 여기서 특별히 기술적 업무에 관련된 것이 없다는 것을 알았을 것이다. 기술은 시니어 개발자의 역할이다. 따라서 테크리드의 역할을 팀에서 가장 경험이 많거나 실력 있는 개발자로 연결지어 생각하는 것은 잘못된 생각이다. 테크리드에게는 기술 전문성 이상으로 사람을 다루는 기술이 필요하다. 그리고 또 다른 중요한 기술인 프로젝트 관리 기술이 필요하다.

☻ 참 부담감 많이 느끼는 직책이다.

테크리드 되기

테크리드가 된다는 건 권위(Authority) 없이 영향력을 행상하는 것을 연습하는 것이다. 테크리드로서 팀을 이끌지만 모든 팀원은 개발 매니저에게 보고한다. 적절한 작업의 우선순위를 정하기 위해 팀원뿐 아니라 상사에게도 영향력을 행사해야 한다.

* 모든 훌륭한 테크리드가 아는 한 가지 비결
테크리드가 발휘해야 할 리더십 중 하나는 상사나 프로덕트 매니저 같은 다른 이해 관계자가 팀의 업무 몰입을 방해하지 않도록 회의 일정을 잡는 것이다.

☻ 팀원뿐 아니라 상사에게도 영향력을 미치는 직책이다.

진짜 참 부담감 많이 느끼는 직책이다.

테크리드의 기본 역할

테크리드가 가장 우선시해야 하는 것은 프로젝트를 계속 진행할 수 있도록 넓은 관점에서 업무를 조망하는 것이다.
테크리드는 새 기능을 개발하기 위해 과로하기 십상인데, 이는 때로 팀이 실패하는 원인이 되곤 한다. 테크리드가 되는 과정에서 소프트웨어 개발자, 시스템 아키텍처, 비즈니스 분석가, 팀 리더로서 직접 할 일과 다른 사람에게 위임할 일을 구분할 줄 알아야 한다.

* 테크리드는 끔찍한 자리인가요?
테크리드는 개인으로 회사에 기여할 수 있는 시니어 개발자보다 광범위한 책임을 맡습니다. 테크리드는 프로젝트의 아키텍처를 정하고 개발 업무의 실제 계획을 차근차근 밟아 프로젝트를 끝내야 하는 자리입니다. 팀원이 매니지먼트 책임을 걱정하지 않도록 하면서 프로젝트의 요구사항을 충분히 이해시키고, 업무를 계획하고, 팀이 효율적으로 일하도록 해야 합니다. 테크리드를 위한 교육도 없지요. 게다가 거의 모든 매니저는 테크리드가 되기 전에 해왔던 개발 업무도 계속 하기를 바랍니다.

* 복잡한 프로젝트 관리하기
프로젝트 관리가 모든 세부 사항을 관리하는 것이 아닌데, 어떤 조직에서는 세부 사항을 지나치게 점검하는 경우가 있다. 이 경우 개발자가 앞으로의 일을 생각하고 현재 무엇을 하고 왜 하는지 자신들이 왜 여기에 있는지 진정으로 질문하고 배우게 하기보다는 프로젝트 매니저에게 지나치게 의지하게 만들기 때문이다.
궁극적으로 '계획의 가치'는 계획을 얼마나 완벽하게 수행하는지, 사전에 모든 세부사항을 미리 파악했는지, 장차 벌어질 일을 예측하는지에 있지 않다. '계획의 가치'는 실제 업무를 시작하기 전에 스스로 프로젝트를 어느 정도까지 깊이 있게 생각할 수 있는지에 있다. 계획을 세우는 데 있어서 어느 선까지 합리적으로 예측하고 계획을 수립하는지가 목표이지, 계획이 얼마나 정확한지에 대해서는 많은 시간을 쓸 만큼 중요치 않다.

* 설명의 중요성
팀원에게 기초적인 개념과 동기를 설명하는 자리를 만드는 것을 주저하지 않는다. 왜냐하면 이런 자리는 팀원의 생각을 넓혀주고 팀원들이 내 판단과 충고를 신뢰하게 만들기 때문이다. 무엇보다 이런 노력이 결국 우리에게 좋은 변화를 가져온다. 시간을 들여 설명하는 건 매우 중요하다.

* 테크리드가 되고 싶지 않아요.
매니저 역할을 강요하는 것은 절대로 해서는 안 됩니다. 그 무거운 책임을 질 준비가 되지 않았다면 책임을 맡지 말아야 합니다. 아직 배울 것이 많다고 느껴 기술에 깊이 빠지는 것은 잘못이 아닙니다.

☻ 그 동안은 이 무거운 책임을 질 마음의 준비가 되지 않아서 멀리했다.

프로젝트 관리에 도움 되는 가이드라인

1. 작업을 작게 나눈다.
큰 성과를 낼 수 있는 업무를 작은 업무로 나누고, 큰 단위의 작업에서 작은 단위로 나누는 일을 반복한다.
작업 단위를 어느 정도 작게 나눈 다음에는 작업 순서에 주의한다.

2. 일을 어렵게 만드는 세부 사항과 문제가 될 수 있는 부분은 끝까지 신경 쓴다.
세부 사항을 더 파악하는 것이 의미가 없다는 생각이 들 때까지 세부 사항을 정리해보자.

3. 프로젝트를 시작하고 진행하며 계획을 수정한다.
잘 짠 계획은 프로젝트가 얼마나 진행됐고 언제 완료될지를 아는 데 도움이 된다. 계획이 어긋날 때면 모든 사람에게 상태를 알려야 한다. 이런 상황에서는 완료까지 얼마나 남았는지 추측하지 말고 마일스톤을 명확하게 지적하고 예상되는 남은 작업의 윤곽을 설명해야 한다.

4. 계획 프로세스에서 얻은 통찰로 변경된 요구사항을 관리한다.
도중에 요구사항이 바뀌면 앞서 분석한 내용을 토대로 변경 사항을 적용한다. 변경에 따른 비용을 명확히 하고, 마감 시간을 맞추려면 어느 정도 작업이 필요한지를 알아야 하며 우선순위를 정하고, 요구사항을 제외하거나 기능, 품질, 완료 일자를 잘 조율해야 작업할 때 도움이 된다.

5. 프로젝트 완료 시점이 가까워지면 세부 사항을 다시 검토한다.
마무리를 위한 세부사항을 꼼꼼히 챙길 때다. 무엇을 빠뜨렸는가? 테스트는 제대로 하고 있나? 검증은 잘 되고 있나?

☻ 대부분의 일을 잘하는 방법은 거의 유사하다.

좋은 매니저, 나쁜 매니저 : 프로세스 독재자

프로세스 독재자는 올바르게 구현된 설계를 따르면 팀의 모든 문제를 해결할 수 있는 '프로세스'가 있다고 믿는다.
프로세스 독재자가 가장 힘들어하는 것은 사람들 대부분이 자신만큼 프로세스를 잘 따르지 못한다는 사실을 알지 못할 때다. 또한 프로세스 독재자는 프로세스의 유연성과 예기치 않은 변경의 불가피함을 이해하기보다 모든 문제가 최선의 프로세스를 제대로 준수하지 않는 데 있다고 믿는다.

프로세스 독재자의 반대는 프로세스를 완전히 포기한 매니저가 아니라 프로세스가 팀과 업무의 요구 조건을 충족해야 한다는 것을 이해한 사람이다. 역설적이게도 애자일 방법론은 종종 엄격하게 적용되는데, 애자일 선언은 '건강한 프로세스 리더십'을 훌륭히 요약한 것이다.
* 프로세스와 도구에 우선하는 개개인과 상호작용
* 완벽한 문서화보다는 작동하는 소프트웨어
* 계약 협상보다는 고객 협력
* 계획을 고집하기보다는 변화에 유연한 대응

☻ 예전에는 프로세스를 빡빡하게 잘 지키지 않으면 스트레스 받고 그랬는데,

지금은 조금 모자란 것들은 내가 채워주고 지원해주고 그렇게 하는게

프로세스를 완벽하게 지켜서 나오는 팀워크나 성과, 효율성보다 훨씬 더 높다고 느낀다.

훌륭한 테크리드가 되는 방법

* 아키텍처 이해하기
테크리드로서 지원해야 할 아키텍처에 관해 충분히 이해하지 못했따는 느낌이 든다면 시간을 투자해야 한다.
1. 아키텍처에 대해 학습하여 감을 잡고 시각화해본다.
2. 데이터가 어디에 있고 어떻게 흘러가는지 파악한다.
3. 제품의 핵심 로직은 어디고, 이 부분이 어떻게 반영됐는지 이해한다.

* 팀 플레이어 되기
혼자서 재미있는 작업을 전부 하고 있다면 당장 멈추자. 기술적으로 필요한데 까다롭고, 지루하고, 성가신 작업이 무엇인지 살펴보고 이런 작업을 해결할 수 있는지 고민해야 한다. 코드에서 별로 재미없는 부분을 작업하다 보면 프로세스 어느 지점에 문제가 있는지 많이 배울 수 있다. 따분하고 실망스러운 프로젝트의 경우 경험 많은 개발자로서 이런 부분을 검토하는 데 시간을 쓴다면 개선할 부분을 분명하게 파악할 수 있다.

* 기술 결정을 주도하기
테크리드는 직접 결정할지, 팀의 전문가에게 결정을 위임할지, 팀원 전체가 모여 결정할지를 정한다. 어떤 경우라도 논의 중인 사항은 명확하게 하고 결과를 가지고 충분히 소통한다.

* 의사소통
팀의 생산성이 당신의 생산성보다 더 중요하다. 많은 경우에 의사소통으로 인한 비용이 든다는 의미다. 모든 팀원이 회의에 참석하는 대신 당신이 팀을 대표해서 팀원들의 요구사항을 전달하고, 회의 결과를 공유해야 한다. 성공한 리더는 글을 잘 쓰고, 주의 깊에 읽으며, 그룹 앞에서 나서서 말을 잘할 수 있다.
의사소통 과정에서 경청을 꼭 기억해두어야 한다. 다른 사람에게 발언 기회를 주고 그 사람의 말을 귀담아 듣는다. 다른 사람의 말을 확실하게 이해하기 위해서 그 사람의 말을 반복해보는 연습이 필요하다. 이때, 다른 사람의 말을 잘 듣고 자신의 언어로 바꾸는 방법을 배운다.

☻ 일단 지식적으로도 공부할께 너무 많고, 부족한 면도 채울 수 있게 스스로 성장도 해야 한다;

특별히 새로운 기술의 발전로 해결책의 패러다임이 크게 변하지 않는 이상은 무언가를 결정하는데 있어서

결론이 이랬다 저랬다 하지 않도록 자신만의 기준점(결정의 흐름이라고 해야하나..)을 확고히 다져놓는게 중요한것 같다.

문화 개선

문화를 만드는 것도 시니어 개발 리더의 역할이다. 팀이 성장하고 발전함에 따라 다른 중요한 인프라에 신경을 쓰는 것만큼 팀 문화에도 신경을 써야 한다.
스타트업 문화를 매력적으로 느끼는 많은 사람에게는 '구조'와 '과정'이 무의미하고 최악의 경우 오히려 방해가 된다고 여겨진다. 회의론자들과 구조를 논의할 때는 논의 방법을 바꾸기도 한다. 구조에 관해 논의하기보다는 학습에 관해 이야기한다. 과정 대신에 투명성을 이야기한다.
구조와 과정에 가치가 있기 때문에 시스템을 만드는 것이 아니다. 성공과 실수를 통해 학습하고 실패로부터 학습한 교훈을 투명하게 공유하고 싶다면 시스템을 만들어야 한다. 이러한 학습과 공유는 시간이 갈수록 조직이 더 안정되고 성장하는 방법이다.

☻ 문화는 여기저기 좋다는 말들만 입밖으로 전달해서는 안된다.

나 부터 실천하고 지키면서 전파하고 따라오게 만들어야 쉽게 개선된다.

문화 만들기

문화는 회사가 발전하면서 나타나는 자연스러운 현상이며, 문화가 존재한다고 믿지 못하면 빠르게 문제가 될 수 있다. 리더는 의식적으로 팀 문화를 이끌어야 하고, 잘 이끌기 위해서는 먼저 문화가 무엇을 의미하는지 이해해야 한다.
문화란 무엇인가? 문화는 일반적으로 사람들 사이에 존재하는 무언의 규칙이다. 서로 다른 입장의 사람들이나 서로 다른 관계의 사람들을 대하는 방법도 문화다. 하지만 모든 사람들이 완전히 똑같은 가치를 가진다는 의미는 아니다.
따라서 사람들은 문화적 가치가 아닌 다른 기준으로 결정을 하기도 하지만, 개인의 요구보다 그룹의 요구를 더 우선시하는 복잡한 환경에서의 문화는 팀으로서 우리가 함께 일할 수 있도록 하는 접착제이고 불확실할 때마다 결정을 내릴 수 있도록 돕는다.

☻ 우리가 함께 일할 수 있도록 하는 접착제이고 불확실할 때마다 결정을 내릴 수 있도록 돕는 우리 사이에 존재하는 무언의 규칙!

장애 사후 분석(Postmortem)

* 비난하거나 지적하고 싶은 충동을 억제하라
비난은 직원들이 실수를 두려워하게 만들 뿐이다.

* 사건의 상황을 살펴보고 맥락을 이해하라.
장애요인 목록을 잘 정리해두면, 개선을 위한 패턴이나 개선이 필요한 부분을 알 수 있고 학습 검토에서 진짜 학습이 일어난다.

* 중요하게 가져가야 할 것과 그렇지 않은 것에 대해 현실적으로 접근하라.
팀원들의 업무 과정에서 발견된 모든 문제를 해결해야 한다는 인상을 주지 않도록 하라.
수많은 학습 검토는 길고 긴 긴 '개선 목록'을 정리하고서야 끝나지만 모든 것을 해낼 수는 없을 것이다. 사실, 모든 것을 다하려고 한다면 아무것도 끝내지 못할 것이다. 정말 위험한 문제와 향후에 상당히 문제가 될 수 있는 두 가지만 선택하라. 그리고 나머지는 내려놓아야 한다.

☻ 특정 누군가의 실수가 아닌 우리 모두의 실수이다.

좋은 매니저는 누구인가

임백준님의 기고
경영층이 개발 팀에게 요구하는 사항과 개발팀의 현실을 조율하고, 소프트웨어 사용자의 목소리를 경청하고, 채용과 비용절감을 고민하고, 소프트웨어 제품의 출시 기간을 결정하고, 인사 부서와 함께 직원의 복지 문제를 논의하고, 평가를 통해 연봉과 보너스 수준을 결정하고, 개발자의 불만과 의견을 접수하고, 개발자 문화를 어떻게 개선할지 고민하는 일.

매니저를 통한 맥락에 대한 이해와 통찰의 안목이 넓어짐.
앞으로 매니저를 하려고 마음 먹은 사람이나 이미 매니저의 길을 걷는 사람이 반드시 기억해야 하는 중요한 논점.

매니저는 기술의 막다른 골목이 아니다. 매니저 트랙과 기술 트랙은 서로 만나지 않는 두 개의 평행선이 아니다. 그것은 서로 수시로 교차하는 나선형이다. 매니저는 언제나 기술현업에 돌아갈 준비가 되어 있어야 하고, 코딩 업무를 보는 사람도 상황에 따라 hands-off 매니저 역할을 수행할 수 있어야 한다.

좋은 매니저는 후배를 성장시키는 사람이다. 잘난 후배는 더 잘나게 만들고, 못난 후배는 자신감을 갖도록 도와주는 사람이다. 자기 장점이 무엇인지 깨닫게 해주고, 배움의 기회를 만들어주고, 자기 역량을 발휘하여 스포트라이트를 받게 해주는 사람이다. 후배가 너무 환히 빛나서 자신을 앞질러 가거나 다른 회사가 데려간다 해도 진심으로 개의치 않는 사람이다. 후배들의 앞 길을 있는 힘을 다해 열어주고, 이끌어주고, 밀어주는 사람이다. 그게 좋은 매니저다. 마음이 넓고 그릇이 커야 한다.

☻ 마음이 넓고 그릇이 커야 한다.

뉴비 프로젝트 매니저를 위한 이야기 한 조각

배상언님의 기고
공유의 힘, 성숙되지 않은 조직에서는 정보가 공유되지 않는 경우를 흔하게 볼 수 있습니다.
첫 번째, 작업이 끝난 뒤 종료일까지 일하지 않기 위해서입니다.
두 번째, 본인의 업무를 좋아하는 담당자라면 스스로 만족할 때까지 노력하고 싶기 때문입니다.
공유하지 않는 것은 어떻게 보면 인간의 본능이란 생각도 듭니다. 내가 준비하고 있는 것을 남에게 알려주고 싶어하지 않는 겁니다. 사람들은 본인의 일이 공유되거나 또는 공개되는 순간 마음이 편하지 않습니다. 나만 알고 있던 것들을 남들도 알게 됨으로써 압박을 느끼고 긴장하게 됩니다.

반대로 생각해봅시다. 나만의 일을 공유했을 때 동료들의 칭찬, 격려 그리고 감사의 마음을 받게되면 사람들은 쉽게 그리고 자주 공유하고자 할 것입니다. 공유가 편해지는 최소한의 조건은 팀 내에서 나의 안전입니다. 그렇다면 안전한 환경은 어떻게 만들 수 있을까요? 안전한 환경이란 솔직히 표현하자면 덜 위험한 환경입니다. 이것은 문화와 프로세스를 통해서 만들 수 있습니다.

투명하고 솔직하게 공유되는 정보는, 그 정보가 나쁜 내용을 가지고 있더라도 비판해서는 안 된다고 강조하고 싶습니다. 투명하게 모든 사람에게 공유한다는 것이 누구에게는 용기를 낸 행동일 수도 있습니다. 우리는 그러한 용기에 감사해야 합니다. 그리고 그런 문화를 만들어야 합니다.

☻ 안전한 환경보다는 덜 위험한 환경. 같이 일하는 동료들을 신뢰하고 공유하자.

어떤 개발자가 살아 남는가

뭐든창하 — Sun, 21 Jan 2024 12:34:53 +0900

어떤 개발자가 살아남는가

개발자로 지내온 지난 날들을 쭈욱 되돌아 보면, 코드를 짜고 버그와 씨름하고 릴리즈 하고 배포하고 등의 일련의 과정들을 컴퓨터 앞에서 계속 보냈지만, 그건 그냥 그 앞에서 시간을 많이 보냈을 뿐이지 이 과정이 순조롭게 흘러가는 모든 단계에는 생각해보면 사람과의 일이었던 것 같다.

그런 과정속에서 나도 개발서적만큼 커뮤니케이션, 철학, 심리, 성장마인드 등에 관련된 책들도 많이 봤던 것 같다. 확실한건 연차가 쌓이고 코드를 보는 시간보다 주위 사람들과 대화를 하는 시간이 많아지면서 그런 책이나 경험들이 도움이 많이 되고 있다는 점이다.

올해 독서 목표로 세운 개발서적들도 모두 코드 하나 없는 그런 책들이다...

이 책의 제목은 그런 관점에 내 관심사를 끌기에 아주 적합하지 않았나 싶다. 사람과의 관계가 더 비율이 높아지는 상황에서 인문학적인 고찰이 분명히 도움이 될 것 같았고, 무려 그게 개발자로서의 인문한적인 관점을 얘기한다고 했으니 말이다.

우리가 어떤 개발 프로젝트를 완성시킬 힘을 갖추어야 한다고 했을때, 그게 프로젝트를 관리하는 위치에 있는 사람도 있고, 개발을 수행하는 위치에 있는 사람도 있고, 품질을 만족시키 위해 검증하는 위치에 있는 사람도 있을 수 있다.

여기에 개발자의 입장에서 좀 더 들여다보면, 연차나 직책에 의해 코드를 구현함으로 참여하는 사람이 있는가 하면, 프로덕트가 완성되도록 조율하는 사람이 있을 수 있다. 하지만 공통적인것은 참여하는 이해관계자들과 함께 완성시켜 나가야 한다는 것이다.

이런 관점에서 내가 어떤 사람인지, 나는 어떠한 사람인지를 인지하고 이해관계자들이 어떠한 사람들인지, 이들과 함께 하기 위한 과정에서 인문학적으로 어떤 사고를 가져야 오랫동안 개발자로써 살아 남을 수 있을지를 알려주는 책이라고 생각이 들었다.

아래는 이 책을 읽으면서 공감이나 내 생각을 요약한 내용이다.

서문. AI를 이기는 개발자 인문학

개발자는 프로그래밍을 하지만, 대부분 정해진 프레임 안에 갇혀 있습니다. 누군가가 앞서 프로그래밍해 놓은 도구를 그저 사용하고 있을 뿐입니다. 대부분의 개발자가 이미 만들어진 환경 안에서 주어진 방법론과 도구들을 사용해서 프로그램 코드를 만들어 냅니다.
그런 관점에서 본다면 개발자들은 프로그래밍을 하는 사람일까요? 아니면 프로그래밍을 당하는 사람일까요?

☻ Spring Framework 로 구현하다보면 진짜 프로그래밍을 당하고 있다는 생각이 가끔 들때가 있다;

가장 완벽한 소프트웨어는 완벽을 추구해서 만들어지는 것이아니라 실패를 이어 나가는 과정에서 만들어집니다. 실패로부터 성공을 만들어 내기 위해서 그리고 더 좋은 개발자가 되기 위해서는 철학이 필요합니다.

☻ 확실히 나만의 철학에 대한 필요성을 느낀다.

Senior Engineer 로써 주위의 동료들로부터 수많은 의사결정/조언/검토 등의 요청이 쏟아지는데

그 때마다 일관된 기준의 대응을 하기 위해 얼마나 신경쓰는지 모른다.

내가 예전에도 이렇게 대답했는지, 앞으로도 유사한 문의에 같은 대답을 할 기준으로 생각하고 대답했는지 등 말이다.

1장. AI의 시대, 우리는 어디에 있는가

AI에 의해 대체되는 직업 분야는 그 기술적 구현 난이도와 함께 경제적 가치 또한 고려된다. 소프트웨어는 막대한 경제적 가치를 가지면서 AI 기술에 가장 밀접한 분야다. 옥스퍼드 보고서에 따르면 약 2030년까지 프로그래머의 48%가 AI로 대체될 가능성이 있다. AI를 구축하는 최일선에 있는 소프트웨어 개발자들이 AI에 의해 사라질 수도 있다는 역설적 상황에 직면한 것이다.

☻ Chat GPT가 할 수 있는 것들만 봐도 그렇다. 단순 코더는 이제 위험할 것이다.

AI가 선도하고 있는 테크놀로지 시대의 부흥은 역설적으로 기술 자체가 아닌 인간이 만들어 내는 인간적인 가치에 달려 있다. 결국 기술이 성공하기 위해서 기술은 인간을 향해 있어야 한다.

교육의 첫 단계는 문제를 정립(문법, 논리, 수사학)하는 것이다. 그 다음은 배운 것(산수, 기하, 역사 천문학)을 바탕으로 묹를 해결하는 것이다. 정리하자면 문제를 어떻게 정의하고 접근할 것인가 그리고 최선의 해결 방법은 무엇인가가 인문학을 배우는 목적이 되는 셈이다.
문제를 정의하는 것을 체계적으로 하기 위해 소프트웨어 요구공학이라는 기술이자 학문 분야가 생겨났고, 정의된 문제를 해결하기 위한 체계적인 접근 방법이 소프트웨어 설계다.

2장. 알고리즘 vs 데이터 그리고 창조력 코드

모방으로 그치지 않기 위해서 역설적으로 숱한 모방이 필요하다. 모방에 있어 중요한 점은 가장 기초가 되는 원론을 숙지해야 한다는 것이다. 소프트웨어가 생각대로 잘 구현되지 않으면 더 많은 정보를 찾아보고 더 공부를 하게 되고 자연스럽게 원개념을 정확하게 이해하게 된다. 단편적인 정보들과 여기저기서 복사한 코드들로 소프트웨어를 만들었는데 운이 좋아 잘 동작하는 것이다. 사실 이는 운이 좋은 경우가 아니라 오히려 운이 나쁜 경우가 될 수 있다. 아무 문제가 없었다면 그냥 아주 운이 좋은 것에 불과하다. '그냥 가져다 쓰고 아무 문제가 없길 기도하는 방식의 개발'은 제대로 된 모방이 아니다.
지나온 물길을 거슬러 물살이 최초로 시작된 그 곳에 가 보았던 사람과 그렇지 않고 바로 지금 흐르고 있는 물줄기만을 보고 있는 사람 간의 차이는 있을 수밖에 없다.

☻ 나는 얼마나 많은 원리들을 깊게 파헤쳐보기 위해 노력했던가 많이 반성하게 되는 부분이다.

3장. 누가(Subject) 무엇을(Object) 어떻게(Project) 해야 하는가?

목표 달성이 중요한 게 아니라 달성한 목표가 무엇인지가 더 중요하다.

☻ 이 문장에 솔직히 충격 받았다...이런 생각을 해본 적이 거의 없다는 것에...

소프트웨어 개발자들은 커밋 로그에 자신이 더 노력을 많이 들인 코드, 더 시간을 많이 들여서 개발한 코드에 대한 내역을 우선하는 경향이 있다. 이는 잘못된 방식이다. 동료 개발자나 해당 커밋 로그를 통해 정보를 얻게 되는 이해관계자들 관점에서 중요하다고 판단되는 것을 먼저 기술해야 한다. 비록 그것이 노력을 덜 들인 것이라 할지라도 말이다. 그 코드가 가지는 최종적인 가치가 우선이다.
이것은 보고서를 쓸 때도 마찬가지다. 내가 무엇을 한 것인지가 중요한 것이 아니라 전체 소프트웨어와 프로젝트의 관점에서 중요한 것을 우선 기술해야 한다.

☻ 코드가 시작된 JIRA 티켓에는 목적과 배경이 있지만, 코드 커밋 내용에 이 코드가 가지는 최종적인 가치를 기술해본적은 없는 것 같다;

소프트웨어를 제조업으로 생각하는 마인드를 가지고 소프트웨어 개발자의 창의성을 논한다는 것 자체가 어불성설이다.

☻ 지금의 회사는 제조업인데, 장비용 소프트웨어는 어느정도 이해는 간다만..그래도 플랫폼 서비스는 아니지 않나싶다...

4장. 지속적인 개선 - Upgradable Software

계속되는 개선이 지연되는 완벽함보다 낫다.
소프트웨어 개발이 추구해야 할 것은 완벽이 아닌 완료다.
경험이 없으면 없을수록 더욱 애자일해져야 한다.

☻ 애자일이라는 단어를 쉽게 얘기하지만 수행할때에는 서로의 상황에서 발생하는 딜레마때문에 어려운 것 같다.

기획자 입장에서는 빠르게 적용해보고 피드백을 통해 빠르게 개선할 생각으로 초기 사양을 작게 기술하고,

개발자 입장에서는 나중에 전혀 다른 사양으로 변할때 많은 부분들을 변경해야 하는 위험성을 감수하고 싶어하지 않으니

좀 더 많은 부분들이 확정되었으면 하는데, 이 중간지점을 정하는게 어려운 것 같다.

물론 빠르게 변경이 가능한 아키텍처와 구조를 잡는게 능력이 아니냐고 말한다면... 딱히 떠 오르는 반문이 생각나지 않는다;;

애자일 소프트웨어 개발 선언(애자일 매니페스토)
첫째, 절차와 도구보다 개성과 화합을
둘째, 포괄적인 문서보다 작동하는 소프트웨어를
셋째, 계약 협상보다 고객과의 협력을
넷째, 계획을 따르기보다 변화에 대응하기를
사실 일하다보면 왼쪽의 가치들로 몰려가는게 현실이다.

☻ 첫 직장은 90:10 이었던것 같고, 지금의 직장은 초기에는 30:70 이었는데 현재는 60:40 으로 바뀐것 같다.

소프트웨어 개발 프로젝트는 대부분 장기 프로젝트이고, 선행해서 구현되어야 하는 부분들이 있기에 설계가 중요하다. 제대로 설계되지 않은 상태에서 다짜고짜 코딩부터 해 버리면 나중에 갈아엎고 다시 처음부터 개발해야 하는 상황이 발생하는데, 이전에는 이런 상황 자체를 문제라고 생각하는 경향이 많았고, 설계가 완벽하지 않은 상태에서 개발을 시작하는 것은 비효율적이고 무데뽀고 주먹구구라고 펌하되었다.
하지만 이제 시대가 바뀌었고, 개발의 선각자들은 마냥 기다리는 것보다 그냥 한번 해보는 것이 결코 비효율적인 방법이 아니라는 것을 깨달았다. 설계가 완벽할 때까지 기다라는 것이 아니라 구현을 하고 다시 이를 설계에 반영하는 반복적인 개발 방법이 대세가 되었다. 해보고 아니다 싶으면 다르게 하면 된다는 린(lean) 개발 방식이다.

☻ 이상적인 말이다.

여러 직장의 경험이 없긴 하지만, 주위 다른 직장의 지인들의 얘기를 들어 보아도 이런 방식의 잘 된 경험을 들어보기 어렵다.

비효율적이고 문제라고 생각될 수 밖에 없는 현실이, 언제나 마감 시간은 정해져 있고

"해보고 아니다 싶으면 다르게 하면 된다"라는 시도의 리소스(시간과 인력)조차 허용되지 않는다.

그러니 시도가 불가능하고 한정된 리소스안에서는, 어떻게든 최대한 완벽한 설계가 나오길 기대하고 이를 한번에 완성해내야 한다.

애초부터 어떤 편견이나 잘못된 지식을 향해 있지 않더라도 스스로를 끊임없이 보정하지 않는 이상 우리는 잘못된 길로 들어설 수 있다.
보정되지 않은 자신감, 즉 오만(Pride)은 잘못된 지식의 쌍둥이 형제와 같다. 영어 Pride 는 희한한 단어다. 자신감과 자부심, 자랑스러움이라는 긍정적인 뜻과 함께 오만함과 거만함이라는 부정적인 의미를 함께 가지고 있다.
자신감과 오만 이 두 가지는 종이 한 장 두께의 차이도 나지 않는 상태로 서로를 바라보고 있다.

☻ 스스로를 끊임없이 보정해야 한다! 너무 필요한 말이다

지금 맞다고 알고 있는 것도 시간이 흐르면 바뀔수도 있고, 모르고 있는 것들조차 내 기준의 잣대에 맞춰 예단해 버리면 안된다.

어디선가 들은 말인데 너무 무서운 말, "잘 모르고 무식한 사람이 신념을 가지면 무섭습니다."

최종 사용자에 도달한 소프트웨어가 어떻게 동작하고 어떤 가치를 가지는지 알아야 한다. 이 최종 지점과 자신이 만들고 있는 소프트웨어 모듈간의 끈은 이어져 있어야 한다. 이 두개의 연결이 단절되어 있다면 좋은 소프트웨어를 만드는 것은 힘들고, 또한 좋은 소프트웨어 개발자가 되는 것은 더욱 힘들다. 위대한 개발자가 되기 위해서는 지금 하고 있는 것보다 더 큰 것들을 볼 수 있어야 하기 때문이다. 더 큰 것을 보기 위해서 우리가 우선시해야 하는 일은 지금 주어진 것들을 명확히 보고 이해하는 일이다. 그것이 내가 만들고 있는 소프트웨어이고 내가 만들어서 사용자가 쓰게 될 제품이다. 여기까지 제대로 하고 있다면 전문가라 불일 수 있다.
전문가는 자신이 하고 있는 복잡한 일을 중학생 이상의 수준이면 누구가 이해할 수 있도록 명쾌하게 설명할 수 있어야 한다. 복잡하고 전문적인 일의 체계와 제품이 적용된 실세계를 엉키지 않은 한 줄의 실로 풀어낼 수 있는 사람이 바로 전문가다.

5장. 팀워크 - 함께 만드는 소프트웨어

"프로그램의 구조는 그것을 제작하는 조직의 구조를 반영한다."
좋은 프로세스를 가진 회사가 좋은 플랫폼을 만들고 좋은 플랫폼이 좋은 소프트웨어를 만들어 낸다.
진짜 필요한 일은 결과를 만들어 내는 시스템을 바꾸는 것이다.

☻ 프로세스라고 명확하게 정해놓은 항목들이 없지만, 스스로 암묵적인 프로세스 속에서 일하고 있는데

이런 프로세스의 기준은 좋은 프로세스가 아닌, 해서는 안되거나 나쁘지는 않은 정도의 수준이 그치는 것 같다.

예전에 오너기반 이었을때에는 좋은 프로세스, 좋은 문화, 좋은 복지를 신경쓰고 있다는게 느껴졌는데

지금 투자회사의 자본금이 들어온 기반에서는, 단기성장과 EXIT 등 빠른 투자금 회수에 필요한 것만 신경쓰는게 느껴져서 아쉽다.

시간이 지난 지금 생각해보면, 그때 오너가 좋은 프로세스, 좋은 문화를 만든것도 장기적인 관점이었다기 보다는

잘 포장해서 판매하고 EXIT를 위한 밑작업이 아니었나라는 생각에 내가 너무 순진했었던것 같다.

코딩이나 글쓰기에서 명료성은 생명과도 같다.
오해를 불러일으키는 코드가 이해하기 어려운 코드보다 나쁘다.

☻ 코드 리뷰의 코멘트는 섬세하게!!

다른 쪽에서의 문제를 해결해 주기 위한 노력이 아닌, 자기 쪽에 문제가 없다는 것을 증명하려는 노력이 우세할 때 결국 프로젝트는 산으로 간다.

☻ 저연차때에는 내 쪽에 문제가 없다는 것을 확실히 하는게 나의 실력을 증명하고 높이는 거라 생각했는데,

확실히 연차가 쌓이고 전체를 바라봐야 하는 위치에 서다보니, 상대방의 문제를 해결해주는 것이

전체의 문제를 해결하는 빠른 지름길이고 이게 나의 전문성을 키워주고 내 능력을 인정받는 것임을 알게 되었다.

외부로 나가는 소통을 명료하게 하는 것, 외부로부터 받는 소통에 있어 최대한의 융통성과 관용을 보이는 것,
이 두가지를 두 글자로 표현하면 바로 '배려'다.

☻ 커뮤니케이션의 중요성! 상대방을 높이는 겸손과 배려가 사실은 나를 높여주는 결과를 가져온다.

2023년도 회고

뭐든창하 — Sat, 30 Dec 2023 14:02:50 +0900

연초에 한적한 커피숍에 자리잡고 잡았던 2023년 목표
중간에 휴직이라는 변수로 몇가지를 제외하고 크게 4가지 목표에 대한 회고

#Bible
1. 하루에 30분 성경읽기
그래도 3월까지는 어느정도 꾸준히 했는데, 4월부터 일이 많아지고 회사 매각에 어수선해지고 휴직하면서부터 달성하지 못함.

#Book
1. IT 도서 5권
[죽을 때까지 코딩하며 사는 법] 이거 한권밖에 못 읽음.
2. 일반도서 5권
5권의 책은 다 채웠는데... 보니 다 돈에 관련된 얘기들이었음;;
이 중에서 [세이노의 가르침]과 [협상의 기술1] 이 두권은 두세번 볼 가치가 있을만큼 추천할만 함!
* [세이노의 가르침]
* [돈 버는 사람은 따로 있다]
* [나는 나에게 월급을 준다]
* [부자는 20대에 결정된다]
* [협상의 기술1]
3. 기독도서 3권
한권도 못 읽었음;;

#Study
1. Spring Framework Deep Dive
다행히도 휴직중에 Spring Core 부터해서 MVC, Security, Data JPA, Boot 까지 깊게 한번 쭉 훑어보는 시간을 가질 수 있었음.
그동안 몇가지들은 머리속에 대략적인 개념들만 가지고 있었는데 이번 기회에 조금 더 깊게 들여다보고 각각의 퍼즐 조각을 하나로 합쳐서 그림 형태로 살짝 본 것 같음. DI 라는게 얼마나 속편한 얘기이면서도 동시에 편하지만은 않은 구현이라는걸 느낌.
2. Low Level Language 1개 학습
시작도 못해봄;; 아직도 Low Level Language 에 대한 자신감이 많이 없는 편..
3. 스터디 모임
2022년 연말의 스터디를 그래도 한번 해봤다고, 의욕만 앞선던가 아닌가 싶음. 이것도 하지 못함.

#Health
1. 건강검진 : 과체중, 지방간, 고지혈 지적 없애기
2023년 12월 20일 건강검진하고, (현재 12월 30일 기준) 아직 결과를 받지 못함. 결과 받고 업데이트 하자.
2. 몸무게 62kg, 체지방률 18%
10월 말 마지막 인바디 측정시, 몸무게는 3kg 감량(66.4kg → 63.6kg), 체지방률도 3.6% 감소(20.5% → 16.9%)
몸무게는 그 이후로 더 감량해서 오늘까지 61kg 유지하고 있어서 성공적으로 봄! 3개월 PT가 아니었으면 달성하지 못했을 것 같다.

3. 야구 : (타자)타율 2할 초과, 삼진 10개 이하, 사사구 20개 이하, (투수)5이닝 이상 투구
어깨 수술이후 재활중의 복귀로 투수로는 경기 참여가 없었고, 타자로는 그 전보다도 성공적인 복귀!! 레슨장을 간것도 아니고 특별히 연습한 것도 없는데 신기함! 타구가 그래도 중견쪽으로 가는 거 보니 타이밍이나 배트 포인트는 나쁘지 않아 보임.

#종합회고
꾸준히 해야 달성할 수 있던 목표들이었는데, 회사의 매각으로 인한 어수선함으로 흐름이 끊기고, 지친 심신으로 년초 계획에 없던 3개월 휴직으로 인해 어느 정도 계획을 수정하긴 했지만 그래도 꾸준함이 부족해서 많이 달성하지 못한것 같다.
특히 휴직 복귀 이후에는 Senior Engineer 로써의 역할에 집중하다보니 개인 시간내기가 더 어려워진 것도 한 몫 한것 같다.

그나마 헬스를 꾸준히 하게되면서 체력이 받쳐주니 그 전보다는 집중력이 오래가고 쉽게 지치지도 않아서 견뎌낼 수 있었지 않았다 싶다.
나이가 들수록 운동의 중요성을 다시 한번 느끼게 되었다.

도서의 경우에는 독서록을 잘 기록해 놓아야 겠다. 한번 읽고 잊혀지기 보다는 생각날때 한번씩 되새길 수 있게 잘 정리해 놓자.
공부는 이 업계에 몸 담근 순간부터 끝이 없다는건 인정했지만, 정말 따라가기가 벅찰 정도로 새로운 기술과 개념들이 쏟아져 나온다.
새로운 기술과 개념들에 마스터가 되긴 어려워도 적어도 개념은 뒤쳐지지 않게 따라가야, 적어도 이게 지금 시점에 필요한 것인지 아니면 앞으로 필요하게 될 것인지 정도는 체크할 수 있도록 챙겨야 겠다.

휴직을 기회로 "뭐든 새로운걸 해보자" 라는 마인드를 갇게 되면서 이것저것 해보는게 좋았다.
* 해파랑길 걷기 - 총 50코스중 35코스 완주
* 스쿠버 다이빙 해보기 - PADI Advanced Open Water Diver 자격증 따기
* Youtube 영상 올려보기 - https://www.youtube.com/@tryanythingchris
이게 너무 좋았다. 새로운걸 해보면서 삶의 활력소가 된다고 할까! 앞으로도 실패해도 좋은것들은 뭐든 해보자!

하나님의 자녀로서 세웠던 목표는 이루지 못했지만 기쁘게 마무리 할 수 있을 것 같다.
휴직기간동안 개인적으로는 주님과 조금 더 가까워지지 않았나 싶은데..주님이 보시기에는 혼자만의 착각일수도..
처음 도담교회 다니면서 살짝 발만 걸쳤던 방송부 미디어쪽 일을 몇년 하다가 지쳐서 쉬고 그렇게 코로나로 몇년이 지나고, 올초에 코로나도 한풀 꺾이면서 마음 한켠으로는 이제 뭐라도 해야 할 것 같은데 약간 두려움이 있어서 선뜻 나서지 못하고 있었는데, 뜻하지 않는 순간에 생각지도 못한 주님의 자녀를 통해 다시금 봉사와 헌신의 자리로 이끌어 주심에 봉사로 한해를 마무리 할 수 있게 되서 감사드릴 뿐이다.
주일예배와 성탄축하예배, 성탄절예배가 연달아 진행되면서 영혼이 털릴정도로 정신없이 보냈는데, 이번주도 주일예배와 송구영신예배로 정신없지만 주님을 위해 헌신하는 마음으로 한해를 마무리 할 수 있어서 기쁘다.

허브 코헨의 협상의 기술 #1

뭐든창하 — Sun, 26 Nov 2023 22:00:12 +0900

총 2권의 책으로 이루어져 있는데, 1권이 필독이고 2권은 그다지 추천하지 않는다고 해서 1권만 사서 읽었다.
보통 책을 읽고 나서 마인드맵으로 정리하고는 하는데, 이 책은 마인드맵으로 똑같이 책을 다 써야 할 것 같아서 정리를 포기하고 6개월마다 한번정도는 빠르게 속독해서 탐독하는게 좋겠다고 생각했다.

나이가 들수록 모든 것이 협상의 가운데 있고, 상대방이 없는 스스로의 선택도 한편으로 나와의 협상이라고 느껴지게 되었다.
매번 협상에서 승리하는 쪽에 있을수는 없겠지만, 적어도 지금이 협상의 한 가운데에 있는 상황이구나 인지는 할수 있어야 겠다 생각이 들었다.

#협상을 좌우하는 3가지 변수
1. 힘 : 당신에게 힘이 있다는 사실을 인지하라.
2. 시간 : 협상은 인내심 싸움이다.
3. 정보 : 상대가 말하지 않는 정보까지 캐내라.

나는 아마존에서 미래를 다녔다

뭐든창하 — Thu, 6 Jun 2019 17:38:04 +0900

구매하고 바로 읽고 싶었지만, 한달이 지나서야 읽게 되었다. 제목만 보고 호기심에 구매했는데, 저자가 아마존에서 12년이나 다녔다니, 아마존이라는 최고의 기업에서는 어떻게 일을 해야하는지 궁금했던것이 제목만 보고 느꼈던 호기심이었다. 책을 구매하고 나서야 큰 제목의 윗부분에 적혀있는 작은 글씨를 보게 되었는데, 그 중에서도 "평균 근속 1년"이라는 문구가, 이 책을 사기 전과는 전혀 다른 호기심을 들게 만들었다.

매일받는 지원자의 이력서만 해도 5000건이 넘고, 전체 직원수는 65만명이 되어가는 상황에, 평균 근속 1년이라는 굉장히 짧은 기간에 직원들이 들어오고 나가고 하면서도, 조직과 프로세스들이 어떻게 구성되어 있길래 오히려 최고의 기업이 될 수가 있는지가 처음의 호기심보다 더 궁금하게 되었다.
어느정도 정규화된 체계를 통해 통제하는 편으로 운영해나가는 방식이 통할리 없는 미국의 IT기업에서, 더욱이 구글이나 애플처럼 직원복지의 혜택을 엄청나게 받지 못하는 아마존이라고 누구나 알고 있는데 최고의 기업이 되었다니, 궁금하지 않을 수가 없는데 마침 12년이나 근무한 한국인 직원의 입장에서 쓰여진 아마존의 이야기는 꽤 흥미로울 수밖에 없었다.

사실 제일 궁금했던 것은 현실적인 경험에 비춘 해결책을 얻을 수도 있지 않을까 해서였다.
매너리즘에 빠지고, 회사의 정치에 신물나고, 정책에 불평불만이 늘어나고, 열심히 일한 동료들과 그렇지 않은 동료들의 차이가 없어지고, 위기의식에 대해 공감하지 못한 상황들에서, 어떤 방식이어야 예방할 수 있는지, 발생한 문제점을 해결할 수 있는지...
모든 동료들이 서로 지켜나가고 싶어하는 비전은 어떤 기준으로 만들어야 하는지, 일을 하는 방식의 가치관은 어떻게 만들어야 하는지, 자신의 책임을 충분히 수행하지 못하는 사람들을 어떻게 빨리 찾아내고 어떻게 대처해야 하는지...이런 현실적은 해결책을 얻을 수도 있지 않을까 했다.

아마존의 내부 깊숙한 얘기는 없어 궁금중을 모두 풀지는 못했지만, 저자의 말처럼 일과 삶을 설계하는 법에 대해서 나 스스로 어떤 기준을 만들어 나가야 하는지도 조금은 도움이 되었다.

#1. 여정의 시작

@인테그리티가 중시되는 회사
동양에서 예의라고 배웠던 것들은 찾아보기 힘든 아마존이었지만 보이지 않는 다른 규치들이 있었다. 우선 그들 대부분은 둘러대는 거짓말을 하지 않았다. 문제가 있으면 있는 그대로 돌직구로 말하는 업무상의 커뮤니케이션도 마찬가지였다. 말도 이메일도 '사실대로 요점만 간단히' 말하는 아마존의 언어는 이런 나에게 꽤나 낯선 문화였다. 또한 뒤에서 상사나 다른 사람을 험담하는 행위는 질 낮은 취급을 받는 분위기였다. 물론 사람이 모여 있는 곳이니 모두가 항상 잘 지낼 수는 없지만 아마존은 어려움과 불만을 이야기할 수 있는 정식 창구가 따로 있었다. 매니저의 가장 중요한 업무 중 하나인 1 on 1 미팅은 별다른 포맷 없이 매니저가 매주 한 시간가량 한 명의 팀원과 단 둘이 이야기하는 것이다. 주로 앞으로의 계획을 함께 짜거나 회사 내의 고충을 이야기하는데, 누군가 때문에 불만이 있다면 매니저에게 가감 없이 말할 수 있다. 뒤에서 남을 욕한다는 측면에서는 크게 다를 것이 없지만 목적이 감정 해소가 아닌 문제 해결이라는 점에서 차이가 있다.
한마디로 아마존은 기본적으로 예의나 복장, 어투, 태도보다는 능력과 다양성 그리고 인테그리티(integrity)가 중시되는 사회였다. 인테그리티는 미국에서 많이 사용되지만 한국어로는 한마디로 번역하기가 쉽지 않은 단어로, 간단히 정의하면 '아무도 보고 있지 않아도 옳은 일을 하는 것(Doing the right, even when no one is watching)'이다. 위로부터 강요되는 권이에 따르거나 남의 눈을 의식하기보다는 스스로 지킬 것은 지키고 할 말은 하는 분위기가 어색하지만 묘한 매력이 있었다.
@원칙이 정말로 지켜지는 곳
생각해보니 내가 살아온 사회는 '말 따로, 행동 따로'인 경우가 많았다. 원칙은 거창하지만 그걸 진짜 믿고 지키면 바보가 되는 사회였다. 교실에 걸려 있던 '정직하게 최선을 다하자' 같은 급훈을 친구에게 인용하다가는 시답잖은 취급을 당할 게 뻔했다. 그런데 아마존의 원칙은 진짜였다. 이곳 사람들은 그 원칙을 정말 믿었고 그대로 행동하려고 노력하고 있었으며, 그것이 이상하거나 유치한 행동이 아니었다.

#2. 아마존의 문화, 공간 그리고 사람들

누군가가 "바보 같은 질문 하나 해도 될까요?라고 시작한 질문을 하고 나면 많은 경우 "그건 사실 굉장히 좋은 질문이네요 That's actually a very good question"라는 말과 함께 대답을 시작한다. 아마존은 잘 모르는 것을 아는 척하는 것이야말로 바보 같고 잘못된 일이라고 생각한다. 오히려 몰라서 질문한 사람은 많은 경우 감사의 대상으로 여겨진다. 왜냐하면 그 사람의 용기 덕분에 모르면서도 가만히 있던 사람들도 혜택을 받았기 때문이다. 이런 질문들을 통해 구성원 모두의 이해가 높아지고 서로 간의 오해는 줄어든다. 단순히 서로를 아이디로 부르는 것이 아니라 구성원 누구나 자기 목소리를 두려움 없이 낼 수 있는 문화가 수평문화가 아닐까?

#5. 본질을 보는 눈과 머뭇거리지 않는 발

베조스 회장은 파워포인트 프레젠테이션은 발표자게에는 편리하고 청중에게는 어려운 방식이라고 말한다. 발표자는 자신의 화술에 따라 강조할 부분을 부각하고 은근슬쩍 너어갈 부분은 적당히 감출 수 있다. 전체 내용의 일부만이 슬라이드로 청중에게 재단되어 전달되기 때문에 정확한 내용을 알기 위해서는 중간중간 질문이 필수적인데 이런 질문들은 미팅의 흐름을 방해하기 일쑤다. 또한 발표자의 역량이 내용을 좌우하며 실제로는 그렇게 대단하지 않은 내용이 멋지게 포장될 수도, 반대로 아주 좋은 내용이 제대로 전달되지 않을 수도 있다. 또 청중들이 각기 다른 내용으로 이해해서 차후에 불필요한 오래가 발생하기도 한다.

반대로 모든 내용이 글로 표현되는 6페이저는 발표자에게는 어렵고 청중에게는 편한 방식이다. 빠르면 몇 시간 안에 준비되는 파워포인트 슬라이드와 달리 6페이저를 작성하는 데에는 보통 몇 주가 걸린다. 시간 낭비처럼 보일 수도 있지만 발표자는 꼼꼼하게 생각하고 조사하고 쓰고 고치는 작업을 반복하며 스스로 주제에 대한 명확한 내용을 글로 정리하게 된다. 흘러가는 말과 달리 온전한 문장으로 쓰인 글에는 도저히 숨을 곳이 없기 때문이다.

프로포절 형식의 6페이저 구조
1) 배경과 질문
2) 질문에 답하기 위한 접근 방식(누가, 어떻게, 그리고 예상되는 결과)
3) 접근 방식 간의 비교
4) 앞으로 취할 행동, 그리고 그 결과가 어떻게 고객과 회사에 혁신을 가져올 것인지에 대한 설명

이렇듯 어렵게 준비한 문서를 미팅 참여자 수만큼 프린트하여 가져가면 아마존 사원들에게는 익숙하지만 다른 이들에게는 생소한 광경이 펼쳐진다. 처음 15~30분 동안 서로 아무 말도 하지 않는 미팅이 시작되는 것이다. 참가자들은 간단히 서로 인사를 하고는 바로 프린트된 문서를 집어 들고 읽기 시작한다. 중간에 질문이 있거나 잘 이해가 가지 않거나 다른 의견을 가지고 있더라도 바로 묻지 않고 각 페이지에 펜으로 메모하며 끝까지 읽는다. 슬라이드 형식과 달리 끝까지 읽는 동안에 스스로 적었던 질문들이 뒷부분에서 답변이 되는 경우가 많기 때문에 앞의 메모들을 중간중간 고치기도 한다.

모두가 내용을 다 읽고 메모를 마치면 첫 번째 페이지로 돌아가서 내용 순서에 따른 활발한 논의가 시작된다. 내용은 이미 글로 설명되었고 읽은 후이기 때문에 내용에 대한 설명을 따로 할 필요는 없다. 참가자들은 각자 자신이 메모한 질문이나 생각을 자유롭게 발언하며, 모두가 처음부터 끝까찌 동일한 내용을 숙지한 상태에서 활발한 토론이 이루어진다. 발표자가 주도적으로 내용을 전달하고 질문을 받는 프레젠테이션 형식의 회의가 아니라 전체가 다 함께 참여하여 본질, 곧 관련 안건이 회사와 고객에 미칠 긍정적 영향과 혁신에 대한 심도 있는 회의가 진행되는 것이다. 발표자는 6페이저에 포함되지 않은 내용에 대한 질문들을 관련 자료를 토대로 대답하며 수동적으로 회의를 주도한다.

#6. 극강 효율 아마존식 솔루션

아마존에서는 회사 규정으로 사원이 사내 이직을 희망할 시에 매니저가 적극 도와야 한다고 명시되어 있다. 그리고 워낙 들어오고 나가는 사람이 많은 터라 아마존은 그 흐름을 막기보다는 사람이 바뀌어도 큰 문제가 없는 시스템을 구축하는데 더 노력한다.

#7. 정글에서 터득한 생존법

하나의 질문에 대한 답을 찾는 것은 아주 작은 한 걸음만큼의 일을 하는 과정이다. 질문은 '이제 뭘 해야 하지?' 같이 아주 바보 같고 단순해도 좋다. 스스로에게 하는 질문이니 아무런 거리낌 없이 편하게 질문하고 그에 대한 답을 하기를 반복한다. 그리고 이 대화 과정을 순차적으로 쭉 기입한다. 글이 있기 전에 말이 있었고 대화야말로 가장 원시적으로 자연스러운 말의 형태라서 이렇게 하면 물 흐르듯이 자연스럽게 일이 진행되는 것을 경험할 수 있다.

8. 아마존의 가장 큰 가르침, 나로 서기

베조스 회장의 '후회 최소화 프로임워크 Regret Minimization Framework'에 대해 듣게 되었다. 이것은 2010년에 자신의 모교인 프린스터대학의 졸업 축사에서 한 이야기인데, 쉽게 말하면 '인생의 갈림길에서 어떠한 선택을 할 것인가?'에 대한 그의 삶의 공식이다. 샤르트르 Jean Paul Sartre가 인생은 B(birth)와 D(depth) 사이의 C(Choice)라고 말한 것과 같이 그 또한 "결국 우리는 우리가 한 선택 그 자체라고 이햐기 한다.

B급 세계사 - 알고 나면 꼭 써먹고 싶어지는 역사 잡학 사전

뭐든창하 — Mon, 27 May 2019 23:05:03 +0900

중.고등학교 시절에는 그렇게도 역사를 싫어했는데, 그 시절에는 단순히 외워야 하는게 너무 싫었던 것 같다.

이제 나이를 먹고 지금에서야 역사가 굉장히 재밌는 이야기들이라는걸 느끼게 되었는데, 어린시절을 비교해서 생각해보니 두가지 정도 원인을 생각해 볼 수 있을 것 같다.

첫째, 역사적인 사건의 앞 뒤 상황에 대한 정보를 취득 할 수 있는 경로가 많다.

중.고등학교 시절에는 역사적인 연도와 사건을 매칭시켜, 단순히 1894-갑오개혁, 1895-을미개혁 이렇게 매칭시켜 외우기만 했다. 역사라는게 그 사건이 일어난 배경과 그 사건으로 인해 무엇이 어떻게 변화되었는지를 흐름을 알게 되면, 단순히 연도-사건 매칭시켜 외우는 것보다 훨씬 오래 기억에 남을 수 있을텐데, 그 시절에는 역사적인 사건의 앞 뒤 정보를 알 수 있는 경로가 교과서, 책이 거의 대부분이었고 PC통신이 있었지만 검색의 한계가 존재했다. 그런 반면, 지금은 갑오개혁 한단어만 검색해도 유투브에서 명강의를 쉽게 찾을 수 있다.

이러한 앞 뒤 상황에 대한 이해를 통해 흥미롭게 알게 된 사실 한가지는, 서양과 동양의 과학/예술의 발전 흐름에 대한 이야기다. 굉장히 흥미로운 이야기라 사석에서만 얘기해주고 싶다. ㅎㅎㅎ

둘째, 나이가 드니, 왜 그랬어야 했는지 사람을(또는 선택을) 이해하게 되었다.

대부분의 사춘기 청소년들이 그러하듯 나 또한 그 시절에는 "왜 어른들은 그럴까?"라는 질문을 많이 가지고 있었다. 언제나 항상 올바르고 정당한 판단과 선택을 하지 않는 어른들을 보며 답답함을 느꼈으나, 어른이 되어보니 상황과 환경과 이득에 따라 항상 올바르고 정당한 판단과 선택을 한다는건 굉장히 어렵다는걸 느끼게 된다. 또한 그 선택이 당시에는 최선의 올바른 선택이었다 하더라도, 시간이 지나며 상황의 변화나 가치관의 변화에 따라 후세들이 판단하는 그 결과는 올바르지 않은 선택이었다는 결론을 내보낼 수 있다는 것도 알게 되었다. 이렇게 머리가 커지고 나니, 역사적인 사건의 중심인물이 어떤 마음과 생각을 가지고, 왜 그러한 선택을 했는지 조금은 이해하게 되었다. 그리고 이런 이해를 통해 역사적인 사건이 언제 누구에 의해 일어났는지를 굳이 외우지 않아도, (이해가 되서 장기 저장되어 있는) 기억속의 에피소드에서 손쉽게 끄집어 낼 수 있는 것 같다.

그때 그 시절에, 역사를 단순히 외우는 과목이 아닌, "그 시절이 그 사람이 왜 그런 선택을 했을까"라는 의문을 가지고 접근했었다면, 난 지금과는 다른 길을 가고 있었을까?

열두 발자국

뭐든창하 — Sat, 4 May 2019 18:49:07 +0900

지하철 알람이 아니었다면 여러번 환승역을 지나쳤을 정도로, 몰입도 있게 본 책이다.

내용자체도 흥미로웠지만, 책 내용의 거의 대부분이 이해하기 쉽게 쓰여져 있어 술술 넘어갈 수 있었다.

이 책을 읽으면서 생각해보니, 나도 굉장히 과학적인 일을 하고 있음에도 과학은 정말 어렵고, 일상생활과는 관계없는 어떤 학문적인 분야라고만 생각했던 선입견을 가지고 있던것 같다.

내가 하고 있는 일도 다른 분야의 사람들이 보기에는 그냥 컴퓨터로 일을 하는 것으로만 알지, 그 안에서 굉장히 많은 전문 분야가 나뉘어져있다는 사실을 모르는것처럼, 나 또한 과학은 아인슈타인등과 같이 어떤 법칙을 발견하기 위한 학문적인 분야라고만 생각했다. 적어도 이 책을 보기 전까지는 말이다.

오래전 알.뜰.신.잡 시즌1에서 정재승 뇌과학자가 나오면서, 굉장히 재밌는 분야의 연구를 하는 굉장한 분이라는걸 느꼈고, 이어진 블록체인에 대한 유시민 작가님과의 100분토론으로 이분에 대해 호감을 가지게 되었는데, 이 책을 보면서 정재승 이라는 분이 어떤 철학과 관념을 가지고 연구하고 사람들에게 이야기하는지, 이 분의 다음 책도 궁금해졌다.

내가 어렵게 공부하고 연구해서 알게 된 지식을, 다른 사람들에게 쉽게 이야기 해주는 능력이 나이가 들면 가장 필요한 항목중 하나가 아닐까 싶다.

# 두 번째 발자국 : 선택의 패러독스

'선택의 패러독스(the paradox of choice)'라는 현상이 있습니다. 선택지가 많을수록 우리는 더 나은 의사결정을 할 것 같지만, 실제로는 오히려 만족스러운 결정을 방해한다는 현상이지요.

선택지가 많으면 구경하는 재미는 있지만, 내 선택에 대한 불신이 높아지고 선택하지 않은 것에 대한 미련이 커지기 때문에, 구매로는 쉽게 이어지지 않는다는 겁니다. 선택지가 늘어나면 처음에는 새로운 선택지를 발견할 때마다 좋은 감정이 커집니다. 그런데 선택지가 점점 늘어날수록 나쁜 감정이 커져서, 어느 숫자를 넘어가면 오히려 만족도가 현저히 떨어집니다. 그 기준점이 보통 6~10가지 정도라고 해요. 사람들이 6~10가지 선택지 안에서는 최대한 적절한 선택을 하려고 노력하는데, 그걸 넘어가버리면 선택이 고통스러워진다는 거죠. 보통 3~6가지 정도의 선택지를 주는 것이 가장 무난합니다.

# 두 번째 발자국 : 패자부활전 없는 사회, 실패에 대한 두려움

왜 특히 요즘에 와서 결정장애가 더 사회적인 이슈가 됐을까요? 저는 그것이 '사회적 안전망의 부족'과 관련이 있을 거라 생각합니다. 옛날에는 한 번 잘못된 선택을 해도 재기할 수 있는 사회적 안전망이 어느 정도 갖쳐줘 있었습니다. 좋은 대학을 못 가도, 대학에서 놀거나 취미생활에 빠져 성적이 안 좋아도 취직 걱정이 적었고, 어떤 시기를 놓쳐도 늦게라도 결혼 할 수 있었지요. 그런데 요즘은 사회에서 요구하는 기준을 제때 딱딱 맞추지 못하면 완전히 낙오되기 때문에, 패자부활전이 점점 줄고 있어요. 한 번 미끄러지면 재기가 불가능한 사회에서 젊은이들로서는 매번 굉장히 신중하게 선택해야 하는 상황에 놓인 거에요. 실패에 대한 두려움이 만연해 있꼬 사회안전망이 부재한 상황이 사람들의 결정을 더욱 어렵게 만드는 것은 아닌가 싶습니다.

# 다섯 번째 발자국 : 뇌가 에너지를 절약하는 방법

뇌를 쓰려면 많은 에너지가 들기 때문에, 되도록 습관적인 선택을 통해 인지활동에 에너지를 쓰지 않으려 노력합니다. 몸도 마찬가지입니다. 왜 사람들은 그토록 운동을 싫어하는 걸까요? 몸을 움직여서 에너지를 쓰는 게 너무 싫기 때문이에요. 왜 우리는 생각하기 싫어할까요? 생각을 하려면 뇌가 에너지를 많이 쓰기 때문에 그게 귀찮은 겁니다. '어떻게 하면 에너지를 안 쓰고 세상을 살까'가 사람들의 생존 전략입니다. 자기가 좋아하는 일에 대해서는 기꺼이 그 에너지를 투자하지만, 별로 중요하지 않다고 생각하는 일에 대해서는 습관이라는 방식으로 에너지를 최소화합니다.

# 다섯 번째 발자국 : 20퍼센트쯤 열어두는 삶

인생의 목표가 성공이 아니라 성숙이라면, 우리는 날마다 새로운 삶을 살기 위해 노력해야 합니다.

# 여섯 번째 발자국 : 미래를 미리 알면 행복할까

행복은 예측할 수 없을 때 더 크게 다가오고, 불행은 예측할 수 없을 때 감당할 만하다. 다시 말하면 우리는 미래를 예측할 수 없기에 더 크게 누리고 불행은 감당할 수 있는 존재가 되는 겁니다.

# 여섯 번째 발자국 : 회의주의자로 살아가기

일견 모순적으로 보이는 두 가지 태도를 모두 필요로 합니다. 하나는 어떤 가설이든 쉽게 믿지 않고 철저하게 의심하는 태도입니다. 이게 과연 맞을까, 이걸 내가 믿어야 할 근거는 충분한가, 혹시 잘못된 것은 아닐까 의심하고 회의하는 태도이지요. 그럼에도 불구하고, 그런 회의주의적인 태도가 진실을 외면하는 어리석음이 되어서는 안 됩니다. 세상에선 어떤 일도 벌어질 수 있고 실제로 가능하다는 열린 태도도 필요합니다. 무언가를 처음부터 '이건 절대 말이 안 되는 것', '비과학적인 것'이라고 단정짓고 어떤 것도 받아들이지 않는 태도는 진실을 외면하는 도그마에 빠질 위험이 있습니다. 그래서 과학자는 이 두 가지 태도를 모두 지녀야 합니다. 이 두 태도를 모두 가지고 있는 사람은 멋있습니다. 이런 태도는 훌륭한 과학자의 길로 인도할 뿐 아니라 누구나 성숙한 삶으로 이끌어줍니다. 새로운 생각을 받아들일 수 있게 해주면, 고정관념에 사로잡히지 않고 편견에 빠지지 않고 세상을 냉정하게 바라보도록 도와줍니다. 그런 면에서 꼭 과학도가 아니더라도 늘 꼼꼼히 따져보고 의심하는 동시에 어떤 것도 가능하다는 열린 태도를 함께 견지하는 것은 우리 모두가 가져야 할 태도가 아닌가 생각합니다.

# 일곱 번째 발자국 : 창의성은 상대적이고 문화적인 것

창의적인 존재가 되려면 우리는 어떻게 사고하고 행동해야 할까요? 남과는 다른 생각을 갖고 있거나 다른 관점에서 문제를 바라보는 사람들과 자주 지적인 대화를 나누어야 합니다. 비슷한 생각을 하는 사람들끼리 모여서 아무리 논의해봤자 창의적인 아이디어가 잘 안 나오는 겁니다. 나와 다른 경험을 한 사람, 나와 다른 분야에서 전문지식이 있는 사람, 나와 다른 관점에서 문제를 보는 사람들과의 지적인 대화를 즐기세요. 여러분의 인지적인 사고가 확장되는 경험을 하게 될 것입니다.

# 일곱 번째 발자국 : 세상과의 의미 있는 충돌을 경험하라

아무리 강조해도 지나치지 않는 것이 독서, 여행, 사람 만나기입니다. 안 하면 나중에 후회하는, 특히 평생에 거쳐 반드시 해야하는 것들이 바로 독서, 여행, 사람들과의 지적 대화입니다. 다시 말해 끊임없이 세성으로부터 자극을 받으시라는 겁니다. 의미 있는 세상과의 충돌, 이것이 우리의 인생을 바꿉니다. 이 세 가지는 자기가 직접 물리적 환경에서 경험할 수 없는 것들을 간접적으로 경험할 수 있게 해줍니다.

# 아홉 번째 발자국 : 아날로그의 반격

아날로그 경험 자체가 중요한 것이 아니라 아날로그든 디지털이든 대면접촉과 사회적 관계 맺기를 증진시키는 경험이 중요한 거지요. 어릴 때부터 친구가 아니어도 재미있게 살 수 있다는걸 충분히 경험한 세대는 관계 맺기에 서툴고 타인과의 대화, 논쟁, 화해, 설득의 경험이 부족합니다. 젊은 세대들이 이별 통보를 문자메시지로 하는 건 매너가 없어서가 아니라 얼굴을 마주하고 이별을 말할 사회성이 부족해서인 것처럼 말입니다.

주말 내내 잤는데 왜 월요일이 피곤할까?

뭐든창하 — Wed, 17 Apr 2019 23:50:22 +0900

지하철 책읽기 시리즈..

애들이 어렸을때는, 밤에도 중간중간 깨서 돌봐야했고, 어느정도 커서도 엄마/아빠랑 같이 자겠다고 늘 옆에 재우다보니 깊은 숙면이라는건 어쩌다 맞이하게 되는 선물같은 존재인것 같다. 이번 춘천여행 이후로 자기들 방에서 자기로 약속했으니 잠을 잘 자기 위한 책을 읽어봐야 겠다고 생각해서 보게 되었다.

예전에 九四日生이라는 글을 통해 아침형 인간이 되어보자 했던적이 있었는데, 이 책을 보니 왜 그리 힘들었었는지 알게 되었다. 혼자 지켜나가기에는 가족 구성원과 함께하는 리듬에는 힘든 시간규칙이었고, 아침에 일어나서 바로 햇빛을 볼 수가 없는 기상시간이기도 하다.

주기적인 수면 시간과 자기전/후의 동일한 패턴을 유지하는게 포인트다!

@머리말

이전에는 철야나 단시간 수면을 내세우는 풍조가 있었지만, 이제는 아무도 그런 것을 자랑하지 않는다. 지금은 자신의 몸을 철저히 관리해 생산성과 효율성을 높이는 것이 보다 중요한 비즈니스 스킬이다.

@잠이 쏟아질 때는 업무 도중에 잠깐 눈을 붙인다.

가능한 한 편안한 자세로
시간은 30분 이내로
직전에 커피 마시기
1. 카페인의 효과가 나타나는 것은 섭취하고 나서 20~30분 후

@쾌면을 위해 운동복보다 잠옷을 입는다.

아침에 기상했을 때 '아아, 잘 잤다!' 하고 만족할 수 있을지 여부는 주로 잠드는데 걸리는 시간과 중도 각성의 횟수로 결정된다.

잡옷을 입는 효과는 크게 두 가지로 나눠 볼 수 있다. 하나는 의복으로서 잠옷의 효용, 또 하나는 '취침 모드'로의 전환 효과.

"취침 1시간 전까지 샤워를 끝내고 잠옷으로 갈아입으세요. 그리고 거실 조명을 낮추고 느긋하게 시간을 보냅니다. 그러면 체온이 내려가면서 자연스럽게 졸음이 오게 되지요. 이 세가지 의식을 매일 습관처럼 실천하면 쉽게 잠들 수 있을 거에요."

@일찍 자고 일찍 일어나는 것보다 '일찍 일어나고 일찍 자기'

일정한 시간에 일어난다.
휴일의 늦잠은 2시간 이내로(2시간을 넘지않게)
침대에 머무는 시간은 가능하면 짧게
1. 아침에 눈을 뜨면 바로 침대에서 나온다.
취침 전 스마트폰 사용, 목욕 시간, 음주에 주의
1. 취침 전 2시간 전부터는 일절 보지 않는 것이 이상적.
2. LED의 블루라이트가 멜라토닌이라는 수면 유도 호르몬의 분비를 억제하고 교감신경을 자극해 정신을 각성시킴
햇빛과 아침 식사가 체내시계를 정비한다.

@잠자리에서 수면 이외의 다른 일을 하는 것은 NG

침실에서 책을 읽는다
1. '침대는 책을 읽는 곳', '침대는 TV를 보는 곳'으로 뇌가 착각하게 되고, 그것이 숙면을 방해한다.
2. 따라서 졸리지 않으면 잠자리에 들지 말아야 하고, 수면 이외의 행위는 되도록 하지 않아야 한다. 그렇게 해서 '침대는 잠자는 곳'으로 뇌에 각인시키는 것이다.
일찍 일어나기 위해 졸리지 않는데도 일찍 잠자리에 든다.
1. 인간은 기상 후 빛을 보고 나서 16시간이 지나면 잠이 오게 되어 있다. 억지로 빨리 자려고 해도 마음대로 되지 않는다.
기상시간에 관계없이 같은 시간에 잠자리에 든다.
1. '취침 시간이 아닌 기상 시간을 일정하게 유지하는 것'이 더 중요하다.
퇴근 전철에서 수면 부족을 보충한다.
1. 저녁때는 졸려도 참자

@세 종류의 생체 리듬을 정비한다.

기상 후 4시간 이내에 빛을 본다. (멜라토닌 리듬 정비)
1. 잠에서 깬 후에는 1시간 이내에 아침 햇빛을 보는 것이 가장 좋다.
기상 후 6시간이 지나면 낮잠 타임. (수면-각성 리듬 정비)
1. 아침에 눈을 뜨고 나서 첫 번째 졸음이 찾아오는 것은 8시간 후이다.
기상 후 11시간이 지나면 몸을 움직인다. (심부 체온 리듬 정비)
1. 아침 기상 후에는 체온이 올라가기 시작해서 11시간이 지나면 체온이 가장 높아진다. 이 타이밍에 운동을 하면 체온이 더 올라가고 수면을 취할 때 더 잘 내려간다.

@아침 식사를 거르면 시차병에 걸린다.

아침 식사는 하루 중 가장 길게 단식한 뒤 섭취하는 음식물. 영어로 아침 식사를 나타내는 breakfast는 단식(fast)을 부순다(break)의 의미.

따라서 단식 이후의 음식물 섭취는 하루를 시작하는 스위치를 눌러 체내시계가 시작시점으로 리셋된다.

만약, 정오의 점심 식사 후 밤 10시에 식사를 하면 그것이 하루 중 가장 긴 단식 후 첫 식사가 된다. 그래서 밤인데도 아침의 스위치가 켜져 체내시계가 리셋된다. (저녁식사를 늦게 하면 체내시계가 저녁형으로 바뀐다)

@주말 늦잠이 병의 원인이 될까?

평일에 일찍 자고 일찍 일어나는 규칙적인 생활을 하다가 주말에 밤늦게까지 자지 않고 아침엔 늦잠을 자는 등 취침과 기상 시간이 달라지면 체내시계가 혼란을 일으켜 시차병과 같은 증상이 나타납니다. 이런 상태는 '사회적 시차병(Social Jetlag)이라 불리며, 주말만의 혼란으로 가볍게 치부하기 쉽지만, 몸에 미치는 악영향은 결코 무시할 수 없다.

@베개와 요를 잘 고르면 한여름에도 쾌면이 가능하다

머리는 차고 발은 따뜻하게
1. 두한족열(頭寒足熱)이라는 말이 있듯이 머리는 시원하게, 발은 따뜻하게 해주면 잠이 잘 온다.
목을 따뜻하게 하면 편안해진다.
1. 머리는 차게, 목은 따뜻하게
등을 시원하게
'안는 베개'를 안고 옆으로 누워 자면 바람이 잘 통한다.
취침 전과 후에 에어컨의 설정 온도를 바꾼다.
1. 자기 전 : 25C 정도로 매우 낮게 설정해 방을 충분히 시원하게 만든다.
2. 잘 때 : 도중에 깨어나지 않을 정도의 온도(26C~29C)로 유지

@액정 화면은 취침 2시간 전까지만 본다.

"잠들기 전에 이불 속에서 스마트폰을 만지작 거리는 사람이 많은데, 가장 나쁜 습관이에요. 방의 전등을 끄고 있으면 화면의 블루라이트만 보이기 때문에 수면의 질이 나빠지는 데다, 당연히 눈에도 좋지 않습니다."

@최적의 수면 시간은 일정하지 않다.

수면 시간은 의식적으로 제어할 수 있는게 아니다. 수면 시간은 개인차도 있지만 계절에 따라 달라지기도 한다.

"수면 시간을 제어하고 싶은 마음을 모르는 건 아니지만, 엄격하게 관리하려 할수록 오히려 불완전한 느낌이 심해질 뿐입니다. 아침에 일어나는 시간만 분명히 정해 두고 취침 시간은 그날그날 상황에 맡기는게 제일이지요"

90년생이 온다

뭐든창하 — Sun, 31 Mar 2019 21:36:12 +0900

지하철 책읽기 시리즈..

70년대의 끝자락에 태어났지만, 행동은 80년대생들처럼 지냈고 마인드는 90년대생이라고 믿고싶다 ㅎㅎㅎ

어린친구들때문에 어려운점도 겪어봤지만, 그들의 특징중의 하나인 '정직함'은 현 시대에 많은 도움이 되는것 같다.

아래는 요약이라기보다는 몇몇 문장들을 적어놓은 것 뿐이다. 전체적인 맥락을 이해하기 위해서는 책을 읽어보는것을 추천한다.

@꼰대의 세상에서 살아남기

사전에서 꼰대란 은어로 '늙은이'를 지칭하거나 학생들의 은어로 '선생님'을 이르는 말이다. 그러나 오늘날에 꼰대라는 단어는 특정 성별과 세대를 뛰어넘어 '남보다 서열이나 신분이 높다고 여기고, 자기가 옳다는 생각으로 남에게 충고하는 걸, 또 남을 무시하고 멸시하고 등한시하는 걸 당연하게 여기는 자'를 지칭한다.

@공무원을 꿈꾸는 어린이들과 공딩족

'변한 것은 세대가 아니라 시대'라는 말을 통해 인간은 누구나 주어진 여건하에서 행복을 추가하는 존재이며, 요즘의 젊은이들 또한 저성장시대에 맞는 생존 전략, 행복 전략을 본능적으로 찾게 되는 것.

@버릇없는 젊은 놈들에게 무엇을 배울 수 있을까?

<한겨례> 인터뷰에서 "노인들이 저 모양이란 걸 잘 봐두어라"라는 촌철살인으로 화제가 된 채현국 효암학원 이사장은 오늘날이 '먼저 안 게 오류가 되는 시대'라고 말했다. 그는 "농경사회에서는 나이 먹을수록 지혜로워지는데, 자본주의 사회에서는 지혜보다는 노욕의 덩어리가 될 염려가 더 크다는 겁니다"라며, "지금은 경험이 다 고정관념이고 경험이 다 틀린 시대입니다. 먼저 안 건 전부 오류가 되는 시대입니다. 정보도 지식도 먼저 것은 다 틀리게 되죠"라고 말했다. 그의 말처럼 과거 경험이 이젠 판단의 기초 혹은 가르침의 근거가 되지 못하는 시대가 되었는지도 모른다.

@90년생의 세 가지 특징: 간단하거나

'간단하거나', '재밌거나', '정직하거나'

@모바일로의 변환, 90년대생에겐 하나의 삶

"신기술의 변화는 35세가 되기 전까지는 우리를 흥분시키는 데 반해 35세 이상에겐 당황하고 난처하게 만든다"라고 했다. 이를 2010년 이후 급격한 변환에 따라 맞춰서 생각해보면, 모바일로의 급격한 변화는 70년대생들에게는 일종의 재앙과 같았고, 90년대생들에게는 일종의 도전이었으며, 90년대생들에게는 새로운 삶으로 다가왔음에 틀림없다.

@앱 네이티브의 시대: 비선형적 사고로의 대전환

어렸을 때부터 인터넷이 주는 풍요를 누리고, 이후 24시간 온라인에 연결되어 있는 앱 네이티브들에게는 어느 때보나 유연한 사고방식이 필요하게 되었다. 그들에게 조용하고 집중적인 기존의 선형적 사고는 구식에 지나지 않는다. 그들에게는 온라인상으로 제공되는 축햑된 정보를 빠르게 흡수하고, 필요할 때 바로 찾는 비선형적인 사고방식이 중요하게 되었다.

@재미를 통한 자아실현이 기본이 된 90년대생들

현대 직장인의 지상 최대 고민은 정확히 다시 고쳐 말하면 '오늘 점심은 뭐 먹지?'이다. 그러나 그 고민의 중심은 '끼니를 때울 수 있을까?'가 아니다. 우리는 더 이상 배고픔을 달래기 위해서 식사를 하지 않는다. 무엇을 먹어서 즐거울지가 중요한 것이다. 그리고 이와 같은 경향은 새로운 세대로 넘어갈수록 더 두드러진다. 최근 유행하는 '먹방'과 '맛집 투어'도 같은 맥락이다.

기존 세대들은 특히 카메라 앞에서 누가 음식을 먹고 있는 장면을 보고 대리만족을 하는 모습을 이해할 수 없었다. 하지만 90년대생들은 이렇게 '먹는 행위'를 단순히 배를 채우는 행위를 넘어선 일종의 유희로 보기 떄문에 이러한 모습을 보고 대리만족을 느낀다고 이야기한다.

@공무원 시험을 준비하는 또 하나의 이유

그들이 이야기하는 정직함이란 성품이 정직하다거나, 어떤 사실에 대해 솔직하거나 순수하다는 'Honest'와 다르다. 나누지 않고 완전한 상태, 온전함이라는 뜻의 'Integrity'에 가깝다. 그들은 이제 정치, 사회, 경제 모든 분야에서 완전무결한 정직을 요구한다. 당연히 혈연, 지연, 학연은 일종의 적폐다.

@로열티: 충성의 대상이 꼭 회사여야 하나요?

과거 70년대생과 그 이전 세대에게 충성심이라는 것은 단연 회사에 대한 것이었다. 하지만 90년대생에게 충성심은 단연 자기 자신과 본인의 미래에 대한 것이다. 충성의 대상이 다르고 그 의미도 다르니 갈등이 일어날 수 밖에 없다. 때문에 90년대생들을 위한 조직 문화 개선 방안은 회사에 대한 충성심을 고취하는 것보다 자신들의 충성도에 회사가 어떻게 도움을 줄 수 있느냐에 방점이 찍혀야 한다.

@보여주기식 업무에 대한 염증

많은 90년대생들은 더 이상 과거처럼 상사나 회사에 대한 수직적인 소속감을 느끼지 않는다. 대신 과거와는 달리, 주변 동료나 지인들을 향한 수평적인 소속감을 더 많이 느낀다. GE의 전성기를 이끌었던 잭 웰치는 위계적 조직의 부작용을 지적하며 "위계적인 조직은 곧 모두가 CEO를 바라보고, 고객에게는 엉덩이를 들이대는 조직이 된다"라고 말한 적 있다. 그리고 이렇게 말로만 고객을 외치고 사실은 상사를 최우선 고객으로 모시는 위선적인 모습에 새로운 세대는 매우 비판적이다.

@형식에 빠져 낭비되는 시간들

90년대생들은 또한 '실행'보다 '계획'이 중시되고 '알맹이'보다 '형식'을 중시하는 조직의 모습에 환멸을 느낀다고 말한다.

조직학의 대가 아미타이 에치오니가 지적했듯이 사람들은 불확실성에 대한 두려움 때문에 의사결정을 방어적으로 회피하거나 필요 이상의 정보를 수집하며 시간을 끄는 경향이 있다. '돌다리도 두드려보고 건너라'는 격언이 '의사결정을 하지 않는 것보다 더 나쁜 의사결정은 없다'라는 격언을 압도하는 것이다.

'사회적 태만'은 협업에 참여하는 사람이 늘어날수록 개인별 노력의 최대량이 줄어드는 경향을 말한다. 책임을 분산하고픈 욕구는 누구에게나 있다. 그래서 조직은 구성원의 임무를 명확히 분배하려 노력한다. 하지만 권한과 책임의 선이 희미해지면 책임을 분산하려는 욕구가 조직에 비효율을 일으킬 수 있다.

@강한 통제 방식이 통하지 않는 세대

90년대생들은 자아에 대한 인정과 존중을 중시한다는 점에서 이전 세대들과 뚜렷한 차이가 있다. 이들에게는 권위와 통제가 통하지 않는다. 갈등만 일으킬 뿐이다. 그들에게는 창의성을 강조하면서 정작 보수적 기업 문화를 고집하고 있다고 비판받기 일쑤다. 90년대생들은 강압적인 요구에 그들의 권리를 잃으려 하지 않고, 전체를 위한 소수의 희생은 합리적이지 않다고 생각한다.

@적절한 참여를 통한 인정 욕구 충족

90년대생들은 숙련공이 되기 전에도 자신의 회사나 팀 내에서 중요한 역할을 하길 원하며, 직접 참여를 통해 주목받기를 갈망하고 있다는 것이다. 이들에게 필요한 것은 조직이 본인을 필요로 한다는 느낌을 받는 것이다. 그들에게 줘야 할 것은 권력이 아니라 표현할 수 있는 일종의 권리이다. 그들이 목소리를 내고, 주목을 받고, 성과를 내게 해주는 것이다. 참여도가 높을수록 90년대생 직원들은 더 빨리 기업에 적응하며, 그들의 의견이 더 많은 주목을 받을수록 그들의 책임감도 더욱 커진다. 그에 따른 성과를 끊임없이 눈으로 확인할 수 있도록 해주는 것이 그들에게 줄 수 있는 최고의 동기부여 방안이다.

@흥미를 어떻게 이끌 수 있는가

90년대생들에게 '일을 통해서 배울 것이 있다는 사실'을 알려주는 것이다. 정당한 근로시간의 확보를 제공해주는 것과 동시에 본질적으로 일과 삶이 별개가 아니라는 사실을 인식하도록 도와줄 필요가 있다. 일주일에 이틀뿐인 주말만을 바라보고 5일을 지옥 속에서 견디고 살 것인지, 아니면 자기 계발과 자기 실현을 근무시간에서 구현할 것인지는 개인의 문제인 동시에 90년대생들을 다루는 조직의 문제이기도 하다.

@90년대생들이 바꿔버린 소비 지형도

90년대생들이 제품이나 서비스 구매를 거부하는 '호갱 기업'

1. 직원과 협력업체에 대한 갑질 등 불공정 행위를 하는 기업

2. 국내의 낮은 경쟁 상황을 이용하여 차별적인 가격정책을 취하는 기업

3. 기업의 수익성 향상을 위해 제품의 품질을 고의로 악화시키는 기업

4. 복잡한 프로세스를 개선하지 않아 소비자의 불편을 야기하는 기업

@새로운 세대를 관찰 할 수 있는 두 가지 방식

새로운 세대들이 더 이상 고객센터로 전화하지 않고, 홈페이지에도 적극적으로 글을 남기지 않는다는 것이 그들에게 의견이나 불만이 없다는 증거가 될 수는 없을 것이다. 앞으로는 점차 듣기 힘들어진 90년대생들의 의견을 어떻게 '직간접적인 참여'로 이끌어내고, 이를 통해 그들의 성향과 감성에 맞는 제품과 서비스를 생산해낼 수 있는지에 기업들의 성패가 달려 있다.

읽기 좋은 코드가 좋은 코드다.

뭐든창하 — Wed, 20 Mar 2019 00:49:52 +0900

현재 재직 중인 회사의 개발팀 권장도서 중 하나이다. 장거리 출퇴근을 통해 읽은 두 번째 책이다.

이 책을 읽고 지난 작업을 돌이켜보니, 작성했던 코드가 읽기 좋은 코드는 아니었음에는 틀림이 없는 것 같다.

굳이 변명하자면, 한정된 자원(연기도 불가능한 촉박한 기간, 나눠서 할 인원도 없는 인력풀 등) 안에 기능이 제공되어야 하는 환경에서, 코드의 질을 높이겠다고 기간을 더 달라던가 기능을 축소하겠다는 말은, 완성된 기능이 반드시 먼저 제공되어야 함만을 바라보는 여러 이해관계자에게는 단순한 개발자의 사치로밖에 느껴지지 않았을 거라 믿어 의심치 않는다.(설령 대면 상태에서는 알았다고 시큰둥하게 넘어가더라도, 뒤에서는 도대체가 이해할 수가 없다는 표정과 뒷말이 오가는 경우가 다반사이다;;)

그럼에도 불구하고, 나 스스로의 발전을 위해서는 "노력 했었어야 하지 않았나" 반성하게 된다.

요즘들어 변수이름/함수이름을 짓는데에도 한시간 이상이 걸리고, 함수를 공통으로 뽑아낼때도 꽤 많은 시간을 고민해보는 횟수들이 잦아지면서, 다시 한번 좋은 코드에 대해 반복학습이 필요함을 느낀다.

아래는 이 책을 읽으면서, 좋은 코드를 작성하기 위한 하나하나의 상세한 방법(기술)보다는, 큰 맥락에서 늘 가지고 있어야 하는 태도와 관점을 정리한 내용이다.

#01. 코드는 이해하기 쉬워야 한다.

코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다.

어떤 사람이 여러분의 코드를 완전히 이해한다는 것은 그가 코드를 자유롭게 수정하고, 버그를 짚어내고, 수정된 내용이 여러분이 작성한 다른 부분의 코드와 어떻게 상호작용하는지 알 수 있어야 한다는 사실을 의미한다.

적은 분량으로 코드를 작성하는 것이 좋은 목표긴 하지만, 이해를 위한 시간을 최소화하는 게 더 좋은 목표다.

#02. 이름에 정보 담기

tmp라는 이름은 대상이 짧게 임시적으로만 존재하고, 임시적 존재 자체가 변수의 가장 중요한 용도일때에 한해서 사용해야 한다.
좁은 범위(scope)에서만 사용되는 변수의 이름에 많은 정보를 담을 필요가 없다.

즉, 변수의 타입이 무엇인지, 초기값이 무엇인지, 그것이 어떻게 사라지는지 등과 같은 변수가 담고 있는 모든 정보가 쉽게 한눈에 보이므로 짧은 이름을 사용해도 상관없다.

특정 프로젝트에 국한된 의미를 가진 약어 사용은 좋은 생각이 아니다. 이런 이름은 프로젝트에 새로 합류한 사람에게 비밀스럽고 위협적인 모습으로 다가온다.

시간이 흐르고 흐르면, 심지어 이름을 만들어낸 장본인에게조차 비밀스럽고 위협적인 모습을 지니게 된다.

#03. 오해할 수 없는 이름들

어떤 이름을 정하기 전에 항상 최악의 경우를 가정하고 이름의 의미가 잘못 이해되는 가능성을 고려해봐야 한다.

최선의 이름은 이러한 오해가 쉽게 일어나지 않는다.

#04. 미학

잘 생각해보면 여러분이 보내는 시간 대부분은 코드를 그저 바라보는 데 소요된다.

코드를 흝어보는 데 걸리는 시간이 적을수록, 사람들은 코드를 더 쉽게 사용할 수 있다.

지난 프로젝트에서 '잘못된' 스타일을 사용하는 경우도 많았지만, 일관성 유지가 훨씬 더 중요했으므로 해당 프로젝트의 스타일을 따랐다.

일관성 있는 스타일은 '올바른' 스타일보다 더 중요하다.

#05. 주석에 담아야 하는 대상

주석의 목적은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는 데 있다.
나쁜 이름에 대한 변명을 주석이 할 이유는 없다.
좋은 이름은 함수가 사용되는 모든 곳에서 드러나므로 좋은 주석보다 더 낫다.
코드가 가진 나쁜 가독성을 메우려고 노력하는 '애쓰는 주석'을 원하지 않는다.

이러한 규칙을 대게 [좋은 코드 > 나쁜코드 + 좋은 주석]이라는 공식으로 설명한다.

여러분이 작성한 코드를 다른 누군가가 읽는다면 "아니, 이게 뭐 하는 코드야?"라고 생각하는 순간이 있기 마련이다.

여러분이 해야 하는 일은 바로 그런 부분에 주석을 다는것이다.

사람들이 코드를 더 쉽게 읽을 수 있다면 그것이 무엇이든 상관없이 기꺼이 설명하라는 것이다.

그 내용이 무엇, 어떻게, 혹은 왜(또는 셋 모두) 중에서 어느 것을 포함해도 상관없다.

주석을 작성하는 과정

마음에 떠오르는 생각을 무조건 적어본다.
주석을 읽고 무엇이 개선되어야 하는지 (그런 부분이 있다면) 확인한다.
개선한다.

#06. 명확하고 간결한 주석 달기

주석 달기는 코드를 작성하면서 생각했던 바를 나중에 코드를 읽는 사람에게 전달해주는 것이다.

#07. 읽기 쉽게 흐름제어 만들기

영어 어순과 일치한다.

왼쪽 : 값이 더 유동적인 '질문을 받는' 표현
오른쪽 : 더 고정적인 값으로, 비교대상으로 사용되는 표현
좋은 예) 당신이 적어도 18세라면..
나쁜 예) 만약 18년이 당신의 나이보다 작거나 같다면..

부정이 아닌 긍정을 다루어라.

좋은 예) if (debug)
나쁜 예) if (!debug)

간단한 것을 먼저 처리하라.
더 흥미롭고, 확실한 것을 먼저 다루어라.
줄 수를 최소화하는 일보다 다른 사람이 코드를 읽고 이해하는 데 걸리는 시간을 최소화하는 일이 더 중요하다.
기본적으로 if/else를 이용하라.

삼항 연산은 매우 간단할 때만 사용해야 한다.

함수 중간에서 반환하는 것은 완전히 허용되어야 한다.
중첩이 일어날 때마다 코드를 읽는 사람의 마음 속에 존재하는 '정신적 스택'에 추가적인 조건이 입력된다.
수정해야 하는 상황이라면 여러분의 코드를 새로운 관점에서 바라보라. 뒤로 한걸음 물러서서 코드 전체를 보라.

#08. 거대한 표현을 잘게 쪼개기

한 줄짜리 거대한 표현으로 작성하는것이 매우 영리하다고 생각되고, 짧은 코드에 논리를 집어넣는 행위에는 어떤 즐거움이 있기 때문에 이해할 만한 일이다.

문제는 바로 그런 코드가 나중에 코드를 읽는 사람에게는 정신적인 장애물이 된다는 데 있다.

#09. 변수와 가독성

변수가 적용되는 범위를 최대한 좁게 만들어라.

코드를 읽는 사람이 한꺼번에 생각해야 하는 변수의 수를 줄여주기 때문이다.

많은 메소드를 정적(static)으로 만들어서 클래스 멤버 접근을 제한해라.

이 메소드의 코드가 저 클래스 멤버 변수들로부터 독립적이라는 사실을 알려주는 매우 좋은 방법이다.
static 선언으로 외부에서 해당 메소드의 직접 참조여부를 제공한다고만 생각했으나, 클래스 멤버 변수와 독립적인 관계라는 의미를 제공한다것이 새로웠음

커다란 클래스를 여러 작은 클래스로 나누는 목적은 데이터, 즉 변수를 서로 분리하는데 있기 때문이다.
변수값이 달라지는 곳이 많을수록 현재값을 추측하기 더 어려워진다.

#10. 상관없는 하위문제 추출하기

주어진 함수나 코드 블록을 보고, 스스로에게 질문하라. "상위수준에서 본 이 코드의 목적은 무엇인가?"
코드의 모든 줄에 질문을 던져라. "이 코드는 직접적으로 목적을 위해서 존재하는가? 혹은 목적을 위해서 필요하긴 하지만 목적 자체와 직접적으로 상관없는 하위문제를 해결하는가?"
만약 상당히 원래의 목적과 직접적으로 관련되지 않은 하위문제를 해결하는 코드 분량이 많으면, 이를 추출해서 별도의 함수로 만든다.
추출한 하위문제는, 해당 하위문제를 사용하는 상위의 프로젝트를 전혀 몰라야 한다.
자잘한 함수를 사용하면 오히려 가독성을 해친다.

작은 함수들이 다른 프로젝트에서도 사용된다면 추출하는 것이 그리 나쁘지만은 않다. 하지만 그런 순간이 오기 전에는 그럴 필요가 없다.

#12. 생각을 코드로 만들기

'쉬운 말'로 자신의 생각을 지식이 부족한 사람에게 전달하는 기술은 매우 소중하다.
프로그램이 수행하는 일을 설명해주는 가장 주된 방법은 결국 소스코드라는 관점을 가진다. 때문에 코드도 역시 '쉬운 말'로 작성해야 한다.

#13. 코드 분량 줄이기

가장 읽기 쉬운 코드는 아무것도 없는 코드다.
완벽하고 다양한 경우를 모두 대비하여 해결하려 하지 말라.

간단한 코드만으로도 약 90%의 실행속도 향상을 이루거나, 원래 분량의 1/4에 해당하는 상대적으로 짧은 코드로 문제의 절반을 해결하는 경우도 종종있다.

매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라.

#14. 테스트와 가독성

테스트 코드를 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적인 문서라고 생각한다.

따라서 테스트 코드가 읽기 쉬우면, 개발자는 실제 코드가 어떻게 동작하는지 그만큼 더 쉽게 이해할 수 있다.

다른 프로그래머가 수정하거나 새로운 테스트를 더하는 걸 쉽게 느낄 수 있게 테스트 코드는 읽기 쉬워야 한다.
코드가 왜 현재 테스트에서 실패하는지 쉽게 진단할 수 있어야 하고, 새로운 테스트도 쉽게 덧붙일 수 있어야 한다.
테스트에서는 길고 다소 복잡해 보이는 이름(테스트 함수명)을 붙이는 걸 두려워할 필요가 없다.

이는 실제 코드베이스에서 호출되는 함수가 아니다. 따라서 '함수명을 너무 길지 않게 해야 한다'는 일반적인 원리가 적용되지 않는다.

지금 작성하는 코드의 테스트 코드를 나중에 작성할 거라는 사실을 염두에 두면 재미있는 일이 벌어진다.

지금 작성하는 코드를 나중에 테스트하기 쉽도록 설계하게 되는 것이다.

블로그 광고수익이 궁금했습니다.

뭐든창하 — Sun, 17 Mar 2019 21:12:41 +0900

작년말 이직한 회사 출근하기전 갖게된 잠시 동안의 휴가기간에, 버려져있던 블로그를 다시 시작해보려 몇가지 설정해봤는데 그중에 한가지가 광고를 달아본거였다.

사실 블로그에 관심을 두지도 않았었는데, 시간이 생기니 이것저것 예전것들을 뒤돌아보게 되었고, 잊고있던 블로그에 오랜만에 접속해서 관리자모드로 로그인해봤더니 방명록의 글 하나가 마음의 변화를 일으키게 했다. 누군가에게는 이정도도 관리해보고 싶다고 마음먹는 마당에 그냥 버려두면 안되겠다는 생각이 들었고, 관리를 다시 해봐야겠다고 마음먹게 했고, 그런 김에 광고도 달아봐야겠다고 마음먹게 했다.

예전 글들을 몇개만 봤는데...시작한지도 오래되었고, 너무 어릴때라 지금도 저 옛날 글들을 읽다보면, 손발이 오글거린다;; 아무튼 관리라고 할만한것도 없었지만 지금까지 누적 방문이 11만을 넘었다는게 참으로 신기하다...

그중 한 가지 의아한것은, 저 인기글 1위를 차지하고 있는 "PreparedStatement 파라미터 포함 SQL 확인하기" 글은 무려 9년전, 2010년에 작성된 글이란거다;;

이제는 저 기능을 일부러 쓰지 않는한 기본적으로 제공하는 framework 자체가 무수히 많은데도 말이다.. 그때 당시에 엄청나게 필요한 기능이었기에 그때 기록되었던 방문통계가 너무 많아서 현재 인기글에 영향을 끼칠정도인가 의심해보기도 했는데, 해당 글의 개별 통계치를 보니 아직까지도 한 주에 20건정도의 방문에 지속적으로 발생하고 있다. 도대체 저 기능이 왜 아직도 검색되고 있단말인가;;

이쯤 되니 12월초에 광고를 설정 해놓고 3개월이 지난 시점에, 광고비가 좀 되나 싶은 기대를 가지게 되지만, 역시나 욕심 부릴만큼도 안된다 ㅎㅎㅎ 그냥 "해봤어~ 땅파도 1000원 안나온다~" 에 만족하자 ㅎㅎ

왜 세계의 절반은 굶주리는가?

뭐든창하 — Sat, 23 Feb 2019 20:39:34 +0900

장거리 출퇴근을 통해 하고 있는 몇가지 중 책보기로 첫번째 본 책.

컴패션을 통해 후원을 하면서도, 내 후원이 100% 고스란히 그 아이들에게 도움이 될 것이라는 믿음보다, 온전히 도움이 되도록 하나님께 기도드리는게 더 나을것 같다는 생각이 들 정도로 기아/빈곤퇴지를 위한 여러 단체/기구들의 활동이 믿음직 스럽지 못한게 사실인데.. 이 책을 통해서 더욱 안타까운 사실들을 알게되어 찹찹하다. 네슬러의 경우는 정말이지...불매운동이라도 하고 싶을 정도이다;;

기아는 자연도태? 아니면 어쩔 수 없는 운명?

@기아는 언제부터 시작되었을까요?

인류의 역사가 시작되면서부터 아닐까? 기아는 인류에게 끈덕진 동반자였지. 석기시대 사람들은 아침부터 저녁까지 먹을 거리를 찾아 헤맸을 거야. 우르와 바빌론 같은 도시에서는 기근이 끊이지 않았고, 끔찍한 대기근이 주기적으로 로마와 그리스인들의 목숨을 대거 앗아갔지. 중세에는 농노나 자유농민, 도시민, 그리고 그들의 가족들이 수백만 명이나 굶어 죽었단다. 19세기 때도 중국, 아프리카, 러이사, 오스만 제국 등에서 수십만 명이 굶어 죽었고.

그러다가 19세기 후반의 산업혁명으로 생산성이 눈부시게 향상되어, 오늘날에는 19세기 같은 '물직적 결핍'이 사라지게 되었지. 하지만 벌써 사라졌어야 할 기아문제는 아직도 해소되지 못하고 있어. 아니, 오히려 그 반대란다. 굶주림은 비극적인 방식으로 더 심해지고 있어. 현재로서는 문제의 핵심이 사회 구조에 있단다. 식량 자체는 풍부하게 있는데도, 가난한 사람들에게는 그것을 확보할 경제적 수단이 없어. 그런 식으로 식량이 불공평하게 분배되는 바람에 안타깝게도 매년 수백만의 인구가 굶어 죽고 있는 거야.

@그러니까 세계의 모든 사람들을 먹여 살릴 만한 식량은 충분히 있다는 건가요?

그뿐 아니란다. 지구는 현재보다 2배나 많은 인구도 먹여 살릴 수 있어. 오늘날 세계 인구는 60억 명 정도(세계 인구는 2006년을 기점으로 65억 명을 넘어섰고 2015년에는 73억 명 정도다 - 편주)되지. 하지만 1984년 FAO의 평가에 따르면, 당시 농업 생산력을 기준으로 계산하여 지구는 120억의 인구를 거뜬히 먹여 살릴 수 있다고 해. 먹여 살린다는 의미는 남녀노소를 가리지 않고 지구상의 모든 사람들에게 하루 2,400 ~ 2,700칼로리 정도의 먹을거리를 공급할 수 있다는 얘기지. 물론 각 개인이 필요로 하는 칼로리의 양은 나이, 직업 또는 거주 지역의 기후에 따라 달라지겠지만 말이야.

@그렇다면 배고픔은 세계의 주민들이 어쩔 수 없이 겪어야 하는 고통이 아닌 거네요?

물론이지. 식량이 제대로 분배된다면 모든 사람이 충분히 먹고도 남게 될 거야. 서구의 부자 나라 사람들을 사로잡고 있는 신화가 있어. 그것은 바로 자연도태설이지. 이것은 정말 가혹한 신화가 아닐 수 없단다. 이성을 가진 대부분의 사람들은 인류의 6분의 1이 기아에 희생당하는 것을 너무도 안타까워해. 하지만 일부의 적지 않은 사람들은 이런 불행에 장점도 있다고 믿고 있단다. 그러니까 점점 높아지는 지구의 인구밀도를 기근이 적당히 조절한다고 보는 거야. 너무 많은 인구가 살아가고 소비하고 활동하다 보면 지구는 점차 질식사의 길을 걷게 될 텐데, 기근으로 인해 인구가 적당하게 조절되고 있다고 믿는 것이지. 그런 사람들은 기아를 자연이 고안해낸 지혜로 여긴단다. 너무 많아진 인구로 인해 나타날 치명적인 영향과 산소부족으로 우리 모두가 죽지 않도록 자연이 스스로 과잉 생물을 주기적으로 제거한다는 거야.

@설마 자연이 그런 일을 할까요?

이런 설명은 전형적인 유럽적.백인 우월주의적 '정당화'란다. 부자들과 권력자들의 논리지. 자신들은 절대로 굶어 죽지 않을 거라는 걸 알고 있으니까 말이야. 영양실조로 팔다리가 비쩍 마른 아이를 안고 있는 벵골이나 소말리아, 수단의 엄마들이 자기 아이들이 죽음과 사투를 벌이는 게 '자연이 고안해낸 지혜'라는 소리를 들으면 어떤 반응을 보이겠니?

그런데도 많은 지식인이나 정치가, 국제기구 책임자들은 엉터리 신화, 즉 기근이 지구의 과잉 인구를 조절하는 작용을 한다고 믿고 있단다.

브라질 북동부 바이아 주에 있는 살바도르의 화창한 오후가 기억나는구나. 나는 기아문제에 대해 지속적인 투쟁을 벌이는 교양 있는 의학자 올란도 카스트로 - 리마와 함께 그곳에 있는 한 묘지를 방문했지. 살바도르는 도시의 4분의 1이 구릉지대였는데, 그곳의 아름다운 언덕에 묘지가 있었어. 바다와 가까워서 시원한 바람이 교회당 벽돌을 연신 간지럽혔단다. 캄포 산토라는 이름의 그 묘지는 고인들의 사회적 계층을 인상적으로 드러내고 있었어. 언덕의 꼭대기 부근에는 특권층인 금융과두제 엘리트들의 묘가 검정과 분홍빛 대리석으로 호화롭게 꾸며져 있었지. 사탕수수 농장주나 돈 많은 의사, 부유한 노예상인 같은 상류층의 묘였단다. 부인들은 죽어서도 남편에게 복종하듯 남편옆에 묻혀 있었지.

일레우스에서 카카오나 담배 농장을 경영하여 큰 부자가 된, 스위스나 독일에서 이주한 외국인 농장주들의 비석은 또 다른 분위기를 풍겼어. 마치 자신들에게는 흑인이나 인디오의 피가 단 한 방울도 섞여 있지 않다는 것을 과시라도 하듯, 원주민 엘리트들의 묘들과 멀찌감치 거리를 두고는 큰 나무들이 우거진 숲에 묘당을 세우고 있었지. 강압적으로 부를 쌓은 이 두 그룹의 묘지는 통로나 벽으로 충분히 분리되어 있었단다.

좀 더 아래의 중턱쯤에는 중류층 시민의 묘가 있고, 그 아래로 소상인이나 하급관리들의 묘가 펼쳐져 있었어. 화려한 묘는 별로 보이지 않았지. 대부분 커다란 판으로 묘를 덮어놓은 모습이었단다. 이곳의 묘는 하얀 천사상이나 고인의 브론즈상 대신 알록달록한 조화들로 장식되어 있었지.

자신의 농장에서 사망한 세르타오의 대농장주나 레콘카보의 사탕수수 농장주 중에는 고국의 가족묘지에 묻어달라는 유언에 따라 대양을 건너 고향에 묻힌 사람들도 있어. 하지만 중류층이나 소시민들은 거의 이곳에 묻히지. 그 아래로는 통로와 담을 사이에 두고 비탈에서 바다까지 이어지는 노단이 있었어. 이곳 좁은 골짜기 가장자리의 우거진 덤불 속, 마르고 붉은 땅에는 만성적인 기아와 거듭되는 대기근에 시달리다 죽은 이름 모를 수많은 희생자들이 어떤 장식도 없이 쉬고 있었단다. 몹시 불안한 휴식처라고 할까?

우리가 방문했을 때는 흑인 인부들이 이곳에서 일을 하고 있었어. 그들은 뱀을 쫓아내고 잡초를 뜯고는 땅을 팠지. 묻힌지 몇 년, 혹은 채 몇 달 되지 않은 해골과 뼈들을 추려서 수레로 던지고 있었어. 그러고는 구석진 곳에서 그것들을 태웠지. 재가 바람에 흩날리더구나.

이 장면을 지켜본 올란도 카스트로-리마는 심각한 표정으로 "자연도태가 무슨 뜻인지, 여기서 아주 명확하게 볼 수 있지요"라고 말했어.

자연도태라. 이 말은 정말 얼토당토않은 말이야. 그런데도 이런 표현은 사람들의 대화 속에 자연스럽게 등장하지. 아빠는 여러 대학과 제네바에서 열리는 각종 국제회의, 그리고 유엔의 책임자들과 나눈 사적인 대화에서 이 말을 무수히 들어보았단다. 숙명적인 기아가 지구의 과잉 인구를 조절하는 확실한 수단으로 여겨지고 있는 거야. 강한 자는 살아남고 약한 자는 죽는다는 자연도태설. 이 개념에는 무의식적인 인종차별주의가 담겨있어.

@그런 엉터리 개념을 맨 처음 사용한 것 누구였나요?

18세기 말 영국국교회 성직자였던 토머스 맬서스라는 사람이었어. 맬서스는 1798년 인구법칙에 관한 논문을 발표했어. 이 논문에서 맬서스는 세계 인구는 기하급수적으로 성정하여 25년마다 2배가 되지만, 식량의 증가는 산술서열을 따르므로, 가난한 가정은 자발적으로 산아제한을 해야 한다고 주장했지. 그리고 가난한 사람들에 대한 사회보조나 지원은 중단되어야 한다고 했어. 맬서스는 질병과 배고픔은 가슴 아픈 일이기는 해도 이 사회에 필수적인 기능을 한다고 주장했단다. 지구상의 인구를 줄여주는 자연적인 수단이라는 얘기였지.

@그 맬서스라는 사람, 정말 이상한 기독교인이군요!

그렇단다. 하지만 그의 책은 출판되자마자 유럽의 지배층에게 널리 읽혔고, 산업화 초기의 국민경제학자들과 기업인들에게 상당한 영향을 끼쳤단다. 맬서스의 주장은 오늘날에도 막강한 힘을 발휘하고 있어.

@맬서스의 이론은 전적으로 틀린 것인데도요? 아까 우리 지구는 인구가 지금의 2배가 되어도 너끈히 먹여 살릴 수 있다고 하셨잖아요. 그런데 어떻게 사람들이 맬서스의 이론에 동의할 수 있는 거죠?

카림, 대답은 아주 간단하단다. 맬서스 이론은 근본적으로 틀렸지만, 심리적 기능을 충족시키거든. 날마다 기아에 시달리는 사람들과 구호시설에서 웅크린 채 죽어가는 아이들, 수단의 덤불 속을 비쩍 마른 몸으로 뛰어다니는 아이들을 보는 것은 일반적인 감성을 가진 사람들에게는 참을 수 없는 일이거든.

그래서 양심의 가책을 진정시키고, 불합리한 세계에 대한 분노를 몰아내기 위해 많은 사람들이 맬서스의 신화를 신봉하고 있어. 끔찍한 사태를 외명하고 그에 대해 무관심하게 만드는 사이비 이론을 말이야.

네이버 뮤직에서 바이브(VIBE)로 갈아타기

뭐든창하 — Tue, 25 Dec 2018 23:32:12 +0900

네이버 뮤직을 몇년째 사용중인데, 언제부턴가 새로운 서비스인 바이브(VIBE)로 갈아타라고 안내문구가 나오던데...

네이버 뮤직도 계속 사용할 수 있다고 하지만, 요즘 서비스를 개발하는 업무를 하다보니 네이버 뮤직도 언제가 중지하고 바이브(VIBE)가 메인서비스가 되겠구나 싶다.

그럴꺼라면 갈아타는데 혜택을 줄때 이용하는게 좋을것 같아서 혜택을 봤는데, 일단 갈아타는데 기본적인 혜택이 있고 연간 멤버십 형태의 혜택이 있어 가격적으로 비교가 필요할 듯 싶다.

https://music.naver.com/buy/indexMusicPromotion.nhn?type=changevibe201812#welcome_vibe

# 기본 정기결제 멤버십은 이렇고...

# 연간멤버십은 1년과 2년 기간으로 나뉘고, 블루투스 스피커를 준단다.

# 가격을 비교해보자. 연간멤버십의 2년 기준으로 매월 얼마인지 비교해보았다.

- 부가세가 별도라길래, 부가세 10%를 추가했다.

# 2년 무제한 듣기

- 3개월 무료
- 24개월치 : 180,000 + 18,000(VAT) = 198,000

- 198,000 / 27개월 = 매월 7,333원, 블루투스 스피커 2개

# 1년 무제한 듣기로 2년을 사용하면

- 3개월 무료

- 12개월치 : 90,000 + 9,000(VAT) = 99,000

- 12개월치 : (7,500 + 750(VAT)) * 12개월 = 99,000원

- 198,000원 / 27개월 = 매월 7,333원, 블루투스 스피커 1개

# 그냥 정기결제 갈아타기로 2년을 사용하면

- 3개월 무료

- 12개월치 : (5,250 + 525(VAT)) * 12개월 = 69,300원

- 12개월치 : (7,500 + 750(VAT)) * 12개월 = 99,000원

- 168,300원 / 27개월 = 매월 6,233원, 블루투스 스피커 없음

# 혜택없이 그냥 27개월을 사용하면

- 222,750원 / 27개월 = 매월 8,250원, 블루투스 스피커 없음

정기결제로 갈아타고 2년을 사용하는것과 2년 연간멤버십의 차이로 보면, 블루투스 스피커 2개를 29,700원에 주고 사는것인데...

미니언즈 블루투스 스피커가 중고시세로 3~4만원정도 하는걸 감안하면, 2년 연간 멤버십을 결제하고 스피커를 중고로 한개만 팔아도 이득이겠거니 싶다.

가즈아~~ 바이브(VIBE)로...

다른 얘기긴한데...개인적으로 이런식의 서비스는 서비스 플랫폼 운영측의 힘과 수익이 커지게 하는 방식인것 같다.

음악들을 앨범/장르/가수 등 전형적인 형태의 항목을 통해 분류하고, 사용자가 직접 듣고 싶은 노래를 찾는 기존 방식은 VIBE가 하려는 방식에 비해 사용자가 더 손이 많이 가야하는 점은 있지만, 음악의 홍보가 서비스와 연관이 많지 않기 때문에 서비스 운영측면에서 보면 수익을 얻는 통로가 사용자를 통한 비율이 높을 것 같다.

반면에 VIBE와 같이 알아서 추천해주는 방식으로 지속된다면, 여기에 익숙해진 사용자가 많아질수록 그냥 추천해 주는 음악만 듣기 마련일테고, 서비스 플랫폼 운영측과 관계가 안좋으면 알고리즘에서 그리 된거다 라는 이유로 추천음악에서 제외되도 할말이 없게 하기도 하고, 음반사나 기획사들이 추천목록에 포함되기 위한 지불하는 서비스가 알게모르게 생겨나 광고비용이 고스란히 수익에 포함될 수 있을 것 같다. 마치, 네이버 업체검색에서 파워링크를 위해 특정 비용을 지불하게 만드는것 처럼 말이다..

기획사와 뮤직서비스의 파워저울에 어떤 영향을 끼치게 될지...

또한 네이버 뮤직 또는 VIBE의 수익에 대한 지표를 통해 유료이용자외에 광고수익 비율의 추세도 궁금하다.

샤오미 미밴드3 10일 사용후기...

뭐든창하 — Mon, 10 Dec 2018 23:37:17 +0900

샤오미 미밴드3 구매 및 한글화는 이전 글 참조..

https://alklid.tistory.com/1027

# Battery

완충 이후에 일주일동안 충전없이 28%, 10일 동안 충전없이 잔량이 23%

활동알림, 기상알림 등 대부분의 알림은 거의 on 상태

# Walk

잘 맞는지 정확하게 세면서 확인해보진 않았지만, 평일은 출퇴근 걸음수가 거의 비슷하기 때문에 첫날에 걷는 걸음 수와 그 이후를 비교해서 큰 차이 없는거 확인하고, "아, 이 정도 걸어야 6000걸음정도 되는구나" 생각한 이후로는 목표 걸음을 6000으로 조정.

단점이라면 목표걸음 설정이 1000단위밖에 안됨..약 100걸음씩 늘려가보면서 알림받고 싶은데...

# Sleep

미밴드3 구매하면서 가장 궁금했던 부분임...

자녀탄생 이후로 피곤하거나 회식이나 해야 세상모르고 잠들고, 그 외에는 깊게 잠들지 못함.

중간중간 어설프게 깨서 이불은 걷어차고 있는지, 열은 안나는지, 엎드려 있다가 곤란한 상황이 발생하지는 않을지 습관이 된것 같음.

첫날은 깊은 수면이 1시간 36분이라길래, 역시....내가 깊게 잠을 못자는구나 했는데 10일동안 평균 2시간정도의 깊은 수면을 취하는것도 상위 20%안에 드는 거란다;;

샤오미측에 축적된 데이터가 얼마나 많고 근거가 있을지는 모르겠지만 이 정도 깊은 수면시간이 괜찮은거라는게 의심스럽다...

# Alarm

카톡알림 좋음..단톡방의 경우 핸드폰에서 관련 설정을 좀 해줘야함.

(단톡방에서 알람 끄고, 설정-알림에서 "알림센터 메시지 표시" 항목을 "알림 켠 채팅방만"으로 변경)

문자, 전화 알림 좋음...특히나 이 기능은 휴대폰을 주머니나 가방에 넣어놓고 전화를 잘 받지 않는 아내에게 유용할듯하여, 아내에게 하나 선물을 해야겠음...

출근길 경험해보기...

뭐든창하 — Fri, 30 Nov 2018 16:44:14 +0900

다음주면 새로운 직장으로 출근을 하게됨에 따라, 미리 출근길을 연습해봄

1. 자율출근제도라 10시까지 출근하면 되는데 거리가 있다보니 감이 안잡힘

2. 애들 등교/등원도 같이 해야해서 가족들의 아침 시간표도 바뀜으로 연습이 필요함

3. 첫날부터 지각할수는 없으니...

4. 몇년동안 자가용으로 출퇴근하다 대중교통 이용하려니 체력이 문제가 될듯

#출발지 : 원흥 도래울2단지

#도착지 : 안암역(6호선)

한 10가지 방법이 있으나, 현실 가능하게 대략 2가지 경로로 줄임

특히 버스로만 출근하는 경우는 제외..

2가지 경로로 이틀정도 다녀본 결과 시간은 1시간 30분정도 걸림

당분간은 아침에 다 같이 나오는 경로를 이용하고, 전학을 가게 되면 원흥역을 이용해야 겠음

#1. 나와 가족들이 따로 출발하는 경로

- 원흥역(3호선)을 이용해서 안암역(6호선)까지 가는 경로

- 실제시간 측정

1) 08:00 : 출발

2) 08:30 : 원흥역에서 전철탑승

3) 09:08 : 약수역에서 6호선 환승

4) 09:18 : 안암역 도착

5) 09:34 : 사무실 도착

#2. 나와 가족들이 같이 출발하는 경로

- 다인이 학교에서 같이 내력서 행신역(경의중앙선)을 이용해서 안암역(6호선)까지 가는 경로

- 이 경우 다인이의 전학여부에 따라 내년에는 변경될 수 있을듯하다.

- 실제시간 측정

1) 07:50 : 출발

2) 08:05: 용현초등학교 출발

3) 08:22 : 행신역에서 전철탑승

4) 08:58 : 약수역에서 6호선 환승

5) 09:10 : 안암역 도착

6) 09:25 : 사무실 도착

다다걸스의 침대이야기 #7 - 정리

뭐든창하 — Fri, 6 Oct 2017 22:32:00 +0900

비용을 정리해봅니다.

메트리스 : 123,230 X 2 = 246,460원
프레임 : 55,300 X 2 = 110,600원
침구류 : 73,550 X 2 = 147,100원

두개 침대, 총 비용은 504,160원이 들었습니다.

낮은 프레임의 침대를 고집하지 않는다면, 일반제품 구입으로 더 저렴하게 할 수 있을것 같네요;;

그래도 만드는 재미도 있었고, 아이들이 불편없이 즐겁게 지내줘서 다행입니다.

사용한지 2년정도 지난 지금의 모습입니다..초등학생 가구로 변경되기 전이라 좀 지저분하네요 ㅎㅎ

Tip..

경첩을 3개 이용했는데 좀 더 많이 달거나, 아니면 경첩부분은 나사를 긴것을 이용하는게 좋겠습니다. 나사를 짧은것을 썼더니, 경첩부분의 나사가 뒤틀려서 빠져버리고 나사 박았던 부분의 목재가 홈이 파여서 다시 박기에 헐거워지게 되더군요.

도구없이 목재와 목재끼리 수직을 맞춰가며 조립했는데, 목재의 재단이 정확하게 직각이 아닐수도 있더군요.

정확하게 도구를 가지고 수직을 맞춰서 조립해야겠습니다. 안그러면 반으로 접었을때 정확하게 포개지지 않습니다;

다다걸스의 침대이야기 #6 - 만들기

뭐든창하 — Fri, 6 Oct 2017 22:24:00 +0900

우리나라 소비시장은 배송(물류)가 기반이 아닌가 싶습니다. '일반 사보고 반품하면 되지'라고 쉽게 생각할만큼 빠른 배송과 쉬운 반품이 잘 서비스되있어, 그 만큼 소비를 촉진시키는게 아닌가도 생각됩니다.

그런 기반하에 배송하시는분들의 처우도 지속적으로 좋아졌으면 합닌다.

구매한 물건들이 2~3일 내로 도착하기 시작합니다.

프레임을 만들기전에 원목들의 모서리를 매끄럽고, 둥글게 사포로 갈아줍니다.

먼지가 나니까 밖으로 나가서 해줘야지요.

그리고 설계한데로 천천히 조립합니다.

중간에 경첩을 이용해서, 이동이나 보관시에는 반으로 접어서 보관이 가능하게 했습니다.

프레임 - 매트리스 - 침구류 셋팅하면 완성이네요 ㅎㅎㅎ

소중하니까 걱정하는거다...

뭐든창하 — Wed, 23 Aug 2017 23:13:00 +0900

단기간의 성과가 좋아지고 있다고 기분내고 있기에는 걱정이 앞서 적게된다...

요 몇년간, 연구개발조직의 조직구성을 보면 미래를 준비하는 연구조직의 부재가 계속되고 있다.

정식명칭은 Research & Development (RnD)라고 하지만 Research는 없이 Development만 운영되고 있는듯 하다.

이 경우, SI성의 사업이나 기존 제품의 기능 개선과 오류해결에 초점을 맞춘 성과는 향상될 수 있겠으나, 개발조직의 전반적인 분위기가 문제를 해결하기 위해 결과에 급급한 구글링이나 stackoverflow에서 코드복붙에 의존하는 scriptkid 수준으로만 머물게 되지, 문제의 원인에 대한 깊이 있는 분석과 근본적인 해결책을 고민하는 deep-dive의 개발자가 양상되는 분위기는 어렵지 않을까 생각한다. 더욱이 이런 상황에서 기술의 부재에 대한 해결로 외부의 전문가에 의존하거나 기술을 가지고 있는 기업과 MOU나 M&A로만 해결한다면 더더욱 deep-diver는 나타나기 어렵지 않을까?

단기간의 성과에 급급한 사업이 아닌, 우리의 자산이 될 수 있는 기술에 대한 투자..

기술베이스의 IT기업에서 장기적으로 창의적이고 혁신적인 제품이나 서비스를 위한 기술력을 갖추기 위해서는 지금이라도 별도의 Research 조직이 필요하지 않을까? 미래를 위한 사업도 고민해야 겠지만, 동시에 미래를 위한 기술도 가질 수 있도록 준비가 필요해 보인다.

by StartCraft

Barracks에서 병사는 계속 나오고 Engineering Bay가 있어서 시간이 지나면 자연스레 짬은 차는데,

Academy나 Science Facility는 없어서 후반에 가면 그냥 발릴것 같은 느낌(?);;;

여담이지만, 얼마전 지인이 해준 지인의 조직장에 들은 말이 아직도 뇌리에 남는다.

"너가 하고 싶은걸 해봐..실패해도 괜찮아..실패해도 그건 회사의 자산이니까"

실패해도 그것이 결국 회사의 자산이라면, 실패해도 괜찮을 도전을 위한 투자를 받았으면 좋겠다.

지금은 어느 누구도 실패에 책임지지 않으려 하고, 실패하면 안되는 단기간의 성과에 대한 압박에 시달리고 있으니까...

사내에서 DDD, Microservice Architecture 같이 얘기나눌사람을 찾고 싶어.....

제품도 가격도 아닌, 요즘 같은 세상에 있어서는 안될 것같은 이유(예상되는...)로 POC떨어지니 더 심난하기만 하다;;;

개발자인데, 자꾸 엔지니어 취급해...엔지니어가 필요하시면 전 갈께요~