A Restless Engineer

인터넷을 쓰는 현대인이라면 여러 암호를 사용하면서 주기적으로 변경하라는 안내에 시달려 본 적이 있을 것이다. 정말 암호 지옥이라는 말이 떠오를 정도로 여러 개의 암호를 외우고, 한편으론 각 사이트에서 요구하는 '충분히 강력한' 암호를 만들어야 하기에 매번 곤욕을 치른다.

xkcd 암호 생성 알고리즘이란 게 있다. 일반적인 암호 생성기는 되도록 긴 길이, 많은 캐릭터 클래스(영대소문자, 숫자, 기호 등)로 유추가 어렵도록 만드는데, 이렇게 복잡한 암호는 사람이 기억하기에 어려울 것이다. 그래서 암호 관리를 위한 도구를 따로 사용하기도 하는데...1

이 알고리즘은 여러 단어를 조합해서 문장을 만들면 기억하기 쉽다는 점을 이용했다. 덩이짓기(청킹)2이라 불리우는 이 기법은 전화번호를 (222-3333)과 같이 3자리, 4자리로 끊어 외우는 등 실생활에서 많이 찾아볼 수 있다. 이 방법으로는 단어의 조합으로 인해 암호문이 길어지는데, 보안 세계에서는 복잡한 암호보다 긴 암호가 더 낫다고 한다. (참고: 왜 긴 암호가 복잡한 암호보다 유리한가?3)

이 기법을 구현하려면 데이터셋이 필요할 텐데, 다음의 Github 저장소에 여러 가지 데이터가 정리되어 있으니 참고하시길. (아쉽게도 영문 데이터밖에 없다)

https://github.com/danielmiessler/SecLists/tree/master/Passwords

https://1password.com/ ↩︎

https://ko.wikipedia.org/wiki/%EB%8D%A9%EC%9D%B4%EC%A7%93%EA%B8%B0 ↩︎

참조: http://www.programcreek.com/2013/09/string-is-passed-by-reference-in-java/

