HN 공개: Haystack – 무한 캔버스에서 코드 탐색·편집하는 IDE

 (haystackeditor.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Haystack은 PR의 대화 기록과 변경 사항을 함께 읽어, 실제로 사람 판단이 필요한 변경만 리뷰어에게 넘기는 코드 리뷰 도구로 제시됨
  • 깨끗한 PR은 자동 병합하고 위험한 PR은 선별 대상으로 분류해, “human code review time to zero”에 가까운 흐름을 목표로 함
  • 예시 PR은 tenancyInit()과 cacheWarmup()을 Promise.all()로 병렬화해 콜드 스타트를 약 4초에서 2.4초로 줄였지만, 과거 실행 순서 결정을 되돌림
  • Haystack은 대화 기록에서 cacheWarmup이 tenancyInit 이후 실행돼야 한다는 근거를 찾고, 샌드박스에서 50회 부팅 중 31회 크래시를 확인함
  • 문제가 있는 PR은 원래 순서를 정한 @maya에게 전달되며, 깨진 설계 결정과 실패 결과가 PR에 붙어 리뷰 판단 시간을 줄임

PR 리뷰를 자동 선별하는 흐름

  • Haystack은 모든 PR의 대화 기록과 변경 사항을 읽고 위험도를 판단함
  • 위험한 PR은 엔드투엔드로 실행해 검증하며, 사람의 판단이 필요할 때만 리뷰어를 끌어들임
  • 화면에는 16개 PR을 Haystack이 선별하는 모습이 나타남
    • TypeScript, JavaScript, C, Python, Ruby, Go, C++ 등 여러 언어의 PR이 나열됨
    • 각 PR은 analyzing 상태로 표시됨

위험한 변경 예시: 서비스 부트스트랩 병렬화

  • 예시 PR platform#3120 feat: parallelize service bootstrap은 서비스 부트스트랩 단계를 병렬화하는 변경임
  • 기존 코드는 tenancyInit()을 실행한 뒤 cacheWarmup()을 순차 실행함
  • 변경 코드는 두 작업을 Promise.all([tenancyInit(), cacheWarmup()])로 동시에 실행함
  • PR 설명상 콜드 스타트는 약 4초까지 늘어났고, 병렬화 후 약 2.4초로 줄어듦
  • 기존 테스트가 모두 통과해 겉으로는 승인하기 쉬운 성능 개선처럼 보임

대화 기록에서 드러난 설계 결정

  • Haystack은 PR 뒤의 이력을 읽어 변경이 과거 설계 결정을 되돌린다는 점을 찾아냄
  • @maya는 cacheWarmup이 빈 설정을 읽지 않도록 tenancyInit이 먼저 끝나야 한다고 요구했음
  • 테스트 스위트에는 이 실행 순서를 검증하는 항목이 없어 회귀가 테스트를 통과함
  • Haystack review는 PR에 다음 정보를 붙임
    • 대화 기록에 남은 결정
    • 현재 PR이 실제로 바꾸는 동작
    • 테스트가 통과한 이유

실행 검증과 실패 결과

  • Haystack은 코드를 읽는 데서 멈추지 않고 변경을 직접 실행함
  • 대화 기록이 테스트에 없는 타이밍 경쟁 조건을 가리키자, 샌드박스에서 서비스를 50회 부팅함
  • 50회 중 31회에서 cacheWarmup이 tenancyInit 완료 전 빈 설정을 읽음
  • 그 결과 서비스가 첫 요청에서 예외를 던지고 크래시함
  • Haystack QA는 실행 이유, 수행한 테스트, 깨진 지점을 PR에 함께 표시함

사람 리뷰가 필요한 지점

  • Haystack은 해당 PR을 자동 병합하지 않고, 원래 실행 순서를 정한 @maya를 참여시키라고 추천함
  • PR에는 깨진 설계 결정과 실패한 부팅 결과가 함께 표시됨
  • 리뷰 화면은 “Request review”, “Chat with @maya”, “Doesn’t need review” 같은 선택지를 제공함
  • Haystack의 흐름은 대부분의 PR을 자동 병합하고, 예시처럼 위험한 변경만 적절한 사람에게 넘기는 데 초점을 둠

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • AI 기능은 잘 모르겠지만, 캔버스 위에서 코드 작업을 하고 흐름도 UI를 함께 쓰는 개념은 오래전부터 바라던 것임
    주로 데이터 처리를 하고, 파이프라인을 설명하거나 스스로 이해하기 위해 흐름도를 많이 그림
    이런 방향의 개발 UI가 있으면 CS 전공자가 아닌 사람들이 만든 다루기 힘든 코드베이스를 다루는 데 좋을 듯함

    • LabView 같은 도구를 떠올린 건가요?
      https://www.ni.com/en/shop/labview.html
    • Java에서 BlueJ가 하는 방식과 비슷한 건가요?
    • 마주한 문제가 데이터 흐름을 시각화하는 쪽인지, 제어 흐름을 시각화하는 쪽인지 궁금함
    • 같은 캔버스 안에서 다이어그램과 코드를 함께 스케치할 수 있으면 멋질 듯함
      시각적 문서화가 훨씬 쉬워질 것 같음

  • 정말 멋짐. 메서드나 선언으로 이동할 때 전체 파일을 정의 위치까지 스크롤한 보조 탭으로 여는 게 아니라, 관련 코드 조각만 보여주는 점이 마음에 듦
    메서드가 호출되는 위치와 정의를 비교해야 해서 읽던 메서드를 자주 놓치곤 하는데, 그게 꽤 답답함
    메서드를 옆에 “고정”해 두고, 고정된 뷰에서 실수로 전체 파일을 스크롤하게 되지 않은 채 훑어볼 수 있는 게 좋음
    잠깐 써보니 아쉽게도 마우스 중심이 강했고, 다른 메서드 안의 메서드를 따라가다 보니 관리해야 할 떠 있는 창이 너무 많아졌음
    어떤 창이 “부모” 창인지 추적할 수 있게 화살표나 선이 있으면 일종의 흐름도를 만들기 쉬울 듯함
    개인적으로 아쉬운 점은 있지만, 이 영역에서 다른 사고방식을 보는 건 반갑고 성공하길 바람

    • 왜 마음에 드는지는 알겠지만, 장기적으로는 순효과가 음수일 수도 있다고 봄
      코드에서 무엇이 어디에 있는지 어느 정도 알고 있는 게 유익하다고 생각함
      몇 년 동안 한 프로젝트를 했는데도 작은 조각만 보며 작업해서 파일들이 대체 뭘 하는지 모르는 상태가 될 수도 있지 않을까 싶음
    • 문학적 프로그래밍은 이걸 1차원, 즉 세로 스크롤 방식으로 구현하며 두 가지 뷰를 제공함
      주석과 텍스트가 섞인 원본 코드, 그리고 서식 있는 텍스트와 탐색용 하이퍼링크가 포함된 보기 좋은 조판 코드가 있음
      http://literateprogramming.com/
    • 맞음, 키보드로 더 쉽게 탐색할 수 있게 만드는 작업이 필요함
      “부모 창”의 기준점으로는 무엇을 상상하는지 궁금함
      특정 창을 앵커로 지정하고 싶은 건지, 아니면 어떤 휴리스틱이 그런 앵커를 찾아주길 원하는 건지 알고 싶음

  • 출시 축하함. 요즘은 완전히 반대 방향으로 가고 있는데, 집중력과 ADHD 성향 때문에 여기저기 뛰어다니다 압도되는 걸 줄이는 데 도움이 됨
    창 하나, 모든 것을 최소화, 그리고 가장 중요하게는 트리 탐색을 없앰
    파일로 이동해야 하면 Intellij의 최근 항목 메뉴를 쓰거나 파일 마커로 점프함
    파일 마커를 기억해야 하고 그곳으로 가려는 의도가 있어야 한다는 뜻임. vim 단축키용으로 IdeaVim 플러그인을 쓰고 있음
    나에게는 이 방식이 프로그래밍을 훨씬 더 집중되고 즐겁게 만듦
    멀티스크린에서 와이드스크린으로 갔다가 다시 단일 화면으로 돌아온 변화의 일부임
    언급한 것 같은 크고 성숙한 코드베이스에서는 LLM으로 길잡이를 삼음

    • 어떻게 쓰는 건가요? 크고 성숙한 코드베이스를 어느 정도로 보는지도 궁금함
      내 경험상 LLM은 파일 하나만 놓고도 실수와 가정을 꽤 많이 함
    • 이해됨. LLM으로 어떻게 길잡이를 삼는지 궁금함
      내 경험으로는 LLM에게 기능 흐름이 어디 있는지 물으면 진입점은 잘 만들어주지만, 세부 사항은 자주 직접 파악해야 했고, 가끔은 관련은 있지만 찾던 것과는 다른 곳을 가리킴

  • 흥미로움. 몇 가지 메모가 있음
    Obsidian에는 “Canvas”라는 비슷한 기능이 있으니 그 작업 흐름을 참고할 만함
    나에게는 독립 실행 도구로는 쓸모가 없고, Idea 플러그인으로 필요함
    레이아웃 만드는 부분이 가장 싫음. Git 패치나 버그 수정을 받아서 그에 맞는 레이아웃을 만들어주는 AI가 있으면 좋겠음
    레이아웃 공유는 아주 쉬워야 함
    Git 이력을 또 다른 차원으로 통합하면 좋겠음. 편집기 안에 diff와 blame 표기까지 들어가면 좋음
    AI 학습에 쓸 수 있는 데이터, 즉 Git 커밋이 있음
    디버깅도 또 다른 차원으로 통합하고, 프로파일러 데이터도 통합하면 좋겠음

    • 데모 영상을 보면 독립 실행형이 아니라 VSCode 안에서 실행되는 것처럼 보임
      거기서 제공되는 건 그대로 얻는 셈임
      Idea 계열 도구를 쓰면 지금은 방법이 없어 보임
    • 도구가 좋아 보이고 업무용으로 써보고 싶음. Android/Kotlin이라서 IDEA 통합에 한 표 더함

  • 이런 걸 오래전부터 써보고 싶었음. 업데이트를 받아볼 방법이 있나요?
    특히 처음 시도할 때라도 AI 기능을 끄는 옵션을 기다리고 있음
    함수 안으로 확대해서 파일의 나머지를 숨기는 기능이 특히 좋음. 이런 걸 원했던 순간이 의외로 많았음
    한 파일 안에서 지금 작업 중인 함수들을 쉽게 옆에 끌어다 놓아, 단일 파일을 가상으로 재배치하는 식으로도 쓸 수 있을 듯함
    편집 인터페이스 외에도 편집기 안에는 시각화 기회가 많다고 봄
    내 코드와 서드파티 의존성의 상호작용, 내 코드의 의존성/호출 그래프 또는 그 일부, 클래스나 모듈 수준의 의존 그래프, 객체 내부 호출 그래프로 드릴다운하는 식의 중첩 호출 그래프가 가능함
    이런 경우 모두 시각화와 편집 사이를 매끄럽게 오갈 수 있는 게, 이 도구가 지향하는 것처럼 보이는 킬러 기능임
    편집기에 그래픽이 들어가기만 해도 코드 변경 빈도 히트맵, 코드 성능 히트맵, 변수 사용 추적 등 더 많은 흥미로운 시각화가 가능함
    https://adamtornhill.com/articles/crimescene/codeascrimescen...
    마지막으로, _The Programmer's Brain_을 읽지 않았다면 이 팟캐스트라도 들어보면 좋겠음
    https://se-radio.net/2021/06/episode-462-felienne-on-the-pro...
    우리 뇌가 작동하는 방식과 관련된 편집 아이디어가 많은데, 아직 편집기에서 잘 지원되는 걸 보지 못했음
    이미 그 방향으로 한 걸음 내디뎠으니 더 많은 기회가 있을지도 모름

    • 아쉽게도 업데이트 신청을 위한 영리한 방법은 아직 만들지 않았음
      가장 좋은 방법을 생각해보겠고, 결국에는 제품 안에서 직접 업데이트를 푸시할 예정임
      지금 막 copilot 옵트아웃을 추가하는 중임
      여기 아이디어들이 좋고, 몇 가지는 함께 논의하고 싶음. 괜찮다면 이메일/DM을 보내겠음
      전반적으로 여러 사람과 대화하고 싶고, feedback@haystackeditor.com 으로 피드백을 받을 수 있음

  • 함수에서 함수로, 파일에서 파일로, 그리고 다시 되돌아가는 탐색 방식이 정말 마음에 듦
    더 유용하려면 브라우저 방문 기록처럼 탐색 기록 창이 있으면 좋겠음
    파일과 함수 사이를 이동할 때 목록을 보여주고, 열려 있는 창들을 힘들게 뒤지지 않아도 앞뒤로 이동하거나 탐색 기록의 임의 위치로 바로 점프할 수 있으면 좋음
    여기서 말하는 탐색 기록은 편집 기록과는 완전히 별개임
    편집 실행 취소/다시 실행이 탐색 기록을 앞뒤로 움직이면 안 되고, 그 반대도 마찬가지임
    물론 탐색 기록을 오가는 키보드 단축키는 있을 수 있음

    • 좋은 아이디어임. 가장 잘 구현하는 방법을 생각해보겠음

  • 멋짐. Code Bubbles와 관련 있음: https://dl.acm.org/doi/abs/10.1145/1753326.1753706

    • 맞음, Bubbles는 훌륭함. 특히 미니맵 개념이 마음에 듦

  • “코드를 저장하거나 로그로 남기지 않습니다. 탐색용 copilot의 입력으로 코드 조각을 Open AI에 보냅니다. 곧 이를 비활성화하는 옵션을 추가하겠습니다.”
    그 옵션이 들어가면 확인해보고 싶음

    • Mac에서 탐색용 copilot 옵트아웃을 추가했음
      명령 팔레트(CMD+SHIFT+P)를 열고 “Opt out of navigational copilot” 명령을 쓰면 됨
      Windows/Linux도 곧 지원 예정임
      존재하지 않는 함수를 호출한다는 진단이 있을 때만 Open AI로 데이터를 보낸다는 점도 참고해주면 좋겠음
    • 같은 반응이었음. 이런 도구 개발을 지원할 의향은 있지만, 좀 더 직접적인 방식이 좋겠음
    • 동의함. 처음부터 옵트인이어야 했음
    • 지금 상태로는 회사에서 시도해보기 어렵겠음

  • 캔버스 기반 편집기(Code Bubbles), 전통적인 탭 기반 편집기(Eclipse), 그리고 내가 설계한 캐러셀 기반 편집기(Patchworks)의 탐색 시간 비교 논문을 냈음
    캔버스는 자유도가 너무 높다는 결과를 얻었음
    https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf

    • 흥미로움. IDE의 공간적 배치를 깊게 생각해본 적이 별로 없었음
      돌아보니 VS Code에서도 탭을 더는 쓰지 않음. 열어둔 파일이 너무 많기 때문임
      그냥 한 번에 파일 하나만 보고, 전환해야 할 때는 Cmd-P로 검색하거나 최근 파일 사이를 이동함
      잘 작동하지만 파일/디렉터리 이름을 항상 머릿속에 담고 있어야 함
    • 논문을 조금만 읽어봤지만, Eclipse 관련 논의를 보면 참가자들이 다중 탭 편집기처럼 쓰기보다 IDE답게 썼다면 훨씬 효율적이었을 것 같음
      메서드를 찾는 일은 알파벳순 개요 뷰가 있으면 훨씬 덜 문제가 되었을 듯함
    • 정말 흥미로움. 그리드와 캔버스 중 고민했지만, 실제로는 탐색이 더 쉽다고 생각해서 캔버스를 택했음
      괜찮다면 이야기해보고 싶고, 이메일을 보내겠음
    • 흥미로움. Patchworks는 내가 Doom Emacs를 설정하는 방식과 어느 정도 닮았음
      여러 작업 공간에 걸쳐 코드 패널 4~6개를 두고, SPC TAB 숫자로 전환함
    • 훌륭한 분석임. 나에게는 캔버스 기반이든 캐러셀 기반이든, 매우 큰 코드베이스를 다룰 때 항상 상당한 양의 인지 데이터를 머릿속에 올려둬야 하는 부담을 덜어줌
      도구를 제대로 쓰려면 충분한 와이드스크린도 사실상 필요함
      핵심은 파일을 세로가 아니라 가로 방향으로 다루는 데 익숙해지는 것임
      이 세로적 사고는 처음 Hello World를 작성하던 방식에 꽤 깊게 뿌리박혀 있음

  • 출시 축하함. 훌륭하고 잘 구현된 도구처럼 보이고, 써보는 게 기대됨
    예전부터 원했고 몇 번 수동으로 만들어보기도 했지만 공유 가능한 형태로는 만들지 못했던 기능이 떠오름. 코드 경로를 하나의 스크립트나 소스 파일로 풀어내는 기능임
    중단점 같은 것을 설정하고 “unravel” 버튼을 누르면, 그 지점까지 일어나는 모든 동작을 보여주는 단일 파일이 남았으면 좋겠음
    이상적으로는 그 파일이 단일 스크립트로 실행 가능하면 더 좋음
    본질적으로 단계별 디버거가 제공하는 뷰와 같지만, 여러 파일과 여러 계층을 참조하는 대신 처음부터 끝까지 하나의 파일 안에서 전부 보고 싶음

    • 왜 필요한가요? 어떤 문제를 해결하려는 건가요? 원하는 결과는 무엇인가요?
      사람들이 요구사항, 매개변수, 결과 대신 구체적인 구현 세부에 집중하면 많은 것이 전달 과정에서 사라진다고 봄
      왜 이 구현을 원하는지, 어떤 기능이나 목적을 수행해야 하는지 궁금함
답변달기