긍정적 사고, 음식의 절제, 규칙적인 운동

https://blog.boot.dev/education/vibe-coding-hell/

https://news.hada.io/topic?id=23590

• 최근 코딩 교육 환경에서 “튜토리얼 지옥” 대신 “바이브 코딩 지옥” 이 새로운 문제로 대두됨
• 튜토리얼 지옥이 "튜토리얼 없이는 아무것도 만들지 못하는" 상태였다면, 바이브 코딩 지옥은 "AI 없이는 코딩할 수 없고, AI가 생성한 코드가 어떻게 작동하는지 이해하지 못하는" 상태를 의미
• AI 도구의 과도한 사용이 학습 동기를 저하시키며, AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 역설적 상황이 발생하고 있음
• AI 도구는 적절하게 활용하면 학습 보조에 큰 도움이 될 수 있으나, 무작정 ‘답만 얻기’식 사용은 건설적 이해 형성에 방해가 됨
• 학습 과정에서 직접 고민하고 스스로 해결하려는 노력이 핵심, 튜토리얼·AI 보조 없이 문제 해결 경험을 쌓는 자세가 중요함

문제의 배경: 튜토리얼 지옥에서 바이브 코딩 지옥으로

• 2019년 당시 코딩 교육의 주요 문제는 "튜토리얼 지옥" 이었음
  • 튜토리얼을 따라하는 데는 성공하지만 혼자서는 아무것도 만들지 못함
  • 실제 프로그래밍보다 프로그래밍 관련 동영상 시청에 더 많은 시간을 소비하며, 핵심 개념은 이해하지 못함
  • 결과적으로 피상적 지식만 쌓고, 내부 작동 원리는 이해하지 못해서 현실에서는 코드를 스스로 쓰지 못하는 상태
• Boot.dev는 이를 해결하기 위해 세 가지에 집중함
  • 심층 커리큘럼: 전통 대학 외부에서도 CS 기초를 배울 필요성 강조
  • 실습 중심 방식: 모든 개념 학습과 함께 코드를 직접 작성
  • 비디오보다 리치 텍스트 강화: 비디오는 수동적 소비에 그칠 위험성 있음
• 2019년에는 수백만 조회수를 기록하던 긴 YouTube 강의들이 현재는 5만 조회수도 달성하기 어려움
  • FreeCodeCamp, Traversy Media, Web Dev Simplified 등의 채널이 이러한 추세를 보임
• 그러나 "learn to code"에 대한 Google Trends 데이터는 여전히 높은 관심도를 유지하고 있음
• Boot.dev에 매일 약 1,300명의 신규 사용자가 등록하며, 최근 18개월간 튜토리얼 지옥에 대한 불만은 줄었지만 새로운 형태의 어려움이 나타남

바이브 코딩 지옥의 정의

• 튜토리얼 지옥의 특징
  • "튜토리얼 없이는 아무것도 만들 수 없다"
  • "문서를 이해하지 못하니 동영상이 필요하다"
  • "간단한 작업에도 복잡한 프레임워크가 필요하다"
• 바이브 코딩 지옥의 특징
  • "Cursor의 도움 없이는 아무것도 할 수 없다"
  • "멋진 타워 디펜스 게임을 만들었어요. 여기 링크에요 http://localhost:3000";
  • "이미지 lazy-load를 위해 Claude가 6,379줄을 추가한 이유를 모르겠어요"
• 현재 자기주도 학습자들은 많은 것을 만들고 있지만, 소프트웨어 작동 방식에 대한 멘탈 모델을 발전시키지 못하는 프로젝트를 구축함
• AI의 환각(hallucination)과 싸우고, 테스트 통과에만 집중하는 봇과 씨름하며 실제 문제 해결보다는 AI가 생성한 코드를 맹목적으로 신뢰함

AI 코딩의 미래와 현실

• 나는 단기적으로 AI가 개발자를 완전히 대체하지는 않을 것이라는 데 긍정적 입장
  • "AI가 일자리를 빼앗을 때까지 6개월"이라는 말이 나온 지 3년이 지났지만 여전히 개발자를 고용하고 있음
• GPT-5가 출시되었지만 GPT-4 대비 점진적 개선에 그쳤으며, AGI가 곧 도래하지 않을 것임을 보여주는 증거로 해석됨
• 매일 AI 도구를 사용하지만 실제로 생산성이 얼마나 향상되는지 확신하지 못함
  • AI가 더 생산적이게 만드는지, 아니면 더 게으르게 만드는지 불분명
• 2025년 연구 결과: 개발자들은 AI가 20-25% 생산성을 높인다고 가정했지만, 실제로는 19% 느려짐
  • 7조 달러 투자 대비 실망스러운 결과

AI와 학습동기 저하의 위험성

