블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

2015년 개발 트랜드-조대협

IT 이야기/트렌드 | 2015.01.12 10:09 | Posted by 조대협

2015년 개발 트랜드


조대협입니다. 2015년 개발 트렌드에 대해서 간략하게 정리해봅니다. 여러 기술들을 보고 정리한 개인적인 생각이며, 앞으로 저도 집중하려고 하는 분야이기도 합니다.


애자일 및 협업 문화

애자일 과 수평 조직 기반의 개발 문화에 대한 현상은 올해에도 쭈욱 지속될 듯 합니다. 기존의 워터폴이나 경직된 조직 문화와 방법론으로는 현대의 빠른 서비스 개발을 따라갈 수 가 없져

애자일은 워낙 오래전 부터 언급되고 나온거라서 별도로 언급을 하지 않겠습니다만, 왜 이 부분을 2015년의 트랜드로 잡았느냐 하면, 국내 기업의 경우 애자일 프로세스만을 도입하는 것이 아니라, 조직의 구조나 문화 자체를 애자일 사상으로 옮겨가는 경우가 많이 보이기 때문입니다. 기존에 무늬만 애자일이었다면, 작년부터 올해까지는 애자일 문화를 적용하기 위한 직급을 없애고 직책(ROLE) 기반으로 일하기 위한 변화, 수평적 조직 구조, 그리고 스크럼 마스터와 프러덕트 오너등이 조직내에 점점 더 확실하게 자리 잡아 가는 것 같습니다.


MSA 아키텍쳐

작년 중반 부터 떠오르기 시작하더니 국내에도 많은 시스템들이 MSA 사상으로 구현되가고 있는 것들이 보입니다. 이제 시작 단계들로 보이는데, MSA를 적용을 하고 있는 조직들은 MSA가 가지고 있는 전통적인 문제들, 분산 트렌젝션에 대한 처리, 여러개의 API를 모아서 새로운 기능을 만들어내는 aggregation 개념들에서 많은 고민들을 하고 있는 것이 보입니다.

그리고 MSA를 개발하기 위한 개발환경을 셋팅하는데 많은 고민들을 하는데, MSA의 특성상 서버 컴포넌트가 많이 분산이 되고 폴리그랏(다양한 언어로 개발)현상이 조금씩 가속화 됨에 따라서, 이러한 복잡한 개발환경을 어떻게 개발자에게 전달할것인가가 새로운 키워드가 될 듯 합니다.

이에 대한 대안으로는 Docker등이 빠르게 떠오르고 있고, 사내/사외 개발용 클라우드를 구축 하는 움직임이 생기지 않을까 조심스럽게 점쳐 봅니다.

MSA를 적용함에 있어서 앞단에 api gateway (또는 proxy)역할을 하는 것들이 중요해지고 있는데, 현재는 대부분 직접 개발해서 사용하는 경우가 많습니다. 그 만큼 거기에 사용할 제대로된 제품이나 오픈소스가 없다는 것인데, (오픈소스는 현재 WSO2 api gateway, 상용 CA Layer7, 클라우드 기반 서비스 apigee) 아마 금년에는 이러한 needs 때문에 다양한 오픈소스가 나오지 않을까 조심스럽게 기대해봅니다. 2013년까지만 해도 API gateway 오픈 소스 제품들은 손에 꼽을 정도였는데, 작년말에 한번 만들어 볼까 하는 마음으로 살펴보니, 벌써 몇개의 오픈소스들이 시작되고 있더군요

그리고 MSA에 맞춰서, SpringBoot도 같이 올라가면서, 자바 진영의 개발 주류가 되지 않을까 생각해봅니다.


데이타 스트리밍 프로세스

빅데이타 영역은 하둡을 중심으로 어느정도 정리가 되었으나, 근래에 들어서 실시간 데이타 분석에 대한 니즈(needs)가 올라오면서 실시간 스트리밍 처리가 작년말부터 다시 주목 받는것 같습니다. 람다 아키텍쳐나 데이타레이크 아키텍쳐가 다시 언급되는 것도 같은 선상이라고 보는데, 금년에는 Storm,Spark 중심의 실시간 데이타 처리 기술이 다시금 부각되지 않을까 합니다.


