OpenCode 기여와 확장 개발 완벽 가이드

오픈소스 프로젝트 OpenCode에 기여하고 확장 기능을 개발하는 방법을 알아봅니다. CONTRIBUTING.md 가이드부터 PR 제출까지 실무에서 바로 활용할 수 있는 내용을 담았습니다.

---

목차

1. CONTRIBUTING.md_가이드
2. 개발_환경_설정과_디버깅
3. 새로운_도구_추가하기
4. 커스텀_에이전트_개발
5. LSP와_포맷터_추가하기
6. PR_제출과_코드_리뷰
7. 자동완성, 오류 표시 확인

---

1. CONTRIBUTING.md 가이드

입사 6개월 차 김개발 씨는 평소 자주 사용하던 오픈소스 도구에서 작은 버그를 발견했습니다. "이 정도는 내가 직접 고쳐서 기여해볼 수 있지 않을까?" 하는 생각이 들었지만, 어디서부터 시작해야 할지 막막했습니다.

그때 선배 박시니어 씨가 말했습니다. "CONTRIBUTING.md부터 읽어봐.

모든 답이 거기 있어."

CONTRIBUTING.md는 오픈소스 프로젝트에 기여하려는 개발자를 위한 안내서입니다. 마치 새로운 회사에 입사했을 때 받는 신입사원 가이드북과 같습니다.

이 문서를 제대로 읽으면 프로젝트의 규칙, 코드 스타일, 기여 절차를 한눈에 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# OpenCode CONTRIBUTING.md 주요 구조 예시

## 기여 전 준비사항
# 1. 저장소 포크하기
git fork https://github.com/opencode/opencode

# 2. 로컬에 클론
git clone https://github.com/your-username/opencode
cd opencode

# 3. 업스트림 원격 저장소 추가
git remote add upstream https://github.com/opencode/opencode

# 4. 의존성 설치
npm install

# 5. 개발 브랜치 생성 (컨벤션 준수)
git checkout -b feat/add-new-tool

김개발 씨는 입사 6개월 차 주니어 개발자입니다. 평소 업무에서 자주 사용하던 오픈소스 CLI 도구가 있었는데, 어느 날 사소한 버그를 발견했습니다.

"이 정도면 내가 직접 고쳐볼 수 있지 않을까?"라는 생각이 들었습니다. 하지만 막상 GitHub 저장소를 열어보니 수백 개의 파일과 복잡한 디렉토리 구조가 눈앞에 펼쳐졌습니다.

어디서부터 손을 대야 할지, 어떤 규칙을 따라야 할지 전혀 감이 잡히지 않았습니다. 그때 옆자리 선배 박시니어 씨가 다가와 말했습니다.

"오픈소스에 기여하고 싶으면 CONTRIBUTING.md부터 읽어봐. 거기에 모든 답이 있어." 그렇다면 CONTRIBUTING.md란 정확히 무엇일까요?

쉽게 비유하자면, CONTRIBUTING.md는 마치 새로운 회사에 입사했을 때 받는 신입사원 가이드북과 같습니다. 회사의 문화, 업무 프로세스, 보고 체계 등이 담겨 있듯이, CONTRIBUTING.md에는 프로젝트의 코드 스타일, 브랜치 명명 규칙, PR 작성법 등이 담겨 있습니다.

OpenCode와 같은 프로젝트에서 CONTRIBUTING.md는 특히 중요합니다. 전 세계 수많은 개발자가 동시에 기여하기 때문에, 일관된 규칙 없이는 코드베이스가 금세 엉망이 되어버릴 것입니다.

CONTRIBUTING.md에서 가장 먼저 확인해야 할 것은 개발 환경 설정 방법입니다. 어떤 버전의 Node.js를 사용해야 하는지, 어떤 패키지 매니저를 써야 하는지가 명시되어 있습니다.

