[opencode 12일 집중 — 터미널 네이티브 AI 코딩 에이전트 완전 정복] 11/12화: opencode 멀티 세션·서브에이전트·Git 통합 실전 가이드 2026

이 글은 「opencode 12일 집중」 시리즈의 11일차입니다. 어제(10일차)는 opencode serve와 opencode run으로 헤드리스 자동화 파이프라인을 구축하는 방법을 다뤘습니다.

터미널 하나에 세션 하나—이렇게만 쓰면 opencode 멀티 세션의 진짜 위력을 절반도 못 쓰는 셈입니다. 오늘은 세션을 나누고, 서브에이전트에 작업을 위임하고, Git 통합으로 실수를 되돌리는 법을 한꺼번에 정리합니다.

오늘의 핵심 3가지

• 병렬 세션 — 터미널 탭마다 독립된 opencode 세션을 열어 프론트엔드·백엔드·테스트를 동시에 진행할 수 있습니다.
• 서브에이전트 위임 — @general 서브에이전트로 반복 작업이나 조사 작업을 메인 컨텍스트를 오염시키지 않고 분리 실행합니다.
• Git 기반 /undo·/redo + GitHub Actions — AI가 만든 변경을 커밋 단위로 되돌리고, 이슈 코멘트 한 줄로 CI에서 opencode를 트리거합니다.

1. 병렬 세션 — opencode 멀티 세션 운영의 기본

대규모 코드베이스에서 하나의 세션으로 모든 작업을 처리하려 하면 컨텍스트가 금방 포화됩니다. opencode는 세션 단위로 대화 기록과 작업 컨텍스트를 격리하기 때문에, 여러 세션을 동시에 띄우는 것이 실무에서 가장 즉각적인 생산성 향상 방법입니다.

1-1. 왜 세션을 나눠야 하는가

opencode의 각 세션은 독립된 대화 히스토리를 유지합니다. 하나의 세션에 “프론트엔드 컴포넌트 리팩터링”과 “백엔드 API 에러 수정”을 번갈아 요청하면 어떻게 될까요?

• 컨텍스트 윈도우가 두 주제의 코드로 뒤섞여 모델의 정확도가 떨어집니다.
• /compact로 요약해도 두 작업의 맥락이 혼재된 요약본이 됩니다.
• 한쪽 작업의 파일 수정이 다른 작업에 의도치 않은 영향을 줄 수 있습니다.

세션을 분리하면 각 세션이 해당 작업 영역의 파일만 집중적으로 다루므로, 모델이 더 정확한 코드를 생성하고 실수가 줄어듭니다.

1-2. 세션을 나누는 실전 패턴

opencode 멀티 세션을 운영하는 가장 간단한 방법은 터미널 탭(또는 tmux/zellij 패인)을 나누는 것입니다. 각 탭에서 opencode를 실행하면 별도의 세션이 생성됩니다.

# 터미널 탭 1: 프론트엔드 작업
cd ~/project
opencode

# 터미널 탭 2: 백엔드 작업 (같은 프로젝트 디렉터리)
cd ~/project
opencode

# 터미널 탭 3: 테스트 전용
cd ~/project
opencode

각 세션은 고유한 세션 ID를 가지며, ~/.opencode/sessions/ 디렉터리에 대화 기록이 저장됩니다. 세션 목록은 TUI 내에서 확인할 수 있고, 이전에 중단한 세션을 이어서 작업하는 것도 가능합니다.

1-3. tmux / zellij로 세션 레이아웃 고정하기

매번 터미널 탭을 수동으로 여는 것은 번거롭습니다. tmux나 zellij를 사용하면 세션 레이아웃을 스크립트 하나로 재현할 수 있습니다.

# opencode-workspace.sh — tmux로 3-패인 레이아웃 구성
#!/bin/bash
SESSION="opencode-work"

tmux new-session -d -s $SESSION -n "frontend"
tmux send-keys -t $SESSION:frontend "cd ~/project && opencode" Enter

tmux new-window -t $SESSION -n "backend"
tmux send-keys -t $SESSION:backend "cd ~/project && opencode" Enter

tmux new-window -t $SESSION -n "test"
tmux send-keys -t $SESSION:test "cd ~/project && opencode" Enter

tmux attach -t $SESSION

