▲

장난감 소프트웨어를 만드는 즐거움

 (blog.jsbarretto.com)
39P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • Toy 소프트웨어 제작은 소프트웨어 개발의 본질적인 즐거움과 창의성을 회복하는 방법임
  • AI와 산업화로 소프트웨어 개발의 순수한 기쁨이 사라지는 시대에, 개인 프로젝트로 간단한 장난감 프로그램을 만들면 실무에서 유용한 지식과 깊은 이해를 얻는 계기가 됨
  • 장난감 소프트웨어는 80:20 법칙에 따라 최소 코드로 최대 기능을 구현하며, 과도한 설계나 완성도 집착을 피하는 것이 핵심임
  • LLM 등 AI 도구에 의존하지 않고 스스로 부딪히며 만드는 경험 자체가 학습과 성장의 본질적인 기쁨

왜 장난감 프로그램을 더 많이 만들어야 하는가

  • Richard Feynman의 명언 “내가 만들지 못하는 것은 내가 이해하지 못하는 것이다 → 직접 무언가를 만드는 경험이 깊은 이해로 이어짐
  • 기존에 ‘바퀴를 재발명하지 말라’는 조언과 달리, 바퀴를 직접 만들어보는 경험이 독서나 이론적 학습보다 더 많은 것을 가르쳐 줌
  • 최근 AI와 소프트웨어 산업화가 개발의 즐거움과 장인정신을 위협하고 있음
  • 장난감 소프트웨어 제작이 다시 컴퓨터에 빠져들게 하는 간단한 즐거움을 회복시켜줌

장난감 프로그램의 원칙: Keep it simple

  • 장난감 소프트웨어는 80:20 원칙을 따름: 20%의 노력으로 80%의 기능 달성
  • 목표는 최종 제품이 아닌, 간단함과 주요 원리를 직접 구현하는 데 있음
  • 과한 구조설계(over-engineering)를 경계하고, 꼭 필요한 코드만 작성하는 방식 강조
  • 모든 코드 경로를 아직 구현하지 않은 상태로 두고, 필요할 때마다 구현을 늘려 나가는 식의 접근 권장
  • 작아 보이는 시스템도 실제로 해보면 의외로 쉽게 만들 수 있음을 경험하게 됨

장난감 소프트웨어의 부가적 이점

  • 장난감 프로젝트에서 얻은 지식이 실제 업무에서 문제 추적, 버그 해결, 실수 예방에 기대 이상으로 도움이 되는 경우가 많음
  • 직접 부딪혀 가며 제약 조건을 경험하는 것이 소프트웨어 본질에 대한 통찰을 주며, 혁신적 해결 방안도 발견할 수 있음

예시: 다양한 장난감 소프트웨어 프로젝트 리스트

