Colin Kang

눈에 보이지 않는 적이 더욱 무섭다.

눈을 감아야 보이는 것들이 있다.

급하고 중요한 일은 없다. 

대부분 중요한 일은 급하지 않고, 급하게 하는 일은 중요하지 않다.

반드시 해야하고, 대부분이 하기 원하는 일은 시켜도 알아서 된다.

하지 않아도 되고, 대부분이 하지 않는 일은 결국 이상하게 끝이 난다.

빈수레가 요란하고, 든 것이 많은 사람일 수록 고개를 숙인다.

원인을 나로부터 찾는 사람은 다른 사람 잘 못도 내 잘 못 같고, 

원인을 밖에서 찾는 사람은 자기 잘 못도 다른 사람 탓이다.

내가 한 잘 못은 다른 사람들은 눈에는 안보일 거라고 확신하니 잘 못을 계속한다.

몰랐다고 한다는 것은 알았다는 것이다.

진짜로 모르면 잘 알고 있다고 한다.

공부는 엉덩이로하고 운동은 머리로 한다.

그렇게 말하는 것은 모르기 때문이다. 

그렇게 말하지 않는 것은 알고 있기 때문이다.

회사에서 프로젝트, task, 과제, pilot 등의 여러 이름으로 어떤 새로운 일을 개발/검증/증명 을 한다.

대부분 이런 경우 목표를 세운다.

목표는 추상적이며 많은 것을 설명해주지 않지만,

아이러니 하게 명료한 어떤 것이 되기 십상이다.

성능을 몇 % 올리기, 비용을 몇 % 줄이기, 

X 만큼 드는 시간을 Y로 줄이기, 

새로운 제품을 X 시간과 Y 비용으로 만들기

복잡한 상황에서 명확한 원인 찾아내기

그것을 하기 위해서 충분한 비용/인력/배경지식/자원 등은 주어지는 경우는 아주 드물다.

이런 프로젝트를 누가하는가?

거기에 실패에 대한 부담까지 져야 한다면 더더욱이 어려운 일이라 하겠다.

이런 프로젝트 일 수록 눈치빠른 사람은 벌써 어딘가에 가 있고, 그 간에 목소리 높고, 선두에 계시던 분들의

목소리는 침묵하며, 갑자기 맨날 욕만 들어먹는 사람이 갑자기 전문가라는 호칭을 들이며, 등 떠밀려 절벽앞에서 

손을 들라고 여러 부추긴다.

때론, 좋은 프로젝트 들이 있어, 누가 봐도 좋은 키워드와 화려한 팀으로 구성된 프로젝트도 있다.

이 2개의 프로젝트는 전혀 다른 배경이지만, 

또한 애석하게도 둘 다 성공한다는 보장은 없다.

성공에는 보이는 것보다 더 많은 측정 하기 어려운 것이 개입되기 마련이다.

이런 프로젝트의 결과에 대한 반영은 극명하다.

프로젝트에 대한 결과로 성공에 대한 경우는 이야기 할 필요가 없다. 

과정이 별로 였던, 운이었던 어찌되었던 성공했다면, 그건 좋은 결과이다. 

프로젝트에 대한 결과로 부정적인 결과인 경우에 대한 반응은 둘로 나눠진다.

첫번째는 부정적인 결과이지만, 원인 분석/결과에 대한 인정이기 보다는 포장과 덮기 등으로 갑자기 좋은 프로젝트로 등극한다.

첫번째도 문제이거니와, 이건 감독 마음이니 이에 대해서는 그럴려니 한다. 떡 주는 사람 마음이니.

문제는 두번째이다. 

두번째는 부정적인 결과에 대한 부정적인 반응으로 이어지는 경우이다.

대부분은 이를 실패라는 용어를 사용하면서 누군가는 공격의 수단으로 사용한다.

그래서 실패라는 용어가 사용된다는 것 자체가 벌써 목적성이 다분한 생각들의 언어에 대한 반영이다.

프로젝트에 대한 결과로 부정적인 결과로 얻는 이익은 적다.

결과가 기대만큼 되지 않았으니 실망과 위기의식과, 이에 대한 해명과, 리포팅과, 

