UA-51329800-1

DDD 제한적 컨텍스트와 마이크로서비스의 크기

지난 6월달에 열린 DDD eXchange의 키노트에서 에릭 에반스가 도메인 주도 설계의 개요를 설명하면서 모델이란 무엇이고 책 출간 이후 기술 변천에 따라 DDD는 어떤 의미가 되었는지 발표했습니다. 모델이 무엇인지 지도를 사용해서 설명하는 데 모델은 현실을 그대로 반영하는 게 아닐 뿐 아니라 완벽할 필요도 없다는 얘기가 인상적입니다.

발표 내내 이벤트 소싱은 여러번 강조했고, 역시나  (요즘 인기있는) 마이크로서비스를 가지고 제한적 컨텍스트(Bounded Context) 약 파는 것도 잊지 않았습니다.

약 한 달 전에 회사 동료와 마이크로서비스와 제한적 컨텍스트를 두고 가볍게 토론을 했습니다. 동료의 팀에서 마이크로서비스 아키텍처로 애플리케이션을 만들었는데 잘 안 풀렸고 나중에 보니 제한적 컨텍스트를 적용하지 않았기 때문이라고 말했습니다. 하지만 저는 이 의견에 동의하지 않았습니다.

Read On…

자바 프로그래머에게 재귀는 왜 어려운가?

저는 컴퓨터 과학 전공자가 아닙니다. 워낙 호기심이 많고 몰입하는 성향이라서 어릴 때 애호가로 프로그래밍을 시작했다가 전공을 버리고 프로그래머로 사회생활을 시작한 사람입니다. 그래서 체계적으로 이론 먼저 배우기 보다는 몸으로 먼저 익히고 나중에 이론을 배우면 정리를 하는 편입니다.

재귀 호출도 저에게는 그와 같은 사례 중 하나 입니다. 어릴 때 이런 저런 프로그래밍 관련 지식을 배우면서 알게 되었고 자연스럽게 익혀서 쓰는 기법입니다. 어떤 문제는 재귀가 아니면 쉽게 푸는 방법을 전혀 모르기도 합니다.

시간이 된다면 이 문제를 하나 풀어 보십시오.

미국에는 1 센트, 5 센트, 10 센트, 25 센트 50 센트 등 다섯가지 동전이 있습니다. 이 동전을 무한정 확보할 수 있다고 하면 이들의 조합으로 어떤 금액도 만들 수 있습니다. 특정 금액 m이 주어졌을 때 이 다섯가지 동전을 조합해서 주어진 금액을 만들 수 있는 경우의 수는 몇가지가 있을까요?

꼭 완벽하기 풀지는 않더라도 몇 분 만이라도 어떻게 풀면 될지 생각해 보십시오.

Read On…

어려운 기술 면접을 변명함

존경하는 최범균님께서 얼마 전에 “면접이 이리 어려워서야“라는 글을 쓰셨습니다. 범균님은 몇몇 회사에서 SW 개발자를 뽑으면서 지나치게 높고 폭넓은 수준의 역량을 요구하는 것 같다면서 그런 사람을 뽑고 싶은 마음은 이해하지만 그런 사람이 세상이 몇이나 되겠냐며 현실에 맞춘 기준이 필요하지 않냐고 제안하십니다.

글을 읽으면서 이 비판(나쁜 의미가 아닌)에 일부 동의하면서도 제가 비판 대상의 일부임을 솔직히 인정하지 않을 수 없었습니다. 그래서 약간의 변명이 필요하다는 생각이 들었습니다. 사실 저는 이렇게 다른 사람의 주장을 논박하면서 토론하는 것을 좋아합니다. 이런 일을 단순히 즐기는 면도 있지만 이런 토론을 통해서 주제가 더욱 풍성하고 명확해진다고 생각하기 때문입니다.

먼저 코딩 시험에 대한 제 개인적인 의견은, 해당 코딩 문제를 풀어야만 통과하는 엄격한 시험이라면 전 낮은 수준의 문제를 내도록 해야 한다는 의견입니다. 높은 역량을 가진 기술자를 뽑기 위한 수단이라기보다는 기준 이하의 기술자를 걸러내기 위한 수단이란 뜻입니다.

