평소 좋아하던 싱어송라이터인 한로로(본명 : 한지수)의 책이 나와서 사봤다.

 

사실 큰 기대를 하며 책을 구매하지는 않았다.
호기심 반, 팬심 반에 마침 HTTP 완벽 가이드를 구매하려고 했던 터라 같이 주문했다.

 

나는 노래를 들을 때 가사를 제일로 보는데,
한로로는 작사 능력이 상당히 출중하다. 국어국문학과 출신의 기예라고 생각한다.

 

같은 이유로 좋아하는 가수들은 비틀즈, 아이유, 백현진 등..

여러 가수, 그룹들이 있다.

 

여기서부터는 소설 "자몽살구클럽"에 대한 스포와
주관적 해석이 있으니 주의하자.

자몽 살구 클럽

 

작중에서 화자로 등장하는 중학교 1학년 김소하는 삶의 의미를 찾지 못하는 청춘이다.

아빠는 알콜중독자에 가정폭력봄이고, 자신에게 유일하게 친절하던 엄마는 도망갔다. 친구도 하나 없다.

 

말 그대로 삶의 기둥 없는 나날들을 보내다

어느 날 자몽살구클럽이라는 동아리 모집 공고를 본다.

 

죽고 싶지만 실은 살고 싶은 자들의 모임, 서로를 지탱하자는 그
이야기에 오랜만의 흥미를 느낀 소하는 그들을 찾아간다.

 

자몽살구클럽의 멤버들은 총 4명으로 각자의 아픔을 지니고 있다.

엄마의 높은 기대와 억압 속에 괴로워하지만 밝은 척하는 리더 하태수

암 투병중인 엄마를 사랑하는, 영화감독을 꿈꾸는 이보현

태수의 오랜 친구인 나유민 

 

화자인 소하의 입장에서 그들은 어른처럼 보일지 몰라도
사실은 모두 앳된 소녀들이다.

 

이야기가 진행되며 소하는 자몽살구클럽의 회원들과 유대를 쌓게 된다.

함께 일탈하고, 이야기하고, 여행하고, 즐기며 삶의 의미를 찾게 된다. 

 

그러던 중 엄마와의 갈등이 심화된 태수는 자해의 흔적과 함께 나타나
그 응어리를 풀기 위해 한바탕 회원들과 노래하며 춤춘다.

 

그리고 그날 새벽 학교 옥상에서 자살한다.

 

유민은 자신을 지탱하던 가장 절친한 친구를 잃었고,
태수의 엄마는 강박적으로 키워내던 소중한 딸을 잃었다.

각자가 최선이라 생각한 길은 모두의 최악으로 돌아왔다.

 

이건 언뜻 엄마를 향한 태수의 복수라고 생각한다.
딸을 위해 살던 엄마에게 희생당한 태수가 그녀에게서 딸을 빼앗았다.

 

태수를 떠나보낸 절친한 친구 유민은 자몽살구클럽 회원들과 함께

그녀가 좋아하던 음악선생님의 도움을 받아 장송곡을 준비한다.

 

보현과 소하는 어설픈 실력으로 캐스터네츠와 트라이앵글을, 음악선생님은 피아노를 유민은 노래를 한다.

생전 태수는 유민의 노래를 좋아했기 때문이다.

이런 배경설정과 가사는 자몽살구클럽 EP의 수록곡인 To. __에 잘 녹아져 있다.

 

그러던 중 소하는 자몽살구클럽 회원들과 함께 엄마를 찾아 나선다.
우여곡절 끝에 찾아낸 엄마는 학대받던 지난날과는 달랐다.
생기 넘치는 얼굴에 어여쁜 카페사장과 예쁜 아이와 남편이 있었다.

 

소하를 지탱하던 마지막 조각이 무너졌다.
유일하게 친절하던 기억 속의 엄마는 내가 아닌 다른 아이를 안고 있었고
소하가 돌아갈 집은 없었다.

 

돌아온 소하는 여느 때처럼 아빠의 학대를 받는다.

