[펌] 아키텍트가 되기 위한 길

1. 어떤 언어를 사용하느냐 하는 것은 중요한 것이 아닙니다. 

문제 위주로 생각하는 버릇을 키워야 합니다.
많은 프로그래머들이 자신이 당면한 문제를 정확하게 이해하는 경우가 매우 드뭅니다.
일단 언어와 개발환경에 익숙해지면 다른 사고와 접근 방식을 요구하는 문제 해결에는 속수무책인 경우가 많습니다.

이것도 일종의 문화이기 때문이겠죠.
C/C++을 배우려고도 하지 않고, 시스템 프로그래밍을 하지 못하는 대다수의 프로그래머를 실력이 없거나, 한계를 갖는 프로그래머로 매도하는 경향이 일부 있는데 이는 바람직하지 않다고 봅니다.
2000년 문제를 해결해야 할 대다수의 프로그래머는 C/C++나 어셈블리어 를 사용하는 사람보다는 코볼을 사용하는 프로그래머입니다. 그들에 대한 수요가 절대적인 이유는 문제가 그것을 주로 사용하는 시스템에서 빚어지기 때문입니다.
(메인프레임의 MIS/뱅킹/.... 관련 프로그램들은 거의 코볼로 작성되었다고 보면 됩니다)
특정 환경에 맞는 특정 언어가 존재하며, 어떤 언어를 선택하느냐 하는 것은 프로그래머의 마음이나 능력 이 아닙니다. 실제로는 문제가 결정하며, 궁극적으로는 시장이 결정합니다.
만약 비디오 대여점에 맞는 프로그램을 짠다고 가정합시다. 비주얼 베이직으로 하는 것이 Visual C++프로그래밍보다는 훨씬 경제적이다는 것은 누구나 다 아는 일일 것입니다.
저는 개인적으로 두 툴을 다 사용하고 Visual C++을 더 좋아하지만 (이것은 완전히 개인적인 기호입니다), 유사시에는 두개의 툴을 동시에 사용합니다. 그리고 C/S 환경에서 프로그래밍을 즐겨 짭니다.
네트워크 프로그래밍을 할 경우, 서버 소프트웨어를 짜는 과정에서 분석 된 도큐먼트 하에서 프로그래밍을 하더라도, 클라이언트 운용환경 하에서 테스트를 해야 할 필요성을 느낍니다.
NT환경하에서, 서버 소트프트웨어는 Unix의 데몬과 같은 Service형태로 돌아가고 네트워크 퍼포먼스와 과부하를 견딜 수 있는 소프트웨어를 짜야만 한다고 가정합시다. 그러면 선택의 여지는 별로 없습니다. C++이죠. 그러나, 아직 클라이언트 소프트웨어는 만들어지지도 않았기 때문에, 여러가지 내가 만든 소프트웨어의 잠재적 위험성은 상당히 높다고 보아야 합니다.
이 경우 아주 빨리 클라이언트 프로토타입을 만드는 도구를 선택한다면 비주얼 베이직이 될 것입니다. 소켓 프로그래밍에서부터, 데이터베이스 프로그래밍에 이르기까지 아주 빨리 아주 편리하게 클라이언트의 프로토타입을 남몰래 (도큐먼트에 없는 비공식 테스트용으로) 만들어 테스트를 해 나갈 수 있죠.
이 경우 제거되는 소프트웨 어의 비효율성이나, 문제점은 상당하며 개발 속도 및 디버깅 속도를 향상시켜 줍니다. 저는 실제로 비주얼 베이직을 프로토타입 작성용으로 즐겨 사용하고 있습니다.
(때로는 실제 클라이언트 릴리지 버전 제작용으로도 사용하죠)

사실 비주얼 베이직 그 자체로도 훌륭한 도구입니다.
만약 비주얼 베이직이 문제가 된다면, 그 환경이 비주얼 베이직으로 해결 되지 않거나, 반대급부가 너무 큰 경우이겠지요.... 어떤 도구를 사용할 것인가에 너무 집착하면 문제를 잘못볼 수가 있습니다. 어떤 도구도 완벽한 것은 없기 때문에 어떤 환경/문제에 어떤 도구가 적합한지를 판단할 수 있는 훈련을 하는 것이 바람직합니다.

