컴퓨터 코딩보다 더 어려운 인간 코딩

• 개발자 도구는 컴퓨터가 실행할 논리뿐 아니라 다른 사람이 이해하고 사용할 정신 모델까지 설계해야 해서 더 어려움
• 빠른 온보딩은 부가 기능이 아니라 제품 자체에 가까우며, 설정·API 토큰·초기 실행 마찰을 줄여 몇 분 안에 노트북에서 써볼 수 있어야 함
• 사용자는 긴 핵심 개념 설명보다 작동하는 예제를 바꿔 보며 패턴을 익히고, 문제에 가까운 출발점이 많을수록 성공 가능성이 커짐
• 오류 메시지, 개념 수, 이름 짓기, 설정 방식, 기본값, 매직, 문법 설탕은 모두 사용자의 성공 경로를 바꾸므로 읽기 쉽고 커스터마이즈 가능한 설계가 필요함
• 좋은 개발자 경험은 기능을 단순히 줄이는 일이 아니라, 만들 수 있는 범위는 유지하면서 알아야 할 복잡성을 크게 낮추는 일임

---

인간을 위한 코드는 정신 모델까지 다룸

• 컴퓨터를 위한 코드는 큰 비즈니스 목표를 논리적 문장으로 쪼개 컴퓨터가 따를 수 있게 만드는 작업임
• 프레임워크, 라이브러리, API, SDK, DSL, 임베디드 DSL, 프로그래밍 언어처럼 사람이 직접 다루는 코드는 실행 가능성만으로 충분하지 않음
• 이런 코드는 컴퓨터에 지시하는 동시에, 사용자가 그 코드를 어떻게 읽고 이해할지도 함께 다뤄야 함
• 개발자 도구 설계에는 컴퓨터 과학뿐 아니라 사용자의 추론 방식을 고려하는 심리적 이해가 필요함

시작 경험이 곧 제품임

• 개발자 도구의 피드백은 대개 제품을 자주 쓰는 파워 유저에게서 많이 옴
• 시작 단계에서 막힌 사용자는 피드백을 남기지 않기 때문에 생존자 편향이 생김
• 소비자 제품이 온보딩 퍼널을 최적화하듯, 개발자 도구도 첫 실행까지의 과정을 제품의 핵심으로 봐야 함
• 빠른 온보딩을 위해서는 제품 구조 자체를 바꿀 가치가 있음
  • 필수 설정 제거
  • API 토큰 설정을 매우 쉽게 만들기
  • 초기 마찰 줄이기
  • 사용자가 몇 분 안에 자신의 노트북에서 제품을 써볼 수 있게 만들기
• 개발자 도구가 너무 많아진 환경에서는 사용자가 특정 LRU cache NPM 패키지의 차이를 깊게 이해할 에너지나 인내심을 갖기 어려움

예제는 핵심 개념보다 빠르게 가르침

• 사람은 엄격한 명령을 따르는 컴퓨터와 달리 패턴 매칭에 강함
• 많은 개발자 도구 문서는 핵심 데이터 모델, 관계, 원자적 개념, 설정, 실행 방법부터 설명하지만, 사람은 작동하는 사례를 바꾸고 결과를 보며 더 잘 배움
• 5,000단어짜리 “core concepts” 설명보다 여러 개의 예제가 더 유용할 수 있음
  • 사용자는 예제를 보며 도구의 동작 방식을 익힘
  • 해결하려는 문제가 있는 사람은 충분히 가까운 출발점을 찾을 수 있음
  • 출발점이 많을수록 필요한 것에 가까운 예제를 만날 가능성이 커짐

사용자를 성공의 구덩이로 밀어 넣기

• 프로그래밍의 기본 상태는 어떤 종류의 오류를 계속 고치는 일에 가까움
• 사용자는 도구를 쓰는 시간 대부분을 “무엇이 동작하지 않는지” 파악하는 데 쓸 수 있음
• 개발자가 더 빨리 성공하면 도구를 좋아하지만, 오류에 계속 막히면 도구를 탓하게 됨
• 모든 오류는 사용자를 행복한 경로로 되돌릴 기회임
  • 예외 메시지에 코드 스니펫 넣기
  • 사용자가 이상한 일을 할 가능성이 있을 때 유용한 경고 출력하기
  • 사용자가 성공하는 데 필요한 조치 제공하기

개념 과부하 줄이기

