(서평) 생각하는 프로그래밍 - 효율에 관한 재밌는 이야기들

사실 프로그래밍에 경험이 생긴다고 모두 다 좋은 코드를 작성하는 것은 아닙니다.

가독성은 물론이며, 속도나 메모리상의 이점을 가진 코드도 많은 경험에서 얻어질 가능성이 높은 것이지 자연스레 얻어지는 것은 아니라고 확신합니다.

이 책은 저자가 경험했거나, 적절하다 생각하는 예제를 놓고 다양한 방법으로 해결을 논합니다. 물론 저자가 거론한 방법이 최선은 아닙니다. 저자도 그렇게 얘기하진 않구요.

효율이란 어느 한 가지 관점에서 이루어져야 하는 것이 아닙니다. 주변 상황에 따라 중요시 여겨야 하는 가치가 달라지므로 그에 맞는 적절한 합의점을 찾아야 한다는 류의 이야기는 이런 류의 책에서 자주 보지만, 진부하다 싶은 감은 있어도 너무 당연한 이야기라 이견의 여지가 없더군요.

알고리즘의 선택에서의 팁이 특히 흥미로웠습니다. 일반적인 퀵정렬이 삽입 정렬이나 선택 정렬보다 느릴 수 있는 상황에 대한 이야기가 아주 적절한 예입니다.

저자는 그런 얘기들을 하면서, 알려진 라이브러리, 자신이 작상했던 함수 등에 대한 맹목적인 믿음을 갖고 코딩을 하지 않았으면 한다는 느낌을 받았습니다. 퀵정렬이 당연히 빠를 것이다라는 믿음에서 올 수 있는 효율성 저하는 단순히 기본 퀵정렬함수보다, 개선한 퀵정렬 함수를 써라가 아니라, 왜 기본 퀵정렬함수가 느릴 수 있는지 이해하고, 개선된 퀵정렬 함수가 왜 효율에 문제가 없는지 이해할 만큼 고민하고 검증하는 과정을 거치라는 이야기가 아니었을까요?

저는 원제인 Programming Pearls보다, 생각하는 프로그래밍이라는 제목이 더 맘에 듭니다. 프로그래밍은 반복되는 작업만하는 단순 노동이 아닙니다. 만약 그랬다면 매크로로 대체될 수 있었겠죠.

그렇기 때문에 어떠한 주제에 대해 한번 더 고민해보는 시도를 할 수 있게 도와준것만으로도 이 책은 가치가 있는 책이었습니다.

(서평) 실용주의 프로그래머 - 실용주의 마인드

누군가 나에게 프로그래머로써 최고의 책을 꼽으라면 무엇을 꼽겠냐고 물어본다면, 난 주저 않고 이 책을 거론한다. 

사실 이런 류의 서적에는 Code Complete 가 있다. Code Complete도 아주 좋은 내용을 담고 있는 책이고, 실제로 더 유명하고 많은 사람에게 교훈을 준 책이지만, 실용주의 프로그래머는 더 좋은 책이다.   무엇보다 실용주의 프로그래머는 좀 더 간결하다. 페이지 수가 더 적다는 의미가 아니다. 지나치게 친절한 과잉 설명도 없이 짧고 적절한 비유를 하고 있으며, 그로 인해 더 즐겁기 때문이다. (더 잘 읽히고, 더 잘 와닿게끔 쓰여있다는 얘기다)

내가 이 책을 Best of Best 프로그래머 필독서 (결코 C++ 프로그래머에게만 좋은 책이 아니다.)로 꼽는 이유는 몇가지 큰 교훈과 습관을 가질 수 있도록 도와주는 책이기 때문이다.

이 책은 어떤 일반적인 상황에 대해 이야기 해놓고, 프로그램 작성시의 비슷한 상황에 대해 이야기하는 식의 전개를 하고 있다.

그 내용은 주로 프로그래머로서 가져야할 이상적인 마음 가짐에 중점을 두고 있다. 코드도 중간 중간 나오긴 하지만, 이해를 돕기 위한 용도이지 소스 코드로 책 내용의 반이상을 차지하거나 그렇진 않는다.

프로그래머로써의 마인드, 협업에 대한 생각, 좋은 프로그래밍 습관 그 어느것 하나 부족함없이 알려준 최고의 책이다.

