OmniFocus 3 안내서 - 4. Reflect, 리뷰(검토)

GTD 시스템 운용의 네번 째 과정 Reflect, 즉 리뷰 단계는 GTD 시스템 운용에서 가장 중요한 역할을 한다. 그리고 이어지는 실제적 실행 및 운영 단계인 Engage 과정에서 진행되는 모든 일에 대한 설계와 평가를 담당하는 부분이기도 하다. 하지만 실제 실행 과정은 OF3와 무관하기 때문에 GTD 프로그램으로서의 운용은 Reflect 과정이 마지막이라고 할 수 있다.

OF3를 시작한 하루, 한 차례에 걸쳐 이전 Capture 과정에 이은 Clarify와 Organize 과정이 마무리 되었다면, 수신함은 비워지고 실행을 앞둔 모든 항목들은 프로젝트 그룹으로 옮겨진 상태가 된다. 결국 OF3의 기본 작업 환경은 수신함과 프로젝트 그룹으로 나눠져 있다고 볼 수 있다.

GTD 시스템의 Reflect 과정은 실제 실행 과정인 Engage 과정에 앞서 계획을 확인하고, 이후 결과를 반영한 관리를 위한 과정이라면 점에서, OF3에서는 프로젝트 화면에서 모든 실행 사항을 계획하고 실행한다. 그리고 정기적으로 OF3의 검토 화면을 통해 업무의 실행 및 진행 여부를 확인할 수 있도록 한다.

그리고 검토 개요가 정기적인 업무 진행 관리 상황을 위한 것이라면, OF3의 프로젝트 개요와 예측 개요는 일상적이고 즉각적인 업무 진행 관리를 위한 기능이라고 할 수 있다.

더불어 특정 상황, 위치 그리고 조건에 따른 업무 현황 관리를 위한 태그 개요과 플래그 지정됨 개요를 함께 활용할 수도 있다. 물론 OF3를 좀더 개인화된 상황에 적합하도록 꾸밀 수 있는 능력이 된다면, Pro 버전을 이용하여 개요를 새로 생성할 수도 있다.

• 프로젝트 개요

프로젝트 개요 즉 프로젝트 화면은 실행 가능한 모든 일상과 업무 항목이 개별 혹은 프로젝트로 구성되어 배치된 곳이다. Reflect 과정의 주된 관리 작업이 프로젝트 개요와 아래 예측 개요에서 진행되는 것에 반해, 태그나 예측 그리고 플래그 지정됨 개요는 상대적으로 사용 빈도나 효용성이 제한되어 있다고 볼 수 있다. 특히 OF3를 GTD 시스템으로서 보다는 일정 관리 시스템으로서의 사용 비중이 높다면 예측 개요를 많이 사용할 수도 있겠으며 그런 경우라면 달력이나 별도 일정 관리 프로그램을 사용하는 것이 더 효율적이라 본다.

OF3의 프로젝트 개요에서는 현재 관리되는 진행이거나 보류중인 모든 프로젝트나 업무 목록을 볼 수 있다. OF3에서의 모든 항목은 순차적 배열이 아닌 사용자가 입력한 순서나 입력한 위치에 설정되기 때문에 마우스를 이용하면 프로젝트와 업무 항목의 순서를 조정할 수 있다. 이점이 OF1 시절과 가장 다른 점인데, OF1에서는 프로젝트나 업무 목록의 각 항목은 마감일이나, 소요 시간 등 여러 요소로 정렬이 가능했다.

프로젝트 구성과 운용은 OF3의 기본적인 운용 방식이기 때문에 별도의 포스팅으로 적어보고자 한다. 만일 OF3에서 프로젝트 단위의 업무 진행 현황이 아닌 전체 관리 항목의 순차적 진행 현황을 기준으로 관리를 하고 싶은 경우에는 아래의 예측 개요를 이용할 수 있다.

• 예측

프로젝트 개요가 계층적 프로젝트 구성으로 OF3에서 관리하는 전체 업무 현황을 보여주는 것에 반해, 예측 개요 화면은 단순하게 보자면 날짜별 업무 목록의 나열이라는 점에서 일반적인 업무 목록 관리 기능이라고 할 수 있다.

