Kwangshin's Positive Blog

이미지 출처: Manifesto for Agile Software Development

애자일 개발(Agile Development)이라고 하면 웬지 큰 기업이 아닌 작은 기업에서만 받아들이고 적용할 것 같은 오해가 있다. 예를 들면, 마이크로소프트와 같은 큰 기업에서는 애자일을 사용하지 않을 것 같고, 작은 벤처로 시작한 구글과 같은 기업에서 웬지 많이 사용될 것 같은 생각이 든다. 하지만 마이크로소프트는 이미 애자일을 지원하는 개발툴까지 있다고 하면 믿을 수 있겠는가? 또한 애자일의 대표격인 스크럼(Scrum)의 아버지라고 불릴 수 있는 Jeff Sutherland가 마이크로소프트의 애자일 부분을 여러모로 도와주고 있는 것 같다. (스크럼은 1993년에 Jeff Sutherland와 Ken Schwaber에 의해서 만들어졌다.) 오늘은 마이크로소프트에서 지원하고 있는 애자일 분야에 대해서 아주 간단하게 이론적인 것들만 소개 하고자 한다. 사실 사용해보지를 않아서 MSDN(MicroSoft Developer Network: 마이크로소프트 개발자 네트워크)에서 제공하는 애자일 관련 문서들만 소개하려고 한다.

