2025년 3월 회고

3월 한 달 동안에는 불안정했던 시스템을 안정화시켰고, 의견 차이를 좁히기 위한 노력들을 많이 했으며 더 나은 팀이 되기 위한 고민을 하며 여러가지로 많이 배웠다. 기술적인 인프라 운영이나 팀 리딩, 커뮤니케이션까지.

그동안 애썼고 앞으로는 또 다양한 도전을 하게 될 것 같다.

3월에 해낸 것들 & 좋았던 것들

• 거의 하루도 빠짐 없이 일기를 썼다.
• LLM 파인 튜닝을 해보았고, 실패했다.
• 시스템 모니터링을 하며 k8s 상에서 여러가지 성능 튜닝을 했다. 그러면서 qos 부터 메트릭의 종류까지 알게 되는 점이 많았다.
• 처음으로 ADR을 작성해보고, 실패했던 것들을 많이 적으려고 노력했다.
• 짬나는 대로 여러 사람들을 만나며 귀기울이고 이야기를 들었다.
• 책 ‘고작 다섯 명이 한 말을 어떻게 믿어요?’, ‘기획은 2형식이다’, ‘일의 감각’ 을 읽었다.

3월에 아쉬웠던 것들

• 생각보다 k8s 클러스터를 운영을 하는 과정이 녹록치 않았다. 시스템이 복잡해질수록 운영 비용은 배로 늘어난다.
• 감정적이었고, 미성숙했다. 갈등이 생기고 이것을 다루어 내는 과정에서 자책을 많이 하게 됐다.

3월 동안 기록했던 토막글들

적은지 얼마나 됐다고, 기억이 새록새록하다.

오늘의 토막글 54

• 로그를 어디에서도 찾을 수 없다면 WAF를 의심할 것이라는 생각을 해봅니다. 요청이 간헐적으로 실패해서 문제를 찾는데 생각보다 시간을 꽤 낭비했거든요. 덕분에 body 가 8KB가 넘어가면 AWSManagedRulesCommonRuleSet 에서 기본적으로 막는다는 걸 알게 되었습니다.
• 요새 힐링이 필요할 때 최유리님의 노래를 자주 듣고 있습니다. ‘숲’은 정말 들어도 들어도 질리지 않네요.
• 글을 봐주시는 분들이 생겨서 말투와 내용을 조금 더 읽기 편하게 바꾸기로 마음 먹었습니다.

오늘의 토막글 55

• 인공 지능에게 밥을 주는 일은 꽤나 고단한 일입니다. 인공 지능은 할루시네이션이 있는 데다 무엇보다 100% 정확한 결과를 보장하지 않아서 결국 사람이 검수 과정에 껴야 하거든요. 데이터가 잘못 들어가면 기대를 벗어날 확률이 높아지니 꼼꼼하게 볼 수 밖에 없습니다. 이 때문에 엑셀을 기가막히게 다루는 능력은 대 AI 시대에서도 필요한 역량이란 생각이 드네요.
• 1월의 회고에서 썼던 ‘작고 사소한 배움일지라도 모두 글로 남기자’를 2월 달에는 잘 지키지 못했습니다. 3월엔 더 분발해보겠습니다.
• GCP 에서 결제 계정 연동은 계정 당 3개의 프로젝트 까지만 가능합니다. 증설하려면 Billing Quota increase 폼을 작성해서 submit 해야 해요. 다행히 금방 승인 답장이 왔습니다. 정말 쓸 데 없는 지식이 하나 늘었네요.

오늘의 토막글 56

• LLM 파인 튜닝을 해보았습니다. 예전에 인공지능을 공부했던 게 새록새록 떠오르네요. 그 때 쓰던 기초적인 용어(loss function, learning rate, batch 등등)가 다시 눈에 보여 반가웠습니다.
• LLM 파인 튜닝을 할 때엔 모델에게 요구하는 동작이 복잡할 수록(창의적일 수록) 데이터셋이 많이 필요합니다. 원하는 결과를 얻기 위해서는 batch 사이즈나 epoch 을 여러 가지로 튜닝해보면서 가장 성능 좋은 파라미터를 채택하는 것도 중요하지만, 2배수로 데이터셋 늘려가면서 데이터셋을 어떤 방향으로 컨트롤 할 지(더 sparse한 예시를 줄지, 약한 부분을 강화할 지 등)에 대한 직관이 더 중요한 것 같습니다.
• 내러티브 & 넘버스라는 책을 읽기 시작했습니다.