다음으로 브랜치 명명 규칙을 확인해야 합니다. 대부분의 프로젝트는 feat/, fix/, docs/ 같은 접두사를 사용합니다.

이 규칙을 따르지 않으면 PR이 자동으로 거절될 수도 있습니다. 커밋 메시지 컨벤션도 중요합니다.

Conventional Commits 형식을 따르는 프로젝트가 많습니다. "feat: add new authentication method"처럼 타입과 설명을 명확히 구분해야 합니다.

코드 스타일 가이드도 빠뜨릴 수 없습니다. ESLint, Prettier 설정이 이미 되어 있는 경우가 많으므로, 커밋 전에 린트 검사를 통과하는지 확인해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. CONTRIBUTING.md를 꼼꼼히 읽은 김개발 씨는 자신감이 생겼습니다.

"생각보다 어렵지 않네요. 규칙만 잘 따르면 되는 거잖아요!" CONTRIBUTING.md를 제대로 읽으면 불필요한 시행착오를 줄이고, 메인테이너에게 좋은 인상을 줄 수 있습니다.

오픈소스 기여의 첫걸음은 바로 이 문서를 읽는 것에서 시작됩니다.

실전 팁

💡 - PR을 올리기 전에 CONTRIBUTING.md를 최소 두 번은 정독하세요

• 기존 PR들을 살펴보며 실제로 어떤 형식으로 기여가 이루어지는지 파악하세요
• 모르는 부분이 있으면 Issue를 통해 질문하는 것을 두려워하지 마세요

---

2. 개발 환경 설정과 디버깅

CONTRIBUTING.md를 읽은 김개발 씨는 본격적으로 개발 환경을 설정하기 시작했습니다. 그런데 npm install을 실행하자마자 빨간색 에러 메시지가 화면을 가득 채웠습니다.

"이게 뭐지?" 당황한 김개발 씨에게 박시니어 씨가 말했습니다. "오픈소스 개발 환경 설정은 생각보다 까다로워.

차근차근 해보자."

개발 환경 설정은 오픈소스 기여의 실질적인 첫 단계입니다. 마치 요리를 시작하기 전에 재료와 도구를 준비하는 것과 같습니다.

환경이 제대로 갖춰지지 않으면 코드 한 줄도 테스트할 수 없습니다. 디버깅 환경까지 완벽히 설정해야 효율적인 개발이 가능합니다.

다음 코드를 살펴봅시다.

// launch.json - VS Code 디버깅 설정
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug OpenCode",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/src/index.ts",
      "preLaunchTask": "npm: build",
      "sourceMaps": true,
      "outFiles": ["${workspaceFolder}/dist/**/*.js"],
      "env": {
        "NODE_ENV": "development",
        "DEBUG": "opencode:*"
      }
    }
  ]
}

김개발 씨는 CONTRIBUTING.md를 읽고 자신감에 차서 터미널을 열었습니다. git clone으로 저장소를 받아오고, npm install을 실행했습니다.

그런데 갑자기 화면이 빨간색으로 물들었습니다. "Node.js 버전이 맞지 않습니다"라는 에러 메시지였습니다.

프로젝트는 Node.js 20을 요구하는데, 김개발 씨의 컴퓨터에는 Node.js 18이 설치되어 있었던 것입니다. 박시니어 씨가 다가와 말했습니다.

"오픈소스 프로젝트마다 요구하는 Node.js 버전이 달라. nvm이나 fnm 같은 버전 관리 도구를 써야 해." 그렇다면 개발 환경 설정은 어떻게 진행해야 할까요?

쉽게 비유하자면, 개발 환경 설정은 마치 요리를 시작하기 전 주방을 정리하는 것과 같습니다. 칼, 도마, 냄비가 제자리에 있어야 요리를 시작할 수 있듯이, 올바른 Node.js 버전, 패키지 매니저, IDE 설정이 갖춰져야 개발을 시작할 수 있습니다.

