Trustworthy Human-AI Collaboration in a Live Type-Theoretic Computational Commons

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Trustworthy Human-AI Collaboration in a Live Type-Theoretic Computational Commons를 중심으로, 미완성 코드에서도 피드백을 유지한다. Hazel은 빠진 구문을 명시적인 ‘홀’로 복구하고, 불완전한 값을 기호적으로 계산한를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 미완성 코드에서도 피드백을 유지한다. Hazel은 빠진 구문을 명시적인 ‘홀’로 복구하고, 불완전한 값을 기호적으로 계산한다. 프로브로 중간 실행 값을 관찰할 수 있어 전체 프로그램을 완성하기 전에도 논리 오류를 찾아 수정할 수 있다. 다만 홀 때문에 분기를 결정할 수 없는 계산은 막힌다.
2. 에이전트의 속도만큼 도구의 응답 속도가 중요해진다. 재컴파일·재실행과 긴 로그 처리는 인간과 에이전트 모두에게 부담이다. Hazel은 이전 계산을 재사용하며, 표현식 수준의 증분 계산과 타입 정보 갱신을 추구한다. 중간 계산을 더 넓게 재사용하는 shortcut memoization은 연구 중이다.
3. 의미 정보를 활용해 수정과 검토의 부담을 줄인다. AI 보조 도구는 타입, 실행 값, 홀을 포함한 의미 모델과 구조화된 편집 동작을 사용한다. 별도의 PR 검토 연구는 변경 조각을 논리적인 설명 순서로 배치해 인간의 이해를 돕는다. 토큰 절감과 편집 효율에 관한 관찰은 아직 정식 연구 결과로 정리하는 단계다.
4. 동시 편집과 실행 권한을 각각 통제한다. 트리를 위한 그래프 CRDT는 코드 이동과 수정이 겹치는 문제를 다루고, Unison의 내용 기반 참조는 여러 버전의 공존과 명시적인 갱신을 지원한다. 객체 역량과 정보 흐름 제어는 에이전트가 사용할 권한과 민감한 데이터의 이동 범위를 제한하려는 접근이다.
5. 최종 구상은 실행 가능한 계산 공유 공간이다. 코드·데이터·표·그래픽을 연결하고 인간과 AI가 함께 편집하는 환경을 지향한다. 타입 이론을 기반으로 기후 모델 등 여러 계산을 연결하려 하지만, 대규모 분야 적용과 외부 데이터 처리에는 미완성 과제가 남아 있다.

🧩 배경과 문제 정의

• 좋은 도구는 사용자의 행동에 신속하게 반응하고, 감각적으로 쉽게 이해할 수 있는 피드백을 제공한다. 프로그래밍에서는 컴파일과 실행을 기다리거나 긴 텍스트 로그를 해석해야 하므로 이 피드백 순환이 느려진다.
• 구문 오류나 타입 오류가 있으면 에디터 기능과 실행 결과가 끊기는 ‘갭 문제’가 발생한다. 프로그램 일부가 완성되어 있어도 다른 부분의 오류 때문에 동작을 확인하기 어렵다.
• Hazel은 언어와 개발 환경을 함께 설계해 미완성 코드에서도 타입 정보와 실행 결과를 제공하고, 표·음악 등 데이터에 맞는 표현으로 피드백을 이해하기 쉽게 만드는 연구 시스템이다.
• AI 에이전트가 도구를 사용하는 환경에서는 인간과 도구, 인간과 인간 사이의 피드백에 에이전트의 도구 사용까지 더해진다. 처리 구간 말미에는 이러한 협업 구조로 논점이 확장된다.

🕒 시간순 섹션별 상세정리

1. 즉각적이고 이해하기 쉬운 피드백이 학습을 돕는다