• 도구를 쓰기 전에 이해해야 하는 새로운 개념은 각각 마찰 지점이 됨
• 2~3개 개념은 받아들일 수 있어도, 8개 새 개념을 배우려는 사용자는 많지 않음
• Kubernetes는 시작할 때 모든 개념이 필요하지는 않지만, 새 개념이 많아질수록 부담이 커짐
• 강력하면서도 3~5개 개념만 가진 프레임워크에는 우아함이 있음
• React를 처음 쓸 때 한두 시간 뒤 개념적 언덕을 넘으면, 몇 개의 단순한 빌딩 블록으로 큰 구조를 만들 수 있다는 느낌을 줄 수 있음
• 목표는 단순히 개념 수를 줄이는 것이 아니라, 만들 수 있는 범위를 유지하면서 사용자가 알아야 할 개념을 줄이는 것임
• 훌륭한 도구는 복잡성을 90% 줄이면서 능력을 그대로 유지할 수 있음
• 복잡성을 90% 줄이고 능력을 10%만 줄이는 도구도 나쁘지 않음

개념적 오리 원칙

• 프레임워크 안에 값을 받아 새 값을 계산하는 요소가 있다면 “compute node”, “valuator”, “frobniscator” 같은 새 이름보다 function이라고 부르는 편이 나음
• 어떤 것이 오리처럼 걷고 오리처럼 꽥꽥거리면 오리일 가능성이 높다는 원칙을 개념 설계에도 적용할 수 있음
• 미묘한 차이가 있거나 값이 캐시되더라도 function에 충분히 가깝다면 function이라고 부를 수 있음
• 기존 용어를 쓰면 사용자가 이미 가진 정신 모델에 연결되어 설명해야 할 양이 크게 줄어듦

프로그래밍 가능하게 만들기

• 사용자는 코드베이스로 예상 밖의 일을 하며, 프레임워크 요소를 for-loop 안, 함수 안, 다른 구조 안에 넣을 수 있음
• 그래서 프레임워크의 거의 모든 것은 프로그래밍 가능해야 함
• 관련 설계 방향은 서로 연결되어 있음
  • CLI를 거치지 않고 코드에서 직접 호출할 수 있게 하기
  • 설정 파일을 줄이고 SDK나 API로 바꾸기
  • 하나만 만들 수 있게 하지 말고 매개변수화해서 n개를 만들 수 있게 하기
• 이런 설계는 사용자가 새로운 사용 사례를 발견하게 만들 수 있음
• 프레임워크 위에서 “해킹”하려는 욕구를 활용하면 약간의 혼란이 생겨도 예상 밖의 발견으로 이어질 수 있음

매직, 기본값, 문법 설탕은 신중해야 함

• 클라우드에서 Jupyter notebook을 실행하는 run_notebook 함수가 있고, 사용자가 어떤 컨테이너 이미지를 쓸지 지정해야 한다고 가정함
• 가능한 선택지는 여러 가지임
  • image=... 인자를 항상 필수로 받기
  • 대부분의 데이터 과학 라이브러리가 설치된 기본 이미지를 두고 사용자가 오버라이드하게 하기
  • 셀의 코드를 검사해 필요한 의존성에 따라 “매직” 방식으로 이미지 고르기
  • 매직 방식에 더해 사용자가 특정 이미지를 선택할 수도 있게 하기
• 입력량을 줄이고 가장 넓은 사용 사례를 지원하려면 마지막 선택지가 좋아 보일 수 있음
• 하지만 첫 번째 선택지를 제외하면 문제가 남음
  • 매직은 일부 상황에서 깨짐
  • 기본값에 의존하는 코드를 읽는 사용자는 커스터마이즈 가능성을 알아차리지 못할 수 있음
• 기본값이 97% 이상 적용되고 매직이 99% 이상 맞는 수준이 아니라면 매우 신중해야 함
• 코딩은 골프가 아니며, 도구 제공자의 일이 사용자가 쓰는 코드 양을 최소화하는 것만은 아님
• Perl은 짧은 코드에 강하게 최적화했지만 프로그램이 특수문자 나열처럼 보일 수 있었고, Python은 코드가 50% 길어도 읽기 쉽고 이해하기 쉬웠음
• 사람들은 코드를 쓰는 것보다 10배 더 많이 읽기 때문에 읽기 쉬움이 중요함
• 문법 설탕도 같은 기준으로 봐야 함
  • 흔한 사용 사례에 특수 문법을 넣고 싶을 수 있음
  • 하지만 일관성을 흐리고 커스터마이즈 방법을 덜 명확하게 만들 수 있음
  • 문법 설탕이 99% 이상 적용되지 않는다면 도입하지 않는 편이 나을 수 있음

