[카테고리:] 스치는 생각들

면접 장소에 종이뭉치 하나가 떨어져 있었다. 아무도 이를 줍지 않았는데 한 사람만이 이를 발견하고 주웠다.

그러자 면접관이 종이를 펼쳐보라고 얘기했다. 종이에는 이렇게 쓰여 있었다. “우리 회사에 입사한 것을 환영합니다.” 몇 년 후 종이뭉치를 주웠던 지원자는 사장이 되었다.

1961년 4월 12일, 구 소련의 우주비행사 가가린은 4.75톤의 보스토크 1호를 타고 89분간 우주를 비행하여 세계 최초의 우주비행사가 되었다.

당시 그는 19명의 지원자와 경합을 벌였는데 선발요인은 뭔지 아는가. 다른 사람들은 모두 신발을 신은 채 우주선에 올랐는데 그 만은 신발을 벗고 우주선에 올랐기 때문이다.

이처럼 별 것 아닌 것 같은 세심함이 사실은 개인과 조직의 성패를 좌우한다. 우리는 늘 2%가 부족해 일을 그르친다. 크게 일을 잘 벌이기는 하지만 언제나 마무리가 약하고 그런 사소한 것 때문에 성과를 내지 못하는 경우가 많다.

사업도 대범함만으로는 안 된다. 이런 세심함이 필수 조건이다. 대만 제일의 갑부 왕융칭 포모사 회장이 그렇다. 그는 어려운 집안 형편 때문에 쌀 가게로 사업을 시작했다. 하지만 위치도 안 좋았고, 경쟁도 심했다. 당시는 길에서 도정을 했기 때문에 쌀에 돌이 무척 많았다.

그는 두 동생을 동원해 이물질을 일일이 골라낸 후 판매했다. 또 노인들이 주로 쌀을 사러 왔는데 운반이 문제였다. 왕융칭은 직접 쌀을 배달하기 시작했다. 좋은 쌀을 편하게 살 수 있으니 당연히 가게는 손님으로 북적이게 되었다.

그는 배달 과정을 활용해 손님을 파악했다. 그 집의 쌀독 크기는 어떤지, 식구는 몇 명인지, 식사량이 어느 정도인지, 언제쯤 쌀이 떨어질 것인지…. 그리고 그 때가 되면 미리 알아서 배달을 했다. 사업이 크게 확장된 후에도 그의 세심함은 계속된다.
그의 말이다. “나는 거시적인 부분에도 관심을 가지지만, 세부적인 관리에 더 심혈을 기울입니다. 세부적인 것을 연구하고 개선하여 2명이 할 일을 1명이 할 수 있으면 생산력이 2배가 늘어나는 셈이고, 한 사람이 2대의 기계를 작동할 수 있다면 생산력이 4배가 되는 것 아니겠습니까?”

요리의 지존 중국에서 토종기업 룽화지가 KFC에 밀린 이유도 디테일에서 뒤졌기 때문이다. 룽화지는 KFC가 가는 곳이면 룽화지도 간다는 캐치프레이즈를 내걸고 선전포고를 했다. 처음에는 제법 선전을 했는데 어느 순간 무너지기 시작해 사업 6년 만에 종지부를 찍었다. 도대체 이유가 무엇일까. 룽화지를 만든 신야그룹의 분석결과이다.

“경쟁에서 제품은 전제 조건일 뿐이다. 실제는 관리기술에서 승패가 결정된다. KFC의 경쟁력은 제품을 둘러싼 엄격한 관리제도에 있다. 전략이 매우 상세하고 구체적이며 세계 어느 매장에서나 동일하게 적용되고 있다. 원료입고, 제품생산, 서비스에 이르는 모든 과정에 엄격한 품질기준을 적용한다. 하지만 우리는 이를 실천하지 못했다. 위생상태와 서비스 질도 떨어졌다. 고객이 보는 앞에서 파리채로 파리를 잡고, 볶음밥과 프라이드 치킨도 뚜껑을 덮지 않은 채 진열대에 놓고 팔았다. 우리는 관리에서 그들에게 진 것이다.”

디테일의 중요성은 아무리 강조해도 지나치지 않는다. 노자도 비슷한 말을 했다. “큰 나라를 다스리는 것은 작은 물고기를 요리하듯 해야 한다. 양념과 불의 세기가 적당해야 한다. 초조한 마음에 물고기를 자주 뒤집으면 살이 모두 부서지고 만다. 세심함과 신중함이 필수적이다.”