• AI 활용 문화가 학습자의 동기 부여에 부정적일 수 있음
• AI 열풍(버블?)에서 가장 우려되는 점은 "왜 배워야 하나? AI가 다 알잖아"라는 태도를 가진 세대가 등장한다는 것
• AI가 실제로 모든 화이트칼라 직업을 대체하지 못한다면, 주식 시장 버블뿐 아니라 교육받은 인력의 가뭄도 겪게 될 것
• 기술적 배경이 없는 투자자들은 “AI가 이미 코딩의 전부를 대체했다”고 오해하고, 시니어 개발자들은 여전히 AI 도구를 일상 업무에 통합할 유용한 방법을 찾지 못함
• AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 경향이 있어 우려됨
  • 궁극적인 ‘Dunning-Kruger(더닝-크루거)’ 함정으로 작용 - 지식이 부족한 사람이 오히려 자신이 잘 안다고 착각하는 현상
  • 학습자들이 "AI가 이미 알고 있으니" 자기계발이 무의미하다고 결론 내림

AI는 학습에 유익한가?

• 여전히 코딩 배우기에 대한 사회적 관심도 높음
• AI가 학습에 유익할 수도 있지만, 두 가지 구조적 문제가 존재함
• 첫 번째: 아첨(sycophant) 문제
  • AI 챗봇은 질문자 의견에 과도하게 동조하는 경향이 있음
  • “ROAS(광고수익률)에 대해” 채팅해보면, 같은 데이터를 놓고 질문 방향에 따라 정반대 결론을 내며, 모두 전문가적 어조로 확신 있게 답함
  • 이는 학습자에게 검증, 비판적 사고, 오류 지적을 경험할 기회를 박탈함
    • 전문가에게 묻는 이유는 우리가 틀렸을 때 알려주기 위함
    • IRC 채팅이나 Stack Overflow는 이를 잘 수행했음(아마도 너무 잘)
    • LLM(대형언어모델) 챗봇은 기존 학습자의 근본적 오해를 바로잡지 못하는 경향이 강함
    • 현재 학생들은 LLM과 편안한 대화를 나누며 필요한 것이 아닌 듣고 싶은 것을 듣게 됨
• 두 번째 문제: 학습자는 실질적 ‘의견’을 원함
  • AI는 지나치게 균형 잡힌 입장을 제시함
    • "어떤 사람들은 X라고 생각하고 어떤 사람들은 Y라고 생각한다"
    • 학습자가 어느 쪽에 동의할지 결정하기 더 어려워짐
  • "자본주의자 역할" 또는 "마르크스주의 혁명가 역할"을 하도록 프롬프트했지만 만족스러운 결과를 얻지 못함
  • 학습자는 실제 경험에서 나온 의견과 논평을 듣고 싶어함
    • DHH가 Turbo에서 TypeScript를 제거한 이유
    • Anders Hejlsberg가 TypeScript가 JavaScript 개발자에게 해결해주는 것
    • 각 저자의 편견과 맥락이 명확히 드러나는 실제 의견을 통해 미묘한 멘탈 모델이 형성됨
  • LLM 특유의 중립적·조심스러운 답변은 실제 지식 내면화에 방해가 됨

AI가 학습에 진짜 도움 되는 경우

• AI는 올바르게 사용하면 학습을 위한 놀라운 도구임
• 코딩을 배우기에 이보다 쉬운 시대는 없었음
• Boot.dev의 Boots(AI 교육 보조 도구) 사례
  • 학생들이 인스트럭터 솔루션(이상적인 정답)을 보는 것보다 AI 튜터(Boots)와 채팅하는 것을 거의 4배 더 많이 사용
  • Boots는 일반 챗봇과 달리 다음 방식으로 학습에 도움 줌
    • 답을 직접 알려주지 않도록 사전 프롬프팅됨
    • 소크라테스식 방법을 사용하여 학생이 문제에 대해 더 깊이 생각하도록 유도
    • 강사의 솔루션에 접근할 수 있어 정답에 대한 환각 가능성이 훨씬 낮음
    • 즐거운 캐릭터성 부여(마법사 곰)

바이브 코딩 지옥 탈출법

• 결론적으로, 튜토리얼 지옥이든 바이브 지옥이든, ‘남에게 맡기지 말고 스스로 해보는 경험’ 이 매우 중요함
  • 튜토리얼 지옥: 비디오 끄고 직접 코드 작성 경험 쌓기
  • 바이브 지옥: 코파일럿 등 AI 자동완성 꺼두고, 스스로 문제 해결 경험 쌓기
• 피해야 할 것:
  • 에디터 내 AI 자동완성
  • 에이전트 모드 및 AI 자동화 도구로 프로젝트 처리
• 활용할 수 있는 것:
  • 질문에 답하고, 개념을 설명하고, 예제를 제공하는 챗봇
  • 소크라테스식 방법으로 질문하도록 유도하는 시스템 프롬프트를 통해 깊은 사고 촉진
  • 주장을 할 때 출처를 인용하고 문서에 링크하도록 요청하는 시스템 프롬프트로 정보 신뢰성 확보

핵심 원칙