그들의 실천적이고 효율적인 방법론은 두고 두고 나에게 자극이 될 것이라 믿는다. 그러다보면 나도 그들처럼 실용주의 프로그래머가 되지 않을까?


실용주의 프로그래머 70가지 교훈 정리

  1. 자신의 기술(craft)에 관심과 애정을 가져라. 소프트웨어 개발을 잘 해보려는 생각이 없다면 왜 인생을 그 일을 하면서 보내는가?

  2. 자신의 일에 대해 생각하면서 일하라! 자동 조종 장치를 끄고 직접 조종하라. 자신의 작업을 지속적으로 비판하고 평가하라.

  3. 어설픈 변명을 만들지 말고 대안을 제시하라. 변명하는 대신 대안을 제시하라. 그 일을 할 수 없다고 말하지 말고, 무엇을 할 수 있는지 설명하라.

  4. 깨진 창문을 내버려두지 마라. 눈에 뜨일 때마다 나쁜 설계, 잘못된 결정, 좋지 않은 코드를 고쳐라.

  5. 변화의 촉매가 되라. 사람들에게 변화를 강요할 수는 없다. 대신, 미래가 어떤 모습일지 그들에게 보여주고 미래를 만드는 일에 그들이 참여하도록 도우라.

  6. 큰 그림을 기억하라. 주변에 무슨 일이 일어나는지 점검하는 일을 잊어버릴 정도로 세부사항에 빠지지 마라.

  7. 품질을 요구사항으로 만들어라. 프로젝트의 진짜 품질 요구사항을 결정하는 자리에 사용자를 참여시켜라.

  8. 지식 포트폴리오에 주기적으로 투자하라. 학습을 습관으로 만들어라.

  9. 읽고 듣는 것을 비판적으로 분석하라. 벤더, 매체들의 야단법석, 도그마에 흔들리지 마라. 여러분과 여러분 프로젝트의 관점에서 정보를 분석하라.

  10. 무엇을 말하는가와 어떻게 말하는가가 모두 중요하다. 효과적으로 전달하지 못한다면 좋은 생각이 있어봐야 소용없다.

  11. DRY(Don’t Repeat Yourself) - 반복하지 마라. 어떤 지식 한 조각도 하나의 시스템 안에서는 모호하지 않고, 권위 있고, 단 하나뿐인 표현을 해야 한다.

  12. 재사용하기 쉽게 만들라. 재사용하기 쉽다면, 사람들이 재사용할 것이다. 재사용을 촉진하는 환경을 만들라.

  13. 관련 없는 것들 간에 서로 영향이 없도록 하라. 컴포넌트를 지속적이고, 독립적이며, 단 하나의 잘 정의된 목적만 갖도록 설계하라.

  14. 최종 결정이란 없다. 돌에 새겨진 것처럼 불변하는 결정은 없다. 그렇게 생각하는 대신, 모든 결정이 해변의 백사장 위에 쓴 글자와 같다고 생각하고 변화에 대비하라.

  15. 목표물을 찾으려면 예광탄을 써라. 예광탄은 이것저것을 시도해보고 그것들이 목표와 얼마나 가까운 데 떨어지는지 보는 방법으로 목표를 정확히 맞추게 해 준다.

  16. 프로토타입을 통해 학습하라. 프로토타이핑은 배움의 경험이다. 프로토타이핑의 가치는 만들어낸 코드에 있지 않고, 여러분이 배운 교훈에 있다.

  17. 문제 도메인에 가깝게 프로그래밍하라. 사용자의 언어를 사용해서 설계하고 코딩하라.

  18. 추정을 통해 놀람을 피하라. 시작하기 전에 추정부터 하라. 잠재적인 문제점들을 미리 찾아내게 될 것이다.

  19. 코드와 함께 일정도 반복하며 조정하라. 구현하면서 얻는 경험을 이용해서 프로젝트의 시간 척도를 세밀히 조정하라.

  20. 지식을 일반 텍스트로 저장하라. 일반 텍스트 형식은 시일이 지났다고 못쓰게 되는 일이 없다. 일반 텍스트 형식은 여러분의 작업을 활용하고 디버깅과 테스팅을 쉽게 만드는 데 도움이 된다.

  21. 명령어 셸의 힘을 설명하라. 그래픽 사용자 인터페이스로는 할 수 없는 일에 셸을 이용하라.

  22. 하나의 에디터를 잘 사용하라. 에디터를 마치 손의 연장으로 자유자재로 다루어야 한다. 여러분이 사용하는 에디터는 설정을 바꿀 수 있고, 확장 가능하고, 프로그램 가능해야 한다.

  23. 언제나 소스코드 관리 시스템을 사용하라. 소스코드 관리는 여러분 작업을 위한 타임머신이다. 언제라도 과거로 돌아갈 수 있게 해준다.

  24. 비난 대신 문제를 해결하라. 버그가 여러분 잘못인지 다른 사람 잘못인지는 별로 중요하지 않다. 그것은 여전히 여러분의 문제이며, 여전히 고쳐야 할 필요가 있다.

  25. 디버깅을 할 때 당황하지 마라. 숨을 깊게 들이쉬고, 무엇이 버그를 일으키는지 ‘생각하라!’

  26. ‘select’는 망가지지 않았다. OS나 컴파일러의 버그를 발견하는 일은 정말 드물게 일어나며, 심지어 서드파티 제품이나 라이브러리일지라도 드문 일이다. 버그는 애플리케이션에 있을 가능성이 가장 크다.

  27. 가정하지 마라. 증명하라. 진짜 데이터와 경계 조건이 있는 실제 환경에서 여러분이 내렸던 가정들을 증명하라.

  28. 텍스트 처리 언어를 하나 익혀라. 여러분은 하루 가운데 많은 시간을 텍스트와 씨름하며 보낸다. 왜 여러분 대신 컴퓨터가 그 일의 일부를 하게끔 하지 않는가?

  29. 코드를 작성하는 코드를 작성하라. 코드 생성기는 생산성을 향상시키며 중복을 막는 일에도 도움이 된다.

  30. 완벽한 소프트웨어는 만들 수 없다. 소프트웨어는 완벽할 수 없다. 피할 수 없이 나타나는 에러로부터 여러분의 코드와 사용자들을 보호하라.

  31. 계약에 따른 설계를 하라. 코드가 실제로 하기로 한 것을 문서로 만들고 검증하려면 계약을 사용하라.

  32. 일찍 작동을 멈추게 하라. 보통은 죽은 프로그램이 절름발이 프로그램보다 해를 훨씬 덜 끼친다.

  33. 단정문을 사용해서 불가능한 상황을 예방하라. 단정은 여러분이 세운 가정을 검증해준다. 확실한 것이 없는 세상에서 여러분의 코드를 보호하려면 단정문을 사용하라.

  34. 예외는 예외적인 문제에 사용하라. 예외를 잘못 쓰면 고전적 스파게티 코드의 모든 가독성과 유지보수 문제를 그대로 겪을지도 모른다. 예외는 예외적인 일들만을 위해 남겨두어라.

  35. 시작한 것은 끝내라. 가능하다면, 자원을 할당한 루틴이나 객체가 해제도 책임져야 한다.

  36. 모듈 간의 결함도를 최소화하라. 디미터 법칙을 적용하고 ‘부끄럼 타는’ 코드를 작성해서 결합이 생기는 일을 피하라.

  37. 통합하지 말고 설정하라. 애플리케이션에서 기술 선택을 설정 옵션으로 구현하고, 통합하거나 만들어 넣지 마라.

  38. 코드에는 추상화를, 메타데이터에는 세부 내용을. 프로그램은 최대한 일반화해서 만들고, 세부사항들은 가능하면 컴파일된 코드 기반 바깥으로 빼라.

  39. 작업 흐름 분석을 통해 동시성을 개선하라. 사용자의 작업 흐름이 허용하는 동시성을 최대한 활용하라.

  40. 서비스를 사용해서 설계하라. 서비스, 곧 잘 정의되고 일관성 있는 인터페이스를 통해 의사소통하는 독립적이고 동시성 있는 객체들의 관점에서 설계하라.

  41. 언제나 동시성을 고려해 설계하라. 동시성이 가능하도록 설계하면 더 적은 가정만 내리고서도 더 깔끔한 설계를 할 수 있다.

  42. 모델에서 뷰를 분리하라. 애플리케이션을 모델과 뷰의 관정으로 설계해서 적은 비용만 들이고도 유연함을 얻어내라.

  43. 칠판을 사용해서 작업 흐름을 조율하라. 참여하는 요소들의 독립성(independence)과 고립성(isolation)을 유지하면서도 개별적인 사실과 에이전트를 잘 조율하려면 칠판을 사용하라.

  44. 우연에 맡기는 프로그램을 하지 마라. 정말 믿을 만한 것만 믿어야 한다. 우발적인 복잡함을 조심하고, 우연한 행운을 목적의식을 가지고 만든 계획과 착각하지 마라.

  45. 여러분의 알고리즘을 차수를 추정하라. 코드를 작성하기 전에, 실행 시간이 대략 얼마나 걸릴지 감을 잡아 놓아라.

  46. 여러분의 추정을 테스트하라. 알고리즘의 수학적 분석이 모든 거을 다 알려주지는 않는다. 실제 대상 환경에서 코드의 수행 시간을 측정해보라.

  47. 일찍 리팩터링하고 자주 리팩터링하라. 정원의 잡초를 뽑고 식물 배치를 조정하는 것과 똑같이, 코드도 필요할 때면 언제라도 다시 작성하고 다시 작업하고 다시 아키텍처를 만들라. 문제의 근원을 해결하라.

  48. 테스트를 염두에 두고 설계하라. 코드를 한 줄이라도 쓰기 전에 테스팅에 대해 생각하기 시작해야 한다.

  49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다. 가차없이 테스트하라. 사용자가 여러분을 위해 버그를 찾게 하지 마라.

  50. 자신이 이해하지 못하는 마법사가 만들어준 코드는 사용하지 마라. 마법사는 엄청난 양의 코드를 만들 수 있다. 그것들을 프로젝트에 통합해 넣기 전에 그 코드 내용을 전부 이해하는지 확실히 해놓도록 하라.

  51. 요구사항을 수집하지 말고 채굴하라. 요구사항이 지면에 놓여있는 경우는 퍽 드물다. 보통은 가정과 오해, 정치의 지층들 속 깊이 묻혀 있다.

  52. 사용자처럼 생각하려면 사용자와 함께 일하라. 시스템이 정말로 어떻게 사용될지 통찰력을 얻을 수 있는 가장 좋은 방법이다.

  53. 구체적인 것보다 추상적인 것이 더 오래간다. 구현 말고 추상에 투자하라. 추상은 서로 다른 구현이나 새로운 기술의 출현 때문에 빗발치듯 생기는 변화를 견뎌내고 살아남을 수 있다.

  54. 프로젝트 용어사전을 사용하라. 프로젝트에서 쓰이는 특정 용어와 어휘들의 유일한 출처를 만들고 유지하라.

  55. 생각의 틀을 벗어나지 말고 틀을 찾아라. 해결할 수 없어 보이는 문제와 마주쳤을 때 진짜 제약 조건을 찾아라. 자신에게 이렇게 물어보라. ‘정말로 반드시 이런 방식으로 해야 하는 일인가? 꼭 해야만 하는 일이긴 한 건가?’

  56. 준비가 되었을 때 시작하라. 여러분은 살아오면서 경험을 쌓아왔다. 자꾸 거슬리는 의혹을 무시하지 마라.

  57. 어떤 일들은 설명하기보다 실제로 하기가 더 쉽다. 명세의 나선에 빠지지 마라. 언젠가는 코딩을 시작해야 한다.

  58. 형식적 방법의 노예가 되지 마라. 여러분의 개발 실천방법과 개발 능력의 맥락 안에 넣어보지 않고 맹목적으로 어떤 기법을 채택하지 마라.

  59. 비싼 도구가 더 좋은 설계를 낳지는 않는다. 판매상들의 과장, 어떤 분야의 도그마 그리고 가격표의 휘광에 넘어가지 마라. 도구 자체의 장점만 갖고 판단하라.

  60. 팀을 기능 중심으로 조직하라. 설계자와 코더를, 데스트 담당자와 데이터 모델 담당자를 분리시키지 마라. 코드를 만드는 방식에 맞춰 팀을 만들어라.

  61. 수작업 절차를 사용하지 마라. 셸 스크립트나 배치 파일은 똑같은 명령을 똑같은 순서로 어느 때라도 반복해서 실행해준다.

  62. 일찍 테스트하고 자주 테스트하라. 자동으로 테스트하라. 매번 빌드할 때마다 실행되는 테스트가 책꽂이의 테스트 계획보다 훨씬 효과적이다.

  63. 모든 테스트가 통화하기 전에 코딩이 다 된 게 아니다. 뭐 더 할 말 있나?

  64. 파괴자를 써서 테스트를 테스트하라. 코드의 별도 복사본을 만들고, 그 복사본에 고의로 버그를 넣은 다음 테스트가 잡아내는지 검증하라.

  65. 코드 범위보다 상태 범위를 테스트하라. 중요한 프로그램 상태들을 파악해서 테스트하라. 단지 많은 코드 줄 수를 테스트 범위 안에 넣는 것만으로는 충분하지 않다.

  66. 버그는 한 번만 잡아라. 인간 테스터가 버그를 찾아내면, 그 때가 인간 테스터가 그 버그를 찾는 마지막 순간이 되어야 한다. 그 순간 이후부터는 자동화된 테스트가 그 버그를 담당하도록 하라.

  67. 한국어도 하나의 프로그래밍 언어인 것처럼 다루라. 코드를 작성하는 것처럼 문서도 작성하라. DRY 원칙을 존중하고, 메타데이터를 사용하고, MVC 모델을 쓰고, 자동 생성을 이용하고 등등.

  68. 문서가 애초부터 전체 중 일부가 되게 하고, 나중에 집어넣으려고 하지 마라. 코드와 떨어져서 만든 문서가 정확하거나 최신 정보를 반영하기는 더 어렵다.

  69. 사용자의 기대를 부드럽게 넘어서라. 사용자들이 무엇을 기대하는지 이해한 다음, 그것보다 약간 더 좋은 것을 제공하라.

  70. 자신의 작품에 서명하라. 옛날 장인들은 자신의 작업 결과물에 서명하는 일을 자랑스럽게 여겼다. 여러분도 마찬가지여야 한다.

