태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

티스토리 툴바


"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
얼마전 나가수에서 인순이씨가 7위를 했습니다. 굉장히 실험적인 음악을 했고 그 실험은 결국 방청객들의 좋은 반응을 이끌어내지 못했습니다. 전 그 노래를 들으며 저 실험적인 음악을 충분히 연습했고 나가수 나오기 전에 다른 곳에서 평가를 받아본 적이 있는 상태였었나 물음을 던져보고 싶었습니다.
(이미지출처)


인순이씨의 실패

인순이씨의 도전정신은 충분히 본 받아 마땅하지만 시간내서 그 곳에 온 방청객에게, 인순이씨의 노래에 잔뜩 기대하고 온 팬들에게 내놓을 수 있는 노래였는지는 납득하기 어려웠습니다. 혹시 나가수에서 처음 시도한 것은 아닌지... (인순이씨 디스하려는 것 절대 아닙니다. 그 연륜과 위치에서 나가수에 나왔다는 점은 매우 존경합니다.) 



임상실험

어떤 약을 연구하고 내놓기 전 반드시 임상실험을 합니다. 아무리 철저히 연구했더라고 하다라도 그 약에 결함이 있으며 생명에 치명적인 영향을 주기 때문에 세상에 나오기 전 충분한 테스트를 거쳐야 합니다.
자동차 역시 비용이 많이 드는 충돌 테스트를 반드시 거칩니다. 세상에 나오기 전, 고객이 사용하기 전 그만큼의 비용은 반드시 들여야 합니다. 너무 당연한 것입니다.


소프트웨어 현실에서

소프트웨어를 만드는 사람들도 고객에게 소프트웨어를 인도하기 전 이러한 검증절차를 거쳐야 합니다. 그러나 그렇지 않은 경우를 종종 보게 됩니다.
자신이 정확히 이해하지 못한 설계 패턴을 책에서 보고 고객 사이트에 적용하려는 시도, 아직 적용해 보지 못한 신기술, 검증받지 않은 최신의 매력적인 기술들을 고객의 시스템에 적용해보려는 시도를 과연 도전정신으로 받아들여야 할까요?

최악의 경우는 테스트 코드가 없거나 테스트를 하지 않은 코드를 고객에게 인도하려는 것입니다. 이런 것이야 말로 무모한 도전이고 그 위험 부담을 고객에게 전가시키는 것입니다.
기본적인 테스트 비용은 고객이 부담하는 것이 아니고 소프트웨어를 만드는 사람들이 부담하는게 맞습니다. 


그래서 해야 할 일

이런 이야기를 하면 항상 프로젝트 중이라 새로운 기술을 배우거나 적용할 기회가 없다고 합니다.
그러나 가끔은 고객이 새로운 기술을 적용하기를 원하는 도전적인 프로젝트를 주는 기회가 있기도 합니다. 이 경우는 행운입니다.

그렇지 않더라도 소프트웨어를 좋아하여 항상 탐구하려는 자세를 가진 개발자들이라면, 실전에 신기술을 적용하기 전 충분히 연구하고 동료들과 검토하고 검증할 기회는 많습니다.

최악의 경우처럼 테스트가 없는 코드를 고객에게 인도하는 일은 없어야 합니다. 기본적인 테스트도 하지 않는 코드를 인도하는 개발자는 기본적인 직업의식도 없는 거나 마찬가지지요. 테스트하기 어렵거나 지친다면 TDD를 해보는 것도 좋은 방법입니다.


부의 환경에 의해 소프트웨어 직군이 3D라는 말을 듣고 불평만 하지 말고, 소프트웨어 종사자가 단순 노동자가 아니라 전문적인 직업이라는 평가를 받기 위해 우리도 좀 더 프로답게 일할 필요가 있지 않나 생각해 봅니다.


저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리

어디에선가 들은 이야기

한참 공사 중인 공사장에서 세 사람의 인부가 열심히 일하고 있습니다. 지나가던 사람이 그 중 한 인부에게 물었습니다.


무엇을 하고 계십니까?

인부1: (매우 짜증나는 듯) 보면 모르쇼? 벽돌을 쌓고 있지 않습니까? 아이고 이거 언제 끝나려나... 그나 저나 날씨는 뭐 이리 더워

또 다른 인부에게 물었습니다.
인부2: (무덤덤하게) 그야 돈 벌고 있지요.

마지막 인부에게 물었습니다.
인부3: (그의 얼굴에는 행복이 가득 차 있습니다) 하나님께 바칠 성당을 짓고 있습니다. 아마 이 세상에서 가장 멋진 성당이 될 겁니다.



우리의 벽돌쌓기

개발자1: (야근으로 지친 모습으로) 저쪽 시스템과 통신하는 모듈을 코딩하고 있습니다. 이 놈의 요구사항은 또 언제 바뀔지도 모르는데 이대로 코딩해야 하나? 대충 돌아가게만...

개발자2: (왜 그런걸 물어보냐는 듯이) 돈 벌고 있습니다.

개발자3: (자신감에 찬 모습으로) 동료간 업무를 효율적으로 수행할 수 있고 소통을 극대화할 수 있는 SNS를 만들고 있습니다. 이 시스템이 완성되면 이 업계에 큰 이야기거리가 될 것입니다. 그리고 많은 사람에게 도움을 줄 것입니다. 왜냐하면 이 시스템은 ...