이후에 결과에 다다르기 위해서는 뭘해야하는지에 대한 반성문등의 ( 이를 전문용어로 재발방지 대책 ) 나중을 위한

작업이 추가 되고, 멘탈도 많이 털린다.

여기에서 중요한 점은 반성문과 진정한 재발방지 대책의 차이가 그것을 리뷰하는 사람들의 생각에 따라 평가가 나눠진다.

아무리 좋게 표현하더라고, 받아 들이는 사람 측면에서 받아 들일 수 없게 전개가 된다면,

그건 아무리 좋은 리뷰라도 그 의도와 결과가 전달이 되지 않는다.

이런 부정적인 결과에 대한 피드백이 비난이 되지 않아야 한다는 건

수 많은 책과 가이드에 나와 있지만, 왜 이게 쉽게 된다면 누가 그렇게 많이 조언했겠나?

사람 인지라, 리뷰하고 가이드 해야 되는 위치에 있다보면, 

부정적인 결과에 대해서 민감해지는 건 어찌보면 즉각적이고 원초적인 반응일것이다.

하지만, 이를 그대로 두면 결국은 앞으로 조금 더 발을 내 디딜 수 없다.

결과에 대해서 그것을 기록하고, 기록에 신중을 가하고, 가능한 많은 자료를 남기로, 

어떠한 가설과 제한조건과, 그것을 어떻게 구현했는지, 당시 상황이 어떠했는지, 

왜 기대와 실제가 달랐는지, 그리고 그것을 진행한 사람의 회고, 

five why? poka-yoke 등의 모스트 모텀을 실시해야한다.

근데 그걸 부정적으로 본다면 그거에 대해서 잘 기록하지 않고 덮으려 한다.

나는 그것이 어떻게 평가되는 어떤 일을 할 때 자세하게 기록하고 남기고 공개하려고 한다.

왜야하는 것에 대한 대답보다는 아래의 사례가 그것을 더 잘 설명해주지 않나 싶다.

오늘 문득 SDE 책을 읽다가 그것이 생각나서 그것에 대한 과거의 사례의 기억을 기록해 둔다.

지금은 개발일을 하고 있지만, 

예전 회사에서 아주 큰 프로젝트를 할 때, 

똑같은 제안을 가지고 업계 1/2위를 다투던 세계적으로도 유명한 한국 회사 2개를 찾아갔던 적이 있다.

A 회사는 제안을 검토한 뒤, 그와 비슷한 프로젝트를 해 본 경험이 있고, 꽤 성공적인 건 아니었지만, 나름 괜찮았는데,

이런 점은 별로여서, 이 정도의 제안으로는 더 큰 성공을 이룰 수 없다며, 제안을 받아 들이지 않고, 

나중에 이 제안을 기반으로 한 유사한 과제 10개 정도를 자체적으로 했었는데, 10개 과제 모두 성공했다 ( ? ) 는 후문이었다.

여기에서의 성공은 그 걸 진행했던 사람들의 승진, 인사고가, 인정 등이라고 생각하시면 된다.

즉 이 제안은 남 좋은 일에 쓰였는게 그 때의 평가였다.

B 회사는 제안을 검토한 뒤, 그와 비슷한 프로젝트를 해 본 경험이 있고, 잘 되지 않았다고 한다.

하지만, 제안을 검토를 더 세밀하게 해서, 다시 잘 되지 않더라고, 비용을 들여서 해봐야 한다고 결과가 나왔고

나중에, 프로젝트를 했지만, 사람들이 노력해서 잘 되게 하려도 노력과 고생을 많이 하였지만, 기대 만큰 결과가 나오지 않았다.

그 때 당시에는 이 제안을 괜히 하였나? 나도 잘 모르면서 설레발을 쳤나? 여러사람 괜히 고생시켰나?

안좋은 건 결국하지 말아야 하나? 등의 사후 검증에 많이 시달리긴 했었다.

이게 2010-2012년 쯤이 었다.

꼭 이것때문만은 당연히 아니었지만, 그로 부터 3년 부터 분위기가 다르 더니 지금은 완전히 다른 결과가 나왔다.