오늘의 토막글 57

• 요새 너무 성급하게 뭐든 결론 짓고 마는 것 같습니다. 심지어 대부분 틀리고요. 여유가 부족해서인가 싶기도 하고 무엇보다 자책을 하게 되네요. 출력을 내기 전에 스스로 갈무리하는 연습을 해보려 합니다.
• 제가 제 스스로의 아버지라 생각하고 아들에게 하는 조언을 스스로에게 하는 연습을 하고 있는데 상황을 좀 더 힘을 빼고 들여다 볼 때에 좋은 것 같습니다. 감정에 너무 휘둘리는 것은 아닌지, 중요한 걸 놓치고 있지는 않은지 다시 생각해보게 되어요.
• 큰 사람이 되려면 작은 일에서 최선을 다하라. 속으로 뜨끔했던 오늘의 문장이었습니다.

오늘의 토막글 58

• 오라클을 써본 적이 없어서, mysql 과는 다르게 isolation level 이 default 로 read committed 라는 걸 오늘 처음 알았습니다. 물론 작동하는 방식은 mysql 과 차이가 조금 있다고 하네요.
• mysql 을 사용하는 많은 서비스 회사들이 모든 엔지니어가 알잘딱깔센으로 맛있게 트랜젝션 범위를 설정하리라…고는 기대하지 않고 isolation level을 read committed 로 설정하지만, 당연하게도 롱 트랜잭션이 많아지면 마찬가지로 MVCC 부하가 생길 수 있어서 주의를 필요로 합니다.
• ‘변화란 항상 양면성을 지니고 있어서 세상에 문제가 끊이지 않는다’ 고 예전에 글을 쓴 적이 있는데, 아주 중요한 문제지만 많은 사람들이 관심을 가지지 않는 문제는 어떻게 해결이 될 수 있는지 궁금해졌어요. 사람들을 위해 문제를 계속해서 해결해 나가는 게 최선의 결과를 보장하지 않을 테니까요. 이를 테면 너무 거대해서 와닿지 않는 환경 문제들. 그래서 정치인이 필요한 것일까요. 정치에 대해선 잘 모르지만, 이들도 사람들의 표를 얻어야 하니 딜레마가 있겠어요.

오늘의 토막글 59

• 처음 시도해보았던 파인튜닝은 대차게 말아 먹었습니다. temperature 가 높아야 하는 테스크와 낮아야 하는 테스크가 합쳐져 있을 정도로 모델에게 기대했던 테스크가 복잡했던 것이 원인이었어요. 그만큼 무지했기도 하고요. 그래도 덕분에 파인튜닝에 대한 전반적인 이해를 하게 되었습니다.
• QLoRA 의 어댑터 퓨전에 관한 논문을 보았는데, 응답에 필요한 노드의 홉을 줄일 수 있는 좋은 아이디어 같았습니다. 퀄리티만 기대한대로 나온다면요.
• 유능함은 동료에 대한 신뢰의 바탕이 되는 자원이지만, 사람마다 유능함의 기준은 주관적이라서 누군가의 신뢰를 얻기 위해선 그사람이 어떤 부분에서 신뢰를 느끼는지 디테일하게 아는 게 먼저란 생각을 했습니다.

오늘의 토막글 60

• 책 내러티브 & 넘버스는 읽다가 도중 포기했습니다. M&A 지식이 조금 있는 편인데도 내용이 너무 어렵게 느껴졌어요. 읽어도 배우질 못하니 빠르게 다른 배움을 좇기로 했습니다. 나중에 투자 유치나 M&A를 하게될 때 다시 펼쳐보면 좋을 것 같아요.
• github actions 으로 하던 CD 파이프라인을 argoCD 로 이관하는 걸 해보고 있습니다. 셋업을 제로베이스부터 해보는 건 처음인데, 그래도 서비스 sync 가 잘 돌아가는 것까지 확인하는 덴 성공했습니다. 부끄럽지만 불과 몇 주 전 만해도 aws, terraform, helm 에 대해 거의 아는 게 없었는데 시행착오를 겪으면서 배우는 게 참 많은 것 같습니다.
• 바쁘고 혼란스러울수록 통제할 수 없는 변수를 최대한 줄일 수 있는 방법을 더 빨리 고안했었어야 했는데, 3월달에는 이 부분에 집중해보려고 합니다. 2월에 급하지 않지만 중요한 일을 많이 놓쳤던 게 후폭풍이 되어 돌아온 듯 합니다.