(서평) 뉴욕의 프로그래머 - 실수를 두려워하지 말지어다

토요일에 읽기 시작해, 일요일에 끝냈으니 매우 금방 읽은 책이다. 그만큼 재미있게 읽었다.

임백준씨의 저서는 모두 다 갖고 있고, 임백준씨의 철학에 깊은 감명을 받은지라 이번 책도 기대를 하지 않을 수 없었다.

이 책에서 가장 인상 깊었던 인물은 로버트였다.

사실 나는 실수를 잘 견디지 못한다. 내가 실수를 하고 나면 모두가 나를 원망하는 것 같고, 내 잘못이 너무 크게 느껴져 괴로움에 몸부림 치곤하니 말이다.

실수를 두려워 하는 사람은 성장할 수 없다는 본문의 내용을 보고 많은 것을 느꼈다.

내 실수를 변호하고, 옹호하려는 것이 아니라, 실수에서 얻는 것이 있다면 그 실수를 두려워 할 필요가 없는 것 아닌가?

그런 생각이 드니 내 마음이 조금은 편해지는것 같았다. 꼼꼼한점이 부족하고, 빠른 결과물을 내려다 실수하는 내 자신이 한심해지기도 했지만, 그런 문제점을 나 자신이 파악하고 있고, 나아지고 있는 중이라는 점으로 위안을 삼았다.

