[IT 정보] [CIO Korea] 반백의 개발자가 전하는 '7가지 프로그래밍 레슨' (0)

 

 

 

=================================

=================================

=================================

 

 

 

 

 

 

출처: LINK : http://www.ciokorea.com/news/24382

 

프트웨어 업계에서는 젊은이들이 환영 받는다. 처자식이 있다면 이미 코딩(Coding)을 하기에 너무 늙은 것이다. 30살만 되어도 이미 꺾인 나이 취급을 받기도 한다.

하지만, 똘똘한 애송이가 항상 모든 문제를 해결할 수 있는 것은 아니다. 머리 속에 최신 유행 아키텍처(Architecture), 프레임워크(Framework), 스택(Stack)이 들어 있지만 소프트웨어의 동작 방식에 대한 근본적인 경험이 부족하다. 이런 경험은 이상하고 설명할 수 없는 버그 때문에 몇 주 동안 고생해서야 얻을 수 있다.

많은 프로그래밍 '선배'들은 선배의 말을 듣지 않았기 때문에 결국 엄청난 양의 코드를 작성하는 젊은이들을 보면서 약간의 통쾌함을 느끼곤 한다.

오늘은 공유 정신에 입각해 몇 주 만에 지식으로는 배울 수 없는 여러 교훈에 관해 생각해 보도록 하겠다. 다음 교훈은 오직 자신의 나이를 표시하려면 2 자리의 16 진수가 필요한 사람들만 알고 있는 내용이다.

- 메모리가 중요하다
- 컴퓨터 네트워크는 느리다
- 컴파일러(Compiler)에는 버그가 있다
- 사용자에게는 속도가 중요하다
- 현실의 웹은 절대로 오피스 네트워크만큼 빠르지 않다
- 알고리즘의 복잡성이 중요하다
- 라이브러리가 문제일 수 있다

 

 

메모리가 중요하다

불과 몇 년 전까지만 해도 컴퓨터 RAM 을 기가바이트가 아닌 메가바이트 단위로 표시했었다. 필자가 첫 컴퓨터(Sol-20)를 조립했을 때는 킬로바이트 단위였다.

보드에는 약 64개의 RAM 칩이 있었고 각각 핀이 18개였다. 정확한 숫자는 기억나지 않지만 필자가 직접 납땜을 했던 기억이 난다. 실수라도 하면 메모리 시험을 통과할 때까지 다시 납땜해야 했다.

이런 식으로 RAM을 만지다 보면 RAM을 금처럼 소중하게 다루는 법을 배우게 된다.

그러나 요즘은 RAM을 아무렇게나 할당한다. 조언을 무시하고 메모리가 싸 보인다는 이유로 데이터 구조를 정리하지 않는다. 버튼만 클릭하면 하이퍼바이저(Hypervisor)가 클라우드 인스턴스(Instance)에 16GB 를 추가한다고 생각한다.

그렇다면 오늘날 아마존에서 244GB 가 적용된 인스턴스를 쉽게 대여할 수 있음에도 불구하고 프로그래밍을 하는 사람들이 RAM을 신경 써야 하는 이유가 무엇일까?

그럴만한 이유는 분명히 있다. 쓰레기를 수거하는 데도 한계가 있다. 부모가 자녀의 방을 청소하는 데도 한계가 있다는 뜻이다. 용량을 크게 할당한다 하더라도 메모리를 정리해야 한다. 코감기 환자가 티슈를 사용하듯이 RAM 을 낭비한다면 244GB를 순식간에 소모하게 될 것이다.

그리고 나면 가상 메모리의 위험이 도사리고 있다. RAM이 바닥나면 디스크를 통해 가상 메모리를 돌리기 때문에 소프트웨어 구동 속도가 100 – 1,000배 느려진다.

이론적으로 가상 메모리는 뛰어나지만 실제로는 매우 느리다. 오늘날의 프로그래머들도 RAM이 여전히 귀중하다는 사실을 깨달아야 한다. 그렇지 않으면 개발 중에는 빠르게 동작했던 소프트웨어가 사람들이 몰림과 동시에 느려질 것이며, 결과물이 쉽사리 확장되지는 못할 것이다.

컴퓨터 네트워크는 느리다

클라우드를 판매하는 세일즈맨들은 클라우드를 끝도 없이 미화한다. 마치 천사가 눈만 깜빡 하면 데이터를 옮겨주는 컴퓨팅 천국인양 떠들어 댄다. 데이터를 저장하고 싶다면 영구 백업 저장기능을 제공하는 단순한 웹 서비스를 구매하고 나머지는 잊어버리라는 식이다.