마이크로소프트 비주얼 스튜디오(Microsoft Visual Studio) 2010에서는 애플리케이션 수명 주기 관리(ALM: Application Life-cycle Management)의 소스 및 형상관리, 리포팅, 테스팅 등 모든 업무를 통합 지원하고 있다. (참고: http://www.microsoft.com/korea/press/pressroom/2010/04/04.aspx) 애플리케이션 수명 주기 관리에서도 프로젝트 계획과 추적(Visual Studio Application Lifecycle Management - Planning and Tracking Projects)에 대한 MSDN의 설명을 보면 성공하는 프로젝트들이 가지는 특징을 다음과 같이 소개하고 있다.

  이미지 출처: http://msdn.microsoft.com/en-us/library/dd286619.aspx

(* 사실 한글 문서도 지원하고 있고, 자동 번역이 아니라고 명시되어 있음에도 이해하기 어렵거나 오해를 불러올 수 있는 번역들이 있어서 직접 번역/의역을 했다.)

• 고객의 요구(the needs of the customers)에 따라 프로젝트가 나아가는 방향이 결정된다.
• 프로젝트를 완료하기 위한 상위 레벨의 계획(high-level plan)을 가지고 있다.
• 여러 번의 반복(several iterations)을 통해 제품을 개발하면서 진행 상황에 따라, 필요하다면 이미 가지고 있는 상위 레벨의 계획(high-level plan)도 프로젝트가 나아가는 방향에 따라 수정할 수 있다.
• 프로젝트에 변경 사항이 발생했을 때, 이러한 변경사항들을 잘 받아들일 수 있는 효율적인 툴들을 팀원들이 사용하고 있다.

또한 프로세스 가이드로 다음과 같은 3가지의 제품들을 지원하고 있다.

• Visual Studio Scrum 1.0
• MSF for Agile Software Development v5.0
• MSF for CMMI Process Improvement v5.0

역시 마이크로스프트 답게 스크럼, 애자일 그리고 CMMI까지 지원하고 있다. 각각의 제품들에 대한 자세한 사항들은 링크를 통해서 확인할 수 있다. 여기에서는 MSF for Agile Software Development v5.0에 대해서 좀 더 살펴보겠다. 링크를 클릭해서 들어가보자.

우선 다음과 같은 간단한 소개가 나온다.

Your team can apply agile practices more easily by using the process template for MSF for Agile Software Development v5.0 with Visual Studio Application Lifecycle Management (ALM). The template and this guidance will help you practice Scrum and apply agile engineering practices. These processes and practices come from Scrum, eXtreme Programming, and other agile methodologies, as Agile Principles and Values, by Jeff Sutherland describes.

비쥬얼 스튜디오 애플리케이션 수명 주기 관리 패키지에 포함되어 있는 MSF for Agile Software Development V5.0에서 제공하는 프로세스 템플릿을 사용하면 애자일 실천사항(agile practices)을 더 쉽고 간단하게 팀에 적용할 수 있다. 제공되는 템플릿과 이 가이드가 스크럼을 사용하고 애자일에서 말하는 여러가지 실천사항들을 적용하는데 큰 도움이 될 것이다.  여기에서 소개하고 있는 프로세스들과 실천사항들은, Jeff Sutherland가 이야기하는 애자일 원칙과 가치(Agile Principles and Values)에서 설명하는 것처럼 스크럼, 익스트림 프로그래밍(XP: eXtreme Programming)과 다른 여러 애자일 방법론(agile methodology)들에 그 뿌리를 두고 있다.

이 소개에 이어서 단순해 보이면서도 애자일 개발의 큰 그림을 볼 수 있고, 마이크로소프트가 애자일 개발 중에서도 어떤 부분을 중요시 여기는지를 볼 수 있는 다음과 같은 그림을 소개하고 있다.

또한 더 자세한 정보들은 다음과 같은 하위항목들을 통해서 설명하고 있다. 링크를 클릭하면 더 자세한 정보들을 볼 수 있다.

• 스크럼 - Scrum
• 공학적인 측면의 실천사항들 - Engineering Practices
• 산출물 (애자일) - Artifacts (Agile)
• 역할 분담 - Roles
• 미팅 (애자일) - Meeting (Agile)

각각의 링크를 클릭해서 정보들을 보면 알겠지만, 아주 자세한 실제적인 설명보다는 좀 더 개념에 치우친 간단한 설명들이 나온다. 하지만 그것만으로도 마이크로소프트가 어떻게 애자일을 생각하고 지원하고 있는지 이해할 수 있을 것이다. 기회가 된다면 MSF for Agile Software Development V5.0을 한번 사용해 보고 싶다. 어느 정도까지 지원을 하고 있는지...

각각에 대한 설명들은 관심있으신 분들은 들어가서 읽어보시기를 권한다. 다음에는 이 자세한 설명들 보다는 위에서도 잠깐 언급되었던, 스크럼의 아버지라고 불릴 수 있는 Jeff Sutherland가 쓴  애자일 원칙과 가치(Agile Principles and Values)에 대해서 알아보겠다. 아마 이 글이 마이크로소프트에서 애자일을 지원하는데 있어 근간을 이루지 않을까 싶다.

한국경제의 4월 15일자 기사 하나가 인터넷에서 소프트웨어 개발자들에게 핫이슈가 되고 있다. 바로 한국 최고의 IT 회사라고 자부할 수 있는 NHN (IT 업계에 종사하지 않으면 잘 모를수도 있으니, 네이버, 한게임등을 개발하고 운영하는 회사라고 하면 다들 바로 아실듯 하다.)의 창업자로 최고전략책임자(CSO)를 겸하고 있는 이해진 이사회 의장의 사내강연 소식이다.

이해진 "편해서 네이버 왔다는 직원에 억장 무너져"

기사에서 언급하고 있는 NHN의 위기론이나 직원들을 독려 하고자 한 얘기까지는 이해가 가는데, (사실 어디까지가 진실인지는 모르겠지만) 몇 가지 부분에서 시대를 거슬러 가고 있는 것 같다.

NHN이 출근 시간을 오전 10시로 정한 것은 전날 야간 근무를 새벽까지 하는 직원들이 많았기 때문이다. 오랜 시간 사내에서 근무하는 직원들을 위해 최첨단 환기 시스템을 도입했고 100만원이 넘는 의자도 제공했다. 하지만 요즘은 오후 7시에 퇴근하고 다음날 오전 10시에 출근하는 직원들이 많다는 것이다. 이 의장은 “출근 시간을 늦추고 사무 환경을 개선한 것은 절박하고 치열하게 일하는 직원들을 위했던 것”이라며 “하지만 지금은 경쟁사와 비교했을 때 NHN은 노동 강도가 가장 약한 곳”이라고 비판했다.

예전에 NHN 관련 기사를 읽으며, 야근하는 직원들을 위한 배려로 의자도 좋은 것으로 바꾸어 주고 환기 시스템도 바꾸었다는 이야기는 들었다. 하지만 이제는 주객이 전도되는 느낌이다. 위 인터뷰가 사실이라면, 야근하는 직원들을 배려했다기 보다는, 직원들에게 회사에 대한 불평없이 야근을 더 많이 시키기 위해서 그런 혜택들을 주었다라는 느낌밖에 들지 않는다. 그럼 야근을 하는 직원들은 좋은 의자와 최첨단 환기 시스템을 사용할 수 있고, 야근을 안 하는 직원은 사용하면 안되는 것인가? 예전에 기사를 읽으면서 직원들을 배려하는 NHN이라는 회사와 회사 리더쉽들에게 가졌던 환상이 일순간에 무너지는 것 같다.

또한 한국 최고의 IT회사의 최고전략책임가라는 직책을 가지신 분이 아직까지도 소프트웨어 개발이라는 공장에서 부품 찍어내는 것과 동일하다는 생각을 하는 것 같아서 참 실망이다. 위 인터뷰를 어떻게 정리했는지, 실제로 이해진 이사가 했던 말은 무엇인지 모르겠지만, 인터뷰만 보자면 야근을 안 하기 때문에 NHN은 노동 강도가 가장 약한 곳이라는 논리를 펴고 있다. 역시 한국은 아직도 그냥 의자에 앉아서 오랜 시간을 때우기만 하면 일을 열심히 하고 잘 하는 직원이구나 라는 생각이 들었다. 10년전에 한국에서 3년간 일하면서 그런 문화때문에 참 많은 고민을 하고 왜 그런 문화가 정착되었을까 라는 의문을 많이 품었는데, 10년이 지난 오늘날에도 동일한 논리가 NHN의 최고전략책임가의 인터뷰에서 나왔다는 사실에 실망하지 않을 수 없다.

그렇다면 이해진 최고전략책임가가 하고 싶은 것들은 무엇일까?

그는 “요즘 NHN은 게임과 서비스 출시도 늦고 콘텐츠마저 ‘엣지(독창성)’가 없다는 이야기가 들린다”며 “매일 아침 구글, 애플 등 글로벌 정보기술(IT)기업들과 경쟁사들이 새로운 서비스를 내놓았다는 뉴스를 볼 때마다 스트레스를 받는다”고 말했다.

참 아이러니 하다. 게임과 서비스 출시가 늦고 콘텐츠의 독창성을 살려서 구글, 애플 등과 같은 글러벌 IT 기업들과 경쟁하고 싶은데, 그렇다면 그 방법이 바로 직원들이 야근을 많이하면 된다는 것인가? 정말 NHN 직원들이 야근만 많이 하면 NHN이 구글, 애플과 같은 기업들을 쫓아갈 수 있다고 생각하는 것일까?

이 의장은 “이용자의 요구를 악착같이 파악해 독하게 추진하는 기업이 결국 이겼다”며 “NHN에는 혁신이 더 이상 없고 독점적 지위로 경쟁사를 압도해 1등을 했다고 이야기하지만 IT산업 특성상 이용자를 배려하는 혁신 없이는 계속 1위를 지킬 수 없다”고 말했다.

이용자의 요구를 악착같이 파악해 독하게 추진하는 기업이 결국 이겼다고 하는데, 애플이나 구글같은 기업을 말하는 것일까? 구글의 검색기능이 애플의 아이폰이라는 제품이 이용자의 요구를 악착같이 파악해 독하게 추진했기 때문에 나온 결과물일까? 정말 애플과 구글의 리더들은 회사 직원들이 야근을 더 많이 하라고 여러가지 혜택들을 제공하고, 거기에 맞춰 모든 직원들이 야근에 야근을 거듭해서 혁신적인 결과물들을 얻은 것인지 묻고 싶다.

이 기사가 나온 이후로 많은 글들이 올라왔다. 다음의 글들도 읽어보시면 더 큰 숲을 볼 수 있을 것 같다.

내 경력에는 조기축구회 4년이 있다.

NHN 개발자들이 떠난 이유를 이해진 CSO는 정말 모를까?

NHN 개발자들은 왜 떠나는가?

NHN 내부 분위기가 기사화 되고 있다.

사실 소프트웨어 개발자로 일을 하다보면 야근을 하게 되는 경우도 많다. 이렇게 야근을 해서 좋은 제품을 만들고 새로운 혁신을 위한 아이디어가 나올 수도 있다. 하지만 이러한 정의의 역이 성립한다고 생각한다는 발상 자체가 이해가 안간다. 즉, 좋은 제품을 만들고 새로운 혁신을 위한 아이디어가 나오도록 야근을 해야 한다는 말은 어불성설이다. NHN의 성공신화의 바탕에 좋은 제품을 만들어내고 혁식을 위한 아이디어가 많이 나올 때 직원들이 많이 야근을 했을것이다. 부인할 수 없는 사실이지만, 왜 그 당시에 직원들이 야근을 많이 했는지에 대해서는 왜 관심을 가지지 않을까? 모든 일이 그렇지만 소프트웨어 개발도 사람과 사람이 함께 하는 일이다. 야근이라는 팩트 하나만을 보지 말고, 더 큰 숲을 본다면 이런 인터뷰가 신문에까지 나는 일은 막을 수 있지 않았을까 생각된다.

또한 이 사건으로 말하기의 중요성을 다시한번 실감하게 되었다. 사실 이해진 최고전략책임가도 이런 의미만을 가지고 사내강연을 하지는 않았을거라고 믿고 싶다. 자기가 전달하려는 주제가 오해를 불러일으키고 잘못된 방향으로 소개된것이 아닐까 싶다. 물론 야근도 훌륭한 제품을 만들어내는 데 도움이 되는하나의 요소가 될 수는 있다고 생각하고 동의한다. (물론 매일 매일 야근을 반복하는 것은 궁극적으로 제품의 질에 긍정적인 영향을 끼치지 않고, 부정적인 영향을 끼친다고 믿는다.) 자기의 생각과 의견을 대중들에게 제대로 그리고 정확하게 전달하는 것, 어느 분야의 어느 위치에 있든지 꼭 필요한 능력이 아닐까 싶다.

마지막으로 이 기사를 읽은 바로 그날, 우연히 보게된 하나의 동영상을 공유하면서 마무리를 하고 싶다.

날개없는 선풍기로 유명해진 Dyson이라는 회사의 사내 이벤트라고 한다. 가장 빠른 고카트(go-kart)를 만드는 사내 경진대회이다. 다만 회사에서 구할 수 있는 여분의 부품(using a few Dyson spare parts)들을 사용해서 만들 수 있고, 또한 동력에 해당하는 부분은 Dyson의 모터만(all the torque they could eke out from one of our handheld motors)을 사용해야 한다. 참여하고 구경하는 엔지니어들의 정말 즐겁고 행복한 모습이 보이지 않는가? 가장 빠른 고카트를 뽑는 대회인데도 불구하고, 자기가 만든 고카트를 타고 달리는 참가자의 희열을 느낄 수 있을 것 같다.

이런 회사의 마인드와 문화가 선풍기는 날개가 있어야 한다는 기존의 개념을 완전히 깨고, 날개 없는 선풍기를 만들어내는 원동력이 되지는 않았을까? Dyson의 리더진들은 왜 회사돈을 써 가며, 직원들의 시간을 뺏어가며 이런 사내 이벤트를 개최하는지 한국의 IT를 이끌어 가시는 분들이 한번쯤은 생각해 줬으면 한다.

Page 42, Test-Driven Development by Example written by Kent Beck

Image source: http://net.tutsplus.com/tutorials/php/the-newbies-guide-to-test-driven-development/

When we decide how much we need to do test during TDD, we don't need to worry and spend a lot of times to decide the coverage and steps in detail. Let's see the Kent Beck's advice:

This is the kind of tuning you will be doing constantly with TDD. Are the teeny-tiny steps feeling restrictive? Take bigger steps. Are you feeling a little unsure? Take smaller steps. TDD is a steering process - a little this way, a little that way. There is no right step size, now and forever.

- Page 42

Image source: http://www.raynauds.org/index.php/2011/04/heated-steering-wheel-cover-news/

Page 46, Test-Driven Development by Example written by Kent Beck

Moreover, we need to abandon our habit even though we are excellent software engineers. Don't try to do everything by ourselves! Pass our works to computers or tools. That's why we have developed the computers and tools we are using.

In teaching TDD, I see this situation all the time - excellent software engineers spending 5 to 10 minutes reasoning about a question that the computer could answer in 15 seconds.

- Page 46

Page 47, Test-Driven Development by Example written by Kent Beck

I know that I show the message - "All code is guilty until proven innocent" above. However there is an exceptional case, as always. In page 47, Kent Beck is trying to do implement "toString()" method without a test! If there are understandable reasons, then you need to accept it.

Whoa! Code without a test? Can you do that? We could certainly have written a test for toString() before we code it. However,
-. We are about to see the results on the screen.
-.  Because toString() is used only for debug output, the risk of it failing is low.
-. We already have a red bar, and we'd prefer not to write a test when we have a red bar.
Exception noted.

- Page 47

Do not forget the principle and purpose! Our purpose is developing software, not the TDD itself!

Happy TDD!

Page 24, "Test-Driven Development by Example" by Kent Beck

Copy-and-paste reuse? The death of abstraction? The killer of clean design?

Not always...

The following cycle doesn't finished yet...

1. Write a test.
2. Make it compile.
3. Run it to see that it fails.
4. Make it run.

[Trying to do "copy-and-paste" here...]

5. Remove duplication.

The cycle is not complete. The first four steps of the cycle won't work without the fifth.

Don't be worry about doing "copy-and-paste", if the "copy-and-paste" is not a purpose, but a mid-step. Of course, it could be happened when we need to do "copy-and-paste". Please see the principle(essence), not superficial, why we would suggest not to use "copy-and-paste".

Focus on promising ourselves we wouldn't go home until the duplication was gone.

Now, it is very easy to implement hash algorithm in Java. You need only java.security package which is included in basic Java package. It means you don't need to install any other classes or packages. Here is the example for MD5 algorithm:

String source = "Java Hash MD5";

MessageDigest md = MessageDigest.getInstance("MD5");
md.update(source.getBytes());

byte[] hashValue = md.digest();

That's all you need. Not you get the hash value as byte array for source string.

If you want to use other algorithm like SHA256, then you need to change only the parameter when you get the instance of MessageDigest class. Here is the source:

String source = "Java Hash SHA-256";

MessageDigest md = MessageDigest.getInstance("SHA-256");
md.update(source.getBytes());

byte[] hashValue = md.digest();

Happy Coding!

오래만에 암호화 관련 코딩을 하는데, 이제 정말 편해졌구나. 해쉬값을 얻을 때, 전혀 걱정할 일이 없네. 유명한 해쉬 알고리즘들이 이미 자바 기본 패키지 안으로 다 들어와 있어서, 그냥 3~4줄 코딩하면 해쉬값을 얻을 수 있다.

예제는 위에 있습니다~

I was trying to save my "SecretKey" into Java KeyStore. In the specification of KeyStore class in Java, you can save the following 3 types into KeyStore according to the KeyStore class specification (http://docs.oracle.com/javase/1.5.0/docs/api/java/security/KeyStore.html):

• KeyStore.PrivateKeyEntry
• KeyStore.SecretKeyEntry
• KeyStore.TrustedCertificateEntry

However, if I try to save KeyStore.SceretKeyEntry using setEntry(...) method, then the following exception came out:

java.security.KeyStoreException: Cannot store non-PrivateKeys

We can store our non-PrivateKeys using KeyStore.SecretKeyEntry according to class specification, but why they say that we cannot store non-PrivateKeys?

You can solve this problem simply. You need to change the type of KeyStore. Basically I used the "JKS" type when I get instance of KeyStore:

//JKS means Java KeyStore.
 ks = KeyStore.getInstance("JKS");

Somehow, this default type of KeyStore does NOT support saving non-PriateKeys. If you change the type into "JCEKS", then the same source code is working properly without the exception.

// JCEKS means Java Cryptography Extension KeyStore.
ks = KeyStore.getInstance("JCEKS");

I think it is better to use "JCEKS" as a default. The "JCEKS" type KeyStore has much stronger protection and implementation than "JKS" type. Please see the following JCE Reference Guide: http://docs.oracle.com/javase/1.5.0/docs/guide/security/jce/JCERefGuide.html. Before Java 2 SDK release 1.4, the JCE(Java Cryptography Extension) package was optional. So you need to include the JCE package to use "JCEKS" KeyStore type. It was a burden to both development and deploy side. However, JCE has been integrated into the Java 2 SDK since the 1.4 release. So if you are using recent Java 2 SDK version like 1.5. or 1.6, feel free to use better "JCEKS" KeyStore type.

Happy coding!

저 에러 때문에 고생 많이했다. 스펙상으로는 분명히 아무 문제가 없는데, SecretKey임에도 불구하고 non-PrivateKey라고 에러를 내다니... "JKS"를 "JCEKS"로 간단하게 고치고 나니 쌩쌩 잘 돌아가는 걸 보고 희열을 느끼면서도 허무하기도 하다. 동일한 에러를 만나시는 분들은 시간 허비 많이 하지 않으시고 해결책을 찾으시기를...

오늘 인터넷 서핑을 하다가 다음과 같은 글을 보게 되었다.

Naming Conventions in Java - How to name Methods,Classes and Variables

When writing programs in the Java language, there are a set of standard conventions which should be followed. These are followed in almost all kind of projects. Beginners in Java language are not used to utilizing the namingconventions but as one writes code in modern day IDE’s these naming practices become a habit.

자바 언어로 프래그램을 작성할때, 몇 가지 표준 규칙들을 지켜주는 것이 좋다. 어떤 분야의 프로젝트를 진행중이건 간에 이러한 규칙들을 지켜주어야 한다. 자바 언어를 시작한지 얼마 되지 않았다면 이런 네이밍 규칙들이 생소하고, 적용하기에 익숙하지 않을 수도 있지만, 요즘 많이 사용되고 있는 통합 개발 환경(IDE)에서도 이러한 네이밍 규칙들을 지키고 있으므로 노력해서 습관이 될 수 있도록 하는 것이 좋다.

자바에서의 네이밍 규칙에 대해서 이야기 하고 있는 짧은 글이다. 특히 메서드(Methods), 클래스(Classes), 변수(Variables) 이름을 짓는 규칙에 대해서 이야기 하고 있다. 사실 이 글에서는 아주 일부분인 네이밍 규칙(Naming Convention)에 대해서만 언급하고 있지만, 사실 자바 프로그래밍 언어가 발표되고 얼마되지 않아서 자바 코딩 규칙에 관한 문서가 발표되었고, 13년 전인 1999년 4월 20일에 마지막으로 수정된 문서가 있다. (그 당시에는 링크가 Sun이었는데 지금은 Oracle이다.)

Code Conventions for the Java Programming Language
http://www.oracle.com/technetwork/java/codeconvtoc-136057.html (HTML 버전 바로가기)

이 글을 보니 11년 전인 2001년도에 프로젝트에 적용하려고 번역해 놓은 문서가 떠올랐다.

[PDF 버전] Korean: Code Conventions for the Java Programming Language (한글) [PDF], 역자: 오광신
[HTML 버전] http://www.javastudy.co.kr/docs/lec_ProgrammingGuide/okshin/JavaCodeConventions.htm (자바스터디에 아직도 링크가 살아있다.)

왜 자바 코딩 규칙이 필요한가가 문서 초반에 나오고 있다. 자바를 만든 Sun에서 말하는 그 이유를 소개하면서 글을 마치고자 한다. 자바를 처음 시작하는 분이라면, 처음이 아니지만 한번도 자바 코딩 규칙에 대해서 들어본 적이 없는 자바 개발자라면 어렵지 않은 내용이니 꼭 한번 정독하시기를 추천한다.

80% of the lifetime cost of a piece of software goes to maintenance.
소프트웨어를 개발하는 일련의 모든 과정에 들어가는 비용 중 80%가 유지보수에 쓰여진다.

Hardly any software is maintained for its whole life by the original author.
소프트웨어의 유지보수를 그 소프트웨어를 직접 개발한 개발자가 담당하는 경우는 거의 보기 힘들다.

Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
코드 규칙을 지키면 다른 개발자가 그 소스코드를 처음 보았을 때, 더 빠른 시간안에 완벽하게 이해할 수 있도록 도와주기 때문에, 소프트웨어의 가독성이 높아진다.

PS. 예전 문서를 지금 보니 여기 저기 손댈 곳이 많아 보인다. 조만간 깔끔하게 업데이트를 해야겠다.