처음 쓰는 사람을 위한 설계 원칙

• 인간을 위한 코드 작성에는 더 많은 설계 문제가 남아 있음
  • 대부분은 불변이어야 하지만 전부는 아님
  • 스캐폴딩, 즉 코드 생성을 피하기
  • 피드백 루프를 매우 빠르게 만들기
  • 사용자가 폐기 예정 기능에 쉽게 대응할 수 있게 하기
  • 문서와 예제의 코드 스니펫에 자동화 테스트 쓰기
• 첫 사용자 경험을 설계하는 일은 팝송을 만드는 일과 비슷함
• 프로듀서는 노래를 천 번 듣더라도, 999번째 들을 때 처음 듣는 사람에게 어떻게 들릴지 상상해야 함
• 개발자 도구에서도 반복해서 만든 사람이 처음 쓰는 사용자의 경험을 상상하는 일은 매우 어려움

[GN⁺]

Hacker News 의견들

• 사람마다 배우는 방식이 다름. 나는 예제로 들어가기 전에 먼저 핵심 개념이 필요함. 핵심 개념이 아주 단순한 경우가 아니라면 더욱 그렇다
  많은 튜토리얼은 손잡고 레고를 조립하는 방식과 비슷함. “여기 레고 조각이 있으니, 내가 장난감 프로젝트를 만드는 걸 따라 하면 하루가 끝날 때쯤 레고를 할 줄 알게 된다”는 식임
  나는 이런 방식이 잘 맞지 않음. 결정이 어떻게, 왜 내려지는지 알고 싶고, 저자의 관점에서 보고 싶음. 레고 조각 각각이 어떤 느낌인지, 서로 어떻게 연결되는지, 특정 설계에 어떻게 도달하는지 알고 싶다
  최소한의 고수준 개념 설명 없이 튜토리얼을 따라가는 건, 굳이 그럴 필요가 없어야 할 것을 역공학하는 느낌임. 새 라이브러리나 프레임워크를 볼 때는 소개 글을 읽고 “시작하기” 코드 예제는 건너뛰는 편임. 보통 “고급” 섹션에 개념 논의가 더 많아서 거기부터 보고, 다음에는 API 참조로 중요한 인터페이스를 파악한 뒤, 마지막에 튜토리얼 초반의 기본 코드 예제로 돌아감

  • 예전에는 내가 “핵심 개념”형 사람이라고 생각했지만, 나중에는 그걸 너무 멀리 밀고 갔다는 걸 깨달음. 미리 모든 걸 진짜 이해했다고 느끼기 전에는 안전지대 밖의 일을 거부하곤 했음
    요즘은 그냥 뛰어들어 예제로 바로 작업하는 경우가 훨씬 많고, 생산성도 더 높다고 느낌. 어느 정도는 신뢰의 문제임. 품질 좋은 소프트웨어를 만든 사람들이 일반적인 사용 사례에서는 내부를 깊게 파지 않아도 인터페이스를 이해하기 쉽게 만들 만큼 충분히 고민했을 거라고 믿는 것임
    물론 더 깊이 들어가야 하는 장애물을 자주 만나긴 함. 하지만 표면적인 인상만으로도 성공적으로 넘어간 다른 10가지가 있었기 때문에 그런 상황이 생김. 그래서 실제로 깊게 파고들 때도 대개 시간 낭비가 아니라고 봄
  • 정말 공감함. 처음 시작할 때 create-react-app 같은 “프로젝트 생성기”를 싫어함. 예시일 뿐이고, React를 그게 생기기 훨씬 전에 배워서 다행이라고 생각함
    이런 도구는 특정한 폴더 구조, 템플릿 파일, 미리 설정된 도구들을 만들어냄. 생성된 파일들이 무엇을 하는지, 왜 그렇게 만들어졌는지 고수준으로 즉시 이해하지 못하면, 이해하지 못하는 마법이 너무 많아서 불편해짐
    새로운 것이 들어올 때마다, 이미 아는 개념과 연결해서 그 목적을 설명하는 고수준 소개가 필요함. 적어도 그 블랙박스의 주 인터페이스를 대략이라도 이해하기 전에는 마법 같은 블랙박스를 다루는 게 편하지 않음. 가령 create-react-app을 처음부터 배운다면, 곧바로 Babel이나 ESLint처럼 그것이 설정한 도구들의 목적을 조사하기 시작했을 것임
  • 그런 식으로 해봤는데, 내가 어떻게 컴퓨터 과학을 그렇게 공부해서 통과했는지 모르겠음. 해법은 재현할 수 있었지만 이해하지는 못했음
    몇 년 뒤 실용적인 좋은 예제를 많이 보고 나서야 개념이 무엇을 말하는지 이해됐음. 그 깨달음 뒤에 학습 방식을 다듬었음
    먼저 핵심 개념을 훑고, 그 개념이 왜 필요한지 이해될 때까지 여러 예제를 시도한 다음, 순진한 예제에서 빠진 경계 사례를 없애기 위해 핵심 개념을 꼼꼼히 읽음
  • 나도 비슷함. Maven이 왜 안 되는지 이해하려고 할 때도 이 문제를 겪었음. “시작하는 법” 튜토리얼이 아니라, 무슨 일이 벌어지는지 이해할 수 있게 기초 원리가 필요했음
    다만 예제에서 시작하는 방식은 좋은 API 설계에 도움이 될 수 있다고 봄. API를 “핵심 개념 우선”으로 설계하면, 결국 핵심 개념을 이해한 뒤에야 사용할 수 있는 API가 되기 쉽고, 가끔만 쓰는 사용자에게는 좋지 않음
  • 잘 정리했음. 특히 “인간은 이런 식으로 배우지 않는다”는 문장에서 의심이 시작됐음
    해커식답게 인용은 없었음. 교육학은 조금만 봤지만, Dewey와 Piaget의 경험심리학에서 현대 원리를 끌어온 거대하고 성숙한 학문 분야임. 블로그 글 하나는커녕 블로그 글의 한 절로 다룰 수 있는 것보다 훨씬 할 말이 많음
    가장 큰 문제는 지적했듯이 사람마다 다르다는 것임. 그다음 큰 문제는 그 차이가 왜 생기는지, 시간이 지나도 얼마나 안정적인지조차 확실히 모른다는 데 있음. 글 자체는 잘 썼고 특정 교육 전략의 실용성을 잘 파고들지만, 조금 더 겸손함이 있었으면 함

