neozest : neo+zest

마법사님의 트윗으로 부터 인사이트 출판사의 전자책 서비스 종료 소식을 접했다.  먼저 13년 동안 묵묵히 운영해 온 인사이트에게 독자의 한사람으로서 감사의 마음을 표한다. 인사이트 전자책 서비스는 단순한 전자책 판매 서비스가 아니라 국내 IT 출판 업계의 가장 진보적이고 실험적인 시도였다고 생각한다.

출판사 블로그를 되돌아 보니 2012년 4월 18일 PDF로 전자책 서비스를 시작했다.  Mobi도 아니고 ePub도 아닌 PDF파일을, 그것도 수작업 결제 처리로 전자책 서비스를 시작한다는 것은 당시로서는 상상하기 어려운 모험이었을 것이다.(만약 내가 사업 담당자라면 이 서비스를 기획한 사람을 싫어했을 것이다.) 더욱 놀라운 것은 서비스 철학이었다. 암호도 없고, DRM도 없이 그냥 자유롭게 자신이 좋아하는 뷰어로 볼 수 있도록 PDF 파일을 보내주는 방식. 기술적으로는 단순하지만 사업적으로는 위험한 선택이었음이 분명하다. 하지만 이 점이 인사이트 전자책 서비스의 정체성을 제대로 드러낸다고 생각한다.

13년간 이 서비스가 지속될 수 있었던 것은 기술력이라기 보다는 철학 때문이리라. 한기성 사장님께 불법적인 PDF 유통이나 허락되지 않은 AI 학습에의 활용이 걱정되지 않느냐고 여쭤본 적이 있었다.  "허허.. 그 분들은 우리 책의 독자가 원래 안될 분이지 않을까요? 오히려 우리 독자분들에게 불편함을 드릴 수는 없지 않나요?"라는 사장님의 말씀에 이 서비스의 본질이 들어있다. 독자와의 신뢰 관계. 고객 중심에서 생각하는 서비스... 단순히 책이라는 상품을 만들어 사고 파는 것이 아니다.

개인적으로 미국에서 개발자 생활을 했었는데, 인사이트의 DRM-Free PDF는 정말 소중한 존재였다. 언어의 장벽없이 고급 콘텐츠를 누리고 싶은데, 교보나 예스 24같은 전자책 플랫폼은 당시 해외에서 사용하기에 여러 제약이 있었다. 본인 인증부터 시작해서 느린 인터넷 환경때문에 DRM인증 자체가 실패하거나 국가 제한에 걸려 보지못하는 경우도 있었다. 그런 상황에서 인사이트의 PDF는 단순히 파일을 다운로드 받아 자유롭게 책을 읽을 수 있는 기쁨을 제공했다. 아이패드든 킨들이든 노트북이든 상관없이 말이다. (하지만 나는 인사이트의 종이책을 너무 사랑해서 한국에 들릴 때마다 잔뜩 사들고 갔다. 한국과 미국을 거쳐 다시 돌아온 나의 책들...)

아쉽게도 인사이트의 Free DRM 실험은 IT 출판 업계 전반으로 확산되지 못했다. 다른 출판사들이 이렇게 못한 이유는 분명하다. 위험 부담이 너무 크고, 수익성에 대한 확신이 없기 때문이다. 특히 최근 인공지능의 확산 속에 허락받지 않은 학습에의 오용도 한 몫했으리라. 하지만 오라일리의 SafariBooks처럼 출판사들이 협력하는 플랫폼이 국내에서도 더 활성화되었으면 좋겠다. 기술적으로는 지금도 충분히 구현가능하지만, 업계의 의지와 독자의 인식 변화가 필요한 부분이다. (아직 AI 학습에 활용하는 문제는 역저자와 출판사, 출판사와 출판사의 권리 관계가 명확히 정리되지 않았다.)

비 오는 저녁, 한 시대의 마감을 지켜보며 드는 생각이다. 우리나라가 K-IT Contents 강국이 되는 날이 올 수 있을까 하는 막연한 생각을 해본다.

* 덧글>  FreeDRM PDF  전자책 서비스는 중단되고, 교보 EBook서비스로는 인사이트 전자책을 계속 만날 수 있다고 한다.

