OpenCode LSP란? 활성화 방법과 비활성화된 서버 해결하기

LSP는 Language Server Protocol의 약자입니다. 언어 서버는 프로젝트 옆에서 실행되며 진단, 심볼, 정의, 참조, hover 정보를 제공합니다. OpenCode는 파일을 단순한 텍스트로만 다루지 않고 이 정보를 세션에서 활용할 수 있습니다.

실제 이점은 컨텍스트입니다. TypeScript 서버가 import 관계를 이해하면 agent가 타입 오류나 이름 변경을 더 구체적으로 판단할 수 있습니다. 그래도 서버가 없거나 프로젝트를 읽지 못하거나 별도 설정이 필요할 수 있습니다. LSP는 테스트와 diff 검토를 대체하지 않습니다.

LSP 항목에는 실행 가능한 명령과 파일 확장자와의 명확한 연결이 필요합니다. 명령이 서버를 실행하고 확장자 목록이 대상 파일을 정합니다. 실행 파일, 인자, 설치 방법은 서버 문서를 따르며 패키지 이름을 추측하지 마세요.

작은 저장소에서 한 언어부터 시작합니다. 예상 확장자의 파일을 열고 프로세스가 실행되는지 확인한 뒤 읽기 전용 요청을 보냅니다. 확장자가 맞지 않으면 서버가 정상이어도 OpenCode가 파일에 연결하지 못합니다.

저장소 전체가 공유할 LSP 결정은 검토 가능한 프로젝트 설정에 둡니다. 개인 실험은 명령, 확장자, 프로젝트 root를 파악할 때까지 전역 설정에 두세요. JSONC 가이드는 범위와 Schema를 다루며 이 페이지는 언어 서버 동작에 집중합니다.

큰 목록보다 작은 항목이 디버깅하기 쉽습니다. 알아보기 쉬운 이름, 명시적인 command 배열, 지원되는 확장자만 사용하세요. 기본 프로세스가 동작한 뒤 초기화 옵션을 추가합니다. JSON이 유효해도 실행 파일이나 workspace가 틀릴 수 있습니다.

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "typescript": {
      "command": ["typescript-language-server", "--stdio"],
      "extensions": [".ts", ".tsx"]
    }
  }
}

현재 공식 문서에 따르면 lsp를 생략하면 모든 LSP 서버가 비활성화됩니다. 다른 설정이 서버를 켠 뒤 모두 끄려면 lsp: false, 한 서버만 끄려면 disabled: true를 사용합니다. 서버가 느리거나 출력이 많거나 저장소와 맞지 않을 때 유용합니다.

사용자 지정 서버는 기본 설정에 없는 언어나 확장자를 처리합니다. 먼저 command와 extensions를 정의하고 공식 문서에 있을 때만 초기화를 추가하세요. 한 번에 하나만 바꾸고 마지막 정상 설정을 rollback용으로 남깁니다.

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": false
}

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "custom-lsp": {
      "command": ["custom-lsp-server", "--stdio"],
      "extensions": [".custom"],
      "initialization": { "preferences": { "mode": "strict" } }
    }
  }
}

처음부터 큰 모듈을 다시 작성하지 마세요. Git 상태가 분명한 저장소에서 파일 하나를 열고 심볼, 정의, 진단을 읽기 전용으로 요청합니다. 에디터, 컴파일러, 신뢰하는 서버의 결과와 비교할 수 있어야 합니다.

읽기가 성공하면 작고 되돌릴 수 있는 변경을 한 번 하고 diff를 확인합니다. OS, command, 확장자, root, 테스트 prompt를 기록하면 다음 문제도 같은 조건에서 재현할 수 있습니다.

1. 정리브랜치와 작업 트리를 확인한다.
2. 일치설정한 확장자의 파일을 연다.
3. 읽기심볼, 정의, 참조, 진단을 요청한다.
4. 수정작고 되돌릴 수 있는 변경 후 diff를 본다.
5. 기록command, 모델, 서버, rollback을 기록한다.

LSP가 비활성화되었다고 나오면 재설치보다 설정 우선순위를 먼저 확인합니다. 다른 파일이 lsp: false를 적용하거나 프로젝트에 서버 이름이 없거나 항목에 disabled가 있을 수 있습니다. 실제 프로젝트 폴더와 최종 설정을 비교하세요.

서버가 켜졌는데 진단이 없으면 command와 확장자를 확인합니다. 같은 shell에서 실행하고 runtime과 PATH, lockfile, compiler 설정, workspace root를 살핍니다. 처음만 느리다면 큰 저장소를 인덱싱하는 중일 수 있습니다.

권한은 좁게 유지합니다. LSP에는 프로세스와 프로젝트 컨텍스트가 필요하지만 넓은 shell, 추가 MCP 도구, 자동 승인이 필요한 것은 아닙니다. 계층이 바뀌면 권한과 MCP 가이드를 사용하세요.

LSP는 저장소의 언어 지능을 제공하고 MCP는 외부 도구와 데이터를 연결합니다. formatter는 스타일을 바꾸고 테스트는 실행 가능한 증거를 줍니다. VS Code가 진단을 보여도 OpenCode가 같은 서버와 root를 쓰고 있다는 뜻은 아닙니다.

문제에 맞는 페이지를 연결하세요. MCP는 로컬·원격 도구 서버, VS Code는 에디터와 터미널, 권한 페이지는 승인을 다룹니다. 이 구분이 OpenCode LSP의 의도를 지켜 줍니다.