• 2주도 안 돼 비슷한 글이 있었음: https://news.ycombinator.com/item?id=41566097
  사람을 위한 글쓰기는 결국 두 가지 기술, 공감과 글쓰기로 압축됨
  코드를 조금 쓰는 것과 애플리케이션이나 제품을 쓰는 것 사이에는 큰 차이가 있음. 이 글도 덜 노골적일 뿐 결국 그 얘기임. 공감이 중요한 이유는 자기중심성과 외부지향성의 차이를 만들기 때문임
  자기중심적인 개발자는 주로 쉬움, 편의, 코드 허영, 기타 주관적 기준에 관심을 둠. 결국 자신의 전달 노력만 따짐. 외부지향적인 개발자는 아키텍처와 문서화에 주로 관심을 둠. 성공이 다른 사람들이 자신의 결과물을 어떻게 받아들이느냐에 달려 있다고 보기 때문임
  단순함은 쉬움보다 중요함. 외부지향적인 개발자는 남의 마음을 읽을 수 없고 무엇을 쉽게 느낄지 알 수 없지만, 단계 수를 줄이고 코드를 작게 유지하는 법은 알기 때문임
  전체 제품 관점에서 애플리케이션을 쓰는 일은 뇌 안에서는 에세이, 글, 책을 쓰는 일과 다르지 않음. 핵심은 조직화와 기능임. 코드는 나중에 오는 것이고, 페이지 위의 단어와 같음. 코드 조각만 쓰는 사람은 모든 것을 하나로 묶는 고차원의 조직화 기술을 개발하지 못함
  그래서 프레임워크를 매우 싫어함. 프레임워크는 개발자가 독창적인 소프트웨어를 쓰는 데 필요한 연습을 빼앗고, 그 결과 조직화 기술을 키우지 못하게 함. 당사자는 볼 수 없지만 볼 수 있는 사람에게는 엄청나게 명확한 큰 격차임

  • 맞는 말이고, 딜레마이기도 함. 프레임워크를 만드는 사람들은 다른 사람들이 제품을 더 쉽게 출시하도록 만들기 위해 그렇게 함. 프레임워크를 만드는 과정에서 그들 자신은 더 나은 개발자가 됨
    하지만 다른 사람들은 이제 그들의 추상화를 배워야 하고, 그만큼 밑바탕 개념에서 멀어짐. 그러면 프레임워크를 넘어서는 데 필요한 핵심 기술을 익히기가 더 어려워질 수 있음. Rails를 배울 때 그런 느낌이었고, 결국 너무 많은 걸 숨긴다는 걸 깨닫고 버린 뒤 처음부터 해보게 됐음
  • 코드 조각을 쓰는 건 꽤 잘하지만, 애플리케이션이 충분히 복잡해지면 문제를 원을 그리듯 다시 쓰는 방식으로 공격하는 경향이 있음. 복잡성이 커지면 때로 재작성 무한 루프에 빠짐
    이것이 완전히 다른 기술이라는 점은 눈이 뜨이는 깨달음임. 말하자면 이제 알려진 미지의 것이 됐음
  • 공감은 좋지만 인지를 이해해야 함. 그렇지 않으면 공감이 엉뚱한 데 쓰임
    상사가 목을 조르는 상황이거나 새벽 2시에 운영 문제를 고치는 사람에게 이 코드가 어떻게 보일까? 그 답이 실제로 필요해지기 전까지는 얼마나 가치 있는지 모름. 그리고 필요해지는 순간에는 그 답에 큰돈을 내게 됨. 그런 걸 할 줄 아는 사람을 찾을 수 있다면 말임. 그런 사람은 드묾