실제 프로젝트와 같은 특정 목표를 기준으로 진행 상황을 점검하는 기능이 아닌 날짜별로 연속된 업무 일정을 확인할 용도가 종종 있다. 다만 일 단위로 해야 하는 일이 많다면 화면이 작은 경우 시각적으로 다소 불편할 수도 있다.

예측 개요의 화면 왼쪽에는 한달 치 달력이 배치되어 있고, 해당 일의 업무 항목 수가 표시되어 있으며, 오른쪽 목록에는 마감일 기준 미완료 항목과 현재 실행 항목 그리고 미래 항목이 순차적으로 나열된다. 각 항목의 색상은 마감일 이후 완료 확인하지 못한 항목은 빨간색, 마감일 임박한 항목은 노란색으로 나타난다.

그리고 예측 개요 화면의 오른쪽 업무 목록에 macOS의 달력 프로그램에서 관리되는 사항을 함께 볼 수 있게 되었는데, 표시 화면 구성에서 전체 혹은 일부 달력을 선택할 수 있다.

• 태그 개요

태그 개요의 화면은 개별 업무 항목의 태그 및 프로젝트가 지정된 태그를 임의 순서로 보여준다. 배열 순서는 사용자가 역시 임의로 구성이 가능하다. OF3는 멀티 태그에서도 기존 컨텍스트와 같이 계층 구조를 지원하기 때문에 다양한 구조의 태그 배치가 가능하다.

태그 자체의 활용성과 달리 OF3의 태그 개요 화면을 효용성은 사용자에 따라 다를 수 있는데, 각 태그가 지정된 업무 항목들은 동일한 사전 조건 요소를 공유하고 있다는 점에서 관리 대상에 지정된 사전 조건들이 유사한 사항들과 비교되면서 태그 지정의 적절성을 검토할 수 있다.

GTD 시스템에서의 컨텍스트가 가지는 의미에서 태그의 활용성은 전체 시스템의 운용성과 신뢰성을 유지할 수 있는 요소라는 점에서 활용을 위한 관심과 노력이 필요한 부분이다. 하지만 GTD 시스템의 운용 방식이나 적용 사안에 따라 태그의 범위나 구조가 제각기일 수 있다는 점에서 일률적으로 특정한 태그 구조나 적용 방식 그리고 분류를-비록 참고는 가능할 수 있지만-그대로 따라 한다는 것은 시스템 운용에 심각한 피로감을 초래할 수 있다. 물론 다양한 사용자의 태그 사용과 구조의 효율성을 참고하여 자신에게 맞는 최적의 태그 구성과 구조를 개발하는 것도 나쁜 방법이라 할 수는 없지만, 강조했듯 GTD 시스템을 완벽한 체계로 전제하고 운용하기란 불가능하기 때문에 태그의 구성과 운용 역시 사용자의 상황에 따라 즉각적인 수정이나 변경이 가능한 대상이다.

• 플래그 지정됨

OF3의 플래그 지정됨 개요는 태그와 같은 구조로 연동된다. 즉 태그의 목록 순서나 구조가 변경하면 플래그 개요의 목록로 함께 변경된다. 물론 반대의 경우도 마찬가지이다. 그런 점에서 플래그 지정됨 개요는 플래그 지정이 많지 않다면 사용 빈도가 적을 수 밖에 없다.

반면 플래그 사용이 많다면 즉 의도적으로 활용을 한다면, 별도로 관리할 수 있는 화면을 제공한다는 점에서 효율적인 활용이 가능하다고 볼 수 있다. 결국 OF3의 사용자가 플래그를 어떤 용도로 사용 하느냐에 따라 그 활용성이 결정된다고 볼 수 있다. 예로 GTD 시스템의 주요 관리 규칙에 비춰 어쩔 수 없이 예외적 관리 대상이나 주의해야 할 업무 항목을 별도로 구분하여 사용하는 용도로 활용할 수 있으며, 또는 GTD 시스템에 관리하는 업무 범위 외적인 요소임에도 별도 프로젝트나 폴더로 구분하여 사용할 수 없는 요소에 플래그를 지정하여 운용할 수도 있을 것이다.

• 검토

마지막 검토 개요는 Reflect 과정의 핵심적인 기능 화면으로 앞서 프로젝트 및 각 업무 항목에 설정된 검토 간격에 따라 정기적으로 점검하는 곳이다. 즉 앞서 프로젝트 개요나 예측 개요 혹은 태그 개용 등이 일상적 즉각적 관리를 위한 용도라면 검토 개요는 일주일이나 3일 등 정해진 간격으로 업무 진행 여부 파악과 수정 등을 전체적으로 검토하는 곳이다.