• 좋은 피드백은 제때 도착하고 처리 부담이 작아야 한다. 피아노는 건반을 누르면 소리가 나고 붓은 종이에 닿으면 흔적을 남기므로, 사용자는 행동의 결과를 감각으로 곧바로 확인한다 [01:04]
• 이러한 짧은 피드백 순환은 빠른 학습과 높은 수준의 수행을 뒷받침한다. 곡을 완벽히 연주해야만 소리를 들을 수 있고 실수하면 약 3분 뒤 오류만 받는 가정은 프로그래밍의 지연된 피드백을 드러낸다 [02:03]

2. 오류와 긴 실행 시간이 만드는 ‘갭 문제’

• 일반적인 개발 과정에서는 코드를 작성한 뒤 컴파일러에 정확성을 확인하고, 오류가 나면 다시 수정한다. 구문 강조처럼 즉각적인 피드백도 있지만, 구문·타입 오류가 있으면 완성된 부분조차 실행 결과를 확인하기 어렵다 [02:51]
• ‘갭 문제’는 오류로 인해 정의로 이동 같은 에디터 서비스가 끊기는 현상까지 포함한다. 긴 컴파일·재실행 시간과 해석하기 어려운 텍스트 로그도 피드백의 속도와 이해도를 떨어뜨린다 [03:57]

3. 미완성 구문을 명시적인 홀로 복구한다

• 퀵소트 예제는 테스트를 먼저 작성하고 빈 리스트를 처리한 상태에서 시작한다. 재귀 분기에서는 리스트의 첫 원소를 피벗으로 삼아 나머지 원소를 분할하려 하지만, 분할 함수와 뒤따르는 식은 아직 완성되지 않았다 [05:34]
• 일반적인 파서는 let … in 뒤에 식이 없으면 구문 오류를 내고 타입 검사까지 진행하지 못한다. Hazel의 오류 복구 파서는 필요한 식의 자리에 육각형 모양의 명시적 빈칸인 ‘홀’을 넣어 이후 분석을 계속한다 [06:44]

4. 프로브로 미완성 함수의 입력부터 관찰한다

• 프로그램의 임의의 식에 프로브를 붙이면 해당 위치의 실행 정보를 코드 옆에서 확인할 수 있다. 아직 정의되지 않은 분할 함수에서도 피벗 3과 나머지 리스트가 인자로 전달되는 모습이 드러나므로 패턴 매칭 결과를 검증할 수 있다 [07:54]
• 두 테스트에서 발생한 호출을 전환해 볼 수 있으며, 함수를 작성하는 동안에도 구문 오류 복구와 자동으로 보충된 구문에 대한 피드백이 계속된다. 분할 함수는 빈 리스트에서 두 빈 분할을 반환하고, 나머지 경우에는 같은 피벗으로 꼬리 부분을 재귀 처리한다 [08:38]

5. 타입 검사로 잡히지 않는 분할 오류를 즉시 수정한다

• 타입 오류가 없어도 분할 결과가 모두 3으로 채워질 수 있다. 실제 원소 대신 피벗을 매번 넣은 오류이며, 삽입할 값을 고치면 아직 전체 프로그램이 미완성인 상태에서도 결과에 원래 입력 원소들이 즉시 나타난다 [10:52]
• 원소를 바로잡은 뒤에도 작은 값과 큰 값이 반대쪽 분할에 들어가는 오류가 남는다. 비교 연산을 ‘작다’에서 ‘크다’로 바꾸자 프로브 결과가 즉시 갱신되어 분할이 올바르게 이루어졌음을 확인할 수 있다 [11:36]

6. 재귀 한도와 부수 효과를 통제해야 실시간 실행이 가능하다

• 재귀 한도에 도달해도 코드 입력 자체가 차단되지는 않는다. 한도를 넘긴 호출을 국소화하고 계산하지 못한 부분에 홀을 남겨 다른 계산은 계속하도록 하는 방향을 취하고 있으나, 이 처리는 개선 여지가 있다 [12:39]
• Hazel에서는 네트워크 호출이나 파일 입출력 같은 부수 효과를 프로그램에 직접 넣을 수 없다. 매 편집마다 다시 계산하는 환경에서 거래 같은 효과까지 반복 실행되지 않도록 통제가 필요하다 [13:34]