오늘의 토막글 61

• 책 ‘고작 다섯 명이 한 말을 어떻게 믿어요?’ 를 읽기 시작했습니다. 유저 리서치와 관련된 책이에요.
• LLM 토큰당 비용이나 RPM 을 확인하기 위해 매번 LLM 홈페이지 들어가서 조회하곤 했었는데 한번에 조회할 수 있는 주소를 찾았습니다. litellm 이라는 파이썬 패키지 코드 일부인데, 오픈소스라서 dify 같은 LLM 오케트스레이터에선 그냥 긁어서 쓰더라고요.
  • https://raw.githubusercontent.com/BerriAI/litellm/main/model_prices_and_context_window.json
• 전에 Mysql innoDB MVCC 부하에 대한 토막글을 잠깐 썼는데, read committed 격리 레벨에선 한 트랜잭션 안에서도 여러 개의 read view가 만들어질 수 있어서 오히려 repeatable read보다 부하가 더 심해질 수도 있다는 사실을 알게 되었습니다. repeatable read 는 팬텀 리드를 막기 위해 read view가 트랜잭션 당 하나만 생기거든요. 이러나 저러나 롱 트랜젝션은 생기지 않게 주의해야 한다는 사실엔 변함이 없긴 하지만요.

오늘의 토막글 62

• 책 ‘고작 다섯 명이 한 말을 어떻게 믿어요?’ 에서는 이해관계자와의 공동 리서치와 리서치 브리프를 위해 아는 것과 알아내야할 것을 잘 정리하는 것에 대해 강조 합니다. 당연한 말이지만 제품 메이커 관점에서 놓치는 것 없이 준비하기란 쉽지 않을 것 같아요
• Claude 에서 만든 MCP 프로토콜을 보고서 어떻게 써먹지하고 찾아보다가 claude desktop에 brave search를 연결했습니다. 존재하지도 않는 쿠버네티스 어노테이션을 마치 있는 것처럼 AI가 생성한 답변을 함부로 믿었다가 엄청 애를 먹었었는데, 이제 같은 질문을 해도 최신 정보 서치해서 잘 찾아줍니다. 효과가 체감되니 MCP 서버를 구현해보고 싶다는 생각이 들었습니다. file system 이나 k8s mcp server는 이미 나왔네요.
• Manus 같은 AI 에이전트는 첫걸음일 뿐이라고 생각하니 당장 2, 3년 뒤 미래가 어떨 지 짐작이 잘 가지 않네요

오늘의 토막글 63

• Awesome MCP servers 라는 레포를 발견해서 스타를 눌러주었습니다. 써볼만한 mcp server 들을 추려보고 있어요. 이 레포, star history 의 J 커브를 보니 내 제품만 같아라 싶네요. 주소는 https://github.com/punkpeye/awesome-mcp-servers 입니다.
• 커서의 AI Agent 는 탄성이 나올 정도로 시간을 어마어마하게 단축시켜 줍니다. 그렇지만 잘 쓰려면 많이 알아야 해요. 딴 길로 샐 때 잔소리를 제 때 해줘야 하거든요. 딴 길로 새지만 않으면 제가 하는 것보다 작업 속도가 훨씬 빠르고요. 그래서 당분간은 AI가 발전해도 ‘많이 알고 있음’은 여전히 중요할 것 같습니다. 그 당분간이란 AI의 결과물이 너무나 완벽해서 ‘인간의 검수가 필요 없을 때까지’여서 생각보단… 짧지 않을 수도 있을 것 같아요. 기준이 기술에게 있는 게 아니라 인간에게 있으니까요.
• 쿠버네티스 환경에서의 PDB 옵션에 대해 간략하게 정리를 했습니다. 이 옵션은 클러스터 위에 떠 있는 DB가 드레이닝/업그레이드 될 때 가용성을 보장하려면 어떻게 할래? 를 설정하기 위한 옵션이에요. standalone DB면 의미 없는 옵션이지만, master-slave 나 master-master 에서 의미를 가집니다.

오늘의 토막글 64