이 스크립트를 실행하면 frontend, backend, test 세 개의 tmux 윈도우에 각각 opencode 세션이 뜹니다. Ctrl+b + 숫자키로 윈도우를 전환하면서 병렬 작업이 가능합니다.

1-4. 세션 간 작업 충돌 방지

같은 프로젝트 디렉터리에서 여러 세션을 띄우면 동일 파일을 동시에 수정하는 충돌이 발생할 수 있습니다. 이를 방지하는 실전 팁입니다.

• 작업 영역을 명확히 지시 — 각 세션의 첫 메시지에서 “이 세션에서는 src/components/ 디렉터리만 다뤄줘”처럼 범위를 한정합니다.
• Git 브랜치 분리 — 각 세션을 별도의 feature 브랜치에서 작업하면 파일 충돌이 원천 차단됩니다. 나중에 merge로 합칩니다.
• Plan 모드 우선 — 5일차에서 다룬 Plan 모드(읽기 전용)로 먼저 분석한 뒤, 확신이 생기면 Build로 전환하는 습관이 멀티 세션에서 더욱 중요합니다.

# 세션 1: feature-auth 브랜치
git checkout -b feature-auth
opencode
# → "인증 모듈 리팩터링해줘"

# 세션 2: feature-dashboard 브랜치
git checkout -b feature-dashboard
opencode
# → "대시보드 차트 컴포넌트 추가해줘"

1-5. 세션 재개와 관리

opencode 세션은 종료 후에도 히스토리가 보존됩니다. TUI에서 이전 세션 목록을 확인하고 원하는 세션을 선택해 이어서 작업할 수 있습니다. 장시간 작업 중 터미널이 닫혔거나 SSH 세션이 끊어졌을 때 특히 유용합니다.

세션이 많아지면 오래된 세션을 정리하는 것도 필요합니다. ~/.opencode/sessions/ 디렉터리에서 불필요한 세션 데이터를 직접 삭제하거나, 주기적으로 정리 스크립트를 돌리는 것을 권장합니다.

2. 서브에이전트 — 작업을 위임하는 새로운 패턴

병렬 세션이 “사람이 여러 터미널을 직접 관리”하는 방식이라면, 서브에이전트는 “AI가 AI에게 하위 작업을 위임”하는 방식입니다. opencode의 @general 서브에이전트는 메인 에이전트의 컨텍스트를 보존하면서 독립적인 하위 작업을 실행합니다.

2-1. 서브에이전트란 무엇인가

서브에이전트는 메인 에이전트가 특정 작업을 별도의 실행 컨텍스트로 분리해 처리하는 메커니즘입니다. 메인 대화에서 “이 부분은 서브에이전트에게 맡긴다”고 판단하면, opencode가 자동으로 서브에이전트를 생성하고 결과를 메인 컨텍스트로 가져옵니다.

핵심 이점은 컨텍스트 격리입니다.

• 메인 에이전트의 컨텍스트 윈도우가 하위 작업의 중간 과정으로 오염되지 않습니다.
• 서브에이전트는 자신만의 도구 호출 권한과 대화 히스토리를 가집니다.
• 작업 완료 후 핵심 결과만 메인에 반환되므로, 메인 에이전트가 전체 그림을 유지하기 쉽습니다.

2-2. @general 서브에이전트 사용법

opencode에서 서브에이전트를 명시적으로 활용하는 방법은 프롬프트에 @general을 포함하는 것입니다. 이렇게 하면 opencode가 해당 작업을 별도의 에이전트 컨텍스트에서 처리합니다.

# opencode TUI에서 입력
프로젝트의 모든 TODO 주석을 찾아서 파일별로 정리해줘. @general 서브에이전트로 처리해.

서브에이전트가 적합한 작업 유형은 다음과 같습니다.

• 코드베이스 조사 — “이 프로젝트에서 사용하지 않는 import를 모두 찾아줘”
• 반복 패턴 적용 — “모든 API 엔드포인트에 동일한 에러 핸들링 패턴을 추가해줘”
• 문서 생성 — “각 모듈의 public API를 분석해서 README 초안을 만들어줘”
• 테스트 코드 생성 — “이 유틸리티 함수들의 단위 테스트를 작성해줘”

