자신의 프로그램에 목숨을 걸 수 있습니까
오픈마루에서 대학생 인턴 구인을 성공적으로 마쳤습니다(전에 말씀드렸듯이 저는 그 과정을 도와드리는 컨설팅을 했습니다).

오늘은 테스트 엔지니어 오디션에 대해 말씀드리겠습니다. 기획 인턴 오디션은 이미 설명을 드렸죠.

대학생 인턴이기 때문에 테스트 전문지식과 경험이 있을 것이라 기대하지 않았습니다. 그래서 초점도 그런 지식과 경험이 있느냐에 맞추지 않았죠. 그렇다면 결국 자질과 잠재성이 있는가를 봐야 합니다. 쉽지 않죠.

우선 전화면접이나, 면대면 면접을 통해 대화로 알 수 있는 것들은 다 했습니다. 행동 설명 질문을 많이 이용했죠. 하지만 여전히 대화로만은 알아내기 어려운 것들이 있습니다. 특히 그 사람의 잠재성을 알고 싶을 때는 말이죠.

테스트 엔지니어 오디션에서는 기획 인턴의 오디션과 비슷하게 후보의 학습 과정을 보기로 했습니다. 문제를 주고 그 문제를 해결해 나가는 과정, 그 사고의 과정을 보고 또 옆에서 면접관들이 도와주면서 그 도움을 통해 어떻게 스스로 길을 찾아 나가는지 보았습니다.

주어진 문제 상황은 다음과 같습니다.

리스트는 유한개의 원소가 정해진 순서로 들어가 있는 자료구조입니다. 리스트에 포함된 원소는 하나의 숫자일수도 있지만 또다른 리스트일수도 있습니다. 이렇게 리스트 속에 리스트가 들어 있는 것을 중첩 리스트(nested list)라고 합시다.

리스트를 격자괄호로 둘러싸고, 각 원소는 쉼표로 구분해 표기하도록 하죠. 다음은 중첩 리스트의 예입니다.

[1, 2, [3, 4, [5]], 6, [[7,8]]]

예를 들어, 이런 리스트가 주어져 있을 때, 그걸 평평하게 만들어주는 프로그램 F를 작성해야 합니다.

즉, 결과가 [1, 2, 3, 4, 5, 6, 7, 8]로 나오면 됩니다.

그런데 몇 가지 조건이 더 주어집니다. 자신은 예컨대 2시간 후에 수술을 받아야 합니다. 그때 사용하는 수술 기계에 이 프로그램이 중요한 역할을 하게 됩니다. 자신이 직접 작성한 프로그램으로 수술을 받는 것입니다. 프로그램이 오작동하면 자신은 죽을 수도 있습니다.

이 프로그램이 정상작동한다는 것을 최대한 보장하기 위해 프로그래밍 전, 프로그래밍 중, 프로그래밍 후 각각의 시기에 어떤 일을 하시겠습니까? (프로그램 F를 작성하는 것이 이 오디션의 목표는 아닙니다 -- 따라서 오디션 중에 그 프로그램을 작성할 필요까지는 없습니다)
이렇게 설명을 해주고, 필요하다면 종이와 펜을 쓰도록 했습니다. 또, 후보가 오디션을 진행하다가 기타 조건에 대해 질문을 하면 몇가지를 즉석에서 알려주기도 했습니다. 예를 들어, 숫자는 몇 개나 들어오나요라는 질문에는 최대 1만개라고 이야기를 해주었습니다. 또 어떤 후보에게는 하드웨어나 OS는 안심해도 된다고 말해주기도 했죠. 시간은 대략 20분 정도 드렸습니다.

"여러가지 테스트를 해봐야 하겠죠"라고 간단하게 대답하는 경우, 저희가 물어봅니다. "어떤 테스트들을 해보시겠어요?" 몇가지 예를 들어 후보가 대답을 합니다. 그러면 저희는 다시 묻습니다. "이제 자신이 수술을 받아도 될 만큼 안심하시겠습니까? 충분한가요?" 십중팔구 스스로 "아니요"라는 대답을 합니다. 이런식으로 오디션이 계속됩니다.