7. 여러 호출 결과와 큰 값을 코드 옆에서 확인한다

• 같은 함수를 여러 번 호출하면 프로브에 여러 결과가 모이며, 결과를 전환하거나 나란히 펼쳐 볼 수 있다. 이러한 수집은 테스트 전용 기능이 아니라 일반적인 함수 호출에도 적용된다 [14:34]
• test 키워드는 테스트 결과를 아이콘으로 표시하며, 함수가 미완성이어서 결과를 결정할 수 없을 때는 물음표가 나타난다. 값이 크면 별도 펼침 영역과 크기 조절 기능으로 표시 공간을 늘릴 수 있다 [14:56]

8. 특정 호출을 고정해 재귀 내부의 값을 추적한다

• 프로브의 step into 기능은 선택한 호출의 정의로 이동하고, 고정된 부모 호출에 연결된 하위 실행 샘플을 선택한다. 이를 통해 해당 호출이 계산될 때 중간 변수에 어떤 값이 들어 있었는지 조사할 수 있다 [15:42]
• 특정 재귀 단계가 관심 대상이라면 그 단계의 값을 선택해 고정하고 같은 호출 프레임에 속한 정보로 범위를 좁힐 수 있다. 코드 옆의 실행 결과가 디버거처럼 호출 맥락을 탐색하는 수단이 된다 [16:26]

9. 홀은 계산을 즉시 중단시키지 않고 값 안으로 전달된다

• 리스트에 넣는 원소를 홀로 바꾸면 결과에도 부분적으로 알려진 값이 나타난다. 홀은 미구현 예외처럼 즉시 실행을 중단시키는 것이 아니라 기호적으로 평가되며 계산을 따라 전달된다 [16:59]
• 홀 때문에 필요한 분기를 선택할 수 없는 등 실제로 계산을 진행할 수 없는 지점에 도달하면 해당 계산이 막힌다. 따라서 불완전한 값이 존재한다는 이유만으로 모든 실행 정보를 잃지는 않는다 [17:24]

10. 점진적 타입과 타입 홀 추론으로 불완전성을 다룬다

• Hazel은 점진적 타입을 사용해 타입 자체에도 미지의 부분을 허용한다. 아직 작성하지 않은 코드의 타입뿐 아니라 조건문의 분기별 타입이 서로 다른 경우에도 미지 타입을 사용할 수 있다 [18:09]
• 별도 개발 브랜치의 ‘타입 홀 추론’은 단일화 방식으로 타입의 빈칸을 가능한 만큼 채운다. 모든 제약을 만족시키지 못하면 일부 제약에 따른 부분 해를 제시하고, 사용자가 선택한 타입을 기준으로 다른 위치의 오류를 구체화한다 [18:46]

11. 풍부한 실행 기록에는 성능과 데이터 규모의 한계가 있다

• 호출 고정과 호출 스택 추적에는 내부 상태를 관찰하고 기록하는 인터프리터가 필요하다. 큰 프로그램에서는 수집 데이터가 지나치게 커질 수 있어, 특정 위치에서 샘플을 10개까지만 모으는 식의 제한을 둘 수 있다 [19:33]
• 개발 중에는 실제 데이터와 형태가 같은 작은 샘플로 계측된 인터프리터를 사용하고, 개발이 끝나거나 큰 입력을 받으면 추적 기능이 없는 효율적인 실행 형태로 JIT 전환하는 구상이다. 이 전환 기능은 아직 구현되지 않았으며, 현재 시스템은 OCaml로 구현되어 있다 [20:10]

12. 실행 여부와 호출 관계를 색상과 스택으로 구분한다