Read On…

기술 조직이 사업에 걸림돌이 될 때, 정렬 함정(Alignment Trap)

회사는 재화나 서비스를 고객에게 제공하고 이윤을 내야 할 사명이 있는 조직입니다. 이윤을 내지 못하는 회사는 본연의 사명을 잘 감수하지 못하는 나쁜 회사입니다. 따라서 회사의 모든 구성원은 회사의 이윤을 극대화하고 지속가능하게 하는데 기여해야 하고 모든 에너지를 그곳에 집중시켜야 하는 것은 이론의 여지가 없는 명제입니다.

이는 IT​ 조직도 예외가 아니어서 대부분의 회사는 IT 조직이 사업에 밀착해서 최적화되어 일하도록 강하게 요청합니다. 사업의  목표를 이해함은 물론이고 사업의 요청에 충실해야 하며 비용 효율화를 달성해야 하고 사업과 방향성이 맞지 않는 일은 금기입니다. 심지어 중장기 R&D도 배부른 짓이고 비현실적인 일이라는 비난을 받기 일쑤입니다.

회사에서는 가볍고 빠르게 일을 처리해서 사업에 날개를 달아 주면서도 비용은 적게 먹고 불필요한 일은 하지 않는 IT 조직을 기대합니다. 하지만 대부분의 IT 조직은 무슨 일을 하는지 모르겠지만 생각보다 비용을 많이 먹어서 부담을 가중시키고, 느리고, 늘 문제를 일으키고, 알지 못할 변명만 늘어 놓는, 필요악 같은 존재입니다. IT 투자는 늘 밑 빠진 독에 불 붓기 같고, 실력이 없는 것인지 일 안하고 놀기만 하는 것인지, 의심의 골만 깊어 갑니다.

MIT 슬론 경영 리뷰지 2007 가을호에는 “IT의 사업 정렬 함정을 피하는 법(Avoiding the Alignment Trap in IT)”라는 제목의 논문이 실렸었습니다. 이 논문에서 “정렬 함정(Alignment Trap)”이라는 재미있는 개념을 소개합니다.

Read On…

소프트웨어 개발 전문가, 골드러시, 함수형 언어

스티브 맥코넬은 우리 컴퓨터 업계에는 주기적으로 골드 러시가 일어난다고 했다. 기술 혁신이 계속되고 새로운 기술이 부침을 거듭고 이에 따라 새로운 기회가 열리며 이 기회를 잡으려고 사람들이 우루르 달려드는 일이 반복된다는 것이다.

그러다 보니 새로운 금광이 발견되었다는 소식을 빨리 접하고 남들보다 먼저 깃발을 꼽는 것이 소프트웨어 개발자를 포함한 컴퓨터 관련 종사자의 중요한 생존 전략이 되어 버렸다. 심지어 어떤 (전직) 개발자는 직접 금은 캐지는 않고 금을 찾으려고 혈안이 된 개발자에게 새 금광 소식을 전하거나 금광 채굴단을 모집하거나 청바지를 파는 것을 생업으로 삼기도 한다.

After the gold rush골드 러시가 일어나고 새로운 기회를 찾는 거야 늘 즐거운 일이지만 이런 특성 때문에 무시되는 한가지는 소프트웨어 전문가 의식이다. 오히려 어떤 기술을 남들보다 먼저 사용하거나 더 잘 쓰는 사람을 ‘전문가’라고 부르는 실정이다. 스티브 맥코넬은 이에 대해 “골드 러시 이후, 진정한 소프트웨어 공학 전문직 창조(After the Gold Rush: Creating a True Profession of Software Engineering)”라는 책을 썼는데 아쉽게 번역이 된 것 같지는 않다.