• 학습은 반드시 불편해야 함
  • 튜토리얼 지옥은 다른 사람이 코딩하는 것을 보면서 불편함을 피할 수 있게 해줌
  • 바이브 코딩 지옥은 AI가 코드를 작성하게 하면서 불편함을 피할 수 있게 해줌
• 진짜 학습은 막히고, 좌절하고, 가장 중요하게는 문제 해결을 강제당할 때 일어남
  • 이것이 인간의 신경망이 재배선되는 방식
• "학습은 어려워야 한다"는 개념을 지나치게 확대하면 형편없는 교육 설계의 변명이 될 수 있음
  • 저자는 이를 옹호하지 않음
  • 개념이 최선의 방식으로 설명되더라도, 학생은 여전히 그것과 씨름하고 새로운 맥락에서 스스로 사용해야 진정으로 이해할 수 있음
• 진짜 학습 은 직접 막히고, 좌절하고, 자신의 힘으로 돌파하는 과정에서 완성됨

[PYTHON] Python 3.14.0 정식 버전 출시 🐍

Python 3.14.0의 정식 버전이 출시되었습니다. 이번 업데이트는 성능 향상과 새로운 기능 추가에 중점을 두었습니다.

주요 기능

• PEP 779: 자유 스레드 Python (Free-threaded Python) 공식 지원: 여러 스레드에서 Python 코드를 동시에 실행할 수 있어 멀티코어 프로세서를 더 효율적으로 활용할 수 있습니다.
• PEP 649: 어노테이션 평가 지연: 타입 힌트와 같은 어노테이션의 평가를 나중으로 미루어 시작 시간을 단축합니다.
• PEP 750: 템플릿 문자열 리터럴 (t-strings): f-string과 유사하지만 더 안전하고 유연한 새로운 문자열 형식입니다.
• PEP 734: stdlib에 다중 인터프리터: 하나의 프로세스에서 여러 개의 독립적인 Python 인터프리터를 실행할 수 있습니다.
• PEP 784: 새로운 compression.zstd 모듈: Zstandard 압축 알고리즘을 지원하여 더 빠르고 효율적인 데이터 압축이 가능합니다.
• PyREPL의 구문 강조 표시 및 색상 지원: unittest, argparse, json, calendar CLI에서 색상을 지원하여 가독성을 높였습니다.

주요 변경 사항

• PEP 761: 릴리스 아티팩트에 대한 PGP 서명 중단: 더 이상 PGP 서명을 제공하지 않고 Sigstore 사용을 권장합니다.
• 실험적인 JIT 컴파일러 포함: 공식 macOS 및 Windows 릴리스 바이너리에 실험적인 JIT 컴파일러가 포함되어 성능이 향상될 수 있습니다.
• 공식 Android 바이너리 릴리스: 이제 Android에서도 공식적으로 Python을 사용할 수 있습니다.
• 새로운 Windows 설치 관리자: Windows Store 또는 다운로드 페이지에서 설치할 수 있는 새로운 설치 관리자로 교체됩니다.

https://www.python.org/downloads/release/python-3140/

구글이 팬데믹 시기에 도입했던 ‘어디서나 근무(Work from Anywhere·WFA)’ 제도를 사실상 폐지 수준으로 축소했다. 이로써 미국 빅테크 전반의 사무실 복귀 흐름이 한층 가속화되고 있다.

미 CNBC에 따르면 구글은 최근 내부 문서를 통해 ‘WFA 제도’를 개정하고, 직원이 한 주 중 단 하루만 원격으로 일하더라도 ‘1주일 사용‘으로 간주한다고 통보했다. 기존에는 연간 4주 한도 내에서 원하는 장소에서 근무할 수 있었지만, 이번 조치로 사실상 활용이 크게 제한된 셈이다. 문서에는 “표준 근무 주 중 1일 또는 5일을 원격으로 일하더라도 WFA 잔여 주에서 1주가 차감된다”라는 내용이 담겼다. 이 문서는 여름부터 직원들에게 공지됐으며 최근 정식 시행에 들어간 것으로 알려졌다.

이번 개정은 기본적으로 주 3일 출근, 주 2일 재택을 허용하는 기존 ‘하이브리드 근무제’와는 별개다. WFA는 본사나 집이 아닌 다른 지역(타 도시나 타국 등)에서 일하는 것을 뜻한다. 다만 데이터센터나 현장 근무가 필수인 일부 조직은 적용 대상에서 제외된다.

구글은 올해 4월에도 일부 부서에 원격근무자 해고 가능성을 통보하고, 사무실 반경 50마일(약 80km) 내에 거주하면서도 출근하지 않는 직원에게는 자발적 퇴직(바이아웃) 프로그램을 제안한 바 있다. 당시 구글은 “대면 협업은 혁신과 복잡한 문제 해결의 핵심”이라고 강조했다. 이번 정책에는 해외 체류 중 WFA 근무를 금지하는 조항도 포함됐다. 회사는 “국가 간 근로는 법적·재정적 문제를 초래할 수 있다”라며 타국 구글 오피스에서 일하는 것도 제한했다.

