HAMA 블로그

소프트웨어 아키텍트는 무엇인가? (개나 소나 다 자기 생각이 있는데 대충 끄젹꺼려 봄...) 
보통 아키텍트 - 디자인 - 개발로 구성되는데 하이퍼레저 패브릭으로 설명 해 보면 
(분야 및 조직규모등에 따라서 달라 질 순 있다)

소프트웨어 아키텍트는 "정체성" 을 확립하고 "균일성" 을 보장하는 롤을 갖는다.
즉 이 소프트웨어는 도대체 뭘 하는 것인가?
각 기업들이 서로 간의 신뢰성을 갖는데 최소의 비용으로 그것을 처리하게 하는게 목적이다.
성능 및 컨트랙트 활용성에 중점을 두고, 보안은 xxx 이상의 수준 이상으로 올리고..유저신원이 discolose 되야하고 플러그인 방식으로 컴포넌트 유연성을 갖추고..등등
이 솔루션이 커져가는데 있어서, 지켜야할 선과 확장되는데 있어서 중구난방하지 않게 사용자들이 혼동하지 않게 균일한 시스템을 보장하며... 그런 역할을 한다.

디자인  은 어떤 개별 컴포넌트가 작동함에 있어서 작동방식과 문제가 될 부분에 대해서 정리해 두는 롤을 갖는다.
즉 카프카 기반 오더러를 예르들면 그것은 어떻게 작동해야 하는가?
블록은 어떻게 만들어지나 (시간, 갯수기반)
채널은 어떻게 만들어 지는가
카프카 특성에 따라서 오더러끼리 통신하지 않고 어떻게 블록을 각자 가지고 있는가
각자 가지고 있는 방식에는 무엇이 있고 어떤 문제가 있는가..어떻게 해결하면 되는가?
하나의 오더러가 다운되면 어떻게 처리 되는가?

개발 은 컴포넌트를 실제 설계/구현한다. 위에 디자인단에서 비지니스로직적 문제해결이라면 여기서는 개발유연성, 성능 및 컴퓨팅 리소스 차원에서의 문제해결에 집중한다.
즉 어떻게 구현하면 가장 좋은가에 대해서 생각하고 설계/개발 해야 한다.
즉 아키텍트-디자인-개발의 모든 레이어에서는 각자 레이어에 맞는 창조적인 생각을 해야 한다.
개발에서는 객체모델 / 객체간의 관계 설정 / 시퀀스 설정 등을 하며, 가장 좋은 자료구조,알고리즘에 대해서도 고민하면서구현에 돌입한다. 어떤 라이브러리, 어떤 버전을 가지고 사용 할 것인가를 결정하고, 위의 디자인단에서 예측해 놓은 Problem과 그것에 따른 solution을 단계별로 구축해 간다.
개발자도 많은 생각을 해야하는 직군이며, 그냥 누가 모든것을 다 결정해 주길 바라며, 단순히 코드로 옮기는 롤이 아니다.

3줄요약

- 아키텍쳐는 크게 상위 아키텍쳐, 하위 아키텍쳐로 구분한다.
- 상위 아키텍쳐는 목적에 촛점을 맞춘다. 즉 프로그램의 목표를 분명히 유지하기 위해 고민을 한다. 
- 하위 아키텍쳐는 구현에 촛점을 맞춘다. 즉 어떻게 구현 할 건지에 대한 고민을 한다.

개인적으로 400여권의 책을 소장하고, 도서관에서 빌린 책만 수백권.... 교보문고는 나의 마음의 안식처로 생각하는
북 콜렉터로써....책은 항상 문고 가서 읽어보고 사는 편인데..

에이콘 출판사는 거른다.... (아 몇권 산거 같긴 하다. 토비의 스프링같은 명저와 함수형류의 괜찮은 번역책들...) 
이 출판사는 바퀴XX같은 매대 장악력과  수준 낮은 편집능력을 보유하고 있는데..

한빛,길벗,인사이트 처럼 수준높은것은 바라지도 않고...제이펍 ,위키북스등에 비해서도 유독 에이콘의 편집 수준은 그 모양인지.. 굳이 찾자면 마이너한 소재에 대한 책도 빠르게 번역 출판해 준다는 감사한 면도 있긴 한데 그 감사함을 희석시킬 정도의 편집 수준... 덕분에 다른 출판사가 출판 할 기회가 없어지기나 하고.... (물론 Packt Publishing 같은 그리 좋은 평판을 갖지 못한 출판사의 책을 많이 번역하여 더 문제있어 보이는 경향이 있긴 하나...O’Reilly, Manning등을 번역한 책도 크게 다르지 않다) 