내 머리 속에는 소프트웨어 개발의 전문성이란 주제로 두 사람이 떠오르는데, 이 스티브 맥코넬이 그 한 사람이고 요 몇년 사이에 엉클 밥(로버트 C 마틴)이 추가되었다. 스티브 맥코넬은 소프트웨어 전문가를 소프트웨어 공학자로 보았다. 아직 기예 수준에 머물러 있는 소프트웨어 개발을 공학적으로 접근해서 여러가지 소프트웨어 공학 지식을 활용하는 사람이다.

The clean coder반면에 엉클 밥은 소프트웨어 개발자의 윤리와 책임과 자부심에서 전문성을 찾는다. 이는 오랫동안 소프트웨어 장인 정신으로 부르던 것과 연장선에 있다.

재미있는 것은 이들이 전문성을 강조하던 시점인데, 스티브 맥코넬은 무어의 법칙으로 인한 소프트웨어 위기가 극에 달했던 2000 년 앞뒤로 그런 주장을 했고 엉클 밥은 무어의 법칙이 공식적으로 죽었다는 선고가 떨어진 2000년 후반에 그런 주장을 했다. 즉 공짜 점심은 끝났으니 이제 소프트웨어 개발자는 무임 승차를 끝내고 이제야 말로 진짜로 전문가로서 전문성을 찾아 나서야 한다는 말이다.

엉클 밥이 이 때부터 함수형 언어(특히 리스프 계열, 그중에서도 클로저)에 전착하며 떠들고 다닌 것도 같은 이유인 것으로 보인다. 그에게 새 시대에는 과거와 전혀 다른 방식으로 소프트웨어를 개발해야 하며 함수형 언어가 그 해결책이라고 본 것이다.

난 무어의 법칙 이후 세상에서 함수형 언어(그 중에서도 리스프 계열)만이 답이라고 생각하지는 않는다. 하드웨어 혁명의 시대가 끝나고 소프트웨어 혁명이 시작된 시대에 대응하는 방법은 다양하리라 생각한다. 함수형의 특징 중 몇가지(예를 들어 불변성)를 부분적으로 혼합하는 방식도 가능하다.

좌우간, 요즘 함수형 언어를 떠들고 다니는 사람들 주변에 많고 관심도 많다. 다만 이들이 새 금광 홍보꾼(보도방?)인지 전문가 의식을 찾는 사람인지 한번 확인해 볼 필요가 있다.

자바의 겉표지

해커와 화가의 폴 그레이엄이 2001년 4월에 쓴 “Java’s Cover“라는 글을 번역했습니다. 오해가 있을까 싶어 번역 의도를 말한다면, 저자의 자바에 대한 생각과 상관 없이, 외관으로 특정 기술을 평가하는 능력의 중요성에 대해서 동의할 뿐 아니라 이 글을 썼을 당시보다 새로운 기술이 쏟아져 나오는 속도가 훨씬 빨라졌기 때문에 이런 능력의 중요성이 더욱 커졌기 때문입니다. 15년 정도가 지난 지금 자바가 어떤 길을 걸어 왔는지 정리해 보는 것도 재미있을 것 같아서 그 글을 작성해 보기 전에 이글을 먼저 번역한 측면도 있습니다. 이미 누군가가 번역했을지도 모르겠다는 생각도 들었으나 폴 그레이엄의 글을 탐독하는 사람이 자바 관련된 글을 번역했을리 없다고 단정하고 찾아보지 않았습니다.


이 글은 내가 여러 다른 프로그래머와 자바에서 수상한 냄새가 나는 이유를 나누던 대화를 정리한 글이다. 이 글은 자바에 대한 비평이 아니다. 해커의 탐지 능력(hacker’s radar)에 대한 사례 연구이다.

오랜 시간 동안, 해커는 좋은 (또는 나쁜) 기술을 분별하는 코를 개발한다. 내가 자바를 수상적어 하도록 하는 이유를 찾아서 적어 보면 재미있겠다는 생각이 들었다.

이 글을 읽은 어떤 사람은 전에 작성된 적이 없는 어떤 것을 적어 보는 게 재미 있다고 생각한다. 다른 이들은 내가 이해 못하는 것에 대해서 쓰려는 듯 보여 곤경에 처할 거라고 말한다. 그래서,  만약의 안 좋은 상황을 대비해, 내가 여기에 (내가 한번도 써 본 적이 없는) 자바가 아닌 해커의 탐지 능력에 대해 쓰려는 걸 분명히 하고 싶다.