• 연한 초록색 표시는 현재 호출 프레임에서 직접 실행된 곳뿐 아니라 하위 호출에서 도달한 곳에도 나타날 수 있다. 기저 사례로 곧바로 끝나는 입력에서는 나머지 위치에 실행 샘플이 남지 않는다 [21:01]
• ‘프로바리움’ 사이드바의 선택 가능한 색상 체계는 초록·파랑·빨강으로 호출 스택상의 상대적 관계를 표현한다. 예제에서 파란색은 현재 프레임 자체가 아닌 하위 호출에서 얻은 데이터를 나타낸다 [22:50]

13. 퀵소트 완성과 테스트 수정이 즉시 결과에 반영된다

• 작은 분할과 큰 분할에 각각 퀵소트를 재귀 호출하고 결과를 결합하면 미완성 상태의 테스트 아이콘이 성공 또는 실패 표시로 바뀐다 [24:46]
• 실패한 테스트 하나는 구현이 아니라 기대값의 순서가 잘못된 경우였다. 기대값을 9, 7, 10에서 7, 9, 10으로 고치자 즉시 성공 표시가 나타나며, 구현과 테스트 양쪽을 짧은 피드백 순환으로 점검할 수 있다 [25:27]

14. 표와 음악의 표현을 데이터 조작 및 실행 결과에 연결한다

• Hazel은 튜플의 리스트로 작성한 데이터를 실제 표 형태로 표시하며, 프로브의 결과도 표로 해석할 수 있다. 표 메뉴에서 점수 내림차순 정렬을 선택하면 필요한 비교 함수를 포함한 정렬 파이프라인 코드가 삽입된다 [26:11]
• 타입별로 표현을 맞춤화하는 체계는 음악에도 적용된다. 드럼 선택 UI, 악보, 피아노 입력, 게인과 팬 조절기를 조합하며, 이 시각적 조작 요소들은 내부적으로 데이터나 숫자를 생성한다 [27:24]

15. AI 에이전트의 도구 사용이 피드백 구조를 확장한다

• 프로그래밍 UI가 에이전트형 AI 실행 환경으로 이동하면서 고려해야 할 피드백 순환도 늘어난다. 기존의 인간과 도구 사이의 상호작용에 더해, 협업하는 인간끼리도 서로 피드백을 주고받는다 [29:14]
• AI 에이전트는 별도의 흐름에서 자신의 도구 집합을 사용한다. 이 도구들은 기존 도구를 바탕으로 하면서도 조금씩 변형되는 경우가 있어, 인간의 도구 사용과 에이전트의 도구 사용을 함께 고려해야 하는 구조로 논점이 확장된다 [29:48]

16. 에이전트가 빨라질수록 도구의 피드백이 병목이 된다

• 여러 에이전트가 같은 코드베이스에서 상호작용하면 피드백 고리가 늘어난다. 현재 최첨단 모델의 속도를 초당 100토큰 미만 정도로 설명하며, 향후 초당 1,000토큰 이상을 생성하는 에이전트가 등장하면 도구의 응답 속도가 병목이 될 수 있다고 전망한다. [30:49]
• AI는 문법 오류를 비교적 적게 내지만, 타입 오류 하나가 전체 실행 피드백을 막는 문제는 여전히 겪는다. 학습 데이터에 Hazel이 없어도 코드를 작성할 수 있다는 관찰과 별개로, 불완전한 코드에서도 피드백을 제공하는 도구가 필요하다. [31:51]

17. 작은 편집에는 필요한 계산만 다시 실행한다

• 완성된 퀵소트에 테스트를 추가할 때 기존 테스트까지 다시 실행할 필요는 없다. 문자 하나를 입력할 때마다 전체 프로그램을 실행하지 않도록, 작은 편집이 정적 정보와 실행 결과의 작은 재계산으로 이어지는 세밀한 증분 처리를 지향한다. [33:38]
• Hazel 시연에서는 이전 테스트의 호출 결과를 재사용한다. 등식 오른쪽을 수정하는 동안 이미 계산한 왼쪽 결과는 유지하고, 등식 비교만 다시 실행한다. [34:46]