어쩌면 정말로 걱정할 필요가 없을 수도 있다. 하지만 분명 기다림은 필요하다. 컴퓨터의 모든 트래픽은 시간이 소요된다. 컴퓨터 네트워크는 CPU와 로컬 디스크 드라이브 사이의 트래픽보다 훨씬 느리다.

프로그래밍 선배들은 인터넷이 존재하지 않던 시절에 태어나 성장했다. 피도넷(FidoNet)으로 목적지에 가까운 다른 컴퓨터에 전화를 걸어 메시지를 전송했다. 시끄러운 소리를 내는 모뎀을 통해 데이터를 다른 국가로 옮기는데 며칠이 소요되었다.

이런 고통스러운 경험 때문에 로컬 상태로 가능한 많은 연산 작업을 수행하고 모든 것이 최대한 작게 완성된 상태에서만 원거리 웹 서비스를 이용하는 방법을 배웠다.

오늘날의 프로그래머들도 이 교훈을 유효하다. 클라우드 스토리지가 위험할 수 있기 때문에 마지막 순간까지 긴장의 끈을 놓지 말아야 한다는 점을 배울 수 있다.

컴파일러(Compiler)에는 버그가 있다

코드 자체에는 문제가 없어도 문제가 발생하는 경우가 자주 발생한다. 초기 설정을 잊거나 널 포인터(Null Pointer) 점검을 잊었기 때문일 수 있다. 이유야 어찌되었든 모든 프로그래머는 소프트웨어에 문제가 발생하면 그것이 자신의 실수 때문이라는 점을 알고 있다.

하지만 대부분의 짜증나는 오류는 우리의 잘못이 아니다. 때로는 그 원인이 컴파일러 또는 해석기(Interpreter)에 있을 때가 있다.

컴파일러와 해석기가 상대적으로 안정되기는 했지만 완벽하지는 않다. 오늘날의 컴파일러와 해석기의 안정성은 힘들게 얻어낸 결과물이다. 안타깝게도 이런 안정성을 당연한 것으로 여기고 있다.

이것들도 잘못될 수 있다는 점을 기억하고 코드의 디버깅(Dubugging) 시에 이런 점을 고려해야 한다. 컴파일러가 문제가 될 수 있다고 생각하지 않는다면, 며칠 또는 몇 주 동안 머리를 쥐어 뜯고 있게 될 수도 있다.

선배 프로그래머들은 오래 전에 문제의 디버깅을 위한 최선의 해결책이 코드가 아닌 툴 시험이라는 사실을 발견했다. 컴파일러를 절대적으로 신뢰하고 코드를 렌더링(Rendering)하기 위해 실시하는 연산을 신경 쓰지 않는다면 존재하지도 않는 버그를 찾느라 몇 주 동안 머리를 쥐어 뜯게 될 수도 있다. 머지 않은 젊은이들도 이런 교훈을 배우게 될 것이다.

사용자에게는 속도가 중요하다

오래 전, IBM이 사용성에 대해 조사하면서 사람들의 마음이 100밀리초 만에 방황하기 시작한다는 연구 결과를 제시한 바 있다.

IBM의 오래된 녹색화면 앱을 사용해 IBM 메인프레임에 접속해 본 사람이라면 실제로 IBM 이 이런 100밀리초의 한계가 마치 사실인 것처럼 가정해 기기를 개발했다는 사실을 알고 있을 것이다.

그들은 I/O 전기 회로망을 고심했다. 그들은 메인프레임을 판매하면서 자동차 제조사들이 엔진 속의 실린더 수를 세듯이 I/O 채널이 몇 개인지를 보여주는 사양서를 제공했다.

최근 흥미로운 풍경을 목격했다. 한 AJAX 중심 프로젝트가 브라우저로 유입되는 너무 많은 자바스크립트(java-s!crip) 라이브러리와 데이터로 인해 멈추곤 했는데, 한 애송이 프로그래머가 이를 끝끝내 지켜내는 모습이었다. 그리고 결국 그로 인해 다른 사람들도 불평을 멈추어야 한다.

멋진 CSS 를 지원하는 모든 것이 멋있어 보이는 것은 사실이지만 사용자들은 느린 것을 싫어한다.

현실의 웹은 절대로 오피스 네트워크만큼 빠르지 않다

현대적 웹 사이트 때문에 시간을 낭비할 수 있다. 수 메가바이트의 자바스크립트 라이브러리가 도착할 때까지 수 초가 소요될 수 있다. 그리고 브라우저는 이런 JIT 컴파일러를 통해 이런 다계층 메가바이트를 푸시(Push) 처리해야 한다. 전 세계적으로 j쿼리(jQuery)를 처리하는데 소요되는 시간을 합산하면 수 천 또는 수 백만 년이 될 수도 있을 것이다.

