waca's field

금의 가치 | 비트코인 현상, 블록체인 2.0 | 마이클 J.케이시, 폴 비냐 지음

wisecow — Sun, 19 Nov 2017 00:06:31 +0900

금이 비싼 이유는 금의 고유의 기능과는 크게 관련이 없다.

우리가 흔히 아는 골드바, 그 골드바 1개의 진짜 가치는 무엇일까? 골드바에 내재되어 있는 가치는 도대체 무엇인가? 골드버그들은 금은 견고하고 대체 가능성이 큰 금속이기 때문에 무수한 쓰임새를 갖고 있다고 말한다. // 골드버그(Gold Bug)란 금본위제도가 화폐의 내재적 가치 문제를 해결할 수 있는 방법이라고 주장하는 무리를 일컫는다.

금의 성질은 알면 알수록 놀랍다고 할 수 있다.펴서 늘릴 수도 있으면서도 동시에 내구성이 강하다. 녹여서 모양을 변형할 수 있으며, 이때 광택을 전혀 잃지 않는다. 또한 전기 전도성은 매우 뛰어나 전기회로판에 이용되며, 내구도가 강하고 변색이 잘 되지 않아 치아 임플란트에도 쓰인다. 그러나 확실히 하고 넘어가자. 이런 쓰임새들 때문에 우리가 금을 가치 있게 여기는 것은 아니다.

사실 금이 가치를 갖는 이유는 공급의 희소성 때문이다. 금에 매겨진 가치는 전통적으로 보석 장식품으로 쓰였으며 건축물과 인테리어 장식 등으로 사용된 것을 보면 알 수 있듯이 인식된 아름다움과 더 관련이 깊다. 그럼에도 불구하고 아직도 금의 가치에 대한 논쟁은 진행 중이다.

우리가 꽃을 보면 그러하듯이 본능적으로 금을 보면 아름답다고 여기는 것인지, 또는 금으로 된 장식물이 부와 번영, 명예 등을 상징하므로 가치가 있다는 통합적 사고를 통해 아름답다고 여기는 것인지 구분하기란 쉽지 않다.

금은 희소하며 이것은 부인할 수 없는 사실이다. 흔히 인류 역사를 통틀어 채굴된 금의 총량은 올림픽 수영장 2개를 채울 정도밖에 안 된다고 얘기한다. 그러나 희소성은 상대적 개념이고 수요가 있을 경우에만 성립한다. 다른 많은 종류의 금속들 또한 희소하다고 볼 수 있지만 수요가 크지 않기 때문에 가치가 높지 않다.

중요한 것은 사람들이 금을 필요로 한다는 사실이다. 금은 우리가 가치 있다고 믿기 때문에 통화나 투자 대상으로서 가치가 있다. 금의 통화로서의 가치는 추상적인 사회의 산물인 것이다.

화폐 제도 | 비트코인 현상, 블록체인 2.0 | 마이클 J.케이시, 폴 비냐 지음

wisecow — Sat, 18 Nov 2017 23:57:15 +0900

화폐란 가상의 개념이다. 화폐의 본질은 실존의아닌, 믿음에 있다.

미크로네시아 연방의 섬인 얍(Yap) 섬은 독특한 화폐제도를 가지고 있었다. 초기에 이곳에 상륙한 유럽인들은 페이(fei)라고 불리는 돌 바퀴(Stone wheel)로 운영되는 화폐제도를 보고 매우 당황했다. 페이는 300마일 정도 떨어진 곳에서 채굴되며, 지름이 12피트(약 3.7미터)나 된다. 거래가 끝나면, 이 거대한 돌덩이를 새로운 주인에게 다시 운반하는 것이 너무나 불편한 일이었다.

그래서 종종 옛주인이 돌 바퀴를 계속 갖고 있곤 했다. 그러나 얍 사회에서는 재산권을 나타내는 이 장대한 물건의 소유권이 거래를 거듭하며 누구에게로 넘어갔는지에 대한 상호 간 협의과 원활히 이루어졌으며, 이 페이는 채무 관계의 청산 및 결제 수단으로서 잘 기능하고 있었다.

미국의 젊은 탐험가였던 윌리엄 헨리 퍼네스 3세(William Henry Furness)가 책에서 했던 이야기에는, 바벨썹(Babelthaup)섬에서 옮기는 도중 페이 하나가 바다로 빠져버렸지만, 여전히 새로운 주인이 소유권을 가진 거래 가능한 통화로 인식되고 있었다는 것이다.

페이 시스템은 인간 사회가 어떻게 가치와 권력에 대한 추상적 관념을 창조해내는지를 보여준다. 그리고 이 관념은 돈의 가치가 허구적일지라도 어디에서나 쓰일 수 있다고 누구나 인식하게 된다면 엄청난 사회적 힘을 발휘한다. 그리하여 이전에는 훨씬 야만적이고 한게점이 많았던 권력 체제였음에도 불구하고 고대 그리스에서는 돈의 등장과 함께 민주주의라는 혁신적인 시스템이 출현할 수 있었던 것이다.

돈이 새로운 세상의 도래를 이끌었고, 많은 가능성들을 창조해냈다. 그러나 추상적 개념을 받아들이는 것만큼 강력한 힘을 가진 것이 또 있었으니, 이는 문명의 발전이었다. 문명의 발전은 개인 중심의 사고에서 벗어나, 세상이 어떻게 돌아가고 특히 가치라는 것이 어떻게 성립하는 것인지에 대해 유의미한 설명을 하고자 하는 투쟁이었다.

벽돌과 박격포를 파는 가게와 기타 물질적 재화들을 보고 자란 옛날 사람들은 요즘 사람들의 '가상의 재화'를 사는 것을 이해하기 힘들어 한다. 이 가상의 재화들은 가상화폐로 지불하는 것이 훨씬 쌀 때가 많으며 우리는 종종 "돈이란 무엇인가"라는 주제로 지적인 토론을 벌이곤 한다. 그렇지만 우리 머릿속 깊이 자리 잡은 1달러 또는 1유로, 혹은 심지어 비트코인처럼 그 자체가 지닌 물질적 가치를 넘어 사고하기란 쉽지 않다.

지금 당장 자신의 지갑에서 1달러를 꺼내보자. 1달러가 될 수도 있고 1유로, 혹은 1,000원인 그 종이를 꺼내보자. 그리고 자세히 들여다보고 이제 스스로에게 물어보자.

도대체 이것의 가치는 무엇인가?

오류 제어

wisecow — Wed, 25 Oct 2017 21:22:21 +0900

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */

# 전송 오류의 유형

전송 프레임의 오류를 극복하고, 상위 계층에 신뢰성 있는 전송 서비스를 제공하려면 다음과 같은 기본 기능을 이용해 오류 복구 기능을 제공해야 한다.

* 수신 호스트의 응답 프레임

송신 호스트가 전송한 데이터 프레임의 일부가 깨지는 프레임 변형 오류를 확인한 수신 호스트는 송신 호스트에게 응답 프레임을 전송해 원래의 데이터 프레임을 재전송하도록 요구할 수 있다. 수신 호스트가 전송하는 응답 프레임의 종류에는 데이터 프레임이 정상적으로 도착했을 때 회신하는 긍정 응답 프레임과 데이터 프레임이 깨졌을 때 회신하는 부정 응답 프레임이 있다.

* 송신 호스트의 타이머 기능

송신 호스트가 전송한 데이터 프레임이 수신 호스트에게 도착하지 못하는 프레임 분실 오류가 발생하면 수신 호스트는 이 사실을 인지할 수 없다. 따라서 오류의 복구 과정이 송신 호스트의 주도로 이루어져야 한다. 송신 호스트는 데이터 프레임을 전송한 후에 일정 시간 이내에 수신 호스트로부터 긍정 응답 프레임 회신이 없으면 타임아웃(Timeout) 기능을 동작시켜 데이터 프레임을 재전송한다.

* 순서 번호 기능

수신 호스트의 긍정 응답 프레임을 분실하면 데이터 프레임이 제대로 도착했음에도 불구하고 송신 호스트가 이를 인지할 수 없다. 따라서 송신 호스트가 타임아웃 기능에 의해 원래 데이터를 재전송함으로써 수신 호스트가 데이터 프레임을 중복 수신하는 결과를 초래한다. 이럴 때 수신 호스트가 중복 데이터 프레임을 가려내려면 각 프레임 내부에 순서 번호(Sequence Number)를 기록해야 한다.

데이터 프레임은 원래의 데이터 외에 오류 검출을 위한 정보도 함께 포함한다. 오류 검출을 위한 정보에는 수신 호스트에서 오류를 감지하는 기능만 하는 정보와 오류가 발생한 프레임을 복구하는 기능을 하는 정보가 있다.

오류를 감지만 하는 방법을 사용할 때는 송신 호스트의 도움을 받아 오류 복구 기능을 수행 해야 한다. 즉, 수신 호스트가 데이터 프레임을 올바로 수신하면 송신 호스트에 긍정 응답(Positive Acknowledgement) 프레임을 보냄으로써, 송수신 호스트 사이의 전송이 완결된다. 그러나 프레임 변형 오류가 발생하면 부정 응답(Negative Acknowledgement) 프레임을 회신해 송신 호스트의 재전송 기능에 따라 오류 복구 과정을 진행한다.

* 정상적인 전송

송신 호스트가 전송한 데이터가 오류 없이 수신 호스트에게 전송된 경우다. 수신 호스트는 데이터 프레임을 제대로 수신했다는 긍정 응답 프레임을 회신함으로써 하나의 데이터 프레임에 대한 전송 과정이 완료된다.

송신 호스트가 긍정 응답 프레임을 회신 받지 못하면 데이터 프레임에 오류가 발생했다는 의미다. 일반적으로 변형된 프레임을 수신한 호스트는 부정 응답 프레임을 전송할 수도 있지만, 프로토콜의 종류에 따라서는 부정 응답 프레임을 지원하지 않을 수도 있다.

이때는 수신 호스트가 회신할 방법이 없으므로 송신 호스트의 타임아웃 기능에 따라 오류 복구 기능을 시작한다. 데이터 프레임은 정상적으로 전송되었지만, 수신 호스트의 긍정 응답 프레임이 송신 호스트에게 도착하지 못해도 송신 호스트의 타임아웃 기능에 따라 오류를 복구한다.

* 프레임 변형

데이터 프레임이 수신 호스트에 도착했으나, 전송 과정에서 프레임의 내용이 변형되는 오류가 발생하는 경우다. 프레임 변형 오류를 인지한 수신 호스트는 송신 호스트에게 부정 응답 프레임을 전송함으로써, 원래의 데이터 프레임을 재전송하는 오류 복구 과정이 진행된다. 앞서 언급한 것처럼 부정 응답 프레임을 재전송하는 오류 복구 과정이 진행된다. 앞서 언급한 것처럼 부정 응답 프레임을 사용하지 않는 프로토콜 에서는 송신 호스트의 타임아웃 기능에 따라 복구 과정을 시작한다.

한편 재전송된 데이터 프레임은 올바르게 전송될 수도 있지만, 반대로 이 과정에서 또 다시 변형 오류가 발생할 수도 있다. 또한 긍정이나 부정 응답 프레임도 전송 과정에서 변형이나 분실과 같은 오류가 발생할 수 있다. 따라서 데이터 링크 계층 프로토콜에서 다루는 전송 오류 문제의 원리는 매우 단순하지만, 프로토콜 설계시 세심한 주의가 필요하다. // 프레임 내부에 시퀀스 번호(순서 번호)를 두는 이유도 이 때문이다.

* 프레임 분실

데이터 링크 계층의 주요 기능 중 하나는 프레임을 전송한 송신 호스트가 동작하는 타임아웃 기능이다. 송신 호스트가 전송한 데이터 프레임이 전송 과정에서 사라지는 프레임 분실 오류를 생각해보자. 수신 호스트는 송신 호스트로부터 어떠한 데이터 프레임도 전달 받지 못했기 때문에 긍정 응답이나 부정 응답 프레임을 회신할 수 없다. 결과적으로 송신 호스트도 응답 프레임을 회신받을 수 없어 응답 프레임을 무작정 기다려야 한다.

수신 호스트는 데이터 프레임의 분실 여부를 인지할 수 없으므로 오류 복구는 송신 호스트 주도로 타임아웃(Timeout)기능에 따라 처리된다. 즉, 송신 호스트는 데이터 프레임을 전송한 후에 특정 시간까지 수신 호스트의 긍정 응답 프레임이 도착하지 않으면 타임아웃 기능에 따라 원래의 프레임을 스스로 재전송한다.

# 순서(Sequence) 번호

데이터 링크 계층의 오류 복구 기능이 수행되는 과정에서 동일한 데이터 프레임이 수신 호스트에 중복해 도착할 수 있다. 따라서 오류 없이 수신된 중복 데이터의 문제에 대비해야 한다. 중복 데이터 처리는 프레임 내부에 각 프레임의 고유 번호인 순서 번호(Sequence Number)를 기록하여 해결한다.

* 순서 번호의 필요성

올바르게 수신한 데이터 프레임에 대한 긍정 응답 프레임이 사라지는 오류가 발생하면 송신 호스트의 타임아웃 기능에 따라 재전송 과정이 진행된다. 재전송된 데이터 프레임이 제대로 수신되면 수신 호스트 입장에서는 동일한 프레임을 중복해 수신하는 결과를 초래한다.

송신 호스트 입장에서 보면 자신이 동일한 데이터 프레임을 두 번 전송했는지, 아니면 서로 다른 두 개의 데이터 프레임을 연속 전송했는지 구분할 수 있다. 그러나 수신 호스트는 두 경우를 구분할 방법이 없다. 따라서 수신 호스트가 두 경우를 구분할 수 있도록 데이터 프레임별로 고우의 순서 번호를 표기하는 방식이 필요하다. // 데이터 전송이 모두 성공한다고 가정하면, 순서 번호가 따로 필요 없겠지만 실패할 확률은 엄연히 존재하기 때문에 이것에 대한 대비책으로서 순서 번호가 필요한 것이다. 좀 더 풀어 설명해보면, 수신한 데이터 프레임의 시퀀스 번호가 1이었고, 다음에 온 데이터 프레임 시퀀스 번호도 1이라면 이는 중복을 의미한다. 바로 이 원리로 수신 호스트는 데이터의 중복 여부를 파악할 수 있다.

# 흐름 제어

오류 제어와 함께 데이터 링크 계층에서 제공하는 주요 기능은 전송 데이터의 속도 조절이다. 송신 호스트는 수신 호스트가 감당할 수 있을 정도의 전송 속도를 유지하면서 데이터 프레임을 전송해야 하는데, 이러한 기능을 흐름 제어(Flow Control)라 한다. 흐름 제어는 송신 호스트가 수신 호스트보다 아주 빨리 데이터를 전송하는 경우에 필요하다.

흐름 제어 기능을 제공하지 않으면 수신 호스트는 자신에게 도착한 데이터 프레임을 내부 버퍼에 보관할 여유를 갖지 못한다. 따라서 전송 매체를 통해 올바르게 도착한 데이터가 분실되는 결과를 초래할 수 있다. 흐름 제어 기능의 부재에 따른 프레임 분실은 앞서 설명한 전송 오류의 프레임 분실과 동일한 결과를 가져오기 때문에 이것도 데이터를 재전송하는 방법으로 복구해야 한다.

흐름 제어의 기본 원리는수신 호스트가 다음에 수신할 프레임의 전송 시점을 송신 호스트에 통지하는 방식이다. 가장 많이 사용하는 흐름 제어 프로토콜의 예는 슬라이딩 윈도우 프로토콜이다.

<Pycharm settings>Theme, Changing font_size etc...

wisecow — Tue, 3 Oct 2017 16:15:14 +0900