즉 부정적인 결과를 어떻게 생각하느냐에 따라 회사의 결과가 바뀌는 건 정말 문자 그대로 교과서적인 결과였다.

현재 A 회사와 B 회사는 어떻게 되었을 까? 

B 회사는 완전히 글로벌 권에 장착했으며,

A 회사는 그 사업부가 없어졌다.

이렇듯 보이지 않는 부분에 대한 리더의 생각은

결과가 당장 나오지 않는다.

하지만, 반드시 청구서는 뒤에 오게 되어 있다.

현재에 회사에서도 이런 일이 있었지만, 

그건 이번에 쓸건 아니고, 나중에 떠오르고 마음에 정리가 되면

그 때 정리해서 써야겠다. Episode 2가 이래서 나오다 보다.

부정적인 결과에 도전하는 것에는 용기가 필요하고, 

그것을 스스로 인정하는 것에는 더 큰 용기가 필요하고, 

그것을 다른 사람에게 공개하는 것에는 더더 큰 용기가 필요하다.

그러니 엔지니어 들이어 힘들더라도 두렵더라고, 용기를 내어 도전해라, 

당장은 힘들어도, 끝이 좋다.

참고 :

개발자 : 어떤 목적에 부합하는 알고리즘을 특정 언어의 코드로 개발

코드가 돌아갈수 있는 환경이 필요함.

N명의 개발자가 개발한 코드를 실행할 수 있는 환경을 만들어야함

이러한 환경 : 하드웨어, OS, DB, Memory 등을 정해진 예산 범위 내에서 구축

구축이후에도 운영/유지보수가 필요함.

엔지니어 : 시스템을 구축, 운영 하는 사람

엔지니어 : 

하나의 새로운 시스템을
(간단하던,복잡하던간에) 구상하고 기본 설계를 할 줄 알아야하고
그 과정의 문제점에 대한 어느정도의 도출과 보완사항에 대한
구상을 생각해야 제대로된 엔지니어

모든 기계및 소프트웨어는 설명서(매뉴얼)이 있지만 처음 접할때는 설명서와
매뉴얼이 매우 많은 도움이 됩니다. 그러나 개발자가 예상하지 못했던 예외의
문제는 매뉴얼로 해결할수 없었습

엔지니어는 어떤 시스템(하드웨어적이거나 소프트웨어적이거나)을 설계하
고 제작하는 사람..

프로그래머는 어떤 시스템(OS)에서 작동하는 어플리케이션을 설계/제작하
는 사람..

시스템을 설계

소프트웨어 개발자는 소프트웨어 개발 방법론을 따라야하며 클라이언트의 요구 사항을 충족하기 위해 소프트웨어 프로그램을 디버깅하고 수정하는 데 전문성

코드 작성을 담당하는 소프트웨어 개발자는 창의적이고 기술적 인 기술을 사용하여 혁신적인 아이디어를 수행 할 수 있어야합니다

요구 사항을 소프트웨어 기능과 지속적으로 비교하는 데 필요한 우수한 분석 기술도 보유

사소한 오류나 잘못된 의사 소통으로 인해 중대한 재정 및 운영 문제가 발생할 수 있으므로 소프트웨어 개발자에게는 세부 사항 지향이 필수적

효율성을 높이도록 설계된 프로그램을 수정하고 수정하기 위해 세부 사항에 눈을 사용

소프트웨어 개발자 책임

• 객과의 요구 사항에 대해 논의
• 소프트웨어 테스트 및 문제 해결
• 시스템이 가동되고 실행되면 유지 관리
• 기술 설계의 일부가 됨
• 소프트웨어 구성 요소 통합
• 효율적인 코드 생성
• 참조 및보고를위한 프로그램 코드 작성

소프트웨어 엔지니어는 전체 프로젝트 라이프 사이클에 참여합

개발자 및 비즈니스 분석가와 협력하여 제안 된 소프트웨어 솔루션에 대한 요구 사항을 논의

발해야 할 항목, 방법 및시기를 식별하기 위해 프로젝트 범위를 지정

작업에 가장 적합한 프로그래밍 언어와 개발 프레임 워크를 선택하고 다양한 플랫폼에서 솔루션을 사용할 수있는 방법을 생각