2. 아키텍처를 이해하십시오. 

종종 프로그래밍을 시작하는 사람들은 그 언어 사용법이나, 도구가 제공하는 환경(IDE같은)을 이해하는 데에 많은 시간을 할애하는 것을 봅니다. 그러나, 이보다 더 큰 문제는 마치 이것을 전부인 것처럼 생각하는 것입니다.
프로그래밍을 한다는 것이 반드시 무에서 유를 창조하는 것만은 아닙니다. 오히려 그런 경우는 아주 소수이지요. 여러분이 아키텍처를 발표한다든지, 운영체제를 만든다든지 하는 일은 연구소나,
학계에서 일하지 않는 한 거의 없을 것입니다.
만약 여러분들이 협애한 생각으로 프로그래밍을 한다면, C/C++만 가지고 할 수 있는 일은 거의 없을 것입니다.
널리 수행되는 데이터베이스 프로그래밍을 하는 것은 C/C++을 알면 도움이 되긴 하지만, 사실 그 자체와는 아무런관련이 없습니다. 오히려 SQL과 데이터베이스 커넥션(네트워크)에 대해 알아야 할 것입니다. 때로는 Embeded SQL이나, ODBC에 대해 알아야 할 것입니다.
C/C++프로그래밍을 한 사람이 네트워크 프로그래밍을 하지 못한다면, 그 사람은 아마 네트워크 아키텍처에 대해 잘 모르기 때문이지 실력이 없어서는 아닐 것입니다. (네트워크 분야라 할지라도, IPX/SPX 프로그램밍, RPC 프로그래밍, TCP/IP 소켓 프로그래밍 등등 여럿이 있으니까요...)
때로는 표준이기도 하거나, 때로는 완성되지 않은 아키텍처이기도 하겠지만, 하나의 아키텍처를 얼마나 신속하고 빨리 이해할 수 있느냐 하는 것이 매우 중요합니다. 사실 제가 경험한 신입사원들은 사용언어보다는 아키텍처를 이해하는데에 더 많은 시간과 노력을 투자해야 한다는 것을 뼈저리게 처험했습니다.
개발경력이라고는 전혀 없는 신입사원들이 수행했던 프로젝트는 광파일 시스템이었는데 이해하여야 할 아키텍처가 상당했거든요... (이미지 프로세싱, TCP/IP네트워크 프로그래밍, C/S, RDBMS 등등 선너머 산이었죠.)
이렇게 닥달을 당하고 훈련되니까, 3개월만에 자연스럽게 잘 하더라구요..... 심지어, 그 중에 한 친구는 비주얼 베이직 갖구 win32프로그램을 하더라구요 (물론 약간 제한적이기는 하지만).
그들은 지금도 서슴없이 이야기하죠. 뭐 언어는 중요한게 아니라구요. 아키텍처가 중요하다구요. 농담삼아 야한 이야기를 할 때도 "허리아래 아키텍처"에 대해 논해보자구 할 정도의 노이로제 증상을 보이 는 정도랍니다.
C++을 배우기 위해서, Visual C++을 공부하는 사람에게 저는 종종 다음과 같은 이야기를 하지요...
먼저 죽어두 MFC프로그램밍으로 시작하지 말라구요....