“겉 표지만 보고는 책에 대해 말할 수 없다”는 격언은 타임스지가 구매자 고유의 취향에 맞추기 위해 보드지로 된 무지 표지의 책을 팔았던 것에서 유래했다. 당시에는 표지를 가지고 책을 논할 수 없었다. 하지만 출판은 그날 이후로 발전했고 오늘날 출판업자들은 표지로 책을 논할 수 있을 정도로 잘 만들려고 힘쓴다.

서점에서 시간을 많이 보내다 보니 이제는 출판업자가 책에 대해서 말하려는 의미를 전부, 어쩌면 조금 더, 이해하는 방법을 익힌 것처럼 느껴진다. 서점에서 죽 때리지 않을 때에는 대부분 컴퓨터 앞에 앉아 있는데, 어느 정도 기술의 표지를 보고도 판단하는 법을 배운 것 같이 느껴진다. 그저 운일 뿐이겠지만, 진짜 저질로 판명난 몇몇 기술에서 날 지켜 주었다.

지금까지는, 자바가 그런 저질로 보인다. 나는 자바로 프로그램을 작성해 보지 않았고 참고 도서도 대충 훑어본 이상은 없지만, 언어로서 그다지 성공할 것 같아 보이지 않았다. 내 실수로 판명이 날지도 모른다. 기술을 전망하는 일은 위험한 사업이다. 아무튼 얼마나 가치 있는지는 모르겠으나, 일종의 타임 캡슐이랄까, 자바가 보기 안 좋았던 이유는 이렇다.

1. 매우 왕성히 과대 선전했다. 진정한 표준은 굳이 홍보할 필요가 없다. 아무도 C나 유닉스(Unix)나 HTML을 홍보하지 않았다. 진정한 표준은 시간이 흐름에 따라 대부분의 사람이 알게 된다고 인정되는 편이다. 매력의 강도로 봤을 때 해커의 탐지 화면에는 펄이 자바 만큼, 오히려 크게 보인다.

2. 목표 수준이 낮다. 첫번째 자바 백서에 의하면, 고슬링은 자바를 C를 사용하던 프로그래머에게 너무 어렵지 않도록 설계했다고 노골적으로 말한다. 자바는 또 다른 C++로 설계된 것이다. C++는 C에 다른 고급 언어에서 몇가지를 아이디어를 취한 언어이다. 시트콤이나 정크 푸드나 패키지 여행을 만드는 사람처럼, 자바를 설계한 사람은 의도적으로 자기들 보다 똑똑하지 않은 사람들을 위한 제품을 설계한 것이다. 역사상, 타인이 사용하도록 만든 언어는 안 좋았다. 코볼(Cobol), PL/1, 파스칼(Pascal), 에이다(Ada), C++ 가 그랬다. 좋은 언어는 창조자 자신을 위해 설계되었다. C, 펄(Perl), 스몰토크(Smalltalk), 리스프(Lisp)이다.

3. 동기가 엉뚱하다. 한번은 누군가 사람들이 책을 쓰고 싶어서가 아니고 뭔가 할 말이 있어서 책을 쓴다면 세상이 더 나은 곳이 될 것이라고 말했다. 이와 같이, 우리가 항상 들은 자바를 만든 이유는 프로그래밍 언어에 대해서 말하고 싶은 무엇 때문이 아니다.  자바가 썬(Sun)이 마이크로소프트의 토대를 약화시키려는 계획의 일부인 것으로 들었다.

4. 아무도 좋아하지 않는다. C, 펄(Perl), 파이썬(Python), 스몰토크(Smalltalk), 리스프(Lisp) 프로그래머는 자신이 사용하는 언어를 사랑한다. 난 한번도 자신이 사용하는 자바를 사랑한다는 말을 듣지 못했다.