긴박한 상황에서 버그를 잡을 때, 사실 나는 일반적인 상황에서, 로직적인 상황에서의 추리를 하곤하는데, 톰의 일반적이지 않은 상황까지 추리해내는 기지에는 감탄을 금치 못했고, 프라빈과 같은 천재 이야기를 보면서는 프라빈 정도는 아니더라도 천재라 느낄만한 프로그래머를 만나봤던 나로선 모짜르트라는 천재를 보고 괴로워했던 살리에르의 기분을 다시금 떠올리게 되었다.

이브와 같은 마인드는 아니었지만, 이브 처럼 우연에 맡기는 프로그래밍을 하는 실수했던 날, 이만큼 성장하게 도와준 동료들도 고맙고, 지금껏 나를 돌아볼 수 있는, 내 마음을 다 잡을 수 있는 좋은 책이었다고 생각한다.

아직 현업에 뛰어들지 않은 프로그래머 지망생들이 이 책을 본다면, 이브와 같은 한심한 마인드를 가지지 않으면서, 로버트처럼 실수에 지나치게 괴로워 하는 용기없는 사람이 되지 않았으면 좋겠다는 생각이 들었던 책이다.

(서평) 해커와 화가

해커이면서 동시에 미술적인 분야에 눈을떠 색다른 시각의 의견을 자주 내놓는다는 폴 그레이엄!