• “인간은 핵심 개념이 아니라 예제에서 배운다”는 말에는 동의하지 않음. 트집일 수도 있지만 모든 인간이 그런 식으로 작동하지는 않음
  일반에서 구체로 가는 방향을 선호하는 사람들은 이미 초중고 교육에서 대체로 무시당하고, 고등교육에 가서야 겨우 잘 맞기 시작할 수 있음. 이미 충분히 소외되어 있으니, 존재 자체까지 부정할 필요는 없음

  • 최근 여자친구와 그 아버지와 여행하면서 수동변속기 운전을 배웠음. 여자친구는 클러치를 언제 밟고 언제 떼는지 행동만 알려줬고, 전혀 도움이 되지 않았음
    언제 무엇을 해야 하는지의 뉘앙스, 무엇은 완전히 동시에 해야 하고 무엇은 바로 뒤따라 해야 하는지 이해되지 않았음. 그때 여자친구 아버지가 클러치가 실제로 무엇을 하는지, 바퀴와 엔진의 연결이 양쪽에 어떤 영향을 주는지 짧게 설명해줬음
    그 순간 바로 이해했고, 특정 상황에서 무엇을 해야 하는지 지시를 들을 필요도 없었음. 20분쯤 뒤에는 수동변속기에서 가장 어렵다는, 뒤로 기운 경사로에서 핸드브레이크로 출발해 차를 몰 수 있었음. 어떤 사람들에게는 제1원리에서 작동 방식을 이해하는 게 훨씬 유용하고, 소프트웨어 엔지니어 중에는 그런 “어떤 사람들”이 꽤 많다고 봄
  • 나는 둘 다 필요함. 나에게 진짜 학습은 핵심 개념을 배우는 것이지만, 예제는 그 이해를 검증할 수 있는 정답이 알려진 사례임
    예제에서 놀라운 부분이 있으면 내 모델이 아직 완전하지 않다는 뜻임. 아니면 예제가 틀렸거나
  • 평균적인 기술자보다 내가 둔한 건지도 모르지만, 둘 다 필요함. 지금 일의 많은 부분이 답답한 이유는 큰 회사라서 새 작업을 만날 때마다 이전 사람이 어떻게 했는지 예제만 주어지기 때문임
    “우리가 달성하려는 것은 이것이고, 이건 이렇게 동작하며, 우리는 이렇게 한다”가 아니라, 실무자에게 노출되는 건 언제나 “우리는 이렇게 한다”뿐임. 아주 조금만 달라져도 추론하고 조정하고 문제를 해결할 수 없게 됨
    자주 수행되는 작업에는 어느 정도 문서가 있긴 하지만, 대개 낡았거나 불완전함. 위키가 아니라서 아무나 언제든 고칠 수도 없고, 문서를 고치려면 짜증 나는 절차를 거쳐야 하니 결국 업데이트되지 않음. 생각해보니 군대에 있던 시절과 꽤 비슷함
  • 나도 동의함. 내 학습 방식은 비유적으로 말해 참조 설명서를 처음부터 끝까지 읽는 것임. 새로운 걸 배우려 할 때 추천되는 입문 자료 대부분이 내가 찾던 것과 정반대였던 경우가 많았음
    지금도 Drizzle ORM을 배우려고 시간을 내면서 그런 일을 겪고 있음. 처음 찾은 자료들은 전부 “쿼리 예제 여섯 개”였고, 왜 그 문법을 쓰는지, 다른 선택지는 무엇인지 답답해졌음. 그런 자료는 닫고, 문서의 모든 페이지를 읽은 뒤 뭔가를 하는 내 방식이 훨씬 편함
  • 학교에서는 머릿속에서 이론 구성을 연습하기 시작한 뒤에야 잘 풀리기 시작했음. 가설을 세우고, 시험하고, 다듬는 방식임
    지금도 실시간으로 할 수 있을지는 모르겠음. 이 방식은 꽤 많은 사고 주기를 쓰기 때문에, 지금은 글을 읽거나 영상을 멈추고 처리하는 속도가 더 맞음
    아직 이해하지 못하는 사람들을 종종 즉석에서 가르치게 됐음. 시스템에 대한 이론이 있으면, 단순 암기를 겨우 넘긴 급우는 답하지 못할 질문에도 답할 수 있음