머신 러닝의 보편화

머신 러닝은 수학 통계적인 지식이 있어야 접근할 수 있는 분야였지만, 근래에는 Apache Mahout등의 프레임웍으로, 주로 사용되는 머신 러닝 알고리즘 들은 대부분 프레임웍화 되어 있어서 접근이 매우 쉽습니다. 약간의 지식만으로도 머신러닝을 사용할 수 있다는 겁니다.

여기에, Microsoft Azure ML 서비스와, IBM의 왓슨 서비스들은 클라우드 기반으로 머신 러닝 알고리즘을 서비스하는데, 사용이 매우 쉬워서, 일반 개발자들도 쉽게 머신 러닝 알고리즘을 구현 및 운영 환경에 적용이 가능합니다.

다른 빅데이타 분석들도 이런 흐름을 따라가지 않을까 싶은데 제가 보는 관점에서는 ML쪽이 선두가 되서 서비스화되는 현상이 작년말 부터 시작되고, 금년에는 초기 활성화 단계에 들지 않을까 합니다.


폴리 그랏

작년에도 그랬지만, 금년에도 여러가지 프로그래밍 언어를 사용하는 폴리그랏 현상은 더욱 더 가속되지 않을까 합니다. Node.js등은 계속해서 약진할거 같고, Ruby,Groovy와 같은 기존의 스크립트 언어 뿐만 아니라 Google Go, MS가 이번에 Linux까지 자사의 프로그래밍 언어를 지원하겠다고 한 이마당에, 금년에 프로그래밍 언어의 흐름은 지켜볼만 합니다.


기타

자바스크립트의 약진, 자바스크립트 기반의 Pure 웹 클라이언트, 클라우드의 적용 가속화

이런것들은 워낙 뻔한 이야기이니 별도로 언급하지 않겠다. 다만 마지막으로 지켜볼것은 중국 IT 기술의 약진으로, 금년에 중국발 오픈소스나 기술들이 인터넷으로 조금씩 공개되지 않을까 기대해봅니다.


 

소프트웨어를 잘하고 싶으시면 개발자를 그만 뽑으세요.




<사진 : 태극기 휘날리며(영화)中>


간만의 포스팅입니다. 요즘 일도 너무 바쁘고 여유가 안생겨서, 그동안 포스팅을 거의 못했네요. 평소에 생각하던 내용인데, 요즘 들어 소프트웨어니, 서비스니 하면서 여기저기서 사람 뽑는 글들이 많아서 올려봅니다.


"소프트웨어를 잘하고 싶은데, 개발자를 뽑지 말라니??" 의아하게 생각하실지도 모르지만, 낚시 타이틀이 아니라 진정으로 드리고 싶은 이야기 입니다.

제가 해외 개발자들이나 엔지니어들과 일해봤을때, 한국 개발자가 실력적으로 그렇게 밀린다고 생각하지는 않습니다. 문제는 관리입니다.!!

아무리 똑똑한 개발자를 뽑아 놓는다 하더라도, 개발자들이 만들어야 할 소프트웨어의 구조를 잡을 아키텍트가 없고, 프로젝트를 위한 계획과 엔지니어에 대한 배치를 제대로 하지 못하면 개발은 제대로 이루어지지 않습니다.

좋은 아키텍트가 있고, 좋은 프로젝트 메니져와, 프로덕트 오너가 있는것은 두번째 조건이라고 생각합니다. 일단 있어야 합니다.

아키텍트가 기술적으로 실력이 떨어지더라도 아키텍트는 기술적 설계만이 본업이 아닙니다. 비지니스와 개발간을 연결하고 개발자간을 연결해서 전체 시스템에 대한 기술적인 그림을 보고 조율을 합니다.

프로젝트관리자 역시, 프로젝트 일정에 따라서 끊임없이 위험요소를 관리하고 우선순위를 조정해야 하며, 개발자원을 적절하게 투입해야 합니다.


