아키텍트로서 성장하기 위한 길은 막막하게 느껴지곤 한다. 누구에게 아키텍트로서 가야 하는 길을 물어야 할 것인가? 산전수전 다 겪은 나이가 지긋한 아키텍트로 활동 중인 사람을 만나기란 하늘의 별따기다. 따라서 필자는 업계 최고의 아키텍트들의 조언을 모아 가상의 인터뷰를 진행해 봤다. 이 인터뷰의 내용은 필자가 PLoP라는 패턴학회에서 만난 해외 거장들과의 토론과 조만간 출간될 번역서인 『아키텍트가 알아야 할 97가지』의 내용을 모아 만들었다.
손영수 안녕하십니까? 여러 선배님들. 아직 ‘Architecture’의 ‘A’자도 깨우치지 못했지만, 여러 선배님들에게 아키텍트로 성장하기 위한 방법과 또 아키텍트로서 올바른 아키텍처를 바라보는 방법들을 여쭤 보고자 합니다. 많은 이들이 궁금해 하는 질문일텐데, 여러 선배님들처럼 훌륭한 아키텍트가 되기 위해선 어떠한 것들을 준비해야 할까요? 실제 현업에서 아키텍팅할 때 어떠한 부분을 고려해야 할지 여러분들의 얘기를 듣고 싶습니다.
마소 (마이크로 소프트웨어 ) 5월호에 “EVA네가 들려주는 Fearless Change 두 번째 이야기“라는 주제로 글을 기고했습니다.
원래 4월에 실릴 예정이었으나, 이런 저런 내부 사정으로 5월에 실리게 되었습니다. 이미 저의 블로그를 구독하시는 분에게는 싱거운 자료지만, 자료 공유 차원에서 올립니다.
물론 기고한 글은 모두 저의 지식이 아니며, Linda Rising의 지식과 다양한 분야의 경험을 가진 저희 EVA팀의 지식으로 만들어진 자료입니다. 지식을 나누어 주신 EVA 식구 여러분 감사합니다. 전 단지 정리를 했을 뿐입니다.
EVA 팀이 없었다면 이렇게 좋은 자료가 나온다는 것은 불가능했을 겁니다. EVA팀 감사합니다. 다음과 같은 내용이 기고 되었습니다.
마소 (마이크로 소프트웨어 ) 2월호에 “조직을 변화시키는 패턴 이야기“라는 주제로 글을 기고했습니다.
지금까지 블로그를 통해 공개한 Fearless Change 포스트를 거의 그대로 올린겁니다. 이미 저의 블로그를 구독하시는 분에게는 싱거운 자료지만, 자료 공유 차원에서 올립니다. 많은 분들에게 도움이 되었으면 하네요 🙂
물론 기고한 글은 모두 저의 지식이 아니며, Linda Rising의 지식과 다양한 분야의 경험을 가진 저희 EVA팀의 지식으로 만들어진 자료입니다. EVA 팀이 없었다면 이렇게 좋은 자료가 나온다는 것은 불가능했을 겁니다. EVA팀 감사합니다.
“패턴을 좀더 쉽게 학습하고 실제 프로젝트에 잘 적용할 방법이 없을까요?” 필자가 강의를 마치고 종종 듣는 질문이다. 부족하지만 필자가 공부한 패턴 지식들과 경험들을 합쳐, 독자 여러분에게 패턴을 학습, 활용하기 위한 시행착오를 조금이나마 줄일 수 있는 지름길을 안내하고자 한다.
손 영수 arload@live.com | 데브피아 Architecture 시삽과 Microsoft MVP로 활동 중이며, 데브피아 소프트웨어 공학 스터디인 Eva팀의 리더이다. 부족한 실력이지만 지식을 나눌 때는 누구보다 ‘부자’라는 자부심을 가지고 지식 나눔에 힘쓰고 있다. Pattern 전도사를 꿈꾸고 있으며, PLoP와 같은 Pattern 학회를 국내에 만들기 위해 힘 쏟고 있다.
요즘은 대학교 학부생의 교과 과정으로 들어갈 정도로 패턴은 많은 이들에게 알려져있다.. 하지만 필자 주위에는 패턴을 잘 활용하여, 성공적으로 프로젝트를 마무리 했다거나 좋은 결과를 보았다는 말보다는, 오히려 많은 불신들과 하소연을 들었다. 왜 이런 상황이 발생했을까? 이 글을 통해 독자들이 패턴에 오해를 풀고, 올바른 시선을 가지길 바라며 글을 적는다.
패턴을 대하기 이전에 마음가짐 – 유연성, 확장성
많은 분들과 패턴을 주제로 애기하다 보면, 패턴에 대한 잘못된 관점을 가진 분들을 종종 만난다. 패턴을 통해, 비약적인 성능 향상, 생산성이 증대 될거라 생각하는 분도 있고 심지어 Silver Bullet (은총알)로 생각하는 분도 있다. 물론 제한적인 도메인 안에서 성능, 생산성 향상을 가져 올 수 있는 패턴도 있지만, 패턴 자체의 목적은 유연성과 확장성에 초점을 맞추고 있다.
초창기 객체 지향(80년대)의 가장 중요시 여기는 패러다임은 “Reuse (재사용)” 이였다. 그래서 Component와 같은 이상적인 패러다임이 나오기도 했다. 마치 Lego와 같이 조립만 하면 만들어지는 Legoware를 꿈꾸어 오면서…
하지만 현재 소프트웨어는 어떠한가? 빈번하게 바뀌는 고객의 요구사항, 몇 명 이서 만들 수가 없을 정도로 거대해진 규모, 길어진 소프트웨어 생명주기를 가진 녀석들이 대부분이다. 그렇기 때문에 소프트웨어가 가져야 할 중요한 설계 방향이 재 사용성 보다는 쉽게 변화를 수용할 수 있는 유연성(Flexibility)과 확장성(Extensibility)이 대두되게 되었다. 만약 여러분이 유연성과 확장성에 초점을 맞춘 설계에 관심이 있다면, 패턴은 좋은 도구가 된다. 하지만, 최적화나 성능 개선이 목적이시라면 패턴보다는 알고리즘을 공부하는 것이 더 낫다.
그리고 패턴을 쉽사리 적용하지 못하는 여러 가지 장벽들이 곳곳에 존재한다. 패턴에 대한 불신들이다. 지면상의 제약으로 이 모든 내용을 언급하기가 한계가 있으니 예전에 필자가 마소 2007년 8월호에 기고한 “미워도 다시 보는 패턴 이야기”를 꼭 읽어보길 권한다. 패턴의 정의, 원칙, 참고할만한 설계구조도 설명하고 있다.
2월 기고에 이은 Framework Engineering Part II를 여러분에게 공개합니다.
Part I에 대한 글에 대한 평이 없어서? 과연 좋은 글을 썼는가 다시 의문을 가집니다. 😦
.NET 진영은 Java 진영보다직접 Framework를 구축하는 일 보다는, 사용하는 일이 더 많으니 그러겠지 하고 혼자 생각하고 있습니다. 🙂
여기서 소개한 툴들과 거의 일대일 대칭이 되는 툴들이 Java 진영에도 있으니 Technic 적인 측면보다, Framework를 구축할때 어떠한 것들을 고려해야 되는지 경험과 프로세스 측면에서 저희들의 부족한 글을 이해해 주시길 부탁드립니다.
많이 부족한 지식이지만 조금이나마 다른 분들에게 도움이 되는 글이였으면 좋겠네요 🙂
이번 글은 지난호에 이어 아래의 주제들중 아키텍쳐에 다 못다한 애기부터 다루었습니다.
마소 1월호 주제인 Application과 Framework 동시 개발하기에 이어, 2월호에는 Framework 설계시 실제 필요한 Engineering 기법들에 대해 기고했습니다. 물론 결코 저의 머리에서 나온 것은 아닙니다. 🙂
이 글은 .NET Framework를 설계한 Krzysztof Cwalina의 TechED 강의 내용과 저의 지식을 덧분인 글입니다.
Krzysztof Cwalina의 강좌를 보시고 싶으신 분은 여기를 클릭하시길 바랍니다.
12월호 있었던 세미나와 지금까지 블로그에 기고한 Post들을 모은 내용이기 때문에, 저의 블로그 독자 분들(?)에게는 미안하네요 🙂
이번 글은 크게 6가지 주제들을 다룹니다.
● 조직 (가장 강력한 설계 툴)
● 계획 (프레임워크를 올바르게 구축하 기 위한 계획)
● 아키텍처 (오랫동안 사용할 수 있는 품질 좋은 프레임워크를 만들기 위한 고려사항들)
● 설계 (품질을 보장하기 위해 고려할 사항들)
● 개발 (프레임워크를 만들기 위해 팀플레이 시 고려해야 되는 사항들)
● 그 외에 고려해야 되는 것들 (가독성, 문서화)
이중 조직, 계획, 아키텍쳐에 대한 내용을 2월호에 다루었습니다.
12월에 진행했던 Framework’s Day 세미나의 내용들을 연달아 마소에 기고하고자 합니다.
거리상의 제약으로 참가하지시 못했던 분이나, 관심 있었던 분들에게 도움이 되었으면 합니다. 🙂
Framework’s Day에서 Framework에 대한 기본 개론과 Ralph Johnson의 Evolving Framework에 대한 이야기는 이미 2008년 11, 12월호에 김용현님이 작성을 해주셨구요.
그 뒤를 이어 Framework Design Guidelines 2nd Edition 번역 팀들이 실제 Framework를 구축히 만날수 있는 문제들에 대한 글을 기고하고자 합니다.
그리고 권효중님이 iBatis.NET과 Spring.NET에 대한 애기들을 진행 함으로써, 총 7회의 Framework 강좌가 마치게 됩니다.
세미나시 진행했던 ASP.NET MVC Framework와 ADO.NET Entitiy Framework은 이미 예전에 장현희님과 한용희님이 마소의 연재로 기고하셔서, 이번 Framework 강좌에서는 포함되어 있지 않습니다. 🙂
이번 기고 내용인 Application과 Framework 동시 개발하기 에 대한 주제는, 예전에 포스팅한 “성공적인 Framework 구축” 에 대한 연장 선상에 있는 글입니다.
마감이 되기 7일전 마이크로 소프트웨어에 갑작스런 기고 요청이 들어왔습니다. 슈퍼 개발자의 꿈이라는 글이였습니다.
하지만 전 고수도 아니고, 아주 생산성이 뛰어난 개발자도 아니라서 많이 고심을 했습니다. 부족하지만 어떤 글을 적어야 후배 개발자들에게 도움이 될까?
결국 제가 지금까지 블로깅 한 글들과 저의 경험을 덧 붙여 이번에 기고를 했습니다. 미리 포스팅한 글들을 짜집기 한거라고 혼내시는 분도 있겠지만, 저의 블로그를 모르시는 분들에게 몇일안에 갑작스러운 글을 만드는 것 보다는 평상시 제가 아껴 쓴 좋은 글들을 대접해드리고 싶어서 였습니다.
사람의 네가지 종류와 꿈에 대한 이야기들이 더 추가되었으니, 너그러이 이해해 주시길 바랍니다.
생산성 향상은 과연 개발자 개개인의 능력에만 달려있는 문제일까요? 생산성 높은 툴, 언어, 프레임워크를 이용하는 것 이상으로, 팀플레이가 생산성에 미치는 영향력 역시 매우 큽니다.
생산적이고, 단결력 있는 팀을 만들기 위해선 어떻게 해야 할까요? 이 화두에 대한 전문가의 경험을 여러분과 함께 공유합니다.
팀 생산성 향상은 개발자 뿐만 아니라 프로젝트 관리자에게도 관심 있는 부분일 겁니다. 대부분의 패턴들은 소프트웨어 설계에 초점이 맞추어져 있습니다. 그러나 독특하게 조직구조와 협력을 위한 패턴들(“Capable, Productive and Satisfied : Patterns for Productivity”)이 PLOP 학회에서 발표 되었습니다.
여기서 소개되는 패턴들과 저의 부족한 경험과 지식을 엮어 팀 생산성 향상을 위한 패턴 이야기를 풀어보고자 합니다.
마소 (마이크로 소프트웨어) 4월호에 SaaS로 가는 길 이라는 주제로 개발자로써 SaaS를 준비하기 위해서 어떠한 것들을 준비해야 되는지, 그리고 역사, 미래등에 대해서 다루었습니다.
요즘 SaaS에 대해서 많은 분들이 장미빛 애기를 하고 있습니다.
하지만 그 것은 대부분 Business 적인 측면이며, 그 이면에는 시스템을 구축하는 개발자에게는 저주에 가까울 정도의 고통을 요구합니다.
SaaS중 가장 많이 활성화 될 Web 2.0 기반의 SaaS를 구축할때는 여러분이 만나야 되는 괴물이 아래에 있습니다
Architecture 101 