HN 소개: 어린이 코딩 교육을 위한 새로운 시각 언어

• Pickcode는 중·고등학교 컴퓨터 과학 수업을 위한 온라인 IDE로, 교사가 수업 운영에 쓰는 시간을 줄이는 단순하고 안정적인 플랫폼을 지향함
• Chromebook 지원, 학생 작업 모니터링, 실시간 협업, 코드 기록 확인이 핵심 수업 관리 기능임
• 교사는 수업 자료와 과제를 맞춤화해 정리할 수 있으며, Pickcode는 AI 코드 보조 기능이 없다고 명시함
• Java, Web Development, Python, AP Computer Science Principles 수업에서 학생들이 더 쉽게 접근하고 독립적으로 작업하는 데 도움이 됐다는 교사 평가가 있음
• 복잡한 전문 IDE보다 수업 생성과 학생 관리에 초점을 맞춘 도구라, 교실 환경에서 산만함을 줄이는 선택지로 볼 수 있음

---

교실에 맞춘 온라인 IDE

• Pickcode는 중·고등학교 CS 수업을 위한 온라인 IDE임
• 교사가 수업 운영 시간을 아끼도록 단순하고 안정적인 플랫폼을 강조함
• 시작하기, 로그인, 요금제 페이지로 이어지는 기본 진입 경로를 제공함

수업 운영 기능과 교사 반응

• Pickcode의 주요 기능은 수업 진행과 학생 작업 확인에 맞춰져 있음
  • Chromebook에서 동작함
  • 학생 작업을 모니터링할 수 있음
  • 실시간 협업을 지원함
  • 코드 기록을 확인할 수 있음
  • 수업 자료를 맞춤화할 수 있음
  • 과제를 정리할 수 있음
  • AI 코드 보조 기능이 없음
• 교사들은 인터페이스가 단순하지만 확장성이 있고, 여러 연령대 학생들이 좋아한다고 평가함
• Java, Web Development, Python, AP Computer Science Principles 수업에서 활용 사례가 있음
• 학생들이 도구를 더 쉽게 사용하고, 작업을 추적하며, 독립적으로 진행하는 데 도움이 됐다는 반응이 포함됨
• 지원팀은 반응이 빠르고 도움이 되며, 제안 사항 중 다수가 구현됐다는 평가도 있음

[GN⁺]

Hacker News 의견들

• var, set, call 키워드를 꼭 요구할 좋은 이유가 있는지 궁금함. BASIC에는 그런 게 없었고, 어릴 때 처음 프로그래밍을 배웠던 흐릿한 기억으로는 이런 키워드가 불필요한 복잡도였을 것 같음
  예를 들어 LOGO에서는 그냥 forward 10, left 90처럼 쓰면 됐는데, call paint.forward(10), call paint.left(90)는 과하고 시끄럽게 느껴짐

  • 키워드는 매 줄을 말로 읽기 쉽게 만들기 위해 넣은 것임. 특히 set x = 7에서는 변수를 바꾸려는 것인지, 동등성을 단언하려는 것인지 키워드가 분명하게 해줌
    기술적으로는 그리기 프로그램 문맥에서 forward()를 최상위 메서드로 만들 수도 있지만, 나중에 학생들이 2D 게임 엔진으로 가서 여러 스프라이트를 제어할 때를 대비해 좀 더 객체지향적으로 만들기로 했음
  • 여기서는 이름이 조금 직관적이지 않게 느껴짐. forward와 left는 이동 방향처럼 보이는데, 특히 화가를 “왼쪽으로 이동”시키고 싶을 때 헷갈림
    실제로 forward는 그리기/이동이고 left는 음수 인자도 받는 반시계 방향 회전이므로, call paint.draw(10), call paint.rotate(90) 또는 rotate("up") 쪽이 더 잘 와닿음
  • 나이가 드러나는 얘기겠지만, 처음 배운 BASIC에는 서브루틴 호출용 gosub 명령이 있었음
    참고로 초기 BASIC들이 그랬다길래 링크 번호도 1부터 시작하게 붙였음 :)
    [1] https://picaxe.com/basic-commands/program-flow-control/gosub...
    [2] https://alandix.com/blog/2021/07/27/a-brief-history-of-array...
  • 내가 쓰던 Basic에는 LET X=10이 있었음
  • 첫인상도 같았음. 하루 종일 훨씬 복잡한 코드를 보지만, 어린아이 입장에서 생각해보면 이런 불필요한 잡음에 꽤 오해하게 될 것 같음