5. 사용하도록 강요 받는다. 내가 아는 자바를 쓰는 많은 사람은 그래야 할 것 같아서 자바를 사용한다. 자금을 지원 받으려면 그래야 할 것 같아서나 고객이 원한다고 생각해서나 관리자에게서 뭔가 말을 들었기 때문이다.  그들은 똑똑한 사람이다. 기술이 좋았다면 그들은 자발적으로 그 기술을 사용했을 것이다.

6. 요리사가 지나치게 많다. 최고의 프로그래밍 언어는 지금까지 소그룹이 개발했다. 자바는 위원회가 운영하는 것 같다. 자바가 좋은 언어라고 밝혀진다면, 역사상 처음으로 위원회가 설계한 좋은 언어가 될것이다.

7. 관료적이다. 자바에 관한 내 짧은 지식에 따르면,  뭔가를 할 때의 따라야 할 규범이 매우 많다. 진짜 좋은 언어는 그렇지 않다. 좋은 언어는 하려고 하는 일을 할 수 있도록 하면서도 번잡한 일은 줄여준다.

8. 진보적인 것처럼 위장되었다. 썬은 자바가 펄이나 파이썬처럼 일반 대중의 오픈소스 언어 성과인 척 한다. 이것은 거대 기업에 의해 통제되도록 일어난 일일 뿐이다. 따라서 이 언어는 큰 기업에서 만들어진 모든 것이 그렇듯 밋밋하고 투박할 것이다.

9. 대규모 조직용으로 설계되었다. 큰  조직은 해커와 목적이 다르다.  큰 조직에서는 그저그런 프로그래머로 구성된 큰 팀이 사용하기에 적합한(적으도 그렇기 보이는) 언어를 원한다. 이런 언어는 이삿짐 센터 트럭에 있는 속도 제한기 같이 바보들이 큰 피해를 입힐 행위를 하지 못하게 하는 특징이 있다. 해커는 자신들을 펌하하는 언어를 좋아하지 않는다. 해커는 정말 힘을 원한다. 역사적으로, 큰 조직을 위해 설계된 (PL/I, 에이다 같은) 언어는 망한 반면, (C나 펄 같은) 해커 언어는 흥했다. 현재의 십대 해커는 미래의 CTO이기 때문이다.

10. 엉뚱한 사람이 좋아한다. 내가 인정하는 프로그래머 대부분은 대체로 자바에 끌리지 않는다.  자바를 좋아하는 사람은 누구일까? 정장을 입은 사람이다. 그들이 아는 언어는 다른 사람에게 추천 받은 것은 하나도 없고 언론에서 계속 들은 자바 뿐이다. 큰 회사에 소속된 프로그래머도 있다. 그들은 C++보다 더 좋은 뭔가를 찾느라 혈안이 되어 있다.  단순한 학부생도 그렇다. 그들은 직업을 구할 수 있는 것(면접 시험에 나올 것인가?)이라면 뭐든 좋아할 준비가 되어 있다.  이 사람들은 바람이 불 때마다 생각을 바꾼다.

11. 아버지가 위기에 몰렸다. 썬(Sun)의 사업 모델은 두 전선에서 토대가 허물어지고 있다. 데스크탑 기기에서 사용되는 것과 동일한 유형의 싸구러 인텔 프로세서는 이제 서버에서 쓰기에도 충분히 빠르다. FreeBSD는 적어도 솔라리스(Solaris) 만큼 서버용 OS로 적합해 보인다. 썬은 우리에게 고성능 애플리케이션에 썬의 서버가 필요한 것처럼 광고한다. 이것이 사실이라면, 야후는 썬을 사려고 앞장설 것이다. 하지만 내가 야후에 있었을 때, 서버는 모두 인텔 기기에 FreeBSD가 돌아갔다. 이는 썬의 미래에 좋지 않은 전조이다. 썬이 위기에 처한다면, 자바도 함께 위험해 질 수 있다.

