자신이 이야기할 때 주위가 갑자기 조용해지는 것을 경험해 본 적이 있는가? 주위 사람들이 입을 닫은 이유가 이야기에 집중해서 들으려고 한 것이라면 다행이지만, 어서 이야기가 빨리 끝나기만을 기다리려고 한 것이라면 슬픈 일이다. 더군다나 당신이 그걸 못 느낄 정도로 무디거나 그걸 알고 있음에도 계속 자기만의 이야기를 이끌어 간다면, 고위 간부인데다 같은 말을 반복해서 이야기 하는 스타일이라면 그것은 슬프다 못해 듣는 사람에게는 지옥이다.


  사사건건 남의 의견에 토를 다는 사람이 있다. 상대가 한 마디 하면 자기도 꼭 한 마디 덧붙여야 직성이 풀린다. 말허리를 자르고 들어와서 "아니, 그게 아니고"로 말을 시작한다. 서로의 의견을 주고받는 토론 자리가 아니라, 일상의 대화에서, 어제 있었던 연예인의 가십거리를 이야기 할 때에도, 오늘 먹을 점심 메뉴를 고를 때에도 자기만의 확고한 생각을 한 마디 거들어야 한다. 주제에 대해 아는 것이 많고 상식이 풍부해 질수록 이런 성향은 더 심해진다.


  그 대화 자리에서는 자신이 똑똑하게 느껴지고 위트도 있는 것 같이 느낄 수도 있다. 하지만 이런 대화술은 대화의 물길을 막을 뿐이다. 물길을 막으면 둑이 넘치고 새로운 물길이 생긴다. 결국 원래 주제의 이야기는 거기서 단절이다. 처음 그 대화 주제를 꺼내서 이야기를 끌어가고 싶어 했고, 좀 더 많은 대화를 나누기를 원했던 사람은 자신의 이야기를 못다 한 게 아쉽다. 자연스레 대화의 단절을 가져온 당사자에게 좋지 않은 감정이 생긴다.


  상대의 이야기를 들어주는 훈련이 필요하다. 내 의견과 다른 단어들이 입과 귀를 드나들면 참기 어렵다. 반대 의견을 내거나 더 재밌는 예를 들고 싶어 입이 근질거린다. 하지만 상대 이야기가 끝나기를 참고 기다려라. 그러고 나서 자기 말을 하자. 물론 상대의 의견을 무시하지 말고 부드럽게 받아 넘겨서. 말이야 쉽지 부단히 연습하지 않으면 어려운 일이다.


  오늘 옆의 동료가 점심메뉴로 해장국을 먹고 싶다고 하면 내 의견을 꺾고 동참해 보라. 그 친구는 어제 저녁 과로로 인해 속이 괴로울 지도 모른다. 그리고 콜을 외쳐준 당신을 속 깊은 사람으로 기억할 지도 모른다.

저작자 표시 비영리 변경 금지
신고

'개발자 Life' 카테고리의 다른 글