우리는...

우리에게 누군가 "무엇을 하고 있나"라고 물으면 어떤 대답을 하고 있나요? 나와 일하는 동료들에게 물으면 어떤 대답을 할까요?



저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
요즘 사용하는 대부분의 컴퓨터는 멀티 태스킹을 지원합니다. 굳이 새삼스럽게 멀티태스킹 이야기를 하는 이유는 요즘 배치작업 관리 설계를 하다가 멀티 프로세스 처리방법과 싱글 프로세스 처리방법에 대한 이야기가 생각나서 글을 적어봅니다.

멀티태스킹이 빠르다?

두 개의 작업이 있을 때 이를 모두 처리하기 위한 시간은 두 개 작업을 병렬도 동시에(2개 프로세스) 처리하는게 빠를까요. 직렬로 하나를 먼저 처리하고 다음 것을 처리하는게 빠를까요.
그냥 이론적으로만 따져볼 때 직렬로 하나의 프로세스로 처리하는게 빠릅니다.


그림의 예를 보시면 작업1, 2 각각 5개의 CPU clock을 필요로 하는 작업이라고 가정합니다. 그리고 수행할 작업을 교체해 주기 위한 스위칭에는 1 clock이 소요된다고 가정합니다.
그러면 두 작업이 모두 끝나기 위해서는 멀티 프로세스로 처리했을 경우 총13 clock, 단일 프로세스는 11 clock 소요됩니다. 즉 스위칭 타임이 빈번할수록 전체 처리시간은 길어지게 됩니다.


멀티태스킹이 빠를 것 같은데??

실제 컴퓨팅 작업시간이 CPU 속도만 관련되지 않기 때문입니다. 작업을 처리하는 동안 자원을 접근하는 경우 이는 CPU 속도에 비해 많이 느립니다. 이 때 자원에 대한 응답 기다리는 동안 다른 작업을 처리하는게 전체 시간을 줄이는데 유리합니다. 웹 브라우저를 예를 들면 한페이지에 나타내기 위해 필요한 컨텐츠들(HTML, CSS, 스크립트 그리고 많은 이미지들...)을 모두 차례로 다운받고 모두 받은 후 화면을 그리는 것 보다는, 받는대로 계속 보여주는 것이 전체적인 속도도 빠를 뿐만 아니라 사용자 반응속도도 좋게 보입니다.


멀티태스킹을 하지 말아야 할 때

사람은 작업전환 속도가 매우 느립니다. 특히 개발자들은 작업전환을 굉장히 어려워할 뿐만 아니라 싫어합니다. 사람은 컴퓨터와 같지 않습니다. 그냥 한 번에 하나의 일을 하는 것이 좋습니다.
개발자가 몰입에 빠져 있을 때(flow) 그것을 깨지 마세요. 여러 사람이 개발자에게 이것 저것 요청하지 마세요. 개발자의 input은 팀 리더만으로 충분합니다.

이미지출처

멀티태스킹을 해야 할 때

소프트웨어 개발은 대략 "분석 -> 설계 -> 구현 -> 통합/테스트" 이런식으로 흘러갑니다. 모든 요구사항을 구현까지 완전히 마치고 테스트로 넘기면 테스터나 고객들 작업에서 병목이 생길 겁니다. 그 기간에 대부분의 개발자는 테스트 결과 받느라 손놓고 있을 경우가 많습니다. 그리고 테스트 결과 오면 이번에는 개발자가 굉장히 바빠집니다.

이 때 멀티태스킹을 해야 할 시점입니다. 모든 요구사항 완전히 끝내기 전 중간 중간 피드백을 받을 수 있도록 결과물을 테스터나 고객에게 넘기세요. 그렇습니다. 애자일에서 말하는 방법이죠 ^^
내가 다음 요구사항을 개발할 때 테스터나 고객을 이전 요구사항을 테스트 하거나 검토할 겁니다. 나중에 통합/테스트 작업에 큰 병목이 걸릴 염려도 줄어듭니다.

 
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
사용자 삽입 이미지
결함이 없는 프로그램은 없을 겁니다. 결함이나 버그의 수는 그 소프트웨어의 품질을 좌우하는 요소입니다. 그럼 우리회사의 제품, 또는 현재 수행하고 있는 프로젝트의 시스템에는 얼마나 많은 버그가 있을까요? 우리 프로그램에 얼마나 많은 결함(또는 버그)가 숨어있는지 예측하는 방법을 알아봅니다.



연못에 있는 물고기 수 확실히 알아내기
근처에 물고기가 살고 있는 연못을 상상해 보죠. 이 연못에 살고 있는 물고기는 얼마나 될까요?
이것을 알아내기 위한 확실한 방법은 양수기를 하나 준비하는 것입니다. 그리고 물을 모두 뽑아 내고 물고기를 모두 잡아 그 수를 세어보는 것입니다.
한 사람의 호기심에 의해 희생되는 불쌍한 물고기에 대한 생각은 접어둔다쳐도 이렇게 힘들게 알아내어야 할까요? 우리는 알아내기 힘든 대상에 대해 예측이라는 방법을 사용합니다.


