20분간의 Coffee Break뒤에 1시간가량의 "에릭에게 무엇이든 물어보세요"라는 Q&A시간이 있었습니다. 아무래도 워낙 유명하신 분이니 처음에는 질문이 약간 주춤하는 듯 하더니 나중에 시간이 모자랄만큼 질문이 쏟아졌습니다. 제가 잘 모르는 부분도 있고 이해못한 것도 있어서 다 정리는 못하고 이해한 정도로만 정리하였습니다.
Q. 애자일을 팀에 적용하려면 찬성하는 사람도 있지만 반대하는 사람도 있는데 어떻게 도입을 하는가?
A. 반감이 있는 사람과 1:1로 함께 개발을 해보는 것이 좋다. 그 사람이 장점을 직접 경험해 보아야 깨닫는다.
Q. 요구사항에 대한 특별한 관리법이 있는가?
A. 요구사항은 항상 바뀔 수밖에 없다. 쉽지 않은 문제다.
Q. 한국에서 개발자들의 처우는 별로 좋지 않은데 다른 나라의 개발자 문화는 어떠한가?
A. 문화권별로 차이는 있지만 스트레스가 많은 업무이다. 항상 과도한 업무를 진행할 수는 없기 때문에 집중적으로 일하는 시기와 릴렉스 할 수 있는 시기가 파도처럼 번갈아가면서 오는 것이 좋다.
Q. RTC가 너무 기능이 많아서 시러하는 사람도 있는데 이런 사람들은 어떻게 설득하는가?
A. 중요한 것은 자기 일을 공유안하면 안되다는 이해가 필요하다는 것이다. 이것은 팀 차원의 개념 공유가 필요하고 RTC는 개별 팀원별로는 없고 팀레벨의 리포트만 있기 때문에 개인을 감시하기 위한 것은 아니다.
Q. 에릭감마가 디자인 패턴의 세계를 열었으나 소프트웨어 크리에이티브 책을 보면 대개 직관에 의해서 설계를 한다는 이야기가 있다. 현실의 세계는 너무 다양하기 때문에 경험에 의존하여 한다는 것이고 실제 Problem Domain의 정의가 여렵기 때문이다. RTC도 어떤 표준을 제공한다고 할 수 있는데 현실에 맞추기에는 어렵지 않은가?
A. 과거의 일로 배우는 것은 중요하다고 생각하며 경험과 직관 모두에 의존해야 한다. 경험이 많을수록 어떤 Pattern이 떠오르게 되지만 경험이 없으면 알려진 Pattern등으로 다른 사람의 경험을 활용할 수 있다. Pattern을 이용해도 이것을 Template처럼 어디에나 적용하려고 하면 안되고 Pattern에서 시작해서 상황에 따라 적용해야하며 이런 점에서 패턴과 직관이 완전히 다른 얘기는 아니다.
책에 나오지 않은 패턴도 생각해야하고 책이 나온지 오래됐기 때문에 실제로 너무 오래된 패턴들도 많은 것이 사실이다.
Q. API설계시 어떤 기준을 가지고 정의하는가?
A. 사용의 용의성과 이해하기 쉬움이 가장 큰 기준이다. API의 사용 용이성을 평가하기 가장 좋은 방법이 Unit Test이며 또한 고객의 피드백도 좋은 방법이 된다.
Q. 엔터프라이즈 아키텍쳐에서는 실제 구현되는 소프트웨어와 문서가 동일하지 않은 것이 가장 큰 불만중의 하나인데 Jazz에서는 이 문제를 어떻게 해결하는가?
A. 현재 RTC는 Construction과 Development의 협업에 대해서만 초점을 맞추고 있다. 차후 계획은 가지고 있지만 아직은 안되고 있다.
Q. Jazz 대쉬보드가 Dojo로 만들어졌는데 사용해 보니 Dojo가 좀 느린 편인데 Jazz에서 사용할 때 속도 개선방법들이 있는가?
A. CSS모듈처리, 압축 등 상당히 많은 튜닝을 가했으며 쉽지 않은 작업니다.
 |  |