MFC는 사실 아주 숙련된 C++프로그래머 (OOP입장에서 볼때 능숙한 C프로그래머가 아니라)
와 능숙한 Win32프로그래머를 위한 것이에요. <<<이것은 마이크로소프트의 도큐먼트에도 나 
와있 는 이야기입니다.>>>
윈32 아키텍처를 이해하지 못하는 대부분의 초보 프로그래머, 더군더나 여기에 C++ 아키텍처도 잘 모르는 프로그래머가 위저드의 도움으로 프로그래밍을 작성했을 경우 자신의 코드를 이해하는 데 걸리는 시간은 윈32 아키텍처와 C++아키텍처를 이해하고 다시 MFC를 공부하고 프로그램을 짜는 데 걸리는 시간보다 더 길다는 것을 사람들은 이해 하지 못합니다.
전체로서의 구조화된 아키텍처를 이해하고 숙달되려고 노력하는 지난한 과정이 필요합니다. 윈도우 프로그래밍을 배우려 한다면, 한번쯤(당장은 아니더라도 머릿속에 항상 기억하십시오) Win32 아키텍처를 이해하도록 노력하여야 합니다.
인터넷 프로그래밍을 하고싶다면(혹시 C/C++을 사용해서), RFC 도큐먼트를 참조해야만 하는 경우가 생깁니다. WEB이 강력하고 저도 자유롭게 즐겨쓰는 프로토콜과 환경을 제공해주지만, 때로는 인터넷으로 메일을 보내고 소켓을 바로 열어 다른 형태의 프로토콜로 대화를 해야할 필요도 있으니까요.
이렇듯 여러분이 앞에 있는 것은 사용법이나, 도구와 관련된 문제가 아니라, 아키텍처의 이해와 적용에 관한 문제가 아닐까 합니다.
참고 : MFC프로그래밍은 단순히 User와 GDI서비스를 적절하게(?) 클래스 라이브러리화한 것에 지나지 않습니다. (스레드, ISAPI나 소켓 등 일부는 예외). 커널 서비스와 관련된 작업은 전적으로 당신의 몫입니다.)

3. 사용자 지향의 마인드를 가져야 합니다.

여러분이 만약 프로그래밍을 생계의 수단으로 삼고 그것을 유통경로를 통해 다른 누군가에게 판매하고자 한다면, 시장을 석권하기 전까지는 자신이 짠 프로그램에 대해 자부심을 갖지 마십시오. 그건 당신의 착각일 수 있습니다.
아무리 화려한 기능과 성능으로 무장을 하였더라도 사용자가 원하는 사소한 기능이 빠졌다면, 그것은 바로 당신의 무능함을 말하는 것입니다. 그사이에 경쟁자는 더욱 구매자의 구매의욕을 자극할 제품을 내 놓을지도 모릅니다.
저도 이 생각을 받아들이기까지 많은 시간이 걸렸습니다.
처음에는 속으로 "뭐 이런 것들이 다 있나"하는 생각도 해보 았지요.
사용자가 현명하기 때문에 사용자가 왕이 아니라, 그들이 바로 내가 짠 프로그램을 구매하기 때문에 왕이라는 사실을몸으로 체험하기까지는 시간이 결렸습니다.
더 싸게, 더 강력하게, 그렇지만 더 작고 더 편리하게 만들 수 없다는 것이 판명나면, 그날로 당신은 시장에서 매장당하게 될 것입니다.
특히 우리나라 시장에서 나타나는 코딩과 관련되서 나타나는 문제는 사용자 인터페이스입니다. 사용자 인터페이스는 그자체로 아주 방대하고 상당한 경험을 요구하는 분야입니다. 뿐만 아니라, 상당한 비용 (소프트웨어 개발 비용보다도 더드는 경우가 많습니다)을 요구합니다.
어느 정도 수준에 도달한 사용자 인터페이스를 갖춘 국산 프로그램을 보기란 아주 어렵죠....
여러분들은 윈도우의 커먼콘트롤들을 사용하는 이유를 잘 아실 겁니다.
이것들이 좁은 화면에서 사용자와 상호 정보를 주고받기 위한 상당히 계산된 도구들이라는 것을요... 그러나, 이것이 전부는 아닙니다. 불필한 정보의 표시, 잘못된 버튼의 위치,중목된 정보, 보기싫은 아이콘, 맞춤법은 흔히 나타나는 문제에 불과합니다.
기본 정보와 고급 정보의 분리 및 배치, 시스템 장애시의 조치사항, 마우스 이동 경로의 계산(최소 이동 경로), 운영시간을 단축할 수 있는 최소 작업 경로의 배치, 다양한 사용자의 운영 습관에 대응하는 인터페이스, 사용자 운영 시스템에 대한 고려, 관리상의 편리를 도모할 수 있는 인터페이스 등등 실제 현장에서 나타나는 문제는 그야말로 산적해 있습니다.
여러분들이 바로 오퍼레이터(때로는 고객)라는 생각을 가지고 프로그래밍을 하는 것이 중요합니다. 그것은 나중이 아니라, 지금부터입니다.
윈도우 프로그래밍의 보이지 않은 기본적인 과제는 사실 손쉬운 인터페이스의 구현에 있습니다. 그러나, 비주얼 툴이 결코 자동적으로 좋은 사용자 인터페이스를 가져다 주지 않습니다.
사실 이 부분은 교재나 샘플코드에 나와있지도 않으며, 누가 가르쳐주는 내용도 아니기 때문에 경험있는 사람들의 조언이나, 본인의 노력, 사용자들의 조언에 의존하는 바가 큽니다.

