Rath World » 2010 » January

Archive

Archive for January, 2010

OOP에 대한 단상들

January 29th, 2010 7 comments

우연히 박영록이 쓴 안드로이드를 하면서 다시 생각해본 OOP를 읽고 OOP에 대한 단상들을 뱉어내기로 했다. 영록이가 쓴 글의 문맥과는 거리가 멀다는 점을 염두해두시라.

나는 OOP를 상당히 좋아한다. 그저 객체 지향- 을 좋아하는 것이다. 다른 동물들에 비해 뛰어난 인간의 능력인, 추상화 능력을 제대로 발휘할 수 있는 좋은 프로그래밍 기법이기 때문이다.

인터페이스가 어쩌고 static을 쓰지 마네 뭐네 그런 규칙들은 관심없다. 내 머리속에서 생기는 추상적인 생각들을 적은 노력으로 코드로 표현하여 완성할 수 있기만 하면 된다. 프로젝트 코드 중 OOP 개념에 반하는 녀석이 생기는 것도 전혀 상관없다. 내 생각을 코드로 옮기는 게 중요하다. OOP는 내게 이러한 작업을 하는데 방해를 거의 주지 않으므로 선호하는 것이다. 내가 OOP를 써야지 OOP가 나를 쓰게 하면 안된다. 막 되는대로 코딩을 해놓고 개선할 생각없이 구현에만 급급해하면 적응력 뛰어난 당신의 두뇌가 당신의 생각을 코드에 따라 흘러가도록 재조정할 것이다. 맘에 안들면 외계인으로 다시 태어나라.

요즘 마켓을 잠식하고 있는 프로그래밍 언어들은 (공부만 충분히 하면) 인간의 추상적인 생각을 제대로 사상하기 위한 기반을 만드는 데 별 문제가 없다고 생각한다. 하나의 프로그래머로써 기쁜 일이 아닐 수 없다.  OOP로 모든 문제를 해결하려고 하면 반드시 한계가 드러나지만 그런거야 완벽주의자들이나 논할 문제니 넘어간다. 그런데 적지 않은 사람들이 자기 생각을 코드로 바로 표현하는 것을 포기하고, 프로그래밍은 원래 어려운 것이라 되뇌이며 어렵게 짜는 것을 어렵지 않게 목격할 수 있다. 슬픈 일이 아닐 수 없다. 이런 분들에게는 이런 말을 하고 싶다. “저기요, 세상 많이 좋아졌거든요? 공부 좀 하시지…” 생각대로 코딩을 할 수 없는 프레임워크가 있다면 그 프레임워크가 나쁜 놈이다. 부적격자는 당신이 아니다.

하지만 운영체제와 프로그래밍 언어와 프레임워크만 후둘겨 깐다고 답이 나오겠는가. 그것들도 한낱 인간들이 만든 것이다. 그러니 프레임워크 수준의 프로그램을 만들고자 하는 사람은 책을 많이 읽고, 국어 공부를 열심히 하든지, 이성친구를 많이 사귀어서 생각의 범위를 확장하든지, 어쨌든 생각의 범위와 질을 높이는데에 더 많은 시간을 투자해야 한다. 똑같은 생각으로 프로그램 많이 짜봐야 실력은 늘어나지 않는다. 몸이 축나고 경제적 이익을 취할 수 있을 뿐.

그래도 프로그래밍은 어려운데, 추상화 능력이 아무리 뛰어나도 제품 출시직전에는 추상화했던 모든 것들의 깊숙한 곳까지 다 책임지고 만들어야하기 때문이다. 여기서부터는 OOP로 해결할 것이 아니라 비인간적인 고급 엔지니어로 해결을 봐야한다. 추상화 레벨이 높아지면 기계 친화적이지 못한 문맥이 생겨 고급 엔지니어가 필요해지고, 추상화 레벨이 낮아지면 인간 친화적이지 않은 문맥이 생기게 되어 관리가 안되고 생산성이 떨어진다.  나라면 추상화 레벨을 높이고 고급 엔지니어를 쓰는 방법을 택하겠다.

잡생각 끝.

Categories: Development, productivity Tags:

Context 크기 줄이기

January 28th, 2010 4 comments

당연하게도, 유지해야할 문맥의 크기가 작으면 작을수록 우리는 더욱 유연해질 수 있다.