그때, 태수에게 받은 용기였을까, 혹은 어린 날의 조종이었을까.
소하는 자고 있는 아빠를 식칼로 찔러 살해한다.

 

자기밖에 모르던 아빠는 딸에게 자신을 잃었다.

 

결국 소설은 끊임없이 등장인물들을 고문한다.

아픔은 쉴 새 없이 그들을 조여 오고 작가는 이를 특유의 표현법으로 풀어낸다.

 

지금 와서 읽어본 클럽의 제목 자몽살구클럽은 
실제로 먹어보면 굉장히 쓴 자몽과, 달달한 살구가 번갈아가며 느껴지기에
자몽살구클럽이 아닌가 싶다.

 

잡설이 길었는데 한마디로 아픔을 조명하는 소설이다.

 

여기에 소설을 기반으로 한 자몽살구클럽 EP의 수록곡들까지 더해지며

독자는 공감과 몰입의 경험을 얻게 된다.

내용과 전개 자체는 별 거 없지만 특유의 표현력에 몰입하게 한다.

혹시라도 페이지를 되돌리면 태수가 돌아올까 앞으로 넘어가기도 했다.

 

큰 기대 없이 봤는데 생각보다 몰입감 있게 보았다. 

혹시라도 책을 읽게 된다면 동명의 EP도 들어보길 추천하낟.

 

마지막으로 자몽살구클럽의 해산멘트를 외치며 마무리한다.

 

나는 살구싶다!

나는 살구싶다!
나는 살구싶다!

 

살구처럼 살고 싶었는데
현실은 자몽이더라.

'' 카테고리의 다른 글

실용주의 프로그래머(20주년 기념판)  (3) 2025.08.01

 

실용주의 프로그래머 20주년 기념판

 

실용주의 프로그래머(the pragmatic programmer) 20주년 기념판을 읽었다.
출퇴근길에 가볍게 1 회독했고 한번 정도 더 읽어볼 생각이다.

 

책에서는 저자의 개발에 대한 전반적인 팁을 서술한다.

 

대체로 white paper 스러운 느낌을 주지만 특히 인상 깊게 느낀 부분을 몇 개 적어본다.

 

예광탄(tracer bullet)은 불빛을 통해 총알이 날아가는 궤적이 보이는 탄환이다.

 

예광탄 개발 방법은 마치 예광탄이 타깃을 관통하듯 핵심적인 부분을 먼저 개발하고

점점 살을 붙여 나가는 개발 방법론이다.

 

이는 근본적으로 문제를 쪼개고 점진적 개발을 추구하는 현대적 아키텍처와 일맥상통한다.
MSA(micro service architecture), Agile, 기타 등등..

 

인간이 유지할 수 있는 컨텍스트는 유한하기에 이를 작은 단위로 쪼개고

차근차근 문제를 해결해 나가는 것 이다.

 

다음은 Topic 30 변환 프로그래밍이다.

이 토픽의 핵심적인 철학은 모든 프로그램은 입력을 출력으로 바꾸는 작업이라는 것이다.

 

위대한 엔지니어들은 데이터에 큰 의미를 가진다.

대표적으로는 1973년 튜링상 수상 강연인 Programmer as Navigator(항해자로서의 프로그래머)를 볼 수 있다.

자기 테이프 시대에서 하드 디스크 시대로 넘어오며 극초기의 데이터베이스 설계자인 Charles W. Bachman은

이 발표에서 순차적 디스크 접근시대를 벗어나며 관찰자에서 항해자로 프로그래머의 역할이 바뀌었다고 말한다.

 

Topic 30 변환 프로그래밍에서는 이런 순수성을 다시 일깨워준다.

우리가 다루어야 할 문제는 결국 데이터의 인풋과 아웃풋 사이의 현상이란 것이다.

데이터의 이동에 비즈니스 로직을 맞추면 프로그래머가 설계에 있어 이를 더 쉽게 이해할 수 있게 만든다.

 

Topic 44 이름 짓기는 우리가 이름을 어떻게 지어야 하는지에 대해, 이름의 의미에 대해 말한다.

