Junie Codes (AsciiDoc 지원)

다른 언어: English Español Português 中文

지난 주에 Duplicate Finder에 대해 Foojay Podcast 에 출연했습니다. 저는 프랑크 델포트가 주최한 이 팟캐스트에서 다른 포맷들에 대한 지원을 구현하는 것에 대해 간략하게 언급했습니다. 그리고 프랑크가 제가 Azul에서의 기술 문서 작업에 유용할 수 있는 AsciiDoc를 추가 계획이 있는지 물었습니다.

우리는 이 지원을 곧 추가하기로 합의했습니다. 그와 동시에 저는 현재 초기 접근 단계에 있는 JetBrains의 새로운 코딩 에이전트인 Junie에 대한 접근 권한을 받았습니다. 잠시 후, 이 기회를 잡아서 실전에서 테스트해 보는 것을 생각했습니다. 코딩 에이전트는 일반적인 작업을 잘 해결하는 것으로 알려져 있습니다. 그러나 잘 알려진 프레임워크를 기반으로 하지 않고 일반적인 도메인 외부에 있는 프로젝트는 어떨까요? 저는 조금은 코딩 에이전트에 대한 회의론자입니다.

다음은 제가 Junie를 사용해 본 결과입니다.

설치 및 개요

Junie는 IntelliJ IDEA 플러그인입니다. UI는 JetBrains AI Assistant 또는 GitHub Copilot와 유사한 세로형 도구 창을 사용하고 있습니다. 이것이 어떤 것인지를 보여주기 위해 스크린샷을 첨부하였습니다:

Junie 도구 창에 프롬프트 입력란, 첨부 파일 및 'Brave Mode' 버튼 표시

최소한의 디자인은 프롬프트 필드, 컨텍스트를 추가하는 버튼, 그리고 Brave Mode라는 제목의 체크박스만을 포함합니다. 이 옵션은 Junie가 귀하와 이중 확인 없이 명령을 실행할 수 있는지를 제어합니다. 저는 아직 그렇게 용감하지 않아서 다음 번에 시도해보려고 합니다.

요건 설정

Junie에 코딩 작업을 부여하기 전에, AsciiDoctor 안내서의 주제 를 다운로드하고 Junie가 테스트 데이터 및 참조로 사용할 수 있도록 src/test/resources/에 위치시켰습니다.

'AsciiDoc 색인자를 구현하시오. src/test/resources/asciidoc-recommended-practices.adoc에 샘플 문서를 넣었습니다. 이것은 색인자가 올바르게 구문 분석해야 하는 테스트 데이터입니다.색인자 클래스에서 분석된 요소를 순서가 있는 컬렉션에 저장하여 반환하기 전에 중단점을 설정하고 청크 목록을 검토할 수 있습니다'라는 프롬프트

디버깅을 위해, Junie에게 변환된 블록들을 별도의 컬렉션에 추가하도록 요청했습니다. 이는 실제 인덱스가 다양한 레벨로 구성되어 있어서 디버깅하는 것이 불편하기 때문입니다. 간단하게 보려면, 런타임에서 결과를 확인해야 한다면, 변환된 요소들을 평평한 구조로 보고 싶습니다.

‘코딩’

메시지를 입력하면, Junie는 작업을 작은 항목들로 분해하고 이를 실행합니다. AsciiDoc 지원을 추가하기 위해 다음과 같은 계획을 세웠습니다:

AsciiDoc 색인기 구현에 대한 초기 계획

각 항목을 실행하면서 Junie는 변경 사항의 요약을 알려줍니다. 전체 워크플로우가 완료될 때까지 기다릴 필요 없이 바로 검토할 수 있습니다:

Junie 도구 창에 몇 가지 변경 사항이 표시됩니다. 예를 들어 'build.gradle.kts +1 -3'과 변경 사항에 대한 설명

파일명을 클릭하면, 매우 유사한 방식으로 Git 변경 사항을 보는 것처럼 IntelliJ IDEA의 차이 보기를 이용해서 변경 사항을 확인할 수 있습니다.

IntelliJ IDEA의 diff 도구가 추가, 삭제 및 수정된 줄을 보여줍니다

모든 항목이 완료된 후에, Junie는 테스트를 작성하고 실행하도록 요청합니다:

Junie는 변경 사항을 테스트하는 방법을 논리적으로 생각한 뒤 테스트를 만들고 실행을 요청합니다

이 작업에서는 Junie에게 테스트 데이터를 주고 명시적으로 테스트를 요청했습니다. 그러나 Junie는 기본적으로 테스트 데이터와 함께 테스트를 생성하는 것 같습니다. 테스트를 언급하지 않고 작업을 실행하면서 실험을 해 보니, Junie는 그럼에도 불구하고 테스트를 생성했습니다. 테스트를 실행하기 위해 Junie는 IntelliJ IDEA의 실행 (Run) 도구 창을 사용합니다.