500 English - 미국인이 많이 쓰는 문장 500  (2) 2014.07.19
커뮤니케이션2 - 말 줄이기  (1) 2013.05.28
커뮤니케이션1 - 용어와 발음  (0) 2013.01.30
행복한 개발자  (0) 2013.01.20
프로그래밍을 배우자  (0) 2012.02.06
10만원짜리 수표의 가치  (6) 2011.07.14


  서점에는 한 쪽 벽면을 당당하게 차지하고 있는, 일명 '자기 계발서'라고 불리는 책들이 있다. 언젠가 부터 이런 류의 "성공하기 방정식 A to Z"식 서적들이 넘쳐나기 시작했다. 나도 몇 권 사서 보고 따라해 보았다. 학창 시절에 "성공하는 사람들의 7가지 습관(김영사)"을 읽고 원문 제목 대로 effective한 사람이 되려고 한 적도 있었다. 그나마 사회생활 하면서 도움이 되었던 자기 계발서는 이 책 뿐이고, 그 외에 책들은 제목조차 기억에 남아 있지도 않다. 


  이런 자기 계발서들의 문제는 독자의 대상을 일반 대중에 맞추다 보니, 성공하기 위한 디테일한 실천법이 오히려 모든 사람들에게 끼워 맞춰지지 않는다는 것이다. 사람들은 너무나 다양한 삶의 스펙트럼을 가지고 있는데 한 권의 책으로 모든 사람을 만족시키려 하다 보니 어쩔 수 없이 내용을 형이상학적으로 기술하거나 저자가 성공 모델로 삼고 있는 인물에 초점을 맞추고 있다. 또한 이른바 '성공'이라는 것의 정의를 부자가 되거나 조직의 높은 자리에 올라가는 것 만으로 내리게 되는 오류도 범한다. 이를 맹목적으로 따라하다 보면 반드시 실패하기 마련인데, 이런 경험을 하면 오히려 나는 실패한 인간이다라는 자괴감만 가지게 되고 나에게 맞는 방법은 따로 있을 것이다라는 착각에 또 다른 자기계발서를 찾아 헤매게 된다.[각주:1]


  하지만 당신이 몸담고 있는 분야, 바로 SW개발분야의 고수 프로그래머들이 들려주는 이야기는 어떨까? 다행히 SW분야에도 이런 자기계발서류가 많이 있다. 이런 책을 찾아 읽어야 한다. SW엔지니어를 위한 자기계발서는 형이상학적이지 않다. 읽으면 읽을 수록 공감이 가고 회사생활에, 경력을 쌓는데, 코딩 실력을 늘리는 데에 도움이 된다. 요즘 '프로그래머로 사는 법'을 읽고 있다. 마치 두권의 책을 한권으로 압축해 놓은 듯 내용이 풍부하다. 중간중간 섞여 있는 구루들의 인터뷰도 책을 읽는 맛을 더한다. 내가 이 블로그를 쓰고자 하는 내용이 다 담겨있다.(그래도 나는 루키 개발자를 위한 조언에 초점이 있으니 계속 하련다.)



   그리고 한 권 더 추천할 책이 있다. '실용주의 프로그래머(앤드류 헌트, 데이비드 토머스 저, 김창준 역, 인사이트)'인데 너무나 유명해서 따로 설명은 필요없을 것 같고 혹시 아직 읽지 않은 분이 있다면 서점으로 얼른 달려 가라. 난 이 책을 신입사원 때 사서 3번 정독했다. 처음 읽을 땐 내공이 부족해 무슨 소리인지 이해가 안되는 내용이 많았는데, 나중에 읽으니 공감이 더 가는 경험을 했던 책이다.



  기왕 책소개를 하는 김에 프로그래머를 위한 교양서적이라고 할 수 있는 책들을 몇권 더 소개한다.

  • More Joel on Software - 조엘 스폴스키 저, 지앤선
  • Hard Code(나잘난 박사의 IT 정글 서바이벌 가이드) - 에릭 브레히너 저, 마이크로소프트 프레스
  • "실용주의 사고와 학습(Pragmatic Thinking & Learning - Refactor Your Wetware)" - 앤디헌트 / 박영록 번역 / 김창준 감수, 위키북스
  • 김창준 씨가 추천하는 책 목록 - http://agile.egloos.com/5181803


.

  1. 딴지라디오, 그것은 알기 싫다 8회 "안아픈데 청춘이다"에서 인용. http://radio.ddanzi.com/index.php?mid=broadcast&category=1176709&page=2&document_srl=582993 [본문으로]
저작자 표시 비영리 변경 금지
신고

'SW 개발자를 위한 멘토링' 카테고리의 다른 글

새로운 업무를 대하는 자세  (0) 2013.06.28
테스트와 품질  (0) 2013.06.06
프로그래머를 위한 자기 계발서  (0) 2013.05.22
무엇을 배워야 할까  (0) 2013.05.12
청소하기  (0) 2013.03.30
개발자(SW 엔지니어)라는 직업의 매력  (2) 2013.03.26


Advanced(고급) > Configuration(설정) > Auto Detect UTF-8 Files (UTF-8 파일 자동 발견) 옵션을 켜 보자.