지난 15년간 직접 구현해본 장난감 프로젝트 종류들을 난이도와 예상 소요 시간으로 정리함. 각 프로젝트에 간단한 설명과 추가 참고 자료가 포함

  • Regex 엔진 (난이도 4/10, 5일) : POSIX 스타일 정규식 해석 및 일치하는 문자열 식별, 정규식의 내부 작동을 깊이 이해하게 됨
  • x86 OS 커널 (난이도 7/10, 2개월) : CLI와 간단한 드라이버, 메모리 매니저 등 포함, 인메모리 파일시스템, ELF 실행파일, GUI, 프로세스 격리 등 추가 도전 가능
  • GameBoy/NES 에뮬레이터 (난이도 6/10, 3주) : 간단한 명령어 집합과 하드웨어에 대한 이해, PPU와 PSG, 특이 카트리지 포맷 구현
  • GameBoy Advance 게임 (난이도 3/10, 2주) : 스프라이트 기반 간단 게임, GBA 개발 커뮤니티 활발, 혼자서 충분히 파악 가능한 시스템 구조
  • 2D 물리 엔진 (난이도 5/10, 1주) : 기본 뉴턴 역학과 간단한 충돌 처리, 복잡한 도형·관성·해결 알고리듬, 소프트 바디/복합 상호작용 등으로 확장 가능
  • 동적 인터프리터 (난이도 4/10, 1~2주) : 트리 워킹 인터프리터, 자신만의 언어 제작이 기술적·창의적 기쁨을 줌
  • C계열 컴파일러 (난이도 8/10, 3개월) : 단순 타입 시스템 및 타겟 환경, 각종 최적화 및 다양한 백엔드 지원 아키텍처 설계
  • 텍스트 에디터 (난이도 5/10, 2~4주) : 간단한 파일 입출력부터 시작, UI 툴킷(QT/GTK 등) 이용 가능, 콘솔 기반 선호, unicode, syntax 하이라이트, 멀티 버퍼, LSP 등 추가 기능
  • Async 런타임 (난이도 6/10, 1주) : Rust의 경우 impl Future 태스크 처리 및 동시성 구현, I/O 웨이킹 추가
  • Hash Map (난이도 4/10, 3~5일) : 내부 작동 원리, 클로즈 및 오픈 어드레싱, 로빈 후드 규칙 학습, 성능 및 적합한 사용 시점 이해
  • Rasteriser / Texture Mapper (난이도 6/10, 2주) : 3D 그래픽 파이프라인 구조 학습, 벡터 수학, Z버퍼, 텍스처 매핑 및 섀딩 알고리듬까지 심화 가능
  • Signed Distance Field 렌더링 (난이도 5/10, 3일) : 수학적 공간 표현, 간단한 비주얼라이제이션, 셰이더와 벡터 수학에 대한 이해
  • Voxel 엔진 (난이도 5/10, 2주) : 3D 그래픽 또는 게임 개발 경험 있으면 이해 쉬움, 텍스처, 프로시저 생성, 네트워크 등 추가 도전 가능
  • Threaded Virtual Machine (난이도 6/10, 1주) : 빠른 해석기, 아키텍처별 코드생성 없이 최적화된 인터프리터 구현, 컴파일러와 맞먹는 성능 경험 가능
  • GUI 툴킷 (난이도 6/10, 2~3주) : 기본 UI 도구작성 경험 후, 레이아웃 엔진, 텍스트 셰이핑, 접근성 등 심화 기능 직접 구현 가능
  • 궤도 역학 시뮬레이터 (난이도 6/10, 1주) : 뉴턴 중력 모델 간단히 구현, 여러 천체의 상호작용, 적분 알고리듬과 시각화로 확장 가능, NASA 데이터 적용 등 가능
  • Bitwise Challenge (난이도 3/10, 2~3일) : 64비트 상태만으로 재현되는 게임, 창의적 상태관리 훈련, GitHub에서 자세한 규칙 확인 가능
  • ECS 프레임워크 (난이도 4/10, 1~2주) : Entity-Component-System 구조 직접 구현, 언어 타입 시스템 통합, 고성능 및 제약 맞춤
  • CHIP-8 에뮬레이터 (난이도 3/10, 3~6일) : 1970년대의 단순 가상머신, 빠른 구현, 다양한 팬 게임 관찰·실행 가능
  • 체스 엔진 (난이도 5/10, 2~5일) : 규칙부터 시작해 점차 발전, 직접 만든 엔진에 패배하는 경험은 개발자 성장의 한 장면
  • POSIX Shell (난이도 4/10, 3~5일) : POSIX 기반 셸의 원리 및 한계, 실제 Shell 언어 호환성 구현을 통한 깊은 이해 및 수많은 트릭 체험

LLM 등 도구 사용에 대한 조언

  • LLM 등 첨단 도구도 유용하지만, 진정한 배움은 스스로 직접 탐구할 때 더 깊어짐
  • 기존 솔루션을 보기보다는, 미지의 영역을 탐구하며 나만의 해답을 찾는 과정에서 더 깊은 성취감을 얻을 수 있음
  • 장난감 프로젝트를 LLM 없이 진행할 때 초반에는 익숙하지 않아 힘들 수도 있으나, 시간이 지날수록 고유의 기술적 기쁨과 높은 성취감을 느끼게 됨
  • 자동차로 이동하면 주자(달리기)로서의 ‘러너스 하이’는 느낄 수 없음 → 지름길이 아닌 직접 경험에서 깊은 즐거움을 얻을수 잇음