• 남들에게 보여지는 글이다 보니 실패했던 걸 적지 않게 되는 것 같아 반성을 하게 되었습니다. 앞으론 그날 그날 실패했던 걸 최대한 적어볼까 해요. 그게 더 성장에 도움이 될 것 같다는 생각이 들었거든요.
• 책 “고객 다섯명이 하는 말을 어떻게 믿어요?” 다 읽었습니다. 뒷 부분에 실무 예시가 나와 이해하기 좋았습니다.
• 서버에서 모니터링은 정말 중요한데 너무 간과하고 있었던 것 같습니다. verbose 한 에러에 묻혀 critical 한 메시지를 놓친다거나, 변경이 시스템 메트릭에 어떤 영향을 주는 지 세세하게 파악하지 못하고 배포를 나간다거나…. 앞으론 더 잘 챙겨보려고 해요.

오늘의 토막글 65

• k8s qos 가 실제 노드의 리소스 사용량과 매칭이 잘 되지 않는 것 같아서 여러가지로 애먹고 있습니다. grafana 로 pod 별 시스템 메트릭을 모니터링하면서 qos requests 를 넉넉히 설정하고 있는데, 의도치 않게 스케일링 된다던가… 하는 현상을 경험하고 있습니다. 일단은 hpa 와 메트릭 쿼리의 rate term 이 달라서 생기는 문제라고 짐작하고 있어요.
• 예전 회사 동료였던 시니어 엔지니어의 포스팅을 보고 오랜만에 연락드렸습니다. custom k8s controller 를 만드셨다는데, 어떤 썰을 풀어주실지 기대됩니다

오늘의 토막글 66

• 오픈소스를 aws 환경에 셀프호스팅 했다가 생각했던 것보다 성능이 나오지 않고, 최신 버전인데도 메모리 릭도 발견하고… 여러가지로 실망스러운 결과를 마주했습니다. 자꾸 강제 업데이트되는 SaaS 로 쓰는 것보단 나을 거라 생각했는데, 오히려 단점이 더 많다고 느껴져서 다 떼어버리고 lanchain4j 로 직접 구현하는 것은 어떨까 고민하고 있습니다.
• Architecture Decision Records (ADR) 라는 걸 알게 되었습니다. “이 시점에, 이런 정보를 감안해, 어떤 옵션 Z를 하기로 결정함. 대안으론 X, Y가 있었음”을 기록하는 문서에요. 분산된 의사결정을 막고, 지식 공유 관점에서 좋은 도구 같다고 느껴졌어요. 최대한 append-only 로 만들고 코드와 같은 레포에서 관리되면 나쁘지 않을 것 같아요. 심지어 homebrew 로 adr-tools 을 설치하고 관리할 수도 있습니다.

오늘의 토막글 67

• 첫 ADR(Architecture Decision Records)을 테스트 삼아 작성해보는 연습을 했습니다. gpt 한테 검토도 부탁하니 잘 피드백 해주더라구요. 잘 알지 못하는 영역, 특히 해보지 않으면 모르는 부분에 대한 기술적 의사결정을 내려야 할 때, ADR이 도움이 된다고 느꼈습니다. 사실 이미 아는 영역이면 ADR까지도 필요 없이 그냥 하면 되는 거겠죠.
• 책 ‘기획은 2형식이다’를 읽기 시작했습니다. 논리적으로 사고하는 연습을 하고 싶어서 목차도 안보고 추천 받자마자 읽기 목록에 넣었던 책입니다.
• 그라파나에서 보던 메트릭에 쿼리를 잘못 넣어서 적절하지 않은 값으로 qos 를 세팅하고 있었단 걸 알게 되었습니다. 카운터 메트릭도 아닌데 rate 를 씌우고 있었어요. 엄청 헤맸는데… 부주의함이 낳은 결과네요.

오늘의 토막글 68

• 책 ‘기획은 2형식이다’ 에서는 문제의 현상이 아닌 본질에 집중하는 것을 강조합니다. 현상에서 본질에 닿기 위해선 ‘왜?’ 가 정말 많이 필요하다면서요. 여러 책에서 같은 이야기를 들려주는 걸 보면 아무리 강조해도 지나치지 않은 것 같습니다.
• 최근에 저는 본질에 집중하지 않는 경우가 많은 것 같아 같은 말을 들어도 더 깊게 와닿습니다. A라는 문제를 해결하기 위해 B를 했는데, 새로운 C 라는 문제가 생기는 바람에 B를 롤백했거든요. 그런에 얼마 지나지 않아 A 문제가 더 크게 다시 도지는 바람에 다시 차악으로 B를 선택하게 됐습니다. 각 행동을 할 때는 결단력있게 밀어 붙였다고 생각했는데, 지나고보니 본질이었던 문제 A에 제대로 집중하지 못하고 우유부단하기만 했습니다.
• Star Rocks 라는 새로운 OLAP 를 알게 되었습니다. 성능은 둘째 치더라도 MySQL 프로토콜을 지원해서 같은 드라이버를 쓸 수 있다는 게 놀라웠습니다. 하둡 인프라가 없다면 데이터 웨어하우스에 좋은 선택이 될 거 같아요. 언제 한 번 직접 구축할 기회가 생기면 좋겠네요.