저작자 표시 비영리 동일 조건 변경 허락
신고


  신입사원이 처음 팀에 투입되면 방치되는 경우가 종종 있다. 맡게 되는 업무라고 해 봐야 팀내 자산조사와 같이 그다지 가치를 느끼지 못하는 일이 대부분이다. 당장 급한 업무를 신입에게 맡기기에는 못 미더울 뿐더러 업무를 일일이 가르치면서 진행하기에는 시간이 너무 오래 걸린다. 하지만 당신은 이 시기를 허비해 버리면 안된다. 당신은 앞으로 회사생활을 하면서 이 시기만큼 마음대로 공부할 시간을 얻지 못할 수도 있다. 평소 항상 좋은 책들을 찾아 읽어라. 무슨 책을 읽어야 할 지 모른다면 선배에게 자문을 구해보라. 필요한 지식을 얻기 위해 노력하는 후배를 위해 기꺼이 시간을 내 줄 것이다. 사내에 멘토링 제도가 있다면 멘토를 적극 이용해라. 멘토는 멘티의 실력을 키워서 한 명의 어엿한 팀원으로 키워내야 할 의무가 있다.


  어떤 책을 찾아 읽어야 하는 지, 어떤 분야의 지식을 쌓아야 하는 지도 중요하다. 내가 처음 입사했을 때 동기들과 책을 제본해서 본 적이 있다. 한 녀석이 휴대폰 개발자의 필독서라고 하면서 침을 튀기며 추천했던 "GMS Switching, Services and Protocols" 라는 책이다. 그 친구가 속해 있던 파트의 업무가 퀄컴과 같은 칩셋 업체가 제공한 SW가 제대로 동작하지 않을 경우 휴대폰 망의 규약을 잘 알고 있어야 문제를 해결할 수 있는 것들이었기 때문에 이 책은 필독서였다. 우리 팀 선배에게 이책을 공부해야 되냐고 물어봤는데 "뭐 공부해 두면 좋긴 하지"라는 어정쩡한 대답이 돌아왔다. 휴대폰을 만드는 제조사에 몸담고 있으니 모르는 것보다 알아두면 도움은 된다는 그런 뜻이었다. 우리 팀은 애플리케이션을 만드는 팀이었기 때문에 사실 망이 어떻게 구성되는 지 프로토콜은 어떻게 이루어져 있는 지 몰라도 업무에 크게 지장은 없었다. 나는 사실 팀에 바로 기여할 기술을 익히기에도 바쁜 신입시절에 언젠가 도움이 될 지 안 될지도 모르는 책을 파고 있었던 것이다.


  나의 요즘 주 업무는 휴대폰에 기본 탑재되는 안드로이드 앱 개발과 관련된 일이다. 문서를 검토하고 회의를 통해 의견조율을 한 후 프로그래밍으로 요구사항을 구현한다. 이후는 검증 부서에서 등록한 이슈들을 해결한다. 이외에도 자잘한 일들이 매우 많이 있지만 개발자들의 업무를 단순히 압축하면 이정도가 된다. 주 업무가 안드로이드 앱 개발이지만 순수 앱 개발 자체에 대한 서적은 한 권도 가지고 있지 않고, 처음부터 끝까지 독파한 책도 없다. Framework을 분석한 책 한 권만 가지고 있다. 개발에 필요한 대부분의 지식들은 Android Developer's 사이트에 잘 정리되어 있고, 시중에 나와 있는 많은 책들이 이 사이트의 문서를 번역한 수준이기 때문이다. 또한 구글링을 조금만 해 보면 개발 팁이 넘쳐난다.


  그렇다고 이런 책을 읽을 필요가 없다는 뜻이 아니다. 나는 Android가 이제 시장에 나와서 사람들에게 퍼지기 시작할 즈음 - 당시 버전이 Cupcake이었다 - 1주일짜리 사내 교육을 통해 앱 개발에 필요한 기초 지식을 쌓았고, 팀내 세미나를 통해 좀 더 세부적인 사항들을 공부했다. 그 후에 책을 한 권 사려고 서점에서 몇권 뒤져 봤는데 그다지 볼 만한 책이 없었다. 지금은 그런 기초적인 책이 필요하지 않게 된 수준이 되어 보지 않을 뿐이다.

  아무리 웹상에 정보가 넘쳐나도 책의 가치는 떨어지지 않는다. 책을 한 권 쓰기 위해 저자는 그 분야에 대해 독자보다 앞서 공부하고 개념을 이해하기 위해 자료를 뒤지고 쉬운 표현으로 전달하려고 고민한다. 위에서 말한 개발자 사이트를 단순 번역한 수준의 책에서도 한글로 매끄럽게 표현하는 데에 노력을 기울일 것이다. 예전에는 컴퓨터 관련 일선에서 뛰고 있는 전문가가 아닌 전문 번역가가 번역한 전공 서적이 많이 있었다고 하지만 요즘은 그렇지 않다. 해당 분야에 충분한 경험이 있고 저자의 뜻을 완벽히 이해한 후 독자에게 충실히 전달하려고 하는 좋은 책들이 많이 있다.


  주위에 도움 줄 사람이 없다면 다음 내용이 도움이 될 것이다.