먼저 .nvmrc 파일을 확인합니다. 대부분의 프로젝트는 이 파일에 필요한 Node.js 버전을 명시해 둡니다.

nvm use 명령어 하나면 자동으로 맞는 버전으로 전환됩니다. 다음으로 패키지 설치를 진행합니다.

OpenCode 같은 TypeScript 프로젝트는 의존성이 많아서 설치에 시간이 걸릴 수 있습니다. 이때 pnpm을 사용하면 속도와 디스크 공간 모두 절약할 수 있습니다.

환경 설정이 끝났다면 이제 디버깅 환경을 구축해야 합니다. console.log로 디버깅하는 것은 비효율적입니다.

VS Code의 내장 디버거를 활용하면 브레이크포인트를 걸고 변수 값을 실시간으로 확인할 수 있습니다. 위의 launch.json 설정을 살펴보겠습니다.

program 항목에 진입점 파일을 지정하고, sourceMaps를 true로 설정하면 TypeScript 코드에서 직접 디버깅이 가능합니다. DEBUG 환경 변수도 유용합니다.

많은 Node.js 라이브러리가 debug 모듈을 사용하는데, DEBUG=opencode:*로 설정하면 내부 로그를 모두 볼 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 OpenCode에서 특정 명령어가 제대로 동작하지 않는 버그를 발견했다고 가정해봅시다. 디버거로 해당 명령어의 핸들러 함수에 브레이크포인트를 걸고, 입력값이 어떻게 처리되는지 단계별로 추적할 수 있습니다.

주의할 점도 있습니다. 디버깅 설정 파일을 실수로 커밋하면 안 됩니다.

.vscode/launch.json은 보통 .gitignore에 포함되어 있지만, 확인하는 습관을 들이는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Node.js 버전을 맞추고 디버거까지 설정한 김개발 씨는 드디어 개발을 시작할 준비가 되었습니다. "이제 진짜 코드를 만져볼 수 있겠네요!"

실전 팁

💡 - nvm use 명령어를 터미널 시작 시 자동 실행되도록 설정하면 편리합니다

• VS Code의 Debug Console에서 실시간으로 표현식을 평가해볼 수 있습니다
• 테스트 파일에서 디버깅할 때는 Jest Runner 확장을 활용하세요

---

3. 새로운 도구 추가하기

개발 환경 설정을 마친 김개발 씨는 이제 본격적인 기능 개발에 도전하기로 했습니다. OpenCode에 새로운 도구를 추가해보고 싶었습니다.

"새 도구를 만들려면 어디서부터 시작해야 하죠?" 박시니어 씨가 tools 디렉토리를 가리키며 말했습니다. "기존 도구 코드를 보면 패턴이 보일 거야."

새로운 도구 추가는 OpenCode 같은 AI 에이전트 프레임워크에서 가장 흔한 기여 유형입니다. 마치 레고 블록을 조립하듯이, 정해진 인터페이스만 구현하면 새로운 기능을 추가할 수 있습니다.

도구는 에이전트가 실제로 작업을 수행하는 손과 발 역할을 합니다.

다음 코드를 살펴봅시다.

// tools/file-search.ts - 새로운 도구 구현 예시
import { Tool, ToolResult } from '../core/types';

export const fileSearchTool: Tool = {
  name: 'file_search',
  description: '프로젝트 내에서 파일을 검색합니다',
  // 파라미터 스키마 정의
  parameters: {
    type: 'object',
    properties: {
      pattern: {
        type: 'string',
        description: '검색할 파일 패턴 (glob 형식)'
      },
      directory: {
        type: 'string',
        description: '검색을 시작할 디렉토리'
      }
    },
    required: ['pattern']
  },
  // 실제 실행 로직
  async execute(params): Promise<ToolResult> {
    const { pattern, directory = '.' } = params;
    const files = await glob(pattern, { cwd: directory });
    return { success: true, data: files };
  }
};