아래 글을 문제점을 보고 새로 거듭나길 간절히 바라며, 내 책장에 에이콘 출판사의 책들이 꽂히길 바래본다.
(문제점이 먼지 그래도 잘 모르겠으면, 한빛 미디어의 편집력과 글꼴, 종이질을 보시라) 

1. 종이의 질도 별로 , 편집은 매우 단순,기괴 (갠적으로 종이의 질은 정말 후져도 괜찮다. 환경을 위해서라면) 
2. 겉표지도 두껍고, 안의 종이도 두껍다. 한빛미디어 종이를 봐라. 
3. 그런데 가격은 타 출판사와 비슷 
4. 한페이지에 글짜가 몇개 안됨. 초딩교과서도 아니고..
5. 한 라인의 글짜가 몇개 안됨. 좀 읽다보면 눈알을 아래로 내려야함. 집중력 저하. 
6. 글짜사이의 간격이 큼. 
7. 중간타이틀에 1, 1-1, 1-2 등의  인덱스가 없음. 챕터,소챕터 구분이 잘 안됨.  
8. 중간타이틀 글꼴이 매우 딱딱함
9. 중요문장,단어에 대한 강조표시가 빈약함, 색상도 단조로움 일색. 시인성 빈약함
10. 번역 수준이 낮음. 

기타등등 

개발자처럼 하위,상위간의 차이가 심한 직업군에서의 "인사"란 정말 중요한 것이라 볼 수 있는데,

현재 면접관의 일방적인 질문은 

1.  면접관 본인이 급조 공부한 질문 리스트를 물어보는데, 이건 면접관 본인과 회사에 아무 도움이 안된다. 그냥 우쭐거릴 수 있다 정도. (질문 오픈북을 강추 한다. 오픈북에 대한 준비 상태를 보면 회사,분야에 대한 열정&노력이 보이고, 그들은 진짜 믿을만하다.) 자신이 알고 있는 것을 아는 사람도 좋지만 모르는 것을 아는데 서로 협동 가능한 사람을 뽑으면 시너지가 나겠지요. 

2.  면접자는 자신의 머리에 있는 진짜 자신의 지식(어떤것들을 구글링 하여 비교 평가 한다도 포함)에 대해 어필할 기회를 박탈 당합니다. 면접관의 위에서 내려다보는 시각에 의한 (일방적) 발언에 반박 내지는 아무 말도 하지 못하는 분위기가 됩니다.

따라서 개발자 면접은 서로 물어보는 맞짱토론을 해야 제대로 구인할 수 있지 않을까 합니다.
면접관도 면접자의 질문 수준을 보며 자신의 부족함을 채워 줄 수 있는지 확인 해야겠지요. 
면접관이 개발자라면 그 정도 자신감 및 포용력은 있어야 평가 할 자격이 주어지지 않을까 싶습니다.

이렇게 되면  (면접비도 못받는 상황에서) 면접자는 자신의 모든 것을 보여주고,  또 모르는 것을 알게되는등  시간을 허투루 쓰지 않았다는 감정을 느낄 수 있게 되며, 사측의 개발자 또한 자신과 함께 일 할 수 있는 동료에  신뢰감이 쌓일 수 있겠지요. 이와 동시에 같이 면접에 참여한 인사팀장이라든지 CTO등은 가장 중요한 덕목인 토론에 임하는 자기 직원 및 면접자의 예의/자세등을 체크 할 수 있게 됩니다. 

PS.1
대략 수개월 후...

저게 진짜 이상적이긴 한데..스스로 얼마간 시도해보니....현실적으로 매우 힘든 요소가.....있더라...
스펙을 우선시 하는 내 자신을 보게 되기도 하고.. 수 많은 면접에 스스로 지치기도 하고...
내 자신의 꼰대성 발견의 연속이기도 했고..따라서 아직은 조금 이상향...
다만 시나브로 저런식으로 바뀌어가야 한다라는 확신은 들었다. 

최악 : 퀴즈 테스트 (채용에 진지하지 않고 귀차니즘....보통 후진 회사 행태)
중간 : Coding Test
최상 : 2시간 정도 토론 
최상 : 3~5일정도 검색해서 정보 찾고 구현 할 수 있는 연구능력,코딩능력(Design Pattern, Algorithm, Test, Documentation) 검증을 위한 입사과제 풀이

PS.2
모두 동일한 프로세스로 입사하는것도 매우 중요합니다.
CEO,CTO 낙하산으로 들어오는 사람이 있으면 절대 안됩니다. (그 사람이 스펙이든 경력이든 얼마나 좋던간에) 원칙이 중요.