18. 중간 계산과 타입 정보까지 증분 처리한다

• 함수 내부의 비교 연산처럼 작은 부분을 바꾸더라도 기존 계산 일부는 재사용할 여지가 있다. 연구 중인 ‘shortcut memoization’은 중간 계산을 패턴 변수로 추상화한 메모 테이블에 저장하고, 패턴 기반 조회로 재사용하는 방식이다. [35:14]
• 타입 검사도 최종 타입의 확인에 그치지 않고, 화면에 표시할 중간 결과의 타입 정보까지 증분 계산한다. 이 계산의 의미론을 다룬 논문에서 정확성을 증명했다고 보여준다. [36:10]

19. 의미 정보를 직접 활용하는 AI 개발 도구

• Hazel AI 보조 도구는 타입이 있는 함수형 프로그램, 실행 중인 데이터, 미완성 부분과 오류를 나타내는 구멍을 포함한 의미 모델 위에서 동작한다. 셸 명령 대신 Hazel의 구조화된 편집 동작을 사용한다. [37:27]
• 의미 기반 검색은 같은 이름의 함수가 여러 개 있거나 정의가 멀리 떨어져 있어도 실제 참조 대상을 찾게 한다. 각 줄의 실행 값을 텍스트로 전달하면 에이전트가 코드 작성 중 데이터 흐름을 확인할 수도 있다. [38:05]

20. PR을 논리적인 설명 순서로 구성해 리뷰 부담을 줄인다

• AI가 변경 제안 생산을 가속하면서 인간의 리뷰가 병목이 된다. 발표자는 여러 프로젝트에서 검토해야 할 PR이 약 50개 쌓여 있다는 사례를 든다. [39:49]
• ‘narrativized change tour’는 PR의 변경 조각을 이해하기 좋은 설명 순서로 배치한다. 마크다운 문서에 변경 조각을 포함하고, 모든 변경을 설명했는지 검사하며, 초기 설명 생성을 돕는 기능을 결합한다. [40:24]

21. 동시 편집의 충돌을 구조화된 트리 편집으로 다룬다

• 기존 버전 관리에서는 다른 에이전트가 지금 무엇을 편집하는지 파악하기 어렵다. 조율이 부족하면 같은 부분을 수정하고, 충돌 해결끼리 다시 충돌하면서 토큰을 소모할 수 있다. JavaScript에서 WebAssembly로 변환하는 검증된 컴파일러를 만들려던 사례에서도 쉬운 작업에 에이전트들이 몰려 성과 대비 비용이 커졌다고 보여준다. [41:19]
• 공동 트리 편집 연구는 구조화된 편집 동작 사이의 교환 성질을 갖추고 관련 성질을 증명하는 데 초점을 둔다. 제안한 시스템은 트리를 위한 그래프 CRDT다. [42:33]

22. 내용 기반 참조로 여러 코드 버전을 공존시킨다

• Unison은 코드를 삭제하는 대신 새 버전을 추가하고, 이름이 아닌 내용 기반 해시로 참조한다. 함수의 새 버전을 만들어도 기존 참조가 즉시 바뀌지 않으며, 필요한 참조만 명시적으로 갱신할 수 있다. [43:33]
• 에이전트들은 서로 다른 버전을 병렬로 만든 뒤 나중에 정리하거나 리팩터링할 수 있다. 이러한 버전 관리 방식을 앞서 설명한 공동 편집 연구와 결합하고 있다. [44:12]

23. 객체 역량과 정보 흐름 제어로 실행 권한을 제한한다