김개발 씨는 개발 환경 설정을 마치고 한숨 돌렸습니다. 이제 진짜 코드를 작성할 시간입니다.

평소 OpenCode를 사용하면서 "이런 도구가 있으면 좋겠다"고 생각했던 기능이 있었습니다. 바로 프로젝트 내 파일 검색 도구였습니다.

하지만 막상 코드베이스를 열어보니 어디서부터 시작해야 할지 막막했습니다. 수십 개의 파일이 있었고, 구조도 복잡해 보였습니다.

박시니어 씨가 조언했습니다. "새로운 기능을 추가할 때는 기존 코드를 먼저 분석해봐.

패턴이 보이면 그대로 따라하면 돼." 그렇다면 **도구(Tool)**란 정확히 무엇일까요? 쉽게 비유하자면, 도구는 마치 스위스 아미 나이프의 각 기능과 같습니다.

칼, 가위, 병따개가 각각 다른 역할을 하듯이, AI 에이전트의 각 도구도 파일 읽기, 코드 실행, 웹 검색 등 특정 역할을 담당합니다. OpenCode에서 도구를 추가하려면 Tool 인터페이스를 구현해야 합니다.

이 인터페이스는 네 가지 핵심 요소로 구성됩니다. 첫 번째는 name입니다.

도구의 고유 식별자로, 에이전트가 이 이름으로 도구를 호출합니다. 보통 snake_case 형식을 사용합니다.

두 번째는 description입니다. 에이전트가 이 설명을 읽고 언제 이 도구를 사용해야 할지 판단합니다.

따라서 명확하고 구체적으로 작성해야 합니다. 세 번째는 parameters입니다.

JSON Schema 형식으로 입력 파라미터를 정의합니다. 어떤 값이 필수이고, 어떤 값이 선택인지 명시해야 합니다.

네 번째는 execute 함수입니다. 실제 작업을 수행하는 비동기 함수로, 파라미터를 받아서 결과를 반환합니다.

위의 코드를 살펴보면, fileSearchTool은 glob 패턴을 받아서 매칭되는 파일 목록을 반환합니다. directory 파라미터는 선택사항이므로 required 배열에 포함되지 않았습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 대규모 모노레포에서 특정 패턴의 설정 파일을 모두 찾아야 하는 상황을 가정해봅시다.

file_search 도구에 "**/tsconfig.json" 패턴을 전달하면 모든 tsconfig 파일을 한 번에 찾을 수 있습니다. 주의할 점도 있습니다.

도구가 시스템에 영향을 미치는 작업(파일 삭제, 프로세스 종료 등)을 수행한다면, 반드시 확인 절차를 거쳐야 합니다. 사용자 동의 없이 위험한 작업을 실행하면 안 됩니다.

또한 에러 처리를 꼼꼼히 해야 합니다. execute 함수 내에서 예외가 발생하면 적절한 에러 메시지와 함께 실패 결과를 반환해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 기존 도구 코드를 분석한 김개발 씨는 패턴을 파악했습니다.

"아, 이 형식만 따르면 되는 거구나!" 자신만의 첫 번째 도구를 완성한 김개발 씨의 얼굴에 뿌듯한 미소가 번졌습니다.

실전 팁

💡 - description은 에이전트의 판단에 직접 영향을 미치므로 신중하게 작성하세요

• 도구 테스트 코드를 먼저 작성하고 구현하는 TDD 방식을 권장합니다
• 기존 도구와 기능이 겹치지 않는지 먼저 확인하세요

---

4. 커스텀 에이전트 개발

도구 추가에 성공한 김개발 씨는 욕심이 생겼습니다. "도구를 조합해서 나만의 에이전트를 만들 수 있다면 얼마나 좋을까?" 박시니어 씨가 눈을 빛내며 말했습니다.

"바로 그게 OpenCode의 진짜 힘이야. 커스텀 에이전트를 만들어보자."

