소프트웨어 아키텍트의 길은 멀고 험난합니다. 그 와중에 조금이나마 아키텍트를 꿈꾸거나, 진입하시는 분들을 위한 과정을 진행하고 있습니다. 이미 다양한 대기업에서 강의를 했습니다. 수업의 커리큘럼은 다음과 같습니다. 관심있는 기업 교육자 담당자 분들은 연락을 주시면 됩니다. 시간당 25만원이 아니면 강의를 하지 않습니다. 시간당 20만원의 요청이 제법있는데, 안 하기로 했습니다. 다만 수도권이 아닌 지방이라면 지식 공유를 위해 훨씬 저렴하게 […]

[1]이 글에서는 Uber와 같은 택시 애플리케이션 서비스의 아키텍처 및 시스템 설계에 대해 배워보고자 합니다. Uber 애플리케이션에서 탑승자(CAB를 원하는 사람)가 앱에서 드라이버를 요청하면 해당 사용자를 선택하기 위해 드라이버가 이동합니다. 이면에는 여행을 지원하는 1,000대의 서버가 있으며 여행에 테라바이트의 데이터가 사용되었습니다. Uber 회사가 시작되었을 때 그들은 단순한 모놀리식(monolithic) 아키텍처를 가졌습니다. 백엔드 서비스, 프런트 엔드 서비스 및 데이터베이스가 있었습니다. […]

지앤선에서 진행한 “아키텍트가 알아야 할 97가지 Face 2 Face ” 행사가 성공적으로 마쳤습니다. 독자들과 한발짝 다가가서 더 많은 이야기를 나눌수 있어서 좋았습니다. 아래와 같은 주제들을 60분간 나누었습니다. 소프트웨어 아키텍트가 알아야 할 97가지 어떤 책인가? 아키텍트는 신기술에 대한 이해가 필수적인데 어떻게 기술을 접하고 있나요 국내에서 아키텍트가 되는 법 아키텍트는 코딩을 잘 해야 한다. 기획자로 일하는 것이 […]

“아키텍트가 알아야 할 97가지 것들” 에서 저에게 가장 와 닿는 에피소드입니다.   기술도 중요하지만, 더 중요한 것은 기회를 잡을 수 있냐다 라는 말이 너무나 가슴깊이 와 닿았습니다. 결국 사람들과 어떠한 관계를 가지느냐에 따라, 그 모듈의 관계 역시 정해 지는 거죠.   기술 매우 중요하지만, 그것 보다는 어떻게 팀원들과 하나되어 서로의 단점을 상쇄시키고, 장점을 강화 시킬수 있을까요? 이게 요즘 저의 가장 큰 숙제인거 같습니다.

지금 이순간에도 실패한 급여 시스템 프로젝트를 진행하고 있는 사람이  아마 한 명 이상 있을 것입니다.

왜 그런걸까요? 자바 대신 루비를 선택하거나, Smalltalk 대신 파이썬을 선택했기 때문일까요? 혹은 오라클 대신에 포스트그레스를 사용하기로 결정했기 때문일까요? 혹은 리눅스를 선택했어야 했는데 윈도우를 선택했기 때문일까요?

실패한 프로젝트에서 사용한 기술이 전락하는 것을 우리 모두는 보아왔습니다. 하지만 문제가 정말 해결하기 너무 어려워서 자바가 해당 업무에 적합하지 않았다라는 것은 무엇을 의미하는 것일까요?

대부분의 프로젝트들은 사람에 의해 만들어지며, 사람들은 성공과 실패에 대한 기반이 됩니다. 따라서, 사람들을 성공할 수 있게 만드는데 도움이 되는 것에 대해 생각해 볼 필요가 있습니다.

한편으로는, “단지 일을 올바로 하지 않고” 프로젝트를 어렵게 하는 누군가가 있다는 가망성에 대해 충분히 생각해 볼 수 있습니다.

계속 읽기

저희 Eva팀이 드디어 두 번째 프로젝트인 “97 things every software architect should know (가제 – 모든 아키텍트라면 알아야 할 97가지 이야기)” 에 대한 1차 번역을 마쳤습니다.

2 달만에 번역하기 프로젝트를 시도했지만, 예상외로 아키텍트 특유의 고급적인 문체, 시와 같이 운율을 살리는 비유, 해당 도메인의 지식 부재등으로 약간의 난전을 겪었습니다.