1. 기본기

  SW 개발자들 중에는 학교에서 컴퓨터 관련학과를 전공으로 하지 않은 사람이 많이 있다. 당신이 만약 이런 부류라면 더 늦기 전에 컴퓨터 공학과의 커리큘럼을 찾아보고 관련 전공서적을 구해 업무와 관련 있는 것부터 읽어야 한다. 운영체제, 자료구조와 알고리즘, 객체지향 설계, 데이터베이스 뿐 아니라 개발 언어도 2가지 이상은 자유자재로 구사할 수 있도록 해야 한다.


2. 유행하는 최신 기술

  SW분야에도 유행이 있다. 개발 방법론에도 유행이 있고, 사용하는 언어나 프레임워크 같은 시스템에도 유행이 있다. 지금은 휴대폰에서 사용되는 대부분의 OS가 Android나 iOS이고 그 위에서 돌아가는 애플리케이션은 Java나 Objective-C로 작성된다. 하지만 앞으로 몇년 후에는 시장의 판도가 어떻게 변할 지 아무도 모른다. HTML5가 시장을 장악하여 사용자가 쓰는 대부분의 프로그램이 웹 애플리케이션이 될 수도 있다. 최신 기술에 뒤쳐지지 않게 1년에 하나 정도 새로운 언어를 익혀 두도록 하자. 마이크로 소프트웨어와 같은 잡지를 구독한다면 최근 유행하는 기술이 무엇인지 감을 잡는 데에 도움이 된다.


3. 업무 프로세스와 사내 시스템

  SW개발은 수많은 파트의 사람들과 함께 쌓는 탑과 같다. 각자 맡은 역할이 다르고 전문 분야가 다르다. 서로의 의견을 조율하기 위한 커뮤니케이션 능력은 매우 중요하다. 서로의 의견을 쉽게 소통하고 공유, 관리하기 위해 만든 시스템도 많이 있다. 가장 간단하게는 이메일이나 게시판이 그 역할을 한다. 위키도 있고, 사내에서 직접 만든 시스템도 있을 것이다. 이를 능숙하게 사용할 수 있도록 익히도록 해야 한다. 빠르고 정확한 커뮤니케이션은 업무효율을 배가시켜 주지만, 약속하지 않은 일방통행식 소통은 문제만 낳을 뿐이다. 

  또한 업무에 관련 파트가 늘어나면 정치가 끼어 들고 입장 차이가 생기기도 한다. 이게 맞는 방향인 것 같은 데 왜 일을 어렵게 만드는 지 이해가 되지 않을 때도 허다하다. 이를 매끄럽게 진행하기 위해 사내에는 업무 프로세스라는 게 존재한다. 이는 게임의 룰이다. 서로 지키고 따를 때 일이 원할하게 돌아간다. 불필요한 프로세스라고 생각된다고 해서 무시하지 마라. 당신의 안일한 생각으로 인해 프로세스를 따르는 많은 사람들에게 피해를 끼칠 수도 있다. 마음에 들지 않는 프로세스는 정식 루트를 통해 개선하도록 해라.


4. 개발 문화

  회사마다 독특한 기업문화가 있지만 업계를 관통하는 문화도 존재한다. 이른바 개발 방법론이라고 하는 것인데 최근에는 애자일이 인기를 얻고 있다. 하지만 이를 만병통치약인 것처럼 맹신하면 안된다. 조금씩 시도해 보고 팀에 맞는 것을 골라 사용하도록 해야 한다. 당신의 업무는 훌륭한 소프트웨어를 만드는 것이지 프로세스를 완벽히 지키고, 완벽한 문서를 만드는 게 아니다.


