[Lobsters 요약] LLM 기반 개발 워크플로우: 생산성 향상과 주의할 점
2
설명
LLM(거대 언어 모델)은 개발 과정에서 마법처럼 느껴질 수 있지만, 때로는 예상치 못한 오류를 발생시키기도 합니다.
개발자는 LLM의 강점과 약점을 파악하고, 이를 효과적으로 활용하기 위한 실질적인 워크플로우를 구축해야 합니다.
본 글은 2026년 8월 17일에 공개된 내용을 바탕으로, LLM을 활용한 개발 생산성 향상 방안과 주의점을 상세히 다룹니다.
### 배경 설명
최근 몇 년간 LLM은 소프트웨어 개발 분야에서 점차 중요한 도구로 자리 잡고 있습니다. 특히 2026년 현재, LLM은 코드 생성, 보일러플레이트 작성, 탐색적 작업 등 다양한 영역에서 개발자의 생산성을 크게 향상시킬 잠재력을 보여주고 있습니다. 개발자들은 LLM을 통해 이전에는 시도하기 어려웠던 규모의 프로젝트를 수행할 수 있게 되었으며, 이는 개발 방식 자체의 변화를 예고하고 있습니다. LLM 기반 개발은 기존의 단계별 코드 구축 방식과는 달리, 초기 결과물을 도출한 후 이를 다듬어 나가는 '에이전트 루프' 또는 '유전 알고리즘'과 유사한 접근 방식을 취합니다. 이는 모델이 초기 결과물을 생성하고, 테스트를 통해 피드백을 받아 반복적으로 개선해 나가는 과정입니다. 이러한 방식은 인간이 비선형적인 문제 해결을 위해 반복적으로 코드를 수정하는 과정과도 맥을 같이 합니다. LLM은 이러한 반복 과정을 인간보다 훨씬 빠르게 수행할 수 있다는 점에서 주목받고 있습니다.
### LLM에 위임할 작업과 주의할 점
LLM은 방대한 공개 코드 데이터셋으로 학습되었기 때문에, 수없이 반복된 일반적인 작업, 즉 보일러플레이트 코드 작성에 탁월합니다. 예를 들어, 샘플 JSON 응답을 기반으로 서비스 엔드포인트를 생성하거나, 여러 API 엔드포인트를 활용하여 UI를 구축하는 작업은 LLM이 높은 정확도로 수행할 수 있습니다. 또한, 특정 호출 그래프를 추적하여 서비스 엔드포인트의 구현 방식이나 필요한 매개변수를 파악하는 탐색적 작업에도 매우 유용합니다. 익숙하지 않은 언어로 작업할 때, LLM은 개념적으로 원하는 로직을 표현하고 해당 언어의 관용적인 구문을 사용하여 코드를 작성하는 데 도움을 줄 수 있습니다. 예를 들어, 2026년 8월 17일의 글 작성자는 DeepSeek를 활용하여 10년 이상 사용하지 않은 JavaScript 프로젝트를 능숙하게 처리할 수 있었습니다. 하지만 LLM은 프로젝트의 특정 맥락이나 미묘한 차이를 이해하는 데 어려움을 겪을 수 있습니다. Chez Scheme 런타임 환경과 같은 구체적인 제약 조건을 명확히 제시하지 않으면, LLM은 잘못된 도구 체인을 선택하거나 비효율적인 구현을 제안할 수 있습니다. 또한, 표면적으로는 올바르게 보이지만 구조적으로 잘못된 '순진한 구현'의 함정에 빠질 수 있습니다. 예를 들어, 문자열 메서드 호출을 일반적인 디스패치 테이블로 라우팅하거나, 시퀀스의 `count` 연산을 비효율적으로 구현하는 경우가 이에 해당합니다. 이러한 문제를 방지하기 위해서는 명확한 제약 조건을 제시하고, 구조적인 수준에서 원하는 바를 구체적으로 명시해야 합니다.
### LLM 활용을 위한 실질적인 워크플로우
LLM을 효과적으로 사용하기 위해서는 작업 시작 전에 명확한 계획 수립이 필수적입니다. 목표하는 바, 사용할 알고리즘, 기존 아키텍처와의 통합 방안 등을 구체적으로 정의해야 합니다. 계획 단계에서는 LLM에게 요구사항과 목표를 제시하고, Markdown 형식으로 단계별 계획을 생성하도록 요청할 수 있습니다. 더 나아가, Mermaid.js 다이어그램 생성을 요청하여 시각적으로 흐름을 검토하고 수정하는 것이 효과적입니다. 다이어그램 검토 후, LLM에게 각 단계를 독립적인 작업으로 분할하고, 각 작업에 대한 브랜치를 생성하며 Pull Request를 제출하도록 지시할 수 있습니다. 이를 통해 코드 변경의 범위를 명확히 인지하고 검토 과정을 용이하게 할 수 있습니다. 특정 접근 방식에 대한 확신이 없을 때는 LLM에게 관련 연구 논문을 조사하도록 요청하여 더 나은 아이디어를 얻을 수 있습니다. 또한, 낮은 결합도를 가진 깨끗한 아키텍처는 LLM이 작은 단위의 작업에 집중하도록 돕고, 결과물 검토를 용이하게 합니다. 함수형 프로그래밍 스타일은 컨텍스트 격리와 명시적인 상태 전달에 중점을 두어 LLM 활용에 유리합니다. Git은 '퀵 세이브'와 같이 활용하여, 테스트가 통과하고 코드가 의도대로 작동하는 안정적인 상태가 될 때마다 커밋하는 것이 중요합니다. 이를 통해 LLM이 실험적인 시도를 하더라도 문제가 발생했을 때 이전 상태로 쉽게 되돌릴 수 있습니다.
### 테스트와 Git을 활용한 안정성 확보
테스트는 LLM과의 작업에서 궁극적인 요구사항 문서 역할을 합니다. 원하는 기능을 테스트 코드로 먼저 정의하고, 테스트 주도 개발(TDD) 방식으로 LLM이 테스트를 통과하도록 유도하는 것이 효과적입니다. LLM은 테스트 실패를 분석하고 코드를 수정하는 데 능숙하며, 테스트는 코드의 기능적 정확성을 보장하는 계약 역할을 합니다. 이는 마치 유전 알고리즘의 선택 압력과 같습니다. 테스트가 없다면 새로운 기능을 추가하면서 기존 기능을 의도치 않게 망가뜨릴 위험이 있습니다. 컴포넌트 기능 및 통합 테스트는 가장 가치 있는 테스트 유형이며, Playwright와 같은 도구를 사용한 End-to-End 테스트는 웹 애플리케이션의 전체 워크플로우를 검증하는 데 유용합니다. 또한, 성능 특성을 고려하여 CPU 및 메모리 사용량과 같은 벤치마킹 스위트를 구축하는 것이 중요합니다. 예를 들어, 2026년 8월 17일의 글 작성자는 Jolt 개발 과정에서 벤치마킹 스위트를 통해 개발 방향을 설정했습니다. Git은 안전망 역할을 합니다. LLM이 안정적인 상태에 도달할 때마다 커밋하면, 잘못된 시도나 복잡한 리팩토링이 실패했을 때 쉽게 이전 상태로 되돌릴 수 있습니다. LLM이 첫 시도에 문제를 해결하지 못하면, 이후에도 근본적인 문제 해결보다는 임시방편적인 수정이 이루어질 가능성이 높습니다. 이러한 경우, 문제 정의를 재검토하고 처음부터 다시 시작하는 것이 좋습니다. LLM은 코드베이스 탐색 비용을 크게 낮추어 줍니다. 예를 들어, Jolt 프로젝트 초기에는 Janet 런타임을 사용했지만, 생성적 가비지 컬렉션의 부재가 지속적인 데이터 구조에서 발생하는 짧은 수명의 객체와 잘 맞지 않음을 깨닫고 Chez Scheme으로 전환했습니다. 이러한 탐색 과정은 LLM의 도움으로 몇 주에서 며칠로 단축될 수 있었습니다.
### 하네스(Harness)의 중요성과 구조화된 제어
다양한 에이전트 하네스(Agent Harness)가 존재하며, 각각 다른 사용 사례에 최적화되어 있습니다. 중요한 것은 하네스가 모델의 기대치를 충족하고 특정 프로젝트에 맞게 워크플로우를 사용자 정의할 수 있는 유연성을 제공해야 한다는 것입니다. 2026년 8월 17일의 글 작성자는 DeepSeek 및 GLM과 같은 모델의 에이전트 루프 내 동작을 관찰하고, Dirge라는 자체 하네스를 개발했습니다. 이 하네스는 기존 도구의 검증된 기법을 통합하고, Janet을 사용하여 Pi와 유사한 플러그인 시스템을 제공합니다. 프로젝트별 `.dirge` 폴더에 사용자 정의 플러그인을 배치하여 하네스가 프로젝트와 함께 발전하도록 설계했습니다. 또한, 모델이 코드에서 괄호 불일치와 같은 문제를 일으킬 때, 이를 기계적으로 수정하는 기능을 하네스 내에 구현하여 토큰 낭비를 줄였습니다. Markdown 파일 기반의 상태 추적은 불안정할 수 있으므로, SQLite를 데이터 저장소로 사용하여 프로젝트 메모리로 활용했습니다. 이를 통해 모델이 현재 작업 중인 작업을 추적하고, 더 큰 기능에 집중하도록 돕습니다. 작업 완료 후에는 별도의 비평가(Critic) 역할을 통해 변경 사항을 검토하고 피드백을 제공하여, 불완전한 솔루션이 배포되는 것을 방지합니다. 'Behavior Trees Enable Structured Programming of Language Model Agents'와 같은 논문에서 아이디어를 얻어, 언어 모델을 결정론적 제어 구조의 리프 노드로 활용하는 방식을 통합했습니다. 이는 모델을 전체 에이전트로 취급하는 대신, 동작을 생성하는 기본 요소로 간주하고, 고전적인 제어 구조와 조합하는 방식입니다. 최종 검증 게이트, 비평가, 코드 검토자는 모델이 통과해야 하는 일련의 결정론적 검사로 구성됩니다. 실패 시에는 재시도 폴백 노드를 사용하고, Publish State Guard와 같은 메커니즘으로 구조적인 안전 제약을 적용합니다. 이러한 구조화된 접근 방식을 통해 로컬 모델로도 상당히 복잡한 작업을 유능하게 해결할 수 있습니다.
### 가치와 인사이트
LLM은 개발자의 생산성을 극대화하는 강력한 도구이지만, 맹신은 금물입니다. LLM은 반복적인 작업, 보일러플레이트 코드 생성, 익숙하지 않은 언어의 구문 처리 등에 탁월한 성능을 보입니다. 그러나 프로젝트의 특정 맥락, 미묘한 제약 조건, 복잡한 알고리즘 설계에는 여전히 인간 개발자의 깊은 이해와 명확한 지시가 필요합니다. 테스트를 계약으로 삼고, Git을 안전망으로 활용하며, 구조화된 워크플로우와 하네스를 구축하는 것이 LLM의 잠재력을 최대한 끌어내고 오류를 최소화하는 핵심입니다. LLM은 개발자의 사고를 대체하는 것이 아니라, 개발자가 더 높은 수준의 문제 해결과 설계에 집중할 수 있도록 돕는 '도구'로서의 역할을 수행해야 합니다. 2026년 8월 17일의 글 작성자는 약 20년간의 Clojure 경험을 바탕으로 LLM을 활용하여 Clojure 컴파일러를 개발할 수 있었으며, 이는 LLM이 기존 전문성을 증폭시키는 도구임을 보여줍니다.
### 기술·메타
- LLM: DeepSeek, GLM
- 언어: JavaScript, Clojure, Chez Scheme, Janet
- 도구: Mermaid.js, Playwright, Git
- 개념: 에이전트 루프, 유전 알고리즘, 테스트 주도 개발(TDD), Behavior Trees
- 데이터 저장소: SQLite
### 향후 전망
LLM 기반 개발 도구는 지속적으로 발전할 것이며, 더 정교한 코드 생성 능력과 맥락 이해 능력을 갖추게 될 것입니다. 하지만 동시에, LLM의 한계를 극복하기 위한 '하네스'와 '워크플로우'의 중요성 또한 더욱 커질 것입니다. 개발자는 LLM과의 상호작용을 최적화하는 방법을 끊임없이 탐구해야 하며, 이는 단순히 코드를 생성하는 것을 넘어, LLM을 효과적으로 제어하고 검증하는 시스템 구축으로 이어질 것입니다. 경쟁은 더욱 치열해질 것이며, 특정 LLM 모델이나 하네스 솔루션이 시장을 주도할 가능성도 있습니다. 또한, LLM이 개발자의 전문성을 대체하기보다는, 특정 도메인 지식을 가진 개발자가 LLM을 활용하여 혁신을 가속화하는 형태로 발전할 것으로 예상됩니다. 커뮤니티는 LLM 기반 개발의 모범 사례, 유용한 도구, 그리고 잠재적 위험에 대한 정보를 공유하며 함께 발전해 나갈 것입니다.
📝 원문 및 참고
- Source: Lobsters
- 토론(Lobsters): [lobste.rs](https://lobste.rs/s/bx8zu1/practical_workflow_for_llm_assisted)
- 원문: [링크 열기](https://yogthos.net/posts/2026-08-17-llm-workflow.html)
---
출처: Lobsters · [원문 링크](https://yogthos.net/posts/2026-08-17-llm-workflow.html)
신고 · 불법·유해·아동 안전(CSAE) 관련 콘텐츠
댓글 0
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.