Q. 투명성(Transparency)에 대해서...
A. 투명성은 양방향이 중요하다. 팀장이 팀원들의 일에 대해서 알고 팀원들은 팀장의 일에 대한 정보를 알아야 한다.
Q. Jazz를 디자인할 때 가장 중점둔 것은 무엇인가?
A. 실제 존재하는 Pain Point를 해결하는 것이 목적이었으며 버전에 대한 의존성에 대해 많은 고민이 있었으며 이것을 REST베이스와 Loose Coupling으로 해결을 했다. 최초부터 완벽한 디자인은 없으며 계속 진화해 나아가야 하며 사실 처음 디자인한 것은 너무 복잡해서 확장이 불가능했으며 피드백 받아서 심플하게 변경하였다. 디자인은 쉽지 않은 일이다.
Q. 퀄리티 매니저를 만드는 이유는 무엇인가?
A. 테스트 관리는 좀 더 협업이 필요하다. 개발과 테스트는 보통 협업이 잘 안되고 있으며 테스터는 왜 이렇게 개발했는지 모르고 개발은 테스트하기 위해서 기다리고 있다는 것 조차 모른다. 협업이 목적이다. 이미 나온 테스트툴들도 많기 때문에 이런 툴들과의 통합도 필요하며 고객이 툴을 선택해서 REST로 통합하는 구조가 궁극적인 목표이고 이것이 OSLC이다.
A. A에서 B로 가는 길을 찾는데 피드백을 받고 테스트를 하면서 가장 효율적으로 가는 것이며 이게 문제를 해결하는 방법이다. 개발자라는 Job이 흥미로운 이유는 어떤 때에는 이미 한 것을 다시 하기도 하지만 어떤 때에는 완전히 새로운 것을 한다는 것이다. 그래서 행복감을 느낀다.
Q. Jazz가 PMS(Project Management System)인데 실제로 쓰이고 있는 곳이 있는가? 한국에서는 개발자들은 RTC나 Trac같은 툴로 인수인계가 가능하고 도움이 되지만 산출물로 문서작업을 많이 하게 되는데 해외에서는 문서가 아닌 이런 툴로 산출물의 역할을 하기도 하는가?
A. Jazz는 플랫폼이고 그 위에 많은 Product가 올라간다. RTC는 애자일을 서포트하는 역할이며 전통적인 방법론을 지원하는 툴은 따로 또 있다. 애자일만을 위해서 RTC라는 툴을 분리한 이유는 애자일은 초기에 설계하는 방식부터 접근방법자체가 완전히 다르기 때문이다. Jazz가 산출물을 위한 리파지토리도 제공하기 때문에 도움이 될 것이다.
Q. 당연한 방향이기는 하지만 Eclipse가 점점 커지고 있고 Plugin 개발자는 알아야 될 것도 많고 인수인계를 해야할 내용도 점점 많아지고 있다. 반갑지많은 않은 일인데 계속 이런 방향으로 진행될 예정인가? 그리고 Eclipse나 RTC 개발자가 이런 방향을 바라보는 자세는 어떠해야 하는가?
A. 이런 추세를 바라고 있는 것은 아니지만 피할 수는 없다. 이런 문제는 이클립스 팀도 충분히 인식하고 있으며 고민하고 여러가지 실험도 하고 있다. 궁극적인 추구는 역할(Role) 베이스로 가는 것인제 Role에 대한 정의가 쉽지 않아서 진행이 빠르지는 않다. 반가운 것은 점점 웹UI로 옮겨가는 단계이기 때문에 좀더 쉬워질 가능성이 높아지고 있다.
또하나 중요한 것은 이클립스 베이스로 Role에 맞게 UI를 변경가능하도록 되어야 한다. 이미 이런 기술을 가지고 있으며 복잡성을 해결하기 위한 방법중 하나이다.
네임밸류가 역시 있어서 그런지 세미나 끝나고 싸인회도 하더군요. 이럴 줄 알았으면 싸인받을 책이라도 하나 준비해 가는 건데 그랬습니다. 에릭감마랑 사진도 찍어주었는데 부끄러워서(?) 싸인만 받아왔습니다.
세미나 참가선물로 준 마우스 패드의 에릭감마의 싸인을 받아왔습니다. 아까워서 쓰지도 못하겠군요... 패턴책이라도 하나 가져가져 싸인받았어야 했는데 아쉽군요. ㅎ
PS. IBM에서 이 행사의 동영상 다시보기를 제공해 주는군요. - 09.10.30 -
좋은 후기 잘 읽었습니다.
감사합니다.