프로그래밍은 상상이다

총평

못해도 열 학번은 앞선 선배가 들려주는 충고의 느낌으로 재미있게 읽었다. 꽤 오래전에 쓰인 책이라, 당시의 코딩을 바라보는 시각이 지금과는 많이 다르다는 점이 먼저 느껴졌다. Web 3.0이 화두인 오늘, 책 속에는 Web 2.0조차 회의적으로 바라보던 시대의 공기가 담겨 있다. 당시에는 인공지능이 가져올 변화를 예측하기 어려웠을 것이다.

지금은 LLM이 추상적인 요구사항에도 현재 상황에 꼭 맞는 놀라운 코드를 제시하고, 개발자는 그 깊은 의미나 동작 원리를 충분히 이해하지 못한 채 코드베이스에 그대로 복사·붙여넣기 하는 경우가 많다.

저자가 말한 “자기 손으로 직접 타이핑한 코드를, 다른 사람도 아닌 자기 자신이 이해하지 못하는 경우”라는 경고는 단순히 코드 내용을 모른다는 차원을 넘는다. 그 코드를 추가하거나 수정했을 때의 영향, 다른 부분과의 연결 구조까지 이해해야 한다는 메시지였다. 책을 덮으며 문득 돌아본다. 우리는 지금 손에 들고 있는 이 코드 한 줄조차 제대로 이해하고 있는가?

저자의 글에서는 개발에 대한 애정이, 그리고 그 애정을 후학들에게 전하고 싶은 진심이 묻어났다. 덕분에 개발자로서 가져야 할 태도, 자긍심, 직업 정신을 다시금 되새기게 된다.

무엇보다 충분히 상상력을 자극하고, 누구나 공감할 수 있을 만한 코드를 작성하기 위해 더 깊이 숙고하겠다고 다짐한다.

되돌아보기

상상력이 풍부한 프로그래머일수록 객체 상호간의 연관성에 대해서 남보다 더 섬세하게 사고한다. 객체의 역할과 성격을 적확하게 규정하고, 기억 속에 존재하는 디자인 패턴을 끄집어내어 객체들이 이루는 관련성에 깊이 주목한다.

키보드 위를 엄청난 속도로 누비던 프로그래머의 손가락은 어느 순간 문득 멈춘다. 그는 커피를 한 모금 마시고, 잠깐 허공을 바라본다. 한 손은 커피 잔을 들고, 다른 한 손은 여전히 키보드 위에 놓여 있었다. 그리고 그의 마음속에서 논리적 추론이 조용히 고개를 든다.

한번 곰곰이 생각해보자. 우리가 회사에서 하는 일을 하는 8시간 중에서 정말로 ‘일’을 하는 시간은 얼마나 될까?

[샤샤 로보와 홀름 프리베]의 논지에 따르면 집에서건 회사에서건 내가 일에 충분히 집중하지 못하는 이유는 … 환경의 탓이 아니라 내가 하는 일이 결국 ‘나’의 일이 아니기 때문이다.

디지털 시대의 일과 놀이의 경계선

… 학교에서 배우는 내용의 대부분이 현실적으로 별로 쓸모가 없게 된 것만큼이나 분명한 사실이다. …. 내가 회사에서 일을 하기 위해서 사용하는 자바 프로그래밍 언어에 대해서 새롭게 배우는 정도를 나타내는 값은 내가 지금 자바소포트의 웹 사이트나 헤인즈 캐부트(Heinz Kabutz)가 발송하는 뉴스레터를 통해서 배우는 정도를 나타내는 값을 넘지 못할 것이다.

정교한 객체를 설계하고, 최선의 알고리즘을 작성하고, 밤늦도록 버그를 잡는 프로그래밍은 많은 순간, ‘놀이’와 구분하기 어렵다. 뭐라고 말로 설명하기는 어려운데, 프로그래밍이라는 행위 속에는 확실히 놀이의 측면이 다분하다.