이러한 변화는 빅테크 기업의 전반적인 흐름과 일치한다. 애플은 주 3일 출근을 의무화하고 사원증(배지) 출입 기록으로 출근 여부를 관리하고 있다. 메타는 지난해 9월 같은 기준을 도입하며 불이행 시 성과 평가 불이익이나 해고로 이어질 수 있다고 경고했다. 아마존은 ‘커피배징(짧은 방문으로 출근 처리)’을 단속하며 주 5일 출근 확대를 추진 중이다. 마이크로소프트 역시 대부분의 직원에게 주 3일 출근을 권장하는 ‘표준 근무 기준’을 정착시켰다.

켈시 샤메트 미국 고용 전문 변호사는 포춘과 인터뷰에서 “팬데믹 이후 직원들이 기대해온 유연 근무 환경이 줄어드는 것은 사기 저하와 이직률 증가로 이어질 수 있다”라며 “특히 높은 성과를 내는 인재일수록 더 유연한 근무 환경을 찾아 떠날 가능성이 크다”라고 말했다.

이러한 조치가 단순한 생산성 강화 목적을 넘어 인력 재편 전략의 일환이라는 분석도 나온다. 미국 연방준비제도(Fed)의 ‘베이지북’ 보고서에 따르면 일부 기업 경영진은 “RTO(사무실 복귀) 정책이 공식 해고 없이 인력 감축을 촉진했다”고 인정하기도 했다. 자발적 퇴사자는 해고수당이나 의료보험 혜택을 받지 못하기 때문에 이를 두고 ‘값싼 해고(layoffs on the cheap)’라는 지적이 나오기도 한다.

이 같은 기조는 포춘 100대 기업 전반으로 확산 중이다. 완전 출근을 요구하는 기업 비율은 2023년 5%에서 2025년 50% 이상으로 늘었으며 연말까지 30%가 주 5일 출근제를 시행할 것으로 전망된다.

다만 에어비앤비, 스포티파이, 핀터레스트 등 일부 기업은 여전히 유연한 원격근무 정책을 유지하며 차별화를 꾀하고 있다. 에어비앤비는 ‘어디서나 생활하고 일하기(Live and Work Anywhere)’ 정책을 유지 중이며 스포티파이는 직원과 매니저 협의로 근무지를 자유롭게 선택하도록 하고 있다.

https://www.mk.co.kr/news/it/11438931

서점은
공공 공간이다.
공공 자산이다.
나라와 사회를 더 도덕적이고
더 정의롭게 일으켜 세우는 인프라다!
민주주의의 기초 조건이다. 도서관과 같은 차원에서
논의되고 육성하는 정책이 수립되고 실현되어야
한다. 서점을 위한 '문화운동, 사회운동'이
전개되기를 기대해 본다.


- 김언호의《세계서점기행》중에서 -


* 서점은
특별한 공간입니다.
책을 만나고 사람을 만나고
지식과 지혜, 문화와 문명을 만납니다.
더러는 서점에서 친구도 만나고 연애도 합니다.
공공 공간, 공공 자산도 되지만 특별한 개인 공간,
개인 자산이 되기도 합니다. 서점을 살리는
사회운동, 문화운동이 필요합니다.

지혜

때를 안다

나를 만들어준 소프트웨어 에세이들  

https://refactoringenglish.com/blog/software-essays-that-shaped-me/

• 20년간 수천 개의 소프트웨어 블로그 글을 읽었지만, 소수의 에세이만이 사고방식을 근본적으로 변화시켰으며, Joel Spolsky의 "Joel Test"부터 Julia Evans의 순수 JavaScript 옹호까지 10개의 핵심 에세이 소개
• Joel Spolsky의 "Joel Test"는 고용주가 개발자를 존중하는지 평가하는 12개 질문을 제시하며, 소스 관리, 일일 빌드, 버그 우선 수정 등을 통해 개발자의 시간과 집중을 우선시하는지 확인
• Alexis King의 "Parse, don't validate"는 데이터 검증 시 새로운 타입으로 변환하는 기법을 소개하여, 타입 시스템이 애플리케이션 보안과 신뢰성 향상에 기여할 수 있음을 보여줌
• Fred Brooks의 "No Silver Bullet"은 소프트웨어 작업을 본질적 복잡성과 우발적 복잡성으로 구분하며, 도구와 하드웨어 발전으로는 10배 생산성 향상 불가능하다고 주장했으나 AI는 이 이론에 변수를 던짐
• Julia Evans의 순수 JavaScript 에세이는 프레임워크 없이도 ES2018 JavaScript만으로 충분하다는 깨달음을 주었고, 이후 2020년부터 어떤 프로젝트에도 JavaScript 프레임워크나 빌드 스텝을 통합하지 않음

Joel Spolsky의 "Joel Test" (2000)