모든 IDE가 그렇듯, Pycharm 또한 테마 혹은 폰트를 변경하기 위해서는 File > Settings를 클릭하여 설정창을 띄운 후 원하는 부분을 수정해주면 된다. 하지만 수많은 옵션 속에 우리가 원하는 부분만을 골라내어 수정하기란 매우 번거롭다.

이 글은 Pycharm 사용이 익숙치 않은 분들에게 가장 도움이 될 수 있는 몇 가지 옵션을 쉽고 빠르게 적용할 수 있게끔 사진과 함께 안내한다. // 도움이 될 수 있다는 건 물론 나의 주관적인 판단이다. 테마를 다양하게 설정할 수 있는 방법과 Visual Studio에서와 같이 Ctrl + MouseWheel 로 폰트 크기를 조절할 수 있게끔 설정할 수 있는 방법을 소개한다.

먼저 Pycharm의 테마를 다양하게 설정할 수 있는 방법을 소개한다. 방법이라 봤자 쓸만한 Plugin을 다운받는 것이 전부이지만. 첫째로, File > Settings를 클릭하여 창을 연다. 좌측의 메뉴 중 Plugins 항목을 클릭하면 아래와 같은 화면을 만나볼 수 있다.

위의 창에서 확인해야 할 건 하단의 3가지 탭이다. Install JetBrains plugin... / Browse repositories... / Install plugin from disk... 탭 중 Browse repositories... 탭을 클릭하자. 아래의 사진과 같이 검색창에 'Material Theme UI'라고 검색한 후 Install을 클릭해서 설치한다.

Install을 진행한 이후에 Pycharm을 다시 실행시켜주면, 아래의 사진과 같이 상단 메뉴바의 Tools에 Material Theme 항목이 추가되어 있는 것을 확인할 수 있고, 기본 Pycharm에서 제공하는 3가지 밋밋한 테마 이외의 다양한 컬러의 테마를 만나볼 수 있다. 자신이 원하는 테마를 선택하여 적용하면 된다. // 뿐만 아니라 File > Settings에 가면 Material Theme 항목이 Appearance & Behavior에도 추가되어 있는 걸 확인할 수 있는데, 해당 탭에서는 폰트 컬러 등 사용자가 원하는 디자인을 추가할 수 있게끔 되어 있다. 아마 따로 작업을 해주지 않아도 사용하는데는 큰 무리가 없을 것이다.

이제 마지막으로 Ctrl + MouseWheel 로 폰트 사이즈를 조절할 수 있는 방법을 소개한다. 생각보다 간단한데, File > Settings > Editor > General 탭에서 맨 위에서 2번째 항목인 Change font size (Zoom) with Ctrl + Mouse Wheel 항목을 체크해주면 된다. 아래 사진을 참고하자.

매우 간단한 설정이지만, 이것 또한 찾는데 시간이 꽤나 걸렸다. 또한 대부분 영어로 설명이 된 자료여서 읽고 해석하는데도 시간이 걸렸다. 위 두 가지 설정이 내가 생각하는 가장 기본적이면서도 꼭 필요한 셋팅이다.

마지막으로 한 가지만 더 설명하자면, 화면 분할하는 방법 또한 소개하고 싶다. 아래의 사진과 같이 상단 메뉴의 Window > Editor Tabs > Split Vertically 또는 Split Horizontally 를 클릭하면 된다.

화면 분할을 하면 아래와 같이 여러 개의 .py 파일을 에디터에서 보며 작업할 수 있어 편리하다. // 위 3가지 기본 설정만 하는데도 시간이 1시간 30분 정도는 걸린 것 같다. 이 글을 보는 사람들은 나처럼 시간을 낭비하지 않고 바로발로 셋팅할 수 있기를 바란다.

cmd 오류: 기본 클래스 *을(를) 찾거나 로드할 수 없습니다. 에 대하여

wisecow — Mon, 25 Sep 2017 11:50:06 +0900

자바를 cmd에서 컴파일 하고, 컴파일 한 .class 파일을 cmd에서 실행하려할 때 어김없이 등장하는 오류가 있는데, '기본 클래스 *를 찾거나 로드할 수 없습니다.' 라는 오류다.

나의 경우 보통 자바 파일을 관리할 때 패키지를 이용하여 관리한다. 패키지를 사용하다 보면 아래의 오류를 정말 많이 만날 수 있다. 해결법을 먼저 소개하자면, java 명령은 패키지의 parent 디렉토리에서 실행하되 실행할 .class 파일의 이름을 줄 때 패키지명.클래스파일명 으로 입력해야 한다.

java 명령어의 인자로 클래스 이름을 전달할 경우, 패키지 이름을 포함한 full class name을 전달해야 한다. java 프로그램에서는 인자로 들어온 full class name을 기준으로 .class 파일들을 찾기 때문이다. 결국 .class 파일의 상위 디렉토리(parent 또는 root 디렉토리)에서 실행을 해야 한다는 뜻이다.

/* 나의 경우 실행할 IOEx.class파일의 parent 디렉토리가 '자바의 정석\src' 였고, 이 위치에서 'java streamEx.IOEx 매개변수' 명령을 주어 성공적으로 실행을 시켰다. */

내가 만든 IOEx.class 파일은 매개변수로 준 소스파일(.java)의 내용을 그대로 출력해주는 기능을 담고 있다. 따라서 제대로 실행이 된다면 매개변수로 넘겨준 IOEx.java 파일의 내용이 그대로 cmd창에 출력되어야 할 것이다.

실행은 되었다는 건 맨 아래의 3줄을 보면 알 수 있지만 보다시피 아무런 것도 출력되지 않는다. IOEx 클래스 파일은 실행을 시켰지만 매개변수 값을 잘못 준 탓이다. IOEx.class 파일의 역할은 매개변수로 주어진 IOEx.java 의 소스코드를 그대로 출력해주는 것인데 화면에 아무것도 없다.

아래와 같이 IOEx.java 파일의 파일 경로를 현재 디렉토리를 기준으로 다시 설정해서 입력해서 결국 제대로 작동시켰다. cmd 창으로 java 실습을 할 때는 이처럼 패키지, 파일 경로 등을 특히 신경써야 한다.

/* 기존의 IOEx.java 매개변수를 streamEx\IOEx.java 로 경로를 추가해 다시 설정해주었다. streamEX라는 패키지(폴더) 안에 이 파일이 있었으므로 이는 당연한 수순이었다. */

cmd 창에서 작업을 할 일은 매우 드물겠지만, 매번 접하는 오류다 보니 한 번쯤 정리할 필요성을 느껴 이렇게 정리하게 되었다. 두번 다시 만나고 싶지 않은 오류 중 하나다.

<네트워크 주소의 표현>

wisecow — Fri, 22 Sep 2017 09:37:45 +0900

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */

시스템을 설계할 때는 기능이나 목적과 함께 구분자(Identifier)를 부여하는 방법을 가장 먼저 고려해야 한다. 디지털화된 컴퓨터에서는 구분자를 숫자로 된 주소로 표현할 수밖에 없다. 그러나 이런 주소 표현 방식은 일반 사용자에게 불편하므로 보통 외우기 쉬운 기호 형식의 이름을 추가로 부여한다. 주소와 이름은 일대일 관계가 이루어지며, 이들을 연결하는 기능이 필요하다. 대상을 유일하게 구별하는 구분자는 일반적으로 아래 네 가지 특징이 있다.

유일성: 구분자의 가장 중요한 역할은 대상 시스템을 서로 구분하여 지칭하는 것이다. 따라서 서로 다른 시스템이 같은 구분자를 갖지 않는 유일성을 보장해야 한다. // 유일성이 보장되지 않는다면 구분자라 부를 수 조차 없는 것이다. 구분할 수가 없으니까.
확장성: 시스템은 활용의 보편화가 진행되면서 자연스럽게 확장 과정을 거친다. 따라서 사용하는 구분자의 양도 증가한다. 시스템의 최대 수용 규모를 예측하여 구분자의 최대 한계를 올바르게 설정하지 않으면, 표현할 수 있는 공간의 크기가 제한되어 시스템의 확장성도 제한된다.

/* 실제로 IP 주소는 원래 32비트의 이진 숫자로 구성되어 있었는데, 인터넷 사용자가 급격히 많아짐에 따라 주소 표현 공간을 128비트로 확장했다. */
편리성: 일반적으로 시스템의 설계 과정에서 부여되는 구분자는 시스템의 내부 처리 구조를 효율적으로 운용할 수 있도록 해준다. 컴퓨터 시스템은 내부적으로 숫자 기반으로 처리되기 때문에 구분자의 체계도 숫자 위주다. 또 배치, 검색 등을 원활하게 수행하기 위해 보통 일반인이 의미를 이해할 수 없는 형식이다.
이처럼 시스템 내부 동작에 종속된 구분자 주소 체계는 사용자가 의미를 파악하기 어렵기 때문에 기호로 된 이름을 추가로 부여해야 한다. 따라서 하나의 시스템이 숫자로 된 주소와 문자로 된 이름을 모두 가지므로 이를 매핑(Mapping)하는 기능이 필요하다. // 110101010010111010 과 같이 되어 있는 데이터는 확실하게 사람이 해석하기 난해한 구조로 되어 있다. 따라서 이름을 추가로 부여하는 것이고, 후에는 이 이름과 본래 담겨 있는 수를 매칭, 매핑 해주는 작업이 필요한 것이다.
정보의 함축: 구분자는 응용 환경에 필요한 다양한 정보를 포함하는 경우가 많다. 예를 들어, 주민번호에는 생년월일, 성별 구분 등의 의미가 부여되어 있다. 집주소도 광역시부터 시작해 지역을 소규모로 분할하는 구조를 가져 위치를 쉽게 가늠할 수 있다. 이처럼 구분자는 응용 환경에 적절히 대응할 수 있는 정보를 포함해야 한다.

# 주소와 이름

시스템을 지칭하는 구분자는 내부적으로 처리, 관리되는 숫자 기반의 주소(Address)와 사용자의 이해와 편리성을 도모하는 기호로 된 이름(Name)을 함께 제공해야 한다. 일반 사용자는 내부 주소를 몰라도 이름만으로 시스템에 접근할 수 있어야 하며, 이름과 주소를 연결하는 방법은 내부적으로 처리되어야 한다. // 우리가 1101010101010 과 같은 이진주소를 다 알아서 사용할 필요가 없다는 뜻이다. 애초에 그렇게 시스템을 설계하면 이는 편리성의 원칙을 완전히 무시한 꼴이 된다.

네트워크 규모가 작아 관리하는 시스템이 작으면 간단한 형식의 주소와 이름을 사용할 수 있다. 따라서 주소와 이름을 관리하는 시스템도 그리 복잡하지 않다. 그러나 관리 대상이 많아지면 주소와 이름 공간도 커지고, 이를 관리하는 시스템의 기능도 복잡해진다. // 그렇기에 설계할 때 더욱 주의를 기울여야 한다. 유일성의 원칙이 깨지지 않으면서 확장성과 편리성의 극대화를 이루는 설계를 지향하자.

네트워크에는 여러 종류의 주소와 이름이 존재한다. 각 계층의 기능을 담당하는 프로토콜마다 주소를 별도로 관리하기 때문이다. 예를 들어, IP 프로토콜은 호스트를 구분하기 위하여 IP 주소를 사용하며, 데이터 링크 계층에서는 LAN 카드별로 MAC 주소를 따로 부여한다. 전송 계층을 수행하는 TCP에서는 호스트에서 수행되는 네트워크 프로세스마다 별도의 포트(Port)주소를 할당하고 관리한다.

# IP 주소

IP 주소(IP Address)는 네트워크 계층의 기능을 수행하는 IP 프로토콜이 호스트를 구분하려고 사용하는 주소 체계다. 임의의 호스트를 인터넷에 연결하려면 반드시 IP 주소를 할당받아야 한다. IP 주소는 32비트 이진 숫자로 구성되는데, 보통 8비트씩 네 부분으로 나누어 십진수로 표현한다. // 11010011(211) 11011111(223) 11001001(201) 00011110(30) -> 211.223.201.30

IP 주소는 유일성을 보장하기 위해 국제 표준화 기구에서 전체 주소를 관리하고 할당해 중복 주소의 사용을 원천적으로 차단한다. IP 프로토콜이 처음 개발될 당시에는 현재처럼 폭넓게 활용되리라 예측하지 못했다. 따라서 IP 주소로 표현할 수 있는 최대 주소 공간의 크기를 32비트로 제한함으로써 확장성에 많은 문제점이 야기되고 있다. 이를 해결하려고 새로운 프로토콜 IPv6(Internet Protocol Version 6)에서는 주소 표현 공간을 128비트로 확장했다. 그리고 현재의 IP 프로토콜은 IPv6과 구분하기 위해 IPv4로 표현한다.

IP 주소는 임의로 할당되는 것이 아니라 어떤 규칙에 따라 인접한 숫자를 그룹으로 묶어 관리한다. 따라서 경로 선택 시 IP 주소를 중요한 기준으로 활용할 수 있다. IP 주소를 보고 라우터는 어디로 패킷(데이터)을 보내야 하는지 경로를 설정할 수 있다. // 예를 들어 211.223.201.0 ~ 211.223.201.30 은 전산실에서 사용한다 등 네트워크를 관리하는 학교별 단체별 자기들끼리 정한 규칙이 있을 것이다. 이러한 정보를 이용하면 인접한 곳에 데이터를 보낼 때 어떤 경로를 이용하는 것이 효율적인지 등의 판단을 내리기 훨씬 수월하다는 의미다.

# 호스트 이름

인터넷에서 특정 호스트와 연결하려면 반드시 호스트의 IP 주소를 알아야 한다. 그런데 숫자로 된 IP 주소는 기억하기 힘들어 보통 의미 파악이 쉬운 문자로 된 호스트 이름을 사용한다.

아래 그림은 일반 사용자가 문자로 된 호스트 이름을 사용하였을 때 IP 주소로 변환되는 과정을 보여준다.

맨 밑에 있는 네트워크 계층의 IP 프로토콜에서는 호스트를 구분하려고 IP 주소만 사용한다. // 컴퓨터에게 필요한 건 문자가 아니라 오로지 숫자이기 때문에.

그에 비해 일반 사용자는 IP 주소 대신 문자로 된 호스트 이름을 사용하기 때문에 중간 계층에서 이를 변환하는 기능을 수행해야 한다. 일반적으로 FTP, 텔넷 같은 네트워크 응용 프로그램은 실행시 사용자에게 호스트 이름을 명령어 인수로 입력받는다.

따라서 가장 먼저 수행해야 할 작업은 이름과 주소 변환 기능인 DNS(Domain Name System)를 이용하여 IP 주소를 얻는 것이다. DNS에서는 호스트 이름을 국가 도메인, 단체 종류, 단체 이름, 호스트라는 네 계층 구조로 나누고, 이들을 점(.)으로 구분해 표기한다. 예를 들어, reddevil.koteam.co.kr과 같은 호스트 이름은 대한민국(kr)에 있는 일반 회사(co) 중에서 koteam라는 회사에 소속된 reddevil라는 호스트다.

<호스트> . <단체 이름> . <단체 종류> . <국가 도메인>

국가 도메인은 호스트가 위치한 국가의 이름을 두 글자의 약자로 표시한다. 한국은 kr, 일본은 jp로 나라마다 고유한 국가 도메인이 존재한다. 단체 종류는 해당 단체의 성격에 따라 부여된다. co(company)는 회사, ac(academy)는 교육 기관, go(government)는 정부 소속 기관이다.

단체 이름은 단체를 상징하는 이름을 사용한다. 회사의 경우는 회사명을, 학교의 경우는 학교 이름을 사용한다. 마지막으로 호스트는 소속 단체의 네트워크 관리자가 내부 규칙에 따라 부여한 이름을 사용한다. // 내부 규칙을 따랐다는 말은 그 단체 안에서의 룰을 적용시켰다는 의미일 뿐이다. 회사나 단체에서 어떤 의사결정을 함에 있어 아무 생각도 없이 호스트 이름을 만들지는 않을 것이니 각 회사별 단체별 규칙을 따랐다는 것을 서술한 것이다.