물고기 수 예측하기
사용자 삽입 이미지
연못에 살고 있는 물고기 수를 예측하는 방법으로 생각해 봅니다.
우선 연못에 100마리의 물고기를 풀어놓습니다. 물론 이 100마리는 우리가 알아볼 수 있도록 꼬리표를 달아둡니다.
모두 풀었으며 연못에서 물고기를 임의로 10마리쯤 잡습니다(통계에서는 이것을 표본이라 합니다). 그리고 10마리 중 우리가 풀어놓은 물고기의 비율을 계산합니다.

예를 들어 10마리 중 2마리가 우리가 풀어놓은 물고기라면 8마리는 원래 연못에 있는 물고기일 겁니다. 결국 우리가 풀어놓은 물고기보다 원래 있는 물고기가 4배 정도 많을 것이라고 가정할 수 있습니다. 따라서 우리가 풀어놓은 물고기가 100마리이니 원래 있던 물고기는 400마리정도 될 것이라고 예측할 수 있습니다.


내 애플리케이션에 있는 결함 개수 예측하기
물고기를 다 잡기 위해 물을 다 퍼내는 것은 가능할 지 몰라도 애플리케이션에 가지고 있는 모든 결함을 찾아내는 것은 불가능에 가까운 일입니다. 아무리 테스트한다 한들 어느 누가 모든 결함을 다 찾았다고 확신할 수 있을까요?

사용자 삽입 이미지
물고기 수 예측하는 방법으로 결함 개수를 예측할 수 있습니다.
우선 결함을 10개 정도 만들어 애플리케이션에 심어 놓습니다. 물론 이 결함은 테스터들에게 알려주지 않습니다. 이 상태에서 테스터는 결함을 찾기 위한 테스트를 진행합니다.
그 후 테스터가 찾은 결함 중에 일부러 심어 놓은 결함의 비율을 계산합니다. 여기서 10개의 결함을 찾았고 그 중 2개가 우리가 심어 놓은 결함이라고 가정하면 다음과 같은 공식이 성립할 것입니다.

원래 있는 결함 수 : 심어 놓은 결함 수 = 찾은 것 중 원래 것 : 찾은 것 중 심어놓은 것
원래 있는 결함 수를 x라 하면
x : 10 = 8 : 2
2x = 80
x = 40

따라서 원래 있는 결함 수는 40개 쯤 됩니다.

결론
이 방법을 사용할 때 주의할 점은 원래 있는 결함과 일부러 심어놓은 결함을 찾을 수 있는 확률이 비슷해야 된다는 점입니다. 그래야 테스터가 찾은 결함이 통계를 위한 올바른 표본이 될 수 있습니다.

물론 이 방법은 꽤 많은 비용이 든다는 점과 위의 제약사항 등에서 몇 가지 문제가 있습니다. 그러나 결함을 통한 소프트웨어의 품질 측정이 필요할 경우 사용할 수 있는 방법입니다.


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
아래 내용은 제 가족이야기는 아닙니다. 오해하지 마세요~

착한 아빠

우리 아빠는 마음이 너무 좋습니다. 그래서 친구분들이 많죠. 친구들이 어려움에 처하면 발벗고 나서 도와줍니다. 그래서 간혹 기꺼이 보증도 서곤 하지요.
나쁜 아저씨들은 이런 아빠의 마음도 몰라주고 도망가곤 해서 아빠를 어렵게 만듭니다. 그래도 아빠는 사람좋다는 말에 위안을 삼고 계속 착하게 살아갑니다.

그런데 우리 가족은 좀 힘드네요. 확실히 아빠가 우리 가족을 사랑하시는 것 같기는 한데 말이죠. 


난 착한 PM

저를 좋아하는 고객은 참 많습니다. 고객을 우선으로 하는 저의 마음가짐이 고객을 감동시키는 것 같습니다. 오늘도 고객의 요구사항을 주의깊게 듣고 고객이 원하는 변경사항을 틀림없이 바로 적어갑니다.
우리 팀원들도 고객이 가장 중요하다는 것을 잘 압니다. 환상의 팀웍이죠.
아~ 오늘밤만 꼬박 새면 고객의 요구사항 변경을 다 처리할 수 있을 것 같습니다. 이걸로 만족해야 할텐데.

미안합니다. 나는 착한 PM입니다.

---
가끔 제가 고민하는 내용입니다.


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
고등학교 2학년 때까지 펑펑 놀다가 고3 들어가기 전 마음잡고 독서실에 들어가 말그대로 공부만 했습니다. 다음의 이야기만 없다면 진짜 하루 20시간 공부만 했다고 자신있게 말했을겁니다.
스톱와치 하나 구해서 공부하는 시간만 측정해 보았습니다. 간단한 식사라도 하면 시간을 멈추고 잠시 머리식힐 때, 5분정도 엎드린 때, 다른 책 가지러 갈때 여하튼 공부하는 시간이 아니라고 판단되는 시간은 모두 빼고 측정해 보았습니다. 결과는 10시간정도였던 것으로 기억합니다.
자신있게 온통 공부에만 집중했고 짧은 시간에 꽤 효과를 보았습니다. 그런데도 기대했던만큼 집중하는 시간이 많이 나오지는 않더군요.