기술 및 과학 지식을 사용하여 소프트웨어를 연루시키고 가능한 문제를 예측

패턴 설계 및 자동화 시스템에 능숙

소프트웨어 엔지니어 책임

• 새로운 하드웨어에 적응할 수 있도록 기존 소프트웨어를 수정하여 오류를 수정합니다.
• 사용자 요구 사항과 소프트웨어 요구 사항을 분석하여 시간 및 비용 제약 내에서 설계를 결정합니다.
• 시스템 설계 및 유지 관리에 대해 고객과 상호 작용합니다.
• 프로그래머 및 기술자의 작업 감독
• IT 아키텍처, 대규모 데이터 및 클라우드 기반 시스템을 만들고 유지합니다.
• 혼자서 그리고 소규모 팀 내에서 효율적으로 작업하십시오.
• 운영 개선을위한 시스템 분석 수행

소프트웨어 엔지니어는 건축가로, 소프트웨어 개발자는 목수로 생각할 수 있습니다.

엔지니어는 엔지니어링 원칙을 사용하여 시스템 전체를 감독하고 개발자는 기능 소프트웨어를 만드는 데 집중합니다

Engineering Excelllence

엔지니어링 우수성은 엔지니어링 기술에 탁월함을 추구하며, 효율적일뿐만 아니라 고객에게 즐거움을 전달하는 데 효과적이며 작업과 완제품에서 자부심과 만족을 얻는 과정에서 효과적입니다. 그것은 최종 목표가 아니라 노력이며 엔지니어로서 우리는 매일 깨어나 더 나은 것을 만들고 우리의 기술을 더 잘하게 만듭니다.

엔지니어링 우수성은 엔지니어가 최고의 작업을 수행하는 데 방해가되는 장애물과 우수성을 추구하고 우수성을 위해 노력할 수 있도록 지원하고 장려하기 위해 취할 수있는 조치를 식별하는 것입니다

버그를 잡는 것만으로는 고품질의 제품을 얻을 수없는 이유

Software Engineering Excellence

Developer Velocity를 마스터 한 기업은 개발자의 역량을 강화하고, 중요한 조력자를 예상하고, 투자를 고객 가치에 맞추고, 생산성 장벽을 최소화하는 데 똑같이 집중

https://en.wikipedia.org/wiki/Software_engineer

https://en.wikipedia.org/wiki/Software_engineering

https://wikidocs.net/113738

https://en.wikipedia.org/wiki/Outline_of_software_engineering

https://www.technojobs.co.uk/info/developer-guides/the-difference-between-software-developers-and-software-engineers.phtml

https://www.geeksforgeeks.org/is-there-any-difference-between-software-developer-and-software-engineer/

https://shecancode.io/blog/software-developer-or-engineer-whats-the-difference

https://medium.com/swlh/what-is-engineering-excellence-a8aa5a1e8dc5

https://medium.com/swlh/you-cant-fix-quality-just-by-catching-bugs-ddc01d900474

https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance#

Manager 혹은 팀장, 개발팀장, 팀리더, 관리자는 모두 하나의 롤을 표현하고 유사한 용어처럼 사용되지만 전혀 다르다.

Manager는 Managing 해야하는

사람들이 성과를 낼 수 있도록

그 사람에게 정기적으로 자신의 상태와 Result에 대한 Feedback을 주고

관리를 해주는 롤이라고 생각한다.

하지만 관리자 ( Administrator) 가 되어서는 안된다. 대부분의 회사를 결국 Administrator를 원하지만..

일부는 팀장은 본인이 어른이고 시니어로서 팀원들을 캐어하고 보호해줘야 한다고 생각한다.

또 팀원도 반대로 팀장이 외부로 부터 보호해주고, 자신이 하기 힘든 부분을 해줘야 한다고 생각한다.

장이라는 표현은 한국적인 의미가 많이 들어가 있다. 

의사 결정권자라는 의미를 가지지만, 어른 혹은 상위라는 개념으로 인식하기 쉬워서 

개인적으로는 장이라는 표현을 사용하는 것을 좋아하지 않는다.

Manager는 팀원이 그러한 문제를 스스로 해결할 수 있도록