즉 정리해서 말하면, 개발자보다는 제대로된 리더쉽을 갖추는 것이 중요합니다. 외부에서 좋은 리더쉽을 데리고올 수도있지만, 그런 리더쉽이 역할이 있는 팀 구조를 만드는 것이 선행되야하고 그 다음으로 그런 리더쉽을 가지고 있는 사람을 데려다가 배치해야 합니다.


국내 기업들이 소프트웨어를 강화하기 위해서 개발자 모시기에 여념이 없고, 내부적으로 개발자를 키우기 위한 프로그램도 진행하고, 뽑을때 미국 처럼 코딩 시험도 보는데.. 그건 그거고...

전쟁 나가는데 사병만 1000명 뽑으면 모합니까?? 통솔한 분대장도 필요하고 장군도 필요하고... 소총분대 분대장, 박격포 부대 분대장.. 기갑부대 분대장등 각 역할에 따라서 적절한 리더들을 잘 뽑는게 중요하지 않을까 싶습니다.


이제 개발자 그만 뽑으시고, 제대로된 program manager, product manager, architect,scrum master 등등 리더쉽 인력에 눈을 돌려봐야할 시기가 아닌가 싶습니다. 특히나 요즘 처럼 리모트 개발이 용이해지고 인건비 문제로 인해서 중국이나 인도 인력을 많이 사용하고 신기술은 미국에 있는 개발자들과 협업을 하는 지금 이러한 사람들을 잘 아울러서 관리하여 제대로된 소프트웨어를 만들어 낼 수 있는 조율자(Coordinator-코디네이터)의 역할이 앞으로 점점 더 중요해질 것 같습니다.


요즘 개발자 채용 트렌드를 보면 총든 병사들만 가지고 전쟁을 하려고 하는게 아닌가 싶습니다.... (인해전술도 아니고.. )


개발자의 잉여력

IT 이야기/IT와 사람 | 2013.03.14 23:42 | Posted by 조대협




오늘은 개발자의 잉여력에 대한 이야기를 해보려고 합니다.

잉여력이란... 남는 시간입니다. 근무시간도 좋고 집에서 쉬는 시간도 좋습니다.

개발자라는 특성상, 모두는 아니지만 대부분은 적어도 기술에 대한 흥미를 가지고 새로운 것을 접하는 것을 좋아 하는 특성상, 남는 시간에는 새로운 기술을 접하고 공부하고, 때로는 새로운 것을 만들어내기도 합니다.


이런 잉여력의 산실이 오픈소스와 블로그등입니다.

오픈소스는 누가 시켜서 하는 것도 아니고, 돈을 벌기 위해서도 아니고, 그냥 남는 시간에 재미있으니까는 하는일입니다.

개발자는 꼭 몬가를 시키지 않아도 스스로 공부를 합니다. 

왜 갑자기 이런 이야기를 하는가 하면, 국내 기업의 경우, 개발자의 잉여력을 발휘할 시간이 없습니다. 항상 바쁘기 때문이지요. 사실 문화적인 차이도 있는데, 미국이나 캐나다 같은 국가의 경우 개발자들이 밤샘 근무를 하거나 일이 많은 경우가 한국에 비하면 상대적으로 없습니다.

외국에 계신 분들 이야기를 들어보면 우스게 소리로 "한국 사람이 하루면 할일을, 여기서는 3일동안 한다."라고 하시더군요. 그렇지만 결과적으로 봤을때, 3배 느리게 일하면서도 전세계 IT 선두는 북미권에서 하고 있습니다.

구글도 근무 시간의 20%를 자체 연구나 프로젝트를 할 수 있도록 하는 것을 보면, 잉여력이 개발자와 같이 끊임 없는 공부와 창의력을 요구하는 분야에서 얼마나 중요하게 생각하는지를 알 수 있습니다.


한국 IT 문화도 많이 바뀌어 가고 있습니다. SKP나 KTH 같은 경우 개발자를 위한 많은 행사나 내부적으로 개발자를 중요하게 생각하는 문화가 생겨 나는 걸 봐도 그렇습니다. (KTH는 이제 그런 문화를 계속 볼 수 있을지 모르겠네요..)