2-3. 서브에이전트 실전 시나리오: 대규모 리팩터링

실제로 서브에이전트가 빛을 발하는 장면을 하나 그려보겠습니다. 50개 파일에 걸쳐 있는 레거시 로깅 라이브러리를 새 라이브러리로 교체하는 작업입니다.

# 메인 에이전트에게 전체 계획 수립 요청 (Plan 모드)
Tab  # Plan 모드로 전환
"winston 로거를 pino로 교체하려고 해.
 영향받는 파일 목록과 교체 전략을 정리해줘."

# 메인 에이전트가 계획을 세우면, 실행은 서브에이전트에 위임
Tab  # Build 모드로 전환
"위 계획대로 실행해줘.
 각 모듈의 로거 교체는 서브에이전트로 병렬 처리하고,
 완료되면 결과를 요약해줘."

이 패턴의 핵심은 계획은 메인, 실행은 서브입니다. 메인 에이전트가 전체 아키텍처와 교체 규칙을 파악한 상태에서 서브에이전트에게 개별 파일 수정을 위임하면, 메인의 컨텍스트 윈도우는 계획과 결과 요약만 담게 됩니다.

2-4. 서브에이전트와 병렬 세션의 차이

둘 다 “작업을 나눈다”는 점에서 비슷해 보이지만, 사용 시점과 방식이 다릅니다.

구분	병렬 세션	서브에이전트
주체	사용자가 직접 여러 터미널 관리	메인 에이전트가 자동으로 생성·관리
컨텍스트 공유	세션 간 완전 독립	메인 에이전트가 결과를 통합
적합한 작업	서로 무관한 독립 작업	하나의 큰 작업을 하위 단계로 분할
결과 합산	사용자가 수동으로 merge	메인 에이전트가 자동 취합
난이도	낮음 (터미널만 열면 됨)	중간 (프롬프트 설계 필요)

실무에서는 두 가지를 조합하는 경우가 많습니다. 예를 들어, 세션 1에서 프론트엔드 리팩터링(서브에이전트 활용)을 돌리고, 세션 2에서는 백엔드 API 신규 개발을 독립적으로 진행하는 식입니다.

3. Git 통합 — /undo·/redo로 AI 변경을 안전하게 관리

AI 코딩 에이전트의 가장 큰 불안 요소는 “잘못된 수정을 해버리면 어쩌지?”입니다. opencode는 Git을 활용한 /undo와 /redo 명령으로 이 문제를 깔끔하게 해결합니다.

3-1. /undo — AI가 만든 변경 되돌리기

/undo는 opencode가 가장 최근에 수행한 파일 변경을 Git 수준에서 되돌립니다. 일반적인 텍스트 에디터의 Ctrl+Z와 비슷하지만, 파일 시스템 변경 전체를 원자적으로 롤백한다는 점이 다릅니다.

# opencode TUI에서
/undo

이 한 줄이면 직전 변경이 되돌려집니다. 내부적으로는 Git의 변경 사항 추적을 활용하기 때문에, opencode가 여러 파일을 동시에 수정했더라도 그 묶음 전체가 한 번에 롤백됩니다.

3-2. /redo — 되돌린 변경 다시 적용

/undo로 되돌린 뒤 “역시 그 변경이 맞았네”라고 판단되면 /redo로 다시 적용할 수 있습니다.

# 되돌린 변경을 다시 적용
/redo

이 조합 덕분에 AI의 제안을 부담 없이 시도해볼 수 있습니다. Build 모드에서 “한번 해봐”라고 지시한 뒤, 결과가 마음에 들지 않으면 /undo, 괜찮으면 그대로 유지—이 루프가 자연스러워집니다.

3-3. Git 기반이라 가능한 것들

/undo와 /redo가 단순 텍스트 버퍼 조작이 아니라 Git 기반이기 때문에 다음과 같은 이점이 있습니다.

• 파일 생성/삭제도 롤백 — 새 파일을 만든 것도, 기존 파일을 지운 것도 되돌릴 수 있습니다.
• 다중 파일 원자성 — 에이전트가 5개 파일을 동시에 수정했으면, /undo 한 번에 5개 파일 모두 원복됩니다.
• 기존 Git 워크플로와 호환 — opencode의 변경 사항이 Git 히스토리에 남기 때문에, git log나 git diff로 에이전트가 무엇을 했는지 사후 감사(audit)가 가능합니다.
• 부분 커밋과의 조합 — /undo로 되돌린 뒤 특정 파일만 스테이징하여 원하는 변경만 커밋할 수 있습니다.