요즘 소위 https 차단(?) 문제로 시끄럽다. 이건 기술적으로는 아무 문제도 없는 것인데.. 내용 살펴보겠다는 것도 아니고..

대중들은 이 기술에 대해 깊숙히 알 수는 없을 것이고, 그냥 먼가 자유를 침해 당한다고 판단하게 만드는 것 같다. 나쁜놈이 사용하면 큰일 나는 것으로...그러니 부정적인 여론 일색 일 수 밖에 없고 진짜 해야 할 논의 진행이 되질 않는다. 그럼 진짜 논의 해야 할 것은 무엇일까? 누구나 알지만 말하지 않는 것인데

성인에게 포르노에 대한 개방을 할 때가 되지 않았냐는 거다. 이런것도 자유롭게 못보게 하니...빡칠수 밖에.. 결국 이런 중요한(?) 것에 대한 논의를 하지 않으니, 불법도박사이트 같은 누구나 불법으로 간주하는것들에 대한 SNI 필터링에 대해 오버하게 되는 것이다. 심각한 자유침해니 뭐니..그냥 문정부는 보수라고 인정하고, 다음엔 더 진보를 뽑던가 하자. 

p.s

위는 개인적인 생각이고, 각자 아래의 내용을 가지고 판단하면 될 거 같다. 물론 정답은 없다.

1. SNI 가 내용인가 아닌가?  (전 NO)
2. 내용이던 아니던, 정부가 개인의 어떤 정보든 엿보는것은 안된다. (전 NO)
3. 성인물에 대한 규제가 필요하다. (전 NO)  

그거 정말 별거 없는데...ㅎㅎ 

이렇게 쉬운 걸 쓸때없이 어려운 용어/사상/구분짓기로 떡칠을 해서,  오히려 개발자들에게 짐을 지우는게 아닌가 싶은..

그냥 객체(모듈,개체,구조체등등) 이 있다고 할 때, 특정 역할을 외부에서 객체/포인터/함수등 무엇이든 주입받아서 해결하는 방식(근데 애들 관리가 힘들어 질 수도..숨박꼭질 하는 애들 종적찾기란..) 주입받는 방식은 기술,언어마다 다를 수도 있으며 생성자를 이용하던, 세터를 이용하던 채널을 이용하던 소켓이나 파이프를 이용하던, 설정파일에 적혀있던 리플렉션을 이용하던 뭐던간에 자신이 다 구현해서 하드코딩되는 것보다 유연해지겠지요. 

이게 특정 프레임워크나 언어에서 유행했다고 해서, 그것이 정답 및 진정한 xxx 류가 될 수 없으며 그냥 유연하게 설계 하기 위한 모든 스프트웨어 세상에서의 나타나는 일반적인 패턴 정도로 바라보면 편할 듯 싶네요. 

한글 위키백과 보니깐 "의존성 주입(Dependency Injection, DI)은 프로그래밍 에서 구성요소간의 의존 관계가 소스코드  내부가 아닌 외부의 설정파일 등을 통해 정의되게 하는 디자인 패턴  중의 하나이다." 이렇게 나오는데, 누가 정의 했는지 정말 지엽적으로 지껄여 놨구나.... 그냥 그런식으로 하는 방식, 또는  life cycle 까지 관리해주는 프레임워크가 있는것 일뿐..잘못된 정의

아래 장,단점도 가져왔는데요. 전 한번 읽어봤는데 이딴거 읽을 필요도 없을거 같아요. ㅎㅎ
웬만한 프로젝트엔 저 단점이 장점보다 훨씬 크지 않을까 의심스러운데.. 뭐 일일이 확인 해 볼 순 없지만서도..암튼 소는 누가 갈고~코딩은 어느세월에 합니까~이런거에 발목 잡혀서...

문법 실수에 겁내서 말하기를 즐기지 못했더라면  오성식은 유창하게 영어를 할 수 없었다.

장점[edit ]

• Dependency injection allows a client the flexibility of being configurable. Only the client's behavior is fixed. The client may act on anything that supports the intrinsic interface the client expects.
• Dependency injection can be used to externalize a system's configuration details into configuration files, allowing the system to be reconfigured without recompilation. Separate configurations can be written for different situations that require different implementations of components. This includes, but is not limited to, testing.
• Because dependency injection doesn't require any change in code behavior it can be applied to legacy code as a refactoring . The result is clients that are more independent and that are easier to unit test  in isolation using stubs  or mock objects  that simulate other objects not under test. This ease of testing is often the first benefit noticed when using dependency injection.
• Dependency injection allows a client to remove all knowledge of a concrete implementation that it needs to use. This helps isolate the client from the impact of design changes and defects. It promotes reusability, testability and maintainability.[22] 
• Reduction of boilerplate code  in the application objects, since all work to initialize or set up dependencies is handled by a provider component.[22] 
• Dependency injection allows concurrent or independent development. Two developers can independently develop classes  that use each other, while only needing to know the interface the classes will communicate through. Plugins  are often developed by third party shops that never even talk to the developers who created the product that uses the plugins.
• Dependency Injection decreases coupling between a class and its dependency.[23] [24] 