5. 개발자 모임

  업계 동향을 넓게 바라 볼 필요가 있다. 사내에만 갇혀 지내는 것은 경력을 쌓는 데에 도움이 되지 않는다. 웹상에는 많은 개발자 사이트와 동호회가 있다. 맘에 드는 것을 하나 골라 적극적으로 활동하는 것도 좋다. 최근에는 정부에서 Open Source SW에 많은 관심을 가지고 있으니 committer로 참여하는 것도 실력도 쌓고 인맥도 늘리는 좋은 방법이라고 생각한다.


  세부적인 책과 좋은 자료들을 추천해 주고 싶지만 너무 내 관심사에 국한되는 것 같아 제외했다. 공부할 자료를 직접 찾아서 정리하는 시간을 가지는 것만으로도 좋은 공부하고 생각하니 시간내서 나만의 커리큘럼을 정리해 보자.

저작자 표시 비영리 동일 조건 변경 허락
신고


  신입사원일 때 한 선배에게 빌드할 때 Warning 메시지가 많이 뜨는데 고쳐야 되지 않냐고 물은 적이 있다. 돌아온 대답은 그럼 네가 한 번 고쳐봐라는 말이었다. 문맥상으로는 본인은 다른 일도 많고 동작하는 데에 별 문제도 없으니 시간이 많은 신입 너가 한 번 고쳐봐란 뜻이었다. 그런데 그는 과연 컴파일러가 친절히 시간을 들여가며 화면에 뱉어 준 경고를 무시할 정도로 바빴는지, 과연 그 경고 메시지들은 무시할 정도로 사소했는 지는 지금까지도 의문이다.

  당신이 훌륭한 SW엔지니어가 되고 싶다면 "청소하는 습관"을 몸에 익혀라. 여기서 말하는 청소는 단순히 책상 위를 깨끗이 정돈하고 먼지를 닦아내라는 뜻이 아니다. 실력 있는 개발자도 책상 위가 지저분한 사람들이 많다. 어제 야근 중에 먹고 반쯤 남겨놓은 커피는 1회용 종이컵에 그대로 담겨 있고 테스트 장비들은 배배 꼬여 있는 전선과 함께 여기저기 널브러져 있다. 구석에는 먼지가 뭉쳐서 굴러다니는데 당사자는 걸레질은 언제 했는지 기억도 하질 못한다. 사실 책상의 청결도와 업무능력 간의 상관관계는 크지 않다. 위에서 언급한 엉망인 책상의 소유자가 업무에는 뛰어는 역량을 발휘하는 것을 많이 보았다. 그렇다고 책상 위를 일부러 지저분하게 하란 소리가 아니다. 마치 책상 위가 어지러운 게 일하는 것처럼 보인다고 여기는 사람들이 있는데 절대 멋있어 보이지 않는다. 집중력만 흐트러뜨릴 뿐이다. 그리고 주위 사람에게 자신의 역량을 보여주기 전에 선입견만 심어 준다. "저 녀석은 자기 책상처럼 평소 업무처리도 깔끔하지 않을 거야."

  주변을 깨끗이 정리한다고 모두 개발의 고수는 아니지만, 고수들은 모두 주위는 지저분하더라도 [각주:1]코드베이스는 깔끔하게 유지한다. 혼자서 진행하는 프로젝트라면, 아니 혼자서 진행하는 프로젝트라도 다음과 같은 짓은 하지 마라. 너무 당연한 내용을 이야기 하는 게 남우세스러울 정도다. 하지만 당연한 것을 당연하다는 듯이 실천하지 않는 사람이 많으니 이제 개발자로서 새 출발하는 당신은 마음에 깊이 새기고 실천해라. 상대방에 대한 '배려'가 조금이라도 있다면 지켜질 것들이다.