3-4. /undo·/redo 실전 워크플로

5일차에서 다룬 Plan → Build 루프에 /undo를 결합하면 더 안전한 워크플로가 완성됩니다.

# Step 1: Plan 모드에서 변경 계획 확인
Tab  # Plan 모드
"이 함수를 async로 바꾸면 영향받는 코드를 알려줘"

# Step 2: Build 모드에서 실행
Tab  # Build 모드
"좋아, 위 계획대로 변환해줘"

# Step 3: 결과 확인 (터미널 or 에디터에서)
# 만족스럽지 않다면:
/undo

# 다른 접근 방식으로 재시도
"async 대신 콜백 패턴으로 바꿔줘"

# 이것도 아니면:
/undo

# 첫 번째가 나았다면:
/redo
/redo  # 두 번 되돌린 경우 두 번 redo

이 흐름에서 핵심은 “일단 시도하고, 아니면 되돌린다”는 마인드셋입니다. /undo가 있으니까 AI에게 과감한 시도를 요청할 수 있습니다.

3-5. /undo 와 git stash의 차이

비슷한 역할을 하는 git stash와 /undo는 어떻게 다를까요?

• git stash는 현재 작업 중인 모든 uncommitted 변경을 일괄 보관합니다. 선택적 롤백이 어렵습니다.
• /undo는 opencode가 수행한 가장 최근 작업 단위만 정확히 되돌립니다. 에이전트의 작업 단위와 1:1로 매칭됩니다.
• 여러분이 직접 에디터에서 수정한 내용과 AI가 수정한 내용이 섞여 있을 때, /undo는 AI의 변경만 선택적으로 되돌릴 수 있습니다.

4. GitHub Actions 통합 — 이슈 코멘트로 opencode 트리거

opencode 멀티 세션의 마지막 퍼즐은 CI/CD 파이프라인과의 통합입니다. GitHub Actions와 연결하면 이슈에 /opencode 코멘트를 달아 자동으로 코드 생성·수정·리뷰를 트리거할 수 있습니다.

4-1. /opencode 이슈 코멘트란

GitHub 이슈나 PR에 /opencode로 시작하는 코멘트를 남기면, GitHub Actions 워크플로가 이를 감지해 opencode를 실행하고 결과를 자동으로 코멘트나 커밋으로 반영합니다. 팀원 누구나 GitHub 웹 UI에서 AI 코딩 에이전트를 호출할 수 있게 되는 셈입니다.

4-2. GitHub Actions 워크플로 구성

아래는 /opencode 이슈 코멘트에 반응하는 GitHub Actions 워크플로 예시입니다.

# .github/workflows/opencode-issue.yml
name: opencode on issue comment

on:
  issue_comment:
    types: [created]

jobs:
  opencode:
    if: startsWith(github.event.comment.body, '/opencode')
    runs-on: ubuntu-latest
    permissions:
      contents: write
      issues: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.head_ref || github.event.repository.default_branch }}

      - name: Install opencode
        run: curl -fsSL https://opencode.ai/install | bash

      - name: Run opencode
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          PROMPT=$(echo '${{ github.event.comment.body }}' | sed 's|^/opencode ||')
          opencode run -q -f json "$PROMPT" > result.json

      - name: Post result
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const result = JSON.parse(fs.readFileSync('result.json', 'utf8'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `### opencode 결과\n\n${result.content || '작업이 완료되었습니다.'}`
            });

이 워크플로의 핵심 포인트를 짚어보겠습니다.

• issue_comment 트리거 — 이슈와 PR 코멘트 모두에 반응합니다. PR 코멘트에서 트리거하면 해당 브랜치의 코드를 체크아웃하므로 PR 컨텍스트에서 바로 작업 가능합니다.
• startsWith 가드 — /opencode로 시작하는 코멘트만 트리거합니다. 일반 대화가 워크플로를 실행하지 않습니다.
• opencode run -q -f json — 10일차에서 다룬 비대화형 모드입니다. CI 환경에서는 TUI가 불가능하므로 반드시 run 서브커맨드를 사용합니다.
• 결과 코멘트 — opencode의 실행 결과를 이슈에 자동으로 코멘트로 달아줍니다.

