Gemini CLI Release v0.66.0, AI 코딩을 둘러싼 마찰 해소에 초점

Google의 Gemini CLI Release v0.66.0은 2026년 10월 27일 공개됐으며, 터미널 동작, 실행 가시성, 업데이트 신뢰성을 겨냥한 수정 사항을 담고 있다. 이번 변경은 실질적인 긴장을 다룬다. 개발자는 AI 코딩 도구가 작업 중 무엇을 하고 있는지 이해할 필요가 있다. 인터페이스가 깜빡이거나, 활동 상태가 모호해 보이거나, 업데이트가 활성 설치본을 교체하지 않았는데도 성공했다고 보고한다면, 뛰어난 응답도 제한적인 안도감만 제공한다.

이번 릴리스의 의미는 이를 둘러싼 소프트웨어에 있다. CLI, 즉 명령줄 인터페이스는 개발자의 지시와 터미널 내부에서 실행되는 도구를 연결한다. 그 표시 방식과 프로세스 처리는 사용자가 작업을 따라가고, 실패를 인식하며, 언제 개입할지 판단할 수 있는지에 영향을 미친다. 이러한 문제는 어시스턴트가 같은 세션에서 여러 작업을 처리할 때 특히 구체적으로 드러난다.

Claude Code도 개발자의 터미널에서 작동하므로 유용한 경쟁 비교 대상이 된다. 그러나 이번 릴리스만으로 두 제품 사이의 승자를 선언할 근거는 없다. 더 타당한 비교는 각 제품이 제공해야 하는 경험, 즉 읽기 쉬운 활동 표시, 이해 가능한 완료 상태, 기존 개발 도구 주변에서 예측 가능한 동작에 관한 것이다. Gemini CLI의 유지보수자와 사용자에게 이번 업데이트는 이러한 운영 세부 사항을 즉각적인 평가 대상으로 만든다.

Gemini CLI Release v0.66.0이 실제로 바꾸는 것

이번 릴리스는 활동이 표시되는 방식과 로컬 프로세스가 동작하는 방식을 포함해, 모델 응답을 둘러싼 소프트웨어에 집중한다.

공개된 릴리스 변경 로그에는 터미널 렌더링 수정, 스케줄러 변경, 업데이트 처리 보정이 명시돼 있다. 문서와 릴리스 관리 작업도 포함된다. 개별 항목이 서로 다른 종류의 작업을 설명하기 때문에 이 조합은 중요하다. 오래된 로드맵 참조를 갱신하는 일은 부정확한 성공 메시지를 수정하는 일과 같은 실질적 의미를 갖지 않는다.

따라서 독자는 전체 변경 목록을 새로 도입된 기능의 집합으로 간주하지 않아야 한다. 일부 항목은 기존 동작을 수정한다. 다른 항목은 구현 책임을 재구성하거나 프로젝트 문서를 유지한다. 편집상 유용한 질문은 어떤 변경이 개발자가 진행 중인 세션을 이해하고 제어하는 능력에 영향을 주는지다.

터미널 관련 작업은 이 질문을 직접 다룬다. 화면은 어시스턴트가 무엇을 하는지 보여 주는 개발자의 즉각적인 기록이다. 그 기록이 예기치 않게 바뀌면 사용자는 이를 다시 구성하는 데 주의를 써야 한다. 렌더링 수정은 그러한 방해를 줄이는 것을 목표로 하지만, 실제 효과는 여전히 사용자가 애플리케이션을 실행하는 환경에 좌우된다.

업데이트 관련 작업은 다른 불확실성을 다룬다. 사용자가 실행하는 소프트웨어가 실제로 설치하려 했던 버전과 일치하는지에 관한 문제다. 설치 프로세스가 성공하는 것과 활성 애플리케이션이 성공적으로 업데이트되는 것은 서로 다른 결과일 수 있다. 이러한 차이를 보이게 하면 애플리케이션 자체 상태 메시지의 의미가 개선된다.

한편 스케줄러 변경은 관련 작업이 대화 기록에 들어가는 방식을 다룬다. 스케줄러는 도구 요청을 구성하는 구성 요소다. 그룹화 정보를 이 구성 요소로 옮기면 인터페이스가 인접한 활동에서 관계를 추론할 필요 없이 명시적인 경계를 갖게 된다.