아무데나 AJAX를 적용하는 브라우저 기반 툴을 좋아하는 프로그래머들이 이런 실수를 자주 범한다. 사무실에서 시연할 때는 좋아 보인다. 서버가 가까이 심지어 때로는 로컬호스트(Localhost)에서 구동한다. 파일이 빠른 속도로 도착하고 모든 것이 멀쩡해 보인다.

하지만 DSL 라인 또는 과부하가 걸린 기지국을 통해 라우팅(Routing)되는 셀룰러(Cellular) 접속을 이용하는 사용자는 어떨까? 그들은 여전히 라이브러리가 도찰할 때까지 기다려야 한다.

알고리즘의 복잡성이 중요하다

필자는 프로젝트를 진행하다가 문제에 봉착했으며, 성인이 채 되지 않았지만 그리즈몽키(Greasemonkey)를 사용할 줄 아는 사람에게 도움을 청했다.

그는 우리의 코드를 다시 작성하여 보내주었다. 변경사항을 확인한 결과 그가 좀 더 유려하기는 했다. 그러나 필자는 알고리즘의 복잡성이 O(n) 에서 O(n^2)이 되었다는 사실을 발견했다. 그는 일관성을 확보하기 위해 데이터를 목록에 붙여 넣었다. 멋있어 보이기는 했지만 n 의 값이 커지면서 매우 느려질 수 밖에 없었다.

알고리즘 복잡성은 대학의 컴퓨터 공학과정에서 잘 다루고 있는 부분이다. 많은 고등학생들이 주말 동안 스스로 루비(Ruby) 또는 커피스크립트(Coffees!crip)를 배우면서 간과하는 부분이기도 하다.

복잡성 분석이 난해할 뿐더러 그저 이론적인 것으로만 보일 수 있다. 하지만 프로젝트의 규모가 커지면서 큰 차이를 보일 수 있다. n 의 값이 작을 때는 모든 것이 순조로워 보인다. 충분한 메모리가 있을 때 코드가 신속하게 구동할 수 있는 것과 마찬가지로 시험 중에는 나쁜 알고리즘도 좋아 보일 수 있다. 하지만 사용자가 늘어나면 O(n^2) 또는 심지어 O(n^3) 가 소요되는 알고리즘을 기다리는 일은 악몽과도 같다.

필자가 매칭(Matching) 프로세스를 이차 알고리즘으로 바꾸려 했냐고 이 나이 어린 전문가에게 질문하자 그는 머리를 긁적였다. 우리가 하는 이야기를 정확히 이해하지 못했다.

결국 우리가 그의 목록을 해시(Hash) 표로 대체하자 모든 것이 다시 정상으로 돌아왔다. 아마 지금쯤에는 그도 충분히 이해할 만한 나이가 되었을 것이다.

라이브러리가 문제일 수 있다

라이브러리를 작성하는 사람들이 항상 사용자를 최우선으로 고려하지는 않는다.

그들은 도우려 하는 것은 사실이지만 종종 성가신 작은 문제가 아니라 세상을 위해 무엇인가를 개발하곤 한다. 그들은 종종 특정 문제에 특화된 것이 아니라 다양한 버전의 많은 문제를 처리할 수 있는 스위스 군용 칼을 만들곤 한다. 뛰어난 엔지니어링이자 코딩일 수 있지만, 느려질 소지가 있다.

잠깐만 한눈을 팔아도 라이브러리 때문에 코드가 느려지고 그 사실조차 인지하지 못할 수 있다. 필자가 문자열에서 문자를 추출하기 위해 10줄의 코드을 작성했다는 이유로 필자를 조롱한 젊은 프로그래머가 있었다.

"나는 일반 수식과 한 줄의 코드만으로 해결할 수 있다"라고 그가 자신했다.

그러나 그는 자신의 코드 한 줄이 호출할 때마다 일반 수식을 분석하고 다시 분석할 수 있다는 점을 고려하지 않았다. 그는 단순하게 자신이 코드를 한 줄로 작성하는 동안 필자가 10줄을 작성한다는 점만 생각했다.

라이브러리와 API를 적절히 사용하면 좋다. 하지만 내부에서 반복적으로 사용하면 속도에 치명적인 영향을 끼치며 그 이유조차도 알지 못할 수 있다.

 

 

 

 

=================================

=================================

=================================