하지만 각 항목에 설정된 검토 간격이 다르기 때문에 일률적이 아닌 해당 간격에 따라 검토 개요에 나타나는 관리 요소가 다르다. 매일 검토해야 할 대상이 있을 수 있고, 일주일이나 이주일에 한번씩 검토해야할 대상도 있을 것이다. 이런 측면에서 개별 항목의 반복 기간과 헛갈릴 수 있는데, 반복 기간은 기본적으로 반복 업무 항목의 추가적 생성을 위한 것이지만 검토 기간은 정해진 일정 간격 단위로 현재 업무 상태를 보여주는 역할을 한다.

GTD 시스템에서 원칙적으로 개별 업무나 프로젝트의 각 항목의 실행 및 완료 그리고 수정 여부는 Refelect, 리뷰 과정에서 수행하는 것이다. 하지만 현실적으로 하루이틀은 커녕 몇 시간만에 진행 여부를 확인해야 하는 경우도 잦은 것이 일상이다. 사실 그런 개별적인 업무는 GTD 시스템에서 관리될 수 없다. 때문에 일정 관리나 별도의 업무 관리 프로그램이 필요한 것이기도 하다. GTD 시스템은 그러한 개별 업무의 실행 여부 보다는 전체적인 시각으로 프로젝트나 주요한 업무의 실행 및 완료 여부를 관리하기 위한 목적이다. GTD 시스템의 이런 보수적, 폐쇄적 기능 구조는 애초부터 컴퓨터 프로그램 운용을 크게 주요하게 다루지 않은 덕분이라고 할 수 있다.

하지만 현재는 GTD 시스템도 현실적인 필요성을 외면할 수 없기 때문에 새롭게 리뉴얼 되면서 리뷰 과정의 반복 기한에 대한 보수적 시각을 해제 되어, 리뷰 과정을 가능한 자주 진행하도록 권장하고 있는 편이다.

때문에 OF1 시절만해도 현재의 Reflect, 검토 과정은 Review 개요에서만 운용하는 것을 원칙으로 했다고 볼 수 있었지만, OF2와 OF3에서는 구조와 인터페이스가 변경되면서 현재와 같은 구성으로 유지되고 있다. 다시 말해 OF3에서는 일상적 업무 입력과 진행에 대한 관리는 프로젝트와 태그를 중심으로 진행하고, 정기적으로 정해진 간격의 업무들은 검토 화면에서 진행을 관리하는 방식이다.

그리고 OF3의 기능적 관리 구성과 구조를 파악했다면, 이러한 리뷰 즉 검토 기능을 어떻게 자신의 업무와 생활 습관에 맞춰 실질적인 Refelct 과정을 구현하는 가에 대한 운용 측면을 생각해볼 필요가 있다.

[OmniFocus의 기본 운용] Review, 프로젝트 관리

GTD의 Review 과정은 단순하게 보자면 계획한 일들이 실행하기에 앞서 필요한 조건이나 상황을 수정 및 정리하는 검토 과정이며 또한 진행 중인 업무나 프로젝트가 계획한 대로 잘 되어가고 있는 지를 정기적으로 검토 및 관리하는 단계이다. 그리고 OmniFocus(이하 OF)에서의 Review 단계는 GTD 운용에 있어 핵심적인 역할을 하는 과정일 뿐만 아니라 OF의 절차적 기능의 핵심이다.

 OF와 비교할 때 Things나 Wunderlist 등은 Review 단계에서의 관리를 사용자가 유연하게(구분된 기능이 없다고 볼 수 있기 때문에) 운용할 수도 있지만 대상 업무 일정이 너무 많은 경우 프로젝트 간의 계획과 검토가 혼란스러워 질 수도 있다. 반면 OF와 같이 Review 기능이 규정되어 있는 경우에는 기본적인 기능에 대한 학습이 선행되고 익숙해져야 효율적 관리가 가능하게 된다. 이런 점에서 OF의 Review 기능은 대부분의 사용자에게 있어 상당히 어색하고 이해하기 힘든 절차로 다가올 수도 있다.

 사실 OF를 시작하면서 처음부터 Review 기능을 적절하게 사용하기는 쉽지 않다. 기능적으로 어렵다기 보다는 이해가 잘 되지 않기 때문이다. 특히 일상에서 진행되는 업무의 양이 많은 것도 문제이지만 각 업무 별로 검토할 시간이 너무 짧게 느껴지기 때문에 느긋(?)하게 업무 관리 기간을 정기적으로 가지기도 쉽지 않다. 그리고 계획한 일들은 개 주변의 변화에 휩쓸려 예측과 다른 방향으로 진행되고 결과적으로 언제나 몸과 마음이 지쳐 있다. 하지만 처음에도 의도적으로라도 정기적으로 차분한 상태에서 OF의 Review 기능을 이해하고 시간을 가지고 적응하여 노력이 필요하다.

