아내와 나 같은 컴퓨터 공학을 전공하였지만, 아내는 연구소에 재직하게되면서, 코딩 실무보다는 설계와 관리쪽으로 치중하게 되었습니다. 비록 실무에서 코딩업무와 멀어졌다고는 하지만, 때론 설계가 잘 적용되었는지 코드를 직접 검토하여야 하기때문에, 가끔씩 저와 코드를 가지고 이야기 할때가 있습니다. 그러면 제가 우위에 서게되는 경우가 많았습니다.
그래서인지, 옛기억을 확실히 해야겠다며, 이번에 OOP 프로그램밍 교육을 신청하여 교육을 받기위해 서울에 머물게 되었습니다. 그런데, 첫날부터 아내로 부터 전화가 와서 숙제를 하는데, 이상하게 동작 하는데 도저히 모르겠다는 것이 었습니다.
다음과 같은 C++ standard library를 활용한 성적처리 프로그램인데, 국어점수로 정수인 99점을 입력하면 괜찮은데, 소수점인 99.5를 입력하면 무한 루프에 빠져버린다는 것입니다.
[code] int kor=-1, eng =-1, math =-1; int tmp; int wrong_score=true;
먼저 전체 소스를 살펴보면서 메모리 overflow가 있을만한 부분은 없는지 훓어보습니다. 대략 이상이 없어 보여 도대체 어떻다는 말인가 하고 프로그램을 실행해 보았습니다.
국어 점수 입력이 뜨자 99.5를 입력하고 엔터를 치니 그때부터 빠르게 ' 0 - 100 사이 값을 입력하세요!' 하는 문구가 수없이 화면을 지나가는 것이 보였습니다. 아 이렇다는 말이구나. 이후 국어점수로 일반 정수를 입력하면 이상 없이 잘 되는 것을 확인하였습니다.
물론 아내도 디버깅을 할 줄 압니다. 그렇지만, 고민하던 아내에게서 일단 내게로 공이 넘어왔으니, 나도 국어 점수 입력라인에 Break Point를 찍고 디버깅을 해보았습니다.
디버깅을 해보니 국어 점수로 99.5를 입력하면 99가 kor의 입력값으로 들어왔습니다. 음... int형이니까 .5가 무시된건가?, 그럼 잘 입력받는데 왜 그러지? 하고 다음 스텝들을 진행하였습니다.
그런데, 영어 점수를 입력받기 위한 cin >> eng; 라인에서 프로그램이 콘솔 입력을 대기하지 않고 그냥 지나처 버리는 것이었습니다. 응? eng 값을 보니 초기값인 -1을 유지하고 있었습니다.
일단 최초 의심은 국어점수 입력과정에서 메모리 overflow가 발생한게 아닐까 하는 것이었습니다. 그러나 국어점수를 기억하기위한 배열이나, Index Count등을 점검해 보았지만 이상이 없었습니다. 그래서, 아하 99.5와 같은 입력으로 인해 cin 객체의 상태에 뭔가 문제가 생겼구나 하는 생각에 이르렇습니다.
그렇다면 분명 초기화 하는 명령이 있을것 같은데....(학창 시절 외에 콘솔 프로그램을 거의 하지 않았으니 cin에 대한 기억이 거의 남아 있지 않았습니다.) 찾아보니 clear() 함수가 있었습니다. 영어 점수 입력을 받기 전에 cin.clear()를 호출해 주었습니다. 그러나, 기대와 달리 증상은 똑 같았습니다. 우~~씨!.... MSDN의 cin 도움말을 찾아보며 쓸만한 함수를 찾아보았지만 도움이 될만한 함수가 쉽게 눈에 띄지 않았습니다. 그사이 아내한테 전화가 왔습니다. 해결했냐구?!. 컥! ^^; 어디가 문제가 되는지 알았으니 좀더 기달려 보라고 했습니다.
MSDN의 키워드 검색기 성능이 떨어지는 관계로 결국 혼자 해결하지 못하고 구글을 통해 검색을 해보았습니다. 그리고 다음의 문서로 부터 바로 해답을 업을 수 있었습니다.
cin 객체는 입력값을 변수에 넣는 과정에서 변수의 형에 따라 변수에 입력할 값을 자동으로 취하는데, int 형임으로 99.5 중 99는 취해서 변수 kor에 넣어주고 .5는 버퍼에 남겨둔채, 자신의 상태값을 아직 버퍼에 남은게 있다는 not ok 상태로 표시합니다.
그런데, 영어 점수 입력단계로 넘어가 cin은 buffer에 남은게 있기때문에, 사용자 입력을 기다리지 않고 버퍼에 들어 있는 것을 eng에 입력하는 것을 시도하고 버퍼에 남은 값 .5가 정수가 아니기때문에 eng 값을 본래 값 그대로 둔채 다음으로 진행함으로서, 결국 이게 계속 반복됨으로서 영어 점수 입력 루틴에서 무한 루프에 빠지게 된 것이었습니다.
어떻게 알았는지 아내한테 두번째 전화가 왔고, clear()와 ignore()에 대해 말해 주었습니다. 그랬더니, 맞아 수업시간에 들었었어!. 하는게 아닙니까? ^^;
clear()가 에러 상태값을 ok 상태로 해주는 것이 맞지만, clear()만으로 되지 않았던 것은 cin은 버퍼에 무언가 남아 있으면 더이상 사용자 입력을 받지 않고 버퍼가 빌때까지 변환을 시도하기 때문에. ignore()를 호출하여 강제로 버퍼를 비어주어야 했던 것입니다.
또한 그럼 문제되는것은 영어 점수 루틴이겠네!, 하고 생각할 수 있지만 만약 국어 점수로 숫자를 입력하지 않고 문자열을 입력하게 된다면 국어 점수 입력 while문에서 무한 루프에 빠져버리게 됩니다.
그래서 저는 코드를 다음과 같이 바꾸어 아내에게 전해 주었습니다. 이미 아내는 해결했다 했지만, 내 예외 처리가 마음에 들면 이걸 쓰라구 전해 주었습니다.(^^; 뭐가 이리 복잡하냐며 싫탭니다.) [code] int kor=-1, eng =-1, math =-1; int tmp; int wrong_score=true;
저의 주관적인 의견으로는 경험적 지식이 근본 이론보다 훨씬 중요하고 유용한 경우가 실생활에서 많이 존재한다고 생각합니다. 아니 거의 모든 실무에서 경험적 지식이 이론보다 문제를 해결하는데 있어 훨씬 도움이 됩니다. 그러나 유독 IT분야에서 지식이 갖는 문제점은 그것의 유효 기간이 무척이나 짧다는 것입니다.
IT분야에서 경험적 지식을 추종하는 엔지니어가 갖게될 미래상은 습득해야 할 지식의 태산 앞에 고꾸라져버린 자신의 모습이 아닐까 합니다.
그렇다고 원리만 좇는 것도 문제가 있습니다. 이론과 원리에는 빠싹한 사람이 현장 실무에서 전혀 도움이 되지 못하고 오히려 방해자가 되는 일이 비일비재합니다. 공학에서는 오차와 오차 범위내에서의 편법을 이용한 효율 재고가 존재합니다. 하지만 이론과 원리를 너무 추구한 나머지, 그 완벽함과 기술수준은 뛰어나나, 실무에 아무런 효용도 없는 결과물이 생성되기도 합니다.
그래서, 실질적으로 제가 속한 프로그래밍의 세계에서 이론가는 환영받지 못하는 측면이 있다고 생각합니다. 즉, 프로그램밍 세계에서 OOP, UML, 컴퓨터의 구조, OS, OSI(Open Systems Interconnection) 7계층 등등 그 이론을 줄줄 나열하며, 네트워크 프로그램을 만들때는 객체지향적으로 UML을 통해 설계해야 하며, OSI 7계층이 어떻니, 어떤 계층에서 어떤식으로 처리해야만 한다는 이론을 줄줄 나열하지만, 정작 네트워크를 통해 파일을 전송하는 프로그램을 만들어오라고 하면 두손을 들어버리는 경우를 드물지 않게 보게 되기 때문입니다.
그럼 도대체 이 치열한 세상에서 새로운 기술 이론과 경험적 지식으로 무장한 후발자에게 뒤쳐지지 않을 방법은 무엇이 있을까?
그래서, 현재 제가 새운 생존 법칙은 되도록 많은 경험적 지식을 끊임없이 습득하되, 경험적 지식을 자신만의 이론을 세우는 좋은 예로 활용하여 새로운 기술 이론 습득에 활용해야 한다는 것입니다.
즉 경험적 지식을 단순한 지식 습득만으로 끝내서는 않된다는 것입니다. 위의 프로그래밍 예에서 보듯 'cin에서 사용자가 잘못된 값을 입력할 것을 대비해 매 cin 입력마다 cin.clear()와 cin.ignore() 호출을 염두해 두어야 한다.' 하는 지식은 매우 한시적으로 사용되고 기억에서 잊혀질 가능성이 높습니다.
여기서, 우리는 설계이론에 있어 자동화에 대해 잠깐 생각해 볼 필요가 있는것 같습니다. 결과물을 제공 받는 입장에서의 자동화는 해당 사용자에게 매우 편리합니다.
cin이 잘못된 입력을 받으면 잘못된 부분을 알아서(버린다) 처리하고 다음 입력을 받을 준비를 자동으로 처리해준다면 정말 편리할 것이라 생각해 볼 수 있습니다. 그러나 이런식의 자동화는 매우 위험한 결과를 초래할 수 있습니다. 이 경우는 위의 예제에 해당하는 경우에만 편리하다 할 수 있습니다. 개발자가 기대하지 않은 동작을 사용자가 함으로 인해 발생할 수 있는 심각한 문제야기에 대한 의문 자체를 갖을 수 없도록 만들어 버릴 수 있습니다.
즉, 도구를 제공 받는 입장에서 도구가 상황에 따라 무언가 자동으로 처리해버린다면 해당 사용자를 매우 난처한 상황에 직면하게할 가능성이 다분합니다. 그러므로 제가 아는한 도구를 설계하는 사람들은 해당 도구에 문제가 발생한다면, 그 문제 해결을 사용자가 할 수 있도록 남겨둡니다.
오늘 이글을 쓰게한 이유가 되었던 위 예제가 정작 이글에서 주장하는 저의 생각을 뒷받침하기에 부족한 점이 있을지 모르겠으나, 그동안 아마도 잠시 잊어버렸을지도 모르는 저의 생존 원칙을 떠오르게 하였습니다.
무언가 경험적 지식을 습득하게 되면 그 지식(cin사용시 주의할점) 또는 다른 지식들(stringstream에서도 비슷한 경우가 있다.)과 연계하여 속에 숨어있는 불변의 원리-비록 그 대상이 변하더라도-(도구를 설계하는 입장에서 도구에 이상이 발생했을때 자동으로 처리하기 보다는 사용자가 이를 인지할 수 있고, 해결할 수 있도록 하는 방법들을 제공하는 방식으로 더 많이 설계되어진다.)를 이해하고 기억할 필요가 있다. 라는 것입니다.
이런 자신만의 이론을 확립해두면, 입력받은 스트림을 Lvalue의 형에 따른 자동 형변환 및 파싱을 해주는 다른 새로운 객체를 다룰 때, 기대하지 않은 사용자의 입력에 대한 예외처리의 중요성과 당연이 이를 위한 방법을 제공할 것임으로 이런 것들을 미리 찾아보면 되겠다고 생각할 수 있게 되지 않을까요? (^^; ㅋ... 그러나, 저는 극심한 수양부족으로 도대체 이게 뭔일이다냐?! 하며 전혀 감조차 잡지 못하다가, 결국 구글신의 도움으로 알게되어 아내에게 그나마 체면치레할 수 있었습니다. ㅠ.ㅠ.)
ㅋ.... 결국 내가 부족한 것에 대한 넋두리가 되어 버린것 같군요. 언젠가 아내와 둘이서 치과 의사인 아내의 언니를 부러워하며 오갔던 말이 떠오릅니다. '자기 언니 같은 경우, 우리처럼 계속 공부할까?!', '아니, 그런것 같지 않던데?, 왜 계속 공부해야 하는지 이해를 못하는것 같더라구!', 'ㅠ.ㅠ 왜 우리는 진작 의과대학이나 법학, 약학과 같은 것에 지원할 생각을 못했을까?, 지금 생각하면 그 사람들이 참 현명하단 말야! ㅠ.ㅠ' ^^; ㅋㅋ.
Track this back : http://www.codeforum.net/blog/pitoosung/trackback/171
Tracked from Life Is Always Emergency 2008/01/19 11:45 x
제목 : 내가 생각하는 한의학의 문제점
의학은 과학입니다. 내가 연구한 결과는 다른 사람도 인정할 수 있어야 합니다. 또한 사람이 하는 학문이기 때문에 나 혼자의 경험만이 진실이라고 말할 수 없습니다. 내가 한 연구가 제대로 됐는지, 방법이 잘못된 것은 아닌지 자신할 수 없습니다. 이런 점들을 보완하기 위한 것이 바로 학술지입니다. 내가 연구한 내용을 학술지에 논문으로 제출을 하면 그 분야의 최고의 권위자들이 그 내용을 검토하고 문제 없이 가치가 있는 내용이라면 학술지에 실리기 됩니......more
저도 예전에 학교를 쉬면서 아르바이트로 코딩을 하던 일이 있어서 디버깅의 짜증남을 조금은 압니다. ^^ 하루 종일 고민하다가 해결을 못하다가 다음 날 아침에 5분만에 해결하고 왜 이걸 몰랐을까 고민하다가 그런 경험들을 모아서 따로 정리해 두기도 했죠.
의학에서도 비슷한 면이 있는 것 같습니다. 의학 전반적인 지식이야 본과 4학년을 마치고 시험 준비를 열심히 한 졸업생이 가장 쌩쌩하게 많겠지만, 실제 환자 진료는 할 수 없죠. 결국 임상 경험이 없는 의사는 환자를 볼 능력이 부족합니다. 이론서를 열심히 습득해도 실제 코딩 경험이 없으면 실무에 투입할 수 없는 것과 비슷하다고 할까요?
하지만 반대로 책 한 권 읽지 않고 무조건 경험만으로 부딪히는 것은 분명히 한계가 있습니다. 병원 생활을 오래 한 간호사들은 막 병원에 들어온 인턴 이상으로 임상 경험도 많고 실제로 인턴보다 더 옳은 판단을 많이 하지만, 이른바 루틴에서 벗어난 예외적인 상황에서는 그래도 이론적인 지식을 갖춘 인턴들이 더 나을 수 있습니다. 즉, 반복된 경험으로도 충분히 지식이 쌓일 수 있지만, 옳지 않은 지식을 습득할 수도 있고(경험으로 인한 성급한 일반화의 오류?) 경험하지 못한 것에 대해서는 대처가 전혀 안되는 거죠.
물론 피투성님처럼 그런 경험에서 일반화된 원칙들을 끌어낼 수 있는 능력이 있으면 경험을 통해 한단계 성장하는 훌륭한 의사(또는 엔지니어)가 될 수 있지만, 모든 이에게 그런 것을 기대하기는 어려운 것 같습니다. 그런 실무와 접목되고 이론과는 거리가 있을 수 있는 원칙들을 좀 더 문서화, 체계화한다면 좋은 지침이 되지 않을까요? 의학과 전산의 차이는 여기에 있는 것 같습니다. 전산은 사람이 만들어낸 산물에 대한 학문으로 그 배경의 이론도 이미 사람이 만들어 놓은 것이지만, 인체는 사람이 아직도 이해하지 못한 부분이 많으므로 학문 자체가 이론이나 원리를 모르고도 질병의 치료라는 목적만 달성한다면 우선 만족하는 부분이 있기 때문이죠. 즉, 전산으로 따지면 이론적인 배경은 모르는 체로 각종 라이브러리의 객체와 메쏘드 사용법만 죽 익히는 것과 비슷하다고 할까요? ^^
처음에는 제 블로그에 왜 트랙백이 걸렸을까 의아해했는데 끝까지 읽어 보니 재밌는 내용이네요. ^^
P.S. 의사들도 공부를 계속 합니다. 아무래도 바뀌는 부분이 많으니까요. 물론 거의 공부를 하지 않으냐 정말 많이 하느냐는 개인적인 성향이나 상황, 위치에 따라 다르겠지만요.
Commented by 