20세기 최고의 건축가로 손꼽히는 독일의 미스반 데어 로에도 비슷하다. “신은 언제나 디테일 속에 있다. 아무리 거대한 규모의 설계라도 디테일한 부분이 잘못되면 좋은 작품이 될 수 없다.” 원자바오 총리도 비슷하다. “중국에는 13억의 인구가 있습니다. 아무리 작은 문제라도 13억을 곱하면 아주 커다란 문제가 됩니다.”

멋진 비전만으로는 꿈을 이룰 수 없다. 그 꿈을 이루기 위해서는 수없이 세세한 일을 생각하고 챙길 줄 알아야 한다. 아니 그것이 비전보다 오히려 더 중요할 수 있다.

서울과학종합대학원 교수

찰스 시모니
– 프로그래밍의 제 1단계는 상상력을 발휘하는 것입니다. 그리고 나서 머릿속에서 구체화 시키는 것입니다. 그 다음 단계에서는 종이와 연필을 사용합니다. 낙서하기 위해서지요. 아직 코드는 쓰지 않습니다. 박스와 화살표는 몇개나 그렸는지 모르지만, 그건 대부분이 정말 낙서입니다. 진짜 설계도는 머릿속에 있으니까요. 머릿속에서 구조를 구성하는게 좋습니다. 코드화 하고 싶다고 생각하는 실물의 상징이 구조를 말이에요. 머릿속에서 구조가 명확해지면 그 때 코드 작성에 착수합니다.

존 워녹
– 무슨일을 하더라도 충분히 생각합니다. 무슨 일을 할 때 버려야 할 것은 과감하게 버립니다. 재미 없는 책을 읽을 때처럼 코드도 주저하지 않고 휴지통에 버릴 수 있는 용기가 프로그래머에게는 필요합니다. 한 가지 생각에만 너무 집착하지 말고, 필요하다면 버리고 가는 것. 프로그래머의 자세란 그래야 합니다. 그리고 자시만 알고 있다고 생각하면 곤란합니다. 머리가 더 좋은 사람도 얼마든지 있으니까요. 갑자기 누군가가 나타나서 자신보다 뛰어난 알고리즘을 만들어 낸다든가 더 간단한 방법을 생각해 낼 수도 있죠. 이 장사의 비결은 말이죠 정보를 보다 빠르게 입수하는 겁니다. 다른 사람의 아이디어는 뭐든지 즉각 입수해야 합니다. 그리고 그걸 자기 나름대로 실행할 때는 <내 발명이 아니다>라는 사실 따위는 신경 쓰지 말고 그걸 활용해야 한다는 것입니다.

– 우수한 컴퓨터 프로그래머가 되는 비결은 프로그램끼리 조합하는 방법에 달려 있습니다.

게리 킬달
– 코멘트는 좀처럼 쓰지 않습니다. 절차상 첫 부분, 그것도 데이터 구조에 관한 설명문만 쓸 뿐 코드, 그 자체에 대한 코멘트는 붙이지 않습니다. 적당한 방법으로 만들어진 코드는 알기 쉬울 테니까요.

– 프로그래머로서 자기 자신만의 스타일을 만들기 위해서는 다른 사람의 작품을 연구해야 합니다. 문제 해결에 접근하는 방법이나 사용하고 있는 툴 등을 연구하면 자기 자신의 작품을 새로운 눈으로 볼 수 있게 됩니다.

빌 게이츠
– 당장 코딩부터 시작하는 사람이 있는가 하면 차분하게 앉아서 충분히 생각한 다음에 시작하는 사람도 있습니다만, 그 차이는 메모 노트가 있느냐 없느냐 하는 차이일 뿐입니다. 그것보다 중요한 것은 그 사람의 머릿속에 떠오른 내용입니다. 우리가 알고 있는 탁월한 프로그래머들은 차를 운전하고 있을 때나 음식을 먹을때나 항상 프로그램에 대해 생각합니다. 그러려면 대단한 정신력이 필요하죠

– 설계 단계에서 우선 프로그램 전체를 개략적으로 생각한 다음에 자리잡고 코드를 작성합니다. 코드 작성이 모두 끝난 다음에는 다시 처음으로 되돌아가서 다시 한번 전체를 검토합니다. 프로그램을 작성할 때 가장 중요한 점은 데이타 구조의 설계입니다. 두번째로 중요한것은 다양한 코드를 분류하는 일입니다. 그것들을 완벽하게 하지 않고는 공통의 서브루틴을 어느 것으로 해야 할지 예리한 감각이 길러지지 않기 때문입니다.

– 처음 3, 4년만 지나면 좋은 프로그래머인지가 아닌지가 분명히 가려집니다.

– 프로그래밍의 능력을 시험하는 가장 좋은 방법은 프로그래머에게 30페이지의 코드를 건네 주고 그가 어느 정도 속도로 그것을 읽어 내고 어느 정도 이해할 수 있는지를 조사해 보는 것이라고 생각합니다.

– 프로그래밍은 재능입니다. IQ와 같은 것이겟지요 코드를 읽을 때는 자신의 프로그램 경험을 바탕으로 코드에 온 신경을 집중 시킵니다. 보통 사람들은 이렇게 말하겟지요 ‘이것을 읽으려면 며칠 밤이 필요합니다.’ 하지만 정말로 우수한 프로그래머라면 이렇게 말하겠지요 ‘집에 가지고 가서 오늘밤 한시간만 집중해서 전부 훑어보겠습니다.’ 그 능력의 차이는 굉장히 큰 겁니다.

– 프로그래머가 되기위한 가장좋은 방법은 실제로 직접 프로그램을 작성해보는 것이고 다음은 다른 사람이 작성한 프로그램을 연구하는 것입니다.

– 자발적으로 자신의 프로그램을 세계의 탑 클라스 프로그래들에게 자신의 프로그램이 어디가 틀렸는지 묻지 않으면 안됩니다. 그리고 피드백을 얻을때는 조금이 나마 자신의 특이성을 집어 넣어야 합니다.

– 퍼스널 컴퓨터 방면에 정말로 관심을 갖고 있는 사람이라면 그러한 제품을 모조리 사용해 볼 것이라고 생각됩니다. 그러다 보면 그러한 제품을 모조리 사용해 볼 것이라고 생각됩니다. 그러다 보면 그 패키지보다 더 좋은 제품을 만들어 낼 수 있죠.

C. 웨인 래틀리프
– 프로그램의 UI등의 디자인시에 직관적으로 뒤로 물러서서 ‘사용자는 무엇을 원하고 있는가, 이것을 어떻게 이용하려고 할 것인가, 그것은 어떠한 이익을 줄 수 있을 것인가’ 에 대해 생각합니다. 어떻게 하면 최고의 프로그램을 만들까 하는 생각에만 골몰하게 되면 현실적인 시장이라는 관점이 머리에서 빠지게 되지요

– 이상적인 모듈을 만들고자 한다면 1페이정도의 길이로 만들어야 됩니다. 만약 1페이지가 넘을 것 같으면 다시 생각해야 합니다. 여기에서 하려는 것이 과연 무엇이었을까, 그것을 따로따로의 모듈로 분해하는 쪽이 좋을 것인가 등을 말입니다.

– 코멘트가 필요하다고 하다는 것은 프로그램이 명확하지 못하며 어딘가 이상한 부분이 있기 때문이라고 생각합니다. 코멘트가 필요하지 않는 프로그램이 좋은 프로그램이지요 프로그램은 그 자체가 코멘트여야 합니다.

– 각 모듈은 비교적 작아야 합니다 만일 1페이지를 초과하면 어딘가 이상한것입니다. 물론 각 모듈에 한 줄 정도의 코멘트가 필요한 것은 확실합니다.

– <의욕>만 있다면 프로그램은 좀 더 쉬워집니다. <의욕>이 없다면 아무리 덤벼도 어렵죠, 아마도 환멸을 느끼는 것으로 끝날지도 모릅니다. 한마디로 말하자면 <자신이 정말로 하고 싶은 것을 하십시오>라고 말해주고 싶습니다.

– 디버깅이나 디자인이라든가 그 밖의 여러가지 분야에서 달인도 얼마든지 있습니다. 저는 그들에게 배우며, 경쟁하는 것이 좋습니다.

조나단 삭스
– 정해진 코멘트 스타일은 한가지 있습니다. 대개의 경우 프로그램을 꽤 작은 모듈로 분해해서 그 모듈과 입,출력에 관한 내용으로 다량의 코멘트를 다는 것이지요 코멘트는 그것 만합니다. 각 모듈의 내부 구조 까지 자세하게 적는것은 의미가 없으니까요 코드는 다른 프로그래머가 보고도 한눈에 알아볼 수 잇게 되어 있습니다.

– 적절한 인텐테이션이 매우 중요하다고 생각합니다. 그리고 나서 변수에는 가장 적절한 이름을 붙이는 겁니다. 정말로 정확하게 잘 짜여진 프로그램에는 일종의 간결함과 조화가 있습니다.

레이 오지이
– 프로그램을 만들때는 치밀한 구조를 중요하게 생각합니다. 모순 없이 깔끔하게 만들죠 그리고 모듈방식을 많이 써서 각 부분을 층층이 겹쳐 쌓아 넣고 화일과 디렉토리 번호는 자유자재로 씁니다.