지금 그대의 편집기에 열려져 있는 파일의 개수가 몇개인지 확인해보라. 4개가 넘어가는가? 너무 많다. 2~3개 정도로 유지할 것을 추천한다.

한번에 한 Task만 처리할 수 있게 최소한의 파일만 열어놓도록 하자. 그렇지 않으면 이것도 해야하고 저것도 해야하고.. 자꾸 새로운 시각정보들이 여러분의 뇌에게 잦은 cs를 발생시켜 업무 효율이 떨어질 것이다. 하나의 Task가 끝났으면 Cmd-Shift-W로 열린 모든 파일을 닫아버리자.

요즘 컴퓨터는 무척 뛰어나서 초당 cs가 4,000번씩 발생하더라도 서버 로드가 0.3이 채 안된다. 그러나 당신의 뇌는 기껏해야 초당 100회도 견뎌내지 못한다 (근거는 없습니다. 죄송 -_-). 유지해야할 문맥을 최소한으로 줄이는 것이 상책이다.

사람이 컴퓨터보다 뛰어난 능력이 있다면 추상화 능력이다. 프로세싱 능력이 떨어지는 대신 최소한의 정보만을 가지고 어떤 의미를 도출하는 추상화 능력 말이다. 인간이 잘못된 추상화 과정을 많이 저지르긴 하지만 (편견, 오해 등등) 누구나 특정 수준 이상의 추상화 능력을 발휘하며 살아간다. 아마 인간의 프로세싱 속도가 떨어지는 것을 커버하기 위해 설계된 부분이 아닐까!

내가 생각하기에 인간이 돌리는 thread stack size는 별로 깊지 않은 듯 하다.

한동안 문맥변환 비용을 어떻게 줄여야 하나.. 고민에 고민을 거듭했던 적이 있다. 오랫동안 고민했음에도 불구하고 딱히 만족스런 결과를 얻지 못했다. 왜냐하면 문맥변환에는 빌어먹을 ‘의지력‘이 필요하므로 자동화할 수 없고 결국 예측할 수도 없기 때문이다. 결국 유지해야하는 Context를 줄였다.

머리속에 유지해야하는 Context를 줄일 수 없다면?

데이터의 값을 저장하지 말고, 레퍼런스만 저장하면 된다. 그렇다고 레퍼런스 변수들을 문맥 클래스에 줄줄 선언해놓으면 문맥을 들여다 볼때마다 변수명이 보여서 그대의 정신을 마비시킬지도 모른다. 그러니,  적절히 Set이나 Map에 넣어놓도록 하자. 요즘 세상은 인덱싱 능력이 뛰어난 툴들이 너무나도 많다. 단, 도구들을 사용하기로 결심했다면 완전히 신뢰하도록 하자. 신뢰하지 않으면 peek/check 비용이 높아져서 결국 생산성이 떨어지기 때문이다.

끝.

Categories: Development, Life, productivity Tags:

프로그래머로 돌아왔다

January 26th, 2010 4 comments

2009년 8월, 프로그래머로 살던 나는 어디로 갔을까라는 포스트를 올린 적이 있다.

그리고 5개월이 지난 지금, 나는 온전히 프로그래머로 살고 있다. 프로그래밍을 해야한다고 생각하지도 않고, 좀 더 나은 프로그래머가 되고자 하는 생각도 없다. 그저 프로그래밍 할 뿐이다.

영어공부 한답시고 RSS를 탐독하지도 않고, 책을 읽을 때 소리내어 읽지도 않는다. 당장 내게 필요한 정보만 얼른 취한다. 만약 해당 분야에 개념이 부족하여.. 필요한 정보만 쏙 빼먹는 얌체권법이 통하지 않는다고 생각되면, 급한 마음을 다스리고 개념 탑재 모드로 바꾼다. 당장 구현하고 싶은 기능이 눈앞에 있지만 별 수 있나. 개념이 없는걸. 잠깐 모든 걸 잊고 욕심도 버리고 자아도 버리고 여유있게 테스트 코드 만들면서 공부한다.

더 좋은 방법론을 찾아 헤매이던 시절을 접고, 바야흐로 trial-and-error의 시대로 돌아간 것.

trial-and-error에 안착하는데 가장 큰 도움을 준 것은 Illuminated mind의 조나단이다. 바로 이 포스트. 그는 이 포스트에서 소중한 통찰을 간단한 문장으로 전달했다.

Sucking is absolutely necessary. There’s no way around it. In order to get better at anything, at some point or another you’re going to have to suck. That’s just the way it is.