• Code Complete의 문장임: “프로그래밍 작업의 작은 부분은 컴퓨터가 읽을 수 있도록 프로그램을 쓰는 것이고, 더 큰 부분은 다른 인간이 읽을 수 있도록 쓰는 것이다.” 733쪽
  거의 20년 동안 기억에 남아 있음

  • “프로그램은 인간이 읽도록 만들어진 것이며, 컴퓨터가 실행하는 것은 부수적인 일일 뿐이다.”
    Abelson과 Sussman의 Structure and Interpretation of Computer Programs 초판 서문에 나오는 말이고, Code Complete보다 10년 앞섬
    내가 지키려는 격언이지만, 고용주들은 이상하게도 컴퓨터가 실행하는 부분을 늘 고집하는 듯함
  • Abelson, SICP 저자 중 한 명도 비슷하게 말했음. 코드는 인간이 이해하도록 쓰여야 하고, 컴퓨터가 이해하는 것은 맨 마지막이어야 한다는 취지임

• 약간 곁가지이긴 한데, 며칠 전 Unity 게임을 만들다가 IDE가 지난 10~20년 동안 정말 별로 발전하지 않았나 하는 생각이 들었음
  기본 IntelliSense는 확실히 많이 좋아졌지만, 그 외 몇 가지 사소한 점을 빼면 코딩이라는 개념 전체는 예전과 거의 같아 보임
  가장 큰 긍정적 변화는 편집기 밖에 있음. 라이브러리와 문서에 훨씬 쉽게 접근할 수 있고, 사용자 질문과 답변이 엄청나게 많아졌으며, 가끔 그 답들을 모아 그럴듯한 답을 주는 ChatGPT 같은 새 도구도 생김
  하지만 전반적으로 코드 작성 행위는 정체된 것 같음. 그래서 지금은 게임 작업을 잠시 멈추고 몇 가지 실험을 하고 있음. 새 언어를 만들고 싶지는 않고, 가능한 모든 잡일을 컴퓨터에 넘겨 창작에 집중하고 싶음
  처음 테스트하고 싶은 것 세 가지는 이렇다. 괄호나 종료자 같은 작은 언어 세부사항을 왜 내가 신경 써야 하는지, 도구가 자동완성할 수 있지 않은지. private-public 접근 체인이나 unsafe 같은 변경자도 도구가 가장 효율적인 집합을 자동 판단할 수 있지 않은지. 서로 상호작용하는 메서드 5개쯤에 집중할 때, 여러 창을 열고 VS의 가로/세로 슬라이더와 싸우지 않고도 모두 한 화면에서 보고 싶음. HashSet을 만들었다가 Dictionary나 Tuple로 바꿔야 한다면 그냥 바꿔주고, 판단이 필요한 곳만 보여줘서 승인하거나 직접 고치게 했으면 함. Unity에서는 메서드나 데이터 집합을 클릭해 Burst Job과 그에 딸린 NativeData 집합으로 변환하라고 지시할 수도 있으면 함

  • 코딩의 개념 전체가 예전과 거의 같다는 건, 프로그래밍 언어의 개념 전체가 그다지 바뀌지 않았기 때문임. 튜링 기계와 람다 계산이라는 두 큰 기둥이 있고, 그 뒤는 추상화들임. 추상화가 좋으면 패러다임이라고 부름
    하지만 결국 전부 추상화이고, 우리는 아주 멍청한 기계가 데이터를 계산하도록 명령을 쓰고 있을 뿐임
    괄호나 종료자를 도구가 자동완성하면 되지 않느냐고 했지만, 컴퓨터는 정말 단순한 것이고 프로그래밍 언어는 마음속 생각을 전달하는 통로임. 그런 구분자는 언어 키워드만큼 중요함. 규칙의 일부이기 때문임. 그것들을 자동완성하려면 더 많은 규칙과 더 많은 구분자가 필요함
    상호작용하는 메서드 여러 개를 한 화면에 보고 싶다면 Vim과 Emacs, 또는 Pharo 같은 Smalltalk IDE가 있음
    데이터 변환은 Vim과 Emacs 매크로로 할 수 있음. 하지만 진실은 데이터 인코딩이 매우 중요하다는 것임. 컴퓨터에게는 전부 비트이고, 우리가 그 비트에 의미를 부여하고 그 의미에 따라 조작하는 규칙을 만든 것임. 한 규칙 집합에서 다른 규칙 집합으로 형태를 바꾸려면 더 많은 규칙이 필요함
    라이브 프로그래밍 환경을 시도해보길 권함. Common Lisp의 SLIME, Smalltalk의 Pharo, JavaScript의 웹 검사기 같은 것들임. 육지에 배를 놓고 항해가 어떤 느낌일지 상상하는 대신, 바다 한가운데 있는 배에서 작업하는 느낌임
  • 텍스트 편집기 경험이 크게 좋아지지 않은 이유는 그것이 병목인 경우가 많지 않기 때문이라고 봄
    프로그래밍에서 가장 어려운 부분은 생각과 학습임. 더 빨리 타이핑한다고 큰 도움이 되지는 않음
  • 자동완성에 대해서는 동의함. 이미 적어도 35년 전 MS-DOS용 편집기 Brief도 임의 템플릿을 정의해 자동완성할 수 있었음
    예를 들어 C 프로그램을 쓸 때 “f”를 “for (=; <=; ++) {;}”나 선호하는 들여쓰기 형태로 확장하게 할 수 있었음
    현대 프로그래밍 편집기 중에도 비슷한 사용자 설정을 지원하는 것이 많지만, 안타깝게도 많은 경우 아주 오래전보다 절차가 더 복잡함
    문법이 장황한 프로그래밍 언어라면, 편집기에서 최소 키 입력으로 어떤 프로그램 구조든 빠르게 쓸 수 있는 템플릿을 시간을 들여 정의하는 게 필요하다고 봄
  • 괄호나 종료자 같은 것은 문법을 명시적으로 만들고 도구 지원을 크게 향상함. 보통 편집기는 이런 걸 넣어주는 기능이 있음. 하지만 어떤 경우에는 나에게는 명백해 보여도 실제로는 여러 유효한 선택지 중 하나라서, 설계 문서 같은 것이 없으면 도구가 마음을 읽을 수 없음
    HashSet, Dictionary, Tuple 중 무엇을 쓸지 같은 문제는 성능 영향이 있고, 추상적으로 어느 것을 써야 하는지 항상 명확하지 않음. Java 같은 명시적 언어, 아마 C#도 마찬가지로, 메서드 호출이 다른 타입을 받도록 리팩터링할 수는 있을 것임. 그러면 메서드 하나를 바꾸고 그 호출들을 모두 리팩터링하면 됨
    Gemini pro와 ChatGPT o1을 실험해봤는데, 둘 다 Python과 JavaScript 코딩을 정말 못함. 버그 있는 코드를 쓰고, 한 버그를 고치려다 다른 버그를 자주 넣음. 둘 다 요구사항을 생각하기보다 답을 서두르는 느낌임. 우리가 원하는 방식으로 “마음을 읽거나” 무엇이 중요하고 중요하지 않은지 이해하는 도구까지는 아직 좀 멀었다고 봄
    더 나쁠 수도 있는 점은 학습 데이터임. 대부분의 코드는 평균 이하와 평균 수준의 코더가 만들기 때문에, 이런 도구는 평균적인 코더의 사고 패턴을 채택하게 됨. 최고 품질 코드만으로 학습시켜도, 대부분의 코더가 올바르게 프롬프트를 줄 수 있을지는 명확하지 않음. 그래서 10~20년 코딩해왔다면, 즉석 마법을 기대하는 한 도구에 늘 조금 실망할 가능성이 꽤 큼
    그래도 비AI 정적 분석 도구는 오래전부터 훌륭했고 더 좋아질 것임. 거기에 AI를 더하면 더 향상될 수 있음. 도구를 명세를 던져 괜찮은 결과를 돌려받는 예술가가 아니라, 내가 예술가가 되도록 돕는 것으로 생각하면 훌륭한 경험을 할 수 있다고 봄
    편집기가 더 해줬으면 하는 일을 AI에게 말하고, 설정을 도와달라고 하는 실험도 재미있을 수 있음. 플러그인에는 비AI 도구가 많음. 생활 방식에 맞는 플러그인을 고르는 데 대규모 언어 모델을 쓰는 것이 가장 효율이 좋을 수 있음
  • 여러 파일의 일부를 편집하면서 상호작용하는 메서드 5개 정도를 한 화면에 보고 싶다는 부분에는 haystack이 흥미로울 수 있음
    https://haystackeditor.com/
    직접 써보지는 않았지만 써볼 생각임