단점[edit ]

• Dependency injection creates clients that demand configuration details be supplied by construction code. This can be onerous when obvious defaults are available.
• Dependency injection can make code difficult to trace (read) because it separates behavior from construction. This means developers must refer to more files to follow how a system performs.
• Dependency injection frameworks are implemented with reflection or dynamic programming. This can hinder use of IDE automation, such as "find references", "show call hierarchy" and safe refactorings.
• Dependency injection typically requires more upfront development effort since one can not summon into being something right when and where it is needed but must ask that it be injected and then ensure that it has been injected.
• Dependency injection forces complexity to move out of classes and into the linkages between classes which might not always be desirable or easily managed.[25] 
• Dependency injection can encourage dependence on a dependency injection framework.[25] [26] [27] 
  
  

술한잔하고 누군가의  잘 모르겠다는 넉두리에 주저리 주저리 해봄.

IBM 클라우드(하이퍼레저)에서 와이프 카드로 날라온 50만원 상당의 결재 금액에 멘붕중이네요. 예전에 계정관련 카드문제가 있어서 굉장히 큰 곤란을 겪었는데... 내카드,와이프카드,회사1카드모두 안되서 결국회사2카드를 통해서 서류를 미국으로 직접 보내서 겨우 서비스 이용중이고 요금도 납부중인데.. 난데없이 아내 카드로 잠시 Start plan 을 시동만 걸어놨다가 락걸려서 (이 부분에 대한 기억이 가물가물..) 잊어버린 서비스가 살았는지 청구를 해 왔습니다. 계정/결제 관련 문제는 한국에서 절대 해결 불가능하다고 하여 미국과 직접 소통하라고 메일하나 던져준 한국IBM 사용자지원센터. 여기까진 ㅇㅋ 50십만원 상당의 금액은 제 실수 일지도 모르기 때문에 납부하려고 마음먹고 (AWS는 이런것도 잘 해결해 주는것으로 알고 있습니다.) 빨리 기억에서 사라진 이 서비스를 중지시켜야 해서 까먹은 해당 IBM Cloud ID가 무엇인지 알려달라는 메일에 3일동안 대답이 없는 IBM 클라우드 .... IBM ID 와 연계된 이메일 주소로는 카드청구를 하고서, 해당 IBM ID 는 알려주지도 않는...망할..이런 사용자경험으론 앞으로 한국에서 IBM클라우드를 사용하긴 힘들거 같습니다.

비용을 청구한 이메일/카드와 연계된 IBM ID가 없다고 메일이 왔네요. 해당 서비스를 사용하는 ID도 없는데 서비스에 대한 비용청구는 한다?? 무언가 과금을 일으키는 서비스를 삭제 할 IBM ID가 없다? 그래도 50십만원씩 계속 청구 할거다? 이런 날강도가 다 있나요 ㅎㅎ

해석)

C++:  완성은 되지만, 시대에 뒤떨어진 포인터사용,쓰레드사용에 의한 버그로 맛이 간 제작물이 탄생. 그것을 보완하기 위해 덧붙혀진 복잡한 래퍼기술의 복잡성에 의한 구토. (feat, Mordern C++ design)
JAVA: 시작하기 전에 먼저 프레임워크부터 만들어야함. 혹은 다양한 프레임워크(도구)들에 대해서 잘 알아야함. 시작 못함.
JavaScript:  다양하고 많은 오픈소스 라이브러리/프레임워크들이 있지만 멀 선택해야 할지 모르겠다. 그리고 안정성은 개나줘버려.
NoSQL: 쩐다고 말들은 하지만, 실체는 없음. 혹은 자신이 하려는 일에는 맞지 않음. 
Cobol: 너무 오래되서 유지보수 막장. 잘못 건드리다간 엉뚱하게 작동할 확률이 큼. 건드리지 말자. 
Lisp: 코드에 괄호가 너무 많아서 가독성/유지보수 최악. 
C#:  MS에 독점적인 제약이 있으며,  그것이 틀릴지라도 (말인데 낙타) 그렇게 해야함. 커스터마이징 하지마. 
Assembly: 현대의 복잡한 어플리케이션을 구현하긴 불가능하며, 초단순 작업만 가능. 
PHP: 먼가 그럴싸한것을 만든 것 같지만 결국 허술함이라는 복병이 숨어있다가 뒷통수 때림. 