• 10살 아이에게 Godot를 소개하는 중임. 지난 6개월 동안 Scratch로 게임을 만들었고 Scratch를 좋아하지만, 한계에도 답답해했음
  진짜 스크립트 언어를 쓰면 더 좋아할 줄 알았는데, GDScript를 쓰기 시작하자마자 타이핑 양 때문에 금방 좌절함. 손이 작아서 터치 타이핑을 익히기 어렵고, 변수명과 메서드 호출을 치는 데 시간이 너무 오래 걸림
  이건 딱 좋은 균형처럼 보여서 확인해볼 예정임

  • 타이핑 속도 제한은 정말 좋은 포인트이고, 이상하게도 전혀 생각해본 적이 없었음
    3살 아이와 아주 가벼운 Python 수업을 하고 있는데, 이해도에 비해 진도가 왜 느린지 궁금했음. 이제 보니 괄호와 따옴표 같은 걸 치는 데만도 시간이 오래 걸렸던 것임
    이 프로젝트가 마음에 들고 써보는 게 기대됨. 아이들 프로그래밍은 많을수록 좋다는 쪽으로 생각이 바뀌는 중임. 여러 언어와 작업 흐름 중에서 고르는 역학에 노출시켜도 좋을 듯함
  • 어린이용 크기 키보드를 쓰지 않는 이유가 궁금함
  • 내 경험도 비슷함. 아들에게 8살 때 Scratch를 소개했고, 2년 뒤인 지금은 생각보다 훨씬 고급스러운 게임을 만들고 있음
    그런데 “진짜” 프로그래밍 언어를 보여주면, 그걸 전부 Scratch로도 할 수 있고 굳이 그렇게 많이 타이핑할 필요가 없다고 함
    GameMaker도 같이 해보며 멋진 결과를 만들었지만, 잠깐만 돌아서면 다시 자기 Scratch 프로젝트로 가 있음. 가끔은 예전의 나처럼 처음부터 코드로 시작했으면 더 나았을까 싶기도 함 ;-)
  • Scratch의 한계는 프로그램이 너무 커졌을 때 복잡도를 어떻게 관리할지가 아이에게 분명하지 않다는 데 있다고 느꼈음
    다만 문제를 짚어주고 어떻게 할 수 있을지 물어보는 것만으로도 아이가 그 문제를 생각하고, Scratch 안에서 가능한 여러 방법을 찾게 됨. 예를 들어 프로그램을 여러 객체나 에이전트로 나누는 식임
    Scratch는 첫인상이나 첫 프로그램이 암시하는 것보다 훨씬 강력함
  • GDScript는 놀라울 정도로 좋은 언어임. 여러 면에서 Python보다 낫고, 예를 들어 var와 const가 있음

• Pickcode 출시 축하함. 세부 완성도가 좋고, 신경 써서 만들었다는 게 드러남
  비개발자에게 프로그래밍을 더 접근 가능하게 만들려는 시각적 프로그래밍 쪽에는 적어도 두 흐름이 있다고 봄
  어떤 시도는 시각적 인터페이스로 문법 학습 부담을 줄이지만, 명령형 성격이나 알고리즘적 사고의 필요성은 숨기지 않음. 사실상 접근성 수준이 다른 IDE라고 볼 수 있고, Pickcode와 Scratch가 이 범주에 들어간다고 생각함
  다른 쪽은 시각적 은유에 어느 정도 잘 맞을 수 있는 다른 프로그래밍 패러다임을 탐색함. 사용자에게도 명령형 프로그래밍과 다른 사고방식을 유도함. Node-RED는 흐름 기반 프로그래밍을 탐색하는 좋은 예이고, 이는 함수형 반응형 프로그래밍과 가까운 친척임. LabVIEW도 데이터 흐름 기반의 가까운 친척인데, 더 많은 마법 같은 요소가 있음. 실제로는 꽤 똑똑한 기본값과 내부 변수 이름 붙이기임. Apple Automator도 떠오름
  어느 쪽이 반드시 더 낫거나 나쁘다고 보진 않지만, 시각적 언어를 볼 때 명령형과 반응형의 구분을 생각하면 최종 사용자 경험이 크게 달라진다는 점이 유용함

  • 초보자에게 Elm 같은 함수형 언어 워크숍을 가르치는 게 오히려 전문가에게 가르치는 것보다 더 쉬웠던 기억이 남. 초보자의 머리는 일종의 명령형 C식 사고에 오염되지 않았기 때문임

• “코드 편집 경험은 완전히 구조화되어 있고, 타이핑 대신 메뉴에서 선택한다”는 점이 아주 멋짐
  성인 프로그래머를 위한 이런 것, 즉 여러 프로그래밍 언어에 쓸 수 있는 범용 구조적 편집기가 있었으면 좋겠음. 프로그래밍할 때 먼저 떠오르는 의도는 의미론적임. 여기서 함수를 정의하고, 저기서 조건을 확인하는 식임
  그렇다면 왜 그 의미론적 의도를 편집기에 직접 전달하면 안 되는지 모르겠음. 왜 먼저 의도를 문자열로 직렬화한 뒤, 편집기가 다시 오류가 생기기 쉬운 방식으로 파싱해야 하는지 의문임. 오타, 괄호 불일치, 연산자 우선순위 오류 같은 어리석은 문법 오류가 끼어들 여지가 생기고, 의미론적 오류만 남기는 편이 더 낫지 않나 싶음
  이런 편집기가 꼭 키보드에 불친절할 필요도 없음. Excel이 키보드에 불친절하지 않은 것과 비슷함. 동아시아 언어 입력기처럼 “조합 창”에 입력하고 “후보 창”에서 골라 삽입하는 방식으로도 작동할 수 있을 것 같음

  • 이런 시도는 많이 있었음. “아무도 생각해본 적 없는 아이디어”라기보다는 “엄청 많은 사람이 생각하고 시도했지만 바로 큰 문제에 부딪힌 아이디어”에 가까움
    내가 이해한 바로는, 이 경우 큰 문제는 코드가 거치는 모든 중간 상태가 의미론적으로 유효해야 한다는 제약을 걸고 싶어진다는 점임. 겉으로는 매력적이지만 실제로는 치명적인 제약이 됨. 뛰어난 사람들도 다소 느슨하게 생각한 뒤 나중에 코드를 고치며, 한 줄 단위에서도 그렇다. 항상 100% 유효해야 한다는 강제는 실제 사고 방식과 크게 어긋남
    이 어긋남은 근본적이라고 보는 편임. 인간 중 극히 일부라도 이런 식으로 생각하는지는 모르겠음. 전문 수학자들조차 실제 작업에서는 앞질러 생각한 뒤 엄밀성을 나중에 채우는 경우가 많다고 함. 그들도 한 단계씩 엄격히 전진하지 않는다면 누가 그렇게 하겠나 싶음
    프로그래밍은 의미를 아는 자동완성과 제안으로 정착했고, 그게 단순한 게으름의 결과가 아니라 실제 최적점일 가능성이 큼
    누군가 끝까지 밀어붙이면 문제가 풀릴 수도 있지만, 여기 열매가 있다 해도 낮게 매달린 열매는 아니라고 말하고 싶음
    saurik이 말했듯이 Emacs를 쓰는 Lisp 세계가 여기에 가장 가깝지만, 그래도 원하는 건 무엇이든 할 수 있음. 단지 더 의미론적으로 작업하도록 돕는 도구가 많을 뿐, 절대적으로 강제되는 것은 아님
  • 이런 게 꽤 많지 않나 싶음. Scratch나 그 친척인 Snap(https://snap.berkeley.edu/snap/snap.html), React용 시각적 흐름 편집기(https://app.flowhub.io/#project/c111454c9fd2f74d37d1e8a4e739...), 비슷한 https://retejs.org/ 같은 것들이 있음
  • 성인 프로그래머용으로 이런 걸 원한다고 했는데, Blythe Omnis 7이 1996년 또는 그 이전에 이미 있었음. Windows와 Macintosh를 모두 지원하던 RAD 플랫폼/솔루션이었음
    당시 그 소프트웨어를 들어본 유일한 지원자라서 일자리를 얻었음. 잡지에서 짧은 글을 한 번 읽은 덕분임
    https://en.wikipedia.org/wiki/Omnis_Studio
    드롭다운 목록과 팝업을 클릭해서 프로그래밍하는 방식은 그렇게 잘 설계된 편이 아니었음. 프로그램은 목록처럼 보이고, 한 줄을 편집하려고 하면 모달 대화상자가 떠서 딱 그 한 줄만 고칠 수 있었음. IntelliSense나 코드 완성은 당연히 없었음
    생각만 해도 PTSD가 올라오는 것 같아서 술이나 담배가 필요할 지경임
  • 예를 들어 https://github.com/nocode-js/sequential-workflow-designer는 이런 식으로 설계되어 있음. 미리 정의된 동작을 올바른 순서로 배치해 논리를 프로그래밍하고, 높은 수준에서 프로그래밍하게 됨
  • Lisp를 Emacs로 다루는 사람들은 이런 경험을 하는 것으로 알고 있음. 단순한 텍스트가 아니라 폼으로 생각하고 작업할 수 있기 때문임

• Scratch에서 가장 좋아하는 기능 중 하나는 문법 오류를 만들 수 없다는 것임. 블록은 맞물리거나, 맞물리지 않거나 둘 중 하나임. 그래서 아이들이 별도 설명이나 과외 없이도 더 쉽게 시작해서 놀 수 있다고 봄
  사각형 튜토리얼의 처음 몇 단계를 따라간 뒤 이것저것 클릭하며 직접 해봤는데, call math paint.forward()가 만들어져 문법 오류가 났음. 당연히 그 줄은 쓰레기지만, math 명령이 어떻게 작동해야 하는지 알아내지 못했음. 튜토리얼을 더 따라가면 설명이 나오겠지만, 발견 가능성도 중요하다고 생각함

  • Scratch는 문법 오류를 만들진 않지만, 뭔가 제자리를 벗어나도 불평하지 않음. 예를 들어 블록을 조작하다가 하나가 떨어져 나가도 프로그램은 실행되지만 제대로 동작하지 않음
    블록이 많아지면 서로 겹칠 수도 있어서 찾아내기 꽤 어려워짐. 블록의 인자를 빼먹는 문제도 있음. 그래도 실행은 되지만 동작하지 않음
    시각적 프로그래밍은 아이들에게 분명 더 낫지만, Scratch보다 더 엄격한 접근과 더 나은 디버깅 능력이 필요하다고 봄
  • Scratch, 정확히는 블록의 또 다른 장점은 새로운 언어에 꽤 쉽게 맞출 수 있다는 점임. 우리는 IoT 고객이 장치를 이벤트에 반응시키고 다른 장치에 이벤트를 보내도록 설정하는 데 블록을 썼고, 이 모든 것이 업로드되는 JSON 설정으로 변환됐음

• 보기 정말 좋음. Khan Academy에서 ProcessingJS 편집기의 블록 기반 버전을 만들던 때가 떠오름
  UI가 조금 투박하고 유지보수가 어려워서 결국 접었지만, 이건 꽤 매끄러워 보임. 새 프로그래머들이 타입 있는 프로그래밍으로 들어갈 수 있는 더 많은 길을 제공한다는 점이 좋음. 블록 코딩 대부분은 실제 코드와 너무 멀리 떨어져 있다고도 생각함

  • 이런 블록 편집 UI는 tree-sitter 파서에서 쓰는 것 같은 문법의 추상 설명으로부터 자동 생성할 수 있어야 할 것 같음
    때로는 이런 블록 기반 편집이 타입 검사와 결합되어 “구멍”을 똑똑하게 질의 기반으로 채울 수 있게 하기도 함. 아마 Agda 같은 순수 함수형 언어용 편집기에서 가장 두드러지게 볼 수 있음

• ZX81의 BASIC이 떠오름. 키워드를 타이핑하지 않고, 특수 키보드에 각 키워드용 키가 있었음
  편집기는 문맥 민감형이었고, 다른 말로 하면 파서가 이끄는 어휘 분석기가 사용자 자신이었음. 당시에는 단어/숫자를 입력하려는지 키워드를 입력하려는지, 또 어떤 종류의 키워드인지 알아내는 게 약간 마법처럼 느껴졌음. 사실 교육적으로 중요한 부분은 내가 그걸 알고 있었다는 점이지만
  ZX81에서 중요했던 건 텍스트 표현 대신 토큰을 저장해 메모리를 아꼈다는 점임. RAM이 1KB였고, 그 안에 디스플레이 메모리까지 포함됐음. 별도 GPU도 없었음. 입력 시 파싱하는 덕분에 실행도 더 빨라졌을 것임

• 사이트는 아주 잘 다듬어졌지만 목표에는 완전히 동의하지 않음. 인상적인 IDE이긴 하나, 새 언어보다는 Python의 부분집합에 집중했을 것 같음
  그렇지 않으면 Scratch가 가르치기 더 쉽고, Python은 배우는 데 더 유용하다는 이유로 외면받을 수 있음. 전자는 개발자인 교사가 있는 학교에서, 후자는 아이를 가르치는 프로그래머 부모에게 해당됨
  소프트웨어 개발자로서 아내의 초등학교/유치원 프로그래밍 수업을 도운 적이 있어 이 영역의 문제를 어느 정도 알고 있음

  • “Python의 부분집합”에 해당하는 대안이 있는지 궁금함. “진짜” 프로그래밍으로 이어지는 자연스러운 다리가 있으면 흥미로울 듯함

• 관련 글:
  Show HN: Pickcode – A new way to introduce programming to kids - https://news.ycombinator.com/item?id=33562193 - 2022년 11월, 댓글 14개
  Show HN: PickCode – An educational coding environment for students after Scratch - https://news.ycombinator.com/item?id=32230329 - 2022년 7월, 댓글 32개
  Show HN: Pickcode – A graphical code editor for education - https://news.ycombinator.com/item?id=31426331 - 2022년 5월, 댓글 4개
  재게시물은 1년쯤 지나면 괜찮고, 이전 스레드 링크는 더 궁금한 독자를 위한 것임

• 비슷한 개념을 음악 프로그래밍 쪽으로 작업 중임:
  https://glicol.org
  랜딩 페이지에 바로 몇 가지 예제가 있으면 좋을 것 같음
  수업을 시도해보면 막히는데, 힌트가 오른쪽에 있지만 그다지 눈에 띄지 않음. Svelte Tutorial(https://learn.svelte.dev/tutorial/welcome-to-svelte)처럼 재배치해볼 수 있을 듯함
  문법은 확신이 안 듦. LOGO를 쓰는 것도 고려해봤는지 궁금함