OpenCode 2.1 작업 목록, 첫 앱의 사용자 검증까지 어떻게 연결할까요?

핵심 요약 (TL;DR)

OpenCode 2.1.0은 2026년 10월 20일 공개됐습니다. 실험 옵션으로 작업 목록을 표시하고, 오래 걸리는 터미널 요청의 연결 문제를 개선했습니다. 초보 앱 제작자라면 기능을 늘리기보다 “무엇을 만들고 무엇을 확인했는지” 나누는 연습에 활용해 보세요. 변경 내용은 공식 릴리스 노트에 나와 있습니다.

OpenCode 작업 목록은 무엇이 달라졌나요?

이번 버전에서는 { "experimental": { "todo": true } }를 켜면 모델에 todowrite 도구를 제공하고 세션과 사이드바에 목록을 표시합니다. 기본으로 켜지는 기능은 아닙니다. 공식 변경 PR도 실험 옵션 뒤에 도구를 복원한다고 설명합니다.

목록의 ‘완료’ 표시와 사용자가 실제로 기능을 쓸 수 있다는 판단은 구분해 보세요. 아래는 출시사가 보장한 성과가 아니라, 작은 앱에서 직접 확인하도록 구성한 실습 제안입니다. 실제 제품을 설치하거나 성능을 측정한 후기는 아닙니다.

첫 앱에서는 어떻게 연습하면 좋을까요?

예제로 문의 접수 화면 하나를 정해 보세요. AI에게 “입력 화면, 빈칸 안내, 제출 결과, 휴대전화 화면 확인을 각각 작업으로 나누고, 완료할 때 확인 근거를 적어 주세요”라고 요청합니다. 첫 실습에서는 결제나 실제 고객 정보는 다루지 않는 편을 권합니다.

먼저 입력 화면만 만들어 직접 열어 보세요. 다음에는 아무것도 입력하지 않고 제출하고, 정상 내용을 넣고 다시 제출합니다. 기대한 안내와 실제 화면을 비교해 기록하세요. AI에게는 “파일을 수정했다는 설명 말고, 확인하지 못한 항목을 따로 남겨 주세요”라고 덧붙여 보세요.

그다음 주변 사용자에게 화면을 보여 주고 설명 없이 문의를 남겨 달라고 부탁해 보세요. 어느 버튼에서 멈추는지, 제출됐다고 이해하는지 관찰합니다. 피드백은 새 기능 목록으로 바로 바꾸지 말고 ‘문구 수정’과 ‘동작 수정’으로 나눠 하나씩 처리해 보세요.

오래 걸리는 명령도 이제 안심해도 될까요?

공식 노트는 Bun의 기본 요청 제한 때문에 긴 TUI 요청이 끊기던 문제를 수정했다고 안내합니다. 모든 작업이 성공하거나 배포가 자동으로 안전해졌다는 뜻은 아닙니다. 자세한 범위는 연결 유지 수정 PR에서 확인할 수 있습니다.

실습에서는 실행 시작과 종료를 구분해 기록해 보세요. 개발 화면이 열렸다는 사실만으로 테스트까지 통과했다고 적지 마세요. 배포 전에는 테스트 결과와 미리보기 주소를 따로 남기고, 사용자에게 보여 줄 화면을 한 번 더 확인하는 절차를 권합니다.

배포 후 확인할 항목도 작업 목록에 미리 넣어 보세요. 예를 들어 새 주소를 다른 기기에서 열기, 제출 후 안내 문구 읽기, 오류가 나면 돌아갈 화면 확인하기입니다. 화면 제작과 공개 후 확인을 서로 다른 항목으로 적으면, AI가 코드를 다 작성한 시점에 검증까지 끝났다고 오해하는 일을 줄이는 데 도움이 될 수 있습니다.

자주 묻는 질문은 무엇인가요?

설정만 켜면 검증까지 자동으로 끝나나요?

작업 목록은 진행 상황을 정리하는 수단으로 활용해 보세요. 이 글의 실습에서는 사용자가 직접 입력하고 결과를 확인하는 단계를 별도로 둡니다.

기존 플러그인을 그대로 써도 되나요?

2.1에는 SDK·HTTP·플러그인 계약의 호환성 변경이 있습니다. 기존 저장 세션을 읽을 수 있다는 안내와 연동 코드가 그대로 작동한다는 의미는 다릅니다. 업데이트 전 공식 호환성 변경 안내를 확인하고 별도 프로젝트에서 점검해 보세요.