• 민감한 데이터와 외부 효과를 다루는 에이전트에 터미널의 루트 권한을 그대로 주는 방식은 부적절하다는 입장이다. 객체 역량은 작은 객체 API를 통해 사용할 수 있는 권한을 세밀하게 제한한다. [44:36]
• 파일 입출력 권한을 특정 로그 파일에 추가만 가능한 권한으로 축소하면, 이를 받은 구성 요소는 일반적인 파일 작업을 할 수 없다. 역량을 위조할 수 없는 언어를 전제로, 검증 가능한 기본 정책을 만들고 작업마다 권한을 더 좁히는 도구 언어를 제안한다. [45:16]

24. 실행 중인 프로그램들이 연결된 계산 공유 공간

• 미래 구상은 코드 저장소들의 집합을 넘어, 실행 중인 프로그램들이 연결된 네트워크다. 인간과 AI의 공동 편집을 지원하면서도 한 부분의 문법·타입 오류가 전체 공유 공간을 중단시키지 않아야 한다. [47:05]
• 비개발자도 계산 결과가 포함된 보고서를 관찰하고 그래프나 슬라이더를 직접 조작할 수 있어야 한다. 각 페이지가 모듈 역할을 하고 필요한 부분만 증분 재계산하는, 위키피디아와 유사한 공동 작업 환경을 상상한다. [48:02]

25. 기존 협업 방식에 실시간 작업 가시성을 보완한다

• 질의에서는 이미 수천 명이 변경·병합·리베이스를 통해 대규모 코드베이스에서 협업한다는 반론이 나온다. 이에 기존 방식이 작동하지 않는다는 표현은 지나쳤으며, 빠른 에이전트 편집에서 부담이 커진다는 뜻으로 수정한다. [50:24]
• Lean의 mathlib 사례에서는 컴파일 처리량뿐 아니라 다른 에이전트가 관련 보조정리를 증명 중인지 커밋 전에 알고 싶다는 요구가 있다. 구상하는 방향은 Git과 같은 기반 위에 Google Docs처럼 진행 중인 작업을 볼 수 있는 기능을 더하는 것이다. [50:54]

26. 세밀한 협업의 필요성은 같은 구성 요소의 편집 밀도에 달려 있다

• 세밀한 편집 단위가 대규모 작업의 필수 조건인 것은 아니다. 같은 구성 요소에서 빠른 반복 수정이 많이 일어날수록 중요해지며, 구조적 경계가 명확하고 구성 요소마다 한두 에이전트만 작업한다면 전통적인 접근도 유효하다. [52:25]
• 한 코드베이스에서 이전 버전을 참조하고 단일한 표준 버전으로 즉시 통일하지 않는 기능, 코드 이동을 정확히 처리하는 기능은 여전히 개선할 가치가 있다. 기존 협업 체계를 전부 폐기하기보다 이런 구체적인 문제를 보완하려는 입장이다. [53:03]

27. 증명과 불변식 중심의 검토를 개발 환경에 통합한다

• 제안한 대규모 협업 형식을 수학이나 다른 분야에 실제 적용한 단계는 아직 아니다. 기반 연구를 진행하면서 Hazel에 정리 증명 기능을 추가하고 있으며, Lean의 전면적인 의존 타입 설계보다 Isabelle 계열의 설계를 택하고 있다. [53:47]
• AI를 통해 증명을 만드는 비용이 달라지면, 코드의 세부 구현과 함께 불변식이 타당한지 검토하고 그 성립을 증명으로 확인하는 방식이 중요해질 수 있다. 수학·과학·기술이 공통의 계산 환경을 사용하는 미래를 지향한다. [54:23]

28. 대규모 데이터는 외부 저장소에서 처리하도록 연결한다