<인터네트워킹(Internetworking)과 프로토콜(Protocol)>

wisecow — Wed, 20 Sep 2017 19:31:57 +0900

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */

네트워크와 네트워크의 연결을 인터네트워킹(Internetworking)이라 한다. 연결하는 네트워크 수가 증가할수록 복잡도가 커진다. 인터넷은 IP 프로토콜을 지원하는 전 세계의 모든 네트워크가 연결된 시스템을 의미하며, 라우터라는 중개장비를 사용해 네트워크를 연결한다.

# 네트워크의 연결

서로 독립적으로 운영되는 두 네트워크가 연동되어 정보를 교환하려면, 이를 적절히 연결하여 데이터를 중개할 수 있는 인터네트워킹 시스템이 필요하다. 여기서 네트워크가 연동한다는 의미는 물리적인 연결뿐만 아니라, 데이터 중개에 필요한 상위 통신 프로토콜을 모두 지원함을 뜻한다.

인터네트워킹 시스템에 의해 연결된 두 네트워크는 물리적으로 같은 종류일 필요는 없다. 상위 계층 프로토콜이 지원하는 논리적 기능이 달라도 된다. 하지만 인터네트워킹 시스템은 양쪽 네트워크에 대한 서로 다른 물리적, 기능적 인터페이스를 모두 지원해야 한다. // 그렇지 않으면 물리적, 기능적 인터페이스가 모두 같아야 한다는 말인데, 매우 비효율적이라는 걸 금방 알 수 있을 것이다.

또한 이 과정에서 데이터 표현 방식을 포함해 프로토콜이 다르면 필요한 변환 작업을 수행해야 한다. 이렇게 인터네트워킹 시스템은 둘 이상의 네트워크를 유기적으로 연동할 수 있다.

# 프로토콜

프로토콜(Protocol)은 통신 시스템이 데이터를 교환하기 위해 사용하는 통신 규칙이다. OSI 7 계층 모델에서는 각 계층에서 수행되는 프로토콜이 서로 독립적이라고 간주한다. 따라서 계층 1에는 계층 1끼리 통신할 수 있는 프로토콜이 존재하고, 계층 2에는 계층 2 끼리 통신할 수 있는 프로토콜이 존재한다.

/* 우리가 스마트폰으로 상대방과 전화를 할 때에도 프로토콜이 존재한다. 스마트폰은 단지 미리 주어진 규칙대로 자신의 일을 묵묵히 수행하는 것 뿐이다. 서로 규칙이 다르면 원활한 통화는 절대 이루어질 수 없다. */

/* 예를 들어, 분명 나는 전화벨이 울리고 통화 버튼을 눌러서 통화를 하는 것으로 알고 있었는데 상대방의 스마트폰은 내 그런 절차를 모르고 바로 통화를 할 수 있는 것으로 인지하여 통화가 진행된다고 해보자. 상대방이 듣지도 않는데 말을 하는 현상 등이 생길 것이다. 당장은 이해가 안될 수 있지만 상호 협의된 규칙이라고 일단은 생각해두는 것이 낫겠다. */

/* 더군다나 상호 협약된 규칙이 없다면 그때 그때마다 규칙을 새롭게 생성하고 정해야 하는데, 전세계적으로 스마트폰 기종만 100개가 넘는데 일일이 다 적용시킨다고 생각해 보면, 엄청난 비용과 비효율성이 발생할 것임이 자명하다. */

# 게이트웨이

인터네트워킹 기능을 수행하는 시스템을 일반적으로 게이트웨이(Gateway)라 부른다. 게이트웨이는 기능에 따라 종류가 다양하지만 리피터, 브리지, 라우터 등이 가장 일반적인 구분이다.

# 리피터

리피터(Repeater)는 물리 계층의 기능을 지원한다. 물리적 신호는 전송 거리가 멀면 감쇄되기 때문에 중간에 이를 보완해 주어야 한다. 리피터는 한쪽에서 입력된 신호를 물리적으로 단순히 증폭하여 다른 쪽으로 중개하는 역할을 한다. // 소리를 지르면 가까이에선 크게 들리지만 멀면 멀수록 작게들리는 것과 같이 물리적 신호는 거리가 멀수록 점점 감쇄한다.

# 브리지

브리지(Bridge)는 리피터 기능에 데이터 링크 계층의 기능이 추가된 게이트웨이이다. // 데이터 링크 계층은 물리 계층으로 데이터를 전송하는 과정에서 발생하는 잡음(Noise)과 같은 물리적 오류를 감지(Sense)하는 기능을 제공하여 송수신 호스트가 오류를 인지할 수 있게 해준다.

# 라우터

라우터(Router)는 물리 계층, 데이터 링크 계층, 네트워크 계층의 기능을 지원한다. 네트워크 계층은 경로 선택 기능을 제공해야 하므로 임의의 네트워크에서 들어온 데이터를 어느 네트워크로 전달할지 판단할 수 있어야 한다. 이를 지원하기 위하여 라우터는 자신과 연결된 네트워크와 호스트 정보를 유지하고 관리함으로써, 어떤 경로를 이용할 수 있고, 또 어떤 경로를 이용해야 빠르게 전송할 수 있는지를 판단한다. 이런 판단을 위한 정보는 일반적으로 라우팅 테이블(Routing Table)에 보관한다.

# 데이터 단위

네트워크 프로토콜을 사용해 데이터를 교환할 때는 먼저 데이터를 특정 형태로 규격화하는 작업이 필요하다. 예를 들어, 우편물을 보낼 때 정해진 규격 봉투를 사용하는 것과 같다. 규격 봉투에 보내는 사람, 받는 사람, 우표 등의 규칙에 따라 정보를 기입하는 것처럼, 네트워크에서도 데이터를 프로토콜에 맞춰 묶어준다.

OSI 7 계층 모델의 각 계층에서 규격화된 데이터는 다음과 같이 고유 명칭이 있다. 계층에 상관없이 사용할 때는 통칭하여 PDU(Protocol Data Uniit)라고 부른다.

APDU(Application Protocol Data Unit): 응용 계층에서 사용하는 데이터의 단위
PPDU(Presentation Protocol Data Unit): 표현 계층에서 사용하는 데이터의 단위
SPDU(Session Protocol Data Unit): 세션 계층에서 사용하는 데이터의 단위
TPDU(Transport Protocol Data Unit): 전송 계층에서 사용하는 데이터의 단위. 인터넷에서 사용하는 전송 계층 프로토콜인 TCP에서는 세그먼트(Segment)라고 부르고, UDP에서는 데이터그램(Datagram)이라고 부른다. 데이터그램은 일반적인 의미로도 자주 사용한다.
NPDU(Network Protocol Data Unit): 네트워크 계층에서 사용하는 데이터의 단위, 보통 패킷(Packet)이라고 부른다. 패킷은 원래 네트워크 계층의 IP 프로토콜에서 유래되었지만 요즘은 일반 용어로 많이 사용한다.
DPDU(Data Link Protocol Data Unit): 데이터 링크 계층에서 사용하는 데이터의 단위, 보통 프레임(Frame)이라고 부른다.

<스트림(Stream)>

wisecow — Mon, 18 Sep 2017 01:03:30 +0900

# 스트림

스트림(Stream)이라는 영단어는 흐르는 시냇물을 뜻한다. 종이배를 시냇물에 올려 두면 떠내려가듯, 컴퓨터 공학에서 스트림은 데이터라는 종이배를 띄울 수 있는 시냇물이다. 즉, 데이터의 흐름을 의미한다.

입력 스트림은 키보드, 마우스, 네트워크 등과 같은 입력 장치로부터 입력된 데이터가 순서대로 프로그램으로 흘러가는 데이터의 흐름 혹은 소프트웨어 장치를 말하고, 출력 스트림은 프로그램에서 출력된 데이터가 프린터, 콘솔, LCD, 네트워크 등과 같은 출력 장치로 순서대로 전송되도록 보장하는 데이터의 흐름 혹은 소프트웨어 장치를 말한다.

입력 스트림은 데이터가 입력 장치에서 프로그램으로 들어가는 방향이며, 프로그램에서 출력 장치로 데이터가 이동하는 방향이 출력 스트림의 방향이다. 입력 스트림의 경우 먼저 들어온 데이터가 먼저 프로그램에게 전달되는 FIFO(Frist In First Out) 구조이고, 출력 스트림의 경우 프로그램에서 출력되어진 순서대로 출력된다.

/* 프로그램에서 출력된다는 뜻은 데이터의 전송, 흐름을 뜻한다. 예를 들어 사용자가 한글이나 워드 프로그램에서 인쇄를 눌렀다면, 그 데이터가 입력스트림으로 PC 본체에 흘러 들어가고 본체에 들어온 데이터는 다시 출력 스트림을 통해 연결된 프린터기로 가는 구조라고 생각하면 된다. 결국 출력도 데이터의 흐름이라고 생각하면 된다. */

스트림을 통해 흘러가는 데이터의 기본 단위는 바이트다. 프로그램은 입력 스트림으로부터 받은 바이트들을 문자로 해석하거나, 4바이트씩 끊어 정수(Integer)로 인식하는 등 다양하게 해석할 수 있다. 이는 전적으로 프로그램을 제작하는 프로그래머에게 달려있다.

컴퓨터의 입출력 시스템은 서로 유기적으로 연결될 수도 있다. 아래의 코드를 예로 살펴보자.

InputStreamReader rd = new InputStreamReader(System.in);

이 프로그램 코드는 표준 입력 스트림을 발생시키는 장치인 System.in에 의해 리턴되는 스트림 데이터를 문자 스트림으로 변환하는 InputStreamReader에 연결시킨다. InputStreamReader를 통해 데이터를 읽으면 입력된 순서로 문자 값으로 해석하여 읽을 수 있다.

예를 들어보자. 사용자가 키보드로 'b', '!' 키를 입력하면, 표준 입력 스트림 System.in은 단순히 'b'와 '!'키의 바이트 정보를 보낸다. 바이트 스트림이 InputStreamReader를 통과하면서 InputStreamReader는 이들 바이트 정보를 문자로 인식하여 'b', '!'의 문자로 응용프로그램에게 전달해준다. // 데이터를 문자로서 해석하기 위해 InputStreamReader를 거쳤다고 생각하면 된다.

결국 연결된 스트림을 통해 표준 입력 스트림의 데이터가 문자 스트림으로 변환된다. 스트림은 데이터 처리를 위하여 몇 개라도 연결이 가능하다. 아래는 스트림의 몇 가지 특징을 적어 놓았다.

스트림은 지연될 수 있다: 입력 스트림의 데이터가 흘러가는 통로가 비어 있다면, 프로그램은 읽어갈 데이터가 없으므로 스트림에 데이터가 도착할 때까지 기다린다. 반대로 출력 스트림의 데이터가 흐르는 통로에 데이터가 꽉 차 있다면 프로그램은 더 이상 출력할 수 없기에 빈 공간이 생길 때까지 기다린다. 이처럼 입출력 시스템은 지연될 수 있다.
스트림은 바이트 스트림과 문자 스트림으로 나눌 수 있다: 자바에서 스트림의 종류에는 바이트 스트림과 문자 스트림이 있다. 프로그램은 필요에 따라 이들 중 하나를 선택하여 사용하면 된다.

자바에서는 응용프로그램이 입출력 스트림을 생성하여 입출력을 수행할 수 있도록 입출력 스트림을 위한 클래스를 제공한다. 아래는 텍스트로 이루어진 스트림 클래스 계층 구조이다. // 출처: https://docs.oracle.com/javase/7/docs/api/java/io/package-tree.html

Class Hierarchy

java.lang.Object
- java.io.Console (implements java.io.Flushable)
- java.io.File (implements java.lang.Comparable<T>, java.io.Serializable)
- java.io.FileDescriptor
- java.io.InputStream (implements java.io.Closeable)
  - java.io.ByteArrayInputStream
  - java.io.FileInputStream
  - java.io.FilterInputStream
    - java.io.BufferedInputStream
    - java.io.DataInputStream (implements java.io.DataInput)
    - java.io.LineNumberInputStream
    - java.io.PushbackInputStream
  - java.io.ObjectInputStream (implements java.io.ObjectInput, java.io.ObjectStreamConstants)
  - java.io.PipedInputStream
  - java.io.SequenceInputStream
  - java.io.StringBufferInputStream
- java.io.ObjectInputStream.GetField
- java.io.ObjectOutputStream.PutField
- java.io.ObjectStreamClass (implements java.io.Serializable)
- java.io.ObjectStreamField (implements java.lang.Comparable<T>)
- java.io.OutputStream (implements java.io.Closeable, java.io.Flushable)
  - java.io.ByteArrayOutputStream
  - java.io.FileOutputStream
  - java.io.FilterOutputStream
    - java.io.BufferedOutputStream
    - java.io.DataOutputStream (implements java.io.DataOutput)
    - java.io.PrintStream (implements java.lang.Appendable, java.io.Closeable)
  - java.io.ObjectOutputStream (implements java.io.ObjectOutput, java.io.ObjectStreamConstants)
  - java.io.PipedOutputStream
- java.security.Permission (implements java.security.Guard, java.io.Serializable)
  - java.security.BasicPermission (implements java.io.Serializable)
    - java.io.SerializablePermission
  - java.io.FilePermission (implements java.io.Serializable)
- java.io.RandomAccessFile (implements java.io.Closeable, java.io.DataInput, java.io.DataOutput)
- java.io.Reader (implements java.io.Closeable, java.lang.Readable)
  - java.io.BufferedReader
    - java.io.LineNumberReader
  - java.io.CharArrayReader
  - java.io.FilterReader
    - java.io.PushbackReader
  - java.io.InputStreamReader
    - java.io.FileReader
  - java.io.PipedReader
  - java.io.StringReader
- java.io.StreamTokenizer
- java.lang.Throwable (implements java.io.Serializable)
  - java.lang.Error
    - java.io.IOError
  - java.lang.Exception
    - java.io.IOException
      - java.io.CharConversionException
      - java.io.EOFException
      - java.io.FileNotFoundException
      - java.io.InterruptedIOException
      - java.io.ObjectStreamException
        java.io.InvalidClassException
        java.io.InvalidObjectException
        java.io.NotActiveException
        java.io.NotSerializableException
        java.io.OptionalDataException
        java.io.StreamCorruptedException
        java.io.WriteAbortedException
      - java.io.SyncFailedException
      - java.io.UnsupportedEncodingException
      - java.io.UTFDataFormatException
- java.io.Writer (implements java.lang.Appendable, java.io.Closeable, java.io.Flushable)
  - java.io.BufferedWriter
  - java.io.CharArrayWriter
  - java.io.FilterWriter
  - java.io.OutputStreamWriter
    - java.io.FileWriter
  - java.io.PipedWriter
  - java.io.PrintWriter
  - java.io.StringWriter

<OSI 7계층 모델의 계층별 기능>

wisecow — Wed, 13 Sep 2017 17:06:10 +0900

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */

# 물리 계층 1 Physical Layer

네트워크에서 호스트가 데이터를 전송하려면 반드시 전송 매체로 연결되어 있어야 한다. 물리 계층(Physical Layer)은 호스트를 전송 매체와 연결하기 위한 인터페이스 규칙과 전송 매체의 특성을 다룬다.

# 데이터 링크 계층 2 Data Link Layer

물리 계층으로 데이터를 전송하는 과정에서는 잡음(Noise) 같은 여러 외부 요인에 의해 물리적 오류가 발생할 수 있다. 데이터 링크 계층(Data Link Layer)은 물리적 전송 오류를 감지(Sense)하는 기능을 제공해 송수신 호스트가 오류를 인지할 수 있게 해준다.