12. 미 국방부가 좋아한다. 국방부는 개발자들에게 자바를 사용하도록 독려한다. 이 사실이 내게는 그 무엇보다 X 같은 신호로 보인다. 국방부는 국가를 방어하는 일은 (돈을 많이 쓰지만) 잘한다. 하지만, 그들은 계획과 절차와 규범을 사랑한다. 그들의 문화는 해커 문화와 반대된다. 소프트웨어에 관한 문제에서 그들은 틀린 답에 손을 드는 편이다. 지난 번에 국방부가 진짜 좋아했던 프로그래밍 언어는 에이다였다.

이 글이 자바를 비평한 글이 아님을 명심하자. 하지만 자바의 표지에 대한 비판이긴 하다. 자바를 좋아하거나 싫어할 만큼 자바를 잘 알지 못하다. 그저 내가 자바를 배우려는데 적극적이지 않은 이유를 설명한 글이다.

프로그램을 작성해 보지도 않고 한 언어를 무시하는 건 거만해 보일 수 있으나, 모든 프로그래머가 해야만 할 일이다. 세상에는 배워야 할 기술이 너무 많다. 밖에서 보이는 신호 만으로 평가하는 방법을 배워야만 시간을 아낄 수 있다. 나는 마찬가지로 여러가지 중에 코볼, 에이다, 비쥬얼 베이직, IBM AS400, VRML, ISO 900, SET 프로토콜, VMS, 노벨 네트웨어, 코바(CORBA)를 호기롭게 무시했었다. 정말 구린내가 났다.

자바의 경우엔 내가 틀릴 수도 있다. 자바는 한 대기업이 경쟁사를 해치려고 촉진했고, 주류 청중을 위해 위원회가 설계했으며,하늘에 닿을 정도로 과장 광고를 하고, 국방부의 사랑을 받았음에도 내가 프로그래밍하고 싶어하는 흠 없고 아름답고, 강력한 언어 일 수도 있다. 그럴 수도 있겠지만 매우 비관적이다.

언어가 해결하려던 것들

폴 그레이엄이 오래 전에 작성했던  What Languages Fix란 글을 번역했습니다. 읽어 보시면 알겠지만 그냥 재미로 읽고 넘길 내용입니다.


 

케빈 켈러허(Kevin Kelleher)가 프로그래밍 언어를 비교하는 재미있는 방법을 제안했다. 각 언어가 해결하려는 문제를 적어 보자는 것이다. 이 방식으로 많은 언어가 정말 잘 설명되는 것을 보고 놀랐다.

알골(Algol): 어셈블리 언어는 너무 하부 수준이야.
Algol: Assembly language is too low-level.

파스칼(Pascal): 알골은 데이터 타입이 부족해.
Pascal: Algol doesn’t have enough data types.

모듈라(Modula): 파스칼은 시스템 프로그래밍에 너무 취약해.
Modula: Pascal is too wimpy for systems programming.

시뮬라(Simula): 알골은 시뮬레이션에 적합하지 않아.
Simula: Algol isn’t good enough at simulations.

스몰톡(Smalltalk): 시뮬라의 모든 것이 객체가 아니야.
Smalltalk: Not everything in Simula is an object.

Read On…

서비스에 인터페이스를 사용해야 하나?

한국 스프링 사용자 모임(KSUG)의 페이스북 그룹에서 스프링으로 웹 애플리케이션을 개발하면서 서비스에 인터페이스를 사용해야 하느냐는 토론이 있었습니다.

원래 그 글의 댓글로 작성한 글인데 무슨 일인지 댓글이 등록되지 않아서 이렇게 블로그에 올립니다.


모든 프로그래밍 원칙과 장치는 ‘적절히 써야 한다’는 대전제 아래에서 논의돼야 한다는 점을 먼저 밝히고 제 생각을 말하고 싶습니다. 프로그래밍 원칙을 위반한다고 지구가 무너지거나 감옥에 갇히지는 않죠. 누가 죽지도 않고요. 그렇다고 해도 어떤 원칙을 위반했을 때에는 원칙의 중요도 만큼 원칙을 무시한 결정이 적절했음을 설득하거나 그로 인해 생기는 문제를 해결할 책임을 위반하기로 결정한 사람(또는 조직)이 수용하고 감당하면 됩니다.