일도, 생산성도 좋지만,개발자의 잉여력이 조금 더 발휘될 수 있는 문화가 되었으면 하는 생각에 몇자 적어봅니다.


제 블로그에 건담이 등장했습니다.



혹시 일본 애니메이션 건담을 보신 분들은 뉴타입이 몬지 아실겁니다.

신인류지요.. 보통 사람이 따라 잡을 수 없는 능력을 가지고 17:1 싸움에서도 이겨내는 주인공들입니다


갑자기 난대없이 왠 뉴타입 이야기냐 하면, 개발자들도 뉴타입이 되어야하는 시절이 왔습니다.

예전 4GL 시대에는 오라클,델파이,턱시도 정도 할줄 알면 됬습니다.

그다음 오픈환경이라는 J2EE 시대에서는 웹로직,EJB,JMS,오라클,Servlet/JSP 정도 하면 되었습니다. 

그 다음 온 오픈소스 시대까지는 견딜만 했습니다. ant,spring,ibatis,hibernate,struts

그런데.. IT 기술의 주도권이 엔터프라이즈에서 SNS등의 B2C로 오면서 상황이 모두 변했습니다.


전통적인 RDBMS 아키텍쳐는 이제 아주 귀한 레거시 같습니다.

RDBMS를 써도 MySQL로 replication,sharding,queryoffloading들을 고민해야 하고, NoSQL이 등장해서 hbase,mongodb,cassandra도 봐야합니다. 더욱이 한국에는 벤더도 없고, 교육 받을 수 있는데도 없습니다.

예저에는 그래도 빵빵한 서버에서 EMC 디스크와 L4 장비로 무장한 인프라 위에서 편하게 개발했습니다. 그런데 요즘은 클라우드라는 놈이 나타났는데, 클라우드는 하드웨어를 사지 않으니 TA가 안 붙습니다. 개발자가 알아서 인프라도 꾸며야 합니다.

subnet도 알아야 되고, L4도 알아야되고, san의 개념도 알아야 합니다.

RDS라고 DB서비스까지 있어서.. 이제 혼자서 DBA도 합니다.

이것만이면 좋겠습니다만, 클라우드 인프라는 무슨 제약들이 이리 많은지..애플리케이션 아키텍쳐도 새로 설계해야 합니다. 이전 빵빵한 하드웨어에서 돌아가던 아키텍쳐는 제대로 돌지도 않습니다 

아마존 클라우드는 만들려면 제대로 만들지 SLA가 99.95%라서 1년에 약 4시간 장애가 날 수 있습니다. 그래서 HA로 구현해야져... 아마존 제약사항때문에, 일반 하드웨어에서 되던 HA도 안돌아갑니다. ㅜㅡ....

아마존은 이야기 합니다. 그러니 그냥 RDS랑 SQS같은 서비스 쓰세요...

근데. 1TB밖에 저장안되는 DB랑, 순서 보장도 안되는 Q를 주고 너무하시네요... EC2에서 안되는 HA로 또 소프트웨어들을 인스톨해서 구성해봅니다.


결국 개발자는 뉴타입이 되야 합니다.

외국의 facebook이나 국내 카카오톡, 제니퍼등의 선진 업체들은 개발자를 중요시 합니다. 기술이 많으니 공부도 하고 준비도 하라는거겠지요..


예전에는 그나마 국내 서비스만 했으면 됩니다만, 요즘 설계하는 시스템은 보통 용량 산정하면 100만 사용자는 기본이고 보통 1000만.. 그리고 목표는 1억 사용자입니다. RDBMS가지고 설계하라구요? 헐~~ 입니다.


개발자는 이제 기술지원도 어려운 수많은 오픈소스를 가지고, 예전보다 1000배는 큰 시스템을 하드웨어 인프라까지 같이 설계해야 합니다. 진짜 뉴타입이 되야될거 같습니다.


그런데 뉴타입이 아니라서.. 조만간에 도태되지 않을까 걱정됩니다.