1. Review 환경 설정

OF의 Review 기능을 수행에 앞서 생각해야 할 것은 사용자가 Review 기간을 얼마 만에-정기적으로-진행할 것인 가에 대한 결정이다. 사실 OF는-물론 GTD에서도-이 과정은 가장 혼란스러운 부분 중 하나인데 이는 현실에서 Review와 일상의(일일) 업무 관리의 방식과 기준이 명확하게 구별하기 어렵기 때문이다. 일상의 업무 관리는 오늘 혹은-조건이 맞는다면-지금해야 할 일의 목록을 확인하고 실행하고 그리고 한 일에 대한 확인 과정이라고 볼 수 있다. 이에 반해 Review 과정은 일주일 혹은 정기적인 기간 동안 계획한(GTD에서 관리 중인) 전체 프로젝트의 진행 여부를 확인하고 문제가 있는 대상을 조정하는 과정이다. 기능적으로 큰 구별은 없다고도 볼 수 있다. 때문에 두 과정에서 실제 겹치는 부분이 많이 발생하게 된다. 굳이 구분하자면 일일 관리는 개별 업무를 중심으로 그리고 Review는 프로젝트 중심으로 진행된다고 볼 수 있지만, 각 과정의 관리 내용이나 범위를 너무 획일적으로 적용할 필요는 없다. 예로 오늘 해야 할 일 과정에서 전체 프로젝트를 수정할 사안이 있다고 이를 반드시 Review 기간까지 미뤄두거나 반대로 Review 과정 중 일일 업무 내용에 대한 검토를 하지 못할 이유는 없다.

 OF의 Review 기간은 Preferences의 Data & Time 설정에서 지정할 수 있다. GTD에서 추천 혹은 권장하는 Review 기간은 딱히 정해진 것은 아니지만 1 주일 내지는 1 주일을 넘지 않도록 하고 있다. 나는 최근에 이런 저런 일이 많아 3 일에 한번 Review 기간을 설정하고 있지만 상황에 따라 적절한 간격이라고 생각되는 기간으로 설정하면 된다. 하지만 Review 기간을 하루나 이틀 정도로 반복하는 것은 앞서 언급한 일일 업무 관리 범위와 중복될 수 있고 이로 인해 계획한 프로젝트에 대한 필요없는 잦은 변경이 가해질 위험도 있다. 그럼에도 OF의 사용자들은 대개 새로운 업무와 프로젝트 구성 후 자주 진행 상황을 검토하고 픈 의지가 생길 수 있다는 것도 사실이다. 무엇보다도 상황에 맞도록 최적의 기간을 설정하고 일관성 있게 유지하는 것도 중요하다.

 그리고 정기적인 점검 기간은 예로 일주일 단위로 설정했다면 금요일 오후나 토요일 오전 등의 효과적일 것이다. 하지만 Review 과정 자체가 너무 길어지지 않도록 15~30분(일주일 간격 기준) 정도를 미리 염두에 둔다. Review 기간이 짧을 수록 Review 과정의 시간도 짧아 지게 된다.

 Review 기간 설정에서 주의할 점은 기본 설정으로 지정된 기간에서 시작된 프로젝트나 개별적으로 Review 기간을 따로 설정한 프로젝트의 경우에는 기본 설정 기간이 바뀌더라도 기존 설정이 그대로 유지된다. 만일 이러한 경우 해당 프로젝트의 Review 기간을 새롭게 설정하고자 하면 Project 화면에서 해당 프로젝트를 선택한 후 한꺼번에 Review 기간을 재설정해 주어야 한다. 때문에 이러한 조건을 이용하여 특정 프로젝트의 Review 기간을 별도로 설정하므로 써 프로젝트 관리에 효욜적으로 이용할 수도 있을 것이다. 예로 장기적인 프로젝트의 경우 Review 기간을 월 단위로 지정할 수도 있을 것이다.