• 글 제목은 논쟁의 여지가 있음. 코드는 오직 인간을 위해 쓰이기 때문임. 컴퓨터는 “코드”가 필요 없고, 특히 고수준 코드는 더더욱 필요 없음. 컴퓨터는 기계어 명령만으로도 충분함
  우리가 코드를 쓰는 이유는 기계어 명령이 사람이 쓰기에는 너무 어렵고, 읽기는 더 어렵기 때문임
  코드를 컴퓨터와 상호작용하는 방식으로 생각해서는 안 됨. 코드는 인간이 생각을 형식화해서, 기계조차 따라 할 수 있을 만큼 모호하지 않게 만드는 방식임

• 지난주에 쓰고 공유한 블로그 글을 이타적으로 홍보함
  Move Fast & Document Things [1]
  철학적인 글을 쓰려던 게 아니라, 우리 작은 팀 [2]이 어떻게 자동화나 AI가 아니라 깊고 어려운 검토를 통해 우리 자신과 서로를 위한 코드 작성 문화를 강제하는지 실제 팁을 공유하려 했음
  다른 조직에서 엔지니어링 리더를 하는 개인적인 친구들은 모두 “우리도 똑같이 하지만, 너는 그걸 실제로 글로 썼다”고 했음. 가치가 있었다면 추천을 부탁함
  [1] https://olshansky.substack.com/p/move-fast-and-document-thin...
  [2] https://github.com/pokt-network/poktroll/graphs/contributors