자신의 결과에 대한 비판적인 자세가 필요하다고 봅니다.

4. 팀 작업을 염두에 두어야 합니다. 

공부하는 단계에서 뭐 이런 것까지 필요할까 생각하는 분들이 있을 겁니다. 사실 급한 것도, 당장 필요한것도 아니지요..... 그렇지만, 내가 만드는 소프트웨어가 나 혼자 개발하는 것이 아니라는 염두에 둔다면 과정과정에서 많은 도움을 얻을 수 있습니다.
여러분들에게 앞서 사용자 인터페이스를 염두에 두어야 한다는 말을 했습니다.
이제는 프로그래머 사이에 존재하는 인터페이스를 이야기하고 싶군요. 개발과정이 복잡해지면 질수록 개발방법 또한 복잡해집니다. 이에 따라, 개발자 사이에 의사소통도 복잡해지고 여가에서 발생하는 문제도 아주 커집니다.
여러분들이 앞으로 OEM 소프트웨어나 상용 프로그램을 개발할 경우, 결코 단독으로 개발하는 일은 거의 없을 것입니다. 사소하게는 디자이너와도 이야기해야 하며, 싫은 일이지만 관리 파트와도 
이야기해야 할 때가 있습니다. 모든 부분들은 공식적인 이야기이며, 여기에는 사소하더라도 도큐먼트가 따라가게 됩니다.
하나의 프로젝트가 끝나면, 프로젝트 관련 문서는 산더미처럼 쌓이게 되죠. 전자형태이든, 종이의 형태이든, 대화의 형태이든 이런 작업은 계속적으로 처음부터 끝까지 이루어집니다. 피할 수 없는 지겨운 작업이죠..... 여러분들이 공부할때부터 이런 습관을 들이는 것은 아주 좋은 일이죠......

1) 주를 충분히 달아두는 연습(프로그래밍을 잘한다고 하는 사람일수록 이것을 잘 안하죠.) 현란한 기법에 빈곤한 주,아마 인수자에겐 지옥일 겁니다. 그리고, 시간이 오래되서 본인이 망각할 경우(특히 공부할 때는 더더욱 그렇죠), 주가 없다면 시간이 많이 걸리겠죠..

2) 인용이나, 참고에 대한 메모 : 종이가 만약 아깝지 않다면 이 부분은 반드시 메모하거나, 프린트 해두세요... 언제든 반드시 다음에 참고가 되고, 인수인계나 공동작업시 좋은 반려자가 된답니다.

3) 좋은 인터페이스 설계: 내부의 복잡한 임플리멘테이션을 숨기고 헤더만 공개할 경우 가능한 한 최소한의 충분한 용을 담고 있어야 하며, 이것과 관련된 사용방법을 매뉴얼화하여야 합니다. 클래스 설계나, 라이브러리, 기타 작업에 있어서 이것은 피할 수 없는 일입니다. 되는 기능과 안되는 기능에 대한 조언이 있다면 더욱 좋구요.