코드를 짤 때 최대 난제인 변수명 짓기.. 요즘은 생성형 AI들이 아주 잘해준다지만 컨텍스트를 이해하지 못하면

아직도 답답한 경우가 많고, 남의 코드를 읽을 때에는 큰 도움이 되지 않는다.

 

어쩔 땐 과도한 이름 짓기가 불편하게 느껴지기도 한다. 예를 들어 요즘은 Ops가 너무 많다.

  • DevOps
  • SecOps
  • DevSecOps
  • DataOps
  • FinOps
  • GitOps
  • AIOps
  • MLOps
  • ChatOps

그것만으로 문제가 되는가? 아니다. 용어는 우리가 소통하는 데 있어

DRY(Don't Repeat Yourself) 원칙을 지키게 해 준다.

 

하지만 용어라는 틀에 갇히는 순간 행위는 틀에 종속된다. 

"우리는 GitOps라서 이렇게 하면 안 돼"
"우리는 AIOps를 실현하기 위해서 어떻게 해야 해"

 

용어의 등장은 그저 창시자가 정의하고픈 어떤 것에 붙인 이름일 뿐임에도

이에 갇혀 능동적인 행위를 막는다. 일종의 Cargo cult인 것이다.

사실은 용어도 어떤 요구사항에서 나왔으며, 조직에 따라 달라져야 한다.

 

전반적으로 무난하게 좋은 책이었고

꽤 흥미롭게 읽었다. 철학서에 가깝기에 가벼운 마음으로 읽었다.

 

다만 기술 용어들은 한글과 영어를 좀 더 크게 병용하면 더 좋았을 것 같다.

한글로 번역되어 익숙하지 않은 용어들은 오히려 책을 읽을 때 이물감을 느끼게 했다.

 

수많은 챕터 중에서도 적은 챕터에 대한 간략한 리뷰와 총평을 써봤는데

이 책을 볼까 말까 고민된다면 책에서 제공하는 수록 팁을 보길 바란다.

취향에 맞는 책인지 아닌지 판단할 수 있을 것이다.

 

수록 팁

더보기
  1. 자신의 기예(craft)에 관심을 가져라
  2. 자기 일에 대해 생각하라.
  3. 당신에게는 에이전시(agency)가 있다.
  4. 어설픈 변명 말고 대안을 제시하라.
  5. 깨진 창문을 내버려 두지 말라.
  6. 변화의 촉매가 돼라.
  7. 큰 그림을 기억하라.
  8. 품질을 요구 사항으로 만들어라.
  9. 지식 포트폴리오에 주기적으로 투자하라.
  10. 읽고 듣는 것을 비판적으로 분석하라.
  11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.
  12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
  13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
  14. 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
  15. DRY: 반복하지 말라 Don’t Repeat Yourself
  16. 재사용하기 쉽게 만들어라.
  17. 관련없는것들간에서로영향이없도록하라.
  18. 최종 결정이란 없다.
  19. 유행을 좇지 말라.
  20. 목표물을 찾기 위해 예광탄을 써라.
  21. 프로토타이핑으로 학습하라.
  22. 문제 도메인에 가깝게 프로그래밍하라.
  23. 추정으로 놀람을 피하라.
  24. 코드와 함께 일정도 반복하며 조정하라.
  25. 지식을 일반 텍스트로 저장하라.
  26. 명령어 셸의 힘을 사용하라.
  27. 에디터를 유창하게(fluency) 쓸 수 있게 하라.
  28. 언제나 버전 관리 시스템을 사용하라.
  29. 비난 대신 문제를 해결하라.
  30. 당황하지 말라.
  31. 코드를 고치기 전 실패하는 테스트부터.
  32. 그놈의(damn…) 오류 메시지 좀 읽어라.
  33. “select”는 망가지지 않았다.
  34. 가정하지 말라. 증명하라.
  35. 텍스트 처리 언어를 익혀라.
  36. 여러분은 완벽한 소프트웨어를 만들 수 없다.
  37. 계약으로 설계하라.
  38. 일찍 작동을 멈춰라.
  39. 단정문으로 불가능한 상황을 예방하라.
  40. 자신이 시작한 것은 자신이 끝내라.
  41. 지역적으로 행동하라.
  42. 작은 단계들을 밟아라. 언제나.
  43. 예언하지 말라.
  44. 결합도가 낮은 코드가 바꾸기 쉽다.
  45. 묻지 말고 말하라 Tell, Don’t Ask, TDA.
  46. 메서드 호출을 엮지 말라.
  47. 전역 데이터를 피하라.
  48. 전역적이어야 할 만큼 중요하다면 API로 감싸라.
  49. 프로그래밍은 코드에 관한 것이지만, 프로그램은 데이터에 관한 것이다.
  50. 상태를 쌓아 놓지 말고 전달하라.
  51. 상속세를 내지 말라.
  52. 다형성은 인터페이스로 표현하는 것이 좋다.
  53. 서비스에 위임하라. Has-A가 Is-A보다 낫다.
  54. 믹스인으로 기능을 공유하라.
  55. 외부 설정으로 애플리케이션을 조정할 수 있게 하라.
  56. 작업 흐름 분석으로 동시성을 개선하라.
  57. 공유 상태는 틀린 상태다.
  58. 불규칙한 실패는 동시성 문제인 경우가 많다.
  59. 공유 상태 없는 동시성을 위하여 액터를 사용하라.
  60. 칠판으로 작업 흐름을 조율하라.
  61. 여러분 내면의 파충류에게 귀 기울여라.
  62. 우연에 맡기는 프로그래밍을 하지 말라.
  63. 사용하는 알고리즘의 차수를 추정하라.
  64. 여러분의 추정을 테스트하라.
  65. 일찍 리팩터링하고, 자주 리팩터링하라.
  66. 테스트는 버그를 찾기 위한 것이 아니다.
  67. 테스트가 코드의 첫 번째 사용자다.
  68. 상향식이나 하향식이 아니라 끝에서 끝까지(end-to-end) 만들어라.
  69. 테스트할 수 있도록 설계하라.
  70. 여러분의 소프트웨어를 테스트하라. 그러지 않으면 사용자가 테스트하게 된다.
  71. 속성 기반 테스트로 가정을 검증하라.
  72. 단순함을 유지하고 공격 표면을 최소화하라.
  73. 보안 패치를 신속히 적용하라.
  74. 이름을 잘 지어라. 필요하면 이름을 바꿔라.
  75. 자신이 뭘 원하는지 정확히 아는 사람은 아무도 없다.
  76. 프로그래머는 사람들이 자신이 원하는 바를 깨닫도록 돕는다.
  77. 요구 사항은 피드백을 반복하며 알게 된다.
  78. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
  79. 정책은 메타데이터다.
  80. 프로젝트 용어 사전을 사용하라.
  81. 생각의 틀을 벗어나지 말고, 틀을 찾아라.
  82. 코드에 혼자 들어가지 말라.
  83. 애자일은 명사가 아니다. 애자일은 무언가를 하는 방식이다.
  84. 작고 안정적인 팀을 유지하라.
  85. 실현하려면 계획하라.
  86. 모든 기능을 갖춘 팀을 조직하라.
  87. 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
  88. 사용자에게 필요할 때 제공하라.
  89. 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
  90. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
  91. 모든 테스트가 끝날 때까지는 코딩이 끝난 게 아니다.
  92. 버그를 심어 놓고 테스트를 테스트하라.
  93. 코드 커버리지만 올리지 말고 상태 조합을 테스트하라.
  94. 버그는 한 번만 잡아라.
  95. 수작업 절차를 사용하지 말라.
  96. 사용자를 기쁘게 하라. 그저 코드만 내놓지 말라.
  97. 자신의 작품에 서명하라.
  98. 먼저, 해를 끼치지 말라.
  99. 쓰레기 가은 인간을 돕지 마라
  100. 결국 당신의 삶이다.삶을 사람들과 나누고, 삶을 축하하고, 삶을 만들어가라. 그리고 그걸 즐겨라

 

'' 카테고리의 다른 글

자몽살구클럽  (3) 2025.08.08

+ Recent posts