혼자 일할 때 벌어지는 일들

회의를 마치고 오늘 해야할 일을 확실히 하고 근무에 집중하겠다는 마음을 다 잡습니다.
아.. 우선 메일을 확인해봐야겠습니다. 중요한 업무관련 메일이 왔을지도 모를일이니다. 내가 구독하는 기술사이트에서 신기술에 관한 소개메일이 왔네요. 이거 내 업무랑 아주 중요한 관련이 있을 것 같습니다. 열심히 읽어보고 ... 아 아직은 이 기술이 때가 아니군요.
이제는 어제 분석한 요구사항을 설계해야겠습니다. 음... 새하얀 도화지 같은 설계도구에 뭘 부터 그려넣어야 할지 모르겠네요. 이럴까 저럴까... 몇분 고민하다... 아 이런 갑자기 기가막힌 아이디어가 떠올라 공상도 해 봅니다.
아.. 정신차려야줘. 집중! 집중! ...
열심히 고민한 끝에 1차 설계가 나왔습니다. 그런데 이 부분은 좀 애매합니다. 음.. 이렇게 해도 될까? 저렇게 한 번 바꿔봅니다. 음.. 원래구도가 낳겠다... 옆동료에게 조언 좀 구하자.
음... 옆동료는 한참 집중중이네. 지금 물어봐도 될까. 말까? 또 몇 분 망설입니다. 차 한잔 하고 와서 물어보자.
차 한잔하고 와서 동료 주위를 어슬렁거리다가 큰 맘먹고 이야기 합니다.
이것 좀 같이 검토해 줄 수 있어요?
한참 집중하고 있던 동료는 짜증나는 얼굴로 대답합니다. "좀 나중에 봐도 돼요?" 그러고는 머리 식힐려고 그러는지 밖으로 나갑니다. 아.. 내가 방해가 되었나보다. 혼자 고민해봐야겠다...


짝 프로그래밍이 노닥거리는 것은 아니다.

짝 프로그래밍을 할 경우 한 컴퓨터로 두 사람이 교대로 프로그래밍을 드라이브합니다. 드라이브하는 사람이 키보드를 가지고 코딩을 하고 다른 사람은 계속 의견을 말하죠.
주로 하는 이야기는 코딩을 말로 읽듯이 하고 그 순간 순간에 설계나 코딩에 대한 의사결정을 합니다. 설계나 프로그래밍을 할 때 굉장히 많은 잘잘한 의사결정이 이루어지집니다. 짝 프로그래밍을 할 때 둘이 의사결정을 협의하여 내리기에 혼자 의사결정을 할 때보다 정확히 빠른 속도로 이루어집니다.
이렇게 작업하다보면 작업하다가 쉽게 옆으로 빠지는 일이 잘 일어나지 않습니다. 프로그래임 드라이브를 교대로기에 혼자하는 것보다 덜 지칩니다.
굉장히 집중하는 시간이 길어지게 됩니다. 이것을 flow라고도 하지요.
짝 프로그래밍을 하다보면 집중하는 시간이 길어지기 때문에 좀 피로감도 느낍니다. 하루에 3,4시간 짝 프로그래밍하기가 그렇게 쉽지는 않습니다.

우리가 하루 8시간 프로그래밍을 한다고 가정할 때 진짜 쓸만한 코드가 집중적으로 나오는 시간은 그렇게 많지 않습니다. 바로 이 시간을 잡으면 그날 하루가 보람찬 하루가 되는거죠.

짝 프로그래밍은 이 시간을 쉽게 잡을 수 있습니다. 결코 노닥거리는 시간도 아니며 오히려 굉장히 힘든(그렇지만 재미있는) 일입니다. 이 사실을 알면 모든 관리자가 짝 프로그래밍을 더 권장할텐요...


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
"코드리뷰의 비밀"에서 프로그램밍에서 인지부조화 문제를 해결하기 위한 방법은 상호간의 코드리뷰라고 이야기했습니다. 그러나 여기에 약간의 문제가 있습니다.

많은 개발자들이 자신의 코드에 자아를 투영시키는 경향이 있습니다. 개발자들은 자신이 작성한 코드에 많은 애착을 갖고 자신의 코드에는 자신의 특색을 나타내는 무엇인가가 있다고 느낍니다. 실제 어떤 개발자는 코드만 보고 내 소스인지 금방 파악할 수 있다고 말하고는 합니다.

여기에서 코드리뷰 방법에 문제가 발생합니다. 일반적이 코드리뷰의 목적은 코드에 어떤 문제가 될만한 요소가 있는지 찾는 것입니다. 그런데 다른 사람이 나의 코드에서 문제를 찾는 것이 나에 대한 심판으로 여겨질 수도 있습니다. 이는 협력이 가장 중요한 프로그래밍 작업에서 사람들간의 대립과 불신을 만들 수 있습니다.