네트워크 프로토콜의 경우도 마찬가지예요. 여러분이 델파이나, C++, 비주얼베이직 등으로 클래스를 만들었을 때한번 이작업을 해 보세요. 그러면 다른 사람만이 아니라, 여러분 자신에게도 많은 도움이 될 꺼예요.

4) 좋은 팀 프로그래밍 관리 소프트웨어의 사용법을 알아두세요. 소스관리에도 좋구요. 나중에 여러사람이 같이 작업할 때 아주 좋아요.

기타 등등이 많겠지만 지금은 이정도가 생각나네요....

참고) 소프트웨어 개발이 일차적으로 끝나고 나면 가장 골치아픈 일이 버전 관리예요. 소프트웨어를 버전별 로 관리하는 것이 굉장히 어렵죠. 때로는 동일버전 넘버가 플랫폼에 따라 여럿인 경우가 생기게 되죠.

이런 습관이 안들어져 있으면 결과는 글쎄요.....
먼 훗날의 일이 아니라, 바로 얼마뒤면 부딛힐 문제가 아닌가 합니다. (팀 프로그래밍을 잘하는 프로그래머, 아마 그사람은 인간성도 끝내줄 거예요. 저는 잘 못하는 거든요)

4. 사소한 아이디어라도 놓치지 마십시오.

C++은 귀신같이 다루지만 아이디어가 없는 프로그래머, 서투르지만 비주얼 베이직을 다루고 아이디어가 풍부한 프로그래머. 당신은 누굴 선택하실건가요? 누가 더 뛰어난 프로그래밍 실력을 갖고 있는가는 분명히 측정할 수 있습니다.이건 주어진 난이도의 과제를 해결하는 시간이 말해줍니다.
어려운 과제를 완성도(성능, 기타)가 주어진 상태에서 빨리 풀어낼수록 좋은 프로그래머인 것은 분명합니다.
그러나, 누가 더 가능성있고 능력있는 프로그래머인가는 측정하기가 곤란합니다.
저는 여러가지 이유로, 후자를 택합니다.

C/C++를 귀신같이 사용하는 사람만이 진정한 프로그래머는 아닙니다. 이런 사람들이 주로 종사하는 분야의 시스템 프로그래밍이 프로그래밍의 전부는 아닌것과 마찬가지입니다.
MIS 프로그래밍을 하는 프로그래머들이 종종 도마의 대상이 되고는 하는 데 만약 이들이 욕을 먹는다면, 그것은 그들이 편리한 도구를 사용하기 때문이 아니라, 편리한 도구로도 할 수 있는 안하는 태도때문이어야 할 것입니다. (사실 그런 경향이 많이 보이기는 하지만, 문제를 거꾸로 보면 안될 것 같군요)
원자폭탄을 만든 사람만이 대단한 것이 아니라, 반창고를 만든 사람도 저는 대단하다고 생각합니다.
무엇인가 더 복잡 하고 더 정교한 것을 만들 수 있는 능력은 존경받아 마땅하지만, 사소한 것이라도 놓치지 않고 유심히 관찰할 수 있는 능력도 저는 정말 대단한 것이라 생각합니다.
사실 공부하는 여러분들이야말로 제가 보기엔 보물덩어리입니다. 프로젝트에 찌들고 프로그래밍에 권태를 느끼는 그런 경력사원(저는 정말 그런 사람 너무 많이 보았거든요)보다는 여러분이야말로 프로그래밍을 프로그래밍답게 할 수 있는 사람이라고 생각해요...
너무 MFC니, 윈도우니 하는 것들에 매몰되지 않도록 노력하시기 바랍니다. 교재에 나온 대로 일단 해보시고, 되면, 그리고 이해하면 그것을 훌훌 내던져 버리세요. 그리고 여러분의 상상력을 화면에 채우시기 바랍니다.
지금 안된다고 잊어 버리지 말고 메모해 두고 다음에 아이디어를 더 구체화해서 실력이 되면 구현하도록 하는 자세가 필요합니다. 때로는 아이디어를 구현하기 해당분야를 공부하는 것도 지름길이죠.
아이디어야말로 프로그래머를 살찌우는 보약입니다!!!!!!!!!!!!!

5. 자신이 가지고 있는 개발 능력이 곧 한계에 부딛힐 수 있다고 생각하여 야 합니다.

항상 새로 시작한다는 생각을 가지십시오.
세상은 급변하고 있습니다. 특히 프로그래밍 분야는 그야말로 지진, 해 일, 홍수가 매일같이 프로그래머들을 덮쳐 수도없이 재해지역을 만들어 내고 있습니다.
그러나, 아무도 여러분들을 대가없이 도와주지는 않습니다.
3년전의 일로 기억되는군요. 인터넷이 대중화되고 웹에 기반한 인트라넷이라는 개념이 태동되었을 때 세상은 완전히 끓는 냄비 속이었습니다.
하나의 아키텍처가 나와 그것을 이해하고 사용하는데에 약 3년 정도이던 시절에 익숙했던 프로그래머들은 3개월단위로 쏟아져 나오는 수십개의 아키텍처에 놀라움을 금치 못하고 드디어는 "나보고 어쩌란 말이냐?"라는 푸념을 서슴없이하던 때였습니다.
지금도 그 후유증에 시달리는 사람이 많이 있습니다.
코볼을 하는 사람들은 2000년 문제를 보면서 하는 말이 있습니다.
이것이 코볼 프로그래머의 마지막 특수라고요..... 자조섞인 농담이겠지요.
컴퓨터업계를 둘러 싼 세상은 지금도 요동을 치며 목숨을 건 싸움이 전개되고 있으며, 한치 앞을 내다볼 수 없는 상황입니다. 이때문에 내가 가지고 있는 기술과 능력이 하루아침에 무용지물이 되거나, 적어도 절름발이가 될 수 있습니다.
이것은 필요하다면, 주저하지 않고 곧바로 새로운 아키텍처와 환경에 적응하려는 자세를 요구합니다.
그러나, 너무 겁을 낼 필요는 없습니다. 그 어느 기술도 하루 아침에 나온 것은 아니며, 또 아무 기반 기술 없이 나온 것은아니니까요.

각각의 기술은 다른 기술과 거미줄처럼 얽혀있는 경우가 허다하니까, 하나의 기술을 전체적인 시각에서조망하면서, 이해하고 닦아나가면 다른 기술을 이해하기는 전보다 훨씬 수월해질 것입니다.
공부를 하는 시점에서는 가능한 한 기초가 되는 공부를 하는 것이 바람직하겠죠? 누가 만약 MFC가 기초라고 이야기한다면 그것은 아마 거짓말일겁니다.
오히려 C++이나, OOP, 분산 객체 기술등을 공부하는 것이 더 장래를 튼튼히 하는 비결이 될 겁니다. 그리고, 막상 취직이 되어서 공부를 하려 한다면, 아마 최악의 상황을 머릿속에 그리시면 될 겁니다.

6. "지금은 12시 10분전" ? 

이런 이야기가 있습니다.
지금 12시 10분전, 12시에 소프트웨어를 포장해서 납품(흔히 Shipping)해야 할 때 당신이 할 수 있는 일은 무엇인가? 물론 서둘러 디버그 코드를 릴리즈 코드로 바꾸어야겠지요.디버깅 정보를 날립니다. 릴리즈에 필요한 정보를 담습니다. 그리고 기타 등등....
그런데 이때 문제가 발생한다면? 혹은 아직도 테스트가 끝나지 않은 코드가 있 다면? 쉬핑하자마자 문제가 있음을 깨닫게 된다면? 또 다른 문제가 있다면?
이 모두는 정말 생각만 해도 치명적인 것들이지만, 실제로 필드에서는 다반사로 일어나는 문제들입니다.
이 문제를 사전에 방지하는 것이 유능한 프로젝트 매니저이지만, 그 책임은 일부 프로그래머도 져야 합니다.
시간과 싸울 줄 아는 프로그래머, 생산성을 고려할 수 있는 프로그래머가 유능한 프로그래머로 대접받는 것은 냉랭한 자본주의 사회에서는 어쩔 수 없는 현실입니다. 시간과 싸운다는 것은 정말 피말리는 일이지요.