• Joel Spolsky는 역대 최고의 소프트웨어 블로거이며, 그의 에세이들이 필자의 소프트웨어 접근 방식에 많은 영향을 미침
• "Joel Test"는 고용주가 소프트웨어 팀에 얼마나 잘 투자하는지 평가하는 12개 질문 세트
• 12개 질문 목록
  • 소스 관리 사용 여부
  • 한 단계로 빌드 가능 여부
  • 일일 빌드 수행 여부
  • 버그 데이터베이스 보유 여부
  • 새 코드 작성 전 버그 수정 여부
  • 최신 일정 보유 여부
  • 스펙 보유 여부
  • 프로그래머가 조용한 작업 환경을 가지는지
  • 돈으로 살 수 있는 최고의 도구 사용 여부
  • 테스터 보유 여부
  • 신규 후보자가 인터뷰 중 코드 작성 여부
  • 복도 사용성 테스트 수행 여부
• 핵심 메시지
  • 일부 질문은 시대에 뒤떨어졌지만, 질문 자체가 아니라 질문의 메타 포인트가 중요
  • Joel이 실제로 묻는 것: 개발자를 존중하는가?
  • 모든 질문은 고용주가 저렴한 사무 공간과 단기 마감일보다 개발자의 시간과 집중을 우선시하는지 평가
  • 닷컴 붐 정점에 게시되었으며, 숙련된 개발자가 귀중한 자원이었지만 모두가 이를 깨닫지는 못한 시기
  • Joel의 블로그는 항상 프로그래머를 희귀하고 섬세한 천재로 제시하여 고용주가 추구하고 아껴야 할 대상으로 묘사
  • 필자는 경력 내내 Joel Test에서 높은 점수를 받는 고용주를 찾았으며, 그 지도를 제공한 Joel에게 감사

Alexis King의 "Parse, don't validate" (2019)

• Haskell의 타입 시스템 활용에 관한 에세이이지만, 타입 시스템이나 Haskell에 관심이 없어도 소프트웨어 사고방식을 근본적으로 변화시킴
• Go, C++, Rust 등 정적 타입을 지원하는 모든 언어에서 Alexis의 기법 사용 가능
• 핵심 개념
  • 데이터를 검증할 때마다 새로운 타입으로 변환해야 함
  • 예시: 사용자 이름을 최대 20자 영숫자로 제한하는 규칙이 있을 때, 순진한 솔루션은 validateUsername(username string) error 함수
• 문제점
  • 코드가 기본적으로 안전하지 않음
  • 수신한 모든 사용자 이름을 검증해야 하므로, 실수로 검증 없이 사용자 이름을 처리하는 코드 경로 생성 쉬움
  • 악의적 사용자가 실수를 발견하면 사용자 이름 필드에 악성 코드 삽입하거나 수십억 문자로 채워 서버 리소스 고갈 가능
• Alexis의 솔루션
  • parseUsername(raw string) (Username, error) 함수 사용
  • 코드베이스의 나머지 부분에서 "username"이라는 string 대신 커스텀 타입 Username 사용
  • Username을 생성할 수 있는 유일한 함수는 parseUsername이며, 이는 Username 인스턴스를 반환하기 전에 검증 규칙 적용
  • Username 인스턴스가 있으면 유효한 사용자 이름을 포함해야 함
  • 신뢰할 수 없는 입력은 항상 string이므로, Username을 예상하는 함수에 string 전달 불가능
• 영향
  • 이 에세이 이전에는 타입 시스템이 언어 너드를 산만하게 하는 재미있는 방법이라고 생각
  • "Parse, don't validate"는 컴파일러 기능이 애플리케이션의 보안과 신뢰성 향상에 얼마나 가치 있는지 눈을 뜨게 함

Fred Brooks의 "No Silver Bullet" (1986)

• 대학에서 Fred Brooks의 The Mythical Man-Month 읽음
• IBM의 OS/360 프로젝트 지휘 경험을 바탕으로 한 소프트웨어 엔지니어링 에세이 모음집
• 본질적 복잡성과 우발적 복잡성
  • 본질적 복잡성: 도구와 하드웨어에 관계없이 반드시 수행해야 하는 작업
    • 예: 영업 사원 보너스 계산 소프트웨어에서 보너스 공식 정의 및 모든 엣지 케이스 커버
    • $5B 슈퍼컴퓨터든 $1 마이크로컨트롤러든 동일한 작업
  • 우발적 복잡성: 그 외 모든 것
    • 메모리 누수 처리, 코드 컴파일 대기, 제3자 라이브러리 사용 방법 파악
    • 도구와 하드웨어 리소스가 좋을수록 우발적 복잡성에 소비하는 시간 감소
• Brooks의 결론
  • 도구나 하드웨어의 발전이 개발자 생산성에 10배 향상을 만들어내는 것은 불가능
  • 모든 우발적 활동을 제로 시간으로 줄여도 전체 노력의 9/10 이상이 아니면 규모 향상 불가능