열심히 하기보다는 공부하는 아키텍트가 되야겠습니다.

요 몇년 코딩을 해본지가 꽤나 오래된것 같은데... 건담에서 자크 몰고 뉴타입에 빔샤벨 한방으로 베어지는 엑스트라보다는 뉴타입은 못되도 2~3화는 나오는 악당 정도는 되야 되지 않을까요?



요즘 예전의 해왔던 일의 경험을 최대한 쏟아 부어서 열정적으로 일을 하고 있습니다.
서비스도 기획해보고, 분석도 해보고, 딜 네고도 해보고, 사람도 뽑고, 예산 관리도 하고, 일정 조정도 하고 사람 관리도 하고, 테스트도 하고,튜닝도 하고, 설계도 하고, 설득도하고... 코딩 빼놓고는 대부분 다하는 군요..

시점이 바뀌다 보니까는 사람을 보는 눈도 조금 바뀌지 않았나 싶습니다.
요즘 IT 인력, 특히 개발자가 없다 보니까는 개발자 단가는 올라가고, 일의 강도도 쉽게 높일 수 없어지는 것 같습니다. 이제야 제대로 IT 인력들이 대접받기 시작하지 않나 싶은데, 아마 많은 시니어 개발자들이 IT의 길을 떠나거나 앱쪽으로 전향을 하고, 새로운 주니어 인력의 충원이 적기 때문에 한참 노련한 30대 중반 개발자들이 시장에 별로 없습니다.

개발자들이 제대로 된 대우를 받기 시작한것은 고무적인 일이지만
반대로 개발자들에 거품과 허영이 생기는 시기가 아닌가 싶습니다.
프리로 들어와서 일하지 않거나, 무조건 NO라고 이야기 하면서 방어적이거나...
야근... 안하는게 좋습니다. 저도 야근 개인적으로 무지 싫어합니다. 그런데 이런 사람들이 하는 이야기들을 보면 "미국에는 야근 안한다... 월급 많이준다... 등등입니다..."
미국.. 야근 잘~~ 안합니다만 필요하면 합니다... 예전 M社나 O社에 있을때도 같이 야근을 하거나 밤샘을 한일도 많았고, 이 친구들은 일을 조절을 하는 거지 않하는게 아닙니다. 집에 가서도 Conf Call로 회의를 할때가 잦고 문서 만들어와서 아침에 회의하자고 덤벼듭니다.

즉, '일'을 합니다. 자기 일에 대한 프라이드와 Owner ship이 있는데, 한국 개발자들은 떠넘기기, 방어하기에 바쁜것 같고.... 제대로 테스트가 되지 않은 코드로 QA를 밤새게 만들고, 튜닝에 들어가지 않아도 될 비용이 들어가게 합니다.

프로라면 실력을 가지고 자신이 맏은일에 필요한 역량을 발휘해야 하고, Commit한 목표에 대해서 ownership을 가지고 일하는 자세가 필요합니다.

요즘 IT 환경이 조금씩 변화되는 느낌을 받습니다만, 개발자들고 조금 더 프로스럽게 전향하는 모습들이 보였으면 합니다.
아마추어가 환경만 선진화 된것을 원하는 것은 부끄러운 일이 아닌가 싶습니다.

TAG 개발자

요즘 느끼는 한국 IT의 변화

IT 이야기/IT와 사람 | 2011.04.28 22:15 | Posted by 조대협
근래에 느끼는 것인데, 근래에 한국 IT 가 조금씩 바뀌어가는 것 같다.