여러분도 사실은 시간과의 싸움을 시작하고 있는 거지요.
이 사실을 깨달은 사람은 인정받는 프로그래머가 될 소지가 있어요. 여러분들은 여러분들에게 주어진 시간 안에, 혹은 여러분이 설정한 시간 안에 주어진 목표를 달성하여야 합니다.
그 결과는 여러분만의 몫이라는 것이 다를 뿐이죠. 책을 읽는 것, 프로그래밍 연습을 하는 것, 자료를 구하는 것, 조언을 얻는 것 모든 것이 결과적으로 하나의 시간표위에 자리잡게 될 것이기 때문입니다.
프로그래밍 연습을 할 경우, 아예 계획을 잡아 놓고 하는 것도 바람직하겠죠...
내실있는 학원에서 프로젝트별로 학원생을 육성하는 것은 좋은 현상이지요 (뭐, 학원생이 한번의 프로젝트로 그것을 익히리라는 생각은 저도 안하지만요)
아마 제가 학원 교육 커리큘럼을 진행한다면 정해진 시간안에 프로젝트를 완성하지 못하면 졸업을 시키지 않게 할 지도 모릅니다.(너무 심했나?)

7. 기타

다음은 몇가지 이야기들을 덧붙여서 이야기하겠습니다.
1) 디버깅에 익숙해지도록 노력하십시오 : 디버깅 과정에 익숙해져 있지 않으면 프로그래밍이 점점 더 어려워집니다.
에러는 프로그래머에게 많은 정보를 줍니다.
책에서는 흘렸던 내용이 에러로 잉태하여 세상에 나오면 그냥나오지 않고 줄줄이 정보(때로는 필요 이상으로 너무 많은 정보)를 가져다 줍니다.
디버깅을 최소화하는 능력과 디버깅을 안하거나, 무시하는 태도와는 구별을 해야겠지요. 물론 이과정은 인내심을 요구합니다.) 초보자일수록 디버깅을 많이하게 되고, 또 많이 하여야 합니다.

2) 만약 윈도우 프로그래밍을 한다면, Win32 아키텍처에 익숙해져야 합니다.

이것은 API를 많이 아는 것과는 다른 것 입니다. 또 User나 GDI서비스가 전부 라고 생각해도 안됩니다. 실로 방대하고도 아주 강력한 커널 서비스들을 적용해야 할 상황들을 아주 많습니다.
굳이 MFC를 공부하야 하는 상황이라면, 그만큼의 시간을 네이티브한 Win32 프로그래밍에 할애하여야 합니다.
만약 여러분들이 분산 객체환경에서 조그마한 콤포넌트를 개발한다고 할 경우, 그리고 작고 가벼운 컴포넌트를 만들어야 한다면, 아마도 MFC는 거의 도움을 주지 않으며 다른 기법(ATL을 이용한 방법)을 해야만 할 것입니다. 이때 여러분이 공부한 Win32 프로그래밍은 아마 강력한 무기가 될 것입니다.

3) C++은 단순히 C에 몇가지를 덧붙인 언어가 아닙니다.

만약 이렇게 이해하고 공부를 한다면 그것은 사실 C++ 프로그래밍이 아니라, 향상된(?) C프로그래밍이라고 보아야 합니다.

제 경험으로 보건데, 분명히 C++컴파일러를 사용하는데, 코드는 C 스타일인 경우(약간만 C++스타일)를 많이 보게 됩니다.

C++은 C와 비교할 때, OOP라는 패러다임의 변화를 요구한다고 종종 이야기합니다. OOP스타일로 사고하고 OOP스타일로 프로그래밍한다는 것은 C프로그래머에게는 종종 견디기 힘든 고통이 되기도합니다.

저도 예전에 C스타일로 짠 프로그램과, OOP스타일로 짠 프로그램을 동시에 비교해 보면 많은 생각을 하게 된답니다. 물론 이제 저는 C++을 C++답게 사용하는 프로그래밍의 옹호자입니다.