트위터에서 우연히 다음과 같은 이미지를 봤습니다. 이걸 깨닫는데 20년 이상이 걸렸다라는 부제가 있습니다.

스르륵 읽어보니 마음에 듭니다. 제 생각을 곁들여 우리말로 풀어 봅니다. 제가 이해한 대로 뜻풀이+제 생각 덧대기를 한 것이므로, 원 저자의 생각과 다른 부분이 있을 수 있습니다.

1. 단지 배우기만 하는 것에는 덜 집중하고, 행동으로 옮기는데 더 집중하라.

개발자가 새로운 기술을 익힐 때 종종 빠지는 함정이 있다. 튜토리얼을 완주하고, 문서를 읽고, 강의를 듣는 것으로 학습이 끝났다고 여기는 것이다. 하지만 실제로는 그때부터 진짜 학습이 시작된다.

우리가 무언가를 배운다는 것은 지금 알고 있는 지식으로 해결하지 못한 문제를 풀기 위한 것이다.따라서 Doing, 지식을 이용하여 문제를 해결하는데 좀 더 집중해야 한다. 학습이란 무언가를 배우는 행위(學)에 그것을 실제로 적용해 보면서 몸에 익히는 과정(習)이다.

<머신러닝 마스터클래스>의 저자 민재식 박사가 언급한 접근법이 인상적이었다. 머신러닝을 학습할 때 필요한 수학 분야를 먼저 파악하고, 해당 영역을 공부하면서 동시에 머신러닝을 익혔다는 것이다. 목적이 명확할 때 학습의 효율성이 달라진다는 점을 보여주는 사례다.

뭔가를 배울 때에는 배우는 목적을 상기할 필요가 있고(가르치는 사람 입장에서), 문제를 해결하기 위해 무엇을 배워야 하는지 순서를 바꿔보면 도움이 되겠다(배우는 사람 입장에서)는 생각이 든다.

2. 버그를 고치다보면 빠르게 배운다.

완벽한 코드를 처음부터 작성하는 개발자는 존재하지 않는다. 버그는 단순한 실수가 아니라 우리가 문제를 완전히 이해하지 못했다는 신호다.

디버깅 과정에서 우리는 처음 문제를 분석할 때 놓쳤던 부분들을 발견하게 된다. 이 과정에서 일어나는 학습은 일반적인 이론 학습보다 훨씬 깊은 이해와 통찰을 얻을 수 있고 지속적인 성장이 가능하다. 이 과정이 실제 맥락 안에서 일어나는 학습이기 때문이다.

3. 해결책은 항상 간단하게 시작해서 반복하면서 발전시켜나가자.

습(習)이라는 글자는 새끼 새가 날개짓을 연습하는 모습을 형상화한 것이라고 한다. 하얀 날개를 가진 새끼 새도 처음부터 완벽하게 날지 못한다. 작은 동작부터 시작해서 점진적으로 복잡한 비행을 익혀간다.

소프트웨어 개발도 마찬가지다. 처음부터 완벽한 아키텍처를 설계하려 하기보다는, 작동하는 최소한의 것부터 만들어서 점진적으로 개선해나가는 것이 현실적이다. 이런 접근법이 실패의 리스크도 줄이고 학습의 기회도 늘린다.

4. 자주 실패하는 것이 비싼 댓가를 치르지 않는다.

큰 단위로 개발하고 나서 실패하면 그 댓가는 크다. 시간, 비용, 그리고 심리적 타격 모두 상당하다. 반면 작은 단위로 자주 시도하고 빠르게 피드백을 받으면, 개별 실패의 비용은 작지만 전체적으로는 더 안전한 경로를 걸을 수 있다.

이론적으로는 당연한 이야기지만, 실제로 실행하기는 쉽지 않다. 특히 완벽주의 성향이 있거나 실패에 대한 두려움이 클 때는 더욱 그렇다. 하지만 경험상 미루고 묵혀두면 결국 더 큰 문제가 되는 경우가 많았다.

5. 계획을 세운 뒤 코드를 작성하자.