발생 가능한 물리적 오류의 종류에는 데이터가 도착하지 못하는 데이터 분실과 내용이 깨져서 도착하는 데이터 변형이 있다. 일반적으로 컴퓨터 네트워크에서의 오류 제어(Error Control)는 송신자가 원 데이터를 재전송(Retransmission)하는 방법으로 처리한다.

# 네트워크 계층 3 Network Layer

송신 호스트가 전송한 데이터가 수신 호스트까지 도착하려면 여러 중개 시스템을 거친다. 이 과정에서 데이터가 올바른 경로를 선택할 수 있도록 지원하는 계층이 네트워크 계층(Network Layer)이다. 중개 시스템의 기능은 일반적으로 라우터(Router) 장비가 수행한다. 네트워크 부하가 증가하면 특정 지역에 혼잡(Congestion)이 발생할 수 있는데, 이것도 데이터의 전송 경로와 관계가 있으므로 네트워크 계층이 제어한다.

# 전송 계층 4 Transport Layer

컴퓨터 네트워크에서 데이터를 교환하는 최종 주체는 호스트 시스템이 아니고, 호스트에서 실행되는 프로세스다. 전송 계층(Transport Layer)은 송신 프로세스와 수신 프로세스간의 연결(Connection) 기능을 제공하기 때문에 프로세스 사이의 안전한 데이터 전송을 지원한다. 계층 4까지의 기능은 운영체제에서 시스템 콜(System Call) 형태로 상위 계층에 제공하며, 계층 5~7의 기능은 사용자 프로그램으로 작성된다.

# 세션 계층 5 Session Layer

세션 계층(Session Layer)은 전송 계층의 연결과 유사한 세션 연결을 지원하지만 이보다 더 상위의 논리적 연결이다. 즉, 응용 환경에서의 사용자 간의 대화(Dialog) 개념의 연결로 사용되기 때문에 전송 계층의 연결과는 구분된다.

# 표현 계층 6 Presentation Layer

표현 계층(Presentation Layer)은 전송되는 데이터의 의미(Semantic)를 잃지 않도록 올바르게 표현하는 방법(Syntax)을 다룬다. 정보를 교환하는 시스템이 표준화된 방법으로 데이터를 인식할 수 있도록 해주는 역할을 한다. 표현 계층의 주요 기능은 압축과 암호화다. 동영상과 같은 대용량의 멀티미디어 데이터를 압축(Compression)해 전송 데이터의 양을 줄일 수 있다. 암호화는 외부의 침입자로부터 데이터를 안전하게 보호하는 기능인데, 전자상거래가 증가하면서 중요성이 커지고 있다.

# 응용 계층 7 Application Layer

응용 계층(Application Layer)은 사용자의 다양한 네트워크 응용 환경을 지원한다. 기능은 한 분야에 한정되지 않고 매우 광범위하다.

/* 일반 사용자는 OSI 7 계층 맨 위에 있는 응용 계층을 통해 데이터의 송수신을 요청하며, 이 요청은 하위 계층으로 순차적으로 전달되어 맨 아래에 있는 물리 계층을 통해 상대 호스트에 전송된다. 그리고 요청이 각 계층으로 하달되는 과정에서 계층 별로 담당하는 기능을 수행해 데이터를 안전하게 전달한다. (7레벨 부터 1레벨까지 순차적으로 진행) */

/* 데이터를 수신한 호스트에서는 송신 호스트와 반대 과정으로 처리한다. 즉 물리 계층으로 들어온 데이터는 순차적인 상향 전달 과정 (1레벨 물리 계층부터 7레벨 응용 계층까지)을 거쳐 응용 계층으로 올라간다. 그리고 처리가 완료된 결과를 회신할 때는 반대 과정을 순차적으로 밟아 송신 호스트로 되돌아간다. */

<시스템 기초 용어>

wisecow — Wed, 13 Sep 2017 16:37:22 +0900

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */

네트워크는 외형적으로 시스템과 전송 매체로 구성된다. 데이터 통신을 위한 전송 매체는 전송 대역, 전송 속도, 전송 오류율 같은 물리적인 특성이 주 관심사므로 논리적인 기능은 비교적 단순한다. 시스템은 전송 매체를 이용해 논리적으로 다양한 연동 형태로 구성할 수 있어 개념의 확장이 폭넓고 복잡하다.

네트워크를 구성하는 시스템이 반드시 컴퓨터처럼 복잡한 기능을 수행해야 하는 것은 아니지만, 일반적으로 컴퓨터 시스템으로 가정한다. 네트워크 시스템은 수행 기능에 따라 다음과 같이 다양하게 부를 수 있다.

# 노드

노드(Node)는 인터넷에 연결된 시스템을 가장 일반화한 용어다. 데이터를 주고받을 수 있는 모든 시스템을 통칭한다.

# 호스트

호스트(Host)는 일반적으로 컴퓨팅 기능이 있는 시스템이다. 일반 사용자가 응용 프로그램을 실행할 수 있어 사용자가 네트워크에 접속하는 창구 역할을 한다.

# 클라이언트

호스트를 세분화할 때 호스트 사이에 제공되는 서비스를 기준으로 클라이언트와 서버로 나눈다. 클라이언트(Client)는 서비스를 요청하는 시스템이다. 호스트는 다양한 서비스를 서로 주고받기 때문에 임의의 호스트가 클라이언트나 서버로 고정되지 않는다. 이용하는 서비스의 종류에 따라서 클라이언트가 될 수도 있고, 서버가 될 수도 있다. 그러므로 특정 서비스를 기준으로 클라이언트와 서버라는 상대적 용어로 구분한다.

# 서버

서버(Server)는 서비스를 주고받는 호스트들의 관계에서 특정 서비스를 제공하는 시스템이다. 일반적으로 서버는 클라이언트보다 먼저 실행 상태가 되어 클라이언트의 요청에 대기해야 한다. 그리고 영원히 종료하지 않으면서 클라이언트의 요청이 있을 때마다 서비스를 반복해서 제공해야 한다.

# 클라이언트와 서버

아래의 그림은 임의의 서비스를 기준으로 클라이언트와 서버의 상대적인 관계를 설명한다. 그림에서 호스트 2는 파일 송수신 기능을 제공하는 FTP(File Transfer Protocol) 서비스를 제공하며, 호스트 3은 원격 단말기 기능인 텔넷(Telnet) 서비스를 제공한다.

FTP 서비스를 먼저 살펴보면, 호스트 1은 호스트 2에 FTP 서비스를 요청한다. 따라서 FTP 서비스를 기준으로 하면 호스트 1이 클라이언트가 되고, 호스트 2는 서버가 된다. 반면, 텔넷 서비스는 호스트 2가 호스트 3에 요청한다. 텔넷 서비스를 기준으로 하면 호스트 2가 클라이언트고, 호스트 3은 서버다.

따라서 호스트 2는 사용하는 서비스의 종류에 따라 클라이언트가 되기도 하고, 서버가 되기도 한다. 결론적으로 클라이언트와 서버라는 용어는 서비스 이용의 상대적 위치에 따라 결정된다. // 절대적인 개념이 결코 아니다.

클라이언트와 서버의 명칭을 호스트 시스템에 부여해 사용할 수도 있다. 특히 다양한 서비스 기능을 제공하는 대형 시스템을 서버로 설정해 다수의 클라이언트가 서버에 접속해 서비스를 이용하도록 할 수 있다. 그러나 기능적인 관점에서는 위의 그림처럼 호스트에서 실행되는 응용 서비스별로 구분하는 것이 더 정확하다.

인터넷에서 네트워크 서비스의 기능은 대부분 응용 프로그램으로 구현되므로 보통 클라이언트 프로세스, 서버 프로세스라는 호칭이 더 자연스러울 수 있다.

<네트워크 기초 용어>

wisecow — Wed, 13 Sep 2017 16:18:27 +0900

/* 본 포스팅은 한빛미디어의 '쉽게 배우는 데이터 통신과 컴퓨터 네트워크 | 박기현 저'를 참고하여 작성되었음을 미리 알려드립니다. */

네트워크(Network)는 전송 매체(Transmission Media)로 서로 연결해 데이터를 교환하는 시스템(System)의 모음이다. 시스템과 전송 매체의 연결 지점에 대한 규격을 인터페이스(Interface)라 하고, 시스템이 데이터를 교환할 때 임의의 통신 규칙을 따르는데 이 규칙을 프로토콜(Protocol)이라 한다. 서로 다른 시스템이 상호 연동해 동작하려면 연동 형식의 통일이 필요하고 이 통일을 표준화(Standardization)라 한다.

시스템은 반드시 컴퓨터일 필요는 없지만 보통 컴퓨터 시스템으로 가정한다. 시스템은 물리적으로 공유하는 전송 매체로 서로 연결한다. 시스템이 전송 매체를 통해 데이터를 교환하려면 반드시 표준화된 프로토콜을 사용해야 한다. 흔히 사용하는 인터넷은 IP(Internet Protocol)라는 네트워크 프로토콜을 사용하는 네트워크 집합체다.

# 시스템

시스템(System)은 체제라고도 하는데, 내부 규칙에 따라 능동적으로 동작하는 대상이다. 자동차, 커피 자판기, 컴퓨터, 마이크로 프로세서, 하드 디스크 같은 물리적인 대상뿐만 아니라, 신호등으로 교통을 제어하는 운영 시스템, MS 윈도우즈 등의 운영체제, 프로그램의 실행 상태를 의미하는 프로세스 같은 논리적인 대상도 시스템이다.

시스템의 동작에 필요한 외부 입력이 있을 수 있으며, 내부 정보와 외부 입력의 조합에 따른 출력이 있을 수 있다. 작은 시스템이 여러 개 모여 더 큰 시스템을 구성할 수 있으므로 크기로는 시스템을 구분하지 않는다.

# 인터페이스

인터페이스(Interface)는 시스템과 시스템을 연결하기 위한 표준화된 접근 방법이다. 예를 들어, 컴퓨터 본체와 키보드를 연결하려면 키보드의 잭을 본체의 정해진 위치에 꽂아야 한다. 이를 위해서는 상호 간의 데이터 교환을 위한 RS-232C, USB 같은 논리적인 규격뿐만 아니라, 잭의 크기 모양 같은 물리적인 규격도 표준화되어야 한다. 인터페이스를 이용해 연결하는 시스템은 능력과 권한이 같은 경우도 있지만 서비스를 주고받는 상하 관계일 수도 있다.

/* RS-232는 PC와 음양 커플러, 모뎀 등을 접속하는 직렬 방식의 인터페이스의 하나이다. 인터페이스는 포트라고도 하여 일반적으로 직렬 포트라고 불리기도 한다. USB는 범용직렬버스라고 불리며(Universal Serial Bus) 컴퓨터와 주변 기기를 연결하는 데 쓰이는 입출력 표준의 하나이다. 대표적인 버전으로는 USB 1.0, 1.1, 2.0, 3.0, 3.1 등이 있다. */ 출처: 위키피디아

# 전송 매체

시스템끼리 정해진 인터페이스를 연동해 데이터를 전달하려면 물리적인 전송 수단인 전송 매체(Transmission Media)가 반드시 있어야 한다. 전송 매체는 사람의 눈으로 볼 수 있는 동축 케이블을 포함하여 소리를 전파하는 공기, 무선 신호 등 다양하다. 인터페이스는 시스템 간의 연동을 위한 논리적인 규격이고, 인터페이스에서 정해진 규칙은 매체를 통해 전송됨으로써 구현되고 동작된다고 볼 수 있다.

# 프로토콜

상호 연동되는 시스템이 전송 매체를 통해 데이터를 교환할 때는 특정 규칙을 따르는데, 이 규칙을 프로토콜(Protocol)이라 한다. 일반적으로 프로토콜은 주종 관계가 아닌 동등한 위치에 있는 시스템 사이의 규칙이라는 측면이 강조되어 인터페이스와 구분된다. 인터페이스는 두 시스템이 연동하기 위한 특정한 접촉 지점(Access Point)을 의미하는 경우가 많지만, 프로토콜은 주고받는 정보의 형식과 그 과정에서 발생하는 일련의 절차적 순서에 무게를 둔다.

# 네트워크

통신용 매체를 공유하는 여러 시스템이 프로토콜을 사용하여 데이터를 주고받을 때 이들을 하나의 단위로 통칭하여 네트워크(Network)라 부른다. 일반적인 컴퓨터 네트워크에서는 물리적인 통신 매체로 연결된 컴퓨터 간에 동일한 프로토콜을 이용해 데이터를 주고받는다. 소규모 네트워크가 모여 더 큰 네트워크를 구성할 수 있는데, 네트워크끼리는 라우터(Router)라는 중개 장비를 사용해 연결한다.

# 인터넷

인터넷(Internet)은 전 세계의 네트워크가 유기적으로 연결되어 동작하는 통합 네트워크다. 인터넷으로 연결된 시스템, 인퍼테이스, 전송 매체, 프로토콜 등은 종류가 매우 다양하지만 데이터 전달 기능에 한해서는 공통적으로 IP(Internet Protocol) 프로토콜을 사용한다. 인터넷이라는 용어는 IP의 첫 번째 단어인 Internet에서 유래되었다.

# 표준화

서로 다른 시스템이 상호 연동해 동작하려면 표준화(Standardization)라는 연동 형식의 통일이 필요하다. 예를 들어, 프린트 용지를 생각해보자. 일반적으로 프린터와 프린트 용지를 만드는 회사는 다르다. 하지만 사전에 A4 규격이라는 통일된 틀을 만들어두었기 때문에 여러 회사의 각기 다른 제품에서 프린트 용지를 자유롭게 사용할 수 있게 되었다.

/* IP는 'Internet Protocol'의 약자이지만, 고유 명사화되어있으므로 IP 프로토콜이라고 부를 수 있다. TCP, UDP 등 대부분의 네트워크 프로토콜도 마찬가지다. */

<기억의 집 | 최승자 시집>

wisecow — Wed, 6 Sep 2017 13:31:44 +0900

20살 이후로 처음 읽어보는 시집일 것이다. 메마른 땅에 촉촉한 비가 달게 받아들여지듯, 황무지 같던 내 마음에 이 시집은 감성의 싹이 틔어날 수 있게 해준 씨앗이다. 시인이 그랬듯, 지금은 서정 연습시대. 연습하지 않으면 내 안의 감정들이 사라져 버릴지도 모르기에 시집을 조용히 꺼내들었다.

시집을 읽으면서 가장 인상 깊었던 4가지의 시와 감상평을 아래 남겨 보았다. 시인의 배경과 삶의 철학 등을 잘 알지는 못하지만 시가 주는 울림은 상상이상이었고, 오랫 동안 마음 속에 남아있을 것 같다.

서녘 항구

저무는 해 닻을 내리고

서녘 항구,

불타는 관절염의 뼈들을 이끌고

나 여기까지 왔네.

흔들어, 흔들어줘!

순교도 배교도 구원이 될 수 없는 시대,

침묵하는 배들이 바닷속에 뿌리내릴 때

내 일생을 내 일평생을

흔들어, 흔들어줘!

/* 저무는 해의 닻을 내린다는 표현은 짧게는 하루가 끝나감을, 길게는 인생이 노년기에 접어듬을 연상시킨다. 그런 점에서 보면 뜨거운 가슴을 가졌던 젊은 시절과는 달리 이제는 점점 차갑게 식어가는 자신의 형상을 닻을 내리고 항구에 정착해 있는 배에 비유한 것 같다.

하지만, 이렇게 인생이 져감은 뭔가 석연치 않다. 항구에 떠 있는 배는 이른 새벽이 되면 다시 닻을 올려 바다로 역동적인 항해를 떠나지만, 화자 본인은 그럴 수 없다. 그렇기에 화자는 지금 이 순간, 배가 정착해 있는 이 순간에 자신의 일생을 인생을 다시 흔들어 달라고 하고 있다.

살면서 생긴 미련, 아쉬움들을 뒤로한 채 편히 저물어갈 수 없음이 느껴진다. */