첫번째는 대우? 또는 인력의 변화인데.
삼별전자가 기술 내재화를 목적으로 벤더의 협력사 엔지니어나, 벤더 엔지니어, 포탈 개발자들을 닥치는 데로 연봉 올려주면서 데리고 가고 있다. K티는 클라우드 한다고 하더니, 열심히 하는 클라우드 벤처와 망해가던 벤쳐(T?)에 있던 선수들을 데리고 가서 기술을 내재화하는 노력들을 하고 있다. (좋은 현상들입니다.!! 연봉 많이들 올려서 데리고 가세요..)
그리고 요즘 프로젝트를 해보면 SI사 인력들도 다르다... 지금 일하는 SI社 사무실에만 봐도.. 다들 영어 다 잘한다.. 외국 컨설턴트도 종종 보인다.. 영어만 잘하는 것이 아니라 논리적인 사람들이 많아졌다. 한마디로 꼰대님들은 안보이신다는.... ( 옛날에는 나 정도면 그럭 저럭 영어 하는 건데.... 경쟁력 저하.. ㅜㅡ )
이래저래 연봉을 알아보면, 벤더보다 많이 받는 사람들도 부지기수다.. 외국계 회사가면 돈 많이 받는다는 것은 이제 점점 바뀌어 가는듯...

두번째는.. 기술 적응력 향상.
얼마전만 해도 아범이나 에이취!!피!! 등의 벤더 기술들을 선호하던 댁업이 1~2년전부터 오픈소스에 맛을 들이기 시작했는데, 이것이 일시적인 현상으로 보이지 않는다. 물론 벤더 기술을 써야 하는데... 완성도 낮은 오픈 소스를 쓰시고 삽질하시는 어리석은 분들도 많으십니다만.. (필요할때는 써야 됩니다. 저라도 씁니다. 오픈 소스가 만능은 아님..)
여하튼.... 해외에서 어느정도 유행하는 기술들은 어줍지 않게라도 한국에 어느 기업에 적용되어 있다. (잘 적용된건 못봤슴다..)

세번째는... 서비스 문화에 대한 인식 변화..
아직 일반 개발자분들은 느끼지 못하는 부분일 수 도 있는데...(개발자 커뮤니티 사이트들을 보면..)
보통 벤더에서 제품을 구매하면, 엔지니어나 기술지원을 무료로 받을려는 성향이 강했다.
그런데. 1~2년 간 약간 변화가 보이는 듯 하더니, 작지만 서비스는 돈이라는 개념이 조금씩 정립되어 가는 것 같다.
엔지니어가 원래 제품 하루 설치하러가면 보통 100~150정도를 받는다.
예전에는 오히려 성을 내는 사람들이 많았는데.. 요즘은 그려려니 하거나. 좋은 엔지니어를 미리 시간을 사두는 경우도 있다.

제가 느끼는 작은 변화지만..그 오랜 기간 동안 안변화하다가 그나마 근래에 조금이라도 변화가 보입니다. 몇몇 제대로된 생각이 박히신 분들이.. 대기업(갑)에 경력으로 들어가면서 꾸준히 만들어낸 문화의 변화라고 봅니다.

우리도 쉴때 쉬고. 일할때 일하고. 대접받을 때 대접받으면서...
극한의 아이디어와 기술을 짜낼 수 있는 환경이 왔으면 좋겠습니다.
그렇게 될거 같아요..

요즘 프로젝트가 바쁘다 보니, 블로그에 포스팅할 시간이 없다.
REST, ROA (Resource Oriented Architecture), Collaboration, Code Review등 포스팅 하고 싶은 것들이 많은데.. 그나마 시간내서 쓰던 포스팅들도 이번달에는 거의 힘든 상태가 되었다. 아마도 다음달이나 되야, 포스팅들이 올라가지 않을까?

이번 글은 어제 저녁에 써놨던 아키텍트,PM,개발자의 차이 중 2번째로 아키텍트에 대해서 이야기 해보고자 한다.

아키텍트

아키텍트는 전체 시스템을 디자인하고 설계하는 역할을 가지는 사람이다.
아키텍처링은 크게 두가지로 나뉘어 지는데 첫번째는 비지니스 아키텍쳐, 다음은 테크니컬 아키텍쳐이다.
비 지니스 아키텍쳐랑, 해당 시스템이 비지니스적으로 어떤 의미를 갖는지에 대한 내용으로 사업 전략,비젼,요구사항 분석과 같은 범주와 관련이 된다. 시스템의 구현 목적은 어떤 비지니스의 목적을 달성하기 위함이다. 사업 전략이야 COO 분들이나, 아니면 비지니스 컨설턴트가 진행을 하기는 하지만, 비지니스 요건을 어떻게 시스템으로 구현하여 효과를 낼지는 IT 아키텍트의 역할이다. 그래서, 비지니스에 대한 아키텍쳐링도 매우 중요하다.
다음이 테크니컬 아키텍쳐인데, 전체 시스템의 그림을 그리고, 비지니스 요건을 충족하기 위한 기술적인 설계를 하는 역할이다.
 강조하고자 하는 바는 비지니스 요건을 잘 이해해야 한다는 것이다.