이러한 변경은 공통된 성능 결과를 입증하지 않으면서도 운영상 주제를 공유한다. 이는 애플리케이션이 자기 상태를 얼마나 정확하게 설명하는지에 관한 문제다. 화면은 활동을 일관되게 보여 주는가? 완료는 사용자가 기대하는 의미를 갖는가? 업데이트 메시지는 실제로 실행될 소프트웨어를 설명하는가?

Gemini CLI Release v0.66.0에서 이는 버전 번호가 향상된 코딩 지능을 뜻하는지보다 더 강력한 질문이다. 인용된 변경 사항은 추론 품질의 측정된 향상을 입증하지 않는다. 대신 모델을 둘러싼 애플리케이션을 평가할 구체적인 기회를 제공한다.

이 구분은 업그레이드에 관한 이야기에도 한계를 둔다. 수정된 동작의 영향을 받은 사람에게는 이번 릴리스를 살펴볼 구체적인 이유가 있다. 문서화된 코드 생성의 도약을 기대하는 사람에게는 별도의 근거가 필요하다. 유지보수 릴리스는 주장된 해결책에도 같은 수준의 검토를 적용하면서, 자신이 해결하는 문제를 기준으로 평가받아야 한다.

터미널 깜빡임은 개발자에게 부담을 전가한다

불안정한 화면은 개발자가 어시스턴트의 작업을 해석하기 전에 인터페이스부터 해석하게 만든다.

동기화된 출력 변경은 조정된 터미널 업데이트와 더 분리된 스피너 렌더링을 설명한다. 스피너는 진행 중인 활동을 보여 주는 애니메이션 표시기다. 해당 기여에 따르면 애니메이션 업데이트는 이를 표시하는 구성 요소에 더 가깝게 유지돼, 다른 곳에서 불필요한 다시 그리기를 줄인다.

같은 기여는 터미널 세션과 패널을 관리하는 도구인 tmux를 위한 특별 처리도 설명한다. 또한 지원되는 터미널과 동기화 시퀀스를 무시하는 환경을 구분한다. 이 단서는 중요하다. 렌더링 기술이 모든 터미널 구성에서 동일한 동작을 만들어 내지는 않는다.

실질적인 문제는 주의력이다. 백그라운드 작업이 계속 진행되는 동안 개발자가 어시스턴트의 설명을 검토하는 상황을 생각해 보자. 관련 없는 화면 영역이 반복해서 다시 그려진다면, 개발자는 의미 있는 변경과 애니메이션을 구별해야 한다. 이는 릴리스에서 측정된 결과가 아니라 예시적인 작업 흐름이다.

터미널 어시스턴트는 여러 종류의 정보를 전달할 공간이 제한적이다. 지시 사항, 진행 상황, 도구 결과, 개입 요청을 모두 표시해야 한다. 이 요소들은 같은 가시 공간을 놓고 경쟁한다. 화면 불안정성은 애플리케이션이 해결을 도와야 할 바로 그 지점에 불확실성을 더한다.

그 영향은 시각적 선호를 넘어선다. 중단 여부를 판단하는 개발자에게는 현재 활동을 신뢰할 수 있게 보여 주는 화면이 필요하다. 완료된 작업을 검토하는 사람에게는 보이는 기록이 계속 읽기 쉬울 것이라는 확신이 필요하다. 어느 경우도 화려한 표현을 요구하지는 않지만, 둘 다 일관되게 동작하는 화면의 이점을 얻는다.

그렇더라도 더 부드러운 애니메이션만으로 도구 요청이 성공했음을 입증할 수는 없다. 인터페이스는 진행 중인 작업, 완료된 작업, 실패한 작업 사이의 구분을 유지해야 한다. 표시 개선은 이러한 구분을 더 쉽게 관찰하게 할 때 유용하다. 단지 기다리는 시간을 더 기분 좋게 만들 뿐이라면 그 가치는 불분명해진다.

이 때문에 터미널 동작은 전반적인 속도 인상에 포함시키기보다 별도로 평가할 가치가 있다. 더 조용한 화면은 기반 작업이 같은 시간이 걸리더라도 더 빠르게 느껴질 수 있다. 반대로 작업은 빠르게 끝날 수 있지만, 그 표시 방식은 사용자를 혼란스럽게 할 수 있다.