물망초

우리가 엽전 열닷 냥 찌개 백반의

자유를 위해 분주할 때에도

모든 길들은 소리 없이 굽이치며 앓고,

보이지 않는 곳에서 물망초들은 피어난다.

외부를 향한 내부의 내부의

피흘림을 고요히 지우며

물망초는 또 한 가지를 뻗는다.

그와 같이 내 낮은 흐느낌 또한

하나의 말이 될 수 있을 때까지

잠시만 기다려 다오.

내가 이 잔을 다 비울 때까지

내가 꿈속에서 다시 한번만 돌아누울 때까지

내가 내 시야를 스스로 거둘 때까지

잠시만 기다려다오,

죽음이여

잠시만,

영원히.

/* 시를 처음 읽었을 때 알 수 있는 건 화자가 현세에 미련이 남아 있구나라는 것과 그 미련은 필연적으로 화자가 겪었을 어떤 일련의 사건들 - 그 사건들은 대부분 화자에게 상처 내지 부정적 감정을 줬던 것들 - 과 관련이 있겠구나 라는 점이다. 그리고 내면의 상처나 부정적인 감정 등을 완전히 이겨내고 털어내지 못했다는 것도 알 수 있다.

수 많은 피흘림과 흐느낌을 고요히 지우며 물망초가 가지를 뻗듯이 화자 또한 내면의 상처, 슬픔, 흐느낌 등을 내려놓아 말로 꺼낼 수 있기를 바라고 있다. 많은 세월이 흘렀음에도 아직 극복하지 못함에 대한 아쉬움이 여실히 드러난다.

특히 마지막 문단에 잠시만 기다려다오. 에서 영원히 라고 바뀌는 부분은 아쉬움을 서정적으로 정말 잘 표현했다. 애절함과 아쉬움이 잘 묻어난다. */

그 거

술은 끊어도 담배는 못 끊겠는 거, 그거.

담배는 끊어도 커피는 못 끊겠는 거, 그거.

커피는 끊어도 목숨은 못 끊겠는 거, 그거.

믿지 못하는 사이

두 발이 푹푹 빠져들어간다.

빠져들어간다는 것까지도

믿지 못하는 사이로

두 발은 더욱 습한 곳으로

푹푹 빠져들어간다.

(나의 이성과 감정은 언제나

나의 현실보다 뒤지는 거, 그거.)

/* 시집에 있는 모든 시 중 가장 소박하면서 귀엽지 않았나 라는 생각을 했다. 누구나 흔히 겪는 심적 갈등을 재치 있지만 깊이가 있는 시다. 욕구 중에서도 순위가 있다면 역시 제일은 살고 싶은 욕구라는 것 또한 시에 드러났다는 점이 참 좋다. */

그날의 함성은 아직도 유효하다

---4.19 에 부쳐

만질 수 있는 것과 만질 수 없는 것,

그 사이에서 4월의 亡者들은 // 亡(망할 망), 者(사람 자), 죽은 사람을 뜻함

돌아앉아 오래도록 꿈을 꾸고

그날의 함성은 아직도 유효하다.

최루탄을 쏘지 마라,

우리는 헤어지지 못한다,

않는다.

식도와 내장 속으로

소리 없이 피 번지는

그윽한 內出血의 4월에 // 內(안 내), 出(날 출), 血(피 혈)

우리는 다시 본다.

어떻게 절망이 희망 속으로 행군해가는가,

어떻게 슬픔의 이데올로기는

기쁨의 이데올로기와 쾌속으로 만나는가를.

최루탄을 쏘지 마라

그날의 함성은 아직도 유효하다.

/* 나는 직접적으로 운동권에 속해보거나 시위, 데모를 해 본 경험 등은 없지만, 이 시에서 흘러 나오는 뜨거운 감정은 나에게도 스며들어왔다. 특히 우리는 헤어지지 못한다라는 부분이 특히 그렇다. 사실은 헤어지지 않는 것이지만, 그건 어느새 의지의 영역이 아닌 의지로는 차마 담지 못하는 뜨거운 감정이 되어버린다. 앞에서 쓰러져 가는, 혹은 고통 당하는 동료들을 볼 때의 그 마음은 아직 경험해보진 않았지만, 어떤지 알 수 있을 것만 같다.

결론적으로 보면 항쟁은 성공했고, 슬픔의 이데올로기는 기쁨의 이데올로기로 이어졌다. 절망이 희망속으로 행군하여 이러낸 쾌거다. 그 날의 뜨거움의 열기가 오랜 세월을 넘어 현대까지 흘러 들어온다. */

<컴퓨터와 프로그래밍>

wisecow — Tue, 5 Sep 2017 17:46:24 +0900

/* 본 포스팅은 kocw의 유상미 교수의 '객체지양언어2' 강의를 듣고 정리한 내용임을 미리 알려드립니다. 유상미 교수의 본 강의 링크는 'http://www.kocw.net/home/search/kemView.do?kemId=1192791' 이며, kocw 사이트에서 따로 객체지향언어2나 교수 이름으로 검색하시면 만나볼 수 있습니다. */

# 컴퓨터, 프로그램, 언어

컴퓨터는 CPU, 메모리 등으로 결합된 하드웨어와 프로그램과 같은 소프트웨어로 구성되어 있다. 컴퓨터를 사용한다는 건 프로그램을 실행한다는 것과 동일한 의미이다. 프로그램은 컴퓨터의 중앙처리장치(CPU)가 처리하는 일련의 명령들과 데이터로 구성되어 있다.

프로그래밍 언어는 크게 저급 언어(low-level language)와 고급 언어(high-level language)로 나눌 수 있다. 저급 언어는 컴퓨터 처리에 용이(즉, 컴퓨터와 친하다)하며 고급 언어는 인간 친화적이다. // 인간 친화적이란 말은 사람이 이해하기 쉽게 구성되어 있다는 뜻이다. 0과 1만으로 이루어진 것보다 print와 같은 문장으로 출력을 할 수 있으니 인간 친화적이라 할 만한다.

1세대 부터 지금의 5세대에 이르기까지의 과정을 살펴 보면, 흔히 말하는 0과 1로만 구성된 기계어를 작성한 시대가 1세대, 기계어에 1:1로 대응하도록 기호화한 언어인 어셈블리어를 사용하던 시대가 2세대이다.

1~2세대에 사용하던 언어를 가리켜 저급 언어라 칭한다. 지금과 같은 고급 언어는 C, 포트란, 베이직, 코볼 등으로 일컬어지는 3세대부터 비주얼베이직, 델파이 파워빌드 등으로 구성됐던 4세대 언어에 이어 자바, C#, C++ 등에 해당하는 5세대 언어까지를 일컫는다.

출처: http://www.atmarkit.co.jp/fcoding/articles/gauche/01/gauche01a.html

위 그림을 살펴 보면, 초기 고급 언어 중 포트란(FORTRAN)은 수치 계산 분야에 많이 사용되었고 코볼(COBOL)은 사무처리 분야에서 많이 사용되었다. ALGOL 언어는 C, Pascal, Simula 언어에 많은 영향을 미쳤다. 이 중 C++은 기존의 Simula의 객체지향 개념의 영향을 받아 제작된 객체지향 언어다.

1980년대부터 C언어의 함수지향 개념의 한계를 넘기 위한 새로운 소프트웨어 개발 연구가 진행되면서 객체지향개념이 등장하게 되었다. 오늘날의 C++, Java, C# 등은 대표적인 객체지향언어로 사랑받고 있다. Java의 경우 객체지향개념과 함께 Lisp이란 언어의 Garbage Collection 이란 개념을 가지고 있다.

Lisp 언어가 있는 아래의 언어를 살펴 보면, Simula의 객체지향의 영향을 받은 Smalltalk 언어가 있다. 또한 최근에 초보자가 쉽게 작성할 수 있다 하여 사랑 받는 Python이 있다. 중간 기준선 위 아래로 구분된 건 동적언어냐 정적언어냐에 따라 구분할 수 있다. // 위쪽이 정적 언어이다.

# 인터프리터 컴파일러

프로그래밍 언어를 이용해서 작성된 프로그램을 소스코드 또는 소스 파일이라고 칭한다. 이 코드는 인간이 이해하기 쉬운 형태로 작성되어 있기 때문에 컴퓨터가 처리할 수 있는 언어로 변환을 해야 한다. 이런 변환 과정을 번역이라고 하는데, 번역을 하는 방식엔 인터프리터 방식과 컴파일러 방식이 있다.

인터프리터 방식은 소스코드 전체가 아닌, 코드를 한 줄씩 읽어와서 컴퓨터가 처리할 수 있는 형태로 시물레이션 하여 해석하고 실행하는 방식이다. 컴파일 방식은 컴파일러라 불리는 번역기를 이용하여 전체 소스코드에 대한 오류를 체크하고 이를 기계어와 유사한 중간 코드로 생성하는데 이 파일을 목적파일 이라고 한다. 이렇게 생성된 목적파일은 이후 링커와 로더에 의해 .exe 형태의 실행파일로 생성되어 컴퓨터가 처리할 수 있게 된다.

위 둘 방식의 가장 큰 차이는 목적파일을 생성하는가에 있다. 각각 처리방식에서 메모리 할당을 할 때 인터프리터 방식의 언어는 주로 동적할당을 하고 컴파일방식의 언어는 주로 정적할당을 한다. 메모리 할당을 정적으로 하면, 효율성이 좋고 동적할당을 위주로 하면 유연성이 좋으며 프로그래밍하기 쉽다는 장점이 있다. 위 두 방식 중 어떤 걸 택했느냐에 따라 각각 정적 언어, 동적 언어로 분류한다.

앞에서 살펴 본 언어들을 컴파일 언어와 인터프리터 언어로 분류하면, 앞의 동적언어와 정적언어의 분류방식 그림과 같다. 하나 다른 것이 있다면 Java 자체는 컴파일 언어로 분류되어 있다는 점이다. 그러나 Java는 동적 언어의 장점을 수용하고 있는 언어인데, 이것은 자바 언어를 이해하는데 매우 중요한 특징을 가진다.

C#이나 Go도 비슷한 방식으로 처리된다. Go는 2009년에 구글이 개발하여 공식 발표한 언어인데 이 언어 또한 컴파일 언어의 효율성과 동적 언어의 쉬운 프로그래밍을 목표로 개발 되었다. 문법적으로는 C와 유사하고, GarbageCollection 기능을 가지고 있다.

<9월 티스토리 초대장 배포: 7장> [마감]

wisecow — Sun, 3 Sep 2017 13:42:50 +0900

안녕하세요. 프로그래밍 관련 블로그를 운영하고 있는 데브맷입니다.

새롭게 블로그 시작하시려고 마음 먹으신 분들을 위해 초대장을 나눠드리려 합니다.

댓글에 이메일 주소와 블로그를 어떻게 운영할지 등을 짤막하게 한 줄로 남겨주세요!

[마감]

모두에게 드리지 못해 마음이 아플 따름입니다. 또 나오는 대로 바로바로 나눠드리겠습니다.

응원합니다 여러분.

Error:This Gradle plugin requires Studio 3.0 minimum 오류 해결

wisecow — Fri, 25 Aug 2017 22:37:31 +0900

본인은 분명 안드로이드 스튜디오 사이트에 등재되어 있는 최신 버전의 안드로이드 스튜디오를 다운 받았음에도 이와 같은 에러를 만나 매우 당황스러웠다.

오류가 발생한 건 공부차 분석해보고 싶은 오픈 소스 앱을 github에서 내려 받아 import project 하는 과정에서 생겼다. 최신 버전을 설치했음에도 더 상위 버전을 설치해야한다는 문구를 봤을 때의 당혹감.. 을 겪었다면 아래와 같이 해결해보자.

여러 가지 해결책이 있을 수 있으나, 스택 오버 플로우에서 참고한 답안이 생각보다 잘 적용되었기에 이렇게 공유하고자 한다. 링크와 사진을 함께 보도록 하자.

https://developer.android.com/studio/preview/index.html

위 링크로 접속하면 아직 안정적인 버전으로 정착하지는 않았지만, 최신 버전의 기능들이 탑재 되어 있는 Android Studio Preview 버전을 설치할 수 있다. 설치 버튼을 누르면 다운로드와 함께 다운로드 안내페이지로 이동하게 된다.

현재 안드로이드 스튜디오가 설치되어 있어도 함께 실행할 수 있기 때문에 걱정하지 않아도 된다. 둘은 별개의 프로그램으로 분류된다. Preview 버전으로 실행하면, 최신 버전이 아니여서 실행할 수 없다는 등의 에러를 만나지 않을 수 있다.

<함수 포인터와 역호출 구조> #qsort

wisecow — Fri, 25 Aug 2017 15:14:34 +0900

/* 본 포스팅은 최호성 저자의 '독하게 시작하는 C프로그래밍' 교재를 참조로 작성되었음을 먼저 알려드립니다. */

함수의 이름 또한 배열의 이름처럼 '주소 상수'에 부여한 식별자다. 따라서 함수의 이름도 포인터 변수에 저장할 수 있다. 다만 변수의 자료형이 함수 호출에 필요한 정보들을 포함하고 있어야 변수를 이용해서 함수를 호출할 수 있다. // 호출에 필요한 정보는 매개 변수, 호출 규칙, 반환 자료형 등이 있다.

그래서 'void *'에 함수의 이름을 저장할 수는 있으나 호출을 할 수는 없다. 아래의 코드는 함수 포인터를 구체적으로 다루기에 앞서 함수의 이름이 주소임을 확인하기 위한 코드다.

#include <stdio.h>

int main(void)
{
	// void *는 어떤 주소든 담을 수 있는 자료형이다.
	// 함수이름은 '주소' 이므로 void *에 담을 수 있다.
	void *pData = main;

	// 함수의 주소를 출력한다.
	printf("%p\n", pData);
	printf("%p\n", main);
	return 0;
}

7번 행에서 void형 포인터인 pData를 선언 및 정의하는데 있어 초깃값으로 'main'을 기술했다. pData에 들어 있는 주솟값이 main 이므로 10번 행과 11번 행은 같은 결과를 출력한다. 이러한 주소와 매개변수, 호출 규칙을 알면 일단 함수를 호출할 수 있다.

변수도 함수도 사실은 다 주소로 식별을 한다. 다만 그 주소의 메모리를 저장공간으로 활용할 것인가, 아니면 그 주소의 메모리에 저장된 정보를 CPU가 인식하는 명령코드로 볼 것인가만 다를 뿐이다.

# 함수 포인터

함수 포인터 변수의 문법은 약간 복잡하다. 다차원 배열에 대한 포인터처럼 '*'가 기술되는 위치가 중간에 기술되며 반드시 괄호로 묶어야 한다. 우선 기본 형식은 아래와 같다.

반환 자료형 ( 호출 규칙 *변수 이름) (매개 변수)

아래의 코드는 매개변수로 char *형 자료 한 개와 int형 정보 0을 반환하는 함수를 main( ) 함수에서 호출하는 코드다.

#include <stdio.h>

int testFunc(char *pszParam)
{
	return 0;
}

int main(void)
{
	// 괄호는 함수 호출 연산자
	testFunc("");

	// 저장하는 행위 자체는 허용이 된다.
	// 다만 자료형이 맞지 않는다.
	int nData = testFunc;

	nData("");
	return 0;
}

다소 난해하게 보이는 이 코드는 일단 컴파일 에러가 난다. int nData = testFunc; 까지는 허용이 되지만 nData(""); 부분에서 오류가 난다. 주소 상수인 testFunc를 int형 변수에 저장하는 건 되지만 이걸로 함수 호출까지는 되지 않는다는 걸 확인할 수 있다. 하지만 아래와 같이 코드를 수정하면 어떻게 될까?