오늘의 토막글 69

• 어플리케이션에서 강제로 소켓 연결을 닫는 상황을 제외한다면 RST 패킷은 방화벽이나 로드벨런서에서 날리는 경우가 많습니다. 특히 로드벨런서는 리소스 절약을 위해 유휴 연결 타임아웃 설정이 있는데, 설정을 건드릴 수 없는 상황에서 가용성을 챙기려면 요청 단에서 back off retry 하는 것이 가장 효과적입니다.
• fake test 는 복잡한 제품에는 적용할 수 없습니다. 기능이 한번에 이해될 만큼 단순하고 강력하지만 구현이 쉽지 않은 경우에 유효한 방법인 것 같습니다. 왜냐하면 제품이 강력한 가치를 지녔더라도 현대인의 인내심은 복잡한 제품을 얼핏 보고 이해할 만큼 충분하지 않기 때문입니다. fake test는 분명 좋은 방법이지만 검증이 어렵다는 점과 브랜드 가치를 훼손할 수 있다는 점에서 실행에 신중해야 해요.

오늘의 토막글 70

• 부족한 점을 요새 많이 깨닫습니다. 스스로 확신이 서면 좁은 시야에 갇혀 의견 대립을 제대로 다루어 내지 못한다는 점, 동의가 되지 않을 때 스스로 동의되지 않는 이유를 찾는 데 오래 걸린다는 점.
• 오랜만에 연락드려 만난 훌륭한 분에게 많은 인사이트를 얻었습니다. 인프라는 장애 대응과 운영이 제일 중요하기 때문에 로컬에서 뭐든지 컨트롤 할 수 있어야 한다는 철학, 헬름의 단점과 마찰에 대한 이야기, sops 라는 오픈 소스 등등.

오늘의 토막글 71

• 최근에 훌륭하신 분들을 많이 만났습니다. 많은 걸 배웠고 즐거운 시간이었어요. 덕분에 저한테 부족한 부분도 많이 깨달을 수 있었습니다.
• 챌린지와 의사결정 방해는 한 끗 차이이고, 의사결정자의 생각 뿌리와 궤를 같이 하느냐의 여부로 결정된다는 걸 알았습니다. 나만의 해결책을 정의해서 이게 맞지 않느냐? 하는 건 챌린지가 아니라 의사결정 방해에요. 좋은 챌린지란 의사결정을 한 실무자의 결정을 존중하되, 놓친 부분이 있다면 도와주는 것이에요.
• 우유부단함이란 고민이 있어 제3자의 의견을 들을 때 스스로의 주관과 결정이 준비되어 있느냐 없느냐의 여부로 결정된다는 걸 알았습니다.

오늘의 토막글 72

• 매일 글로 하루를 붙잡아두면 좋은 점은, 하루를 놓쳤을 때 아쉬워할 수 있다는 점인 거 같습니다
• 피드백을 수용하는 건 받는 사람의 마음입니다. 주는 사람은 수용을 강요할 수 없어요.
• 명료하게 질문하는 것은 참 어렵습니다. 어디까지 합의가 되었고, 어디서부터 논의가 될 수 있는지를 속속들이 알아야 해요.

오늘의 토막글 73

• MCP와 RAG 를 결합하면 시너지가 날 수 있을 것 같아요. RAG는 정보를 어떻게 하면 잘 가져올까를 고민하고, MCP는 가져온 정보를 어떻게 잘 구조화할까를 고민하거든요. 어쩌면 LLM과 룰베이스가 교묘하게 잘 짜여질 수 있는 교착점이 MCP 서버가 될 것 같네요.
• 현상에는 좋고 나쁨이 없습니다. 어떻게 바라보느냐의 차이이죠. 어떤 식으로든 좋게도 해석할 수 있고 나쁘게도 해석할 수 있습니다. 저는 감정이 섞이면 좋게 해석하는 게 잘 안되는 사람이라, 한 발짝 물러나서 바라보거나 글로 감정을 정리하는 등의 연습을 요새 하고 있어요.
• LLM이 학습하지 못한, 독점적이고 비지니스에 필수적인 정보를 가진 사람일수록, 할루시네이션이 너무 크리티컬한 결과를 가져와서 책임을 지는 사람이 필요한 영역에 있을 수록 AI 시대에 오래 살아남을 수 있을 것 같습니다. 그래서 오히려 개발자는 역할과 책임이 더 많아질지언정 금방 사라지진 않을 것 같아요.