이런 경우에는 프로그래머에서 코드리뷰의 유용성을 설명하고 코드리뷰에 적극적으로 임하라고 교육시키는 것만으로는 충분하지 않습니다. 물론 교육을 받을 당시에는 그 뜻에 공감하겠지만 개발자가 자신의 코드에 자아를 투영시키는 한 다른 사람이 그 코드에서 문제점을 지적하는 일은 개발자에게 방어적인 태도를 취하게 만들는 일이며 결국 성공적인 코드리뷰가 이루어질 수 없습니다.

따라서 근본적인 문제인 자아적 프로그래밍 문화를 바꾸어야 합니다. 이것을 "프로그래밍 심리학"에서 비자아적 프로그래밍이라고 합니다.
이 책에서는 비자아적 프로그래밍을 하는 조직에서는 프로그램 작성 후 작성자가 코드를 리뷰할 사람을 찾고 적극적으로 조언을 구한다고 합니다.
비자아적 프로그램을 할 경우 우선 남에게 보여줘야 하는 코드이기 때문에 명확한 프로그램 구조를 가져야 하고 읽기 쉽게 작성하려고 노력합니다. 결국 자연스럽게 코드의 품질은 높아집니다.
또한 릴리즈 되기전 동료가 문제될 만한 버그를 대부분 찾기 때문에 릴리즈 후 발생하는 버그로 인해 개발자가 받을 수 있는 곤경을 차단하기에 개발자는 일과 팀에 대한 만족감을 높일 수 있습니다.
그 팀은 서로 코드를 읽어야 하기 때문에 다른 사람의 지식을 자연스럽게 습득할 수 있어 팀 학습능력이 뛰어납니다.

그러나 여기에서는 비자아적 프로그래밍을 하는 팀이 되기 위한 구체적인 방법은 없으며 그런 팀이 많지 않은 이유만을 설명합니다.

비자아적 프로그래밍을 하기 위한 구체적인 실천방법으로 XP(Extreme Programming)에서 이야기 하는 짝프로그래밍이 아닐까 합니다. 이 방법으로 개발을 하다 보면 프로그래밍 소스에 대한 소유권이 애매해져 자연스럽게 코드를 공유하게 되고 나 혼자만의 코드가 아니라 자아를 투영하기 어렵습니다.
또한 누군가 코드에서 문제를 발견하여 보고하더라도(또는 심하게 비판을 하더라도) 혼자 개발한 코드에 대한 문제보다 덜 상처받고 쉽게 응할 수 있습니다.

이 방법은 결국 자연스럽게 비자아적 프로그래밍이 가능하게 하고 그로 인한 열매를 얻을 수 있습니다.


크리에이티브 커먼즈 라이선스
Creative Commons License

'하고싶은말' 카테고리의 다른 글

난 착한아빠가 싫다  (0) 2010/02/03
짝 프로그래밍이 더 생산성이 좋은 이유  (2) 2010/02/01
비자아적 프로그래밍  (4) 2010/01/28
사람이 가장 훌륭한 도구다  (6) 2010/01/21
개발자를 괴롭히는 기술들  (3) 2010/01/11
코드리뷰의 비밀  (3) 2010/01/04
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
가끔 후배들에게 이런 질문을 합니다.
프로그래머가 뭐하는 직업이냐
아무런 상황 설명 없이 하는 이런 류의 질문이 사람을 당황하게 하고 짜증나게 합니다. 물론 머뭇머뭇 거리다가 제대로 답하지 않는 경우가 대부분입니다. 꽤 오래 생각해 봐야 할 질문이죠. 특히 자신이 하는 직업일 경우는 더욱 그렇습니다.

프로그래머라는 직업을 가지고 이분야에서 일한지 십수년이 지났네요. 시간이 흐름에 따라 나이도 먹고 직급도 올라가고 거기에 따라 하는 일도 조금씩 달라지게 됩니다.
현재는 이클립스(프로그램 툴)보다 파워포인트가 화면에 떠있는 시간이 더 많아졌지만 나는 아직 "프로그래머"라는 직책을 버리지 않았습니다. 하는 일은 달라졌어도 여태껏 했던 일의 맥은 같다는 걸 알았습니다.
(이미지출처)


코드와의 만남

처음 컴퓨터 프로그램을 만난 것은 중학교 실습 교과서에서 본 FORTRAN 코드였습니다. 기억을 더듬어보면 교과서에 컴퓨터 관련 페이지가 몇 페이지 있었고 천공카드이야기도 있었고 그 당시 최첨단 언어인 FORTRAN으로 짠 이차방정식 예제 코드가 있었던 걸로 기억합니다.
(이미지출처)
컴퓨터 언어라는게 신기해서 1/3 페이지 정도 되는 몇 줄짜리 포트란 코드를 오려서 읽고 또 읽어 그냥 외워버렸습니다. 아무런 지식이 없었던 때인데도 외워버리니까 이해가 되더군요. 그 정도로 신기해하고 열정적이었죠.
그리고 그 열정은 대학을 가서 파스칼을 독학하고 C를 독학하고 컴퓨터 언어에 깊이 빠졌습니다. 명령어들을 조합하고 엮어서 프로그램이 만들어지는 과정이 너무 재미있었습니다.


객체에 빠지다