지속적인 터미널 세션을 사용하는 개발자에게 관련 질문은 일반적인 작업에서 화면을 해석하기 위한 중단이 줄어드는지다. 유지보수자에게 과제는 서로 다른 표시 환경에서 그 개선을 유지하는 것이다. 두 집단 모두 실제 사용하는 구성에서 얻은 근거가 필요하다.

이번 릴리스는 다시 그리기 문제를 줄이기 위한 엔지니어링 메커니즘을 제시한다. 개발자 집중도, 작업 완료, 만족도에 대한 독립적인 측정치를 제공하지는 않는다. 이러한 결과는 렌더링 동작을 구체적이고 관찰 가능한 출발점으로 삼아 계속 조사해야 한다.

도구 호출 그룹화는 실행에 더 가까워진다

스케줄러 리팩터링은 병렬 실행 규칙을 바꾸지 않은 채 그룹화 정보를 명시적으로 만든다.

도구 호출 그룹화 리팩터링은 관련 요청을 식별하는 책임을 스케줄러로 옮긴다. 도구 호출은 사용 가능한 도구를 통해 작업을 수행하라는 요청이다. 이전에는 인터페이스가 앞으로 예정된 호출을 검토해 어떤 완료 작업이 함께 속하는지 결정했다.

해당 기여에 따르면, 조건을 충족하는 인접한 하위 에이전트 호출은 이제 공유 그룹 식별자를 받는다. 하위 에이전트는 작업 일부를 처리하도록 위임된 어시스턴트 작업자다. 인터페이스는 완료된 호출 중 어떤 것이 함께 기록에 들어갈지 결정할 때, 자체적으로 그룹화 판단을 재현하는 대신 이 식별자를 사용한다.

해당 기여는 실행 자체는 변하지 않는다고 명시한다. 기존의 병렬 실행 가능성 판단은 여전히 어떤 호출이 동시에 실행되는지 결정한다. 이는 중요한 경계다. 표시를 위해 작업을 그룹화하는 방식을 재구성한다고 해서, 어시스턴트가 이제 더 많은 작업을 동시에 수행한다는 의미는 아니다.

이 변경은 새로운 실행 기능보다는 덜 극적이지만, 신뢰성과는 여전히 관련이 있다. 실행 로직과 표시 로직이 같은 활동을 독립적으로 해석하면 그 의미에 대해 서로 다르게 판단할 수 있다. 명시적 그룹화는 인터페이스가 그러한 해석을 해야 하는 지점 하나를 줄인다.

코드베이스의 서로 다른 부분을 위임해 점검하는 예시적 작업을 생각해 보자. 개발자는 통합된 결과를 보며 완료 상태를 이해하고자 한다. 인터페이스가 이러한 점검을 함께 그룹화한다면, 그 그룹화는 우연한 시각적 순서가 아니라 정의된 관계를 반영해야 한다.

이 아키텍처는 대기에 관한 유용한 질문도 제기한다. 그룹화된 표시는 가독성을 개선할 수 있지만, 개별 구성원이 서로 다른 상태임을 전달해야 한다. 한 작업이 끝났다고 해서 전체 그룹이 끝났다는 뜻은 아니다. 명확한 표시는 이러한 구분을 유지해야 한다.

해당 기여의 설명은 복원된 세션과 관련된 구현 경계를 인정한다. 기존 기록 표시는 여전히 새로운 스케줄러 경로 밖에서 일부 그룹화 동작을 유지한다. 이 단서는 리팩터링을 모든 기록 렌더링 경로의 완전한 통합이라고 설명하지 말아야 함을 시사한다.

유지보수자에게 이점은 구성 요소 간의 계약이 더 명시적이 된다는 점이다. 실행 측은 표시 측이 소비하는 정보를 제공한다. 이러한 배치는 인터페이스가 주변 작업 목록에서 관계를 다시 찾아내도록 하는 방식보다 이해하기 쉽다.

사용자에게 잠재적 이점은 간접적이다. 사용자는 식별자나 내부 구성 요소 경계를 이해할 필요가 없다. 필요한 것은 발생한 일을 정확하게 나타내는 기록과 미완료 작업을 알아볼 수 있게 하는 현재 화면이다.