오늘의 토막글 74

• 책 ‘기획은 2형식이다’ 를 다 읽었습니다. 문제의 현상에서 벗어나 본질에 닿는 방법을 좀 더 면밀하게 나눠준 부분(뽑아낸 문제가 현상인지 본질인지 구분하는 방법이라던가)이 제일 좋았어요
• 표절과 창조적 모방의 차이는 눈에 보이는 것을 훔치느냐, 보이지 않는 것(이를테면 아이디어)을 훔치느냐의 차이다라는 구결도 인상깊었습니다.
• 최근에 했던 실수는 엣지 케이스에 대한 테스트를 놓쳐서 발생했습니다. 로컬에서 열심히 테스트 했지만 놓쳤던 케이스가 있었어요. 다행히 영향 범위가 크지 않았지만… 슬프게도 꼼꼼하지 못한 건 타고난 부분이라, 보완하기 위해 앞으론 변경 전에 변경 전략을 기록한 문서를 반드시 작성을 해보려고 해요.

오늘의 토막글 75

• 책 ‘일의 감각’ 을 읽기 시작했어요. 비전에 완전히 공감하지 않아도 동기부여 될 수 있다는 글을 이전에 쓴 적이 있는데, 그것을 오너의 행복을 바라는 마음이라며 소개하는 책의 앞부분이 신기하면서도 반가웠습니다.
• 마음을 먹었던 대로 작업을 하기에 앞서 구현 전략, 고민했던 점들, 테스트 전략, 모니터링 전략을 미리 세우고 글로 남겨 보았습니다. 배포 후에는 좋았던 점, 나빴던 점을 같이 남겨보려 해요. 고민했던 점들은 예전에 글로 남겼던 ADR 과도 맞닿는 부분이 있네요. 연차가 조금이라도 더 낮았을 때 했더라면 더 좋았을 텐데.
• integration 테스트를 짜는 게 시간을 많이 잡아 먹어서 일정을 맞추기 위해 종종 http 파일을 만들어 로컬에서 테스트하는 것으로 갈음했었는데, http 파일 안에서 js 로 pre-request 와 post-assertion 을 할 수 있더라구요. jb-http-client 도 있어서 CI에 붙이는 것도 가능합니다. 해보고 나서 느낀 점은.. 역시 integration 테스트는 테스트를 구현하는 데 오래 걸리는 게 아니라 외부 의존성을 통제하며 반복 가능하게 만드는 데서 오래 걸린다는 점을 재확인할 수 있었습니다. 그래도 속도와 테스트 커버리지 사이의 중간 합의점을 찾은 것 같아 만족합니다.

오늘의 토막글 76

• 기능 구현 별로 회고를 해보니 간단한 기능에도 제가 생각보다 꽤 많은 고민과 의사결정(이번엔 6개)을 한다는 것과 엣지케이스에 대한 셀프 리뷰가 부족하다는 점을 알게 되었습니다. 그래서 다음부턴 코드 셀프 리뷰 뿐만 아니라 설계 단계에서부터 셀프 리뷰 단계까지 하나 더 넣어보려고 해요.
• 책 ‘일의 감각’ 을 다 읽었습니다. 엇, 그런데 읽고 보니 똑같은 이름으로 책이 하나 더 있네요. 예전에 병찬님이 추천하셨을 땐 몰랐는데… 다음부턴 저자 이름도 같이 들어봐야겠습니다.
• 성장률의 평균을 구할 때는 산술평균이 아니라 기하평균을 사용해야 한다는 것을 처음 알았습니다. 산술평균을 내면 과대평가를 하게 되어요. 따지고 보면 성장률은 이전 결과의 곱으로 계산되는 것이라 n제곱근을 사용하는 기하평균이 더 상식적인데, 관성적으로 산술평균을 적용하려고 하고 있었습니다.