▲
nezz1204 5시간전  [-]

토이프로젝트를 말하는거였군요. 제목만 보고 장난감에 들어가는 소프트웨어를 만드는거라고 생각했네요. ㅎㅎ

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • LLM을 검색 엔진처럼 사용하는 사람인지 궁금함. 예전엔 Google에 “pros cons mysql mongodb”처럼 검색하고 공식 문서, 포럼, 블로그, stackoverflow까지 찾아읽으며 시간 소요가 컸음. 하지만 읽으면서 배우는 시간 자체는 언제나 환영. 지금은 LLM에 좀 더 구체적으로 “사진 저장할 때 mysql vs mongodb 장단점, 참고 링크 제공” 식으로 프롬프트를 넣음. 빠르게 핵심을 파악할 수 있고, 링크도 같이 있어서 환각에 의존하지 않아도 되는 점이 좋음. 가끔 “postgres로 사진 메타데이터 저장하는 data schema 짜줘, X를 다른 테이블에 분리하고 싶음” 등 구체적 요청도 하지만, 이건 내가 어떤 결과물이 나와야 할지 정확히 알 때만 사용함. 그저 타이핑 시간이 아까울 때나 타입 구체적 명칭(int와 integer 등)을 잠깐 잊었을 때 쓰는 것임

    • LLM을 기술 질의 엔진으로 쓰면, 언뜻 보기에는 그럴싸하지만 중요한 부분에서 틀린 정보를 줄 때가 많음. 곧이곧대로 믿고 답을 따라가면 쓸데없이 수 시간, 며칠을 허비할 수도 있음. 참고 링크를 요구해도 실제 정보가 있는 경우와 관련 없는 내용을 주는 경우가 반반임. 그래도 한 가지 확실하게 잘 하는 것은 "tip-of-my-tongue" 식 역검색임. 즉, 개념을 설명하면 그에 해당하는 검색어를 추천해주는 역할에는 일관성 있고 만족스러움
    • 머지않아 기업들이 많은 돈을 LLM에게 지불해서 자기 제품이 더 좋은 비교로 노출되게 만들 것 같음. LLM은 결과가 '유기적으로' 보이게끔 프레이밍, 강조만 달리할 수 있음. 진실과 근거가 있는 정보만 노출하고 '문맥의 강조'만 할 수 있기 때문임
    • 나도 똑같이 LLM을 검색용으로 쓰고 있음. 느낌이 과거 2010년대 초반 구글링이 막강했던 때로 되돌아간 것 같음. 뭐든 다 찾을 수 있던 시절. 물론 이 시기는 오래가지 못했고, 지금 구글링은 고통과 좌절 그 자체임. 구글과 마케터들이 만든 변화에 대해 불만도 많지만, 현재 LLM들은 순간적으로 온라인 정보 표면화에 매우 효율적이라는 느낌임. 참고 링크들도 대체로 꽤 정확. 결국 예전과 같은 변화의 힘이 작용할 테고, 다시 사라지기 전까지 잠깐의 기회라는 생각
    • 나도 LLM을 검색 엔진처럼 쓰는 사람 중 한 명임. 아직 AI IDE는 사용하지 않음. 최근 라이브 기술 면접에서 내가 선택한 LLM으로 구글링 하듯 질의를 하면서 답하려 했는데, 면접관이 이렇게 AI를 쓰는 지원자를 처음 봤다고 했음. 대부분 개발자들이 아직 AI IDE보다는 검색용으로 먼저 쓰는 줄 알았음. 혹시 우리 같은 사례가 드문가?
    • 심지어 개발에도 LLM을 검색 엔진처럼 사용. “/src/foo에 내가 클론한 레포를 분석해 barFeature가 어떻게 구현되었는지 설명해줘. 이제 /src/baz 프로젝트 봐서 foo 접근법이 baz에 적용하기 어려운 이유를 설명해줘” 식으로 활용. 새로운 걸 시키지는 않고, 기존 프로젝트에서 내 아이디어로 번역해서 활용. 진짜 새롭고 도전적인 개발은 내가 직접 코딩해야 즐거움이 있음

  • 커리어적으로 가장 잘한 일 중 하나는 직장 사이 6개월 쉬면서 진행한 개인 프로젝트임. 원래 시작할 프로젝트가 많았지만 제한이 없다 보니 범위가 계속 커지면서 결국 완성하지 못하는 경우가 많았음. 그래서 각 프로젝트마다 1주일만 투자하기로 결정. 1주일 안에 할 수 있는 만큼만 만들었음. 제로에서 시작해서 새로운 언어나 프레임워크, 혹은 생소한 분야에서 1주일 만에 쓸 만한 뭔가를 만든 경험은 자신감이 엄청나게 쌓이는 계기였음. 원래 프로그래밍을 좋아했던 이유도 다시 상기할 수 있었음. 만약 직장 사이에 몇 달쯤 휴식 시간이 생긴다면, 실리콘밸리 면접 준비 대신 그냥 토이 프로젝트를 만드는 것이 얼마나 많은 걸 이미 알고 있었는지 스스로 놀라게 됨

    • AI 생성 도구가 있다면 이런 개인 토이 프로젝트를 진행할 때 엄청난 도움이 됨. 나는 백엔드를 주로 하지만 프런트도 할 수는 있음. 다만 CSS에 시간이 너무 많이 걸려서 예전에는 개인 프로젝트를 끝까지 못한 경우가 많았음. 지금은 AI에게 “이쁘게 만들어줘”라고 시키면 85%까지 완성된 단계로 만들어주고 나머지 버그 수정이나 수정 작업만 하면 되므로 빠르게 마무리할 수 있음. 예전엔 진흙탕 같았던 개발이 지금은 이렇게 수월해진 덕분에 개인 프로젝트를 더 자주 만들게 됨
    • 최근엔 사용 중인 라이브러리에 불만이 쌓여 직접 고치는 쪽으로 옮겨감. 불완전한 온보딩 문서, 깨진 SDLC, 심각한 성능 문제 등을 발견하면 종일 수정작업을 함. 다른 사람이 기다리고 있는 협업 프로젝트와 달리, 개인 토이 프로젝트는 사이드퀘스트(잡일)에 빠지기 쉬움. 협업은 누군가가 기다리는 압박이 있음
    • 어떻게 6개월이나 쉬고 다음 직장을 구하게 되었는지 궁금함. 나도 6개월 쉬고 싶기는 한데, 혹시 일자리를 못 구해 더 오래 쉬게 될까봐 불안함
    • 어릴 적에는 classic ASP + SQL로 서버 세팅하고 HTML/CSS/JS 다 다루면서 쉽게 배포했었음. 그땐 FTP로 파일만 올리면 됐음. 지금은 더 현대적인 방법을 연구해보고 싶지만, 개인 프로젝트하다 보면 매번 배포와 개발 프로세스(라이프사이클) 고민에서 헤매는 경우가 많음. 토이 프로젝트 호스팅, 배포 방식에 대해 어떻게 선택하는지 궁금함
    • 나도 AI가 보일러플레이트 부분이나 테스트 자동화 코드 등을 생성해주는 덕에 이런 개인 프로젝트 진행 속도가 확실히 빨라짐

  • 토이 소프트웨어 개발은 자전거나 자동차, 보트 정비랑 비슷함. 즐거움. 하지만 출근용 자전거를 고치는 건 스트레스. 토이 소프트웨어 만드는 건 즐거운데, 언젠가 내가 진짜 사용하려고 하면 버그를 다 발견하게 되고 고칠 시간은 없다는 딜레마가 생김

    • 나 스스로 쓸 용도의 소프트웨어만 개발하는 걸 더 좋아함. 자동차도 더 저렴하게 오래 타는 게 만족감임
    • 한때 이메일 서버를 직접 운영했는데, 지금은 안 함. 이건 내가 직접 하고 싶었기 때문이 아니라, 이 일은 전문가에게 맡기고 싶어짐
    • 최근에 직접 인보이스 애플리케이션을 만듦. 필요한 기능을 하나하나 추가하는 게 즐거웠음. 기존 유료 서비스에서 월정액 내고 써야 하는 기능들까지 다 포함시켰지만, 실제로 송장을 발송해야 하는 순간, 내가 만든 앱에서 해결해야 할 이슈(스타일, 주소 입력 등)가 너무 많다는 걸 깨달음. 결국 자전거 타는 재미와 출퇴근용 자전거의 실용성 사이에 균형을 찾아야 할 필요성을 느낌. 시간이 지나면 재미와 실용성이 점점 가까워질 수도 있다는 깨달음
    • 나도 “완성된 소프트웨어”로 만들고 싶은 게 너무 많지만, 시간과 에너지가 없음. 지루하고 반복적인 작업도 매우 많음. 그래도 “AI 결과물”을 관리하고 선별하는 것도 꽤 일임. 아직 초반 실험 단계라 몇 달 후에도 이 의견을 유지할지는 모르겠음
    • 이런 이유 때문에 개인 홈페이지 만드는 게 정말 즐거움. 실제로 내 놀이터처럼 쓸 수 있음

  • LLM에 대해 부정적인 의견이 많은 게 의외임. LLM은 정보를 숟가락으로 떠먹여줌. 새로운 프로젝트를 시작할 때는 당연히 모든 걸 다 알고 시작하는 게 아님. 최선을 다했다가 망하고, 그 다음에 공부하고, 왜 안 됐는지 이해, 새로운 방법으로 조정하는 게 진짜 배움임. 다 안다고 그냥 튜토리얼 따라 하면 방법별 한계나 진짜 장단점을 체험할 수 없음. 예를 들어 정규표현식으로 파서 만드려고 시도했다가 재귀 표현식 못 다루는 걸 스스로 발견하고, 더 복잡한 구조나 시간복잡도 이슈 등도 손에 쥐고 배워야 함. 직접 최적화 컴파일러를 구현하며 온갖 최적화 트릭에서 좌절하다가 실제 컴파일러가 왜 그렇게 설계됐는지 이해하게 됨. 직접 레이아웃 엔진을 짜야 "width" 개념조차 제대로 다뤄야 하는 고충도 체험 가능. 시행착오를 통해 배우는 것 이상 좋은 경험은 없음. LLM이 실수를 막는다고 해서, 중요한 학습 기회까지 놓치지 않았으면 함

    • 많은 사람들이 LLM을 안 쓰면 뒤처진다고 하지만, 오히려 LLM을 적게 쓰는 게 장기적으로 큰 이점이 될 것 같다는 생각

  • 나도 컴퓨터 그래픽스를 배우기 위해 몇 년간 주말과 밤새 이상한 프로젝트들을 셀 수 없이 진행. 한 푼도 벌지는 못했지만 그 덕분에 꿈의 직업을 얻음. 대표적인 작업물 링크:

  • 이 글이 제시한 “프로그래밍의 즐거움”이라는 정신이 진짜 필요하다고 느낌. AI 에이전트 코딩 시대에 오히려 더 소중. 하지만 저자가 제시한 토이 프로젝트 예상 소요 시간이 너무 짧다고 느낌. 나는 평균 속도도 아니지만, 오히려 해당 리스트 대부분은 2~3시간씩만 일한다고 가정하면 며칠로 끝날 프로젝트가 아니라고 생각. 시작 전에 리서치에만 꽤 걸린다는 느낌. 예시로, 최근 내 Pelican 블로그를 개인 Odin static site generator로 대체했는데, 하루 2~3시간만 투자해도 2주 걸렸음. 저 리스트의 다른 프로젝트들보다 더 쉬운 편이었는데도 그 정도 소요임

    • 네 프로젝트는 “토이” 프로젝트 이상임. 스스로가 진짜 고객이 되어, 배포된 뒤에도 제대로 작동하길 기대함. 그 기대가 토이와 진짜 툴을 나누는 경계임. 한 시간 만에 워드프로세서도 만들 수는 있음. 입력 하나하나만 처리, 미친듯이 단순, 종료 버튼도 없는 버전일지도. 하지만 그것도 “토이” 워드프로세서로는 충분함
    • 만약 “X일”이라는 소요 시간을 24*X시간으로 해석하면 이 리스트가 그럴 듯해짐
    • 토이 프로젝트의 장점 중 하나는 데드라인이 없다는 점임. 그래서 충분히 느긋하게, 천천히 진행하는 게 가능. 나도 PEG 기반의 튜링 완전 언어를 코로나 시절부터 아직도 다듬고 있음
    • 이런 시간 단축에는 어디까지 3rd-party 라이브러리를 쓰고 무엇을 직접 해결했는지, 실제로 얼마나 가장 핵심에만 집중했는지에 따라 큰 차이가 남. 저자의 깃허브(https://github.com/ssloy?tab=repositories)를 보면 규모를 작게 유지하는 팁을 많이 배울 수 있음. 그리고 저자는 문제 영역에 대한 이해도가 원래 깊어서 저 정도로 “타이트”하게 코딩 가능. 새로운 주제라면 이런 식으로 구현하기 어려움

  • “LLM을 이런 프로젝트에 쓰지 마라”는 조언에 나도 동의는 하지만, 너무 극단적으로 받아들이지 말자는 입장임. AI의 도움을 어떻게 받아야 할지에 대한 조언이, 왜 사람에게 도움을 구하는 것과 다르게 느껴지는지도 흥미로운 지점임. 블로그 맨 아래에 “프로그래밍 잘하는 친구가 있다면 절대 도움을 요청하지 마세요”라고 쓴다면 이상할 것임. 전문가 친구는 맥락을 이해하고, 나 스스로 풀도록 도와줌. AI도 정말로 “문제 푸는 걸 대신 해줄 게 아니라, 전문가 친구처럼 지도해달라”고 요청해본 사람 거의 없을 거임. 물론 아직은 못하거나 미흡할 수 있지만, 1~2년 후에는 이런 식 가이드가 아주 자연스러워질 수도 있음. 그러니까 “내가 어떤 도움방식을 원하는지 명확하게 전달”하는 습관을 들이면 좋겠음. 무조건 LLM이 잘못된 정답만 줄 거라는 고정관념을 가질 필요는 없음

    • AI는 아직 전문가 개발자가 아니라고 명확히 느끼고 있음
    • LLM을 전문가 친구처럼 사용하는 게 내가 가장 많이 쓰는 방식임. 믿음직스럽게 만들려면 프롬프트나 질문 자체를 편파적이지 않게 바꿔서 물어야 함. 최근엔 Claude나 ChatGPT가 너무 내 생각에 동조하는 경향이 짙어진 것 같음
    • (글쓴이) 사실 나도 진짜로는 “전문가 친구에게도 도움을 요청하지 말라”고 추천. 정말 막혔을 때만 주제 관련 간단한 문헌 읽어보는 게 낫다는 쪽. 정말 여러 방법을 스스로 시도해보고 좌충우돌하며 풀어나가는 경험이 창의력, 문제해결력을 키우는 데 필수 요소라고 강하게 믿음. 혼란스러운 시간이 꼭 필요함. 단, 누구든 스스로 결정할 문제임
    • 실제로 LLM을 “선생님”처럼 대하듯 물어봄. 인턴처럼 답해달라는 식의 질의는 안 함

  • Claude 기반 vibe coding 덕에 정말 오랜만에 재미있는 사이드 프로젝트를 시작하게 됨. 툴과 프로세스를 익히고 나니 몇 주 만에 가족용 캘린더/날씨 대시보드, Bluesky 읽기앱(이미 본 글 숨김), 게임화된 회사 PM 대시보드, 일정 시간 뒤 Reddit 글 숨겨주는 Chrome 확장, 유지보수 안 되는 WordPress 플러그인 대체 앱 등 다양한 앱을 빠르게 만들고 있음. 초기엔 Claude에게 UI 개선 등 많은 걸 맡겼지만, 이제는 90% 완성도에도 만족하면서 고도화 대신 새로운 앱 기능에 집중하는 법을 터득함

    • Claude가 버그를 수정해 놓고 결과물을 바로 보여주지 않는 경우가 있어서 곤혹스러움. 한 가지 수정에 업데이트된 결과 출력을 6번이나 재요구해야 했던 적도 있음. 비슷한 경험이 있는지 궁금함

  • 이 리스트는 정말 인상적임. 저자에게 쉽다고 느껴진 프로젝트 상당수가 내겐 확 높은 난이도일 듯. 하지만 실제로 내 토이 프로젝트를 다시 시작하고 싶게 만드는 동기부여 효과는 확실함. 단, LLM 학습에 대한 결론은 좀 더 미묘함. 어떤 식으로 쓰냐에 따라 완전히 다름. 예를 들어 “이 문제를 그냥 구현해줘” 식 요청은 공부에 최악이고, “ELF의 구조를 최상위 추상적으로, ‘왜’에 집중해서 설명해줘”는 오히려 엄청난 학습 촉진제임. 매번 리서치를 직접 안 하게 된다는 부분은 단점일 수 있지만, 정말로 지적으로 고민하는 자세면, 소크라테스식 질문 답변을 언제든 받을 수 있다는 건 대단한 학습 가속 효과임

    • (글쓴이) 그게 바로 내가 본문에서 말한 “특정 유형의 학습”임. 예를 들어 ELF 바이너리 구조를 배우려면 직접 추측만으로 알아낼 수 없음. 역사나 의사결정 과정을 알아야 하므로 스펙이나 문서, LLM도 포함해 참고자료를 써야 함. 근본적으로 “스스로 만들어보는 constructive learning”이 중요한데, 직접 바이너리 포맷을 만들어보며 좌충우돌하는 탐구 과정이 ELF 등 실제 포맷의 이유와 문제, 전체 디자인 스페이스까지 깨닫게 하는 포인트임. 이런 탐구 학습에 LLM 도움을 받지 않는 걸 추천. “노트북, 텍스트 에디터, 컴파일러만 주고 10년간 방치한다면 어디까지 만들 수 있을까? 어디서 구체적 정보를 얻어야 막힘?”

  • 여기 소개된 프로젝트들은 정말 좋은 아이디어인데, 나한테는 그 어떤 것도 흥미롭지가 않음. 이럴 때면 내가 진짜 프로그래밍을 좋아했었나 싶어 의문이 생김

    • 나와 정반대인 듯. 리스트 대부분의 프로젝트가 흥미로웠고, 누군가 시도해보고 싶거나 실제로 해봤던 주제임. 사실 나도 최근까지 이 질문을 던졌고, 아기가 태어나 휴직하면서 정말로 재미로 해보려고 “단순한” 코딩 프로젝트를 시작했음. 모든 의존성을 빼고 전부 처음부터 스스로 만들기로 했더니 원래 생각보다 훨씬 복잡해졌지만, 그래서인지 오히려 그 몇 시간 코딩 시간이 너무 기다려졌음. 갑자기 코딩이 너무 재밌어짐. 아마 본인이 번아웃 된 상태가 아닐지 싶음
답변달기