예를 들어 분산 트렌젝션 요건이 있다고 하자. "주문과 결재" 두가지 기능을 묶어야 할경우, 여러가지 선택이 있다.
XA기반의 분산 트렌젝션을 사용하는 방법, 보상 트렌젝션 처리, 로깅을 통해서 유실분에 대한 처리, 아니면 유실되는 것 데로 놔두는 것...
고급 기능과 아키텍쳐에는 돈이 든다. 물론 XA기반으로 구현하면 좋겠지만, 해당 시스템이 느린 경우 LOCK 경합 문제가 발생할 수 도 있고, 복잡도가 높아지는 만큼 테스팅에 대한 코스트도 높아진다.
 유료 회원 가입 프로세스 경우 차라리 에러가 나는데로 놔두는 것이 비용 측면에서 훨씬 유리할 수 있다. 공짜로 가입되었다고 Complain할 사람은 그리 없으니까는.
 즉. 완벽한 보안 장치를 하기 위해서, 서랍에 자물쇠를 하느냐 몇천만원짜리 지문 인식 장치를 하느냐가 아닐까?

아키텍트의 능력 중에서 중요한 것은

숲을 보는 능력
아키텍트는 전체 시스템을 보는 능력이 매우 중요하다. 개개의 시스템과 구현 방법에 대해서는(나무를 보는 능력) Senior Developer만으로도 충분하다. 전체 시스템을 조망하고, 그 방향을 잡는 조타수의 역할이 아키텍트이다.

기술에 대한 폭 넓은 지식
제대로 된 설계를 하기 위해서는 어떤 기술이 적절한지 장단점과 위험 요소는 무엇인지를 파악해서 적재 적소에 알맞은 기술을 배치해야 한다. 아니면. 결국 벤더 영업이나 마케터 손에 놀아나게된다. 마치 피라미드 그룹에 걸린것 처럼.

현실을 인지하는 능력
아키텍쳐는 현실적이라야 한다. 아무리 좋은 아키텍쳐라도 금액과, 수행하는 팀원의 능력에 맞지 않으면 말짱 도루묵이다. 적절한 시간과 Learning Curve에 드는 시간도 충분히 고려되어야 한다.

그리고 인맥
왠 갑자기 인맥이냐라고 할 수 있지만. 아무리 뛰어난 아키텍트라도 여러 프로젝트를 경험해보기는 쉽지 않다. 인맥을 통해서, 경험을 공유하고, 문서 템플릿, Reference Architecture, Delivery methodology등을 수집할 수 있는 것은 좀더 안정적이고 성숙된 아키텍쳐를 설계할 수 있는 빠르고 확실한 방법을 제공한다.

커뮤니케이션
아키텍쳐는 기존의 아키텍쳐나 이해관계, 또는 새로운 도전등에 대한 반감에 부딪히기 쉽다. 이를 논리적으로 설득하고, 함께 일할 수 있는 협업 분위기를 만드는것 역시 아키텍트의 역할이다.

프로젝트를 하다보면 많은 AA (Application Architect)를 만난다. 프로젝트의 꽃이자 기술의 마지노선이 AA이다.
그런데 국내 AA를 보면, 숲보다는 나무를 보는 경우가 많고, 중반 이후에는 아키텍쳐에 대한 책임을 지지 않으려는 방어적인 자세로 가는 경우를 종종 봐 왔다. 실제적으로 AA에 대한 시간 배정과 역할에 대한 이해가 부족한 면도 있고. AA 들 자체가 좀더 전략적인 사고 를 가질 필요가 있다.