커스텀 에이전트는 특정 목적에 최적화된 AI 어시스턴트입니다. 마치 전문 요리사가 특정 요리에 특화되어 있듯이, 커스텀 에이전트는 코드 리뷰, 테스트 작성, 문서화 등 특정 작업에 특화됩니다.

여러 도구를 조합하고 시스템 프롬프트를 커스터마이징하여 만듭니다.

다음 코드를 살펴봅시다.

// agents/code-reviewer.ts - 코드 리뷰 전문 에이전트
import { Agent, AgentConfig } from '../core/agent';
import { readFileTool, grepTool, diffTool } from '../tools';

export const codeReviewerConfig: AgentConfig = {
  name: 'code-reviewer',
  description: '코드 리뷰에 특화된 에이전트',
  // 시스템 프롬프트로 에이전트 성격 정의
  systemPrompt: `당신은 시니어 개발자로서 코드 리뷰를 수행합니다.
    - 버그 가능성이 있는 코드를 찾아냅니다
    - 성능 개선점을 제안합니다
    - 코드 스타일 일관성을 확인합니다
    - 보안 취약점을 점검합니다`,
  // 사용할 도구 목록
  tools: [readFileTool, grepTool, diffTool],
  // 에이전트 동작 설정
  settings: {
    maxIterations: 10,
    temperature: 0.3
  }
};

export const codeReviewerAgent = new Agent(codeReviewerConfig);

김개발 씨는 파일 검색 도구를 성공적으로 추가한 뒤 자신감이 붙었습니다. 그런데 문득 궁금해졌습니다.

"여러 도구를 조합해서 더 복잡한 작업을 자동화할 수는 없을까?" 박시니어 씨가 설명했습니다. "바로 그게 커스텀 에이전트의 역할이야.

도구는 손과 발이고, 에이전트는 그것을 조종하는 두뇌라고 생각하면 돼." 그렇다면 커스텀 에이전트란 정확히 무엇일까요? 쉽게 비유하자면, 커스텀 에이전트는 마치 전문 분야가 있는 의사와 같습니다.

내과 의사, 외과 의사, 안과 의사가 각자의 전문 분야에서 뛰어난 것처럼, 코드 리뷰 에이전트, 테스트 작성 에이전트, 문서화 에이전트가 각자의 역할에 특화됩니다. OpenCode에서 커스텀 에이전트를 만들려면 AgentConfig를 정의해야 합니다.

이 설정에는 세 가지 핵심 요소가 있습니다. 첫 번째는 시스템 프롬프트입니다.

에이전트의 성격과 역할을 정의합니다. 위 코드에서 코드 리뷰 에이전트는 "시니어 개발자로서 버그, 성능, 스타일, 보안을 점검한다"는 역할을 부여받았습니다.

두 번째는 도구 목록입니다. 에이전트가 사용할 수 있는 도구를 지정합니다.

코드 리뷰 에이전트는 파일 읽기, 검색, diff 도구를 사용합니다. 불필요한 도구는 제외하여 에이전트가 혼란스러워하지 않도록 합니다.

세 번째는 동작 설정입니다. maxIterations는 에이전트가 최대 몇 번의 도구 호출을 할 수 있는지 제한합니다.

temperature는 응답의 창의성을 조절하는데, 코드 리뷰처럼 정확성이 중요한 작업에서는 낮게 설정합니다. 위의 코드를 자세히 살펴보겠습니다.

codeReviewerConfig는 코드 리뷰에 특화된 설정을 담고 있습니다. systemPrompt에서 에이전트의 역할을 구체적으로 정의했고, 필요한 세 가지 도구만 할당했습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 매일 수십 개의 PR이 올라오는 팀이 있다고 가정해봅시다.

코드 리뷰 에이전트를 CI 파이프라인에 통합하면 기본적인 리뷰를 자동화할 수 있습니다. 사람 리뷰어는 비즈니스 로직에 집중하고, 에이전트는 스타일이나 보안 점검을 담당하는 것입니다.