So, here’s the secret to sucking at anything.

Start.

시작해버리는 것.

그런데 잘못 해석할 여지가 있다. 나 이거 이거 시작해요~ 라고 선언하는 것은 여기서 말하는 시작과는 구분되어야 한다. 큰일날까봐, 개판될까봐, 마음속에서 꾸물대며 시작하지 못하던 것을 시작하라는 얘기다. 그런데 대부분의 사람들은 큰일날까봐, 개판될까봐 시작하지 않는다는 것을 스스로 자각하지 못한다. 당연히 필요한 준비들을 하고있다고 생각하는 경우가 많을 것이다. 그러므로 어차피 안될(?) 사람은 이 글을 읽든 말든 시작하지 않는다.

저 글을 읽고 시작한 프로젝트가 하나 있다. 여태까지 써보지 않은 새 플랫폼 (안드로이드)에서의 프로젝트였는데, 무언지 모를 기운에 말려 시작을 1년 넘게 미루고 있었다. 여튼 시작해버렸더니 정말 수많은 suck이 시작됐다. 그런데.. Start => Suck => Better 패턴이 한 프로젝트에 결코 한 번 나오지 않는다는 것을 깨달았다. 즉,

  • 프로젝트 시작
  • 뻘짓
  • 내공 향상
  • 뻘짓
  • 내공 향상
  • 프로젝트 끝.

이런 게 아니라는 거다.

프로젝트 중간중간 셀 수 없이 많은 Start가 필요하다. 한 트랜잭션이 짧다. 개판이 될지도 모르는 위험을 무릅쓰고 계속 Start를 해야하는 거다. 이렇게 Start => Suck => Better가 계속되다보면 어느 시점에서는 꽤 좋은 품질에 도달해있다는 것을 깨닫게 될 것이다. 그러면 더욱더 Start가 어려워진다. 왜냐하면 개판이 됐을 때 잃는 것들이 훨씬 더 많아져버렸기 때문이다.

여기서 하나 짚고 넘어가야할 것이 있다. 대체 왜 시작하기가 어려운 걸까. 왜 개판되는 것을 왜 싫어하는 걸까. 스스로 시작해서 개판이 됐으면 자기 행동에 책임을 져야한다. 그런데 책임지기는 싫다. 혹자는 책임질 용의는 있으나, 스스로 책임질 능력이 없다고 생각한다. 그래서 괴테님은 파우스트에서 이렇게 말했다.

As soon as you trust yourself, you will know how to live.

내 생각에, 당신이 당신 자신을 신뢰하지 못하면, 당신 존재의 일부분을 신뢰하는 그 누군가가 당신의 영혼을 사용하기 시작한다. 사는 게 사는 것이 아니다. 하지만 본인은 깨닫지 못한다.

다시 Start 얘기로 돌아와서. 내 생각에, 시작하고나서 중요한 핵심 기능들을 다 완성하는데는 전체 프로젝트진행 시간의 20%도 걸리지 않는다. 그래서 나는 프로토타이핑을 아주 좋아한다. 20%의 노력만 쏟아도 고객들은 80%라고 보기 때문이다. 그런데 매번 고객 상대한다고 해서 본인마저도 핵심 기능이 정말 80%라고 착각하면 큰일난다. 왜냐하면 완성도를 높이는 부분은 핵심 기능이 아닌데, 이런 중요한 부분에 20%의 시간만 할당하고 20%의 관심만 주입할테니 (게다가 바람둥이 기질이 없는 사람은 관심을 분할하는 방법을 알지 못한다) 완성되는 결과물의 품질 또한  개판이 되기 때문이다.

그런데 왜 다들 핵심 기능에 목매달고 있는 것일까? 아직 80%에 대한 부분(UX도 80%에 포함될 것이다)이 normalize되지 않아서? 모르겠다. 내가 알 바 아니지. 남들이 우르르 start -> suck 하기 시작하면 긴장감이 극에 달하겠지만, 그들이 wait, wait, wait, bomb! 해준다면 나로써는 감사할 따름.

이제 다 끝났다고 생각했을 때, 다시 suck을 시작해야 한다는 사실을 잊지 말자.

위 곡은, 조금전에 연주한 피아노 소나티네 20분 투어. 틀린 부분만 빼면 -_- 썩 들어줄만 하다는 아내의 증언.

Categories: Development, Life, Piano, productivity Tags: