[펌] 컴퓨터 프로그래머의 현실 (도움이 되는 자료)

프로그래머의 현실

1. 대기업 발주

2. 경쟁 입찰

3. 관련 업체 벌떼처럼 모여듬

4. 금액이 낮고 기간이 짧은 업체가 선정

5. 프로젝트 진행

6. 기간이 짧으므로 제대로 된 기획이 나오지 않음

7. 설계시작( 여기서도 제대로된 설계는 없음)

8. 고객도 PM도 그냥 개발 진행

9. 일단 화면부터 만듬( 개발기간이 짧으므로 계속 밤샘)

10. 화면이 나오면 그때부터 고객과 이야기가 시작됨

11. 이때부터 완료되지도 않은 시점에서 수정사항 쏟아짐

12. 데이터베이스 구조 변경, 서버 프로세스 변경 (매일 야근에 주말까지 야근)

13. 12번 변경에 따라서 문서변경작업에 관련 화면 쿼리변경등 또 죽어남

14. 버그 투성이로 날짜는 다가옴

15. 고객과 PM과의 합의 도출 ( 일단 검수는 하고 나머지는 남아서 합시다)

16. 검수함으로 프로젝트 종료

17. 개발자들으 보통 남아서 계속 밤새면서 버그 잡음

18. 버그를 잡는 중에도 다시 화면 추가 또는 변경 요청

19. 계속된 수정과 변경 반복으로 인해 결국에는 처음과 너무 틀려짐

20. 결국 남아있던 사람들은 다른 프로젝트를 하면서도 문제가 생기면 2중으로 일을 하게됨

21. 20번이 쌓이면서 연차가 쌓이면 혼자서 커버하는 프로젝트가 많으면 열개 이상 됨

22. 아.. 누군가 일을 나누어 줬음 좋겠다.. 라고 생각하는데 회사에는 신입만 뽑음

23. 위 생활이 반복됨

24. 가장 큰 문제는... 16번 검수가 끝나면 회사에서 프로젝트 끝났으니까 다른 프로젝트에 배정

25. 결국 다른 프로젝트 가서 계속 이전 프로젝트 정리 작업 해야함(매일 야근)

26. 주말되면 이전 프로젝트 하던 회사에 가서 작업한거 확인

27. 반복.. 반복.. 반복.. 반복.. 반복..반복..반복..반복..

 

 

 

 

 

 

 

 

 

 

 

 

 

>-------------------------------------------------------------------
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++답게 사용하는 프로그래밍의 옹호자입니다.

---------------------------------------------------------------------------------------------------

지금적을 글은, 마이크로 소프트웨어 1997년 7월호 168-169에 걸쳐 게제된 글로, 서울대학교 대학원을 졸업하고, 휴먼컴퓨터를 거쳐 현재 아이큐브의 개발 실장으로 방송용 디지털 비디오 시스템을 개발중인 이준희님의 글입니다. 평소 제가 생각하던 것과 많이 비슷해서 감격, 눈물을 금치 못하며 옮겨 적어봅니다.

"다시 한 번 말하노니, 당신에게 프로그래밍을 향한 정열이 있다면 먼저 그 기초를 튼튼히 하라. 그러지 않으면 그 정열은 허무한 추억만을 남길 것이다. 기초를 튼튼히 하라. 그러지 않으면 그 정열은 허무한 추억만을 남길 것이다. 그러지 않으면 그 정열은 허무한 추억만을 남길 것이다. 허무한 추억만을 남길 것이다."

여기서 부터 시작입니다.

★ 정열은 있다, 그러나 기본이 없다 ★

위말은 하이든이 작곡을 배우기 위해 찾아온 베토벤을 보고 한 말. 베토벤의 아버지는 아들을 모짜르트 같은 신동을 만들어 일확천금을 벌겠다는 욕심에 어린 베토벤에게 하루도 거르지 않고 피아노 연습을 시켰다. 덕분에 베토벤은 12살의 나이에 피아노 작품을 출판할 수준에 이르렀지만 모차르트 같은 선풍적인 인기몰이에는 실패했다. 귀를 솔깃하게 할 기교만 익혔지 음악을 학문적으로 제대로 배우지 못했기 때문이다.

★ 기초없는 프로그램은 빛 좋은 개살구에 불과하다 ★

필자는 오늘날의 컴퓨터 프로그래머에게도 이러한 문구가 꼭 들어맞는다고 생각한다. 프로그래머를 꿈꾸는 젊은이도 많고, 프로그래머를 위한 개발툴도 우후죽순처럼 쏟아지고 있다. 프로그래밍을 가르치는 학원도 성업중이고, 책과 잡지, CD-ROM도 지천에 깔려있다. 주위를 둘러보면 열성적으로 프로그래밍에 몰두하는 사람들을 쉽게 찾을 수 있다. 그럼에도 불구하고 왜 우리 나라 정보 산업계는 심각한 인력난을 겪고 있을까.

필자가 다니는 회사는 작은 규모지만 우수한 개발 인력을 뽑기위해 부심하고 있다. 그래서 프로그래머로 지원하는 사람에게 간단한 프로그래밍 과제를 내주고 결과를 평가하는 절차를 거치고 있다. 과제는 fgets나 printf등의 표준 입출력만 사용하는 C프로그램으로 200줄 안팎에서 충분히 끝낼 수 있는 크기이다. 그런데 지금까지 접한 지원자중 과제를 제대로 짜는 사람은 열 명중 다섯 명이 채 못됐다.

프로그램을 짠 사람중에서도 버그없이, 각종 경계 조건에서 문제없이 잘 돌아가는 프로그램을 짜는 사람은 열에 두셋이고, 프로그램 소스 코드도 잘 정리하고 함수 구조를 탄탄하고 확장성 있게 만들고, 변수 이름도 의미있게 붙이고 주석도 잘 다는 사람은 스무 명에 한두 명 꼴이었다.

왜 실력있는 프로그래머의 품귀현상이 두드러지는 것일까. 이력서를 받은 지원자중 많은 사람들이 C++와 윈도우 프로그래밍이나 MFC에 경험이 있었다. 유닉스에서 X윈도우나 모티프 프로그램을 해본사람도 있었도 C/S환경에서 DB프로그램을 만들어 본 사람도 있었다. 다소 개인차가 있었지만 대개 수천 줄에서 만줄이상의 프로그램 경험을 가진 사람들이었다.

그런데 어째서 200줄짜리 간단한 C 프로그램에서 헤맨단 말인가. 이유는 간단했다. 그 과정을 거쳐서 입사한 신입사원 한 사람이 윈도우 SDK를 공부하면서 연습삼아 과제와 비슷한 기능을 하는 프로그램을 윈도우용으로 만들었다. 그러자 라인 수가 200라인이 아니라 1,000라인으로 불어났다. 프로그램의 알고리즘이나 데이터 구조는 본질적으로 달라진 것이 없건만, 윈도우 생성이며 다이얼로그 박스며 프린터 제어 같은 부분이 들어가자 코드량이 눈덩이 처럼 불어난 것이다. 앞서 말한 지원자들이 짜봤다는 수천이나 수만라인짜리 프로그램도 그 뼈대가 되는 알고리즘과 데이터 구조 부분만을 따지면 1,000줄 안쪽의 코드만 남을지도 모를 일이다.

★ 샘이 깊은 물은 가뭄에 아니 마를 새 ★

프로그래밍이란 결국 설계와 구현으로 집약된다. 기능을 정하고, 모듈 스펙을 정의하고, 함수구조를 결정하고, 데이터 구조를 작성하고 알고리즘을 구현하는 것이 프로그래밍의 주된 작업이다. 이런 것을 연습하기 위해서는 군더더기를 뺀 알짜 프로그램을 짜보는 것이 필요하다.

커니건과 리치의 명저인 "The C Programming Language"에 나오는 연습문제는 매우 오래되었지만, 분산객체와 자바가 출현한 지금에도 변함없이 유용한 과제다. 이런 프로그램을 짜는데는 윈도우 API도, MFC도, OLE도 액티브X도 필요없다. 오직 관심이 되는 문제의 해결에만 집중하면 된다. 필자의 생각에는 사용자 인터페이스 부분을 제외한 엔진 부분이 1만라인 이상되는 프로그램을 짜본 사람이라면, 어떠한 프로그래밍 과제도 스스로 해결할 수 있는 능력을 갖추었다고 본다.

반면 코딩없이 프로그래밍을 할 수 있는 시대가 멀지 않았다는 주장도 있다. 델파이나 비주얼 베이직 등의 RAD툴을 사용하면 마우스 클릭 몇 번으로 그럴듯한 고객관리 프로그램을 만들기란 어렵지 않다. OCX와 VCL로 대표되는 컴포넌트 제품은 컨트롤을 드래그해서 폼에다 집어넣기만 하면 워드프로세서며 스프레드시트며 그래프 기능을 순식간에 구현할 수 있다고 선전한다.

컴포넌트를 사용하는 RAD툴은 확실히 DB가 관련된 업무용 프로그램을 만드는 데 대단한 위력을 발휘한다. 또한 프로그래밍 초보자가 예쁜 달력이나 CD플레이어 프로그램을 만드는데도 적합할 뿐 아니라, 어떤 프로그램이라도 컴포넌트만 있다면 만들 수 있다. 그러나 한 번 생각해보자. 컴포넌트만 있으면 "누구나" 만들수 있다. 그렇다면 프로그래머로서의 가치는 과연 어디에 잠재돼 있는 것일까.