성공적인 테스트 실행 후에, Junie는 작업 내용에 대한 요약을 제공합니다:

Junie는 변경 사항 요약과 변경된 파일 목록을 함께 제공합니다

코드 품질

코드와 테스트를 검토했을 때, 잘 구성되어 있고 깔끔하다는 것을 발견했습니다. 저가 정말 마음에 들었던 부분은, Junie는 프로젝트를 컴파일하는데 필요한 코드 뿐만 아니라 작업 문맥에서 의미 있는 다른 변경 사항도 추가로 도입했다는 것입니다.

IntelliJ IDEA의 diff는 관련 클래스의 변경 사항을 보여줍니다

예를 들어, 새로운 인덱서가 커맨드 라인 인수에서 노출되어야 한다는 것을 언급하는 것을 잊어버렸습니다. 이 실수는 컴파일 오류를 일으키지는 않지만, 최종 사용자가 기능에 접근할 수 없다면 의미가 없습니다. Junie는 이것을 인식하고, 설명과 함께 해당 커맨드 라인 옵션을 추가했습니다. 또한 팩토리 메서드를 올바르게 업데이트하여, 클라이언트 코드가 새 인덱서의 인스턴스를 얻을 수 있도록 했습니다. 동시에 불필요한 변경 사항은 없었어서 매우 좋았습니다!

지금까지는 모든 것이 좋아 보입니다. 그러나 아직 해야 할 작업이 더 있는 것 같습니다.

구현 수정

코딩 에이전트가 아직 완전히 자율적이지 않은 부분 중 하나는 런타임에서 잠재적인 문제를 식별하는 것입니다. 기술적으로는 구현이 옳고, 모든 테스트를 통과합니다. 파싱 결과가 Evaluate 대화 상자에서 확인할 수 있듯이 일관성을 유지합니다.

'Evaluate' 대화 상자에 분석된 블록 목록이 표시됩니다

모든 것은 잘 보입니다, 단지 한 파일을 처리하는 데 놀랍도록 오래 걸리는 것입니다. 이를 살펴보니, 약 35개의 파일 묶음을 파싱하는 것은 항상 OutOfMemoryError 로 실패한다는 것을 발견했습니다. 구현을 분석하면서 비효율적인 루프나 유출되는 자원과 같은 분명한 결함을 찾을 수 없었습니다. “-XX:+HeapDumpOnOutOfMemoryError”를 이용해서 앱을 실행하면 힙 덤프를 얻을 수 있는데, 이를 통해 매우 큰 유지 크기를 가진 수많은 JRuby 유형을 찾을 수 있었습니다. 이것은 라이브러리가 문제의 원인일 가능성을 시사합니다.

물론 이 추측이 정확하지 않을 수도 있어서, 이는 프로파일링 (또는 문서 읽기)을 위한 놀라운 기회를 제공합니다. 어쨌든, 간단한 Kotlin 구현을 위한 JRuby 종속성을 변경하면 속도가 상당히 향상될 가능성이 큽니다. 그래서 저는 Junie에게 사용자 정의 파서를 이용해서 구현을 재작성하라고 요청했습니다.

새로운 작업을 시작하는 대신에, Follow up 프롬프트를 이용했습니다:

'asciidoctorj 라이브러리를 집에서 만든 간단한 구현으로 교체할 수 있습니까? 동일한 테스트를 통과해야 합니다'라는 후속 프롬프트

결과

Junie는 요청대로 구현을 수정했습니다. 제가 AsciiDoc 포맷에 대해 매우 익숙하지 않지만, 첫 눈에 파싱이 대체로 올바른 것으로 보입니다. preamble의 파싱을 개선할 여지가 있고, 아마도 다른 무언가가 있을 수도 있지만, 그렇게 해도 일이 되고 있습니다.

업데이트된 Duplicate Finder를 AsciiDoctor 자체의 도움말에서 중복을 발견하는 데 사용했습니다! 분석은 제 노트북에서 350 밀리초가 걸렸습니다:

중복 찾기 UI가 AsciiDoctor 도움말에서 중복된 항목을 보여줍니다

커밋된 변경 사항을 가진 프로젝트는 제 GitHub에 있습니다. 앱의 새로운 버전을 설치하려면, Duplicate Finder 페이지에 지시사항과 다운로드 링크가 있습니다. 전반적으로, 구현이 완벽하지 않을 수도 있고, 분명히 더 철저한 확인이 필요하지만, 5분 만에 이렇게 많은 일을 할 수 있다는 것에 대해 매우 놀랐습니다.

Junie를 직접 사용해 보고 싶다면, EAP여기에서 가입할 수 있습니다.

all posts ->