따라서 Gemini CLI Release v0.66.0은 실용적인 표시 목적을 지닌 아키텍처 정리를 제공한다. 이를 평가하려면 완료, 실패, 중단을 거치는 동안 기록이 일관되게 유지되는지 확인해야 한다. 위임된 코딩이 더 빨라지거나 정확해졌다는 주장을 정당화하지는 않는다.

업데이트 메시지와 백그라운드 프롬프트에는 명확한 결과가 필요하다

어시스턴트의 상태 메시지는, 특히 로컬 도구가 모호성을 만들 때 사용자의 실제 환경을 설명해야 한다.

활성 바이너리 검증은 여러 설치본이 있는 시스템을 다룬다. 바이너리는 사용자가 실행하는 실행 파일 프로그램이다. 명령어를 찾기 위해 검색하는 위치의 순서 목록인 PATH는 오래된 설치본이 새로 업데이트된 복사본보다 우선하게 만들 수 있다.

기여자는 패키지 업데이트가 성공적으로 완료됐지만 실제로 사용 중인 설치본은 이전 버전으로 남아 있던 실패 사례를 설명한다. 이번 변경은 업데이트 절차가 끝난 뒤 확인 단계를 추가한다. 활성 버전이 여전히 오래된 상태임을 검증할 수 있으면, 부정확한 성공 메시지 대신 실패를 알린다.

다만 제한 사항도 있다. 패키지 정보를 확인할 수 없을 때 검증 절차에는 대체 경로가 적용된다. 기여자는 이것이 정상적인 업데이트를 막지 않기 위한 것이라고 설명한다. 따라서 이 변경은 특정 불일치 감지를 개선하지만, 모든 설치 구성에 대해 완전한 정보를 보장하지는 않는다.

더 큰 쟁점은 성공의 의미다. 설치 프로그램은 특정 디렉터리에 소프트웨어를 배치했다는 사실을 정확히 보고할 수 있다. 그러나 애플리케이션이 답해야 할 더 실용적인 질문은 사용자가 다음에 실행할 때 예상한 버전을 사용하게 되는가이다. 두 결과는 겹칠 수 있지만, 서로 바꿔 말할 수는 없다.

이는 문제 해결 과정에서 중요하다. 사용자가 이미 업데이트했다고 믿는다면, 계속되는 문제의 원인으로 버전 차이를 배제할 수 있다. 더 명확한 메시지는 누군가 잘못된 가정을 검증하는 데 시간을 쓰기 전에 설치 우선순위 쪽으로 조사를 돌릴 수 있다.

별도의 Git 프롬프트 수정은 백그라운드 인증 동작을 다룬다. Git은 코드 변경 사항을 추적하는 데 사용되는 버전 관리 시스템이다. 이 기여는 터미널 프롬프트를 억제하도록 의도된 기존 설정이 있어도, 인증 경로에 따라 여전히 상호작용을 요청할 수 있었다고 설명한다.

이 변경은 인증된 원격 액세스에 흔히 사용되는 프로토콜인 SSH를 포함해 해당 경로를 제어하는 방법을 추가한다. 명시된 목표는 인증되지 않은 백그라운드 가져오기 작업이 애플리케이션과 터미널 입력을 두고 경쟁하지 않고 즉시 실패하도록 하는 것이다. 이는 백그라운드 Git 환경에 관한 것이며, 모든 인증 프롬프트를 없애는 조치는 아니다.

이 절충안은 쉽게 설명할 필요가 있다. 인증할 수 없는 백그라운드 작업은 애플리케이션을 계속 사용할 수 있게 해야 하지만, 그 실패 자체는 여전히 해석이 필요하다. 예기치 않은 프롬프트를 막는다고 해서 누락된 자격 증명이 제공되거나 원격 작업이 성공하는 것은 아니다.

두 수정 사항은 같은 원칙을 강화한다. 소프트웨어는 자체 로직과 로컬 환경의 경계에서 의미 있는 결과를 드러내야 한다. 하나의 경계는 설치된 버전과 관련되고, 다른 하나는 인증과 백그라운드 프로세스와 관련된다. 모델 응답에 오류가 없어도 각각 혼란을 초래할 수 있다.

업데이트를 평가하는 팀에는 이들이 점검할 수 있는 구체적인 시나리오다. 관련성은 설치 이력과 리포지터리 접근 구성에 따라 달라진다. 애플리케이션이 전반적으로 더 신뢰할 수 있게 됐다는 광범위한 주장보다, 릴리스를 평가할 더 탄탄한 근거를 제공한다.