자신이 작성한 프로그램에 자신의 목숨을 맡길 수 있겠습니까(이런식으로 자기가 만든 걸 직접 사용하는 것을 Eat one's own dog food라고 합니다)? 만약 그런 상황이 벌어진다면 최대한 당신의 목숨을 보장하기 위해 어떤 행동을 하시겠습니까? 상당히 도전적이고 흥미로운 문제입니다. 면접관들에게도 절대 쉬운 문제는 아닙니다. 정답이 있는 것도 아니고요. 하지만 저는 이 질문이 상당히 강력한 질문(앨런 케이가 powerful idea를 말하는데 제가 보기에는 powerful question들도 있습니다, 예를 들면 켄트 벡이 말한, 이게 네 돈이면 어쩔래?도 그런 종류이죠)이며, 분야를 막론하고 프로그래머라면 한 번 쯤은 이런 문제를 고민해 보아야 한다고 생각합니다. 절대 달성할 수는 없더라도 끊임없이 자문해야 하며, 그 과정 중에 얻는 것이 많습니다.

후보가 이 문제를 해결해 나가는 동안 역시 소리내어 생각하기(think-aloud)를 하도록 유도했고, 막다른 길목에 막혀서 진전이 없으면 저희가 힌트를 주기도 했습니다(주로 소크라테스적인 질문을 하려고 노력했죠).

이 오디션이 우리가 대화에서 발견하지 못했던 것을 찾아내는 데에 큰 도움이 되었습니다. 그리고 오디션 진행 중 저는 항상 '어떻게 해야 이 사람이 갖고 있는 내면의 잠재력과 재능을 끌어내서 이 문제 해결에 도움이 되게 할 수 있을까?'를 고민하고 또 노력했습니다. 처음에 방향을 잡지 못하던 분이 나중에 나름대로 진전을 보였을 때는 저도 무척 기뻤습니다.

여러분은 정말 2시간 후 자신이 작성한 프로그램으로 수술을 받아야 하는 상황에 빠진다면 어떻게 하시겠습니까? (무서운 영화4에서 쏘우2 패러디하던 게 떠오르네요)

--김창준
by 애자일컨설팅 | 2007/01/11 23:24 | 트랙백(7) | 핑백(4) | 덧글(27)
트랙백 주소 : http://agile.egloos.com/tb/2970034
☞ 내 이글루에 이 글과 관련된 글 쓰기 (트랙백 보내기) [도움말]
Tracked from [1002] at 2007/01/12 08:24

제목 : 자신의 프로그램에 목숨을 걸어야 한다면..
자신의 프로그램에 목숨을 걸 수 있습니까 그런데 몇 가지 조건이 더 주어집니다. 자신은 예컨대 2시간 후에 수술을 받아야 합니다. 그때 사용하는 수술 기계에 이 프로그램이 중요한 역할을 하게 됩니다. 자신이 직접 작성한 프로그램으로 수술을 받는 것입니다. 프로그램이 오작동하면 자신은 죽을 수도 있습니다. 이 프로그램이 정상작동한다는 것을 최대한 보장하기 위해 프로그래밍 전, 프로그래밍 중, 프로그래밍 후 각......more

Tracked from jeddli님의 블로그 at 2007/01/12 10:37

제목 : 자신의 프로그램에 목숨을 걸 수 있습니까 ?
제목숨을 제 자신에게만 맡기기에 저자신을 못믿을것 같습니다. ^^; 첫 번째 떠오르는 생각은 이런 형식이 시도된 적이나 있는 지 모르겠지만 "그룹 프로그래밍" 이런건 어떨까요? 정말 신뢰할수 있는 동료 4~5명과 같이 하나의 모니터를 보며 프로그래밍을 하는겁니다. 그리고 더해서 전세계 생중계... 이런 환경에서 제대로 프로그래밍을 자신있게 해나갈수 있을지 의문이지만 목숨이 달린일이니 코딩 한줄한줄에 자존심을 내세......more

Tracked from AhaBlog at 2007/01/15 10:39

제목 : 내 생명을 위하야 개밥을 먹자
애자일 이야기 블로그의 자신의 프로그램에 목숨을 걸 수 있습니까라는 포스팅을 읽고 재미삼아 나도 한번 :-)----프로그램 전 입력값은 신뢰할 수 있는가? 괄호 쌍이 맞는가? Comma의 위치는 정확한가? 리스트의 원소가 모두 숫자여야 하는가? 수행시간은 얼마나 빨라야 하는가? 계산에 시간이 걸리면 죽을 수도 있으니까..프로그램 중 최대한 빨리 끝내버린다.프로그램 후 캐슁데이터를 쌓아가면서 실수한 것이 있는지 계속 검증한다.----# 간단 Pe......more

Tracked from 사가의 잼있는세상 at 2007/01/17 18:50

제목 : 자신이 짠 프로그램에 자신의 목숨을 맞길수 있을까요?
"자신이 짠 프로그램에 자신의 목숨을 맞길수 있을까요?" 란 질문에 선듯 네... 라고 말할실수 있는 분 과연 얼마나 될까요?나또한 프로그래머 이지만 내가짠 프로그램을 신뢰하는 경우는 거의 없습니다. 아니한 80% 없었던거 같습니다.. 다만 내가 짠 프로그램이지만 테스트에 테스트를 해서 결국 오류없다고 판단이 되더라도.... 하지만 이런생각은 일반적으로 컴퓨터 프로그램쪽에 일을 하시는 어떤 분들도 같은 마음일 것이라 생각 합니다.. 프로그램을 ......more

Tracked from 게으른 개발자의 일상 at 2007/01/22 16:17

제목 : 자신의 프로그램에 목숨을 걸 수 있느냐...
자신의 프로그램에 목숨을 걸 수 있습니까 트랙백으로는 처음 글을 써보는데, 이제 4학년이고 곧 졸업과 면접, 취업등을 준비해야 하는 나에게 흥미로운 글이다. '나는 내가 짠 프로그램에 목숨을 걸 수 있을까?' 일단 답을 내자면 주어진 시간동안 최선을 다하겠지만 지금 실력 으로서는 그 시간동안 최선을 다한다고 해도 단언하고 목숨을 걸 수 있다고 말할 수 는 없을것이다. 프로그램을 짤 때, 나름대로 미리 구상도......more

Tracked from 겐도사마의 재림 at 2007/02/07 18:24

제목 : 자신의 목숨이 걸린 프로그램
http://agile.egloos.com/2970034테스팅에 관련된 글중 최근에 많이 회자되었던 글입니다. 두시간 후에 수술에 사용될 프로그램에 대한 테스트 플랜을 작성하라는 내용입니다. 수술 대상은 바로 자신입니다. 안정성을 검토하는 테스트 자체에 대한 검증문제죠.만약 저에게 이런 문제가 주어진다면 저는 이렇게 답할지 모릅니다. 그냥 두시간 남은 인생 밖에서 놀다 오렵니다.너무 무책임한가요?제가 소프트웨어를 개발함에 가지는 기초적인 관념중......more

Tracked from humbroll's t.. at 2007/05/16 14:22

제목 : 자신의 프로그램에 목숨을 걸 수 있습니까
자신의 프로그램에 목숨을 걸 수 있습니까 Agile 이야기라는 블로그에 오픈마루의 대학성 인턴 면접시에 했던 질문에 대한 글이 있었다. 과거에도 한번 읽어본적은 있었으나, 그것에 대한 구체적인 나의 대답은 길게 생각해보지 않은 passive한 태도를 취했지만, 머지 않아 입사면접을 치뤄야 할 나에게는 이제 더이상 지나칠 수가 없다. 그래서 진지하고 담담하게 나의 생각을 떠올려보았다. 2시간을 생각한건 아니지만, 나름 신중한 생각을 해보았다. 문......more

Linked at 유승근 » Blo.. at 2007/08/09 00:10

... 수 있지? 그 회사에서 판단은 어떻게 할지? 내가 해야 할일은 무엇인지? 내가 할 수 있는 일들은 무엇인지? 등등 이런 것들이 가장 고민입니다. 자신의 프로그램에 목숨을 걸 수 있습니까 라는 포스트를 읽었습니다. 과연 나라면 어떻게 생각했을까? 어떻게 대답했을까? 내 대답이 상대에게 만족할 만한 것일까? 애자일 이야기에는 정말 ... more

Linked at 승렬님의 기록장-.- : 리쿠.. at 2008/02/20 19:56

... 얻지는 못했다.기술력이 아닌, 위기 대처 능력과 학습 능력을 기준으로 다섯가지 정도의 질문을 준비했는데, 마지막에 했던 질문은 애자일컨설팅의 김창준님 블로그에서 본 "자신의 프로그램에 목숨을 걸 수 있습니까" 였다.뭐.. 다른건 다 괜찮았다.... 한분이 기억나는데... 저 질문에,"주위에 잘 하시는 분이 있는데, 전화해서 물어볼 것 같습니다." 라고 대 ... more

Linked at 애자일 이야기 : 성공적인 채.. at 2010/07/15 19:49

... 년 전부터 소프트웨어 개발 회사의 채용 컨설팅도 함께 해오고 있습니다. 제 블로그에 관련 글을 몇 번 썼지요. 인터뷰에서 진실을 들으려면전화면접과 오디션자신의 프로그램에 목숨을 걸 수 있습니까오늘은 채용 면접 관련하여 가장 기본적이면서 중요한 이야기를 해볼까 합니다. 위 글 중 "인터뷰에서 진실을 들으려면"과 연결되는 부분이 많으니 먼 ... more

Linked at 진눈깨비님의 이글루 : 애자일.. at 2011/08/08 11:22

... ://agile.egloos.com/3689158http://agile.egloos.com/3595396http://agile.egloos.com/2973245http://agile.egloos.com/2970034http://agile.egloos.com/2950590http://agile.egloos.com/2920765http://agile.egloos.com ... more

Commented by TayCleed at 2007/01/12 00:07
저라면 일단 가장 먼저 프로그램 구상을 "간단하게" 하려고 애쓰겠네요. 복잡한 프로그램은 버그를 야기하니까요. 간단하게 만들수록 버그는 줄어들 것이고, 오작동 여지도 내칠 수 있겠죠. 입력값, 출력값 등의 범위를 명확히 합니다.

흐음.. 프로그래밍 중일 때는 그냥 프로그래밍 자체에만 집중하는 지라 'ㅅ'.. 하하. 프로그래밍 후에는 테스트 해봐야죠. 일반적인 값부터 넣어보고, 터무니 없어보이는 입력도 해봅니다.
Commented by 제임스 at 2007/01/12 00:36
오... 그런 상황에 빠지는 것을 상상만 해도 끔찍한데요.
게다가 목숨을 거는 일이라면, 열심히 기도를 할것 같습니다.

사실 제목을 보고, 이런 생각이 언뜻 떠올라서 리플을 오랜만에 달아봅니다.
합격한 대학생 인턴이 이 글을 보면 어떤 생각이 들까 하고 말이죠.
왠지 '자신의 프로그램에 목숨을 걸 수 있습니까' 하는 질문이 recursion같이 들려서요.

항상, 김창준님의 신선한 아이디어 감사드립니다.
Commented by 도닥붕 at 2007/01/12 01:02

검증되지 않은 프로그램을 수술에 이용하는 병원이나 의사는 없을 것이므로 무효라고 대답하면 안되겠죠? 'ㅂ'

Commented by 카페모카 at 2007/01/12 01:19
1.
깊이가 1단계까지만 나열하는 매서드를 정의하고, 이 매서드를 재귀적으로 사용할겁니다.

2.
전 - 인터페이스를 찾는다.
중 - 구현한다. 단, 인터페이스간 데이터만 공유한다. 로직은 공유하지 않는다. (최소한의 피해.. 거의 모든 인터페이스가 오작동을 한다면 모를까..)
후 - 인터페이스를 확인해본다.
Commented by 졸리 at 2007/01/12 03:06
저라면, 이 프로그램이 오동작을 하지 않도록 노력하기 보다는 이 프로그램이 오동작을 해도 제가 살수 있는 방법을 찾아 보겠습니다. 중첩 리스트를 펼치는 프로그램이 오동작을 한다고 해서 제 목숨이 간당간당 한다는건 너무 억울하지 않을까요? ^^; 즉, 이런 상황 자체를 바꾸려고 노력하는 것이 이상적이다.
Commented by at 2007/01/12 03:40
일단은 가능한 테스트할 필요가 적은 코드를 짜겠죠. 저같으면 일단 API 레퍼런스를 뒤져서 있는 걸 쓰겠습니다. 구현을 한다면 하스켈로 아래처럼 (자세한 설명은 http://functional.or.kr/node/109 )

flatten lst = map read $ words $ map (x -> if elem x "0123456789" then x else ' ') lst :: [Integer]
Commented by picxenk at 2007/01/12 10:54
2시간이란 시간이 참 짧군요. (저는 문제상황을 보면서 숨을 헐떡이고 있을거구요.. 헉.. 헉.. )
프로그래밍 전에는 우선 가장 "안전"하고 "명확"한 언어를 찾으려고 노력을 하겠어요.
그리고 주어진 문제 상황을 만족하는 가장 작은 셋 N을 풀고 검증하는 간단한 도구를 만들어야겠어요.
그 도구를 사용해서 N+1, N+2를 풀어나가보구요, 시간이 너무 촉박해지면 2N, 4N, 8N...으로 풀어나가면서 검증해보겠어요.
죄송하지만 프로그래밍 후라는 시간은 없을거 같아요. 2시간이 지나면 수술을 받겠어요.
아.. 그리고 수술 받기 전에 유서 비슷하게 지금까지 했던 작업 내용을 간단히 글로 남길래요.
혹 내가 죽으면 다른 사람이 다시 이어서 하라구요. :)
Commented by 애자일컨설팅 at 2007/01/12 10:57
[picxenk에게]
> 혹 내가 죽으면 다른 사람이 다시 이어서 하라구요. :)

감동적이다. 아주아주 중요한 부분이다. Grady Booch의 Handbook of Software Architecture가 생각나네. (http://www.booch.com/architecture/index.jsp )
Commented by 즐거운인생 at 2007/01/12 11:12
Perl을 이용하면 프로그램 F는 정말 간단해요 ^^
Commented by Jooni at 2007/01/12 11:31
picxenk님의 답변이 정말 뭔가를 느끼게 하는 것 같습니다.
Commented by 가짜집시 at 2007/01/12 12:47
recursion을 사용하고 싶은 욕망이 불끈- 솟아오릅니다만 문제는 10000 개 데이터가 최악의 경우 함수 호출을 10000 번 하게 만들 수도 있다는 거로군요. recursion을 써서 안심이 되려면 중첩이 몇 단계까지 포함되는지도 알아야겠습니다. 보장 안되면 recursion 을 쓰지 않는 로직을 만들어야 하는데 기계적으로 stack 을 써서 구현하는게 어떻게 하는 거였더라... 아무튼 한 10분 생각해보면 대충 로직은 나올듯. 나머지는 종이에 대충 그려서 로직을 확인해보고, 대충 빨간불과 파란불 사이를 왔다 갔다 하면서 테스팅과 코딩을 함께 진행하고- boundary condition 과 test 가능한 범위 내에서 충분히 큰 데이터들까지 처리할 수 있는지 보고, 담배 한 대 피우러 가는 거죠 뭐.
Commented by Kidd™ at 2007/01/12 15:06
먼저 사랑하는 사람에게 전화를 걸고 시작하겠습니다. 코딩이 끝나면 다시 전화를 걸어서 저녁약속을 잡을겁니다.
Commented by 낭망백수 at 2007/01/13 01:15
소스에 대한 태도나 코딩에 대한 마음자세를 짚는다면,
여지껏 내 자신이 만족할 만한 코드를 만들기 위해 늘 애썼다고 말하고 싶습니다.
언제나 자신의 기준에도 못 미치는 코드를 배포해야함에 늘 아쉬웠고,
융통성을 갖고 trade 하지 못하는 것이 오히려 지나치는 경우 팀전체에 악영향을 미치기도 했습니다.

우선 문제가 현실적이지 않습니다.
현실은 늘 많은 조건들과 개발자의 양심을 트레이드 할 줄 아는 경제적 마인드를 요구하고 있습니다.
그래서 저도 현실적이지 않은 답변을 해야겠습니다.

동일한 문제가 제가 주어진다면,
그 즉시 저는 키보드를 창준님이든 누구든지 그 자리에서 가장 신뢰할 만한 분에게 맡길 겁니다.

꾸벅~!
Commented by daybreaker at 2007/01/13 01:31
"혹 내가 죽으면 다른 사람이 이어서 하라구요"라는 부분은... 문서화의 중요성을 뜻하는 것 같기도 하군요.
아무리 코드를 잘 짰고 무결하다 할지라도 어떤 목적의 코드인지 모르면 말짱 헛것이니..

일단 저라면 입력값의 범위와 길이, 그리고 프로그램이 처리하는 데 걸리는 시간에 얼마나 제한이 있는지 등을 따져보고 제가 자신 있는 프로그래밍 언어 중 가장 적합한 것을 선택할 겁니다.
또한 입력값에 오류가 있을 경우 예외 처리를 어떻게 해야 하는지도 알아야겠죠. (그 입력 전체를 무시한다든가, 아니면 그 원소만 무시한다든가, 그 sublist만 무시한다든가...)
선조건으로는 먼저 문자열을 한 번 스캐닝하여 입력값의 오류를 검사합니다. 숫자들이 원하는 범위의 값인지, 그리고 괄호 열고 닫기에 문제는 없는지. 그에 따른 예외 처리를 해줍니다.
중첩리스트더라도 실제 표현은 순서대로 1차원에 나타나 있으므로 이제 원소값에 해당하는 token들만 분리하여 배열에 담습니다. (괄호 열고 닫기를 모두 없애고 구분자로 split하는 것이죠)

뭐 떠오르는대로 적어보면 대충 이 정도네요. 어쨌든 수행하기 전에 입력값 형식을 빡세게 검사하고, 구현을 최대한 단순하게 하는 방향으로 갈 겁니다. 마지막엔 원소값들이 정해진 입력값이 맞는지 맞추는 정도면 될라나요. (하드웨어적인 I/O, 메모리 오류라든가 컴파일러나 OS 등 프로그램 외적 요인에 의한 오류는 없다고 가정해야겠죠?)
Commented by 최종욱 at 2007/01/13 15:51
예. 저는 제 코드에 목숨을 걸 수 있습니다. 문제가 너무 간단하잖아요. 제가 사용한 방법은 TDD 입니다. 귀납적 증명법으로 믿는 것이죠. 아래는 결과물 Python 코드입니다. 파이썬 내려받기부터 시작해서 10분 걸렸습니다. (isinstance 함수를 몰랐거든요) 남은 1시간 50분 동안 다른 위험을 제거할 겁니다.

def unpackList(givenList):
_resultList = []
_for item in givenList:
__if isinstance(item, list):
___resultList += unpackList(item)
__else:
___resultList += [item]
_return resultList

#Test:
result = unpackList([1,2,[3,4,[5],6],7,[[8,9]]])
if result == [1,2,3,4,5,6,7,8,9] :
_print "ok"
else:
_print "not ok"
_print result
Commented by 애자일컨설팅 at 2007/01/13 19:08
[최종욱님] TDD와 귀납적 증명법을 사용하신 것은 훌륭합니다(TDD와 귀납적 증명법은 서로 직교적이라고 봅니다 -- TDD만으로 증명이 되지는 않지요). 그런데 남은 1시간 50분 동안 다른 위험을 제거할거라고 하셨는데 어떤 위험들이 있을까요? 사실 오디션에서 프로그램을 직접 작성한 후보는 아무도 없었습니다. 이 오디션의 초점은 자신이 온전히 믿는 프로그램에서 어떻게 숨겨진 약점들을 찾을 수 있나, 그런 체계적 방법을 갖고 있나, 또 그를 통해 어떻게 확신을 강화할 수 있나, 자신이 무의식적으로 했던 가정들을 찾아내고 거기에 도전할 수 있나 등을 보는 것입니다. 작성하신 코드에 어떤 생각하지 못한 위험들이 있을까요?
Commented by 최종욱 at 2007/01/14 11:20
위 코드는 치명적인 오답은 절대 내지 않습니다. 그래서 제 목숨을 걸 수 있습니다.

그와는 별개로 제 코드는 개선할 여지가 분명히 있습니다. 여기서는 재귀를 루프로 풀어내는 최적화가 가장 좋은 방법이라고 생각합니다. 리턴값용 리스트를 단 한 번만 만드므로 메모리가 절약되고, 스택을 직접 관리하여 더욱 믿을 수 있습니다. (VB6는 호출스택 제한이 256이라서 피를 본 경험이 있습니다) 덤으로 리스트를 만드는 횟수를 줄여 실행 속도도 빨라집니다. 이 최적화에 약 30분 정도 걸리리라 예상했는데 9분 30초 걸리더군요. 회귀 테스트를 활용했습니다. 코드는 필요하다면 올리겠습니다.

이 밖에도 제가 생각하지 못한 위험을 확인하기 위해서 저는 테스트를 강화하거나, 실행환경(파이썬 구현 등)을 확인하거나, 2배의 스트레스 테스트, 실행시간 프로파일링, 메모리 프로파일링을 할 수 있습니다. 단순 루프로 큰 자료를 만들고 측정 도구 몇 개 돌리면 끝인걸요. 길어야 20분이면 끝날겁니다.

다른 사람에게 코드 리뷰나 작성을 요청하거나 조언을 요청하는 방법도 있습니다. 다른 사람의 코드를 베낄 수도 있습니다. 하지만 제 수술을 2시간 안에 받을 때에는 되도록 삼가겠습니다. 믿을 수 있는 제 코드에 비해서 위험과 시간 소모가 큽니다.
Commented by 서지원 at 2007/01/14 15:35
a=[];a.append(a)
unpackList(a)
저렇게 쓸 가능성이 별로 없긴 하지만 목숨을 걸기엔... ^^;
Commented by 최종욱 at 2007/01/14 18:20
서지원님/ 아, 그런 경우가 있었군요. 자칫하면 전 죽었겠습니다 ^^;
Commented by 아폴룬 at 2007/01/17 01:18
목숨을 걸 프로그램을 TDD하다니, 대체 목숨이 몇 개나 -_-
Commented by 김신 at 2007/01/17 17:20
[게스트가 최종욱님께.]
이곳을 오가며 글을 보았지만 처음으로 댓글을 달아 봅니다.
덧글을 읽다가 핀트가 다른 방향인거 같아서 이렇게 글을 답니다.

이것은 해법의 HOW가 아니라 자신의 생각과 실제로 구현되는 코드 간의
오류 침입 가능성을 어떻게 확인하느냐의 문제입니다.

대개 오류가 발생하는 부분은 내가 이해하고 있는 것을 컴퓨터가 이해하도록 만들때 발생합니다.
두뇌와 컴퓨터 CPU 사이에 캐즘이 있다고 할 수 있습니다.

설계를 강화하고 UML로 표현을 한다던지, TDD를 해서 녹색불을 본다던지 하는 모든
행위가 모두 이런 간극을 줄일려는 행위입니다.

이번처럼 간단한 문제이고 2시간이란 제한적인 상황이지만
문제가 휠씬 복잡해지면 위와같이 절대 오류가 없다고 말씀 하실 수 있느냐는 문제입니다.

즉 종욱님께서 적으신 ' 절대' 라는 믿음을 어떤 근거로 믿을 것이냐라고 생각합니다.

아마도 김창준님은 이런 의도에서 마지막에 질문을 던지셨던거 같네요..: )

덧으로, 여러분들의 믿음은 어떤 근거를 기반으로 하고 있나요?
Commented by 최종욱 at 2007/01/17 19:34
김신 / 우선, 전 제 나름대로의 방식으로 코드를 짰습니다. "나는 어째서 믿을 수 있는가?" 에 저는 대답할 수 없습니다. 이건 불확실한 답이 나올 수 밖에 없습니다. 그래서 그 질문을 거꾸로 생각했습니다. "나는 어째서 믿을 수 없는가?"

첫째, 작은 부분을 풀 수 있는지 조차 모릅니다. 둘째, 그걸 풀었다고 해서 전체에 적용할 수 있는지를 모릅니다. 첫째 불신을 없애기 위해서 [1, 2, [3, 4]]와 같은 작은 입력을 시험했습니다. 둘째 불신을 없애기 위해서 더 깊게 만들어 시험했습니다. 그래도 혹시나 싶어서 생각할 수 있는 여러 패턴을 더 넣어 시험했습니다. 나중에는 자동 생성기로 수만개의 자료를 시험했습니다. 모든 결과는 성공적이었습니다. (다만, 깊이 시험에서는 실패하여 결국 루프 버전으로 풀어버렸습니다.)

자신의 불신을 모두 없앴을 때, 저는 다시 한 번 묻습니다. "나는 어째서 믿을 수 없는가?" 분명히 올바른 결과가 나오며, 의심은 없습니다. 그렇다면 전 믿습니다. 나중에 불신이 추가되면, 그것을 또 해결하면 그만입니다.

물론, 그 과정에서 코드를 많이 고치고, 가끔은 뒤엎기도 합니다. 현재의 코드 형태가 중요한 것은 아닙니다. 다만 어떤 형태로든 제대로 돌아가는 코드가 있다는 것이 중요합니다.
Commented by [1002] at 2007/01/18 01:10
저의 경우 믿음에의 근거는 '테스트 셋이 되는 모델이 현실과 얼마만큼 가까운가?' 라는 질문으로 바꾸어질 수 있지 않을까 생각해봅니다. 시간에 구애받지 않고 이상적이면 '나와 똑같은 클론을 만들고 - 상처부위까지 똑같은 - 최종 테스트를 해보고' 수술기계가 클론을 잘 고치면 저도 수술 받을 것 같습니다. 하지만, 이 것이 불가능하기에 테스트 셋에의 모델을 좀 더 간단히, 좀 더 구축하기 쉬운 간이 모델로 만들고 테스트를 해보겠죠. 그대신 좀 더 불안해 할 겁니다.;;
믿음을 수치적으로 표현한다면, 테스트 셋에의 모델과 현실과의 차이값으로 표현되지 않을까 얼핏 상상해봅니다. (여기서의 테스트는 유닛테스트 레벨이 아닌, 최종 수술기계 레벨의 Acceptance Test 를 의미합니다)
Commented by silverbird at 2007/01/23 16:37
최종욱님의 사고 방식은 과학적인 사고 방식이라 할 수 있습니다. 가설을 세우고 그 가설을 뒷받침할 실험결과가 있으면 그것을 법칙이라 인정하는 것입니다.
대부분의 프로그래밍 역시 이런 방법으로 오류를 검증합니다. TDD 역시 이런 방식이겠죠...
어찌보면 대부분의 경우 가장 현실적인 방법인 것 같습니다.
그런데 이 글에서 내세운 조건...내 목숨을 건다...라는 것은 이런 수준을 넘어선 어떤 다른 것을 요구하는 것이라 생각합니다.
현재의 상황에서 오류가 발생하지 않으면 그냥 프로그램을 작동하고 오류가 생기면 고치고...이런 여유를 부릴 수 없습니다.
지금 당장에 올바른 결과가 나오면 의심이 없다...이런 수준이 아니라 정말로 오류가 없다는 증명이 필요하다는 것이죠...수학적인 사고 방식이 필요합니다.

저는 우선 입/출력 형태에 대해 명확하게 정의하는 것에서부터 시작하겠습니다.
자신이 가장 쉽게 구현할 수 있는 형태로 입력값이 들어온다는 보장은 없으니까요...
여기에는 입력값의 타입, 범위(크기) 등이 있을 수 있겠죠. 이렇게 입/출력 형태가 정의가 되면 해당 타입에서 들어올 수 있는 입력 패턴을 찾겠습니다.
이 때 찾은 패턴이 아닌 패턴이나 타입의 입력값에 대해서는 어떤 처리를 해 줄지 정의를 합니다. 프로그램을 도중에 멈출지 혹은 어떤 디폴트 값을 넘겨줄지... (혹은 어떤 동작을 취할지...)

구현에 들어가서는 정의된 입력 패턴에서 필요한 출력값이 나올 수 있도록 각 단계를 찾아 나가야 할텐데 각 단계를 구현할 때마다 증명과정이 반드시 필요할 것입니다.
아마도 side effect가 없는지 여부를 확인해야 할 것 같습니다. 즉, A라는 입력에는 반드시 B라는 출력이 나오는지를 살펴봐야 겠죠...언어적으로 이것을 지원한다면 가장 좋겠고(함수형 언어처럼) 그렇지 않는다면
소스 검증이 필요할 것 같습니다. 각 단계에서 입/출력이 항상 일정하다는 증명이 된다면 전체 단계를 연결하더라도 안심할 수 있지 않을까요? (사실 그래도 수술받을 땐 불안하겠죠...^^)

프로그래밍 후에는...각 입력 패턴에 대해서 테스트를 해보고...누군가 다른 프로그래머가 있고 시간만 충분하다면 소스 검증을 부탁해야겠죠? 원래 사람들은 훈수를 더 잘 두니까요...^^
Commented by 디토 at 2007/01/30 15:10
irb(main):002:0> [1, 2, [3, 4, [5]], 6, [[7,8]]].flatten
=> [1, 2, 3, 4, 5, 6, 7, 8]
Commented by 달룟 at 2007/02/14 19:53
Smalltalk로는...

nestedArray := #(1 2 (3 4 (5)) 6 ((7 8))).
Compiler evaluate: '#(', (nestedArray printString reject: [:ch| '#()' includes: ch] ) , ')'
Commented by 마시멜로 at 2010/04/15 08:26
다음에 문제 내실때는 자기자신의 목숨을 건다는 것 보다는 남의 목숨이 왔다갔다 한다고 문제를 내면 더 강력할 것 같은데요.
아니면 가족이라던가.
실패하면 두사람이 황천길로...
죄책감으로 살수가 없을 테니까요.

:         :

:

비공개 덧글

< 이전페이지 다음페이지 >