#include <stdio.h>
// 함수 포인터를 사용하는 기본 형식
//int (*이름) (char*)
int testFunc(char *pszParam)
{
	return 0;
}

int main(void)
{
	// 괄호는 함수 호출 연산자
	testFunc("");

	// 저장하는 행위 자체는 허용이 된다.
	// 다만 자료형이 맞지 않는다.
	int nData = (int)testFunc;

	// 강제 형변환을 통해 함수호출을 할 수 있는 구조로
	// 만들어주면 호출이 가능하다.
	((int(*)(char*))nData)("");
	return 0;
}

정상적으로 컴파일이 되고 함수 호출까지 된다. 변수에 대한 이해도도 높일 수 있기에 좋은 코드라고 할 수 있다. 변수도 결국 메모리고 어떻게 해석하는지에 따라 용도가 얼마든지 달라질 수 있다. 비록 int 형 변수지만 함수를 호출할 수 있는 코드로 사용할 수 있다는 건 어찌보면 당연한 얘기다.

함수 호출 포인터의 문법이 이렇다는 점과 변수와 함수 이름 등은 모두 메모리에 기록된 상수이며 어떻게 해석하는지에 따라 달라진다는 점 또한 다시한 번 상기하자. 아래의 코드는 함수 포인터를 이용하여 함수를 호출하는 문법을 다시한 번 보여준다.

#include <stdio.h>

// 함수 포인터를 사용하는 기본 형식
//int (*이름) (char*)
int testFunc(char *pszParam)
{
	return 0;
}

int main(void)
{
	int(__cdecl *pfTestFunc)(char *) = testFunc;
	pfTestFunc("pszParam");
	return 0;
}

다차원 배열에 대한 포인터처럼 (호출규칙 *이름)이 괄호로 묶이는 것 때문에 조금 복잡해 보이는 것 뿐, 나머지는 함수 본래의 반환 자료형과 매개변수 자료형을 그대로 기술하면 된다.

그리고 늘상 봐오던 함수호출 연산자에 대해서도 언급을 하자면, 함수호출 연산자는 바로 괄호이며 주소( 매개변수 ) 형식으로 사용한다. 여기서 주소는 물론 함수 이름이다. 혹은 함수 포인터 일 수도 있다. 바로 위의 코드는 함수 호출을 함수 포인터로 하는 것에 대한 예제 코드다.

# 역호출 구조

함수호출 연산자나 함수 포인터가 꼭 필요한 경우가 언제인지에 언급하자면 아래의 두 경우가 있다.

동적 연결 라이브러리(DLL, Dynamic Linking Library)를 활용하는 경우
역호출(call back) 구조를 구현하는 경우

이 중 역호출에 대해 다뤄보고자 한다. 지금까지 우리가 사용해 왔던 함수 호출은 주로 직접 호출하는 능동적인 방법이었다. 그런데 이 함수라는 것이 작성자 입장에서 "내가 호출하는 것이 아니라 다른 무엇에 의해 호출" 될 수도 있다. 간단한 예로 아래와 같은 코드를 살펴보자.

#include <stdio.h>

// 함수 포인터를 사용하는 기본 형식
//int (*이름) (char*)
int testFunc(char *pszParam)
{
	return 0;
}

// 매개변수로 함수 포인터와 int형 변수를 받는 함수
void myTest(int(*pfTest)(char*), int nParam)
{

}

int main(void)
{
	myTest(testFunc, 10);
	return 0;
}

정말 단순하게 생각해보면 난 testFunc( ) 함수를 만든 제작자다. 하지만 main함수에서 testFunc( )를 직접 호출하는 것이 아니라 myTest( ) 함수를 통해 간접적으로 호출이 되고 있다. 즉, 다른 무엇에 의해 호출 되는 경우인 것이다.

역호출 구조를 좀 더 제대로 이해하기 위해서는 qsort( ) 함수에 대해 공부하는 게 도움이 된다. qsort( ) 함수에 대해 먼저 살펴보면 아래와 같다.

void qsort(void *base, size_t num, size_t width, int(__cdecl *compare)(const void *, const void *));

인자
base: 정렬 대상 배열의 기준주소
num: 배열 요소의 개수
width: 배열 요소의 바이트 단위 크기
compare: 각 요소를 비교하여 같을 경우 0, 다를 경우 양수 혹은 음수를 반환하는 함수의 주소
반환값: 없음
설명: 퀵 정렬 알고리즘을 이용하여 배열에 담긴 요소를 정리하는 함수이다. 사용자 정의 콜백 함수를 만들어 인수를 전달하는 방법으로 각 항을 비교하는 방법을 구체화 한다.

아래의 예제는 CRL 함수인 qsort( )의 사용 에를 보인 것이다. qsort( ) 함수의 네 번째 매개 변수는 const void* 둘을 매개변수로 받고 int형 자료를 반환하는 함수에 대한 포인터이다. // 퀵 정렬은 평균 정렬 속도가 가장 빠른 것으로 알려진 정렬 알고리즘이다. CRL은 C Runtime Library의 약자이다.

#include <stdio.h>
#include <stdlib.h>

// qsort() 함수가 역호출할 함수의 선언 및 정의
// 각 항을 비교하는 함수
int myCompare(const void *left, const void *right)
{
	// void *로 매개변수를 받으면 사용할 수 없으므로
	// int * 라고 명시해준다.
	return *(int*)left - *(int*)right;
}

// 메인함수가 직접 myCompare를 호출하지 않는다.
int main(void)
{
	int aList[5] = { 20, 50, 10, 30, 40 };

	qsort(aList, 5, sizeof(int), myCmpare);

	for (int i = 0; i < 5; i++)
		printf("%d\t", aList[i]);
	return 0;
}

myCompare 함수의 경우 정렬의 대상이 int형 혹은 double형이 될 수도 있으므로 qsort( ) 함수는 자료형을 구체화하지 않고 일반적 개념 (myCompare(void *, void *))로 정렬을 구현한 것이다. 따라서 일반화된(혹은 추상화된) 개념을 구체화하는 것은 qsort( ) 함수를 사용하려는 사람의 몫이다.

구체화하는 방법은 "각 항을 비교하여 결과를 반환하는 함수"를 만드는 것이다. 그리고 void *에 대해 간접지정연산을 통한 인스턴스화가 불가능하므로, myCompare의 return 문에서 const void *를 int *로 강제 형변환 한 후 간접지정 연산을 수행했다. // void *는 자료형을 해석하지 않겠다는 의미로 해석되기 때문에 반환을 할 수 없다. 반환이라는 건 어떤 값을 어떻게 해석해서 내보내겠다는 의미인데 해석을 안하는 void *를 가지고 반환할 수는 없는 노릇이다.

위의 코드는 메인 함수에서 qsort( ) 함수를 호출하고, qsort( ) 함수가 myCompare( ) 함수를 역호출(call back)하는 구조를 가지고 있다.

위의 예제의 코드만 봐서는 myCompare( ) 함수가 몇 번이나 역호출 되는지는 알 수 없다. myCompare( ) 함수는 qsort( ) 함수가 정렬을 위해 두 항을 비교할 때마다 호출될 것이므로 알고리즘을 정확히 알고 있는 사람이라면 예측할 수도 있을 것이다. 그러나 그런 내용을 전혀 알지 못하면, myCompare( ) 함수는 '언제 그리고 몇 번' 호출되는지 알 수 없다.

역호출(call back) 이란 이름이 붙은 이유도 qsort( ) 함수의 호출자는 main( ) 함수지만 피호출자인 qsort( ) 함수가 다시 myCompare( ) 함수의 호출자가 되기 때문이다.

만약 main( ) 함수의 제작자가 A 라고 한다면 myCompare( ) 함수의 제작자 역시 A라고 할 수도 있다. 그러나 qsort( ) 함수의 제작자가 누군지는 몰라도 그는 A가 아닐 것이라 생각해 볼 수는 있다. B라고 가정한다면, 최초 A가 만든 main( ) 함수가 B가 만든 qsort( ) 함수를 호출한다. 이 때, A는 자신이 만든 함수의 주소를 B에게 전달하고 B는 자신의 코드를 수행하다가 A가 알려준 주소의 함수를 '역으로 호출(call back)' 한다. // 함수 주소를 등록한다는 개념이다. 이 등록을 받은 쪽에서 주소를 아니까 call 을 해준다는 의미다. 등록을 한 대상으로부터 called 된다 라고 생각하면 된다.

위 예제에서는 main( ) 함수가 myCompare( ) 함수를 호출하는 코드가 없다. 그럼에도 myCompare( ) 함수는 분명히 호출된다. 즉, 피호출자 함수에 의해 역으로 호출된다. "내가 호출하는 것이 아니라 자동으로 호출된다" 라는 개념은 앞으로도 대단히 중요하다.

객체지향언어에서도 대단히 중요한데, 문법적으로 함수 포인터가 등장하는 것은 아니지만 함수가 자동으로 호출된다는 가정에 기반을 둔 문법이 존재하고, 이를 명확히 이해하고 제대로 사용하려면 반드시 "자동으로 호출된다"라는 의미를 활용할 수 있어야 한다. // 콜백은 주로 유저(user)모드와 커널(kernel)모드의 개념에서도 쓰인다. 유저가 만든 함수를 커널에 등록하면 OS가 비동기적으로 이 함수를 call back 한다. 언제 부르고 왜 부르고 몇 번 불렀는지는 모른다.

그렇다면 qsort( ) 함수를 왜 callback으로 만들었을까? 정렬하는 대상 자료형이 계속 달라질 수 있기 때문이다. 자료형에 따라 비교를 하는 방법을 다양하고 전부 다 다르다. 따라서 정렬의 대상은 사용자가 직접 정해야 한다. 전체적인 정렬의 방법(인터페이스)은 제공해주고, 직접적인 적용인 비교 logic은 비교하고 싶은 사람이 알아서 규정하게끔 콜백 구조가 만들어지는 것이다. // 인터페이스의 역할을 한다고 생각하면 콜백을 이해하기 한결 쉽다.

# 함수포인터 + (Look up) 배열

이 기법을 사용하면 switch 와 case 문을 완벽하게 대처하면서 고성능으로 코드 제작이 가능하다. 앞서 말한 함수 포인터와 조합해서 사용하면 아래와 같은 기법이 가능하다. // 상당한 고급 테크닉으로 분류된다. 실제로 switch case를 쓰는 것보다 성능이 정말 많이 향상된다.

#include 

void testFunc1(int nParam)
{
	puts("testFunc1");
}
void testFunc2(int nParam)
{
	puts("testFunc2");
}
void testFunc3(int nParam)
{
	puts("testFunc3");
}

int main(void)
{

	void(*pfList[3])(int) = {	// 함수 포인터의 배열이다.
		testFunc1, testFunc2, testFunc3
	};

	// 룩업 테이블처럼 인덱스를 입력 받아서 한다고 생각해보면
	// switch case를 할 필요가 없이 신속하게 함수를
	// 호출할 수 있다. 성능에 큰 도움이 된다.
	int nInput;
	scanf_s("%d", &nInput);

	if(nInput >= 0 && nInput <= 2)
		pfList[nInput](10);
	
	return 0;
}

<함수에 대한 고급 이론> 함수 호출 규칙

wisecow — Fri, 25 Aug 2017 09:57:19 +0900

/* 본 포스팅은 최호성 저자의 '독하게 시작하는 C프로그래밍' 교재를 참조로 작성되었음을 먼저 알려드립니다. */

함수 호출 규칙(calling convention)은 호출자 함수가 피호출자 함수를 호출하는 과정에서 매개변수를 전달하는 순서 및 매개변수가 사용한 메모리 관리방법 등에 관한 규칙이다. 대표적으로 __cdecl, __stdcall, __fastcall 등 세 가지 정도가 있는데 이 세 가지가 C 언어의 표준에서 정의하는 것은 아니다. 모두 약간씩 차이가 있는데 C/C++ 컴파일러의 기본 함수 호출 규칙은 __cdecl이다.

우리가 자동변수를 선언할 때 auto를 생략해도 되는 것처럼 __cdecl도 생략할 수 있다. 따라서 아무것도 기술하지 않으면 함수 호출 규칙은 __cdecl이다. 제대로 표시하자면 함수의 반환 자료형과 이름 사이에 아래와 같은 호출 규칙이 명시되어야 한다.

#include <stdio.h>

int __cdecl main(void)
{
	printf("Hello world!\n");
	return 0;
}

세 함수 호출 규약의 특징을 요약하면 아래의 표와 같다.

호출 규칙	매개변수 스택 정리	매개변수 메모리
__cdecl	Caller	Stack
__stdcall	Callee	Stack
__fastcall	Callee	Stack + Register

# __cdecl

프로젝트의 속성에서 '[구성 속성] -> [C/C++] -> [고급]'의 '호출 규칙' 항목을 보면 기본 설정이 __cdecl로 되어 있다. 따라서 별도로 명시하지 않았을 때 모든 함수 호출 규칙은 __cdecl인 것이다.

__cdecl 호출 규칙은 매개변수를 오른쪽부터 스택에 Push한다. 그리고 매개변수로 인해 증가한 스택을 호출자 함수가 본래 크기로 줄인다. 자동변수는 모두 스택 영역 메모리를 사용한다. 메모리가 자동으로 관리된다는 말은 결국 사용되는 스택의 영역이 늘거나 줄어드는 것에 불과하다.

힙 영역 메모리처럼 운영체제에 반환되는 형태로 관리되는 것이 아니다. 아래 코드의 gMax( )함수는 int형 매개변수 세 개를 받아 그 중 최대값을 반환해주는 함수다. 따라서 매개변수로 인해 증가하는 스택의 크기는 12바이트이다. // 4바이트 int 변수 * 3 = 12바이트

#include <stdio.h>

int __cdecl gMax(int a, int b, int c)
{
	int nMax = a;
	if (b > nMax)
		nMax = b;
	if (c > nMax)
		nMax = c;

	return nMax;
}

int __cdecl main(void)
{
	int nResult = 0;
	nResult = gMax(1, 2, 3);
	return 0;
}

위의 코드를 작성하여 디스어셈블리 화면을 확인하면 아래와 같은 내용을 확인할 수 있는데, 잘 보면 gMax( )함수를 호출하는 부분에서 오른쪽 인수 3부터 스택에 Push하는 것을 확인할 수 있다.

       int nResult = 0;
0003171E  mov         dword ptr [nResult],0 
       nResult = gMax(1, 2, 3);
00031725  push        3 
00031727  push        2 
00031729  push        1 
0003172B  call        _gMax (03126Ch) 
00031730  add         esp,0Ch 
00031733  mov         dword ptr [nResult],eax 
       return 0;
00031736  xor         eax,eax

그리고 call 연산으로 gMax( )함수를 호출한 후 이 함수가 반환하면 main( )함수 내부에서는 add esp, 0Ch라는 연산을 수행한다. 여기서 '0Ch'는 0x0C 즉, 10진수 12를 의미하며, esp(extended stack pointer)는 스택 메모리에 대한 '포인터'이다. 포인터에 대해 ADD 연산을 수행하므로 주소값이 증가한다. // 스택의 주소가 증가하는 건 스택이 감소한다는 걸 뜻한다. 상식적으로 생각할 때 이해가 안될 수 있지만 실제로 스택은 쌓일 때마다 주소가 감소한다. 먼저 한계 선을 긋고 그 안에서 왔다갔다 하는 개념이기 때문에 이렇게 설계가 되었다고 생각하면 된다.