신뢰성 주장은 변경 로그를 넘어선 증거가 여전히 필요하다

기여 내용은 표적화된 해결책을 설명하지만, 전반적인 생산성 향상이나 경쟁 우위를 입증하지는 않는다.

터미널 코딩 어시스턴트를 비교할 때 이 구분은 중요하다. Anthropic은 Claude Code를 코드베이스 작업, 일상적인 작업, Git 워크플로를 위한 터미널 도구로 설명한다. 터미널 코딩 워크플로는 사용자가 활동을 추적하고 결과를 판단해야 하는 유사한 작업 환경에 이를 위치시킨다.

이 비교는 공통된 제품 범주를 보여 줄 뿐, 동등한 구현을 뜻하지는 않는다. 여기서 검토한 출처는 어느 제품이 터미널 렌더링, 인증 또는 설치 업데이트를 전반적으로 더 잘 처리한다는 주장을 뒷받침하지 않는다. 공정한 비교를 위해서는 명확히 설명된 조건에서 같은 작업을 테스트해야 한다.

이번 릴리스는 익숙한 질문들에도 답을 남기지 않는다. 영향을 받은 개발자는 각 문제를 얼마나 자주 겪었는가? 어떤 환경에서 가장 많은 실패가 발생하는가? 수정으로 제거되는 중단은 어느 정도인가? 인용된 기여 내용은 이러한 질문에 대해 전체 사용자 집단 수준의 답을 제공하지 않는다.

이런 측정치가 없다고 해서 작업이 중요하지 않은 것은 아니다. 다만 기사가 할 수 있는 주장은 제한된다. 문서화된 실패 모드는 수정이 왜 중요한지 설명하는 근거가 된다. 그렇다고 백분율 개선을 제시하거나 개발자의 광범위한 이동을 주장할 근거가 되지는 않는다.

가장 긍정적으로 해석하면, 이 작업은 운영상의 불확실성을 유발하는 인지 가능한 원인을 겨냥한다. 렌더링, 기록 그룹화, 업데이트, 백그라운드 상호작용은 모두 사용자가 세션을 따라갈 수 있는지에 영향을 준다. 대화형 개발 도구를 개선할 때 엔지니어링 노력을 투자할 만한 합리적인 영역이다.

회의적인 해석도 마찬가지로 구체적이다. 제안된 메커니즘과 병합된 변경 사항은 실제 사용 환경에서 여전히 관찰이 필요하다. 서로 다른 터미널, 설치 구성, 인증 설정은 서로 다른 조건을 만든다. 수정이 의도한 재현 사례를 해결하면서도, 다른 곳의 관련 동작은 해결하지 못할 수 있다.

이 관점들은 억지로 논쟁을 만들지 않고도 공존할 수 있다. 기여자들은 무엇을 왜 변경했는지 설명한다. 사용자는 관련 동작이 자신의 환경에서 개선되는지 판단해야 한다. 독립적인 평가자는 효율성이나 선호도에 관한 더 넓은 주장을 하기 전에 재현 가능한 비교가 필요하다.

운영상의 신뢰성과 결과물의 정확성도 구분해야 한다. 읽기 쉬운 기록은 부적절한 결과를 낸 작업을 정확하게 보여 줄 수 있다. 성공적인 업데이트는 여전히 신중한 검토가 필요한 소프트웨어를 설치할 수 있다. 명확한 인터페이스는 판단을 돕지만, 판단을 대신할 수는 없다.

엔지니어링 팀에게는 평가 맥락을 보존하는 일이 이런 판단을 정직하게 유지하는 데 도움이 된다. 버전, 환경, 관찰된 동작, 그에 따른 작업을 함께 기록하라. 이러한 관찰이 흩어진 기술 메모 속으로 사라질 수 있다면, 검색 가능한 지식 베이스 구축에 관한 지침이 유용하다.

따라서 Gemini CLI Release v0.66.0에 대한 방어 가능한 평가는 구체적이다. 이 릴리스에는 여러 운영상 실패 모드에 관한 문서화된 작업이 포함되어 있다. 이러한 변경이 특정 팀의 코딩 워크플로를 실질적으로 개선하는지는 대표적인 작업을 통해 답해야 하는 경험적 질문이며, 인상만으로 판단해서는 안 된다.