프로그래머인 당신을 힘들게 하는 무엇이 있다면 …. 그 무엇이 프로그래밍 자체인 경우는 없을 것이다.

취미로 즐겨보는 컴퓨터 그래픽스

석기 시대의 인류가 물감대신 타다 남은 마루토막으로 동굴의 벽에 멋진 황소의 모습을 그렸듯이, 텍스트 모드라는 시대적 한계에 갇힌 컴퓨터 사용자들은 128개의 문자를 나열해서 꿈을 표현했다. 그들의 상상은 아무런 한계가 없었다.

SOA(Service Oriented Architecture)에 대한 소고

내가 봐서 아무것도 이해할 수 없고 아무 감흥도 얻을 수 없다면, 그 그림은 현대적 기법에 충실한 수준 높은 추상화가 아니라 그냥 쓰레기이다.

매쉬업의 시대

문제는 기술이 아니라 부가가치를 만들어내는 상상력이기 때문이다.

메타언어와 프로그래밍의 추상성

젊은 시절에 사실적인 그림을 그린 피카소가 점차 디테일이 생략된 추상화를 그리게 된 것은 그가 마음속으로 상상하는 이미지가 담는 추상의 수준이 차츰 높아졌기 때문이었을 것이다.

실력이 무르익지 않은 사람들이 작성한 코드를 보면 알고리즘의 내용이 지나치게 직설적이고 평면적이다. 코드의 재사용성, 에러 확인, 유닛테스트, 확장 가능성 등을 고려하지 않고 당장 필요한 논리를 구현하는데 급급하기 때문에 코드에 간결한 함축이나 지시가 없다. 코드가 상상력을 자아내는 시적인 묘사가 아니라 지루한 산문이 된다.

날마다 수십 혹은 수백줄의 코드를 작성하는 프로그래머라면 잠시 생각해보기 바란다. 매일 작성하고 있는 자신의 프로그램이 산문인지 아니면 시인지를.

프로그래머는 산문이 아니라 시를 적어야 한다. 특정한 문맥에 국한된 국한된 구구절절한 산문이 아니라 의미의 확장이 용이하고 탄력적인 시를 써야 하는 것이다. 예컨대 if-else 구문이 산문적인 요소라면, 팩토리 패턴은 시적인 요소다. 100줄 짜리 메소드 1개가 지루한 산문이라면 5줄짜리 메소드 10개는 감칠맛 나는 운문이다. 프로그래머는 시인이다.

AOP(Aspect Oriented Programming)

‘내부타입정의(Inner Type Declaration)’ 기능은 객체에게 새로운 필드를 동적으로 더하는 것을 가능하게 만든다. …. 이러한 기능이 바람직한지에 대해서는 의문이 든다.

AOP는 … 프로그램 코드의 특정 부분, 즉 조인포인트를 프로그래밍적으로 포착할 수 있는 문법, 다시 말해서 프로그램 소스코드 자체를 대상으로 하는 메타데이터를 정의하는 방법을 제공해준다.

유닛테스트의 즐거움

새로운 기능을 구현하는 일을 맡았을 때 요구사항을 철저하게 소화하고, 차분히 설계를 하고, 설계를 다른 사람들과 검토해서 필요한 부분을 수정하고, 코드를 작성하고, 유닛테스트 코드를 작성하고, [그 과정에서] 필요하면 기존 코드의 이러부를 리팩토링하는 일체의 과정을 머릿속에서 그리면서 실제에 가장 근접한 값으로 시간을 예측하는 것은 프로그래머가 갖춰야하는 중요한 능력의 하나이다.

유닛테스트를 작성하는 것이 습관이 된 사람들은 유닛테스트의 옷을 입지 않은 벌거숭이 코드를 작성하는 것이 불안하게 느껴진다.

프로그래밍을 구성하는 일곱 개의 단계