위의 코드에서는 12바이트(4바이트 int형 변수 3개)만큼 증가한다. 주소가 증가했다는 건 스택의 감소를 의미한다. 즉, main( )함수에 들어가는 이 한줄의 코드로 스택은 gMax( )함수호출 전 상태로 복원되는 것이다. 이러한 점 때문에 자동변수 메모리는 자동으로 관리된다는 말을 할 수 있는 것이다.

# __stdcall

__stdcall 호출 규칙 또한 __cdecl 호출 규칙처럼 매개변수를 오른쪽부터 스택에 Push 한다. 그러나 매개변수로 인해 증가한 스택을 호출자 함수가 정리하는 것이 아니라 피호출자 함수가 정리한다. // 피호출자 함수를 어렵게 생각할 것 없이 불려지는 함수라고 생각하면 된다. A called by B 라는 문장이 있다면 A가 피호출자 함수가 된다.

이 역시도 어셈블리를 살펴봄으로써 확인할 수 있는데, 아래의 코드의 어셈블리는 좀 복잡한 관계로 호출자 함수의 어셈블리에서 스택을 정리하는 코드가 사라졌다는 정도만 확인하려 한다.

#include <stdio.h&g;

int __stdcall gMax(int a, int b, int c)
{
	int nMax = a;
	if (b > nMax) nMax = b;
	if (c > nMax) nMax = c;
	return nMax;
}

int __cdecl main(void)
{
	int nResult = 0;
	nResult = gMax(1, 2, 3);
	return 0;
}

main( ) 함수는 __cdecl 호출 규칙을 사용하지만, gMax( ) 함수는 __stdcall 호출 규칙을 사용하도록 명시했다. 따라서 main( )함수가 gMax( )를 호출하면서 증가한 12바이트의 스택 메모리는 피호출자 함수인 gMax( )에 의해 정리될 것이다. 그러므로 앞서 살펴봤던 add esp, 0Ch 는 main( ) 함수의 어셈블리에 존재하지 않을 것이다.

	int nResult = 0;
00F7171E  mov         dword ptr [nResult],0  
	nResult = gMax(1, 2, 3);
00F71725  push        3  
00F71727  push        2  
00F71729  push        1  
00F7172B  call        _gMax@12 (0F71073h)  
00F71730  mov         dword ptr [nResult],eax  
	return 0;
00F71733  xor         eax,eax  
}

gMax( ) 함수를 호출한 이후로 mov dword ptr [nResult], eax 라는 연산이 수행되었는데 이는 gMax( ) 함수가 반환한 값을 nResult에 대입하는 C 코드에 대한 어셈블리 코드다. call 연산과 mov 연산 사이에 스택을 정리하는 코드가 더는 보이지 않는다. gMax( ) 함수 내부에서 스택을 정리하기 때문이다.

# __fastcall

__fastcall은 __stdcall 처럼 매개변수는 오른쪽부터 스택에 Push하고 피호출자 함수가 스택을 정리한다. 단, 매개변수가 여러 개면 가장 나중에 Push 되어야 할 왼쪽 첫 번째, 두 번째 매개변수는 스택 대신 CPU의 레지스터(EDX, ECX)를 이용해 전달한다. 따라서 매개변수가 메모리에 복사되는 횟수를 줄이고, 이 효과로 연산속도가 일부 향상될 수 있다. // 레지스터에 대해선 OS 2일차 게시물을 살펴보도록 하자.

#include 

int __fastcall gMax(int a, int b, int c)
{
	int nMax = a;
	if (b > nMax) nMax = b;
	if (c > nMax) nMax = c;
	return nMax;
}

int __cdecl main(void)
{
	int nResult = 0;
	nResult = gMax(1, 2, 3);
	return 0;
}

	int nResult = 0;
00B6171E  mov         dword ptr [nResult],0  
	nResult = gMax(1, 2, 3);
00B61725  push        3  
00B61727  mov         edx,2  
00B6172C  mov         ecx,1  
00B61731  call        @gMax@12 (0B6134Dh)  
00B61736  mov         dword ptr [nResult],eax  
	return 0;
00B61739  xor         eax,eax  
}

위 예제의 디스어셈블리 (아래 코드)를 보면 왼쪽 첫 번째, 두 번째 인수인 1과 2는 각각 ECX, EDX 레지스터로 전달되고 오른쪽 첫 번째인 3은 스택에 Push 되었다. 그리고 __stdcall과 마찬가지로 호출자 함수에서 스택을 정리하는 코드도 보이지 않는다.

/* C++에는 이 세 가지 외에 '__thiscall'이란 함수 호출 규칙이 하나 더 있다. 이 호출 규칙은 객체의 멤버함수(method)를 호출하는 것에 관련된 호출 규칙이다. 존재한다는 사실만 일단 알아두자. */

/* 또한 우리가 이렇게 일일이 호출 규칙을 정해줄 일은 거의 없다고 봐도 된다. 컴파일러가 알아서 최적화를 시켜주기 때문이다. */

<셸 정렬(shell sort)> 기본 개념 및 알고리즘

wisecow — Thu, 24 Aug 2017 22:54:44 +0900

# 셸 정렬 개념 및 원리

셸 정렬(shell sort)은 Donald L. Shell 이 제안한 방법으로 삽입 정렬이 어느 정도 정렬 되어 있는 배열에 대해서는 대단히 빠르다는 점을 이용해 만든 방법이다. 셸 정렬은 삽입 정렬의 시간 복잡도 $O(n^2)$보다 빠르다.

삽입 정렬의 문제점은 요소들일 삽입될 때, 이웃한 위치로 한 칸씩만 이동한다는 점이다. // 제 블로그에 삽입 정렬로 검색하시면 관련 설명과 알고리즘을 확인해보실 수 있습니다. 삽입 정렬은 for 루프를 이용해 인접한 위치부터 한 칸씩 이동하며 삽입할 위치를 탐색하므로 만약 삽입할 원소가 들어갈 자리가 멀리 떨어져 있다면 한 칸씩 이동하는 설계 때문에 불필요하게 많은 반복과 비교를 해야 한다는 단점이 있습니다.

셸 정렬에서는 요소들이 멀리 떨어진 위치로 이동할 수 있다는 장점이 있다. 이런 것이 가능한 이유는 셸 정렬이 전체의 배열(리스트)을 한 번에 정렬하지 않는다는 점 때문이다. 대신 먼저 정렬해야 할 리스트를 일정한 기준에 따라 분류하여 연속적이지 않은 여러 개의 부분 리스트를 만들고, 각 부분 리스트를 삽입 정렬을 이용하여 정렬한다.

실제로 여러 개의 부분 리스트가 생기고 이것들을 병합하는 것이 아니라, 단순히 gap 값으로 간격을 주어 부분 리스트가 만들어진 것처럼 구현한다. 하나의 단계에서 모든 부분 리스트가 정렬이 되면 셸 정렬은 다시 전체 리스트를 더 적은 개수의 부분 리스트로 만든 후에 알고리즘을 되풀이한다. 이러한 과정은 부분 리스트의 개수가 1이 될 때까지 되풀이된다.

부분 리스트를 구성할 때는 주어진 리스트의 각 $k$번째 요소를 추출하여 만든다. 이 k를 우리는 간격(gap)이라 부른다. 셸 정렬에서는 각 단계별로 gap을 줄여가면서 수행 과정이 반복되므로 하나의 부분 리스트에 속하는 레코드들의 개수는 증가된다. gap이 1이 될 때까지 반복 한다.

# 셸 정렬 예시

예를 들어 원소가 (11, 9, 7, 21, 5, 4, 23, 2, 1, 14, 16)로 구성되어 있는 크기 11의 배열이 있다고 했을 때 셸 정렬 적용하는 과정을 아래의 표와 함께 살펴보자. // 직접 표를 보며 손으로 써 보며 따라가는 것이 좋은 공부법이다.

첫째로 먼저 gap을 설정을 해야하는데 gap은 보통 배열(리스트)의 크기를 2로 나눠 사용한다. gap은 홀수로 다루는 것이 성능에 더 좋은 영향을 끼친다는 연구 결과를 토대로 gap이 짝수라면 1을 더해서 짝수로 만들어준다.

배열의 크기는 11이므로 첫 gap 값은 5로 설정된다. 입력 배열의 각 5 번째 요소를 추출하여 부분 배열(리스트)을 만든다는 생각으로 표를 살펴본다. (10, 3, 16) 으로 구성된 부분 배열1, (8, 22) 로 구성된 부분 배열2, ... , (4, 15) 로 구성된 부분 배열 5 이렇게 총 5개의 부분배열이 추출된다. // 각 인덱스에 5를 더한 인덱스에 해당하는 값들로 구성되어 있음을 알 수 있다.

추출된 부분 배열을 삽입 정렬 알고리즘으로 정렬하면 그 아래에 있는 정렬 후 부분리스트가 등장하게 된다. 그리고 이 정렬 된 부분리스트 들을 합치면 정렬 후 전체배열 항목이 등장한다. 아직 완전히는 아니지만 그래도 어느 정도 정렬이 되었음을 확인할 수 있다.

위에서 언급했다시피 실제로 부분 리스트들을 여러 개 만들어서 하는 것이 아니라 단지 gap 값만 변화시켜 가며 삽입 정렬을 시행하는 것 뿐이다.

셸 정렬의 첫 번째 단계가 끝나면 비슷한 방식으로 다시 부분리스트를 구성하는데 이 때도 기존의 gap 값에 2를 나눈 것을 간격으로 사용한다. 마찬가지로 짝수일 경우 홀수값으로 gap 값을 설정한 후 진행한다. // 1을 더하는 것으로 홀수를 만들어준다. 이렇게 하는 것이 성능에 더 도움이 된다고 한다.

# 셸 정렬의 구현 및 알고리즘

외부 for문은 gap 값을 절반씩 줄이는 기능을 수행하면서 각 부분 리스트에 대하여 일정한 간격으로 떨어져 있는 요소들을 삽입 정렬하는 gap_insertion_sort 를 호출하였다. 만약 gap 값이 짝수라면 1을 더해줌으로써 홀수로 만들어주는 작업도 추가했다. gap_insertion_sort 함수는 기존의 삽입 정렬 알고리즘과 동일하다. 단지 숫자만 몇 개 바뀌었을 뿐이다.

/*************************************************
 ** 셸 정렬과 삽입 정렬 (shell sort & insertion sort)
*************************************************/

int gap_insertion_sort(int list[], int first, int last, int gap);

// 셸 정렬 알고리즘
int shell_sort(int list[], int n)	// n = size
{
	// gap과 내부 반복을 위한 j를 변수로 선언
	int gap, j;

	// 초기 gap 값은 배열의 크기 n을 2로 나눈 값을 사용하며
	// 각 단계 별로 2를 나눠간다.
	for (gap = n/2; gap > 0; gap /= 2)
	{
		// 짝수일 경우 1을 더해주는 것이 성능에 더 도움이 된다.
		if (gap % 2 == 0)
			gap++;

		// j는 각 부분리스트의 시작인덱스 값이다.
		// j가 gap 이전까지만 가는 건 시작 인덱스 값과 gap 값만 알면
		// 배열의 끝까지 갈 수 있기 때문으로 실제 그 과정을
		// 표를 보고 그림을 그려가며 살펴보면 쉽게 알 수 있다.
		for (j = 0; j < gap; j++)
			gap_insertion_sort(list, j, n - 1, gap);
	}
}

// 시작 인덱스 first 부터 시작하는 부분리스트를 구성해 삽입 정렬을 시행한다.
int gap_insertion_sort(int list[], int first, int last, int gap)
{
	int i, j, key;

	// 삽입 정렬에서도 첫 번째 원소는 정렬을 할 필요가 없으므로
	// 그 다음 인덱스 값을 key값으로 설정해줬기 때문에 초기값은
	// first + gap이다.
	for (i = first + gap; i <= last; i += gap)
	{
		// 각 반복별로 인덱스 i값에 gap을 더해줌으로써 부분 리스트 삽입 정렬을 구현
		key = list[i];

		// 키 값 이전의 배열의 값들을 조사하면서 key값이 들어갈 위치를 찾는다.
		for (j = i - gap; j >= first && list[j] > key; j -= gap)
		{
			// 마찬가지로 각 반복별로 1을 감소시키는 것이 아닌 gap을 감소시킴으로써
			// 부분리스트의 삽입 정렬을 구현한다.
			list[j + gap] = list[j];
		}
		list[j + gap] = key;
	}
}
 

/*************************************************
 ** End Line
*************************************************/

# 셸 정렬의 시간 복잡도

삽입 정렬에 비해 셸 정렬은 아래와 같은 장점이 있다.

연속적이지 않은 부분 리스트에서 자료의 교환을 진행하여 더 큰 거리를 이동한다. 기존의 삽입 정렬에서는 한 칸씩 이동하며 비교를 하여 key 값의 자리를 찾았기 때문에 먼 거리를 이동할 경우 그만큼 반복 비교 연산이 많이 일어나는 단점이 있었다.
더 큰 거리를 이동함으로써 교환되는 요소들이 삽입 정렬보다는 최종 위치에 더 가까이 있을 가능성이 더 높아진다. 최종 자리를 더 빨리 찾아감으로써 연산의 횟수를 줄이는 데 기여할 수 있다.
삽입 정렬은 어느 정도 정렬이 된 배열에서 더 빠르게 작동한다는 것을 우리는 알고 있다. 이 점을 토대로 우리는 한 번에 정렬하는 것이 아니라 부분 리스트를 구성해 조금씩 정렬된 상태를 만들어가는 것이므로 삽입 정렬에 비해 속도가 점점 더 빠르게 수행된다.

실험적인 연구를 통하여 증명된 셸 정렬의 시간 복잡도는 대략 최악의 경우에는 $O(n^2)$이지만 평균적인 경우에는 $O(n^{1.5})$로 나타난다.

<페이스북 개발자와의 만남>

wisecow — Mon, 21 Aug 2017 19:47:24 +0900

# 짧은 소감

대학교 친구가 알고 있는 페이스북 개발자분께 대학생들을 위한 세미나 요청을 했는데, 흔쾌히 수락해주셨다며 세미나를 주최했다. 당연 나는 해외 취업 뿐만 아니라 업계현황 등이 궁금했기에 가장 먼저 참여하겠다는 의사를 밝혔다.

그리고 오늘 다니고 있는 대학교에서 열린 페이스북 개발자와 함께하는 세미나에 참여했다. 그 분이 말씀해주신 것들을 토대로 개발자를 꿈꾸는 분들에게 도움이 됐으면 좋겠다는 생각에 이렇게 바로 포스팅을 작성하게 됐다.

# 개발과 관련 있는 혹은 없는 것들에 관한 여러 가지 조언

1. 프로그래밍 언어는 별로 중요하지 않다.

실제 회사 업무에서는 자기가 쓰는 언어가 아니었을지라도 한 달 안에 알아서 숙지해야할 경우가 얼마든지 생길 수 있다. 따라서 언어를 얼마나 많이 아느냐가 아닌 언어를 얼마나 빠르게 습득할 수 있느냐가 더 중요한 덕목이라고 할 수 있다.

따라서 언어의 문법 공부 등에 힘을 쓰기 보다는 실제 개발 혹은 사고력에 도움이 되는 알고리즘 공부 등을 하는 것이 더 도움이 된다고 생각한다.

/* 개발자분의 경우 페이스북에 입사하자마자 한 번도 해보지 않은 파이썬을 다루기 시작했다고 합니다. 언어를 얼마나 많이 아는 것이 아니라 언어의 특징을 얼마나 빨리 캐치하고 사용할 수 있는지, 즉 기본기가 중요하다고 하셨습니다. */

2. 실무적인 경험을 많이 쌓아라.

국내 뿐만 아니라 해외에서도 실무경험은 굉장히 중요하다. 인턴을 가급적이면 꼭 하라고 추천해주고 싶다. 어떤 IT 직종을 가더라도 인턴 경력이 제일 중요하다.