• 적용 사례
  • 경력 내내 사람들이 소프트웨어에서 프로그래머를 제거하려고 시도
  • 노코드 플랫폼이 비프로그래머에게 숙련된 웹 개발자의 모든 권한을 약속하며 화제 생성
  • Brooks의 에세이는 최신 버즈워드 플랫폼이 개발자를 대체할 수 없다고 항상 안심시킴
  • 플랫폼은 우발적 복잡성에 집중하며, 본질적 복잡성에는 집중하지 않음
  • 플랫폼이 기능 사양에서 마법처럼 작동하는 코드를 만들 수 있어도, 여전히 사양을 작성할 누군가가 필요
• AI의 영향
  • 현대 AI는 Brooks의 이론에 렌치를 던짐
  • AI는 실제로 본질적 복잡성을 줄임
  • 불완전하거나 모순된 사양을 AI에 전달하면, AI가 유사한 사양에서 차용하여 공백 채움
  • AI가 알려진 프로그래밍을 제거하더라도, Brooks의 에세이는 결국 어떤 추상화 수준에서든 본질적 복잡성을 관리할 사람이 여전히 필요하다는 희망 제공

Joel Spolsky의 "Choices" (2000)

• 좋아하는 Joel Spolsky 에세이를 하나만 선택하기 어려워 두 개 선택
• "Choices"는 사용자 인터페이스 생성과 사용자에게 권한을 부여하는 미묘한 비용에 관한 것
• 핵심 메시지
  • 옵션을 제공할 때마다 사용자에게 결정을 요청하는 것
  • 사용자가 무언가에 대해 생각하고 결정해야 함을 의미
  • 반드시 나쁜 것은 아니지만, 일반적으로 사람들이 내려야 하는 결정의 수를 최소화하려고 노력해야 함
• Windows 98 예시
  • Joel은 Windows 98에서 도움말 문서 검색 시 나타나는 황당한 대화상자 공유
  • 대화상자가 Joel을 분노하게 만든 이유:
    • 사용자가 도움을 받으려고 할 때 중단
    • 데이터베이스 최적화에 대한 정보 없는 결정을 내리도록 요청
    • Windows가 결정을 회피하고 사용자에게 떠넘김
• 적용 범위
  • Joel의 에세이는 그래픽 사용자 인터페이스에 초점을 맞추지만, 필자는 명령줄이나 작성한 함수를 호출하는 다른 개발자를 포함하여 코드를 접할 수 있는 모든 곳에서 이를 고려
  • 사용자를 대신하여 유용한 결정을 내릴 수 있는지, 동시에 그들이 관심 있는 것에 대한 권한을 제공할 수 있는지
  • Joel의 에세이는 내가 직접 내릴 수 있는 결정을 사용자에게 떠넘기는 것을 무수히 막아줌

Raymond Chen의 "“Application compatibility layers are there for the customer, not for the program” (2010)

• Raymond Chen은 Microsoft Windows 팀에서 가장 오래 근무한 개발자 중 한 명
• 블로그에는 Windows 프로그래밍 역사에 대한 수천 개의 유익하고 재미있는 이야기가 있음
• 고객 요청 사례
  • Windows Vista 호환성 모드에 관한 고객 요청:
    • Windows XP 및 Windows Server 2003용으로 설계된 프로그램이 Windows Vista에서 어려움 겪음
    • Windows XP 호환성 모드로 설정하면 Vista에서 잘 작동
    • Vista에서 실행 시 자동으로 XP 호환성 모드로 실행되도록 설치 프로그램에 어떤 변경 필요한지 질문
• Raymond의 비유
  • "나는 일반적으로 애완동물 가게 앞 보도에 쓰레기를 버리고, 매일 아침 가게가 열리면 누군가 쓰레기를 쓸어 쓰레기통에 버립니다. 하지만 애완동물 가게는 일요일에 열지 않아서, 일요일에는 쓰레기가 그냥 거기 있습니다. 일요일에도 애완동물 가게를 열게 하려면 어떻게 해야 하나요?"
• 교훈
  • 비유가 너무 재미있어서 Raymond가 틀렸다는 것을 이제야 알아챔
  • 단일 릴리스 후 Windows가 앱을 깨뜨리지 않을 것으로 기대한 개발자의 죄를 조롱
  • 세부 사항에는 동의하지 않지만, Raymond의 글은 매우 재미있고 날카로워 결함을 넘어설 수 있음
  • 훌륭한 사용자 행동 영향 교훈:
    • 사용자가 당신을 돕는 무언가를 하도록 유도하려면, 사용자 관점에서 저항이 가장 적은 경로를 신중히 생각해야 함
    • 보도에 쓰레기를 버리는 것이 문제를 완전히 해결한다고 보여주면, 계속 그렇게 할 것

Erik Kuefler의 "Don’t Put Logic in Tests" (2014)