– 프로그램 하나를 여러 사람이 만들 때는 프로젝트 초기 단계에서 전체적인 에러 처리 방법, 개개인의 의견에 대한 검토, 서브 루틴의 이름 등을 미리 정해 두는 것이 중요합니다. 간혹 이런 일을 싫어하는 사람들도 있지만 명령어 쓰는 법, 브레스 사용법, 인텐테이션하는 법 등을 반드시 지시해 두어야 합니다.

– 프로젝트의 착상은 대부분이 끊임없는 모방과 개성을 통해 만들어집니다.

– 젊은 프로그래머들 중에는 시간을 잘못 계산하기가 일쑤거든요 하지만 경험이 쌓이면 자신의 습관이나 그때 그때의 마음가짐을 기초로 해서, 독자적인 <시간 계산>을 정확하게 할 수 있게 됩니다.

– 여러가지 경험이 쌓인 프로그래머와 일을 하고 싶습니다. 경험이 충분하다는 말은 여러 가지 일을 해봤다는 뜻이지요 즉 대학을 졸업해서 1, 2년 동안은 한눈 안팔고 어떤일을 해본후 컴퓨터공학내에서도 전혀 다른 분야로 옮겨 다니는 것이 좋다고 생각합니다.

– 사용자가 필요로 하는 프로그램을 개발할 때는 제품의 예상 구매자에 대한 프로필을 작성합니다. 그 다음 모든 사용자의 몇 퍼센트가 각각의 기능을 이용할지 예측합니다. 그렇게 하면 어떤 기능이 가장 많이 이용될지 예측할 수 있기 때문이지요.

– ‘만일 나는 프로그래밍에 빠져 헤어날 수 없다. 어쩔 수 없이 프로그램을 쓸 수 밖에 없다라는 사람이 있다면 마음을 편히 가지십시오 가능한 많은 프로그램을 작성하십시오. 그리고 가능한 여러 가지 프로젝트에 관계 하십시오. 또한 많은 시간 동안 컴퓨터를 사용하십시오. 그러나 자신의 체력 한계를 정확히 판단할 수 있어야 합니다. 그리고 사람들로부터 이상한 놈이라는 소리를 들어도 신경 쓰지 마십시오.

앤디 헤르츠펠드
– 기술자와 예술가의 역활을 동시에 할 수 있는 일은 프로그래밍 이외에는 없다고 생각합니다.

– 매년 새로운 언어를 최소 하나는 배워라.
다른 언어는 동일한 문제를 다르게 푼다. 몇 개의 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데에 도움이 된다. 게다가 지금은 인터넷에서 무료 소프트웨어를 다수 구할 수 있기 때문에 많은 언어를 배우는 것이 훨씬 쉬워졌다.

– 기술 서적을 분기마다 한 권씩 읽어라.
서점에 가면 현재 프로젝트와 관련있는 흥미로운 주제의 기술 서적이 넘쳐난다. 습관이 들면, 한 달에 한 권씩 읽어라. 현재 사용하는 기술을 일단 완전히 익혔다면, 가지치기를 해서 지금 하는 프로젝트와 관련 없는 분야까지 공부 범위를 넓혀라.

– 비 기술 서적도 읽어라.
컴퓨터를 사용하는 것은 사람 – 우리는 바로 이 사람들을 만족시키려고 노력하고 있다 – 이라는 점을 기억하는 게 중요하다. 방정식에서 인간이라는 변을 잊지 마라.

– 수업을 들어라.
근처의 대학, 혹은 시사회에서 열리는 흥미로운 강좌를 찾아보라.

– 지역 사용자 모임에 참여하라.
가서 가만히 듣고만 오지 말고, 적극 참여하라. 고립은 경력에 치명적일 수 있다. 여러분 회사 밖에서는 사람들이 어떤 일을 하는지 알아보라.

– 다른 환경에서 실험해보라.
윈도우에서만 일을 해 왔다면, 집에서는 유닉스를 갖고 놀아보라(공짜 리눅스가 이 경우 안성맞춤이다.) 만약 makefile과 에디터만 사용하고 있다면 IDE를 시도해보라. 반대인 경우도 마찬가지다.

– 요즘 흐름을 놓치지 마라.
업계의 잡지와 기타 저널을 구독하라. 여러분의 현재 프로젝트와 다른 기술을 다루는 것도 몇 개 선택하라.

– 인터넷을 이용하라.
새 언어 혹은 기타 기술에 대해 속속들이 알고 싶은가? 다른 사람이 그에 관해 어떤 경험을 했는지, 그들이 사용하는 특별한 전문용어가 어떤 뜻인지 등을 알아내는 데에는 뉴스그룹이 탁월하다. 논문, 상업 사이트 기타 여러분이 찾는 정보의 원천을 찾기 위해 웹 서핑을 하라.