함수의 호출 방법에는 CBV(Call-by-value)와 CBR(Call-by-reference) 가 있다. (더 자세한 내용은: http://luckyyowu.tistory.com/9)

C계열 언어와 달리 자바에서는 포인터를 명시적으로 사용할 수는 없지만, 연결리스트(링크드 리스트) 구현 등에 있어서는 어쩔 수 없이 포인터를 사용하기도 한다. 예를 들면 다음과 같다.

class Node {   int value;    Node next; }

다음 노드의 포인터가 next 변수에 저장되어 여러 노드를 연결시킨 연결 리스트를 구성할 수 있는 것이다.

난 자바 세계에서는 좀 이상한 말을 들어왔던 것 같다. 바로, 함수 호출 인자에 있어서 기본(primitive type)형을 제외한 모든 객체는 CBR로 취급된다는 말이다. 과연 사실일까?

getName(myName); System.out.println(myName);

private void getName(String myName) {   myName = “Mr.” + myName; }

위 코드는 어떠한가? getName함수 내에서 myName의 값이 바뀌었으므로 2번 째 줄에서는 문자열 앞 부분에 “Mr.”가 붙어있을 것인가? 그렇지 않다. 위 코드 3번 째 줄에서 getName함수의 인자 myName은, 레퍼런스 값이 복사된 지역 변수에 불과하기 때문에 getName의 호출이 끝나는 즉시 소거된다. (정확히는, 가비지컬렉터의 수집/소거 대상이 된다)

결론적으로, 위 getName에서 보듯이, 자바에서의 함수 호출에서 인자의 전달은 모두 CBV라 보는 것이 맞을 것이다. 레퍼런스 값이 넘어가기는 하나 이 값이 지역 변수로 “복사"되는 것이니...

C언어에서는 다음과 같이 인자에 &기호를 붙이면 CBR로 사용이 가능하다. 2번째 줄에서, 1이 증가된 값이 출력될 것이다.

addInt(num); printf(”&d”, num); void addInt(int& n) {   n = n + 1; }

개발자들 중에는 HTTPS/TLS로 암호화된 컨텐츠는 안전하다고 믿는 이가 많을 것이다. 그래서 ID/암호를 평문으로 실어 보내는 사람도 있을 것이고. (과거의 나...;;)

최근 자전거 공격이라는 이름을 붙인 한 페이퍼[1]가 공개되어 궁금증을 참지 못하고 실험해 보았다. 결론적으로 이는 스트림 기반 HTTPS/TLS 암호화의 취약성을 이용하고 있다. 이는 예전부터 보고된 내용[2]으로, 새로운 발견은 아닐테지만 웹어플리케이션에서 어떻게 이용될 수 있는지를 실제로 보여주는 유용한 연구라 말할 수 있다.

스트림 기반 암호화와 블록 기반의 차이는?

먼저 스트림 사이퍼와 블록 사이퍼의 차이점을 알아보자. 스트림은 이름에서 알 수 있듯이 연속적인 비트를 입력받아 대응하는 암호화 비트를 생성하는 방식이다. 함수 f(x)의 형태나, 자판기를 연상하면 쉽게 이해될 것이다. 이에 반해 블록 암호화는 정해진 길이(블록) 단위로 처리한다는 점이 다르다.

<원본 이미지>

<암호화된 이미지>

위 그림을 보면, 암호화가 된 이후에도 대략적인 그림의 형태는 파악할 수 있다. 이를 텍스트라고 가정하면 암호가 유출될 수도 있을 것. 스트림 사이퍼의 특성은 낮은 확산성(Diffusion)을 가진다고 말한다. 하지만 블록 기반의 방식도 블록 길이가 충분히 크지 않다면 일련의 경향성이 드러나는 것을 피할 수는 없을 텐데, 또 이를 해결하기 위한 다른 방법들이 있다고 한다.

원래의 연구 이야기로 돌아가 보면, 널리 사용되는 보편적인 스트림 기반의 방식으로 HTTPS/TLS 통신을 할 경우 각 구성요소의 길이를 따져서 특정 인자의 길이를 유추할 수 있다고. 같은 길이의 컨텐츠에서 항상 같은 갈이로 암호화된 결과가 나온다면 이를 역으로 계산하여 특정 구성 요소의 원래 길이를 찾아낼 수 있지 않을까? 그게 만일 사용자의 암호라면 어떻게 되는 것일까? 소개된 실험은, 이러한 물음에서 시작된 것이었다.

왜 자전거 공격이라 이름 지었나?

위 그림에서 본 것처럼, 암호화를 해 놓아도 모양 판독이 가능하다. 마찬가지로, 자전거는 포장을 해 놓아도 자전거라고 식별할 수 있을테니 이를 빗대어 듣기 좋게 자전거 공격이라 칭한 것이다... 라고 원문 필자가 이야기하고 있다.

어떻게 공격이 이루어지나?

페이퍼에 소개된 내용대로, 가상머신에 워드 프레스를 띄우고, 일련의 로그인 과정을 BurpSuite 도구로 캡처했다. 아래 그림과 같이, HTTP/S 통신 내용을 편리하게 갈무리할 수 있다.

<그림: HTTP/S 통신을 기록하기 위한 프록시 도구 BurpSuite>

많은 이들이 사용하는 Wireshark를 이용하면 아래 그림에서처럼 네트워크 패킷 송수신 상황을 캡처할 수 있는데, 이를 통해 주고 받은 컨텐츠의 순서, 크기 등을 파악할 수 있다.

<그림: 네트워크 패킷 캡처하는 Wireshark>

자, 만일 위 그림과 같이 공격 대상의 패킷 덤프를 확보했다면 로그인 때 ID/암호를 담은 POST 요청이 어떤 것인지 찾아야 한다. 위 그림에서 중간 쯤에 보이는 1212바이트짜리 요청, 바로 저 것인데, BurpSuite에서 확보한 로그인 시의 Request 길이 정보를 가지고 피어슨 상관 계수를 이용, 해당 POST 요청을 찾아낼 수 있다. (각 요청은 암호화할 때 일정한 비율로 크기가 증가한다)

페이퍼에 파이썬 소스가 들어있으니, 데이터 넣고 한번 돌려보면, Access to wp-login.php detected at element 23 in sequence S

이런식으로 해당 POST 요청을 찾아낼 수 있는 것이다. 그 다음부터는 그냥 더하기 빼기해서 암호의 길이를 알아내는 것. 만약 다섯 글자라고 해보자. 

나처럼 그냥 숫자 12345를 암호로 썼으면 위에 보는 바와 같이, 초당 1,000번의 Brute-force 공격으로 2분 내에 뚫린다. 만약 “자주 쓰이는 암호 100,000개" 등의 사전 데이터로 공격하면 더 빨리 뚫릴 것이다. 이처럼, 암호의 길이만 노출된다고 해도 위험한 일이 아닐 수 없다.

얻을 수 있는 교훈

1. 일단 사용하는 암호는 길면 길수록 좋다. 

2. 개발자라면, 암호를 그냥 네트워크로 흘려보내지 말지어다. 패딩값을 주던가 고정길이로 해싱을 해서, 혹은 암호화시켜서 원래 암호의 길이를 알 수 없게 해야 한다.

3. 보안은 목적지가 아닌 여정, 영어로 “Security is a journey, not a destination”라고 하더라. 모든 조직과 사람이 그렇듯이, 보안도 지속적으로 개선해나가야 한다는 말일 것이다.

참고자료

[1] http://blogs.websense.com/security-labs/https-bicycle-attack-obtaining-passwords-tls-encrypted-browser-requests

지난 시간에 이어 다룰 내용은 보안에 대한 부분이다. 흔히 보안은 나중에 여유가 되면,이라고 미루는 경우가 많다지만 아키텍처를 처음 구성할 때부터 이를 염두에 둔다면 나중에 보다 적은 노력으로 작업할 수 있다. 

전에 이야기한 대로, 막 사용자수가 늘어나는 그럭저럭 ‘흥한' 서비스라면 이제 저 멀리 중국이나 여러 다른 국가들에서 해킹 시도도 들어오고 슬슬 입질이 온다. 처음 서비스 오픈할 때야 얼기설기 막 짜여진 코드로 어떻게든 돌아가기만 하면 되었다지만 이제 하나씩 바로잡아야 할 때가 온 것일지 모른다. 쌓여있는 다른 할일도 많은데 하필이면 왜 지금, 이 시점에서 보안을 신경써야 하는지, 또 어떤 사항을 어떻게 체크해야 하는지 짚고 넘어가자.

보안, 왜 필요한가?

데이터 유출의 피해는 생각보다 심각한데, 무엇보다 고객의 서비스 신뢰도를 무너뜨릴 수 있다. 한번 떠나간 고객은 돌아오지 않을 것이다.

회사의 IP(지적재산권 컨텐츠 등)와 각종 개인정보가 유출될 수 있다. 이는 다른 법적이슈를 유발하며 회사에 손해를 줄 것이다.

해킹 피해를 당하고도 그 범위를 추산할 수 없다. 소 잃고 외양간도 고치지 못한다.

갈수록 각종 해킹기법의 도구가 다양해지고 악의적인 공격이 늘어나고 있다. 마우스 클릭 한번에 해킹공격이 가능한 시대라서, 서비스 초기에서부터 기본적인 방어책을 염두에 두는 것이 필요하다.

어떻게 대비해야 할까?

대부분 보안을 가장 나중의 우선 순위로 미루다 보니 막상 때가 닥쳐도 어디에서부터 손을 댈지 막막하다. 다음의 체크리스트로 하나씩 점검해나가자.

서버와 서버간 호출(RPC), 서버와 클라이언트(모바일, 웹브라우저) 등 네트워크 통신은 무조건 암호화하라. 바로 TLS/SSL인데, 현존하는 가장 안전하고도 보편적인 기법이라 할 수 있다. 

사용자 요청(Request)은 기본적으로 한 번 걸러내고(Sanitize/escape) 항상 검증하라(Validate). 자바스크립트 태그, 예약된 문자(예를 들어 홑따옴표)들을 코드 내에서 혼동되지 않도록 전처리하며 입력값의 범위 (숫자면 최소값과 최대치 내의 값만 받음)를 검증하도록 하자.

Safe coding, secure coding으로 일컬어지는 코딩 규범을 익히고 따라야 한다. 예를 들면 에러 로그의 출력 레벨을 조정한다든지, 언어별로, 또 플랫폼 별로 공개된 자료를 찾고 숙지하자.

크로스 사이트 스크립팅, SQL인젝션 등은 항상 시도되는 공격 형태이고 시스템에 상당한 피해를 줄 수 있음을 명심하자.

쿠키, 변수를 사용할 때 조심하자. 민감한 내용이라면 암호화하여 사용하고 사용을 하더라도 끝에서 꼭 지워주어야 한다.

코드 리뷰 등을 통해 문제점을 찾고 공유하며 이를 권장하는 개발 문화를 만들어야 한다. 이를 위해서는 회사 경영진의 노력이 절실하다.

특히, 보안 관련 이벤트(Audit, 감사)를 생성하는 게 중요하다. 해킹을 감지할 수 있게 중요한 단서를 제공하기 때문이다. 

보안 관련 레퍼런스로는 다음 두 가지를 많이 참고한다.

공통취약점목록 (Common Weakness Enumeration, CWE): CWE는 소프트웨어 보안 및 품질 강화를 위해 개발 시에 참고할 수 있도록 전세계 소프트웨어 취약점을 표준화한 목록으로 미국 국토안전부와 미국 국립표준기술연구소(NIST) 산하 비영리 기관인 미트리(MITRE)에서 후원.

공통평가기준 (Common Criteria, 약어 CC)는 컴퓨터 보안을 위한 국제 표준. IT 제품이나 특정 사이트의 정보 시스템에 대해 정보 보안평가 인증을 위한 평가 기준이다.

여기에서는 서비스 초기에 챙겨야할 가장 기본적이면서도 대표적인 것들을 참고삼아 골라보았다.

보안 관련 이벤트 (감사) 생성 코드를 넣고, 언어 레벨, 프레임워크 레벨에서 설정을 점검하자 (CWE-778 Insufficient Logging)

감사에 대한 감사를 생성해야 한다. 무슨 말이냐면 특정 감사정책을 끄거나 켰을때 그 이벤트 또한 기록이 되어야 한다는 것이다. 또, 로깅에 빠진 사항은 없는지 다음의 항목을 체크하자: 생성시점, 이벤트타입, 유저ID, 처리결과(성공인지 실패인지) 등을 기록할것 (FAU_GEN.1.1)

로깅되는 내용에 보안 관련 이슈는 없는가: 유저가 입력한 암호가, 그것도 평문으로 저장된다면? 혹은, ID 입력란에 암호를 잘못 넣었는데 이것이 로그로 저장된다면 문제가 될 수 있다. (FAU_GEN.1.2)

[Java] ThreadLocal을 사용할 때 주의점.

톰캣이나 제티 등의 워커쓰레드 풀을 운용하는 환경에서는, 특정 스레드에 연결된 ThreadLocal 변수들이 제대로 삭제되지 않고 남아있어 메모리 이슈를 유발한다.

예전에 잠시 일했던 스타트업에서 인력교체로 인해 새로 서비스를 구축하며 1백만명까지 회원수가 늘어난 적이 있다. 실제 이용자수는 그보다 훨씬 적은 몇십만명 수준에 동시 접속자수는 피크 타임 시 1만~2만 명 수준이었지만 무엇보다 갑자기 높아진 트래픽으로 인해 분산 처리와 갖가지 예외 상황에 마주쳤던 기억이 있다. 

지금은 대기업에서 일하면서 그보다 더 큰 트래픽도 다루면서 제대로 된 설계와 단계별 접근 전략에 대해 생각한다. 당연히 처음 서비스를 구축할 때부터 백만, 천만명의 트래픽을 걱정할 필요는 없을 것이다. 하지만 그 임계점에 도달했을 때, 전에는 미처 신경쓰지 못했지만 이제는 챙겨야 할 사항들을 하나씩 정리해 볼까 한다.

1. 백업 정책 - 데이터베이스 전체/증분 백업 정책 (테이블 별로 설정해도 좋다) - 클라우드 이미지 백업 (AWS 등) - 콤포넌트 백업 (Docker 등)

2. HA 기반 시스템 구성 보통 서비스에 문제가 생겼을 때 Pingdom 등의 서비스를 통해 오류 상황을 통지받아서 처리하지만, High Availability, 고가용성을 염두에 둔다면 장애없이 계속 서비스를 제공할 수 있다. 이 때 서버를 다중화시키기 위한 방법은 크게 다음의 2가지로 나눌 수 있을 것이다.

- Failover를 위한 Slave 서버 구축 : 데이터베이스는 로그 트랜잭션 기반의 이중화 정도는 반드시 해놓아서 메인DB가 문제가 생겼을 때 언제든지 교체가 가능하도록 준비한다. 일반적으로 cold방식으로 불리우며 퍼포먼스를 위해 비동기식 이중화(Asynchronous)를 걸었을 경우 장애 때 Primary-slave로 takeover되는 순간의 데이터는 유실될 수 있다.  - 여러 Active서버로 구성한 클러스터의 구축 (+프록시서버 혹은 하드웨어 로드밸런서) 위 방식과의 차이는, 여러 서버가 동시에 트래픽을 균일하게 나누어 처리한다는 것이다. 샤딩(shard) 방식을 통해 데이터의 저장 구역을 나눌 수 있다. 예를 들어 회원번호 1~1000번은 1번 서버에, 1001~2000번은 2번 서버에 저장하는 식인데, 저런 순차식이 아니라 해싱(Hash)을 통해 균일하고 랜덤하게 분포할 수도 있다.  이처럼 여러 서버로 분산하기 위해 앞 단에 프록시 서버 혹은 하드웨어 방식의 로드밸런서를 배치하는데, 이 또한 장애를 대비해 여러대를 대기시켜 놓고 takeover되도록 구성한다.

뒤늦게 참석했던 Deview 2015 컨퍼런스에 대한 후기를 남깁니다.

1. 먼저 이번 참가 신청은 경쟁이 매우 치열했던 것 같습니다. 저도 처음 접수했던 것 다 떨어지고 보니 타임라인에 저와 같은 분들이 많았습니다. 그냥 마음을 비우고 있었는데, 정말 감사하게도 한 발표자 분이 초대권을 보내주셔서 갈 수 있었습니다. 참석하고 보니, 역시 많은 걸 배울 수 있는 자리였고 예상 외로 많은 지인과 마주쳤습니다. 명실공히 국내 최고의 개발자 컨퍼런스가 아닌가 싶습니다.

2. 모든 세션을 들어본 것은 아니지만, 꽤 유익한 발표가 많았습니다. 시간이 겹칠 때 어떤 세션을 들을지 감이 안 서면 네이버의 세션에 갔는데, 결과적으로 괜찮은 선택이었던 것 같습니다. 네이버의 실제 서비스 중에 겪는 예외 상황이나 각종 노하우를 들을 수 있어 좋았고, 특히 데이터마이닝 세션에서는 지난 시간에 배운 학교 수업을 복습하는 기분이 들더군요.

기억에 남는 걸 꼽자면, Rust - 언어 자체의 시도는 좋은데 보다 성공적인 레퍼런스가 필요해 보입니다. 이를 이용한 웹브라우저도 만들고는 있다지만 아직 이렇다할 어플리케이션이 없습니다. 스토리지 접근 - 메모리 적재 방식을 다루는 세션이었는데, 유익한 정보 같았지만 바로 쓸 일은 없어 아쉽죠.. 그래도, 디스크에 한 번 쓸지 두 번 쓸지, Flush를 언제 해야할지 그런 설계에 있어서 알아두면 나중에 한 번씩 써먹을 수 있을 것입니다. Presto - 여러 최적화 기법이 녹아있어 Query 엔진 공부할 때 좋아보입니다. Unsafe 패키지야 많이들 이용하지만 바이트코드를 실시간 생성하는 부분에서는 '저렇게까지 해야 하다니'라는 생각도... 실시간 추천엔진을 머신 한대에 구겨넣기 - 기술에 대한 제대로 된 이해를 가지고 '잘' 설계하는 것이 중요하다는 점을 일깨워준 세션입니다. 문제도 좋았고 푸는 과정에서 많은 고민을 했던 것 같습니다. 발표자의 입담과 재치 역시 일품이어서 의사 전달이 쉽고 강력했다는 느낌입니다.

3. 역시, 될 수 있으면 발표자로 참여하는 게 좋은 것 같습니다. 오픈 소스의 경우 제품 홍보도 할 수 있고, 회사나 자기 자신의 홍보가 될 뿐더러 공개된 자리에서 의견 교환도 활발히 할 수 있지요. 예전 대학원생 때도 느꼈지만 컨퍼런스 직후에는 이렇게 한껏 동기부여가 되었다가 며칠만 지나면 쑥 기운이 빠지는 바람에... 주기적인 컨퍼런스 참석이 필요한 듯.

그 외... 요즘 오픈소스를 다루는 직장이 많습니다. 이번 참석한 회사는 TD (Treasure Data)와 엘라스틱 등.. 회사 업무로 오픈소스를 작업하니 개인 경력에도 좋아보이고 Github 등 외부인들과 교류할 수 있는 기회가 많은데, 오픈소스를 다루는 회사에서도 되도록 이런 활동이 활발한 개발자를 영입하려 합니다 (특히 기술 기반 스타트업에서는 개발자가 무형의 자산이기도 하죠). 또, 인사팀 레벨에서는 모르지만 면접보는 프로그래머들은 지원자가 오픈소스 작업했던 걸 보고 싶어합니다.

4. 아쉬운 점.

사람들과 이야기할 수 있는 휴식시간이 따로 없었습니다. 다른 컨퍼런스 등에서는 다과 등을 곳곳에 놓고 네트워킹을 독려하는데, 그런 것들이 없어 좀 아쉬웠습니다.

좋았던 점.

한국에 살 때 밤 12시가 되어도 회사에서 일하는 친구들이 자주 이야기한 불만은, 보여주기식 야근 때문에 몸과 마음이 축난다는 것이었다. 하는 것 없어도 책상머리에 붙어서 뭔가 하는 것 처럼 시늉해야 월급을 받을 수 있다는 현실. 어떻게 보면 이는 밤늦게까지 학교/학원에 앉아서 반강제적으로 공부를 해야 했던 학창 시절의 연장일지 모른다.

특히 개발자, 엔지니어인 나와 같은 직업에 종사하는 친구들은 이런 현실을 못마땅해 했다. 마치 관습처럼 효율성을 추구하는 그들에게는, 어차피 야근할꺼 쉬엄쉬엄 하자며 일하게 되는데 이를 바꾸려 하지 않는 윗선에 불만이 컸을 것이다. 

많은 시간을 근무한다고 해서 많은 성과를 기대할 수 있을까? 다음 기사에서는 노동 생산성에 초점을 맞추고 주요국에서의 자동차 공장 편성 효율을 비교했다. 또, 연평균 근로시간과 노동생산성에 대한 통계자료도 가져왔다.

“[한국경제의 아킬레스건… 노동생산성 높이자] 체코 현대차 공장서 車 1대 만드는데 15시간(대당 투입 시간)… 한국선 27시간”

<구글펌>

파킨슨의 법칙이라는 걸 들어보았는가? 업무에 주어진 시간만큼 일이 늘어난다. 만약 밤 12시까지 일해야 한다고 하면 오후 6시에도 마칠 수 있는 일을 질질 끌면서 일하게 된다는 것이다. 어느 한 외국인이 한국 회사의 고질적인 병폐들에 대해서 기사로 다룬 적이 있었는데, 야근에 대한 내용 또한 들어있었다.

“OECD 국가들 중 가장 낮은 노동 생산성을 기록한 한국, 왜 그랬을까?” - 허핑턴포스트

앞서 소개한 자료들에서 보듯이, 이제는 단순 노동 투입시간을 늘리는 데 그치지 않고 노동 생산성, 즉 효율을 높여야 경쟁력을 가질 수 있다. 첨단 지식산업에 종사하는 화이트 컬러들은 특히 더 그럴텐데, 근로 시간에 따라 결과가 비례하는 단순 노동과 다르게 고부가가치를 창출할 수 있는 것이다. 요즘에는 시험처럼 재택근무를 채택하는 스타트업들도 늘어나고 있고, 몇몇은 좋은 성과도 보이고 있다고 한다.

“재택근무의 치명적인 매력" - 슬로우뉴스

“재택근무 잘 하고 있어요" -스마트 스터디

인터넷으로 전세계가 연결되고 경량의 노트북을 들고 다니며 어디에서든 업무를 수행할 수 있는 요즘 세대의 화이트 컬러들에게 출퇴근과 근무시간은 큰 의미가 없어지고 있다. 이제는 일정 시간동안 해낸 일이 얼만큼인가를 논해야 하며 내가 경험해본 미국 대기업/스타트업은 이미 이러한 인식을 바탕으로 각자의 생산성을 추구하고 있었다. 

미국에서 개발자 면접을 보러 다니면 기본적인 자료구조와 알고리즘은 기본이고 분산 처리나 자신이 사용하는 언어에서의 고급 기능에 대해 질문을 받습니다. 동시성 제어(Concurrent programming)는 그러한 토픽의 단골 주제라고 할 수 있습니다.

자바에서의 예를 들자면, 메소드 선언문에서의 synchronized 키워드와 코드 내 블록의 차이점이라든가, 변수를 가지고 동시성을 제어하는 방법을 들 수 있는데, 여기에서 이야기할 Volatile은 클래스 멤버 변수를 선언할 때의 키워드이며 이는 멤버 메소드에서 사용할 때 메모리 복사본이 아닌 오리지널 포인터를 참조하게 합니다. 

이는 낙관적인 동시성 제어에서 유용하게 사용되는데, 이것이 뭘까요?

데이터베이스에서는 트랜잭션이라는 개념이 있어, 여러 프로시저를 하나의 단계로 묶어서 실행 중간에 오류가 나게 되면 전체 과정을 되돌리는 것이 가능하고, 완료 전까지는 변경 사항이 다른 사용자에게 보여지지 않습니다. 예를 들어 A, B라는 두 변수의 값을 순차적으로 바꾼다고 하면 ‘commit’ 명령이 떨어지기 전까지 A, B의 값은 다른 사용자들에게 이전 값으로 보인다는 것입니다. 이전 값으로 보인다는 표현보다는, 원본 값을 건들지 않는다라는 말이 적절할 듯 하네요. 여기에서 알아야 할 두 가지 개념은 원자성(Atomicity)과 가시성(Visibility)입니다. 원자성은 여러 줄의 코드가 하나의 단계처럼 동작하여 중간에 다른 사용자의 접근을 막을 수 있고 중간에 오류 발생시 변경사항 전체를 되돌릴 수 있습니다. 가시성은 하나의 변수를 변경한다고 했을 때 다른 사용자에게 이것이 제대로 보여지냐에 대한 것입니다. 전역 변수의 예를 들면, 최적화를 위해 각 CPU스레드의 캐시로 이 값이 설정되어 있을 수 있기에 이 개념이 중요한데, 바로 Volatile 키워드가 이를 위한 것입니다.

코드로서 예를 들어볼까요?

class MyClass {

  int n = 0;

  void manipulate() {

    if (n == 0) {

      // some routine

간단한 코드의 일부이지만, manipulate 메소드의 초입부에서 n이 0일 경우를 검사하고 있고 이 n은 여러 스레드에서 접근하고 있죠. 위 그림에서 보시다시피 최적화를 위해서 이 n의 값을 각 cpu스레드로 복사해서 사용하기 때문에 n이 변경된다고 해도 해당 조건문에서 검출하지 못하는 경우가 생깁니다. 바로 이 경우에, Volatile을 사용해주면 각 스레드에서의 복사값을 쓰는 게 아니라 원본을 엑세스하기 때문에 변경 즉시 알아챌 수 있다는 것이죠.

Volatile int n = 0;

하지만 최적화를 방해하기 때문에 이 코드의 경우처럼 가시성을 강제해야 할 때만 사용해야 합니다.

낙관적인 동시성 제어에서는 변수 등을 읽을 때는 동기화를 하지 않고 값을 쓸 때에만 동기화를 통해 값의 변경을 체크하고 원자적으로(Atomic) 처리되게 합니다. 다른 스레드의 Block이 값을 쓰는 경우만 일어나죠. 이 때 읽어들이는 변수값은 유일한 값이 되어야지, 위에서처럼 복사본을 읽는 경우는 없어야 한다는 것입니다.

또 한 가지 생각해야 할 점은, 이 Volatile은 원자성을 보장하지 않습니다. 다음의 코드를 한 번 볼까요?

Volatile int n = 0;

void manipulate() {

  ++n;

3번 째 줄의 n값은 다른 스레드가 읽을 때 항상 1이 증가된 그 값으로 읽힐까요? 이는 알 수 없습니다. 왜냐하면 이 줄에서는 n의 값을 1 증가시키고 n에 다시 할당하는 2개의 operation이 있고, Volatile 키워드를 사용한다고 해서 원자적으로 처리되지 않기 때문입니다.

결국은 이 한 줄이라도, synchronized 블록을 사용해 주어야 원자성을 보장할 수 있습니다.

void manipulate() {

  synchronized (this) {

    ++n;

  }

최근 직장에서 GIT을 도입하면서 이쪽 시스템에 대한 공부를 새로 하고 있다. 새로운 트렌드이고 명확한 장점이 있는 도구이지만 기존 VCS에 비해 개념이 복잡하고 명령어 조합이 쉽지 않다. 이를 위해 SmartGit이나 SourceTree 등의 GUI기반 어플리케이션이 존재하지만 보통 CLI기반으로 배우기 때문에 진입장벽이 좀 있고, 다양한 기능들을 몰라서 쓰지 못하는 경우도 있다고...

일례로, ‘방금한 커밋 어떻게 되돌리나요?’라는 글이 stackoverflow에서 엄청난 투표수를 보여주는데, 많은 이들이 GIT의 어려움에 공감하고 있는 듯 하다.

아직 공부하는 중이지만 Branching 기능을 통해 여러 버전을 관리할 수 있고 속도가 빠르다는 점은 충분히 매력적으로 다가온다. 나와 같이 처음 시작하는 이에게 도움이 될 만한 포스팅을 소개한다:

GIT입문강좌 - http://backlogtool.com/git-guide/kr/

새로운 웹 프로젝트를 기획하면서 어떤 기술스택을 가져갈지에 대한 고민이 있었다. 그리고 그 고민으로 각 잡사이트를 뒤지면서 구인 현황들을 조회해봤다. 물론, 비지니스와의 연계성뿐만 아니라 개발자의 향후 경쟁력 둘다 고려해야 했다. 비지니스에 최적화만 고려할 수 없는 것이 개발자들이 충분히 흥미가 있어야 하고 또 그 기술적인 투자가 헛되지 않아야 개발 시너지가 생기기 때문이다. 노드를 기반으로 한 MEAN 스택..

원문 : http://codedependents.com/2014/01/27/11-best-practices-for-low-latency-systems/

구글은 500ms의 지연이 접속자 수를 20%까지 떨어뜨린다는 것을 발견했고, 아마존은 100ms의 추가 지연이 그들의 매출을 1% 깎는다고 말했습니다. 그 후 개발자들은 밀리세컨드 단위로 지연 시간을 측정하며 자바스크립트와 CSS, HTML을 수정했지요. 물론 트레이드 오프는 항상 있는 것이지만 이론적인 내용을 정리해볼까 합니다.

1. 제대로 된 언어를 선택하라

스크립트 언어는 빠르지만 메모리 모델 등 세부적인 내용까지 만질 수는 없지요. 자바나 스칼라, C++ 11, Go언어 등을 찾아보세요.

2. 메모리에 올려라

I/O는 지연 속도를 늘릴 뿐입니다. 메모리에 데이터를 올리세요. 인메모리 데이터베이스인 Redis나 MongoDB 등이 있겠죠. (하지만 크래시가 발생할 시 데이터를 날릴 수 있다는 것도 염두에 두시고요)

3. 데이터와 코드를 한 곳에

네트워크 교환 속도가 디스크 검색 속도보다 빠르다는 이야기도 있지만 오버헤드는 만만치 않습니다. 여러 대의 서버에서 돌아갈 작업이라면 각 서버에서 독립적으로 수행이 가능하도록 신경써서 파티셔닝 하세요.

4. 서버 자원을 넉넉히 유지할 것

요청을 제 때 처리하려면 서버의 자원이 넉넉해야겠죠. 하드웨어/소프트웨어의 한계까지 운영하지 말고 유사시를 대비해 적당한 여유를 두세요.

5. 컨텍스트 스위칭을 최소한으로

이 말은 즉, 현재 코어 수에 비해 할당할 수 있는 작업량이 더 많다는 이야기겠죠? 적절한 쓰레드 수를 유지하세요.

6. 데이터 검색은 순차적으로 구현할 것

SSD를 쓰든지 어떤 종류의 스토리지를 쓰든지 간에 순차 검색이 엄청나게 효율적임은 분명하죠. CPU캐시나 RAM메모리 내용 등 제대로 순차 검색을 쓴다면 바로바로 처리할 것입니다. 가장 쉬운 방법은 원시 데이터 타입의 배열 구조를 효과적으로 사용하는 것입니다. 포인터로 구현하는 링크드 리스트나 객체의 배열 등은 절대 피해야 합니다.

7. 쓰기 작업은 배치로 묶어라

언뜻 보기에 배치로 쓰기 작업을 처리한다는 것은 직관적이지 않습니다. 일정 시간 동안 쓰기 작업을 미루라는 이야기가 아닙니다. 한 쓰레드가 주기적으로 쓰기 작업을 수행한다는 의미인데, 시스템을 아주 빠르게 만들어 줄 것입니다.

8. 캐시를 써라

여기까지 했으면 이제 메모리 접근조차 병목 지점이 됩니다. CPU 캐시를 위해 쓰레드를 독자적으로 할당하고 순차 검색을 통해 캐시 효율을 높일 수 있었겠죠. 이제는, 원시 데이터 타입을 사용함으로써 메모리 소모량을 줄이고 캐시 효율을 높여야 합니다. 또한 작업을 하기 이전에 cache-oblivious algorithms를 사용할 수도 있습니다.

9. 논 블로킹 방식을 고수할 것

록(Lock)에 자유로운 데이터 구조와 알고리즘을 익히세요. 아니라면 Lock을 추적하기 위해 OS레벨까지 파고들어야 할 텐데 만만치 않은 작업이죠. JVM이나 C++ 11, Go언어의 메모리 모델을 공부해야 할 수도 있어요.

10. 웬만하면 비동기 방식으로

응답을 보낼 때 I/O작업이 꼭 끝나야 하는 게 아니라면 비동기로 처리하세요.

11. 웬만하면 병렬화도

특정 I/O작업이라든지 뭐든지 간에 병렬로 묶을 수 있다면 병렬화하세요. 예를 들어 로그 트랜젝션을 디스크나 다른 서버로 보내야 한다면 병렬로 처리 가능할 것입니다.

12. 그 밖에 다른 자료들

Almost all of this comes from following what LMAX is doing with their Disruptor project. Read up on that and follow anything that Martin Thompson does.

Disruptor Project

The LMAX Architecture

Mechanical Sympathy

Bad Concurrency

Disruptor Blogs

Disruptor Presentations

Additional Blogs

Java is the new C

Psychosomatic, Lobotomy, Saw

Preshing on Programming

Vanilla #Java

나는 이 면접 방식에 명확한 한계가 있다고 생각한다. 문제 풀이에 있어서 정말 기발한 접근방식과 아이디어를 낼 수 있는 사람은 정말 소수에 불과하고 대부분은 그 해결책을 익히는 식으로 면접을 준비하고 있는데, 이를 한 두 시간에 불과한 면접으로는 가려낼 수 없다는 것이 내 생각이다.

실제 개발자 채용이 이루어지는 과정을 그려보면 이러하다:

1) 리크루터가 이력서 내용을 기준으로 면접 대상자를 걸러낸다. 좀 확실히 하고 싶은 지원자는 직접 전화를 해서 확인한다.

2) 팀의 실무진이 번갈아가며 전화 면접을 실시한다. (엔지니어일 수도 있고, 채용 담당자일 수도 있다.) 이 때 클라우드 기반의 문서도구를 열거나 화면공유를 통해 코딩을 시켜보는 것이다. 

3) 지원자는 본인이 아는 문제면 의사코드든 실제코드든 척척 설명해낸다. 면접관은 본인이 생각한 해결책이거나 다른 방식의 해결책이라면 감동을 받고 높은 점수를 준다. 이 후 지원자는 다음 단계로...

4) 온사이트 면접도 크게 다르지는 않지만 실무진들로 면접단을 구성해 몇 번의 라운드를 거친다. 이 후 점수를 종합해 채용 여부를 가린다.

바로 3번에서 맹점이 발생한다. 면접관은 조금 헤매거나 답 언저리까지 푸는 지원자를 자격 미달로 여기고 떨어뜨린다. 이제 이 지원자는 다른 면접에서는 이 문제를 완벽히 풀어내고 천재 개발자로 평가받을 것이다. 면접 경험이 쌓이면 쌓일수록 면접을 더 잘보게 된다. 하지만 이러한 '문제 풀이' 실력이 실무에서 도움이 될지는 의문이다. 실무에서는 커뮤니케이션 능력과 일 처리 방식, 다양한 경험 등 복합적인 요소들이 작용할 것이기 때문이다.

이러한 이유 때문에, 나는 현재의 코딩 인터뷰/프로그래밍 면접이 지원자의 지적 능력을 시험하는 용도에 지나지 않는다고 생각한다. 물론 기술을 다루는 개발자에게 이러한 지적 능력은 필수적인 것이지만, 답을 도출하는 능력을 보는 게 아니라 답을 기억하는 능력을 측정하는 일부 회사의 채용 프로세스는 조금 안타깝다.

구글 검색만 있으면 웬만한 해결책은 금방 찾아낼 수 있는 현재의 상황에서, 조금 더 나은 면접 방식을 구상할 필요가 있을 것이다. (어떤 회사들은 프로그래밍 과제를 내고 그 코드의 품질을 평가하거나 해결 방식을 따지기도 한다.)