능력있는 개발자 어떻게 알아볼 수 있나?

생활코딩 페이스북에 황준식님께서 올리신 글입니다.

(https://www.facebook.com/groups/codingeverybody/permalink/1501967613177103 )

"해외 개발사의 제의를 받았다고 글쓴이 입니다.

지난 글은 제 생각이상으로 많은 분들이 공유하는 모습을 보았고, 
또 단순히 공유를 넘어서 서로 권하는 모습도 보았습니다.
그리고 저에게 자신이 앞으로 어찌할지 문의하는 분도 있었습니다.

사실, 지난 글은 그저 제 경험담일 뿐입니다.

그래서 이번에는 생코에 github을 통해 모듈을 공개하신 김재원님의 동의를 받아 코드 리뷰와 함께 
해외 CTO가 말한 really impressed with the quality에 대해서 하고 싶은 말을 몇자 적었습니다

ps. 다른 곳으로 퍼가도 됩니다."

---

능력 있는 개발자는 어떻게 알아볼 수 있나?

제 생각보다도 제 글은 더 센세이션 했던것 같습니다.

오퍼가 왔다고 해도 딱히 가지도 않아서 크게 생각 안하고 살았는데 말이죠.

여튼, 제 글이 400회 가까이 공유가 되었습니다.

공유한 분들 중에서는 이제 막 프로그래밍 공부를 시작하는 분들이나 현직 개발자는  물론이고, 사장님들도 보였습니다. 그리고 나름 영향력을 가진 분들도 있더군요.

저에게 자신이 어떻게 해야되냐고 문의하신 분들도 있습니다.

앞선 제 경험담은 솔직히 읽으신 분들의 일상이 달라지는 것은 아닙니다.

그래서 이번 글은 읽어주신 분들이 구체적으로 어떻게 해야하는지를 전달 할 수 있기를 바라면서  “really impressed with the quality” 에 대해서 제 생각을 적습니다.

솔직히 말해서...

우리나라의 개발 문화는 엉망입니다. 초중고급으로 구분된 개발자 등급제, 과다한 야근, 무리한 일정, 신입 개발자에게 사수도 없이 덥썩 일을 맡기는 현실, 학원 말고는 배울 곳이 없는 환경 등 끝이 없습니다. 해결을 위해 여러가지 논의가 되긴하나 신통한것은 없죠.

이 악순환 속에서 개인이 어찌 할 수 있는 것이 별로 없습니다. (네.. 헬조선이죠..)

하지만 선순환이든 악순환이든 중요한 고리가 있기 마련입니다.

순환을 가속하던지 끊어낼수 있는 고리 말입니다.

저는 개발자의 능력을 신뢰성있게 알아볼 방법이 이런 악순환을 끊을 수 있는 고리라고 생각합니다.

개인이든 조직이든 능력있는 개발자와 함께하면 악순환에서 탈출 할 수 있다고 생각합니다.

그래서 저는

능력있는 개발자로부터 무엇을 얻을 수 있는지?

그리고 어떻게 능력있는 개발자를 구분해 낼 수 있는지?

에 대해  제 방법을 공유하고 합니다.

이를 많은 사람들이 알면

이 악순환이 조금은 해결될 것이라고 기대하며

제 방식과 그에 필요한 Code Quality가 무엇인지 적습니다.   

본론 들어가기 전에..

감사를 표할 분이 있습니다.  생코에 easy-map 소스를 올린 wonism님입니다.

github에 적절한 수준의 소스를 올려주신 덕분에

제가  해외의 CTO가 말한  Code Quality가 무엇을 말하는지 작게 나마 공유할 수 있게 되었습니다.

능력있는 개발자를 왜 알아봐야 하나?

개발자의 능력은 우리나라에서 통용되는 초중고급 경력 구분으로 파악 할 수 없습니다.

현재 제가 기준으로 삼는건 드레퓌스 기술 습득 모형입니다. (자세한것은 http://blog.lastmind.io/archives/593 한번 읽어보세요.)

드레퓌스 모델과 우리나라의 초중고급은 사실상 비교가 불가능합니다.

옛날 등급제를 따르면 대학 나오고 경력 13년이면 특급입니다. 개발자가 20년간 일할수 있다고 하면, 전직하지 않으면 전체의 40%는 특급이 겠네요. 실상 드레퓌스 모델에서는 1%만 expert에 도달합니다. 숫자만 따져도 뭔가 말이 안되는 구조입니다.  

또한 슈퍼 개발자의 능력에 대한 개념이 우리나라는 잘못 되어 있습니다.

http://www.zdnet.co.kr/column/column_view.asp?artice_id=20141106211852

윗 글은 영국의 개발문화를 체험한 기사입니다. 글에서 언급하듯이 슈퍼 개발자는많이 / 빨리 만드는 사람이 아니라, 다른 사람의 실수 / 삽질을 사전에 막아내는 사람입니다.

프로그래머 생산성의 차이가 10배 이상도 벌어진다는것은 이미 공공연한 사실입니다. expert 레벨이 아니어도 3배 정도 개인 생산성은 우습게 벌어집니다.

하지만 능력 좋은 사람을 잘 대우해야 하는 이유는 그 사람이 3~4배의 일을 하기 때문만이 아닙니다. 게임에서 히어로가 정말 좋은 이유는 팀 버프가 있기때문이죠. 개발자도 마찬가지 입니다. 본인 생산성도 좋지만, 타인의 학습 속도/생산성를 올려줍니다.

때문에 능력있는 개발자는

조직 전체로는 일을 효과적으로 할수 있도록 해주고,

개인에게는 빨리 실력을 키울수 있게 해줍니다.

(꼭 알아봐야 할 것 같죠?)

우선 드레퓌스 모델을 기준으로 능력있는 개발자는 Competent부터입니다. 그림에서 보듯이 Coach가 가능한 레벨이기도 합니다. 그리고 제 경험상 우리나라에서 Competent 이상에 해당하는 사람은 10~20%라고 생각합니다.

여튼, Competent가 구체적으로 무엇을 할 수 있는 사람인지 적어 보겠습니다.

1.  영향력 있는 분들에게 하고 싶은 말입니다.

일단 수준 이상에 도달한 개발자에게 팀 전체의 개발 생산성을 늘리도록 할 수 있습니다. 기술을 리딩하게끔 권위를 실어주면, 팀 생산성을 1.5배나 그 이상도 늘릴 수 있습니다. Advanced Beginner는 개발 과정에서 등장하는 지뢰를 전부 밟고 터트려서 확인해야 합니다. 하지만 Competent에 이르면 절반은 피해서 갈수가 있습니다. 팀 전체의 삽질에 빠지는 총 시간이 줄어들면 그것만 계산해도 팀 생산성이 1.2배는 충분히 늘어납니다.

다만 아주 중요한건 일단 Competent수준에 들어서야 다른사람을 코치하는게 가능합니다.

교과서  내용을 전부 외운 Advanced Beginner라도 다른 사람을 코치하는 것은 거의 불가능 합니다. Competent는 지식의 양이 많은게 아니라 지혜를 가진것입니다. (물론 지식의 양도 경력만큼 충분히 받쳐주지만요.) Competent 이상 수준은 정말 얼마 안됩니다. 이런 사람을 찾으면 중용하시기 바랍니다. 중용하라는 건 월급 더 주는것으로 끝내라는 소리가 아닙니다. 팀 전체가 Competent의 업무방식을 배울 수 있게끔 강권하는 것이 좋다는 소리입니다. 지극히 개인적 생각이지만 가볍게 권장 해봐야 소용없는 것 같습니다. 그리고 제가 팀장일때는 저는 독재자 스타일이기도 합니다.

2. 신입 개발자분들과 대학 3~4학년 정도의 학생들에게 하고 싶은 말입니다.

잠재력이 있는 Advanced Beginner라고 해도 Competent가 기술을 구사하는 것을 관찰하지 못하면, 평생 실력 향상을 하지 못할 가능성이 매우 높습니다.

마찬가지로 Competent는 Proficient나 Expert를 찾아서 모방해야 성장에 유리합니다.

자신이 닮아야 하는 모습을 보지 못한다는 것은

별자리도 등대도 없이 망망대해에서 신대륙을 찾는 것과 다를바 없는 일입니다.

여러분들은 무조건 실력자의 바지를 붙잡고 늘어져야 합니다. 전 글에서 실력향상을 위해 수단 방법을 가리지 말라고 조언했습니다. 그 구체적인 실행방법은 Competent를 찾아서 무조건 물고 늘어지라는 것입니다. 제가 권하는건  C++/JAVA 1000제 풀기, JAVA 책 10독, 디자인 패턴 세미나 이런게 아닙니다. 여러분이 모방해야하는 더 나은 기술을 가진 사람은 기껏해야 10~20% 정도입니다. (분명 얼마 안되지만 그렇다고 찾을 수 없는 정도는 아닙니다) 이런 사람을 찾으면 뭐 하나라도 더 배우기 위해서 노력해야하는 것은 당연한거고, 왜 그러는지 이해가 가지 않더라도 기술을 모방해보시기 바랍니다. 모방하고 혼나고, 모방하고 혼나고... 최소한 그렇게는 해야 이해의 실마리라도 잡히게 됩니다. 그러자면, 같이 일 할 기회가 오면 그 일을 택 하세요. 먹고 사는데 지장만 없으면 고민할 필요가 없을 정도의 문제입니다. 능력있는 개발자를 따라 그 아래서 일하는 사람들이 함께 이직하는 것은 이런 이유가 큽니다.

또 회사를 고를 때는 여러분들도 회사를 평가하시기 바랍니다. 그렇다고 주식 투자자들이 생각하듯, 소스 보유량으로 결정되는 회사의 기술 역량을 평가하면 안됩니다. 그곳에 일하는 사람의 기술 역량을 판단해야합니다. 그냥 잘한다, 빨리 만든다가 아니라, 조언/업무지시를 얼마나 효과적으로 주는가? & 보고 배울게 있는가?를 생각해야합니다.

일단 찾는다면, 어떻게든 최대한 가까이서 관찰하고 모방하고 질문하기 바랍니다.

2.1. Advanced Beginner에게 조언하고 싶은 것 한가지 더.

Competent를 찾았을때, 조언하고 싶은 것이 하나더 있습니다. 자신의 코드를 보여주는 것에 용기를 가지세요. 솔직히 Code Review하면, 혹자는 발가벗겨져서 홀로 나체로 서있는 기분이라고도 합니다. 분명 그런 기분이 들겠지만, 그래도 용기를 내서 Code를 내밀어야합니다. 자신의 실패를 그대로 보여 줘야 한다는 두려움을 이겨내지 못하면 제대로 배울수가 없습니다.

3. 입문자에게 하고 싶은 말입니다.

입문자는 대학 1~2학년을 비롯해  이제 막 프로그래밍 공부를 시작한 분들 입니다. 굳이 드레퓌스 모형으로 분류하면 Novice입니다.

저는 개발 코칭을 할때, 코칭받는 분의 최소 조건이 자력으로 취업용 포폴을 구현할수 있는 사람입니다. 즉 Novice는 받지 않습니다. 이유가 있습니다. 그 아래 단계에서는 일단 절대적인 지식의 양과 기초체력이 부족해서 코칭 받은 것을 실습 할 수가 없습니다. 예를 들면, 제가 차범근 감독님을 코치로 섭외해서 현란한 발기술을 보고 배워도 기본 드리블과 90분간 뛸 체력이 없어서 제대로 배울 수가 없습니다.

이 단계 분들에게 권할 것은 따로 있습니다. 책을 보세요. 가능하면 외우세요. 어느정도로 봐야하는지 기준을 제시 한다면, 대학 학부 교재의 목차만 보고 섹션별로 관련된 키워드를 전부 쓸 수 있어야 합니다. 보통 제가 이런 수준을 요구하면 과하다고 합니다. 하지만 그 키워드를 외우고 있지 못하면, 여러분들이 기초 개발 능력을 갖추고, Advanced Beginner가 되어서 Competent를 마주했을때 그 조언을 이해할 수가 없습니다. 어렵게 Competent를 찾아도 제대로 배울 수가 없다는 소리입니다. 더 안타까운 것은 Competent입장에서 가르쳐 볼만한 사람은 많기 때문에 기회가 다시 오기 어렵다는 것입니다.

그러니까 나중에 후회하지 않으려면 일단 교과서는 다 외우고 가라는 겁니다. 굳이 책을 고르자면, 언어책 2~3권, 데이터구조, 알고리즘, DB, OS, 네트워크, OOP, 소프트웨어 공학, 병렬 컴퓨팅(Thread & 분산)  정도에 각자의 분야에 따라서 몇개 더 보태는 정도 입니다. (대충 10권 정도겠네요)

능력있는 개발자는 어떻게 알아보나?

능력있는 개발자, 즉 Competent를 찾아야 겠다고 결심했다면 어떻게 찾는지를 알아 봐야겠죠.

알려져 있듯이 드뤼퍼스 기술 습득 모형은 경력하고는 관계가 매우 적습니다.

소처럼 년 몇 이상 키운다고 1등급이 되지 않습니다. 기술 레벨은 직급이나 직위, 또는 경력 년수에 상관없이 어떻게 개발을 하는가만 보고 판단해야합니다.

문제는 자기보다 윗레벨을 인터뷰로 파악하는건 거의 불가능하다는 점입니다. 어쩔수가 없는게, 표면을 보는 사람에게는 심층부를 보는 사람의 대답은 선문답이나 사기꾼 같이 들리기도 합니다.

예를 들어 저에게 객체가 뭐냐고 물으면, 객체라고 대답합니다. 사기꾼 같게 들릴수도 있지만, 객체를 가장 잘 표현하는 단어는 “객체”입니다. 객체라는 속성이 가진 각각의 측면이 가진 특징을 강의 할만큼 알고는 있지만, 그 개개의 설명이 객체를 표현했다고 하기에는 너무 빠진게 많습니다.

아니면 반대로 연봉이 걸린 면접 자리면 최대한 능력 어필을 해야하니까, 아예 고급 주제로 갈수도 있습니다. 일반적으로 다루는 Class 기반 객체가 아니라 Prototype 기반 객체와 비교를 한다거나, 아예 사전 템플릿이 없는 Duck Typing 중심으로 객체를 사용할때를 예를 든다거나, 시맨틱 웹의 온톨로지에 나오는 Class 개념과 결부시켜 설명한다거나…

(이러니 저러니 해도, 지식적으로 내가 좀 더 나을것이다 정도 밖에 안됩니다)

제가 생각하기에는  어렵게 설명하나 쉽게 설명하나 듣는 사람에게는 항상 뜬구름 잡는 설명 일 뿐이라고 생각합니다.

반대로 아랫줄을 파악하는 것은 크게 어렵지 않습니다. 15분정도 면접하면 알 수 있어요.

하지만 이래서는 Competent를 찾을수가 없겠죠.

그런데 자기 보다 윗줄인 Competent를 비교적 쉽고 정확하게 구분할 방법이 하나 있습니다.

여러분들의 (코딩 모르는 사장님이면 회사내 직원의) 코드를 리뷰하여 고치게 해보세요.

온라인으로 하면 안되고 현장에서 1시간쯤 고치게 하면 됩니다. 즉, 코드 리뷰를 시킵니다.

그리고 코드 리뷰어가 왜 코드를 이렇게 작성했는지 의도를 알 수 있게,  코드 작성자에게 질문을 할수 있어야 합니다.

수정해서 나온 결과물이 교과서에서나 보던 그런 코드 같다면, 적어도 Competent라고 볼 수 있습니다.

이에 대한 이유는 생각보다 간단합니다.

Advanced Beginner는 교과서를 흉내내려고 하지만 생각처럼 잘 되지 않습니다. 고친다고 해도 책을 보면서 고쳐야 합니다.

Competent는 교과서 내용 정도는 몸에 베여있습니다. 코칭을 할 수 있다는 것은 자기 몸이 교과서라는 의미입니다. 그래서 1시간이면 충분히 고칠수 있습니다.

Proficient 레벨은 몸이 교과서인건 마차가지지만, 직관적 레벨에서 결정을 내리기 때문에 Competent보다 더 빨리 고칩니다. 저같은 경우에는 코드 크기나 기능에 따라 다른데, 5분 ~ 15분이면 교과서적인 구조로 고칠수 있습니다.

교과서적인 코드라는 것은 퀄리티가 좋은 코드를 의미합니다. 교과서에는 전산학의 개념을 가장 잘 보여줄 수 있는 코드를 실어 놓습니다.

그러면 어떤 코드가 퀄리티가 있는 건지, 코드 품질에 대해서 예시를 들겠습니다.

The Quality Of Code

코드에는 품질이있습니다.

이건 기능에 돌아가는 것과 전혀 상관없이 코드 자체의 질입니다. 똑같이 4인승을 실어 나를수 있지만 티코와 링컨 컨티넨탈은 다른겁니다.

리뷰 대상 코드를 제공해주신 wonism 님에게 감사를 표하며  

https://github.com/wonism/easy-map/blob/master/src/easy-map.js 를 가지고, 코드 품질에 대해서  애기해보겠습니다.

wonism 님이 생코에 소개한 글에 따르면 아래 기능을 수행합니다.

정의된 생성자로 객체를 생성한 뒤 특정 메소드를 실행하면, 마커와 인포윈도우, 클릭 이벤트, 거리 표시 등의 기능이 자동으로 구현됩니다. 현재는 구글, 네이버 지도만 사용가능하지만, 다음 지도, 바이두 지도도 추가해보려 합니다. 사용 방법, 데모 실행 방법 등 README.md 파일에 상세히 설명해두었으니, 가볍게 살펴봐주세요.

우선 코드의 첫 인상은 Advanced Beginner가 작성한 것으로 보인다 입니다..

멤버 변수 이름부터가 중복이 과합니다. prefix  형태로 쓰였는데, 그런 반면에 같은 대상에 대한 데이터를 같이 묶는( structure나 Class를 쓰는) 기법이 보이지 않습니다.

아래가서 찾아보니,

역시나 2개는 같이 묶여서 다닙니다.

외부가 Class EasyMap로 감싸여져 있긴하나, Class를 교과서처럼 쓸 수 없다고 판단 할 수 있습니다.

조금더 보니 Switch문이 보입니다.

oop에서 Switch가 과하게 등장하면, 추상화 개념을 아직 적용못했다는 의미 입니다.

혹시나 해서 검색해보니, 다해서 7군데 switch (this.mapType)이 쓰였습니다.

보다 보니까 함수 길이도 엄청나게 깁니다.

markCurrentPosition() 함수는 120줄 정도, createMarkers()  140줄 정도 subscribeInfoWindow()도 100줄 정도 입니다.

그리고 저 함수들 마다 Switch가 다 들어가 있네요.

작업자는 문제 해결하는 루틴을  함수 하나 안에 주르륵 쓰고 있습니다.

따라서 체계적으로 계획을 세우는 함수 단위의 사고 적용을 잘 못한다 고 평가할수있습니다.

전체 코드를 다 본 평가도

아직 교과서를 자기 몸에 체화하지 못한 Advanced Beginner로 결론을 내리겠습니다.

이제 본격적으로 고쳐보겠습니다.

일부나마 좀 더 전산학적으로 이쁘게(= 교과서에서 보던 것처럼) 고치려면 이렇게 해야합니다.

우선 Marker를 클래스를 사용해서 데이터를 묶습니다.

markerNames와 Ids는 없애고, markers = [] 로 선언하고, Marker클래스는 name과 id를 가지게 합니다.

그리고 위 루틴은

for (let j = 0, len2 = tempCoordsArr.length; j < len2 ; j++){
        var coord = tempCoordsArr[j];
        var marker = new Marker(coord.__id, coord.__name )
        this.markers.push(marker);}

으로 고쳐야 겠습니다.

Marker의 생성자는 (id,name)을 받아서  486, 487 라인과 동일한 일을 하도록 합니다.

이렇게 함으로써, markerName과 markerIds가 일치하지 않아,

문제가 발생할 가능성이 사라졌습니다.

그리고 대대적으로 고칠것은  Switch를 수정하는 것입니다. 전체 함수 영역에 걸쳐서 switch분기가 나오는 것은 추상화가 안된것입니다.

그러니 NaverMap Class와 GoogleMap 클래스를 따로 만들어서 각각에 해당하는 기능만 넣습니다.

정리하자면 구조가 아래와 같게 나와야 합니다.

class NaverMap  
markCurrentPosition()  { … } 
createMarkers()   { … } 
subscribeInfoWindow() { … } 


class GoogleMap  
markCurrentPosition()  { … } 
createMarkers()   { … } 
subscribeInfoWindow() { … } 



class EasyMap
        constructor(obj) {  
… 
if(this.isValid(obj)) { … } 
this.createConcreteMap()
 }


markCurrentPosition() {
        this.MapImplement.markCurrentPosition() 
}createMarkers() {
        this.MapImplement.createMarkers() 
}
        subscribeInfoWindow() {
        this.MapImplement.subscribeInfoWindow() 
}


createConcreteMap(){switch(this.mapType)
        case “naver”:
                this.MapImplement = new NaverMap()
        case “google”:
                this.MapImplement = new GoogleMap()


}

이제 추상화 개념을 적용하여 EasyMap은 구체적 구현 코드에 영향을 받지 않습니다.

디자인 패턴으로 따지면 Adapter 패턴으로 형태를 잡은 것입니다.

또한 subscribeInfoWindow등 100줄 단위의 함수를 mapType별로 Class를 묶었으니 50줄 정도 됩니다.

50줄이면 더 쪼갤 필요는 있는데 여기서는 생략하겠습니다.

그리고 역시 switch 는 코드가 너저분 하니까  

createConcreteMap()을 좀더 수정하여 아래처럼 고칩니다.

createConcreteMap(){
        var type = {
 naver: NaverMap, 
google: Googlemap
        }
        constructor = type[this.mapType]
        if(constructor  == undefined) 
throw new Error(“Not Supported”)  
        this.MapImplement  = new constructor()}

이정도 고치는데 5~10분 정도 들어갑니다.

그러나 변경 이후에는

Naver와 Google에 변동사항이 생겨도 각각의 Adapter Class에만 영향을 줍니다.

하나의 오류가 시스템 전체로 퍼지지 않게 보장됩니다.

전체적인 구조는 일관되게 동작할수 있으며. DaumMap 클래스를 구현하고 createConcreteMap 함수에 집어 넣기만 하면 루틴이 동작할수 있습니다.

유지보수 및 확장이 쉽다는 의미입니다.

아마 기존 소스에

DaumMap을 붙이려면, 모든 Switch를 찾아서, 100줄 짜리 함수들이 다 150줄이 되었을 것입니다.

그리고 구글 지도에 패치를 했을때 네이버 지도 기능에 영향을 안주는 것을 보장 할 수가 없습니다.

결국은 모든 지도를 다 테스트해야 출시할수 있게 됩니다.

코드 퀄리티는 이런것입니다.

굳이 표현하자면, 전산학에서 정립된 개념을 얼마나 반영했는가가 코드 퀄리티의 척도라고 말 할 수 있습니다.

그리고 효과는 엄청날 수 밖에 없습니다.

좋은 것을 만들기는 어렵지만,

좋은 것을 쓰기는 쉽습니다.

조직을 운영하는 분들은 느끼셨을것 같지만,

만드는데 품이 많이 들어가는 작업은 Advanced Beginner가 거의 하고, Competent는 그걸 정리해서 수준을 끌어 올립니다.

하지만 작업해서 나온 결과물의 사용성 / 안정성은 Competent가 모두 직접 만든 것에 비해서 크게 떨어지지 않습니다.

게다가 Advanced Beginner는 자신이 100% 작업한 코드보다도 Competent가 체계적으로 정리해둔 코드를 사용해서 개발할때,  오류도 훨씬 적고 속도도 빨라져 생산성이 올라갑니다.

그리고 Advanced Beginner레벨에 있는 분들은

어떻게든 능력있는 개발자를 찾아서  좋은거 많이 보고 모방해서 자기 것으로 하기 바랍니다.

흔히, 다른 사람이 작성한 좋은 코드를 보면 많이 배운다고 합니다.

하지만, 그것보다 더 빨리 배우는 방법은

자기가 작성한 코드가 좋은 코드로 변화하는 모습을 보는 것입니다.

왜냐면,  교과서적으로 좋은 코드를 볼 땐,  그 사람이 이미 잘하니까 이런게 가능하겠지라고 생각하게 됩니다. 하지만, 내 코드가  품질 개선이 되는 과정을 직접보고 이해하면, 나도 저렇게 할수 있다 라는 생각을 가지게 되기 때문입니다.

저는 여러분들이 단지 우리나라서 하던일만 잘해도 해외 개발사의 오퍼를 받는 것이 가능하다는 소식을 듣는 것만이 아니라, 코드 품질을 더욱 중요하게 생각해주셨으면 좋겠습니다.

해외 개발사에서는 코드 품질을 중요시하고, 그런 품질의 코드를 만들수 있는 사람을 대우하기 때문에, 저에게 제의를 했다고 생각합니다. 우리나라에서도 개발을 할때는 빨리 / 많이 만드는 것보다도 코드 품질을 더 중요하게 생각하는 문화가 생기길 바랍니다.

아울러 여러분들이 능력있는 개발자를 찾아 평생 동업자가 되거나 맨티를 자처하거나 또는 그 어떤 방향에서든지 생각하는 바를 얻을 수 있기 바랍니다.