추상에서 구체로 가는 것이 공학이라면, 구체에서 추상으로 가는 것이 프로그래밍인 셈이다.

객체지향, 유닛테스트, 리팩토링, 그리고 소프트웨러의 총체적인 인식

이미 존재하는 소프트웨어에 새로운 기능이나 코드를 더하는데도 불구하고 시스템의 복잡성이 늘어나지 않고 오히려 줄어드는, 그리하여 프로그래머가 시스템 전체의 작동 방식을 이해하는 수준이 낮아지는 것이 아니라 오히려 높아지도록 만드는 경이로운 역전 형상을 가능하게 만드는 것이 바로 객체지향 기법이 가진 마력이다.

유닛테스트 코드가 존재하지 않는 상태에서 리팩토링을 수행하는 것은, 차라리 아무 일도 하지 않는 것보다 나쁘다. 그것은 마치 학술대회에 나선 수학자가 스스로 증명할 수 없는 명제를 내세우면서 자기도취에 빠지는 것보다 더 무책임한 태도라고 말할 수 있다.

자기 손으로 직접 타이핑을 해서 짜 넣는 코드를 다른 사람도 아니고 자기 자신이 이해하지 못하는 경우가 있는 것이다.

애자일 프로그래밍

소프트웨어를 관리할 때에는 빠르게 움직이는 것보다 느리지만 안전하게 움직이는 쪽이 더 바람직하나. 당연한 이야기이지만 애자일은 모든 소프트웨허 프로젝트에 적용될 수 있는 만병통치약이 아닌 것이다.

방어적 프로그래밍(Defensive Programming)

if-else 구문을 삽입하고 싶은 충동을 누르고 대신 새로운 메쏘드나 객체를 만드는 것이 더 올바른 해결책인 경우가 더 많다.

프로그래머가 버그를 만들어내는 것은 버그가 생길 것을 모르고 만들어내는 경우보다 버그가 생길 것을 알고 만들어내는 경우가 더 많다.

시간이 100% 충분하게 주어져서 코드를 완성해 놓고, 방어적 원리를 꼼꼼히 따져보고, 유닛테스트 코드도 작성하고, 코드를 조금씩 수정하다가 이 정도면 완성이 되었다 싶을 때 코드를 제출할 수 있는 프로젝트는 세상에 존재하지 않는다.

방어적 프로그래밍의 원리는 지금 여기에서 단 한줄의 코드를 적어 넣는 상황에서 감각적으로 적용되어야 하며, 그 순간이 지나고 나면 그 코드로 다시 돌아갈 수 있는 경우란 없다.

코드의 웃음을 빼앗아가는 리펑토링(Refunctoring)

객체지향은 민감한 수술과 같아서 잘 하면 큰 병을 낫게 하지만 잘못하면 오히려 몸을 망치기 십상이다. 간단하게 두 줄로 구현할 수 있고, 그 자체로 아무 문제가 없는 코드를 객체지향이라는 명목으로 복잡하게 꼬아놓는 것은 현명한 태도가 아니다.

행복한 프로그래밍

소설가가 자기 혼자 읽기 위해서 소설을 쓰는 것이 아니듯이, 프로그래머 역시 자기 혼자 읽기 위한 프로그램을 작성하는 것이 아니라는 것이다.

소설처럼 읽히는 프로그램 작성하기

경험이 풍부한 고급 프로그래머 중에서조차, 코드의 가독성(redability)을 이러한 ‘코딩 관습’을 통해서 통일시킬 수 있는 코드의 겉모습으로 착각한다는 사실이다.

프로그래밍 실력이 뛰어난 사람일수록 압축적이고 은밀한 코드를 작성하고픈 충동을 자주 느끼게 되는데, 그러한 욕구를 억제하여 의미를 쉽게 전달하는 절제된 코드를 작성하는데 초점을 맞추는 것이 ‘소설처럼 읽히는 프로그램’만들기의 두 번째 요체에 해당한다.