그래서 3달 만에 1차 번역이 마치게 되었네요. 내부적으로 1차 리뷰를 마치고 출판사에 맡겼지만 아직 손봐야 할 것이 여러군 데 있는 건 사실입니다.  어느정도 책의 형태가 나오면 베타리더를 모아 더 다듬어야 겠죠.

계속 읽기

dave quick범위는 프로젝트의 크기를 언급합니다.

얼마나 많은 시간, 노력, 자원들이 필요한가?. 어떤 수준의 품질에서 어떤 기능성을 가지는지? 얼마나 많은 위험이 있는지? 어떠한 제약이 존재하는지? 이에 대한 대답들이 프로젝트의 범위를 정의합니다.

소프트웨어 아키텍트들은 크고, 복잡한 프로젝트에 도전하는 것을 사랑합니다. 잠재적인 보상은 사람들이 인위적으로 프로젝트 외관상의 중요성을 증가시키기 위해 프로젝트의 범위를 인위적으로 확장하게 유혹할 수 있습니다.

범위를 확장하는 것은 성공의 적입니다, 왜냐하면 실패할 가능성이 예상했던 것보다 더 빨리 증가하기 때문입니다.

프로젝트의 범위를 2배로 증가시키는 것은 종종 실패의 가능성을 10배로 높입니다. 왜 이렇게 실패 가능성이 높아질까요? 몇 가지 예 들을 살펴봅시다.

직감은 일을 두 배로 일을 하기 위해 우리의 시간이나 자원을 두 배로 늘리라고 말합니다.

역사[1]는 ,직관이 제안했던 것처럼,  미치는 영향이 선형적으로 증가(두배로 일하기 위해 미치는 영향이 단시 시간과 자원을 두배로늘리는 것)하지 않는다고 말합니다. 예를 들어나 네 명의 팀은 두 명의 팀이 커뮤니케이션 하는 것보다 2배 이상의  커뮤니케이션 비용이 들것입니다.

계속 읽기

안녕하십니까 저의 블로그 독자 여러분 🙂

드디어 패턴, 소프트웨어 공학 이슈 그리고 닷넷 관련 강좌들을 모아 놓은 EvaCast를 블로그 형태로 리뉴얼 했습니다.

거의 80개의 가까운 강좌가 등록되었으며, 모두 무료입니다

이 EvaCast는 양질의 컨텐츠를 생성하기 위해, 여러번의 재 발표를 감행해서 만든 저희 스터디 팀의 노력의 결정체라고 할수 있습니다. 

묵묵히 4년의 시간동안 고난의 길을 같이 걸어주신 스터디 팀원들에게 매우 감사드립니다.

9월 4일 기준으로 데브피아의 메인 화면에 서비스로 등록되었고, http://www.EvaCast.net 이라는 도메인을 통해서도 접근 가능합니다.

이번에 저희 스터팀 내부 협의로 Presentation 파일 외에도  동영상 파일을 무료 공개했습니다.  

다운 받으셔서, 얼마든지 나누시면 됩니다. 다만 저희 자료들은 비상업, 변경 불가입니다. 이 부분은 지켜 주셨으면 합니다. 🙂

그리고 리뉴얼 작업을 해주신 데브피아 직원 여러분께 진심으로 감사드립니다.

 

계속 읽기

Conway’s law (콘 웨이의 법칙)

If you have four groups working on a compiler, you’ll get a 4-pass compiler

당신이 하나의 컴파일를 만들기 위해 4개의 팀을 만든다면,  당신은 4단계(four-pass) 컴파일러를 얻을 것이다.

이 말은 시스템의 구조는 시스템을 설계한 조직의 구조(형태)를 그대로 반영한다는 것입니다. 보면 볼수록 묘한 감정과 예전 기억들이 떠오르는 법칙입니다.

성공적인 회사생활을 하기 위해서는 순수한 개발 능력외에 많은 변수들이 우리를 따라 다닙니다.

  • 사내 정치에 승리하기 위한 명분 만들기
  • 서로간의 책임을 회피하기 위한 일 덜 가져오기
  • 영업 / 기획 / 개발 부서 간의 대화 단절
  • 직급 문화가 가져오는 대화의 단절 (상명하복의 의사 전달)

 

계속 읽기