주의할 점도 있습니다. 시스템 프롬프트가 너무 길거나 모호하면 에이전트가 혼란스러워합니다.

명확하고 구체적인 지시를 담아야 합니다. 또한 도구를 너무 많이 할당하면 에이전트가 어떤 도구를 써야 할지 판단하기 어려워집니다.

목적에 맞는 최소한의 도구만 할당하는 것이 좋습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

커스텀 에이전트 개념을 이해한 김개발 씨는 팀에서 자주 하는 반복 작업을 자동화할 아이디어가 떠올랐습니다. "테스트 코드 작성 에이전트를 만들면 정말 편하겠다!"

실전 팁

💡 - 시스템 프롬프트는 구체적인 예시를 포함하면 에이전트 성능이 향상됩니다

• temperature는 작업 유형에 따라 조절하세요 (정확성 중시: 0.20.4, 창의성 중시: 0.70.9)
• 에이전트 테스트 시 다양한 시나리오를 준비하여 예상치 못한 동작을 확인하세요

---

5. LSP와 포맷터 추가하기

김개발 씨는 OpenCode에 새로운 프로그래밍 언어 지원을 추가하고 싶어졌습니다. 하지만 단순히 문법 강조만으로는 부족했습니다.

"코드 자동완성이랑 포맷팅도 지원하고 싶은데..." 박시니어 씨가 말했습니다. "그러려면 LSP 서버와 포맷터를 연동해야 해.

생각보다 어렵지 않아."

**LSP(Language Server Protocol)**는 IDE와 언어 서버 간의 표준 통신 규약입니다. 마치 통역사가 서로 다른 언어를 사용하는 사람들을 연결하듯이, LSP는 다양한 에디터와 언어 분석 도구를 연결합니다.

포맷터는 코드 스타일을 일관되게 유지하는 자동화 도구입니다.

다음 코드를 살펴봅시다.

// language-support/rust-support.ts - Rust 언어 지원 추가
import { LanguageSupport, LSPClient } from '../core/language';

export const rustSupport: LanguageSupport = {
  language: 'rust',
  extensions: ['.rs'],
  // LSP 서버 설정
  lsp: {
    command: 'rust-analyzer',
    args: [],
    initializationOptions: {
      cargo: { allFeatures: true },
      checkOnSave: { command: 'clippy' }
    }
  },
  // 포맷터 설정
  formatter: {
    command: 'rustfmt',
    args: ['--edition', '2021'],
    // stdin으로 코드를 전달하고 stdout으로 결과 받기
    useStdio: true
  },
  // 린터 설정
  linter: {
    command: 'cargo',
    args: ['clippy', '--message-format=json'],
    parseOutput: (output) => parseDiagnostics(output)
  }
};

김개발 씨는 최근 Rust 언어에 관심이 생겼습니다. 그런데 OpenCode에서 Rust 파일을 열어보니 단순한 텍스트로만 표시될 뿐, 자동완성이나 오류 표시 같은 기능이 전혀 작동하지 않았습니다.

"TypeScript나 Python은 잘 되는데, 왜 Rust는 안 되는 거죠?" 김개발 씨가 물었습니다. 박시니어 씨가 설명했습니다.

"각 언어의 분석 기능을 제공하려면 LSP 서버를 연동해야 해. OpenCode에 Rust 지원을 추가해보는 건 어때?" 그렇다면 **LSP(Language Server Protocol)**란 정확히 무엇일까요?

쉽게 비유하자면, LSP는 마치 국제회의에서 활약하는 동시통역사와 같습니다. 한국어를 사용하는 사람과 영어를 사용하는 사람이 통역사를 통해 소통하듯이, VS Code 같은 에디터와 rust-analyzer 같은 언어 분석 도구가 LSP를 통해 소통합니다.

LSP 이전에는 어땠을까요? 각 에디터마다 각 언어의 지원 기능을 따로 개발해야 했습니다.

VS Code용 Rust 플러그인, Vim용 Rust 플러그인, Emacs용 Rust 플러그인을 각각 만들어야 했던 것입니다. M개의 에디터와 N개의 언어가 있으면 M x N개의 플러그인이 필요했습니다.

LSP의 등장으로 상황이 완전히 바뀌었습니다. 언어별로 LSP 서버를 하나만 만들면, LSP를 지원하는 모든 에디터에서 사용할 수 있게 되었습니다.

M + N개의 구현만으로 충분해진 것입니다. 위의 코드를 살펴보겠습니다.

rustSupport 객체는 Rust 언어 지원에 필요한 모든 설정을 담고 있습니다. lsp 섹션에서 rust-analyzer를 LSP 서버로 지정했고, 초기화 옵션으로 Cargo 설정과 clippy 검사를 활성화했습니다.

formatter 섹션은 코드 포맷팅을 담당합니다. rustfmt 명령어를 사용하고, 2021 에디션 설정을 전달합니다.

useStdio: true는 표준 입출력을 통해 코드를 주고받는다는 의미입니다. linter 섹션은 코드 품질 검사를 담당합니다.

cargo clippy를 실행하고, JSON 형식의 출력을 파싱하여 진단 정보로 변환합니다. 실제 현업에서는 어떻게 활용할까요?

팀에서 새로운 언어를 도입했는데 기존 개발 도구에서 지원하지 않는 상황을 가정해봅시다. LSP 지원을 직접 추가하면 자동완성, 오류 표시, 정의로 이동 등의 기능을 모두 사용할 수 있게 됩니다.

주의할 점도 있습니다. LSP 서버는 별도로 설치해야 합니다.

rust-analyzer, typescript-language-server 같은 도구가 시스템에 설치되어 있어야 연동이 가능합니다. 또한 LSP 서버마다 초기화 옵션이 다릅니다.

공식 문서를 꼼꼼히 읽고 올바른 옵션을 전달해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Rust LSP 지원을 추가한 김개발 씨는 이제 OpenCode에서 Rust 코드를 편하게 작성할 수 있게 되었습니다. "이제 Rust 공부가 훨씬 수월해지겠어요!"

실전 팁

💡 - LSP 서버 설치 방법을 README에 문서화하세요

• 포맷터 설정은 프로젝트의 기존 설정 파일(.rustfmt.toml 등)을 존중하도록 구현하세요
• LSP 연결 실패 시 친절한 에러 메시지를 보여주세요

---

6. PR 제출과 코드 리뷰

드디어 모든 기능 개발을 마친 김개발 씨는 설렘 반 긴장 반으로 PR을 제출하려 합니다. "PR을 올리면 끝인 거죠?" 박시니어 씨가 고개를 저었습니다.

"PR 제출은 시작일 뿐이야. 코드 리뷰를 통과해야 진짜 기여가 완성되는 거지."

PR(Pull Request) 제출과 코드 리뷰는 오픈소스 기여의 마지막 관문입니다. 마치 논문을 학술지에 제출하고 피어 리뷰를 받는 것과 같습니다.

PR 템플릿을 잘 작성하고, 리뷰어의 피드백에 성실히 대응하면 성공적으로 병합될 수 있습니다.

다음 코드를 살펴봅시다.

# Pull Request 템플릿 예시

## 변경 사항 요약
<!-- 무엇을 왜 변경했는지 간단히 설명 -->
Rust 언어 지원을 추가했습니다. rust-analyzer LSP 연동과
rustfmt 포맷터 통합을 포함합니다.

## 관련 이슈
Closes #234

## 변경 유형
- [x] 새로운 기능 (기존 기능에 영향 없음)
- [ ] 버그 수정
- [ ] 문서 업데이트

## 테스트 방법

---

3. 자동완성, 오류 표시 확인