마소는 회장 바뀌고나서 오픈소스화 정책으로 돌아서서~ 

인터넷은 아직 진화 단계의 초기에 있다

좀 충격적인 문장이죠?  아래의 링크 글에 나오는데요. 매우 휼륭한 글로써 (맞는 글로써가 아니라, 생각을 하게 만드는 글) 블록체인에 관심이 없더라도 개발자들이라면 반드시 읽어보시길 바랍니다. 아래 문장도 좋았습니다.

 게임의 규칙이 변하는 것을 걱정하지 않고 그 프로토콜 위에서 비즈니스를 만들 수 있었기 때문이다.

원문) Why Decentralization Matters  
번역본) 왜 탈중앙화가 중요한가? 

음..현재 웹 아키텍쳐(단일지점서비스)에서 완전히 변화된 발상으로 혁신을 꾀하고 있는 분산웹에 관심 있는 분들은 IPFS 에 대해서 읽어보셨으면 좋겠습니다. 블록체인/코인과 직접적인 관계는 없습니다만 분산이라는 사상과 윤활류로써의 역할은 간접적으로 관계가 있습니다. 간단히 말하면, 블록체인 기술 보다는 토렌토 기술의 진화형이라고 생각하면 더 쉽습니다. 

그리고 링크의 글에서 말하는 바와 같이 사실상 3번째 인터넷 시대는 탈중앙화로 흘러 가고 있는것 같습니다.
그것이 성공하도록 많은 사람들이 현재 새로운 아이디어를 계속 해서 시도해보고, 비판하고~ 재밌는 상황입니다. 
그런 시도를 할 수 있게 해주는 것이, 코인판에서 흘러들어오는 자금력이 원동력이 되고 있으며,(물론 이런 자금을 유용하려는 스캠도 많습니다만;;) 현재 *이더리움* 이 얕은 수(?)를 쓰지 않고 그 어려운길을 헤쳐나가는데 중심을 잡고 있는 상황입니다. 그 이더리움의 정직성(?)을 레이어1이라고하면, 그 기반위에 레이어2,3이 올라가서 응용레벨로까지 발전 할 수 있느냐가 3번째 인터넷시대의 핵심 장벽으로 생각합니다. 사이드체인이라고 하죠. 이더리움에서는 플라즈마라고 합니다. 관련 구현체들은 나오고 있지만  아직 완벽한 해법이 나오진 않은 상태입니다. 

* 참고로 엔터프라이즈형 블록체인(하이퍼레저 패브릭,CORDA) 의 경우는 좀 다른 케이스입니다. 세번째 인터넷에서 매우 중요한 비허가형 즉 아무나 쉽게 참여 가능하고, (참여 대상이 사기꾼인지 아닌지 전혀 신경 쓰지 않음. 이것이 혁명), 능동적으로 변경해 자신의 길을 나아 갈 수 있는 그 핵심 포인트와 반대되는 먹거리를 찾아서 가는 놈이죠. 아무한테나 노출하는 것을 두려워하여 노드들이 허가가 있어야 참여하며, (그렇다고 각 노드들의 완전한 신뢰를 요구하며 작동하는 시스템은 아닙니다.나름 탈중앙화 시스템임.)정확히 누구인지 인증되야 하며, 트랜잭션에 있어서 비공개가 가능한 서비스입니다. 

* 이더리움은 월드오브워크래프트(WOW)를 하다가 블리자드의 독단적 결정에 의해 자신의 흑마법사 캐릭터의 너프를 먹고 빡쳐서 밤새 울다 게임을 접은 경험이 있는 "비탈릭 부테린" 이라는 돈 욕심 없어보이고 수행자 처럼 생긴 젊은 천재에 의해 이끌어 지고 있습니다. (전 고술이 양손을 버리는 순간 마음에서 접었..) 

* 서점에 가면 "플랫폼의 시대" 에 관련된 책들이 많습니다. 이는 현재 중앙화된 플랫폼이 엄청난 힘을 가지고 있기 때문인데, 곧 서점에서 없어질 '과거에는 그랬다' 의 책이 될런지도 모르겠습니다. ㅎㅎ

마지막으로 탈중앙화보다 더 중요한것은 개발자들의 마음을 얻는 것입니다. ^^