4-3. 실전 사용 시나리오

팀에서 이 워크플로를 도입하면 다음과 같은 시나리오가 가능합니다.

시나리오 1: 버그 이슈에서 바로 수정 요청

# GitHub 이슈 코멘트
/opencode src/utils/parser.ts의 parseDate 함수에서
윤년 2월 29일을 처리하지 못하는 버그를 수정해줘.
테스트도 추가해.

opencode가 코드를 분석하고, 수정하고, 테스트를 추가한 뒤 결과를 코멘트로 보고합니다. 코드 변경을 커밋까지 자동으로 하려면 워크플로에 git commit과 git push 스텝을 추가하면 됩니다.

시나리오 2: PR 리뷰 코멘트에서 코드 개선

# PR 리뷰 코멘트
/opencode 이 PR에서 변경된 파일들의 에러 핸들링을
일관된 패턴으로 통일해줘. try-catch 대신
Result 타입을 사용하는 방식으로.

시나리오 3: 문서 자동 생성

# 이슈 코멘트
/opencode src/api/ 디렉터리의 모든 엔드포인트를 분석해서
docs/api-reference.md 파일을 생성해줘.

4-4. 보안 고려사항

GitHub Actions에서 opencode를 실행할 때 반드시 신경 써야 할 보안 사항이 있습니다.

• API 키 관리 — LLM 프로바이더의 API 키는 반드시 GitHub Secrets에 저장합니다. 워크플로 파일에 직접 넣으면 안 됩니다.
• 권한 최소화 — permissions에서 필요한 권한만 부여합니다. contents: write가 필요한 경우 커밋 범위를 특정 브랜치로 제한하는 것이 좋습니다.
• 포크(Fork) PR 주의 — 외부 기여자의 포크에서 올라온 PR 코멘트에서 /opencode가 트리거되면, 악의적인 프롬프트가 실행될 수 있습니다. if 조건에 github.event.comment.author_association 체크를 추가하세요.
• 프롬프트 주입 방어 — 코멘트 본문을 그대로 opencode에 전달하면 프롬프트 인젝션 위험이 있습니다. AGENTS.md에 명확한 제약 조건을 설정해두면 방어층이 됩니다.

# Fork PR에서의 트리거 방지
jobs:
  opencode:
    if: |
      startsWith(github.event.comment.body, '/opencode') &&
      contains(fromJson('["OWNER","MEMBER","COLLABORATOR"]'),
               github.event.comment.author_association)

4-5. 자동 커밋까지 연결하기

opencode의 실행 결과를 코멘트로만 보고하는 것이 아니라, 실제 코드 변경을 커밋하고 푸시하는 확장 구성입니다.

      - name: Run opencode and apply changes
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          PROMPT=$(echo '${{ github.event.comment.body }}' | sed 's|^/opencode ||')
          opencode run "$PROMPT"

      - name: Commit and push if changed
        run: |
          git config user.name "opencode-bot"
          git config user.email "[email protected]"
          git add -A
          if git diff --cached --quiet; then
            echo "No changes to commit"
          else
            git commit -m "fix: apply opencode suggestion from issue #${{ github.event.issue.number }}"
            git push
          fi

이렇게 하면 이슈 코멘트 한 줄로 코드 수정·커밋·푸시까지 자동으로 이어집니다. 물론 프로덕션 브랜치에 직접 푸시하는 것은 위험하므로, 별도의 feature 브랜치를 만들어 PR을 생성하는 방식이 더 안전합니다.

5. 실전 통합: 세 가지를 조합한 대규모 작업 패턴

지금까지 다룬 병렬 세션, 서브에이전트, Git 통합을 하나의 워크플로로 엮으면 어떤 모습일까요? 실제 프로젝트에서 “Express.js → Fastify 마이그레이션”이라는 큰 작업을 진행한다고 가정해보겠습니다.

5-1. 단계별 조합 전략

# === 세션 1: 마이그레이션 계획 수립 (메인 세션) ===
opencode
# Plan 모드에서:
"Express.js를 Fastify로 마이그레이션할 계획을 세워줘.
 라우트 목록, 미들웨어, 에러 핸들러 매핑 표를 만들어줘."