• 계산 모델은 데이터와 계산이 함께 존재하는 거대한 스프레드시트에 가깝다. 다만 행성 규모의 데이터가 실제로 IDE 메모리에 모두 들어간다는 의미는 아니다. [55:40]
• 연구 중인 ‘foreign data interface’는 외부 데이터셋을 연결한다. Apache Spark의 pushdown API에서 영감을 받아, 함수형 데이터 변환을 원격 SQL 저장소의 필터 질의 등으로 바꾸어 실행하는 방식을 구상한다. [56:09]

29. 계산 공유 공간의 기반으로 타입 이론을 선택한다

• 트리 기반 표현을 어디까지 일반화할 것인지에 대한 질의에, 핵심 입장은 모든 것을 트리로 보는 것이 아니라 타입 이론을 온톨로지의 좋은 기반으로 보는 것이라고 답한다. [57:55]
• RDF를 타입 없는 대상 사이의 이항 관계로 지식을 표현하는 방식으로 비판하며, 세계에는 이항이 아닌 관계와 서로 다른 종류의 대상도 있다고 지적한다. 계산 공유 공간은 곱·합·함수·모듈을 기반으로 해야 한다는 입장이다. [58:13]

30. 수학적으로 뒷받침된 구현을 통해 다른 생태계의 채택을 유도한다

• 연구 성과의 확산 전략을 ‘질투를 통한 이전’으로 표현한다. 수학적 증명이 뒷받침하는 매력적인 시스템을 만들면, 충분한 엔지니어링으로 실용화되거나 다른 공동체가 유사한 기능을 구현하도록 자극할 수 있다는 생각이다. [59:04]
• 코드에 그래픽을 통합하는 작업, 라이브 프로그래밍, 구멍을 활용하는 프로그래밍이 여러 언어와 공동체에서 발전하고 있다. 이러한 흐름을 자신의 연구 집단만의 영향으로 보지는 않는다. [59:40]

31. 라이브 실행의 안전성은 순수성 분석과 부수 효과 처리에 달려 있다

• 순수성이 보장되지 않는 코드의 매 입력 실행은 부수 효과가 그대로 발생하는 것을 감수하거나, 의미 분석으로 순수한 코드만 골라 실행하는 방식으로 접근할 수 있다. [1:00:02]
• Chrome 개발자 도구의 JavaScript 라이브 실행은 얕고 보수적인 순수성 분석으로 부수 효과가 발생하지 않는지 확인하는 사례다. [1:00:19]

32. 언어 도입 비용의 감소가 새로운 코드 환경을 설계할 여지를 넓힌다

• 표·그래픽·슬라이더와 에이전트의 코드 수정이 결합된 환경에서는 코드가 컴파일되는 텍스트 파일이라는 관념에서 얼마나 멀어질지, 인간이 그 아래의 여러 계층을 얼마나 이해할 수 있을지가 열린 문제다. [1:01:06]
• 인간이 기반 계층을 얼마나 이해할지는 불확실하지만, 기존 기반을 계속 쌓아 올려야 하는지도 분명하지 않다. 새로운 것을 구축하고 도입하는 비용이 크게 달라졌으며, Hazel에서는 도구를 밤새 실행해 라이브러리를 만들거나 다른 언어의 코드를 쉽게 이식할 수 있다는 경험이 그 근거다. 데이터 분석 사례 연구에는 Jupyter 노트북을 Hazel로 옮긴 작업도 포함된다. [1:01:46]

33. 실시간 갱신의 가치와 명시적인 버전 선택을 함께 확보해야 한다

• 모든 것이 계속 바뀌는 환경은 개발 중인 코드와 배포된 코드의 경계를 흐리며, 수정이 사용자에게 즉시 장애를 일으키지 않도록 배포를 어떻게 다룰지라는 문제를 만든다. [1:03:12]
• 기후과학에서는 전 세계 수백만 센서의 데이터가 밀리초마다, 지구 표면의 10제곱미터 단위 위성 데이터가 매일 들어온다는 점이 실시간 갱신의 가치를 뒷받침한다. 대형 기후 모델의 소규모 버전 출시 사이에 2년을 기다리지 않고 지구 상태를 최신 정보로 파악하며 정책 개입의 가상 결과를 추론할 수 있다면 유용하다는 기대다. [1:03:50]