/* 개발자분 본인도 아마존 인턴부터 시작하여 아마존, 마이크로소프트, 지금의 페이스북으로 오게 되었다고 합니다. */'

3. 자격증을 공부할 거라면 AWS Solution Architect 자격증을 알아봐라.

요즘 입사시험의 구성은 코딩 60% + 디자인 40%가 추세라고 한다. 여기서 말하는 디자인이란 'Objected Oriented Design' 즉, 객체지향적 설계를 의미한다. 예를 들면 facebook 메신저를 설계해봐라, 검색포탈의 자동완성기능은 어떻게 설계할래? 가 면접질문인 것이다. 어떤 요소(객체)들이 필요하고 그것들을 어떻게 연결해서 동작하게 할 것인지 등의 구조적인 사고가 필요하다.

AWS Solution Architect 자격증의 경우 객체지향에 대한 개념과 이해도를 높일 수 있다는 측면에서 추천할만 하다. 정보처리기사 보다 이 자격증을 공부하는 걸 더 추천한다. 요즘 제일 핫한 자격증이다.

4. 구글의 개발자가 한국의 개발자보다 더 실력이 뛰어난 것은 결코 아니다.

실제로 구글이나 페이스북에 일하게 된 사람의 대부분은 누군가의 추천으로 면접단계에서 발탁이 된 사례가 많다고 한다. 서류전형부터 시작해서 자신의 포트폴리오로 검증 받고 올라온 사람이 많지 않다는 것이다. 연봉이 1억 5천만원 이라고 해서 한국개발자보다 월등히 뛰어난 것이 결코 아니다. 그저 어쩌다 보니 그런 자리에 가 있는 것이다 라고 생각하면 된다.

즉 구글 같은 기업에는 7살부터 코딩한 사람만 들어갈 수 있겠지? 라는 생각은 하지 않아도 된다. 자신이 원하는 기업에서 꼭 일해보고 싶다면 입사지원서를 넣는 것보다 원하는 회사에 지인을 만들어 추천을 받아 면접단계까지 바로 가는 것이 더 확률이 높다.

5. 개발자로서 안정을 꿈꾸지 마라.

당장 50년 뒤에 네이버나 카카오가 건재할지 생각해봐라. 아무도 예측할 수 없다. 10년 뒤만 잡아도 모른다. 다니고 있는 회사가 하루 사이에 없어질 수 있다. 개발자 자체가 안정적인 직장은 아니기에, 차라리 대박 하나를 노리는 자세가 더 낫다. 개발자로서의 실력을 키우는 건 물론이고 자신만의 길을 개척하는 데도 (창업이든 뭐든) 신경을 쓰는 게 좋다.

6. IT 개발자로서 취업을 생각하고 있다면 개발로 먹고 사는 회사를 가라.

현대 백화점, 현대 홈쇼핑 등 개발이 주가 아닌 곳에서 개발을 하게 되면 어떤 일이 발생할까? 개발자가 대우를 받기 어렵다는 걸 금방 눈치챌 것이다. 배달의 민족, 네이버, 카카오 등 개발이 주가 되고 밥줄이 되는 회사를 가야 개발자가 대우를 받지, 개발 따위 외주로 맡겨버리면 되지 뭐 라는 회사엔 들어가면 제대로 된 대우를 받기 힘들다.

7. 개발자 연봉

보통 실리콘 밸리에서 5년차 개발자들 연봉은 1억 3천만원에서 1억 5천만원 정도 한다. 단순히 액수만 들으면 와~ 하겠지만, 세금이 40%라는 점과 집세 등 물가가 장난 아니게 비싸다는 점 등을 고려하면 실제 수령액은 절반도 안되는 경우가 많다. 물론 그럼에도 많은 거겠지만..

8. 저녁이 있는 삶을 원하기 전에 저녁시간에 뭘 할지를 생각하라

실제 개발자들을 보면 알겠지만, 여기선 여가시간이 있어도 남아서 일을하는 사람들이 있다. 기껏 집에 있어봐야 티비 보고 잠드는 게 고작이기 때문에. 따라서 저녁이 있는 삶을 막연히 바라기 보단 뭐가 하고 싶은지를 생각하는 게 먼저인 것 같다. 마찬가지로 30세 전까지 100억 만들기 등의 목표를 세우는 것보다 100억이 있으면, 돈이 있으면 무엇을 할까를 고민하는 것이 우선이 되야 한다.

9. 마치며

해외 취업을 하고 싶다고 하기 전에 왜 하고 싶은지를 명확히 생각해봐야 한다. 해외에 사는 건 높은 연봉, 좋은 문화 등과 같이 장점만 있는 것이 결코 아니다. 그만한 외로움도 동반되기 때문이다. 따라서 본인이 정말 뭘 원하는지, 어디에 더 가치를 두는지 등을 생각해보고 결정했으면 좋겠다.

<안드로이드 뷰, 뷰 그룹, 레이아웃> 개념 정리

wisecow — Sun, 20 Aug 2017 20:37:21 +0900

/* 본 게시물은 '핵심만 골라 배우는 안드로이드 스튜디오 & 프로그래밍(Android Studio 2 Development Essentials) | 닐 스미스 지음' 의 내용을 토대로 작성되었습니다. */

# 서로 다른 안드로이드를 장치를 위한 디자인

애플리케이션의 사용자 인터페이스는 가능한 한 많은 종류의 화면 크기에서 제대로 보일 수 있도록 신중하게 디자인되어야 한다. 이때 가장 중요한 것은 서로 다른 장치에서 레이아웃의 크기 조정이 올바르게 될 수 있게 하는 것이다.

안드로이드 기반의 스마트폰과 태블릿은 사용자가 세로(portrait)와 가로(landscape) 방향 모두를 사용할 수 있다는 것이다. 따라서 디자인이 잘된 사용자 인터페이스라면 모든 방향에서 그런 변경에 적응할 수 있어야 하고, 사용 가능한 화면 공간을 잘 활용하기 위한 레이아웃을 조정할 수 있어야 한다.

# 뷰와 뷰 그룹

안드로이드 사용자 인터페이스의 모든 요소는 View 클래스(android.view.View)의 서브 클래스다. 안드로이드 SDK에서는 사용자 인터페이스를 구성하는 데 사용할 수 있는 여러 뷰 클래스를 제공한다. // Button, CheckBox, ProgressBar, TextView 클래스 등

그런 뷰들은 위젯(widget) 또는 컴포넌트(component) 라고도 한다. SDK에 제공되지 않는 위젯이 필요할 때는 기존 뷰 클래스의 서브 클래스를 만들거나 또는 View 클래스로부터 상속받는 아예 새로운 컴포넌트를 생성하여 새로운 뷰를 만들 수 있다.

또한 뷰는 여러 개의 다른 뷰로 구성될 수 있으며 복합 뷰(composite view)라고도 한다. 이러한 뷰들은 안드로이드 ViewGroup 클래스(android.view.ViewGroup)로부터 상속받는다. // ViewGroupd 클래스 자신은 View의 서브 클래스다.

예를 들면 RadioGroup이 있다. 이것은 여러 개의 RadioButton 객체들을 포함하여 항상 하나의 버튼만이 선택될 수 있게 한 것이다. 구조적인 관점에서 복합 뷰는 다른 뷰(자식 뷰(child view))들을 포함할 수 있는 하나의 부모 뷰(parent view)로 구성된다. // RadioGroup이 RadioButton 객체들을 포함하듯이.

그리고 그 부모 뷰는 ViewGroup 클래스로부터 상속받으며, 컨테이너 뷰(container view) 또는 루트 요소(root element)라고도 한다. 또 다른 ViewGroup 기반 컨테이너 뷰로 레이아웃 매니저(layout manager)가 있다.

# 안드로이드 레이아웃 매니저

안드로이드 SDK에서는 레이아웃(layout)이라고 하는 뷰들도 제공한다. 레이아웃은 컨테이너 뷰이므로 ViewGroup의 서브 클래스이며, 자식 뷰들은 화면에 위치시키는 방법을 제어하는 목적으로 설계되었다. 안드로이드 SDK에는 아래의 레이아웃 뷰들이 포함되어 있으며, 이것들은 안드로이드 사용자 인터페이스 디자인 내부에서 사용될 수 있다.

LinearLayout - 선택된 방향(수직 또는 수평)에 따라 하나의 행이나 열에 자식 뷰를 배치한다. 각 자식 뷰에는 가중치(weight value)를 설정할 수 있다. 이것은 해당 자식 뷰가 다른 자식 뷰에 비해 얼마나 많은 레이아웃 공간을 차지할 것인지를 결정하는 값이다.
TableLayout - 자식 뷰들을 격자 형태의 행과 열로 배치한다. 하나의 테이블에 있는 각 행은 TableRow 객체로 나타내며, 각 셀의 뷰 객체를 포함한다.
FrameLayout - 일반적으로 하나의 뷰를 보여주기 위해 화면의 영역을 할당하는 것이 FrameLayout의 목적이다. 여러 개의 자식 뷰들이 추가될 때는 기본적으로 레이아웃 영역의 왼쪽 위 모서리를 기준으로 다른 뷰 위에 겹쳐서 나타난다.
따라서 각 자식 뷰들의 위치를 달리하고자 할 때는 각 자식 뷰에 그래비티(gravity) 값을 설정하면 된다. 예를 들어, 어떤 자식 뷰에 center_vertical 그래비티 값을 설정하면 그 자식 뷰는 FrameLayout 뷰 영역의 수직 방향 중앙에 위치하게 된다.
RelativeLayout - 가장 강력하고 유연한 레이아웃 매니저일 것이다. 이 레이아웃은 자식 뷰가 다른 자식 뷰와 자신을 포함하는 레이아웃 뷰 모두에 관련해서 자신에 지정된 마진(margin) 등에 따라 상대적으로 배치될 수 있게 해준다.
예를 들어 자식 뷰 A는 자신을 포함하는 RelativeLayout 뷰의 수직과 수평 중앙에 위치하게 구성할 수 있다. 반면에 자식 뷰 B도 레이아웃 뷰 내부에 수평적으로 중앙에 있지만, 자식 뷰 A의 맨 위보다 30픽셀 높게 위치시킬 수 있다. 자식 뷰 A의 위치와 관련해서 상대적으로 자식 뷰 B의 수직적인 위치를 설정할 수 있기 때문이다.
다양한 화면 크기와 방향에서 동작해야 하는 사용자 인터페이스를 디자인할 때 RelativeLayout 매니저가 사용될 수 있다.
AbsoluteLayout - 자식 뷰가 자신을 포함하는 레이아웃 뷰의 특정 XY 좌표에 위치할 수 있게 해준다. 이 레이아웃은 사용하지 않는 편이 낫다. 화면 크기나 방향의 변화에 대응하는 유연성이 부족하기 때문이다. // 상대적으로 위치를 설정한 것과는 달리 딱 그 좌표에 위치하게끔 하는 기법으로, 레이아웃의 변화에 따라서 알아서 변화하거나 하는 등의 기능은 기대할 수 없다.
GridLayout - GridLayout은 비교적 새로운 레이아웃 매니저로서 안드로이드 4.0의 일부로 소개되었다. GridLayout 인스턴스는 행과 열이 교차되는 셀을 포함하는 격자(grid)를 구성하며, 보이지 않는 라인들로 분할된다. 그다음에 자식 뷰들이 셀에 위치한다.
자식 뷰들은 수평과 수직 모두 여러 개의 셀로 구성될 수 있다. GridLayout의 컴포넌트들 간격은 Space 뷰라는 특별한 타입의 뷰를 인접 셀에 두어서 구현하거나 마진 매개변수를 설정하여 구현할 수 있다.
CoordinatorLayout - 안드로이드 5.0의 안드로이드 디자인 지원 라이브러리의 일부로 소개되었다. CoordinatorLayout은 애플리케이션 화면 위에 있는 앱 바(app bar)의 모습과 기능을 다른 뷰 요소와 함께 사용하기 위해 특별히 설계되었다.
안드로이드 스튜디오에서 새로운 프로젝트를 생성할 때 Basic Activity 템플릿을 선택하면 CoordinatorLayout 인스턴스를 사용해서 레이아웃의 부모 뷰가 구현된다.

안드로이드 애플리케이션의 사용자 인터페이스에서 레이아웃을 사용할 때 주의해야할 점은 레이아웃이 다른 레이아웃 내부에 중첩될 수 있어서 어떤 복잡한 수준의 사용자 인터페이스 디자인도 생성할 수 있다는 점이다.

# 뷰 계층 구조

사용자 인터페이스의 각 뷰는 화면의 직사각형 영역을 나타낸다. 뷰는 그 직사각형 안에 그려지는 것에 대한 책임이 있으며, 화면의 뷰 영역에서 발생하는 이벤트(터치 등)에 응답해야할 책임도 있다.

사용자 인터페이스 화면은 뷰 계층 구조로 구성된다. 그리고 뷰 계층 구조는 계층 구조 트리(tree)의 맨 위에 위치한 루트(root) 뷰와 그 밑의 가지에 위치한 자식 뷰로 되어 있다. 컨테이너 뷰의 자식 뷰는 자신의 부모 뷰 위에 포개져서 화면에 나타나되, 부모 뷰의 화면 영역 경계 안에만으로 그 범위가 제한된다. 아래의 사용자 인터페이스를 살펴보면서 이해를 해보자.

이 사용자 인터페이스에서는 버튼과 체크 상자 뷰가 위치하는 방법을 제어하는 레이아웃 뷰를 포함한다. 아래의 그림은 위와 동일한 사용자 인터페이스를 다른 관점으로 보여준다. 즉, 자식 뷰들과 관련된 레이아웃 뷰들을 나타내고 있다.

사용자 인터페이스 화면은 맨 위에 루트 뷰를 갖는 뷰 계층 구조의 형태로 구성된다. 따라서 위의 그림은 아래와 같이 뷰 트리 형태로도 나타낼 수 있다.

사용자 인터페이스를 구성하는 다양한 뷰들 간의 관계를 가장 분명하게 보여주는 것이 위와 같은 뷰 계층 구조 다이어그램(diagram)이다. 사용자 인터페이스가 화면에 보일 때 안드로이드 런타임은 뷰 계층 구조를 순회한다. 이때 루트 뷰에서 시작해서 트리의 아래로 내려가면서 각 뷰를 나타낸다.

# 요약

안드로이드 애플리케이션의 사용자 인터페이스 화면에 있는 각 요소는 뷰이며, 모든 뷰는 android.view.View 클래스의 서브 클래스다. 각 뷰는 장치 화면의 직사각형 영역을 나타내며, 그 직사각형 안에 나타나는 것에 대한 책임이 있고 또한 뷰의 경계 안에서 발생하는 이벤트(터치 등)를 처리하는 책임도 있다.

여러 뷰를 결합시켜 하나의 복합 뷰(composite view)를 만들 수 있다. 복합 뷰 안에 있는 것들은 컨테이너 뷰(container view)의 자식들이다. 그리고 컨테이너 뷰는 android.view.ViewGroup 클래스의 서브 클래스다. // ViewGroup 자신은 android.view.View의 서브클래스다.

사용자 인터페이스는 뷰 계층 구조의 형태로 생성된 뷰들로 구성된다. 안드로이드 SDK에는 사용자 인터페이스를 만드는 데 사용될 수 있는, 미리 생성된 뷰들이 많이 있다. // 텍스트 필드나 버튼과 같은 기본적인 컴포넌트들, 그리고 자식 뷰들의 위치를 제어하는 데 사용될 수 있는 다양한 종류의 레이아웃 매니저 등

만약 미리 제공되는 것들만으로 부족하다면 커스텀 뷰를 만들 수도 있다. 기존 뷰에서 상속 및 결합시켜 만들거나 android.view.View 클래스로부터 상속받는 완전히 새로운 뷰 클래스를 생성하면 된다.