@robota-sdk/agent-cli 아키텍처 코드 리뷰

process.exit(), process.stderr.write(), process.stdout.write() 호출이 cli.ts와 bin.ts에만 있는 것이 아니라 startup/ 하위 5개 모듈에 산재해 있다. 이는 두 가지 심각한 결과를 낳는다.

1) 테스트 불가능성: 각 startup 함수를 단위 테스트하려면 process.exit를 목(mock)해야 한다. 실제로 cli-update-check.test.ts와 cli-command-composition.test.ts를 보면 vi.spyOn(process.exit)나 process.stdout.write를 직접 패치하는 코드가 반복되어 있다. 이는 DI 없이 사이드이펙트를 직접 호출한 결과다.

2) 책임 혼재: session-setup.ts의 경우 세션 ID 해석이라는 순수 로직 함수가 process.exit(1)를 직접 호출한다. 이 모듈은 exit 정책을 알 필요가 없다. 반환값으로 오류를 표현(예: Result<ISessionSetup, Error> 또는 예외 throw)하고 exit 결정은 cli.ts에서 일괄 처리해야 한다.

code-quality.md — "ALWAYS use dependency injection for logging and side concerns."

code-quality.md — "Separate core behavior from side concerns."

startup 모듈들은 오류를 throw로 표현하거나 Result 타입을 반환하고, process.exit와 process.stderr.write 호출은 cli.ts의 최상위 try-catch 또는 bin.ts의 catch 핸들러에 집중한다. session-setup.ts의 경우 resolveSessionIdByIdOrName가 undefined를 반환하면 createSessionSetup이 new Error('Session not found: ...')를 throw하고, cli.ts에서 catch하여 exit한다.

SHELL_EXEC_TIMEOUT_MS = 5_000 상수와 execSync 기반 shellExec 클로저가 print-mode.ts와 tui-mode.ts 두 파일에 완전히 동일하게 정의되어 있다. 이는 "No magic numbers or strings" 규칙 위반이며, Parallel collection invariant와 동일한 위험인 '동일 로직의 평행 복사본'을 만든다. timeout 값 변경 시 두 파일을 모두 찾아 수정해야 하며, 하나를 놓치는 버그가 발생할 수 있다.

// print-mode.ts
const SHELL_EXEC_TIMEOUT_MS = 5_000;
const shellExec = (command: string): string =>
  execSync(command, { timeout: SHELL_EXEC_TIMEOUT_MS, encoding: 'utf-8', stdio: 'pipe' }).trimEnd();

// tui-mode.ts — 동일한 코드
const SHELL_EXEC_TIMEOUT_MS = 5_000;
shellExec: (command: string): string =>
  execSync(command, { timeout: SHELL_EXEC_TIMEOUT_MS, encoding: 'utf-8', stdio: 'pipe' }).trimEnd(),

code-quality.md — "No magic numbers or strings. Use named constants." / Anti-monolith: 중복 로직은 단일 소유 모듈로 분리해야 한다.

packages/agent-cli/src/startup/shell-exec.ts와 같은 단일 유틸 모듈을 만들어 SHELL_EXEC_TIMEOUT_MS와 createShellExec() 팩토리를 내보내고, 두 mode 파일이 이를 import한다. 더 나아가 이 어댑터는 CLI의 "concrete local host adapter" 소유 범위이므로 startup/ 계층에서 생성하여 mode 함수에 주입하면 테스트 시 mock으로 교체 가능해진다.

tui-mode.ts는 TuiTransport에 아래처럼 전달한다:

providerOverride: providerSetup.providerSettings.name,
providerType:     providerSetup.providerSettings.name,

IProviderConfig.name은 실제로 provider type 문자열이다 (예: "anthropic", "openai"). 이는 provider-merge.ts의 resolveActiveProvider에서 name: profile.type으로 할당됨으로써 확인된다.

반면 TuiTransport의 providerOverride는 useSideEffects.ts에서 applyActiveModelChange에 전달되어 { providerOverride } 옵션으로 사용된다. applyProviderSwitch나 설정 파일 기준으로는 프로파일 이름(예: "my-anthropic")이 키가 된다. type 문자열을 프로파일 키로 사용하면 모델 전환 시 잘못된 프로파일을 조회하거나 무시하게 된다.

providerType의 경우 SessionStatusBar가 cliAdapter.getProviderDisplayName(providerType)을 호출하므로 type 문자열을 넘기는 것은 올바르다. 그러나 providerOverride에도 type 문자열을 넘기는 것은 오류다. 클리닉 사례가 드러나지 않는 이유는 대부분의 사용자가 type과 동일한 이름의 프로파일을 쓰거나, 모델 전환 기능이 특정 상황에서만 활성화되기 때문이다.

IProviderSetup에 activeProfileName: string | undefined 필드를 추가하고, createProviderSetup에서 opts.provider(프로파일 이름 override) 또는 설정에서 읽은 merged.currentProvider를 그 필드에 저장한다. tui-mode.ts는 providerOverride: providerSetup.activeProfileName과 providerType: providerSetup.providerSettings.name으로 명확히 구분하여 전달한다.