2015.03.11

반백의 개발자가 전하는 '7가지 프로그래밍 레슨'

Peter Wayner | InfoWorld
소프트웨어 업계에서는 젊은이들이 환영 받는다. 처자식이 있다면 이미 코딩(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)하기 위해 실시하는 연산을 신경 쓰지 않는다면 존재하지도 않는 버그를 찾느라 몇 주 동안 머리를 쥐어 뜯게 될 수도 있다. 머지 않은 젊은이들도 이런 교훈을 배우게 될 것이다.
 
CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.



2015.03.11

반백의 개발자가 전하는 '7가지 프로그래밍 레슨'

Peter Wayner | InfoWorld
소프트웨어 업계에서는 젊은이들이 환영 받는다. 처자식이 있다면 이미 코딩(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)하기 위해 실시하는 연산을 신경 쓰지 않는다면 존재하지도 않는 버그를 찾느라 몇 주 동안 머리를 쥐어 뜯게 될 수도 있다. 머지 않은 젊은이들도 이런 교훈을 배우게 될 것이다.
 
CIO의 프리미엄 콘텐츠입니다. 이 기사를 더 읽으시려면 개인정보 등록이 필요합니다. 이미 등록하신 분은 '본인확인'을 해주십시오.

X