군대를 제대하고 세상이 많이 바뀌었습니다. 접근하기 어려웠지만 인터넷이라는게 등장하고 언어쪽에서는 이해할 수 없는 객체라는 놈이 새로운 다크호스로 등장했습니다.
이 때 선배가 건네준 객체지향 관리 기법이라는 책을 읽고 또 한 번 감동~. 이 기술에 또 한 번 빠지게 됩니다. 처음 입사한 회사도 객체지향 기술을 주로 다룬 행운도 따랐습니다.
이 때는 코드를 넘어서 프로그램 내에 존재하는 객체들을 찾아내고 관계를 맺고 구조화하는 일이 주된 관심이 되었습니다. 바로 설계라는 영역에 들어섰습니다.


컴포넌트와의 불편한 관계

지금은 소프트웨어 컴포넌트나 CBD에 대한 이해가 어느 정도 공유된 상태라고 보여집니다. 2000년 들어서기 전 ETRI에서 진행하는 컴포넌트 소프트웨어 프로젝트에 참여한 적이 있습니다. 이 때 회의를 보면 컴포넌트에 대한 정의가 명확하지 않았던 때였던 것 같습니다. 어떤 이는 OS 조차도 컴포넌트로 정의해 버리곤 했는데 모든 게 컴포넌트라면 정의는 쉽지만 우리가 푸는 영역의 해결은 되지 않았습니다.
현재는 소프트웨어 컴포넌트에 대한 어느 정도 공통된 이해가 있고 객체보다는 좀 더 넓은 영역에서 소프트웨어를 정의합니다. 이 때는 주로 소프트웨어 모듈(컴포넌트) 구분과 이들의 명확한 인터페이스 정의에 제 업무 시간을 많이 사용하게 되었습니다.


아키텍처 세계

소프트웨어 컴포넌트 설계 외에 프레임워크 설계를 담당하다가 성능, 가용성 등 시스템 품질이라는 영역을 다루다가 보니 아키텍처라는 영역에 오게 됩니다.
이 때는 주로 전체 시스템에 대한 영역과 이들간의 관계에 집중하게 됩니다. 그 안에는 컴포넌트도 있고, 모듈도 있고 그리고 하위 시스템도 존재하게 됩니다. 시스템이 목표하는 품질에 맞추기 위해 전체적인 소프트웨어 얼개를 어떻게 맞추느냐가 주업무가 됩니다.
(이미지출처)
아키텍처 일을 하다 보면 프레임워크가 중요한 부분을 차지하게 되는데 이 때 개발자들이 쉽게 사용하고 생산성을 높일 수 있는 프레임워크를 고민하게 됩니다. 그러면서 개발환경에도 관심을 갖게 되고 개발자가 좋은 생산성을 낼 수 있는 여러가지 방법을 고민하게 됩니다.

이 때 개발자가 행복하게 효율적으로 일하는 방법이 중요하다는 것을 깨닫게 되었습니다.


팀워크의 힘을 경험하다

좋은 사람과 좋은 개발 환경과 좋은 기술을 가지고 있으면 이 세계에서 일하는 것이 한결 쉬워집니다. 물론 그 결과물도 훌륭하게 나오겠죠. 그래서 좋은 아키텍처를 계속 고민하고 개발자들이 효율적으로 일할 수 있는 환경(형상관리, CI, 자동화...)에 힘을 쏟는 것이 굉장히 중요합니다. 그리고 가장 중요한 것은 좋은 사람들입니다.

좋은 사람들은 그냥 만들어지는게 아니고 팀워크라는 것을 통해 만들어집니다. 일하는 방법에 대한 공감이 형성되어야 하고 서로 존중하는 문화가 만들어져야 합니다.


모든 것은 사람이 중심이었다

프로그래머라는 직업은 고객이 원하는 문제를 풀어주는 직업이라고 봅니다. 그 방법은 코딩이 될 수도 있고 객체설계, 컴포넌트 설계, 아키텍처 설계가 될 수도 있습니다.
그러나 모든 것은 사람이 하는 일이고 사람이 그 중심에 있습니다. 사람들을 어떤 환경(프레임워크)에서 어떤 일하는 문화(프로세스)에서 일하게 조직하느냐(설계)가 가장 막강한 방법입니다.

고객의 문제를 풀어주는 가장 훌륭한 도구는 컴퓨터 언어나 설계가 아니라 바로 사람입니다.

나는 개발자가 행복하게 일할 수 있는 환경을 설계하는 사람이 되고 싶습니다.


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
소프트웨어 분야의 기술들은 정신없이 쏟아지고 있습니다. 저도 제가 관련된 분야에 최신 기술의 최선봉에 있다고 생각했지만 점점 그 기술들을 쫓아가기 벅찹니다. 이제는 클라우딩 컴퓨팅이나 VM 쪽 기술들을 잘 살펴볼 필요가 있네요.

이런 최신 기술들은 현재 산적한 문제들을 풀기 위해 나온 기술들이고 당연히 그 기술을 사용하는 개발자를 행복하게 만들어야 한다고 생각합니다. 그런데 제가 경험한 기술들이 모두 개발자를 행복하게 만든 것 같지는 않습니다. 저를 괴롭히 기술들은 한 번 정리해볼까 합니다.
(이미지출처)


CORBA (Common Object Request Broker Architecture)