• 필자는 항상 단위 테스트를 좋아했고 테스트 코드에 큰 자부심을 가짐
• 이 에세이가 화장실에 나타나 경력 내내 끔찍한 테스트를 작성해왔음을 폭로해 충격
• 문제가 있는 테스트 예시
• @Test public void shouldNavigateToPhotosPage() { String baseUrl = "http://plus.google.com/";; Navigator nav = new Navigator(baseUrl); nav.goToPhotosPage(); assertEquals(baseUrl + "/u/0/photos", nav.getCurrentUrl()); }
• 발견한 문제점
  • 처음 에세이를 읽었을 때 "내가 단위 테스트를 작성하는 방식과 정확히 같다!"고 생각
  • http://plus.google.com/ 문자열을 두 곳에 중복하는 이유는? 프로덕션 코드처럼 단일 진실 소스 생성
  • 필자는 테스트에서 중복을 제거하기 위해 헬퍼 함수, 변수, 루프를 추가하는 것을 항상 했음
  • 문제는 이 접근 방식이 미묘한 버그를 가림: 실제로는 http://plus.google.com//u/0/photos를 assert(슬래시 두 개)
• 깨달음
  • Erik의 에세이는 테스트 코드를 프로덕션 코드처럼 취급하지 말아야 함을 보여줌
  • 두 가지는 완전히 다른 목표와 제약 조건을 가짐
  • 좋은 테스트 코드는 무엇보다도 명확해야 함
  • 테스트 코드에는 자체 테스트 코드가 없으므로, 정확성을 검증하는 유일한 방법은 검사
  • 테스트는 어떤 동작을 assert하는지 독자에게 눈이 멀 정도로 명백해야 함
  • 이 목표를 위해 복잡성을 줄이기 위해 중복 허용 가능

Julia Evans의 “A little bit of plain Javascript can do a lot” (2020)

• 소프트웨어 엔지니어로서 웹에 당혹스럽게도 늦게 입문
• 경력 첫 10년간 데스크톱 앱과 백엔드 서버용 코드만 작성
• 2017년까지 HTML이나 JavaScript를 신경 쓰지 않음
• 프레임워크에 대한 오해
  • 프론트엔드 개발 학습을 진지하게 시작했을 때, JavaScript는 10일 만에 만들어진 엉망인 언어이며 브라우저마다 동작이 크게 다르다는 인상
  • 웹 앱을 작성하려면 JavaScript의 모든 담즙과 결점으로부터 보호해주는 현대적이고 세련된 무언가가 필요
  • Angular, React, Vue 같은 인기 있는 웹 프레임워크 시도
  • Vue를 충분히 학습했지만 여전히 의존성 문제와 프레임워크 함정에 엄청난 시간 소비
  • 이 모든 프론트엔드 프레임워크가 JavaScript를 수정하기 위해 한 작업 후에도 웹 프로그래밍은 여전히 형편없었음
• Julia의 에세이가 준 깨달음
  • JavaScript가 수정이 필요하다고 너무 확신한 나머지 기회를 주지 않았음을 깨달음
  • TinyPilot 프로토타입 작업 중이었고, Vue로 웹 인터페이스를 구현할 계획
  • Julia의 에세이가 순수 JavaScript로 얼마나 갈 수 있는지 보도록 영감을 줌
  • 프레임워크, 래퍼 라이브러리, 빌드 스텝, Node.js 없이, 그냥 일반 JavaScript(ES2018)만 사용
  • 프레임워크나 빌더로 전환해야 할 문제에 부딪힐 것으로 계속 예상했지만 결코 일어나지 않음
  • WebComponents 관련 몇 가지 함정은 있었지만, Vue와 Angular로 겪은 고통에 비하면 아무것도 아님
• 프레임워크 없는 자유
  • 프레임워크에서 자유로워지는 것을 좋아함
  • 런타임 오류가 있을 때, 스택 트레이스가 축소되고 변형되고 트리 쉐이크된 코드의 열악한 꿈이 아님
  • 작성한 대로 내 코드를 디버깅하는 것
  • JavaScript에 대한 편견이 틀렸음
  • 현대 JavaScript는 꽤 좋으며, 래퍼 라이브러리의 많은 아이디어를 흡수하여 이제 래퍼가 필요 없음
  • 브라우저들이 플랫폼과 디바이스 간 일관된 동작을 보장하기 위해 정신을 차림
  • 2020년 이후 어떤 새 프로젝트에도 JavaScript 프레임워크나 빌드 스텝을 통합하지 않았으며 뒤돌아보지 않음
  • 순수 JavaScript로 프레임워크 이점의 90%를 5%의 골칫거리로 얻음

Dan McKinley의 “Choose Boring Technology” (2015)

• 이 목록에 포함하기 이상한 에세이인 이유는 실제로 읽어본 적이 없기 때문
• 사람들이 이 에세이를 인용했고, 아이디어를 이해하자 너무 직관적이어서 읽을 필요를 느끼지 못함
• 핵심 아이디어
  • 새 프로젝트를 시작할 때 화제가 많은 최첨단 기술을 사용하고 싶은 유혹
  • Google이 엑사바이트까지 확장되는 새 데이터베이스를 발표했고, Postgres보다 40% 빠르고 비용은 20%
  • 이 섹시한 새 대안이 바로 거기 있을 때 Postgres를 사용하면 바보
  • 실제로 새 기술에는 버그와 약점이 있지만, 아직 명백하지 않음
  • 이에 부딪히면 막막함
  • Postgres는 문제가 있지만, 30년의 현장 경험 후 직면할 가능성이 있는 모든 문제에 대한 검증된 솔루션 보유