🧾 결론

• 발표의 중심은 코드 생성량 확대보다, 불완전한 상태에서도 결과를 관찰하고 변경을 이해하며 실행을 통제할 수 있는 협업 환경이다.
• 라이브 피드백, 구조화된 편집, 버전 선택, 권한 제한은 서로 다른 문제를 해결한다. 어느 한 기능만으로 협업의 신뢰성이 완성되는 것은 아니다.
• 기존 Git 기반 협업도 구조적 경계가 명확한 작업에서는 유효하다. 세밀한 공동 편집의 필요성은 같은 구성 요소에 빠른 수정이 얼마나 집중되는지에 달려 있다.
• Hazel의 시연 기능과 장기적인 계산 공유 공간 구상은 구분해야 한다. 개별 연구의 증명이나 시연이 전체 시스템의 실용성과 확장성을 입증한 것은 아니다.

📈 투자·시사 포인트

• AI 개발 도구의 평가 범위를 모델의 생성 속도에서 피드백 지연, 실행 정보 전달, 리뷰 부담, 충돌 해결 비용까지 넓힐 필요가 있다.
• 의미 정보를 직접 활용하는 편집과 세밀한 계산 재사용은 도구 차별화의 후보가 된다. 다만 발표만으로 상용 성능이나 비용 절감 규모를 판단할 수는 없다.
• 에이전트가 많아질수록 진행 중인 작업의 가시성, 제한된 실행 권한, 명시적인 버전 전환을 지원하는 협업 기반의 중요성이 커질 수 있다.
• 새로운 언어로 라이브러리를 만들거나 코드를 이식하는 비용이 낮아졌다는 경험은 개발 환경 실험의 여지를 보여준다. 생태계 전환의 경제성이 입증됐다는 의미는 아니다.

⚠️ 불확실하거나 확인이 필요한 부분

• 추적 기능이 있는 실행에서 효율적인 실행 형태로 바꾸는 JIT 전환은 발표 시점에 구현되지 않았다. 외부 데이터 인터페이스와 Spark 연결도 연구·구상 단계다.
• 구조화된 AI 편집의 토큰 절감은 초기 관찰이다. 비교 조건, 효과 크기, 작업별 성공률을 확인할 정식 결과가 필요하다.
• 타입 홀 추론은 별도 개발 브랜치에 있으며, 재귀 한도 처리와 실행 정보 UI에도 개선 과제가 있다. 음악 시연에서는 일시정지가 작동하지 않았다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• hazel.org에서 미완성 함수와 홀을 포함한 작은 예제를 실행하고, 유지되는 피드백과 계산이 막히는 지점을 확인한다.
• 현재 개발 흐름에서 컴파일·재실행 대기, 로그 처리, PR 검토, 편집 충돌에 드는 시간을 구분해 병목을 기록한다.
• 같은 구성 요소를 여러 에이전트가 수정하는 빈도를 살펴보고, 작업 가시성과 세밀한 공동 편집이 필요한 범위를 정한다.
• 에이전트의 파일·네트워크 권한을 작업별로 점검하고, 로그 추가처럼 더 좁은 권한으로 수행할 수 있는 작업을 찾는다.

❓ 열린 질문

• 표현식 수준의 증분 계산과 풍부한 실행 기록은 큰 코드베이스에서 어느 정도의 메모리·응답 시간 비용을 요구할까?
• 구조화된 편집과 의미 기반 피드백은 기존 도구 대비 에이전트의 정확도와 전체 작업 비용을 얼마나 개선할까?
• 코드가 표·슬라이더·실행 값과 결합될 때 인간은 변경의 의미와 기반 계층을 충분히 이해하고 검토할 수 있을까?