제가 입사해서 처음 만난 환상적인 아키텍처입니다. 한 때 이 기술에 심취해 있었고 OMG에서 주도한 이 기술이 세상을 하나로 통합할 것이라는 순진한 믿음을 가지고 있었습니다.
이와 더불어 객체지향데이터베이스(OODBMS)를 같이 사용했는데 처음 다닌 회사가 이 두 제품을 다뤘기에 회사 게시판을 OODBMS와 ORB 제품인 Visibroker를 이용하여 만들었습니다. 엄청 느려터진 반응속도와 쓸데없이 많이 분산된 객체들 무엇보다 이 두 제품을 공부하지 않고는 간단한 게시판을 수정할 수 없었습니다. 그냥 PHP 같은 걸로 만드는게 백번 나았을텐데 말이죠.

CORBA는 임베이드에서 부터 엔터프라이즈까지 통합할 스펙을 갖추었고 모든 산업분야를 거쳐 표준화된 프로토콜을 이용하여 통합할 수 있는 스펙들이 진행되고 있었습니다. 그러나 이 거대한 스팩을 완벽히 구현하는 제품은 나오지 않았으며 서로 다른 ORB 제품의 통합도 그리 쉽지는 않았습니다.
이제는 역사의 뒤안길로 사라지고 남은 거라고는 그 많은 스펙중 IIOP 정도만 남은 것 같았습니다. 무조건 환상적인 아키텍처와 스펙이 좋은 것만은 아니라는 것을 깨닫게 해 준 기술입니다.

객체지향데이터베이스가 성공하지 못한 건 개인적으로 참 안타까웠습니다. ㅠㅠ

Entity Bean

객체를 관계형데이터베이스(RDBMS)에 자동(?)으로 매핑시켜주는 기술은 객체지향에 심취해 있는 나로서는 열렬히 옹호할 수 밖에 없는 기술이었습니다.
그러나 부족한 스펙, 안되는 기술들 그리고 현실에 맞지 않는 작동방식들은 이걸 사용함으로써 더 복잡성만 증가시키고 캐싱이나 클러스터링 같은 해결하기 더 어려운 문제를 양산하고 말았습니다. 이런 문제를 해결하느라 더 고생하고 시스템은 더 복잡해졌던 것 같습니다.
이제는 많이 성숙한 Hibernate 같은 ORM이 있어 더 이상 Entity Bean의 쓸모에 대한 논쟁은 필요가 없어 다행입니다. Hibernate 같이 재야 기술이 성숙해 주도를 하는 일은 개발자에게 행운입니다.

이쪽 관련한 기술 중 JDO(Java Data Object) 라는 꽤 성숙한 기술이 있는데도 불구하고 JPA라는 새로운 스팩이 나왔습니다. JDO는 비단 RDBMS 뿐만 아니라 LDAP, XML 등 저장 매체와 독립적인 스펙입니다. DBMS 벤더 입장에서는 반길만한 스펙은 아니죠. 그래서 비슷한 그러나 아직 부족한 JPA 표준이 출현했다는 이야기가 있습니다. 기술의 출현과 선택은 시장에서 이루어지는 것 같지만 몇몇 대형 벤더의 이해관계에 따라 주도되는 경우가 있습니다. 이런 경우가 그 경우인 것 같습니다. 경험상 이런 기술들이 개발자를 괴롭히곤 합니다.



SOAP

SOA(Service Oriented Architecture)를 이야기하면 먼저 떠올리고 거론하는 기술입니다. 그래서 모든 시스템간의 호출과 통합은 SOAP으로 통합한다는 꿈을 비추고는 하지요. 이 기술이 나온지 꽤 되었지만 제가 기업 시스템 쪽 일을 하면서 이 방식의 통합은 진짜 손에 꼽을 정도입니다.(제 경험상) 전체 시스템간 통합방식에서 SOAP이 차지하는 비중이 얼마나 되는지 진짜 궁급합니다.
구글이나 아마존같은 대형 인터넷 기업에서는 이 방식의 통합이 이미 줄어들거나 없어지는 추세이고 말이죠.

이 기술도 CORBA와 비슷한 것 같습니다. 엄청난 스팩, 그 스팩에 대한 완전한 구현체가 있는지 그리고 그게 현실에 부합하는지는 의문이 갑니다. SOAP 호출의 릴레이, 보안 그리고 분산 시스템의 트랜잭션 등이 해결하기 그렇게 쉬운 부분이 아니죠. 기업 안의 이종 DB간의 분산 트랜잭션도 현실에서는 쓰기를 주저하는 판에 서로 다른 회사의 트랜잭션을 한 가지 기술로 해결하려는 시도는 아직 요원해 보입니다.

무엇보다도 불행한 건 간단한 통합에 있어 이 기술을 강요하는 경우입니다. 완전한 스팩을 위해 SOAP은 다른 것 보다 배우기 어렵고 여러가지 문제를 해결해야 합니다.
이쪽 전문가들에게 욕을 먹을 수 있겠지만 개인적으로는 SOAP이 CORBA와 같은 절차를 밟지 않을까 생각합니다.


Javascript, CSS, ActiveX