2. Review 작업 수행

Review 단계의 진행은 OmniFocus의 Project, Context 그리고 Review 화면에서 수행하게 된다. Review 화면 뿐만 아니라 Project나 Context 화면도 함께 사용하는 것은 Review 완료 후 전체 계획에 대한 검토에 따라 프로젝트 및 각 업무의 컨텍스트 수정도 함께 진행할 수 있기 때문이다. 따로 컨텍스트 별로 내용을 점검하는 시간을 가지기 쉽지 않으니 Review 수행 시에 여유가 되면 함께 진행할 수 있으면 좋을 것이다. 혹시나 OF의 Review에 대한 무언가 새로운 기대 혹은 오해를 가진 사용자들이 많을 수 있겠지만, 기능적으로 볼 때 OF의 여러 기본 기능과 다를 바 없다.

 OF의 Review 화면에는 지난 Review 완료 후 정해진 Review 시간에 해당되는 프로젝트들이 나타 난다. 그리고 한번도 Review 과정을 거치지 않은 프로젝트들은 계속 드러나게 있게 된다. 왼쪽에는 Review 대상 목록이 오른 쪽에는 해당 프로젝트의 전체 항목들이 나타난다. 기본적으로 Review 대상의 프로젝트는 활성화된 경우만 보여지고, 내부 목록에서도 완료된 일을 제외된다.

 Review 과정은 프로젝트를 보면서 계획대로 진행 중인지를 먼저 확인하고, 개별 항목 중 완료된 일 중 완료 처리가 되지 않은 항목을 먼저 처리 한다. 이어 전체 진행 상황을 고려하면서 각 항목 간의 우선 순위와 항목의 날짜나 컨텍스트 변경 사항이 있는 경우 이를 수정한다. 필요 없게 된 일이나 이름이나 내용이 수정된 경우도 즉시 변경한다. 검토가 완료된 프로젝트는 Review 완료로 처리한다. 혹은 프로젝트 진행 중 문제가 없거나 실행 전 대기 상태로 인해 별 다른 조치가 없는 프로젝트도 마찬가지로 Review 완료로 처리한다. 필요한 경우 프로젝트 자체를 삭제할 수도 있다. 하나의 프로젝트에 대하여 Review가 완료되면 다음 대상의 프로젝트로 진행되게 된다.

 Review 완료는 프로젝트 내용을 나타나는 화면 상단의 오른 쪽에 있는 ‘Mark Reviewed’를 선택하므로 써 목록에서 글자 색상이 옅어지면서 완료 처리가 된다. 같은 위치에는 Review 대상으로 나타난 프로젝트나 업무 목록은 전체 대상 수와 함께 Review 기간, 지난 번 Review 날짜 그리고 다음 Review 날짜가 나타난다. 아래 예에서 Review 간격은 3일이며 이전 Review 일자는 3월 10일 그리고 다음 Review 날짜는 오늘, 3월 13일로 보인다.

 이러한 방식으로 각 프로젝트에 대하여 이상의 과정을 진행하게 되면 전체 Review 과정이 완료되고 ‘All projects reviewd’ 메시지가 나타난다.

3. Review vs. 프로젝트 관리