컴포넌트를 적당히 조합해서 이런 저런 프로그램을 만들어 내는 것도 분명 프로그래밍이라 할 수 있다. 미래에는 지금 우리가 생각하는 개발자의 개념도 바뀌어서 일반 사용자가 워드프로세서나 스프레드시트를 사용하는 개념으로 '프로그래밍'을 하게 되는 엔드유저시대가 도래할 지 모른다. 그러나 이런 종류의 '프로그래밍'은 이 글을 읽는 독자가 원하는 바가 아니라고 믿는다. 누구든지 할 수 있는 일을 단순 반복하는 사람이라면 타이피스트나 다를바가 없기 때문이다.

이 말은 컴포넌트를 사용하는 것이 잘못된 일이라는 말은 아니다. 어차피 프로그램에는 여러가지 기능이 필요하고 어설프게 구현하는 것보다는 잘 만들어진 컴포넌트를 가져와서 쓰는 것이 훨씬 현명한 방법이다. 요는 단순한 컴포넌트의 집합이 아니라 독자적인 개념과 사용법을 가진 프로그램이 되어야 한다는 것이다. 그래서 프로그래머는 컴포넌트에 모든 것을 맡길 것이 아니라 자신의 프로그램 안에서 컴포넌트를 적절히 배치하고, 서로를 유기적으로 연결하며, 혹 모자라는 부분이 있다면 직접 그 부분을 보충할 능력이 있어야 한다.

자신이 짠 프로그램을 한치 떨어져서 평가해보라. 비주얼툴이 생성해 준 코드 말고, 컴포넌트의 메쏘드를 호출하는 코드 빼고, 다이얼로그박스나 메뉴를 처리하는 코드를 제외하고 자기가 직접 짠 코드의 양이 얼마나 되는가. 스스로 고민해서 데이터 구조를 만들고 그것을 다루는 함수를 짠 적이 있는가. 더 나아가서 그런 함수들을 모듈화한 것이 있는가. 그 모듈은 범용으로 사용할 수 있도록 자기 완결적으로 설계되었는가. 각함수의 내부는 최적화돼 있는가. 디버깅에 도움이 되는 여러 가지 요소(ASSERT등)를 포함하고 있는가. 그 모듈의 헤더 파일은 모듈의 기능을 충분히 활용할 수 있도록 잘 문서화 되어 있는가. 함수 이름이나 데이터 구조체의 이름은 그 의미를 잘 나타내고 있는가. 열거하자면 끝이 없다.

★ 정열의 가치 여부는 기초에 달려있다 ★

물론 코딩 실력은 하루 아침에 이루어지지 않는다. C나 파스칼 문법을 알고 라이브러리함수를 많이 안다고 해서 코딩을 잘 하게 되는 것은 아니다. 여러가지 다양한 프로그램을 많이 만들어보는 것이 최선이다. 한편 남이 짠 좋은 코드를 보는 것도 도움이 된다. 요즘 개발퉁에는 대부분 클래스 라이브러리 소스가 포함되어 있으므로 좋은 참고가 될 것이다.

많은 프로그래머 지망생들이 전산학의 기본 개념에 무지한데, 그것은 좋지 않은 경향이다. 학교 숙제로 주어지는 자료구조와 알고리즘에 대한 연습이 따분하게 느껴지겠지만 그것은 코딩 실력을 키우는 데 좋은 방편이다. 아울러 이진 트리나 일반화된 리스트(generalized list), 재귀적 호출(recursive call), 해시 테이블(hash table) 같은 방법들은 현장에서 부닥치는 문제 해결에도 도움이 된다.

자신이 지금까지 짜왔던 프로그램들을 돌이켜 보라. 가장 큰 프로그램은 몇 줄짜리였지, 그 중에서 자기가 직접 짠 코드는 몇 줄이었지, 스스로 판단하기에 코딩의 기초가 돼 있다고 생각하는가.

다시 한 번 말하노니, 당신에게 프로그래밍을 향한 정열이 있다면 먼저 그 기초를 튼튼히 하라. 그러지 않으면 그 정열은 허무한 추억만을 남길 것이다.

★
누구나 할 수 있는 일은 다른 사람에게 맡겨라. 자신만이 할 수 있는 일을 할때 프로는 더욱 아름다운 것이다. 프로그래머를 꿈꾸는 젊은이여, 진정 필요한 것은 기교나 고난도 테크닉이 아니라, 프로그래밍의 밑바탕을 차곡차고 다지는 기초이다

[출처] 컴퓨터 프로그래머의 현실 (도움되는 자료) (전국대학생모임(레포트,족보,취업정보,토익자료,자격증자료)) |작성자 sunmo0808