- 들여쓰기를 들쑥날쑥하게 해서 가독성을 떨어뜨리지 마라.
- 선언만 해 두고 쓰지 않는 변수, import(또는 include)가 있다면 바로 지워라.
- 나중에 사용할 지도 모른다고 넣어둔 테스트 코드는 당신의 노트에만 기록해라. 코드베이스는 메모장이 아니다.
- 마찬가지로 주석으로 막혀 있는 사용하지도 않는 코드 블록 역시 즉시 삭제해라.
- 사내 코딩 표준안을 지켜라. 지키기 어려우면 Editor의 formatter기능을 설정해서 편집할 때 자동으로 맞춰지게 하라.
- 중복코드는 만들지 마라. 중복코드를 만나면 그 자리에서 고쳐라.
- 코드는 1번 쓰고 100번 읽는다는 것을 명심해라. 지저분한 코드는 다시 읽을 때 방해만 될 뿐이다.

  가끔 위에서 언급한 지저분한 코드를 코드베이스에 머지하는 몰상식한 개발다들과 함께 일할 때가 있다. 코딩을 하면서 위의 것들을 지키지 않는 것은 마치 바둑의 기본도 배우지 않고 묘수풀이를 하는 것과 다르지 않다. 선과 선이 만나는 교차점에 착수를 해야지 돌 위에 돌을 놓는 격이다. 걸음마를 배우기 전에 육상 선수를 흉내 내는 사람이다. 기본 박자도 배우기 전에 스틱 돌리기만 연습하는 초보 드러머와 같다.

  지금 당장 사내에 정해진 Coding Rule(또는 Coding convention)이 존재하는 지 알아보라. 만약 있다면 자신의 코딩 스타일을 거기에 맞게 바꿔야 한다. 준비된 문서가 없다면 일반적으로 업계에서 통용되는 것을 찾아 익히도록 해라.[각주:2] 이 기회에 팀원들과 함께 만들고 공유하는 것도 좋다. 

  코드베이스를 더럽히지 않는 것도 중요하지만 만약 누군가 똥을 싸 놓았다면[각주:3] 보는 즉시 치워라. 한 개의 깨진 유리창이 건물 전체를 망가뜨린다는 것을 항상 기억해라.
  오랜 기간 수리하지 않고 방치된 창문 하나가 거주자들에게 버려진 느낌을 스며들게 한다. 당국자들이 그 건물에 별 관심이 없다는 느낌말이다. 그래서 다른 창문이 하나 더 깨진다. 사람들은 이제 어지르기 시작한다. 낙서(Graffiti)가 등장한다. 심각한 구조적 손상이 시작된다. 꽤 짧은 시간 안에 소유주가 그걸 고치려는 의지를 넘어설 정도로 건물이 손상되고, 결국 버려진 느낌은 현실이 되어 버린다. 
  '깨진 창문 이론'은 뉴욕과 다른 주요 도시 경찰들에게, 큰일을 막기 위해 조그만 것들을 엄중 단속해야겠다는 영감을 불어넣어 줬다. 정말 그렇게 된다. 깨진 창문, 낙서, 기타 작은 위반 행위를 잘 단속했더니 중범죄가 줄었다. 
  '깨진 창문'(나쁜 설계, 잘못된 결정, 혹은 형편없는 코드)을 고치지 않은 채로 내버려 두지 마라. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 충분치 않다면 판자로 덮는 것만이라도 하라. 불쾌한 코드를 주석처리 하거나, '아직 구현되지 않았음(Not Implemented)'이라는 메시지를 표시하거나, 가짜(dummy)데이터로 대치해 놓거나 하라. 더 이상의 손상을 예방하기 위해 어떤 조치든 취하고 현 상황을 잘 관리하고 있다는 것을 보여줘라
  깨끗하고 잘 기능하는 시스템들이 일단 창문이 깨지지 시작하면 급속도로 악화되는 것을 많이 보아 왔다. 소프트웨어의 부패에는 다른 요인들도 있지만 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다.

- 실용주의 프로그래머, 앤드류 헌트, 데이비드 토머스, 인사이트, 35쪽

  도요타가 급성장했을 때 그 생산방식과 경영철학에 대한 연구가 활발히 이루어졌고 이를 SW에 접목시킨 사례[각주:4]도 있었다. 도요타의 5S 정신 중 "청소(Seiso)"는 자동차 업계에만 통용되는 게 아니다.


  1. 공용으로 관리하는 SW 소스코드. 매일 작성한 코드를 코드베이스에 머지해서 공유한다. (참조) http://en.wikipedia.org/wiki/Codebase [본문으로]
  2. 예를 들어 Java 클래스 이름은 대문자로 시작하고, 메소드 이름은 소문자로 시작하지만 단어마다 대문자로 붙여서 지어야 한다. [본문으로]
  3. 다른 사람이 만든 버그를 수정해야 하거나, 안해도 될 일을 해야 할 때 "똥을 치운다"라고 한다. [본문으로]
  4. 린 소프트웨어 개발의 적용. 메리 & 톰 포펜딕. 위키북스 [본문으로]
저작자 표시 비영리 변경 금지
신고

티스토리 툴바