김개발 씨는 Rust 언어 지원 기능을 완성하고 뿌듯한 마음으로 git push를 실행했습니다. 이제 PR만 올리면 끝이라고 생각했습니다.

하지만 박시니어 씨가 말했습니다. "PR 제출은 여정의 절반이야.

진짜 중요한 건 코드 리뷰를 통과하는 거지." 그렇다면 좋은 PR이란 어떤 것일까요? 쉽게 비유하자면, PR은 마치 학술 논문과 같습니다.

연구 내용이 아무리 훌륭해도 형식이 엉망이면 리젝당하듯이, 코드가 아무리 잘 작성되어도 PR 설명이 부실하면 리뷰어의 외면을 받습니다. 좋은 PR의 첫 번째 요소는 명확한 제목입니다.

"feat: add Rust language support with LSP and formatter"처럼 변경 유형과 내용을 한눈에 파악할 수 있어야 합니다. 두 번째는 상세한 설명입니다.

무엇을 변경했는지, 왜 변경했는지, 어떻게 테스트했는지를 기술합니다. 리뷰어가 코드를 이해하는 데 필요한 맥락을 제공해야 합니다.

세 번째는 관련 이슈 연결입니다. "Closes #234"처럼 이슈 번호를 명시하면 PR이 병합될 때 자동으로 이슈가 닫힙니다.

프로젝트 관리가 깔끔해집니다. 위의 PR 템플릿을 살펴보겠습니다.

변경 사항 요약에서 핵심 내용을 간단히 설명하고, 변경 유형을 체크박스로 표시했습니다. 테스트 방법을 단계별로 기술하여 리뷰어가 직접 확인할 수 있도록 했습니다.

PR을 제출하면 이제 코드 리뷰가 시작됩니다. 리뷰어는 코드의 정확성, 성능, 가독성, 일관성 등을 검토합니다.

피드백이 달리면 어떻게 대응해야 할까요? 첫째, 열린 자세를 유지합니다.

리뷰어의 의견이 틀렸다고 느껴져도 먼저 이해하려고 노력합니다. 대부분의 피드백에는 이유가 있습니다.

둘째, 신속하게 대응합니다. 피드백을 받고 며칠씩 방치하면 리뷰어의 기억도 흐려지고, 다른 변경 사항과 충돌이 생길 수 있습니다.

셋째, 토론을 두려워하지 않습니다. 피드백에 동의하지 않는다면 정중하게 의견을 제시합니다.

건설적인 토론은 코드 품질 향상에 도움이 됩니다. 실제 현업에서는 어떤 피드백이 자주 달릴까요?

"이 부분 테스트 코드가 없네요", "변수명이 명확하지 않습니다", "이 로직을 별도 함수로 분리하면 좋겠습니다" 같은 피드백이 흔합니다. 주의할 점도 있습니다.

PR의 크기가 너무 크면 리뷰가 어렵습니다. 가능하면 하나의 PR에 하나의 관심사만 담는 것이 좋습니다.

또한 CI 파이프라인이 통과하는지 확인해야 합니다. 테스트 실패, 린트 오류가 있는 상태로 리뷰를 요청하면 안 됩니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 꼼꼼하게 PR을 작성한 김개발 씨는 메인테이너로부터 몇 가지 피드백을 받았습니다.

성실하게 수정한 끝에 드디어 "LGTM, Merging!"이라는 댓글이 달렸습니다. 김개발 씨의 코드가 OpenCode에 병합되는 순간, 전 세계 개발자들이 그 기능을 사용할 수 있게 됩니다.

이것이 바로 오픈소스 기여의 보람입니다.

실전 팁

💡 - PR은 작을수록 좋습니다. 500줄 이하를 권장합니다

• 리뷰어를 직접 지정하지 말고 프로젝트의 리뷰 프로세스를 따르세요
• 리뷰가 오래 걸리면 정중하게 리마인드해도 괜찮습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!