기대를 갖고 본 책이었습니다.

저는 조엘의 책을 보면서 그의 통찰력과 의견에 동의했었는데요, 이번에도 마찬가지였습니다.

조엘이 주로 프로그래머로서의 시각으로 이야기 했다면, 제가 느낀 폴 그레이엄은 책 이름과는 달리 사람 그 자체에 대해 이야기를 한 부분도 많았습니다.

책에도 써있는 이단적인 통찰과 현실적인 지혜라고 써져있는데 맞는 얘기가 참 많습니다만…!

조금은 여유가 있는 프로그래머들에게 한정된 이야기 아닌가 싶은 투정도 부리면서 읽게 됐던 책입니다.

이 책을 읽게된 계기는 임백준씨에게 많은 감명을 받았는데, 그런 임백준씨의 역서이자 추천서라서 더욱 더 관심을 갖고 읽게 됐는데요, 임백준씨의 프로그래밍에 대한 애정과 자부심이 폴 그레이엄의 영향도 어느정도 있지 않았을까 싶은 생각도 이 책을 읽으면서 들었습니다.

자신의 직업과 자신의 업무, 자신의 생활에 좀 더 자부심을 갖고 일하라는 메시지가 아닐까 싶네요.

(서평) API로 배우는 윈도우즈 구조와 원리