풍부한 클라이언트 요구가 증가합에 따라 이 기술들을 점점 더 많이 사용하고 있는 추세입니다. Javascript는 막강하고 좋은 언어이지만 cross browser 문제를 해결하는데 힘이 듭니다. CSS도 마찬가지죠. 특정 브라우저(IE ^^)를 욕하고 싶지만 뭐 제가 욕할만한 처지는 아니라 하지 않습니다. (우이씨~ 너무 괴롭습니다.)
Cross browser가 되어야 한다고 열심히 여러 브라우저에서 테스트하여 맞추었습니다. 그런데 마지막에 보안때문에 ActiveX 보안 솔루션 탑재합니다. 여태까지 왜 다른 브라우저에서까지 테스트 했는지 모르겠습니다. 한 순간에 여지껏 한 작업 의미 없게 됩니다.


그 밖에...

글을 쓰다보니 오늘은 불평을 늘어놓은 날이 되었네요.
개발자들 굉장히 바쁩니다. 이것 저것 배우고 연구해야 하고 고객 요구사항 들어줘야하고 버그도 처리해야 합니다. 그런데 개발자를 도와야 할 기술들이 오히려 개발자가 가치를 내어야 할 시간을 뺏는 경우를 볼 때 참 안타깝습니다. 이런 기술들을 제 마음대로 여러 개 뽑아보았는데 글이 길어져 대충 마무리할랍니다.

SOA: 실체가 없는 기술(아키텍처)입니다. 너무 현혹되지 마세요.
ORM: 필요할 때 사용하세요. 제발.. Hibernate 잘 가고 있는데.. JPA라니... JDO는 어쩌라구..
XML: XML 너무 복잡해지고 있습니다. 선별해서 잘 사용하십시오. POX(Plain Old XML)에 대해 고려해 보세요.


크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠
"올바른 성장과 따뜻한 나눔"이 있는 넥스트리
인지부조화

사회심리학자 페스팅거를 필두로 해서 인지부조화(cognitive dissonance)라는 심리현상의 실체를 규명하기 위한 수많은 실험이 행해졌다.
피실험자들에게 자신이 강하게 부정하는 논제를 긍정하는 방향으로 논증하는 글을 쓰도록 한다. 피실험자들을 두 그룹으로 나누고 한 그룹에는 실험 답례로 1달러를 다른 그룹에게는 20달러를 주기로 한다.
실험 후 피실험자의 의견을 다시 조사하여 자신의 의견을 어느 그룹이 더 많이 바꾸었나 보았다.
상식적으로는 20달러를 받은 사람들이 더 열심히 하여 자신의 의견을 바꿀 가능성이 높아 보이지만 반대로 1달러를 받은 사람들이 글을 쓴 후 자신의 의견을 더 많이 바꾸었다.
이런 현상을 인지부조화라고 한다. 어느 누구나 자신의 의지에 반하는 일을 하는 것은 매우 불편한 일이다. 자신의 의견과 반대되는 글을 쓰는 것 역시 그렇다. 이런 상황을 인지부조화 상황이 발생했다고 한다.
20달러를 받은 사람들은 이런 부조화 상황을 20달러라는 보수를 받는 것으로 위안삼고 행동을 한다. 반면 1달러를 받는 그룹은 1달러는 이런 부조화 상태를 해소하기에는 너무 작은 금액이라 실험을 충실히 하여 실험에 기여하는 것을 통해 부조화 상태를 해결한다.
결국 보다 충실히 실험에 임한 1달러 그룹은 자신의 의견을 공정하게 보도록 노력한 결과 원래의 의견을 더 많이 바꾸게 된다.
- 프로그래밍 심리학 중


인지부조화의 일상의 예는 당신이 구입한 물건에 대해 그 물건의 품질에 관계없이 좋다고 믿는 경향에서 찾아볼 수 있다. 당신이 만일 자동차로 소나타를 구입했다고 가정하자. 그런데 어느 영업사원이 현대차 카탈로그를 한뭉큼 던져주면 당신은 분명 다른 차보다는 아마 소나타 카탈로그를 유심히 볼 것이다.
이미 결정한 자기 결정에 반하는 상황(인지부조화)에 빠지지 않으려는 자연스러운 현상이다.

(이미지출처)

코드리뷰

흔히 코드에 문제가 발생했을 때 코드를 작성한 자신보다는 다른 사람이 문제점을 쉽게 발견하는 현상을 많이 경험하게 된다. 대부분의 프로그래머는 자신이 작성한 프로그램을 자신의 분신이라고 생각하는 경향이 있다. 이러한 결과물(프로그램)에서 문제점을 발견한다는 것은 불편한 일이며 심리학적인 부조화 상태를 만들어낸다.
이런 부조화 상태에서 무의식적으로 프로그램의 잘된 것만 보고 잘못된 것은 보지 않으려는 능력은 생각외로 탁월하다.
따라서 모든 사람들이 자신의 프로그램에 대해 가질 수 있는 인지부조화 상태의 문제를 해결할 수 있는 방법에는 객관적으로 프로그램을 검토해 줄 수 있는 코드리뷰가 있다.

소프트웨어 추정(Steve McConnell)에 따르면 정밀코드리뷰는 적게는 45% 많게는 70%의 결함을 제거할 수 있다고 한다.
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 행복한아빠