OF의 Review 작업에서 가장 의문스럽게 생각될 수 있는 점은 전체 프로젝트 관리를 위해 Project 혹은 Context 화면에서 각 프로젝트나 컨텍스트의 업무 내용을 수정하는 것과 별도로 Review을 수행하는 것의 차이에 관한 것일 수 있다. 앞서 일일 업무 관리와 Review 진행의 차이에서 간략히 적었지만 기능적으로 볼 때 전체 프로젝트 관리와 Review 작업 간에도 기능적으로는 큰 차이가 없다.

 하지만 GTD의 목적이 현재 진행중인 업무들과 향후 추진해야 할 업무들로 인해 발생하는 스트레스를 미연에 예방하는 것이라는 점에서, 시간이 날 때 마다 자주 그리고 전체적으로 진행 중이거나 계획한 프로젝트를 검토하고 수정하는 것은 시간적으로 정신적으로 매우 힘든-또 다른-일이며 스트레이스가 될 수 있다. 때문에 프로젝트 관리를 정기적으로 그리고 기계적으로 처리하므로 써 관리 과정에서 발생하는 스트레스와 이로 인한 프로젝트 관리의 오류를 방지할 수 있도록 하기 위해 별도의 Review 작업을 진행한다고 볼 수 있다. 실제로 OF든 다른 어플리케이션에서 별도의 Review 작업이 아닌 단순한 프로젝트 관리나 컨텍스트 점검 등을 진행해보면 상당한 시간이 소요됨은 물론 작업 자체를 종료하기 힘든 경우도 많이 겪게 된다.

 처음에 OF의 Review 기능의 효용성을 느끼지 못한 상당 기간을 사용하지 않았지만 어느 시점 이후 나름 일관성을 가지고 정기적으로 Review 작업을 수행 함에 따라 실제로 프로젝트 관리 시간이 현저하게 줄어들게 되고 또한 프로젝트 자체에 대한 고민이나 걱정도 상당히 적어지게 되었다고 생각된다. 특히 언제나 현재 진행 중인 프로젝트에 대한 점검이 필요한 가에 대해 불안해 하던 경우도 사라지게 되었다.

 프로젝트 관리에서 다룰 내용이기도 하지만 만일 계획한 프로젝트가 현재 제대로 진행되고 있지 않다면 이에 대한 조치가 반드시 필요하다. 그 조치로는 지연되는 프로젝트의 실행 가능성을 다시 높이기 위해 내용을 점검하고 수정하거나 혹은 조건이 만족 될 때까지 일단 대기 상태로 만들어 다음 Review 작업 시 까지 잊어 버린다 등 다양한 방법이 있을 수 있다. 또한 아직 실행 되지 못하거나 지연 되고 있는 프로젝트라도 정기적으로 검토하므로 써 일상에서 갑자기 머리 속으로 들어와 생각을 복잡하게 만드는 일을 현저히 줄일 수 있게 된다.

4. 새로운 프로젝트의 점검

Review 기능의 일반적인 진행 절차에 포함되면서도 약간 차이가 난다고 볼 수 있는 것이 새로 진행하기 위해 추가된 업무나 프로젝트의 관리에 대한 것이다. 원칙적으로 이러한 대상들도 정기적인 Review 절차에 따라 진행하면 되겠지만 새로운 프로젝트의 경우 초기 입력이나 수정 사항이 많기 때문에 또한 진행 상황을 예측하기 어렵다보니 정기적인 Review 시간까지 기다리기 조급할 경우가 많다.

 이러한 경우를 위해 정기적인 Review 단계를 수행할 시점이 아니더라도 즉시 해당 프로젝트를 점검할 수 있도록 한다. 진행 중인 프로젝트와 달리 새로운 프로젝트의 경우 초기에 설정한 내부 업무에 대해 추가되는 사항도 많으며 수정 혹은 삭제되는 사항도 많다는 점에서 빨리 대응하지 못하면 제대로 된 관리가 힘들어 질 수도 있다고 본다. 만일 프로젝트의 내용 자체가 너무 많거나 복잡하면 OF의 Focus 기능을 사용하는 것도 효율적일 수 있다. 이러한 내용은 실제로는 OF의 프로젝트 구성과 관리 측면에서 다시 언급해야 할 사안이기도 하다.

5. iOS 기반 OF의 Review

Review 작업을 iPhone이나 iPad 버전에서도 수행할 수 있다. 기능적으로 iPhone이나 iPad에서의 Review 작업도 Mac OS X에서와 크게 다르지 않다. 그리고 상대적으로 iPad 버전의 OF에서의 작업이 iPhone 보다는 손이 덜 가기 때문에 수월하다. iPhone에서는 프로젝트와 내부 항목을 한번에 볼 수 없기 때문에 상당히 불편할 수 있다. 다만 역시나 프로젝트 내용이나 이름을 수정하는 등의 작업이 실제 마우스와 키보드를 사용하는 것에 비해 불편하다보니 iOS 기반으로만 Review 작업을 진행하는 것에 대해서는 고민할 필요가 있다고 본다.