KSUG에서 논의된 내용을 요약하면

  • 인터페이스 없어도 AOP 잘 됨
  • 인터페이스 하나에 서비스 하나 뿐임
  • 인터페이스 때문에 가독성이 떨어짐
  • 테스트를 하면 인터페이스 구현체를  하나 더 만들게 됨
  • 테스트도 요즘 목 프레임워크 기술이 좋아서 인터페이스가 꼭 필요하지 않음
  • 프로젝트 규모와 중요도에 따라 다를 듯
  • 인터페이스를 나중에 추출하는 방법도 있음

저도 인터페이스가 비용인 건 인정합니다. 모든 코드는 비용이죠. 다만, 그 비용을 들인 만큼 얻는 가치가 있다면 투자하면 되고 없다면 투자해서는 안 될 것입니다. 프로그래밍에서 간접화와 추상화와 관련된 코드를 비용으로 따진다면 간접비(overheads)에 해당할 것입니다. 따라서 과도한 간접화나 추상화는 피하도록 노력해야 합니다. 그렇지만 단순히 간접화나 추상화와 관련된 투자가 비용이라서 쓰면 안 된다는 식의 논리는 빈약입니다. 투자회수율(RoI)을 생각해야지 총비용만 무조건 줄이겠다는 생각은 현명하지 않습니다.

같은 맥락에서 @김지헌님이 링크 거신 동영상 강좌(?)에서 문제 삼은 “모든 클래스에는 인터페이스를 만든다”는 과격하고 경직된 정책은 저도 반대입니다. 그러나 저 화자께서 한 쪽의 극단적인 상황을 예로 들면서 그 반발로 또 다른 극단으로 치우치시는 것 같아서 저 강좌의 주장을 그대로 인정하지 못하겠습니다. 저 강좌를 얼마 전에 보고 따로 글을 쓰고 싶었는데 시간이 될지는 모르겠습니다.

OOP의 핵심, 메시징

살짝 한 발 물러서서 객체 지향 프로그래밍(OOP)이 뭔지 생각해 보는 게 좋을 것 같습니다. 최초의 OOP 언어라고 불리우는 두 언어가 있(었)습니다. 하나는 67년도에 나온 시뮬라 67이고 또 하나는 80년도에 나온 스몰토크-80입니다. 우리나라의 많은 사람들이 (아마도 마이크로소프트 덕에) C++를 통해서 OOP를 접했는데, C++는 시뮬라 67에서 OOP의 특성을 물려 받은 언어입니다. 우리가 OOP를 생각하면 흔히 떠오르는 객체, 클래스, 상속 같은 언어적 장치는 모두 시뮬라 67에서 소개되었습니다. 시뮬라 67에서는 프로그램을 작은 여러 독립 프로그램(객체)으로 나누고 이 작은 독립 프로그램들이 병렬적으로 서로 협력하며 동작하도록 하는 프로그래밍 모델을 도입했습니다.

Read On…

왜 자바는 포획된 지역 변수(Captured Local Variable)가 불변(final)이어야 하는 가?

요즘 자바 8의 람다식 때문인지 지역 클래스(Local Class), 무명 클래스(Anonymous Class), 람다식(Lambda Expression)에서 포획된 지역 변수가 final로 명시되거나 “사실상 final(자바 8에서 명시적으로 final 키워드가 붙지는 않았지만 대대입문으로 값을 바꾸지 않아 사실상 값이 바뀌지 않는 변수를 가리키는 용어)”이어야 하는 이유를 두고 온라인이나 오프라인에서 토론하는 일이 많아졌습니다. 저희 팀에서도 지난 주에 이를 가지고 의견을 주고 받았습니다.

이 때 말한 내용을 조금 자세히 정리해 보겠습니다.

내부 클래스 예제

먼저 간단한 예제 코드를 보겠습니다. 좀 쓸모있는 예제를 작성하려 했지만 역시나 그리 유용한 코드는 아닙니다. 예제로 만든 AsyncPrinter 클래스는 비동기로 문자열을 출력합니다.

Read On…