개발과 코딩은 다르다. 개발은 문제를 이해하고 해결 방법을 설계하는 것이고, 코딩은 그 설계를 프로그래밍 언어로 구현하는 것이다. 순서가 바뀌면 좋은 결과를 기대하기 어렵다.

키보드를 두드리기 전에 먼저 생각하는 시간을 갖는 것. 간단해 보이지만 실제로는 상당한 훈련이 필요한 습관이다.

6. 뭔가 잘 안된다면 새로운 것을 배우는 중이라는 뜻이다.

어려움에 부딪혔을 때 좌절하기보다는 성장의 기회로 받아들이는 관점이 중요하다. 모든 것이 순조롭게 진행된다면 새로 배우는 것이 없다는 뜻이기도 하다.

물론 일상적인 업무는 안정적으로 처리해야 하지만, 의도적으로 자신의 역량보다 조금 높은 수준의 도전을 찾아가는 자세도 필요하다.

7. 코드 품질이 중요하다. 의도가 명확히 드러나는 코드를 작성하자.

코드는 일종의 번역 작업의 결과물이다. 인간의 언어로 표현된 문제와 해결책을 컴퓨터가 이해할 수 있는 언어로 옮기는 것이다. 좋은 번역이 원문의 의도를 정확히 전달하듯, 좋은 코드는 개발자의 의도를 명확히 드러내야 한다.

의도가 명확한 코드는 별도의 문서 없이도 스스로를 설명한다. 이런 코드는 유지보수 비용을 크게 줄여준다.

8. 피드백을 받고, 도움을 요청하자.

성장의 핵심은 도전과 피드백의 순환 구조를 만드는 것이다. 혼자서 모든 것을 해결하려고 하는 것은 비효율적일 뿐만 아니라 성장 기회를 놓치는 일이기도 하다.

코드 리뷰, 페어 프로그래밍, 멘토링 등 다양한 형태로 피드백을 받을 수 있다. 중요한 것은 도움을 요청하는 것을 부끄러워하지 않는 것이다. 적절한 도움 요청은 프로페셔널의 자질이다.

9. 항상 작성한 코드를 테스트해보아야 한다. 테스트 자동화를 배워라.

AI가 코드 작성을 도와주는 시대가 되어도 테스트의 중요성은 변하지 않는다. 오히려 더 중요해질 수도 있다. 자신이 작성한 코드에 대한 책임은 여전히 개발자에게 있기 때문이다.

반복적인 테스트 작업을 자동화하는 것은 단순히 시간을 절약하는 것 이상의 의미가 있다. 코드의 품질을 지속적으로 보장하는 안전망 역할을 한다. 이광근 교수님이 운영하는 쉬운용어 사전에서 회귀 테스트를 퇴행 방지, 여전히 동작하는지 검사하는 것이라 풀어낸 것을 봤다. 우리가 작성한 코드가 쉽게 상하지 않도록 테스트하고, 자동화해야 한다.

10. 문제를 푼 다음에 코드를 작성하자.

코드를 작성하기 전에 해결하려는 문제를 정확히 이해해야 한다. 때로는 코드를 작성하지 않는 것이 가장 좋은 해결책일 수도 있다.

문제를 제대로 이해하지 못한 채 작성된 코드는 결국 다시 작성해야 할 가능성이 높다. 처음에 시간을 충분히 투자해서 문제를 분석하는 것이 전체적으로는 더 효율적이다.

11. 디버깅은 어렵다. 디버깅하는 방법부터 숙달하자.

코드를 작성할 때와 디버깅할 때는 다른 종류의 사고 과정이 필요하다. 전자는 구성적이고 창조적인 사고라면, 후자는 분석적이고 추론적인 사고다.

디버깅 능력은 단순히 도구 사용법을 아는 것 이상이다. 체계적으로 문제를 분석하고, 가설을 세우고, 검증하는 방법론을 익혀야 한다. 이런 프레임워크가 있으면 복잡한 문제 상황에서도 당황하지 않고 차근차근 접근할 수 있다.

이 11가지 관찰은 완성된 원칙이라기보다는 개발 과정에서 지속적으로 되돌아볼 만한 지점들이다. 기술은 빠르게 변하지만, 문제를 해결하는 근본적인 접근법은 상당히 일관된 면이 있다는 생각이다.