예전에 모 대기업 의뢰를 받아 "중급 자바 개발자 실력 검증"을 위해 출제한 문제들입니다.
필기 문제 20문항과 실기 문제 1문항으로 이루어져 있으며,
자바 문법 / 객체지향 이해도 / 자바 프로그램의 동작 원리 이해 등을 묻는 질문으로 구성했습니다.
[MS 워드 형식]
JAVA 필기문제.docx
AddressBook_exam.zip[PDF 형식]
2015. 4. 17. 20:15
JAVA 필기문제.pdf2015. 4. 4. 11:05
"Gregor Hohpe의 횡성수설"이라는 글 모음 중 하나를 번역했습니다. 소프트웨어 설계에 대한 훌륭한 통찰(insight)를 일상생활을 통해 얻을 수 있다는 깨달음을 주는 훌륭한 글입니다. 데이터베이스 관련 기술을 이야기 하고 있지만, 동기/비동기 처리 방식을 왜 구분하고, 어떻게 써야 하는지에 이해하는데 도움이 됩니다.
원문 사이트 : Starbucks Does Not Use Two-Phase Commit
스타벅스는 2단계 커밋을 사용하지 않는다.
Hotto Cocoa o Kudasai (ホットココアください, Hot Cocoa, please, 핫 코코아 주세요.)
방금 2주간의 일본 출장을 마치고 돌아왔습니다. 출장 중에서 접한 익숙한 광경 중 하나는 신주쿠와 록본기 주변의 말도 안될만큼 많은 스타벅스 커피숖들이었습니다. 주문한 "핫 코코아"를 기다리면서 스타벅스가 어떻게 음료 주문을 처리하는지를 가만히 생각해보기로 했습니다. 스타벅스는 대부분의 다른 기업들처럼 주문 처리량을 극대화하는데 매우 큰 관심을 가지고 있습니다. 많은 주문은 많은 수익을 의미하죠. 결과적으로 그들은 비동기 처리 방식(asynchronous processing)을 사용합니다. 당신이 주문을 하면, 점원은 커피 한잔의 주문을 입력하고 대기열(queue)에 추가합니다. 대기열 혹은 큐(queue)는 문자 그대로 에스프레소 기계의 상단에 늘어서 쌓여 있는 빈 커피 컵들을 의미합니다. 이 대기열은 점원과 바리스타를 분리시키고 바리스타(barista)가 잠시 동안 숨을 돌리거나 반대로 매우 바쁜 경우에도 점원이 주문을 계속 받을 수 있도록 해줍니다. 이런 방식은 카페가 바쁜 시간에 다수의 바리스타들을 "경쟁적인 처리자(Competing Consumer)" 시나리오대로 움직이게끔 합니다.
상관 관계 (Correlation)
비동기 일처리 방식의 잇점을 선택함으로써 스타벅스는 비동기 방식이 근본적으로 가지고 있는 문제를 다룰 수 밖에 없게 됩니다. 예를 들자면, 상관관계입니다. 음료 주문은 2가지 이유 때문에 반드시 주문한 순서대로 처리해야 할 필요가 없습니다. 첫째, 바리스타들이 서로 다른 도구를 이용해 음료를 만든다는 점입니다. (드립 커피용 도구와 에스프레소 머신 등등) 또, 혼합 음료(blended drink)는 드립(drip) 커피 보다는 만드는데 시간이 더 걸립니다. 둘째, 바리스타들은 처리 시간을 최적화한 일괄(batch) 작업을 통해 한번에 여러가지 음료들을 만들 수 있습니다. 결과적으로 스타벅스는 상관관계라는 문제를 안고 있는 것입니다. 음료는 주문 순서에 상관없이 만들어지겠지만, 그것을 주문한 고객에게 정확히 전달 되어야 합니다. 스타벅스는 이러한 문제를 메시징 아키텍쳐(messaging architectures)에서 사용하는 상관관계 식별자(Correlation Identifier) 패턴으로 해결하고 있습니다. 대다수의 미국 스타벅스 매장에서는 명확한 상관관계 식별자인 고객의 이름을 컵에 쓰고, 커피가 완성되면 컵에 적힌 고객의 이름을 부릅니다. 다른 나라들에서는 음료의 종류를 이용해 상관 관계를 식별합니다.
예외 처리 (Exception Handling)
비동기 메시지 시나리오(asynchronous messaging scenario)에서 예외 처리는 어려운 문제입니다. 현실 세계에서 예외(문제)를 처리하는 최적의 사례를 살펴보려면 스타벅스가 문제를 해결하는 방식을 관찰해 보면 됩니다. 만일 당신이 마치 지갑을 깜박 잊고 있었다면, 스타벅스의 점원들은 어떻게 대응할까요? 이미 음료를 만들었다면 치워 버릴 것이고, 아직 만들기 전이라면 주문 목록(대기열 혹은 큐)에서 제외할 것입니다. 만일, 당신이 주문한 음료를 마음에 들어하지 않거나 주문하지 않은 음료를 내놓았을 경우에는 음료를 다시 만들어 낼 것입니다. 만일 커피 머신이 고장나서 주문한 커피를 제공할 수 없다면, 환불해 줄 것입니다. 각각의 시나리오는 제각기 다른 상황이지만, 일반적인 오류 처리 전략(error handling strategy)에 대해 설명하고 있습니다.
가격 인하 혹은 취소 (Write-off) - 다양한 오류 처리 전략 중에서 가장 단순한 것입니다 : 아무 것도 하지 않거나, 이미 벌어진 일을 취소하는 것입니다. 썩 좋아 보이지는 않지만 실전 비즈니스에서는 그럭저럭 수용할만한 선택입니다. 손실이 작을 경우, 제대로 일처리하기 위해 오류 정정 시스템을 구축하는 것이 오히려 더 많은 비용을 지출하는 것일 수도 있습니다. 예를 들자면, 제가 컨설팅을 수행했던 여러 ISP(Internet Service Provider)사업자들은 과금(billing) 및 프로비저닝(provisioning) 싸이클(cycle)에서 발생하는 에러를 이런 방식으로 처리했습니다. 결과적으로, 고객은 비용을 청구받지 않고 서비스를 누리게 되는 것입니다. 이런 방식을 도입할지라도 수익 상의 손실은 사업을 유지하는데 있어 지장이 없을 만큼 작았습니다. 주기적으로, "무료(free)" 계정을 찾아 정리하기 위한 "조정 보고서"를 작성하는 작업을 수행하고, "무임승차"한 고객들을 처분합니다.
재시도 (Retry) - ("트랜잭션"이라고 부르는) 큰 작업 그룹을 실행하는 중에 오류가 발생했을 때, 우리는 기본적으로 두 가지를 선택할 수 있습니다. 이미 수행된 작업을 취소하는 것 혹은 실패한 작업들을 재시도하는 것입니다. 재시도가 현실적으로 성공할 가능성이 있다면 그럴싸한 선택입니다. 예를 들어 비즈니스 규칙을 위반한 것이라면, 재시도는 성공할 수 없을 것입니다. 그렇지만, 외부 시스템이 일시적으로 응답하지 않는 상황이라면 재시도는 성공할 가능성이 있습니다.
단, 특별한 경우는 멱등 수신기(Idempotent Receiver : 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 가진 경우)입니다. 이러한 경우는 성공한 수신 처리 이후에 반복되는 메시지는 모두 무시되기 때문에, 간단히 모든 작업을 다시 시도할 수 있습니다.
보상 처리(Compensating Action) - 마지막 옵션은 일관성 있는 상태로 시스템을 돌려놓기 위해 이미 수행된 작업을 취소하는 것입니다. 통화(금융) 시스템을 다루는 경우 이러한 "보상 처리""는 잘 작동하는데, 인출된 돈을 "얼마든지" 재입금할 수 있기 때문입니다.
이러한 전략들은 분리된 준비와 실행 절차에 의해 동작하는 "2단계 커밋(2 phase commit)"과는 다릅니다. 스타벅스의 사례에 접목해보면, "2단계 커밋"은 점원(cashier)이 커피가 완성될 때까지 한 고객만을 바라보며 영수증과 돈을 테이블 위에 올려놓고 기다리는 것과 같습니다. 마지막으로 음료가 준비되면, 영수증과 돈으로 일거에 교환하는 것입니다. 이런 상황에서는 점원뿐만 아니라 고객까지도 "트랜잭션(거래)"이 끝날 때 까지 자리를 떠날 수 없게 됩니다. 이러한 "2단계 커밋" 방식을 적용하게 되면 일정 시간에 서비스 할 수 있는 고객 수는 극적으로 감소할 것이고, 스타벅스의 비즈니스를 확실하게 망하게 만들 것입니다. 이것은 2단계 커밋이 일상을 좀 더 단순하게 만들 수는 있지만, 메시지들의 자유로운 흐름을 방해하게 된다(그리고 확장성을 해친다)는 사실을 일깨워 주는 사례입니다. 왜냐하면, 비동기의 다중 작업 흐름 속에서 트랜잭션의 상태를 관리해야 하기 때문입니다.
대화 (Conversations)
커피숖 상호작용 사례는 간단하면서 일반적으로 대화 패턴(Conversations pattern)입니다.
두 그룹(고객과 커피숖)간의 상호작용은 짧은 동기 상호작용(주문과 지불)들과 하나의 긴 비동기 상호작용 (음료 만들기와 받기)로 구성됩니다. 이러한 대화(혹은 작동방식)는 구매 시나리오에는 매우 일반적인 것입니다. 예를 들어, 아마존(Amazon) 인터넷 쇼핑몰에서 주문할 경우, 주문 번호 발행과 그에 따른 처리 절차(신용카드 지불 요청, 포장, 발송) 등은 짧은 동기적 상호작용이지만, 전체 흐름은 비동기적으로 처리됩니다. 추가적인 단계들이 처리될 때마다 (비동기적으로) 이메일을 통해 통보 받을 수 있습니다. 만일 어떤 것이라도 잘못 처리되는 것이 있다면 아마존은 보상(신용카드 결제를 취소하는 등)하거나, 재처리(분실된 물품을 다시 배송하는 등)를 해줄 것입니다.
요약하면 실제 세계에서 벌어지는 일들은 대게 비동기적으로 동작한다는 것을 알 수 있습니다. 우리의 일상생활은 조화롭지만 비동기적인 상호작용(이메일을 읽고 쓰는 것, 커피를 사는 것 등등)들로 이루어져 있습니다. 이것이 의미하는 바는 비동기적인 메시지 아키텍쳐가 이러한 상호작용을 수행하는데 있어서 가장 자연스러운 방식이라는 것입니다. 또한 우리는 일상적인 생활 속에서 성공적인 메시징 솔루션을 설계할 수 있는 아이디어를 얻게 된 것입니다. 도모 아리가또 고자이마스. (Domo arigato gozaimasu! 감사합니다.)
참고 : 호토 코코아를 검색하면 , 일본 애니메이션 "호토 코코아"가 나오는 군요.
2015. 3. 31. 03:48
Introduction to the Domain Name System
Domain Name System (DNS)는 지속적으로 증가하는 인터넷 사용자를 수용하기 위해 설계되었다. DNS는 www.google.com 같은 명칭을 59.18.44.50 같은 IP 주소로 변환하여 (혹은 보다 확장된 IPv6 주소로 변환), 컴퓨터들이 상호 통신할 수 있게끔 하고, 월드 와이드 웹 같은 인터넷 어플리케이션을 사용할 수 있도록 해준다. DNS 의 역할은 마치 친구에게 전화를 하고자 할 때, 친구의 전화번호를 일일이 외울 필요가 없이 친구의 이름만으로 통화를 할 수 있게 해주는 것과 같다.
▶ DNS는 어떻게 동작하는가?
DNS를 이해하기 위해서 자신의 컴퓨터에 로그인하고 있는 사용자 홍길동을 상상해보자. 홍길동은 웹 브라우저를 실행해 근무하고 있는 회사인 Acme.co의 웹 사이트를 조회할 수 있다. 회사 홈페이지를 조회하기 위해서 웹 브라우저에 http://www.acme.com을 입력할 것이다.
- 홍길동의 컴퓨터는 DNS 서버에 www.acme.com 의 IP 주소를 알려달라는 요청을 전송할 것이다.
- DNS 서버는 www.acme.com 의 IP 주소인 192.168.1.4를 찾기 위해 위해 자체 데이터베이스를 확인할 것이다.
- 서버는 확인한 IP 주소를 홍길동의 브라우저에 반환한다.
- 브라우저는 IP 주소를 이용해 웹 사이트의 위치를 파악한다.
- 브라우저는 홍길동의 컴퓨터 모니터에 웹 사이트를 출력한다.
그림 : 도메인 명칭과 주소 (Domain Names and Addresses)
▶ 도메인 (Domains)
홍길동은 DNS 서버가 www.acme.com의 IP 주소를 주소를 알고 있기 때문에 회사 홈페이지에 접근할 수 있다. DNS 서버는 도메인 네임스페이스(domain namespace)를 검색해 회사 홈페이지 서버의 주소를 알아낸다. DNS 는 각각 이름이 부여된 도메인(domain)이라는 노드(node)로 구성된 트리 구조(tree structure)로 설계되어 있다. 트리의 최상위 노드는 DNS 루트 도메인(DNS root domain)이다. 그 아래에 .com, .edu,, .gov, .mil 같은 하위 도메인(sub domain)들이 존재한다.
그림 : 도메인 명칭 시스템 계층도 (The Domain Name System Hierarchy)
정규화된 도메인 이름(Fully qualified domain name : FQDN) 은 모든 네트워크 도메인 명칭이 루트까지 점(.)으로 연결된 문자열이다. FQDN 은 인터넷에 존재하는 모든 호스트(host)들을 구분하는 고유한 명칭(unique name)이다. 예제 도메인의 FQDN은 sample.com 이며, 부모 도메인은 .com 이고, 루트 도메인은 "." (dot)이다.
▶ Acme.co 회사의 주소 학습
홍길동의 서버가 www.acme.com 의 IP 주소를 요청하는 과정을 좀 더 자세하게 살펴보자.
그림 : DNS 계층도 검색 (DNS Hierarchical Name Search)
- 로컬 DNS 서버는 www.acme.com 도메인이 자체 데이터베이스에 등록되어 있는지를 확인한다. 만일 찾을 수 없다면, 해당 도메인을 관리하고 있지 않다는 것을 알게 된다.
- 로컬 DNS 서버는 루트 네임서버(root nameserver)에 최상위 레벨의 도메인 "."(dot)에 대한 정보를 요청한다.
- 루트 네임서버는 .com 도메인 및 하위 도메인을 관리하는 .com 네임서버에 요청하도록 지시한다.
- .com 네임서버는 acme.com이 자신의 하위 도메인임을 확인하고, acme.com 도메인을 관리하는 네임서버의 위치를 알려준다.
- 로컬 서버는 acme.com 네임서버에 www.acme.com 서버의 위치를 요청한다.
- acme.com 네임서버가 IP 주소 192.168.1.4를 알려준다.
- 로컬 서버는 최종적으로 검색한 IP 주소를 홍길동의 웹 브라우저에 반환한다.
▶ 도메인 등록 (Establishing a Domain)
Acme.co 는 홍길동이 접속할 수 있는 웹사이트를 운영하고 있는데, 이는 해당 도메인이 공인된 도메인 관리 회사(업체)에 등록되어 있기 때문이다. 또한 .com 서버의 데이터베이스에 도메인 명칭을 등록하고, IP 주소 범위를 규정하는 네트워크 번호(network number)를 요청했다. acme.com이 부여받은 네트워크 번호는 192.168.1.0이며, 이는 192.168.1.1 부터 192.168.1.255 까지를 포함한다. IP 주소는 옥텟(octet) 이라고 부르는 4개의 숫자로 구성되어 있고 각 숫자(번호)는 0부터 256까지 사용할 수 있다. 그러나, 0과 256는 브로드캐스트(broadcast) 및 네트워크 자체를 위해 예약되어 있으므로 호스트의 주소를 지정하는데 사용할 수 없다.
▶ 도메인과 존(zone)의 차이
도메인 네임스페이스는 DNS 트리의 특정(일부) 영역을 나타내는 존(zone)으로 구분되어 있다. 존은 특정 지점의 하위에 존재하는 모든 도메인을 포함한다.
각 존은 일반적으로 해당 존을 관할하는 하나 이상의 네임서버를 가지고 있다. 각 기관(혹은 기업)은 복수의 네임서버를 소유(및 운영)할 수 있지만 인터넷 클라이언트들을 루트 네임서버가 알고 있는 (혹은 루트 네임서버)에 등록된 네임서버에만 주소 검색을 요청할 수 있다. 루트 네임서버에 등록되지 않은 서버들은 각 기관의 내부에서 자체적인 용도로 사용된다.
Acme.co 회사는 acme.com 이라는 도메인을 등록했다. 또한 acme.com, marketing.acme.com 및 finance.acme.com이라는 3개의 존을 구성했다. Acme.co 는 마케팅 및 재무 부서에 marketing.acme.com 및 finance.acme.com DNS 서버에 대한 관리 권한을 위임하였다. acme.com에 속한 누군가가 marketing.acme.com 내에 존재하는 호스트의 주소를 요청하면, acme.com은 주소 요청을 marketing.acme.com으로 유도할 것이다. Figure 13-4 acme.com은 3개의 존으로 구성되어 있으며, acme.com 존은 자체에 대한 관리만을 수행한다.
그림 : Acme.com With Delegated Subdomains
Acme.co 는 하위 도메인(subdomain)들에 대한 관리 권한을 위임하지 않을 수도 있다. 이런 경우, acme.com 도메인은 marketing 및 finance 을 관리하는 존이 된다. acme.com 서버는 마케팅 및 재무 영역에 대한 주소 요청에 대해서도 응답한다.
그림 : Acme.com Without Delegation
존을 설정할 경우, 각 존에 네임서버를 필히 설정해야 한다. 각 존 마다 로컬 설정 데이터베이스를 가지고 있는 하나의 기본 네임서버(primary server)가 있어야 한다. 각 존은 기본 네임서버로부터 복사한 데이터를 가지고 있는 여러 개의 보조(secondary) 서버를 가질 수 있다. 다음 그림은 하나의 보조 서버를 구성한 사례이다.
그림 : Primary and Secondary Servers for Zones
▶ 네임서버
DNS는 클라이언트/서버 모델을 기초로 만들어졌다. 네임서버는 DNS 데이터베이스를 저장하고 있으며, 네트워크를 통해 IP 주소를 요청하는 클라이언트에 해당 정보를 제공한다. 네임서버는 물리적 서버에서 실행되는 프로그램이며, 존 데이터(zone data)를 저장한다. 도메인의 관리자는 하나 이상의 존에 위치한 호스트들에 대한 정보를 표현하는 Resource Records (RR) 데이터베이스를 네임서버에 구성(입력)한다.
그림 : Client/Server Name Resolution
DNS 서버는 호스트 명칭을 주소로 변환하는 기능 혹은 명칭 식별 기능을 제공하며, 정규화된 도메인 명칭(FQDN)을 이용해 주소를 변환한다. 만일 로컬 네임서버가 변환을 요청 받은 명칭에 대한 데이터를 가지고 있지 않을 경우, 찾을 수 있을 때까지 다른 네임서버에 질의한다. 일반적으로 IP 주소 변환은 네임서버가 도메인 네임스페이스에 대한 질의 내역을 캐시(cache)에 담아두고 있기 때문에 매우 빠르게 수행된다.
각각의 존은 필수적으로 기본 네임서버가 존 내의 호스트들에 대한 정보를 담고 있는 데이터베이스를 가지고 있으며, 복수의 보조 서버들은 기본 서버 데이터의 복사본을 저장하고 있다. 기본 서버의 정보를 이용해 보조 서버의 데이터를 최신 상태로 업데이트하는 작업을 존 전송(zone transfer)라고 한다.
그림 : DNS Zone Transfer
보조 네임서버가 기본 서버의 백업 역할을 수행할지라도, 두 가지 서버 모두 존에 대한 관리를 할 수 있다. 두 서버 모두 주소 변환 요청을 수행하면서 얻는 정보(RR) 뿐만 아니라, 존 데이터베이스의 호스트 정보를 활용한다. 클라이언트는 두 가지 종류의 서버에 모두 주소 변환을 요청할 수 있다.
네크워크 관리 기관(업체, Network Registrar)의 DNS 네임서버에 자체 네임서버를 등록할 때, 존의 기본 서버, 보조, 혹은 캐시 기능만을 수행할 지 지정할 수 있다. 각 네임서버의 유형은 어떤 역할을 지정하느냐로 구분된다. 하나의 서버가 어떤 존의 기본 서버이면서 다른 존의 보조 서버가 될 수 있다. 기본 혹은 보조 서버의 역할만을 수행하거나, 존에 대한 관리 서버가 아니라 캐시(cache)를 이용해 주소 변환만을 수행하는 기능을 수행할 수도 있다.
▶ 참조 문서
