본문 바로가기

IT 살이/04. 기술 - 아키텍처

"아키텍처"라는 것을 설명해보자v0.3 아키텍처 ! 이론적이고 공학적인 방법으로 설명하는 것 말고, 다른 방법으로 할 수 없을까 고민하고 정리해도 매번 실패로 끝난다. 이번에도 다시 시도해본다. ▣ 이해관계자와 관심사(Concerns) 그리고 요구사항 아키텍처와 직접적으로 관련있는 말은 "관심사(concerns)"이다. 즉 다양한 사람들의 관심사가 있고 그 관심있는 일 때문에 그들의 요구 사항들이 나오게 된다. 이런 요구사항들때문에 프로젝트가 시작되고 그리고 요구 사항들은 프로젝트가 해결해야 하는 직접적인 대상이 된다. 그 프로젝트가 성공하기 위해서는 프로젝트와 관련된 다양한 관심사들을 파악하는 것이 매우 중요하다. 따라서 이런 관련자들, 그들의 관심사들, 그리고 요구사항들을 검토할 수 있는 프레임워크를 정의해두는 것은 매우 큰 의미가 있게 .. 더보기
"아키텍처"라는 것을 설명해보자v0.2 이론적이고 공학적인 설명 말고, 일반적인 개념으로 설명 시도. 아키텍처와 직접적으로 관련있는 말은 "관심사(concerns)"이다. 일과 프로젝트는 뭔가 문제를 해결하기 위한 요구사항이 있기때문에 시작된다. 그런데 그 문제를 해결하는데는 많은 관심 사항들이 존재한다. 다양한 관심사항들은 문제를 해결해나가는데 다양한 영향을 주게 된다. 일과 프로젝트에 존재하는 다양한 관심사들을 파악하는 것이 일을 성공시키기 위해서 매우 중요하다. 따라서 이런 관심사들을 검토할 수 있는 프레임워크를 정의해두는 것은 매우 큰 의미가 있게 된다. 너무 많은 사람들과 조직, 역할의 관심 거리가 있고 그리고 그 관심 거리는 다시 또 계획 단계와 실행 단계별로 세분화되어서 존재한다. 그래서 관심사는 그림에서처럼 (조직과 역할, 계획.. 더보기
"아키텍처"라는 것을 설명해보자 v0.1 IT 아키텍처를 설명할 방법을 고민한 적이 자주 있다. 검색을 해 보면 공학적인 정의들은 많이 있다. 때로는 비유를 통해서 정의를 시도하는 경우도 있다. 생각해보면, 아키텍처라는 것이 IT나 토목, 건축에서만 사용되는 것은 아니기에 좀 더 일반적인 설명이 필요할 것 같다는 생각이었다. 오늘 산책을 하다가 문득 아키텍처를 어떻게 설명할까를 다시 생각해보게 되었다. 우리는 어떤 일( 보통 프로젝트라고 부른다)을 할때는 보통 분석, 설계, 수행을 하고 그러고 나서 유지 보수 및 개선 활동을 하게 된다. 이것은 뭔가 구체적인 목표를 달성하기 위한 액션들이다. 아키텍처는 이런 액션 차원과는 다른 차원의 목표를 갖는 플래닝이라 할 수 있을 것 같다. 다른 차원의 목표란 보통 품질이 된다. 예를 들어서 보안, 성능,.. 더보기
03. 개발 방법론 & 개발 프레임워크 IT 전략화 계획이 수립되면, 이제 개발에 들어간다. 그러기 전에 개발 방법론이 결정되어야 한다. 그런 다음 생산성, 유지보수성같은 품질을 확보할 수 있는 방법으로 개발 프레임워크를 도입하게 된다. 개발 방법론 자료 몇가지 개발 프레임워크 자료 몇 가지 더보기
그림으로 공부하는 IT 인프라구조 마음이 엉망진창이다. 마음의 벽돌들이 와르르 무너지는 듯 하다. 이것 저것 마구 하고 있다. 그림으로 그려진 기술책을 보면 좀 재미있어지려나 해서, 얼마전 구입해서 읽고 있는 기술 책이다. 목차를 손으로 써야 의미가 있는데,,, 이번에는 귀찮다. 온라인 서점에서 복사해왔다. Chapter 1 인프라 아키텍처를 살펴보자 11.1 | 시작하며 2Column 궁극의 아키텍처와 최적의 아키텍처 31.2 | 집약형과 분할형 아키텍처 41.3 | 수직 분할형 아키텍처 10Column 웹은 클라이언트-서버형을 대체할 수 있을까? 141.4 | 수평 분할형 아키텍처 14Column 가상화 진행 상황 181.5 | 지리 분할형 아키텍처 19Column 기술은 대물림되고 있다 23 Chapter 2 서버를 열어 보자 25.. 더보기
소프트웨어 아키텍트가 알아야 할 12/97가지(링크) 구구절절이 마음에 와 닿는 얘기들이다. "나무에 그네"를 만드는 그림을 보면서는 이렇구나 했다.요구하는 사람은 그네가 흔들리기만 하면 되는 거다. 하아하아 05. 아키텍트가 알아야할 12 97가지 from YoungSu Son 더보기
책상정리#8-Design Patterns 개발에 사용되는 패턴이긴 하지만, 디자인 패턴에서 사용하는 관점과 개념에 익숙해지면 아키텍처를 설계할때도 도움이 된다. Head First Design Patterns에릭 프리먼 외 디자인 패턴 소개1. 디자인 패턴의 세계에 오신 것을 환영합니다. SimUDuck 조는 상속에 대해서 생각을 해 봅니다. 인터페이스는 어떨까요? 소프트웨어 개발에 있어서 바뀌지 않는 것 바뀌는 부분과 그렇지 않은 부분 분리하기 오리의 행동 디자인 Duck 코드 테스트 동적으로 행동을 지정하는 방법 캡슐화된 행동을 큰 그림으로 바라봅시다. "A는 B이다" 보다 "A에는 B가 있다"가 나을 수 있습니다. 스트래티지 패턴 전문 용어의 위력 디자인 패턴을 어떻게 사용하나요? 디자인 도구 상자 연습문제 정답 옵저버 패턴2. 객체들한테.. 더보기
책상정리 #5 - 엔터프라이즈급 애자일 개발 늘 관심은 가지고 있지만, 제대로된 애자일 개발을 경험해 볼 기회는 그리 없다는... 주로 큰 기업의 프로젝트를 주로 하다보니 더욱더 기회가 없는 듯 하다. 애자일 방법론이 큰 프로젝트에 적용되기 어렵다는 말은 들어서 알고 있지만 그런 이유 말고도 큰 기업은 조직이 크다 보니까 약간의 변화를 가져오는 것도 힘들다는 생각을 하곤 한다. 소프트웨어 개발 방법론이란게 원래 직접 경험해 보는 것보다 좋은 게 어디 있겠는가. 아쉬움에 관심있는 책은 늘어나지만 늘어가지만 책으로는 해결할 수 없는 한계를 어떻게 해 볼 수 없다. 엔터프라이즈급 애자일 방법론저자 딘 레핑웰 엔터프라이즈 애자일 솔루션 개발저자 스콧 앰블러 외 엔터프라이즈 애자일 프로젝트 관리저자 요헨 크렙스 Agile Principles, Pattern.. 더보기
책상정리 #4 - Patterns of Enterprise Application Architecture 그 이름, Martin Fowler !! 2000년대 초반에 나온 고전(?)이긴 하지만 현재 기업에서 사용되고 있는 엔터프라이즈 아키텍처에 대해서 정리하고 싶다면 이 책을 보면 되지 않을까 싶다. 이 책의 부분들을 조합하면 대부분의 기업들의 아키텍처는 만들어 질 수 있을 것으로 보인다. 저자 Martin Fowler외 목차를 옮기려 하니 꽤 길다. 휴~~ Introduction Architecture Enterprise Application Kinds of Enterprise Application Thinking About Performance Patterns The Structure of the Patterns Limitations of These PatternsPART 1: The Narratives.. 더보기
책상정리 #3 - 서비스 디자인 패턴 외국계 기업에 아키텍트로 들어갈려고 당일치기로 인터뷰를 준비하면서 구입한 책이다.-_-;; 아닌가? 그 회사 입사에 실패하고 인터뷰에서 나온 질문을 공부하기 위해서 구입한 책인것 같기도 하고. 저자 로버트 다이뇨 1장 객체에서 웹 서비스로 웹 서비스란 무엇인가? 지역 객체부터 분산 객체까지 왜 웹 서비스를 사용하는가? 웹 서비스 고려사항과 대안 서비스와 느슨한 결합도의 약속 SOA는 어떠한가? 정리2장 웹 서비스 API 스타일 서론 웹 서비스 API의 디자인 고려사항 RPC API 메시지 API 리소스 API3장 클라이언트와 서비스의 상호작용 서론 요청/응답 요청/확인 미디어 타입 협상 링크된 서비스4장 요청과 응답의 관리 서론 서비스 컨트롤러 데이터 전송 객체 데이터 바인딩 고려사항 일반적인 고려사항 .. 더보기
책상정리 #2 - Software Architecture In Practice 책상에서 책꽂이로 이동시킬 두번째 녀석들이다. 달봉이가 IT쪽으로 와서, 7,8년전에 처음으로 이쪽 자격증 시험을 본적이 있다. 실패는 했지만, 이쪽의 비전공자로서 IT 분야의 전체적인 기술부분을 정리할 계기가 되었다. 이때 만나서 관심을 가지고서는 이후로 계속 구입해 온 녀석들인데, 아직 완독을 못하고 있다.아키텍처를 공부하는 사람은 모두(?) 알고 있다고 할 수 있는 유명한 책들이다. 그러나 지금 근무하는 곳의 환경때문에 이 녀석들을 사랑할 시간을 좀 처럼 만들지 못하고 있다. 현재 일하고 있는 직장에서는 아키텍처라는 용어 자체를 사용하지 않는 곳이다. 아직도 "정보공학" 방법론에나 맞을것 같은 조직 구조와 명칭을 사용한다. 아키텍처라 하면 아주 아주 기술적인 주제로만 생각한다. 한마디로 "기술쟁이".. 더보기
Proxiable Types-모든 웹 서비스 호출을 가로챌 수 있다 달봉이는 얼마전에 L기업의 ERP 프로젝트에 참여하고 있었다. 이 시스템은 스마트클라이언트 애플리케이션으로 구현했는데, 서버와의 통신은 웹 서비스를 사용하고 있다. 웹 서비스 호출시는 VS.NET이 자동 생성하는 프락시 클래스를 확장해서 사용하고 있다. 이것을 이름하여 "웹 참조 차원의 프락시"라고 하고 있다. 그러나 또 하나의 프락시를 제작해서 사용하고 있는데, 모든 웹 서비스 호출이 일단 이 프락시를 거치고 난 다음 각각의 원하는 "웹 참조 차원의 프락시"를 호출한다고 해서 "시스템 차원의 프락시"라 칭하기로 했다. 이 포스트에서는 시스템 차원의 프락시 클래스에 대해서 이야기할 것이다. 이 시스템 차원의 프락시를 사용하면 모든 웹 서비스 호출을 가로채서 웹 서비스 호출을 서버로 보내기 전에 전처리 작.. 더보기
커맨드 패턴 이번 포스트는 개인적인 메모다. 나름대로 핵심들이라고 생각되는 사항들을 다짜고짜 거두절미하고 나열한다( 시간나면 좀 자세히 정리해야 겠다. 언제가 될지 모르겠지만...-_-;;) 디자인 패턴의 각 유형을 정의내린다는 것은 참 힘들다. 차라리 어떤 점이 편리한지 응용성이 어떤지를 정리하는 것이 더 쉬우면서도 유용한 것 같다. 달봉이는 지금 스마트클라이언트 어플리케이션의 클라이언트측 프레임워크를 제작해서 사용하고 있다. 그 구현 내용중에서 커맨드 패턴이라는 것을 사용하고 있다. 해서 이 포스트에서는 나름대로 정리를 좀 해 놔야 할 것 같다. 안해 놓으면 잊어버리고 같은 문제로 또 언젠가는 고민하게 된다( 요즘은 눈에 띄게 기억력이 떨어진 것 같다 쓰으...). ■ 기본 커맨드 패턴 1. 커맨드 객체는 특정 .. 더보기

티스토리툴바