• “너무 많은 프로그래밍 책과 튜토리얼은 ‘처음부터 벽돌 하나씩 집을 지어보자’는 식인데, 내가 원하는 건 ‘여기 작동하는 집이 있으니, 무언가를 바꿔보고 무슨 일이 생기는지 보자’임”
  나는 그런 방식으로 프로그래밍을 독학했음. 작고 단순하고 좀 별로인 프로그램을 잘 쓰는 데 몇 년을 보냈음
  나중에 더 나은 소프트웨어 개발 일자리에 적합하지 않다는 걸 알게 됨. 소프트웨어 설계, 프로그래밍 언어, 컴퓨터에 대한 기초 지식이 전혀 없었기 때문임. 지루한 방식으로 배우지 않았기 때문에 얼마나 모르는 게 많은지 면접장을 나오며 깨달은 건 겸손해지는 경험이었음
  항상 전체 설명서를 읽고, 항상 기초를 배워야 함

• 내 코드는 전부 인간을 위해 씀
  그 인간이 나이든, 몇 년 뒤 내 의도를 파악해야 할 불쌍한 누군가이든 마찬가지임
  코드를 쓰는 것 자체는 어렵지 않다고 봄. 문제를 포괄적으로 추론하고, 다른 이해관계자들과 협업해 최선의 길을 발견하고 그들을 이끌며, 새로운 수학이나 업계 관습 같은 전문 기술을 배우고, 효율적인 알고리즘을 고안하고, 프로그램의 구조와 패턴이 명확하고 우아한 경계를 갖도록 전달하는 부분이 재능을 보여줌
  결국 많은 부분은 소통과 명확성에 달려 있음

• 이 글의 큰 부분은 문서화에 관한 것이고, 4doc 모델을 참조했으면 큰 도움이 됐을 것임: https://docs.divio.com/documentation-system/
  기본적으로 참조 문서만 제공하지 말고 사용법 문서도 제공하라는 말임. 그리고 사용자가 일반적으로 전체 문서 중 먼저 보고 싶어 하는 부분이므로 그것을 앞세우라는 뜻임
  물론 일반적으로 그렇다는 것이고, 나는 참조 자료로 바로 가는 편이지만 항상 그런 것은 아님
  4doc이 만능 해결책이나 자연법칙이라는 뜻은 아님. Hillel Wayne도 여기서 그 문제점을 잘 다룸: https://www.hillelwayne.com/post/problems-with-the-4doc-mode...