내가 처음본 API서적은 국내에서 가장 유명(아닐지도 모르지만)한 김상형씨의 API 정복이었다. 물론 나역시도 만족했고, 현재도 WIN32 API 레퍼런스로 사용하고 있다.

API란 Application Programming Interface라는것, 그리고 기본적인 프로그래밍에 필요한 함수 집합이라는것은 알고 있었지만, 다들 배워야 한다기에, 다들 알아야한다기에 접했을뿐 별다른 감흥은 없었고, 더 알고 싶지도 않았다.

컴퓨터 공학을 공부하다보니 운영체제란 과목이 있었지만, 설명이 부족해선지, 아니면 교재가 좋지 않아선지 별 흥미를 느끼지 못했고, 다른 과목보다 관심도가 낮았다.

프로그래밍을 하는데, 왜 운영체제가 필요한지는 의문이었었고, 윈도우 프로그래밍에 필요한 내용을 어느정도 선(멀티 태스크, 멀티 쓰레드, 이벤트 프로그래밍, 핸들, 인스턴스등 기본 개념)까지는 알고 있었기 때문에, 괜찮다고 생각했다.

하지만 그렇지는 않았다.

신기술의 이해를 위한 바탕에는 그 근본 원리를 아는것이 중요했고, 프로그래밍의 근본 원리에는 그 바탕이 되는 운영체제에 대한 이해, 데이터 구조에 대한 이해, 그 언어에 대한 이해등 많은 지식이 필요하고, 그 중 하나인 운영체제에 대한 이해를 놓친 내가 바보같기도 했지만, 후회만 하고 있을수없기에, 운영체제에 관련된 책을 몇권 구입하게 되었다. (이 책도 그중에 하나였다)

여러권 구입한 책들중 (API 정복의 경우는 미리 사둔 책이라 예외다) 가장 설명이 잘 되어있었다.

책의 두께, 많은 페이지수, 긴 설명 이런게 중요한것이 아니다. 운영체제와 그 구동 원리를 이해하는데에 핵심적인 내용은 모두 담고있고, 어떠한 책이든간에 모든 정보를 담을순 없다. (에세이나, 소설, 수필, 참고서등은 당연히 예외다) 다른 참고 자료 혹은 참고 서적을 봐야하는건 어떠한 경우에나 마찬가지이고, 이 책도 마찬가지로 부족한건

다른 책을 참고해야했지만, 윈도우에 대한 개념을 잡아주는데에(사실 윈도우나 유닉스나 리눅스나 그 근본구동원리나 기능은 비슷하기에 하나만 잘해도 나머지는 어느정도선까지 따라오기 마련이다) 큰 역할을 했다.

프로그래밍을 좀 더 잘하기 위해 운영체제에 대해 알고 싶으신분이나, 윈도우의 원리에 대해 궁금하신분은 주저 말고 선택하시길 바란다.