# === 세션 2: 라우트 마이그레이션 (서브에이전트 활용) ===
opencode
# Build 모드에서:
"세션 1의 매핑 표 기준으로 src/routes/ 아래 모든 라우터를
 Fastify 플러그인으로 전환해줘. @general 서브에이전트로 병렬 처리."

# === 세션 3: 테스트 업데이트 ===
opencode
# Build 모드에서:
"tests/ 디렉터리의 모든 supertest 기반 테스트를
 light-my-request (Fastify 테스트 유틸)로 변환해줘."

# === 결과 확인 후 ===
# 세션 2에서 미들웨어 변환이 잘못됐다면:
/undo
"미들웨어는 Fastify hook 패턴으로 다시 변환해줘."

5-2. 이 패턴이 효과적인 이유

• 계획과 실행의 분리 — 세션 1이 전체 청사진을 담당하고, 나머지 세션이 실행합니다.
• 컨텍스트 집중 — 각 세션이 자기 영역만 다루므로 정확도가 높습니다.
• 안전한 실험 — /undo가 있으므로 어떤 변환이든 일단 시도해볼 수 있습니다.
• 감사 추적 — 모든 변경이 Git 히스토리에 남아 사후 검토가 가능합니다.

6. opencode 멀티 세션 운영 팁 모음

실무에서 멀티 세션을 효과적으로 운영하기 위한 팁을 정리합니다.

6-1. 세션별 AGENTS.md 활용

7일차에서 다룬 AGENTS.md를 세션 특성에 맞게 활용할 수 있습니다. 프로젝트 루트의 AGENTS.md 외에, 하위 디렉터리에 별도의 AGENTS.md를 두면 해당 디렉터리에서 시작한 세션이 더 정확한 컨텍스트를 받습니다.

# src/frontend/AGENTS.md
이 디렉터리는 React 18 + TypeScript 프론트엔드입니다.
- 상태 관리: Zustand
- 스타일링: Tailwind CSS v4
- 테스트: Vitest + Testing Library
- 컴포넌트 명명: PascalCase, 파일은 kebab-case

# src/backend/AGENTS.md
이 디렉터리는 Node.js + Fastify 백엔드입니다.
- DB: PostgreSQL + Drizzle ORM
- 인증: JWT + refresh token
- 테스트: Vitest
- 라우트 파일명: {resource}.route.ts

프론트엔드 세션과 백엔드 세션이 각각의 AGENTS.md를 참조하면, 에이전트가 해당 영역의 규칙을 더 정확하게 따릅니다.

6-2. /compact로 세션 수명 연장

오래 실행된 세션은 컨텍스트 윈도우가 가득 찰 수 있습니다. 이때 /compact를 사용하면 이전 대화를 요약해 컨텍스트를 확보합니다. 특히 멀티 세션 환경에서는 각 세션의 컨텍스트 효율이 전체 생산성에 직결되므로, 주기적인 /compact가 중요합니다.

# 세션이 길어졌을 때
/compact
# → 이전 대화가 요약되어 컨텍스트 윈도우가 여유로워집니다
# → 이후 요청의 정확도가 개선됩니다

6-3. 모델 배분 전략

3일차에서 다룬 BYOK의 자유를 멀티 세션에서도 활용할 수 있습니다. 세션마다 다른 모델을 배정해 비용과 성능을 최적화하는 전략입니다.

• 계획 세션 — 고성능 모델 (복잡한 아키텍처 분석에 적합)
• 반복 작업 세션 — 비용 효율적인 모델 (패턴 적용, 테스트 생성 등)
• 리뷰 세션 — 고성능 모델 (코드 리뷰, 버그 탐지)

opencode 설정 파일에서 모델을 지정하거나, 세션 시작 시 --provider와 --model 플래그로 세션별 모델을 다르게 설정할 수 있습니다.

6-4. 세션 간 정보 전달

독립된 세션 간에 정보를 전달해야 할 때가 있습니다. 직접적인 세션 간 통신 채널은 없지만, 다음과 같은 우회 방법이 있습니다.

