Archive for the ‘Uncategorized’ Category

예산 위원회 회원들에게 – E. W. 데이크스트라

이 글은 에츠허르 W. 데이크스트라가 1999년에 16년간 가르치던 오스틴 텍사스 대학에서 은퇴하고 2년 후 대학에서 프로그래밍 입문 과정에 자바를 가르치기로 했다는 소식을 듣고 대학에 보낸 편지(원문)입니다. 데이크스트라는 이 편지를 보낸 다음 해에 암으로 사망합니다.


예산 위원회 회원들에게

학부 프로그래밍 입문 교과의 함수형 언어 하스켈을 명령형 언어인 자바로 바꾸려고 한다는 소문 때문에, 그리고 예산 위원회가 잘못된 수준에서 이 결정이 내려지지 않도록 책임져야 한다고 생각해서 이 글을 씁니다.

여러분도 알다시피 이는 사소한 일이 아닙니다. 외지에서 온 동료들은, 엄격한 보수주의에서는 똑같이 평범해 질 것이 강요될 것이라고 가정하고서는, 내가 텍사스 오스틴 같은 곳에서 어떻게 버틸 수 있는지 궁금합니다. 이에 대해 나는 “걱정 마세요. 우리 컴퓨터 과학 학과는 매우 계몽된 곳입니다. 예를 들어, 프로그래밍 입문에 우리는 신입생들에게 하스켈을 가르칩니다”라는 식으로 답하곤 했습니다. 이 대답에 그들은 처음에는 거의 믿지 못하겠다는 반응을 하다가 결국엔 부러워합니다. 대게 그들의 학부 교과가 파스칼에서 C++나 자바 같은 것으로 전환하는 수준을 넘어서지 못하기 때문입니다.

Read On…

(번역) 기술자의 히포크라테스 선서

저는 소프트웨어가 점차 사회의 핵심 요소로 사용되는 만큼 소프트웨어 개발자도 중요한 역할을 맡게 되었으니 전문가 의식을 가지고 그 역할에 맞는 행동을 해야 한다고 생각합니다.

대부분 개발자도 회사에 고용이 되어 일을 합니다. 하지만, 일반 노동자의 경우 고용자가 생산 수단을 제공하고 노동자는 단지 이 생산 수단을 운영하는데 필요한 노동력을 제공하는 것이 주인 것과 달리 소프트웨어 개발자(그리고 다른 지식 노동자)는 자신이 가진 지식과 지능으로 제품을 만들기 때문에 그 지위도 고용인과 대등한 관계에 있다고 볼 수 있습니다. 저는 이런 상황을 “소프트웨어 개발자는 생산 시설을 들고 일터에 걸어들어가고 퇴근할 때 들고 나오는 노동자”라고 말하곤 합니다.

작년에 우연히 마리사 데일(Mariesa Dale)이란 분의 기술자 히포크라테스 선서라는 글을 읽었습니다. 내용을 읽고 너무나 감동했고, 오랫동안 견지하던 제 뜻과 일치하여 이 선서에 동참하기로 했습니다.

동료들에게도 소개하고 싶어서 번역하려 했으나 계속 미루기만 하다가 최근에 조금씩 번역해서 이렇게 공개합니다. 오역이나 어색한 부분은 알려주시면 수정하겠습니다.

Read On…

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

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

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

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

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년 후반에 그런 주장을 했다. 즉 공짜 점심은 끝났으니 이제 소프트웨어 개발자는 무임 승차를 끝내고 이제야 말로 진짜로 전문가로서 전문성을 찾아 나서야 한다는 말이다.

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

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

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

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

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

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


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

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

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

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

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

OOP의 핵심, 메시징

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

Read On…