회귀, 업데이트 정확성, 세션 명확성을 살펴봐야 한다

다음으로 유용한 증거는 수정된 동작이 일상적인 개발 작업 중에도 유지되는지에 관한 것이다.

첫 번째 신호는 렌더링 작업의 영향을 받은 환경 전반에서의 터미널 안정성이다. 앞으로 몇 달 동안은 일반적인 칭찬보다 재현 가능한 터미널 구성과 함께 제시되는 보고가 더 유익할 것이다. 의도한 조건에서 깜빡임이 지속된다는 증거는 해결책의 실질적인 적용 범위에 대한 신뢰를 약화시킬 것이다.

가장 강력한 긍정 신호는 정상적인 활동 중에도 상호작용을 유지하면서 읽기 쉬운 출력을 제공하는 경우다. 평가자는 렌더링 회귀와 관련 없는 실행 실패를 구분해야 한다. 그렇지 않으면 별개의 문제가 어시스턴트가 신뢰할 수 없다는 모호한 불만으로 묶이게 된다.

두 번째 신호는 중복 설치가 있는 시스템에서 업데이트 보고의 정확성이다. 핵심 결과는 겉보기에 성공한 업데이트가 사용자가 이후 실행하는 실행 파일과 일치하는지다. 더 명확한 불일치 감지를 보여 주는 보고는 새 검증 절차의 가치를 뒷받침할 것이다.

여기서 대체 경로에도 주의가 필요하다. 패키지 정보를 검사할 수 없다는 사실을 성공적으로 교체됐다는 검증과 혼동해서는 안 된다. 확인된 업데이트, 감지된 불일치, 해결되지 않은 검증을 구분하는 관찰은 증거의 유용성을 크게 높일 것이다.

세 번째 신호는 그룹화된 작업이 완료되거나 실패할 때 도구 기록이 얼마나 명확한지다. 아키텍처 변경은 중단되거나 복원된 세션을 포함해 사용자가 보게 되는 기록을 통해 평가해야 한다. 일관된 기록은 그룹화 정보를 명시적으로 만들기로 한 결정을 뒷받침할 것이다.

반대로 혼란스러운 완료 상태는 스케줄링과 표현의 분리가 여전히 보완되어야 할 지점을 보여 줄 것이다. 유용한 이슈 보고는 기대한 그룹화, 관찰된 기록, 관련 작업 상태를 설명해야 한다. 그런 세부 정보는 유지 관리자가 재현할 수 있는 구체적인 근거를 제공한다.

이러한 신호는 분석이 릴리스의 실제 범위와 연결된 상태를 유지하게 한다. 어느 것도 추측성 시장 전망을 요구하지 않는다. 함께 살펴보면, 변경 사항이 시사하는 핵심 운영상 약속인 애플리케이션이 자신의 동작을 더 정확히 전달하는지를 검토한다.

또한 개발자가 업데이트에 얼마나 주의를 기울일지 결정할 합리적인 근거를 제공한다. 표시 문제나 설치 모호성을 겪는 팀에는 직접적으로 관련된 시나리오가 있다. 다른 팀은 변경의 긴급성이 낮다고 판단할 수 있지만, 일상적인 유지 관리 중 그 동작을 계속 추적할 수 있다.

대표적인 환경에서 익숙한 작업을 기준으로 Gemini CLI Release v0.66.0을 평가하라. 인터페이스 변경이 서로 다른 생성 결과와 혼동되지 않도록 작업, 모델 선택, 검토 기준을 일관되게 유지하라. 표시가 계속 읽기 쉬운지, 실행된 버전이 기대와 일치하는지, 그룹화된 작업이 이해 가능한 기록을 남기는지 기록하라. 관찰된 개선과 더 광범위한 생산성에 대한 가정을 구분하라. 유지 관리자가 조사할 수 있도록 충분한 맥락과 함께 재현 가능한 실패를 공유하고, 성공적인 관찰도 함께 보존하라. 이 릴리스는 개발자가 살펴볼 구체적인 변경 사항을 제공한다. 그 구체성을 활용해 자신의 코딩 세션에서 마찰을 줄이는지 판단하고, 그 결과를 다음 업그레이드 결정에 반영하라.