시간과 방법을 알려주고

결과를 만들어 낼 수 있도록 피드백 루프를 가지는 역할이다. 

개발팀장은 인사관리자 롤을 뺀 팀장이거나 개발을 잘 알아서 이에 대한 코칭을 많이 해줄 수 있는 팀장을 지칭할 때 사용한다.

하지만, 개발을 잘 안다고, 아니 개발을 모른다고 팀 멤버에게 좋은 코칭을 할 수 없는가?

방법/solution/막힌 부분을 해결해주는게 Manager가 아니라 그 사람에게 피드백을 주는 역할이여야 한다.

꼭 개발팀장이 개발역량 혹은 개발경험을 가지고 있어야 한다고 생각하지 않는다.

물론 있으면 개발을 하는 팀 멤버를 더 잘 이해할 수 있겠지만, 

팀원은 사람이다.

사람을 이해하는 것이 매니징에서는 더 중요하다.

사람을 잘 이해하는 가장 좋은 방법은 자기 자신을 잘 이해하는 것이다.

자기 자신을 잘 이해하는 방법은 성경의 말씀을 보면서 자기 자신을 거울로 비워보면 알 수 있다.

이 글은 페이스북에 Sedong Nam이 포스트한 글(저의 1촌인 장병진님의 1촌인 것으로 나옵니다. )을 적은 것입니다.(작성일 2018년 4월 30일 기준)

링크를 찾을려고 검색을 해 봤지만 안되어 일단 글을 다시 적어서 배껴서 여기 글로 남기지만, 글의 저작권은 Sedong Nam님에게 있습니다.

다음 주소는 제가 글을 읽었던 Sedong Nam 님의 facebook 주소입니다.

https://m.facebook.com/dgtgrade?fref=nf

조직이 건강하다고 느낄 때 : (순서 없이)

1. 모르는 사람이 모른다고 솔직히 얘기할 때

2. 잘 아는 사람이 나서서 얘기할 때

3. 힘들 일 하겠다고 먼저 손드는 사람이 있을 때

4. 열심히 하고 잘한 사람에게 다른 사람이 박수칠 때

5. 어려움을 겪고 있는 사람이 도움을 요청할 때

6. 문제를 일으킨 사람이 숨기지 않고 공유할 때

7. 다른 사람의 일에 대해서 얘기를 주고 받을 수 있을 때

8. 리더 사람의 잘못이나 문제에 대해 얘기할 수 있을 때

9. 실패의 이유에 대해서 터놓고 반성할 수 있을 때

10. 구성원들이 동료와 조직과 사회를 함께 생각할 때

11. 서로의 장점이 서로의 단점을 잘 덮어 줄 때

a. 별거 아닌 걸로 함께 신나게 웃을 때

b. 내부 구성원들만 이해하는 언어가 있을 때

c. 구성원들 서로의 단점까지도 잘 이해하고 있을 때

d. 서로 주고 받는 농담의 성공 확률이 높을 때

e. 누가 무엇을 좋아하고 싫어하는지 서로 잘 알 때

f. 짧은 말로도 뜻이 명확하게 전달될 때

조직을 떠날까 싶을 때 : (순서 없이)

1. 배우는 것이 없다 느낄 때

2. 하고 있는 일이 의미 없어 보일 때

3. 좋은 성과가 인정 받지 못 할 때

4. 나쁜 일이 덮어지는 것을 목격할 때

5. 윗 사람들이 능력도 실력도 없을 때

6. 서로 일을 떠 넘기려 할 때

7. 아무도 책임지려 하지 않을 때

8. 조직 이기주의가 지나쳐 보일 때

9. 좋은 사람이 떠나갈 때

10. 아부가 통하는 것이 보일 때

11. 조직이 오로지 돈에만 관심 있다 싶을 때

12.사람을 부픔으로 대하는 것이 느껴질 때

a. 언제 마지막으로 웃었지 싶을 때

b. 마음이 통하는 동료가 적다고 느낄 때

c. 롤 모델이 될만한 사람이 없다고 느낄 때

d. 조직에서 외롭다 느낄 때

e. 짜증나고 화가나는 회수가 늘었을 때