• 혁신 토큰 개념
  • Dan은 가끔 새 기술을 사용해야 한다고 인정하지만 전략적으로 그리고 제한된 수량으로만
  • 모든 비즈니스는 소비할 세 개의 "혁신 토큰" 을 얻음
  • 화려한 새 데이터베이스를 원하면 토큰 중 하나를 소비해야 함
  • Dan의 에세이는 Julia의 에세이와 자연스럽게 맞물림
  • 프론트엔드 프레임워크로 그 모든 시간을 낭비하기 전에 둘 중 하나라도 읽었으면 좋았을 것

Terence Eden의 “I’ve locked myself out of my digital life” (2022)

• Terence Eden은 유쾌하고 절충적인 기술 블로거
• 매주 여러 새 글을 쓰지만, 가장 큰 영향을 준 것은 "디지털 생활에서 나 자신을 잠갔다"
• 재난 시나리오
  • 번개가 Terence의 집을 치고 모든 소유물을 파괴하면 어떻게 될지 시뮬레이션
  • 비밀번호 관리자에 모든 것에 대한 비밀번호 보관
  • 모든 디바이스가 파괴되면 비밀번호 관리자에 액세스 불가능
  • 하드웨어 패스키로 대체할 수 없는 이유는 그것들도 집에 있었기 때문
• 깨달음
  • 필자는 중복 드라이브에 모든 것을 저장하고 두 벤더로 세 대륙에 오프사이트 백업을 가지고 있어 데이터에 대해 꽤 안전하다고 느낌
  • Terence의 글은 모든 디바이스를 동시에 없앨 수 있는 많은 신뢰할 수 있는 위협에 대해 생각하게 함: 화재, 홍수, 전기 서지, 범죄 수사
  • 모든 데이터는 머릿속에 있는 비밀번호로 암호화되어 있으므로, 기억 상실, 무능력, 사망도 목록에 추가
• 온라인 서비스의 문제
  • 온라인 서비스는 사용자가 재난에서 복구하는 데 도움을 주는 데 취약
  • 전화를 잃는 것이 불가능하다고 가정하는 여러 서비스 사용, 이메일 계정과 소유한 모든 디지털 디바이스는 말할 것도 없이
• 영향
  • Terence의 에세이를 읽은 이후 어떤 서비스와 디바이스가 중요한지, Terence가 설명한 시나리오에서 어떻게 복구할 수 있는지 더 많이 고려
  • 다음 노트북을 구입했을 때 도서관에서 설정하여 집에 있는 디바이스 없이 비밀번호 관리자와 중요한 계정에 대한 액세스를 복구할 수 있는지 테스트
  • 여전히 디지털 재난 대비를 더 잘할 수 있지만, Terence의 글은 디바이스와 데이터 보안 방법을 생각할 때마다 머릿속에서 울림
  • 모든 것이 갑자기 파괴되면 어떻게 될까?

보너스: Brad Fitzpatrick의 "parsing user input" (2009)

• 기술적으로 에세이는 아니지만, 소프트웨어 인터뷰의 인용문을 지속적으로 생각
• 2009년 Joel Spolsky의 극찬 리뷰 결과로 Coders at Work 읽음
• 성공한 프로그래머들과의 인터뷰 모음집
• Brad Fitzpatrick의 명언
  • LiveJournal과 Memcached 창시자 Brad Fitzpatrick이 인터뷰이 중 한 명으로 등장
  • 당시 28세로 책에서 가장 어린 프로그래머이자 가장 욕이 많고 재미있는 사람
  • 소프트웨어 엔지니어링 윤리에 대한 질문에 입력 검증에 대한 열정적인 발언:
    • "모두가 신용카드 양식에서 공백이나 하이픈을 입력할 수 있게 일관되게 해주기를 요청하고 싶습니다. 컴퓨터는 그런 것들을 제거하는 데 능숙합니다. 내 숫자를 어떻게 포맷할지 말하지 마세요."
• 적용
  • 웹 양식에 전화번호를 붙여넣으려고 할 때마다 이 인용문을 떠올림
  • 괄호나 공백이 허용되지 않는다고 투덜거리거나, 더 나쁜 경우 괄호 때문에 전화번호를 잘라내고 괄호가 허용되지 않는다고 불평
  • 소프트웨어에서 입력 필드를 만들고 예상치 못한 문자에 대해 생각할 때마다 Brad Fitzpatrick이 "컴퓨터는 그런 것들을 제거하는 데 능숙합니다" 라고 말하는 것을 들음