• 파일 기반 — 세션 1에서 분석 결과를 마크다운 파일로 저장하고, 세션 2에서 해당 파일을 @로 참조합니다.
• Git 기반 — 세션 1에서 커밋한 변경 사항을 세션 2에서 git pull로 가져옵니다.
• 클립보드 — 세션 1의 출력을 복사해 세션 2의 프롬프트에 붙여넣습니다.

# 세션 1에서 분석 결과를 파일로 저장
"프로젝트의 의존성 트리를 분석해서 docs/dependency-analysis.md로 저장해줘"

# 세션 2에서 해당 파일 참조
"@docs/dependency-analysis.md 를 참고해서 순환 의존성을 해결해줘"

7. 복사-붙여넣기 실습: /opencode GitHub Actions 설정

오늘의 핵심 실습입니다. 여러분의 프로젝트에 /opencode 이슈 코멘트 트리거를 바로 설정해보세요.

# 1. 워크플로 파일 생성
mkdir -p .github/workflows

cat << 'EOF' > .github/workflows/opencode-issue.yml
name: opencode on issue comment

on:
  issue_comment:
    types: [created]

jobs:
  opencode:
    if: |
      startsWith(github.event.comment.body, '/opencode') &&
      contains(fromJson('["OWNER","MEMBER","COLLABORATOR"]'),
               github.event.comment.author_association)
    runs-on: ubuntu-latest
    permissions:
      contents: write
      issues: write
      pull-requests: write
    steps:
      - uses: actions/checkout@v4

      - name: Install opencode
        run: curl -fsSL https://opencode.ai/install | bash

      - name: Extract prompt and run
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          PROMPT=$(echo '${{ github.event.comment.body }}' | sed 's|^/opencode[[:space:]]*||')
          opencode run -q "$PROMPT"

      - name: Report result
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `opencode 실행이 완료되었습니다. (status: ${{ job.status }})`
            });
EOF

# 2. GitHub Secrets에 API 키 등록 (GitHub 웹 UI에서)
# Settings → Secrets and variables → Actions → New repository secret
# Name: ANTHROPIC_API_KEY
# Value: (본인의 API 키)

# 3. 커밋 & 푸시
git add .github/workflows/opencode-issue.yml
git commit -m "ci: add opencode issue comment trigger"
git push

# 4. 이슈에서 테스트
# 아무 이슈에 코멘트: /opencode 이 프로젝트의 README를 개선해줘

Gotcha 미니 코너: 멀티 세션에서 같은 파일을 동시에 수정하면?

함정: 두 세션이 동일한 파일을 동시에 Build 모드로 수정하면, 나중에 저장되는 쪽이 먼저 수정한 내용을 덮어씁니다. opencode 자체에는 파일 잠금(locking) 메커니즘이 없습니다.

해결책: 작업 영역을 명확히 분리하세요. 같은 파일을 다뤄야 한다면 반드시 Git 브랜치를 분리하고, 나중에 merge하세요. 또는 한 세션은 Plan 모드로만 분석하고, 실제 수정은 다른 세션 한 곳에서만 하세요. 가장 확실한 방법은 세션을 시작할 때 “이 세션에서는 src/api/만 수정해. src/components/는 절대 건드리지 마”처럼 명시적 경계를 설정하는 것입니다.

정리

11일차에서는 opencode를 단일 세션 도구에서 팀 생산성 플랫폼으로 확장하는 방법을 다뤘습니다.

• 병렬 세션으로 독립된 작업을 동시에 처리하고
• 서브에이전트로 큰 작업을 컨텍스트 오염 없이 분할하고
• /undo·/redo로 AI 변경을 안전하게 실험하고
• GitHub Actions 통합으로 이슈 코멘트만으로 코드 작업을 트리거합니다.

이 네 가지가 맞물리면, opencode는 단순한 코딩 도우미가 아니라 소프트웨어 개발 워크플로 전체를 자동화하는 허브가 됩니다.

내일(12일차, 최종화)에서는 Ollama 로컬 모델 연동, 에어갭 환경 구성, 금융·의료 규제 환경 도입 체크리스트를 다루며 12일 집중 시리즈를 마무리합니다. 데이터가 외부로 나가면 안 되는 환경에서 opencode를 운영하는 방법—시리즈의 대미를 장식할 주제입니다.

---