2장. 실용주의 접근법

스터디 내용은 아래에 정리하고있음
https://www.notion.so/10af59ac13a14d33affe40355f5e9852

Topic 8. 좋은 설계의 핵심

Tip 14. 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다.

ETC 원칙. (Easier to Change)

• 결합도를 줄인다.
• 단일 책임 원칙(Single Responsibillity Principle) : 하나의 모듈은 한 가지 책임만 져야한다.
• 이름 짓기가 중요

ETC는 규칙이 아니라 가치

• 초기에는 의식적으로 노력해야 한다.
• "내가 방금 한 일이 전체 시스템을 바꾸기 쉽게 만들었을까, 어렵게 만들었을까?"

ETC 규칙을 어떻게 지킬지 잘 모르겠을 때

1. 앞으로 어떤 모습으로 바뀔지 모르겠을 때, 언제건 궁극의 '바꾸기 쉽게'라는 길을 선택한다
2. 이런 경우를 직관을 발전시키는 기회로 삼으라
   1. 엔지니어링 일지에 현재 상황과 선택, 그리고 변경 사항에 대한 추측을 정리해 둬라.
   2. 그리고 소스코드에 이에 대한 표시를 남겨 둬라.

ETC원칙. 알고있고 실제로 코드 작성할 때 본능적으로 ETC원칙을 지키는 방향으로 작성하게 되는 것 같다.
그럼에도 불구하고 잘 안된다. 나중에 코드 수정할 때, 얘도 수정해야하고, 쟤도 수정해야하는 상황이 발생한다.

나는 마지막의 "이런 경우를 직관을 발전시키는 기회라 삼으라"라는 말이 인상깊었다. 이러한 시행착오가 다 나를 발전시킬 수 있는 기회가 될 수 있다. 단, 그냥 실수를 많이한다고 되는 것이 아니라, 그 때의 과정을 지금 블로그에 남기는 것으로 노력해야겠다는 생각을 했다.

블로그 앞으로도 더 열심히 해야지...

 

Topic 9. DRY: 중복의 해악

사람들은 대부분 어플리케이션이 출시되었을 때 비로소 유지 보수가 시작된다고 믿는다.

하지만 이 것은 틀렸다. 프로그래머는 늘 유지 보수 모드에 있다. 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.

DRY 원칙: 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.

Tip 15. DRY: 반복하지 말라 (Don't Repeat Yourself)

이 파트는 읽으면서 정말 뜨끔한 부분이 많았다.
하나를 수정하기 위해서 각 조건문의 각 분기를 일일히 수정한 적은 굉장히 많기 때문이다. 수정하면서도 이 코드가 좋지 못하다는건 알고있었다. 하지만 시간이 없어서, 지금도 잘 돌아가니까, 귀찮아서 등등의 이유로 그냥 뒀었다. 앞 장의 "깨진 유리창 효과"였던걸까? 정말 이 책은 가슴을 마구 후벼판다.

DRY를 따르지 않으면 똑같은 것이 두 군데 이상에 표현될 것이다.
하나를 바꾸면 나머지도 바꿔야 한다.

DRY는 코드 바깥에서도 지켜져야한다.
DRY는 지식의 중복, 의도의 중복에 대한 것이다.

1. 코드의 어떤 측면 하나를 바꿔야 할 때, 여러 곳을 바꾸고 있나? 그것도 여러 가지 다른 형태를?
2. 코드를 바꾸고 문서도 바꾸는가?
3. 데이터베이스 스키마와 스키마를 담고 있는 구조 등도?\

9-1) 코드의 중복

중복된 코드

음수를 다루는 부분을 함수화 한 코드

또 만약 클라이언트가 항목 이름과 숫자 사이에 공백을 한칸 더 넣어달라고 하면 어떻게 될까?
다섯 군데나 고쳐야 한다.

 

9-2) 모든 코드 중복이 지식의 중복은 아니다

 

9-3) 문서화 중복

이 함수는 주석으로, 그리고 코드로 두번 표현되었다. 수정이 필요하면 두 군데를 함께 고쳐야한다.
이 코드는 이름이나 코드 구조의 부실함을 주석으로 메꾸고 있다. 코드만 보고도 알 수 있게 자세한 이름을 사용해라.

세세한 주석이 달린 이 예제 코드를 봤을 때, '어 이건 내가 하는 방식인데?' 싶었다.
주석을 세세히 달아놓는게 좋은거라고 생각했다. 하지만 이게 DRY원칙에 위배되는 것이었다니...
코드는 코드만 읽고 이해될 수 있도록 자세히 짜야겠다.

 

9-4) 데이터의 DRY 위반

접근자(getter)를 사용해라.
모듈이 자료 구조를 노출하면 언제나 모듈의 구현과 그 자료 구조를 사용하는 코드사이에 결합이 생긴다.

이 부분은 웹개발자라면 다들 지키고 있을 것이라고 생각한다.
학생때 부터 VO객체를 사용할 때 이렇게 사용하라고 배웠기 때문에 몸에 익었다.
위에서 계속 혼나기만 하다가, 이렇게 늘 사용하던 것이 잘 하고 있는 것이라니 기분이 좋다 ㅎㅎ

 

9-5) 표현상의 중복

API나 다른 서비스를 사용하는 등 외부의 연결은 DRY를 위반하게 된다.
외부에서 정의한 API의 에러 코드를 당신도 알아야만 한다. 한쪽에서만 바꾸면 다른 쪽은 망가질 것이다.
이런 중복을 아예 피할 수는 없지만 다소 완화할 수는 있다.

9-5-1) 내부 API에서 생기는 중복

언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아보라.
이 도구를 이용하여 모든 API정의를 중앙 저장소에 넣어 두고 여러 팀이 공유할 수 있게 하면 좋다.
스웨거, 아파치 스리프트, 구글 프로토콜 버퍼 등이 있다.

이 방법은 구글 프로토콜 버퍼를 이용해서 실제 업무에 적용해봤던 적이 있다.
프로토콜 버퍼를 새로 배우는데 고생을 좀 했지만, 언어에 상관없이 API를 정의할 수 있어서 꽤나 편리했었다.
스웨거도 꼭 써보고싶은 툴 중 하나이다.

9-5-2) 외부 API에서 생기는 중복

명세를 만들어서 공개하는 것을 고려하라

씁... 이게 팁이라고? 싶었다.
이건 회사에서 내가 맨날 하는거다. 근데 이게 너무 불편하다. 한 번 문서 정의가 나가면 사실상 바꿀 수 없다.
내가 문서를 바꾸면 클라이언트도 문서와 코드를 다 같이 바꿔야하기 때문이다. 그걸 놓치는 클라이언트도 있을 것이다. 그래서 바꿀 수 없다.
어쩔 수 없이 output을 최대한 바꾸지 않고 유지보수를 하려다보니 쉽지가않다.
뭔가 꿀팁을 알려줄 줄 알았는데 좀 실망쓰...?

 

9-6) 데이터 저장소와의 중복

많은 데이터 저장소가 데이터 스키마 분석 기능을 제공한다. 이런 기능을 이용하면 저장된 데이터를 객체로 옮기기 위한 코드를 손으로 만드는 것이 아니라, 스키마로부터 바로 생성해낼 수 있는 것이다. 이렇게 귀찮은 일을 줄여주는 영속성 프레임워크도 많이 있다.
 때에 따라서는 더 좋은 방법도 있다. 구조체나 클래스 인스턴스를 사용하는 대신, 그냥 key-value 데이터 구조(해시맵 or Dictionary or JSON 등)을 사용하는 것이다. 이 방식은 필요한 만큼만 데이터에 접근함으로써 생기는 안전장치가 많이 사라지기 때문에 위험하기도 하다. 그래서 이 방식을 쓸 때는 데이터를 한 겹 더 감쌀 것을 권장한다.

여기도 내가 늘상 쓰고있는 부분이기 때문에 할 말이 많다.
첫 번째, 영속성 프레임워크를 사용하면 좋다는 말은 별 이견이 없다. 나도 매일 쓰고있는게 MyBatis이다.
이견이 없는 정도가 아니라 웹개발에서는 이런 프레임워크를 사용하지 않으면 바보거나 그럴 수 밖에 없는 이유가 있는 것이다.

두 번재, 클래스 인스턴스 대신 HashMap을 사용하라는 말은 조금 동의하기 어려웠다.
처음에 내가 회사에 들어왔을 때에는 실제로 그렇게 했다. HashMap은 그 구조가 정의되어있지 않기 때문에 데이터를 넣고 빼는데 구조적으로 유연하므로 개발하기가 편하다.
하지만 이 코드를 나만 보는게 아니라 동료들도 같이 본다는 것이 문제다. 동료들은 일반적으로, 정의되어있는 클래스를 보고 데이터의 구조를 파악한다. 그러나 HashMap은 정의되어있는 구조가 없기 때문에 직관적으로 파악하기가 어렵다.

현재 회사에서는 위 이유 때문에 전통적인 방식인 클래스 인스턴스 방식을 사용하고있다.

 

9-7) 개발자 간의 중복

아마 발견하거나 없애기 가장 어려운 유형의 중복일 것이다.
똑같은 일을 하는 코드가 우연히 중복으로 추가될 수 있고, 이런 중복은 수년 동안 발견되지 않을 수 있다.
아래 방법들로 노력해서 중복을 방지하는 수 밖에 없다.

• 일일 스크럼 미팅 운영
• 슬랙 채널 운영
• 프로젝트 사서를 임명
• 유틸리티 루틴과 스크립트를 모아두는 장소를 마련
• 코드 리뷰 진행

나도 이러한 유형의 중복을 없애는 것이 가장 힘들다고 본다.
코드 리뷰가 참 중요한 것 같다.
그런데 우리회사만 그런건지, 개발자들은 자신의 코드를 들추는 것을 기분 나빠한다. 무언가 자신의 약점이 드러나는 것 같고, 부끄러운 마음이 들기 때문이다.
그런 마음이 드는 것은 나도 동의한다. 그렇기 때문에 더더욱 리뷰를 해야하는 것이 아닐까?
내가 주니어라서 잃을게 없어서 그렇게 생각할 수 있는 것일까? 
나도 PM이 되고, 팀장이 되면 치부를 들추는 것 같은 기분이 들까?

Tip 16. 재사용하기 쉽게 만들어라

사람들은 쉽지 않으면 하지 않을 것이다.
재사용에 실패한다면 지식 중복의 위험을 감수해야 한다.

맞는 말인것 같다.
단편적인 예로 옆 팀의 소스코드가 같은 기능을 하고, 내 코드에 바로 적용할 수 있으면 굉장히 중복을 막을 수 있을 것이다.
하지만 그 코드가 너무 복잡하고 어렵다면 '차라리 내 방식대로 만들고 말지'라고 생각하여 중복을 일으킬 수 있을 것이다.

 

Topic 10. 직교성

컴퓨터 과학에서 '직교성'이라는 용어는 일종의 독립성이나 결합도 줄이기를 의미한다.
하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다.

헬리콥터 조종은 직교적이지 않다.
왼쪽레버를 밀면 부드럽게 착륙할 것 같지만 이 동작은 파생 효과를 일으키기 때문에, 오른쪽 레버를 당기면서 오른 페달을 같이 밟아야 한다. 그리고 이 변화는 다시 모든 조종간에 영향을 끼친다.

Tip 17. 관련 없는 것들 간에 서로 영향이 없도록 하라

이 얘기는 어떤 책을 읽든 정말 주구장창 나오고 있는 것 같다. 그 만큼 중요하다는 뜻이겠지.
나도 코딩하면서 항상 예의주시 하도록 해야한다.

10-1) 직교적 시스템의 장점

1. 생산성 향상
   • 작고 자족적인 컴포넌트를 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 쉽다
   • 재사용을 촉진한다. 재조합하고 개량하기가 쉽다.
   • M가지 일을 하는 컴포넌트와 N가지 일을 하는 컴포넌트가 결합했을 때, M x N 가지 일을 한다.
2. 리스크 감소
   1. 감염된 코드가 격리된다.
   2. 시스템이 잘 깨지지 않는다.
   3. 테스트를 더 많이하게 된다.
   4. 특정 제품, 플랫폼에 덜 종속적이다.

 

10-2) 직교적 시스템의 설계

개발자 대다수는 시스템을 직교적으로 설계해야 한다는 것을 잘 안다.
직교적이라는 것을 설명할 때 '모듈식', '컴포넌트 기반', '계층' 같은 다른 용어를 사용하기도 하지만 말이다.

계층 구조는 직교적 시스템을 설계하는 강력한 방법이다.

계층 구조 그림

설계가 직교적인지 확인하는 방법:
특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?
답은 '하나'여야 한다.

자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.
외부 속성은 어떤 이유에서든지 변경될 수 있다.

• 전화번호
• 주민등록번호
• 우편번호
• 이메일 주소
• 도메인 이름

주민번호를 식별자로 쓰지 않으면 무엇을 써야하는거지?
미국이라서 전산화된 주민등록번호가 없어서 그렇게 얘기한건가?
시스템 내에서 전화번호, 이름, 우편번호 등을 조합한 해시값인 고유 ID같은 것을 만들라는 의미인가?

 

10-3) 툴킷과 라이브러리

외부에서 만든 라이브러리를 도입할 때 시스템의 직교성을 해치지 않는지 주의 깊게 살펴보기 바란다.

라이브러리 버전이 바뀌면서 기존것을 못쓰게 되는 경우가 있기때문에, 나의 경우에는 외부 라이브러리를 import할 때에는 반드시 라이브러리 버전을 반드시 명시하고있다.

 

10-4) 코딩

코딩에서 직교성을 유지할 수 있는 몇 가지 기법

1. 코드의 결합도를 줄여라
2. 전역 데이터를 피하라
3. 유사한 함수를 피하라

여기에서 유사한 함수를 피하라는 말에 뜨끔했다.
시작과 끝에서는 동일한 코드를 사용하지만, 중간의 알고리즘이 다른 함수를 말하는 것이다.
나는 이런 경우가 종종 있었다. 책에서는 이러한 경우에 디자인 패턴 중 '전략 패턴'을 사용할 수 없는지 고려해보라고 한다.
이 책에서 종종 디자인 패턴에 대한 얘기가 나오는데, 디자인 패턴 책을 읽기를 잘한 것같다.

 

10-5) 테스트

직교적으로 설계하고 구현한 시스템은 모듈 수준의 테스트가 가능하기 때문에 테스트하기가 훨씬 쉽다.
단위 테스트를 작성하는 행위 자체가 직교성을 테스트해 볼 수 있는 기회이다.
버그 수정은 시스템의 직교성을 총체적으로 점검해 볼 수 있는 값진 시간이다.

10-6) 문서화

직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있다.
워드프로세서의 스타일시트와 매크로 or 마크다운을 사용하면 된다.

10-7) 직교적으로 살아가기

 

Topic 11. 가역성

당신이 가진 생각이 딱 하나밖에 없다면, 그것만큼 위험한 것은 없다
- Emil-Auguste Chartier <<Propos sur la religion(종교론)>>

흑백논리로 가득한 요즘 세상에 정곡을 찌르는 말 아닐까. (갑자기 철학적...)

어떤 사실을 굳게 믿고 그 사실에 전적으로 의존하고 있다 하더라도 그 사실 역시 언젠가는 변한다.

프로젝트가 진행되면서 중요한 결정 하나하나가 프로젝트 팀을 점점 더 달성하기 힘든 목표로 몰아넣는다.
중요한 결정이 많이 내려졌을 즈음엔 목표가 너무 작아져서 목표가 움직이거나, 바람의 방향이 바뀌거나, 도쿄의 나비가 날개짓을 한다면 여러분의 겨냥은 빗나갈 것이다. 아마 매우 큰 차이로 빗나갈 것이다.

특정 업체의 DB나 아키텍쳐 패턴, 배포 모델을 사용하기로 했다면 큰 비용을 치르지 않고는 되돌릴 수 없는 행동을 하기로 묶여버린 셈이다.

(오마이갓)

11-1) 가역성

A 데이터베이스에서 B 데이터베이스를 사용하는 것으로 프로젝트가 바뀌었다. 올바르게 추상화하여 영속성을 하나의 서비스로 제공하도록 만들었다면 달리는 도중에 말을 갈아탈 수 있는 유연성이 생길 것이다.

웹 브라우저 기반 애플리케이션을 모바일 앱 기반으로 변경된다고 한다. 이상적인 상황이라면 적어도 서버 쪽은 큰 변화가 없어야 한다. HTML 렌더링을 걷어내고 API로 대체하기만 하면 될 것이다.

결정이 바뀌지 않을 것이라 가종하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다.

Tip 18. 최종 결정이란 없다.

변경될 수 있다는 가능성을 열어두고 프로그램을 짜라는 것은, 직교하도록 하라는 말이고, 그 말은 계층별로, 모듈별로 프로그램을 짜라는 말이다. 결국 계속 같은 말을 하고있는 것 같다.
그런데 데이터베이스를 갈아타는 일은 어떻게 한다는 말인가?
예를 들어서 우리팀은 사용중인 Oracle을 MySQL로 모두 바꿔야할 수도 있는 위기에 처해있다.
그런데 단순한 SQL을 제외하고는 문법부터가 다르기 때문에 (예를들면 현재 시간 조회, JOIN방법 등) 거의 모든 쿼리를 MySQL의 문법에 맞게 다시 수정해야한다.
이 것도 대비할 수 있는 것인가?????
다행이라면 MyBatis를 사용하고있기 때문에 sql-template만 수정하면 Java소스는 크게 수정할 부분이 없다는 것이다. 책에서는 이걸 말한건가...

 

11-2) 유연한 아키텍쳐

앞으로 아키텍처가  어떻게 변할지 모르는 변덕스러운 환경에서 계획을 세울 수 있을까? 못한다.
할 수 있는 것은 바꾸기 쉽게 만드는 것이다. 외부의 API를 추상화 계층 뒤로 숨겨라. 코드를 여러 컴포넌트로 쪼개라.

Tip 19. 유행을 좇지 말라.

누구도 어떤 미래가 펼쳐질지 알 수 없으며, 우리 분야는 특히 더 그렇다. 코드가 Rock n Roll할 수 있게 하라.

코드를 때론 Rock과 같이 단단하게, 때론 Rollable 즉, 유연하게 하라는 뜻인가?
지금까지 이 책을 읽은 바로는, 현재 유행하는 스타일의 아키텍쳐를 구성했다가도, 다른 효율적인 아키텍쳐가 등장하면 그렇게 수정할 수 있도록 유연하게 해야한다고 배웠다.
유행을 좇지 말라는건 아마도 지금 유행하는 스타일에 맞추고, 변경하기 힘들게 하지 말라는 뜻이라고 생각된다.

 

Topic 12. 예광탄

 

예광탄은 순식간에 목표물에 도달하고, 기관총 사수는 즉각적인 피드백을 얻을 수 있다.
코딩에서 동일한 효과를 얻으려면 우리를 요구 사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가를 찾아야 한다.

Tip 20. 목표물을 찾기 위해 예광탄을 써라.

위 그림은 내가 프로젝트를 시작할때 항상 쓰는 방법이다.

1. 프로젝트 생성
2. 프로젝트 환경 설정
3. Printf문 찍어보기
4. DB 호출만 하는 간단한 서비스 로직 생성
5. 데이터 모델 생성
6. 간단한 쿼리 호출 및 확인

Spring은 컨트롤러, 서비스 레이어, DB연결, 쿼리 모두 분리되어 개발하도록 권고하고있기 때문에 뭔가 하나를 갈아끼우기가 비교적 수월하다.
예를들어 지금 우리팀에서는 로그를 DB에 쌓을 때도 있고, Kafka에 전송할 때도 있다. 두 가지 모듈이 개발되어있고, 스위치를 ON/OFF 함으로써 갈아낄 수 있도록 설계되어있다. 예광탄이 DB를 맞추고있다가 아니다 싶으면 Kafka를 쏘도록 조종간을 조절하면 되는 것이다.

 

Tip 21. 프로토타이핑으로 학습하라

이 글을 읽기 전까지 프로토타이핑과 예광탄 코드의 차이점을 몰랐다. 둘 다 간단하게 기능을 구현한다는 것이므로 같은 줄 알았다.
하지만 책을 읽으면서 알게된 가장 큰 차이점은, 프로토타입은 결국엔 그것을 버린다는 것이다. 버리고 처음부터 새로 만든다. 파이썬으로 쉽게 구현한 뒤에 본 개발은 C++로 로우레벨부터 시작할 수도 있는 것이다.

나는 프로토타이핑을 해본 적이 없는 것 같다. 듣기로는 너무 아깝다. 간이로 만들긴 했지만 결과물을 버려야한다니. 나라면 여기에 살을 붙이는 방식을 선호할 것 같다.

Tip 22. 문제 도메인에 가깝게 프로그래밍하라

책의 내용이 잘 이해되진 않아서 도메인이 무엇인지 찾아봤다.
여기서 도메인이라고 표현하는 것은 일반적으로 도메인 특화 언어(DSL)이라고 불리운다. 
"도메인 특화 언어는 관련 특정 분야에 최적화된 프로그래밍 언어입니다."

테스트 등을 위해서 비개발자가 사용할 수 있도록 만들어진 언어인것같다. 반드시 프로그래밍 언어를 사용해서 문제를 해결하려고만 하지말고, 도메인 언어를 사용해서 문제에 접근하면 다른 시각으로 해결할 수 있다는 말을 하고있는 것같다.
도메인언어라는 것을 처음 알았기 때문에 와닿지는 않지만, 기회가 된다면 써보고싶다.

Tip 23. 추정으로 놀람을 피하라

"얼마나 걸릴것같아?"
"언제까지 끝낼 수 있어?"
회사에서 거의 맨날 듣는 말이다. 처음에는 이 말에 대답하는게 너무 힘들었다. 경험이 없다보니 아예 감조차 잡을 수 없었다. 지금은 저 질문을 듣는 순간, 대략적인 프로세스가 머릿속에 그려지고 각 프로세스별 소요시간을 대략적으로 계산해서 언제까지 완료할 수 있는지 대답할 수 있게 되었다.
그런데 여기에서는 더 참신한 방법으로 추정할 수 있는 방법을 알려주었다. 미 해군에서 사용한 PERT라고 부르는 방법론에서 쓰인 추정 방식이다.
낙관적 추정치, 가장 가능성이 높은 추정치, 비관적 추정치를 모두 계산해서 전체 프로젝트의 예상 최소 및 최대 소요시간을 계산한다. 추정이 범위로 나오는 것이다.
추정을 할 때, 나는 보통 뭔가 문제가 생길 경우를 생각해서 여유있게 추정을 하게된다. 하지만 아무런 문제가 없이 일이 잘 진행될 경우 예상보다 매우 많은 시간이 남게된다. 그럴 때 이런식으로 범위로 추정을 했다면 아마 오차범위 안에 들어갔을 것 같다.

Tip 24. 코드와 함께 일정도 반복하며 조정하라.

각 주기를 한 번, 두 번 반복하면서 몇 주기정도 필요할지 예상을 해라. 반복 주기가 끝날 때 마다 추측을 더 다듬다 보면 일정에 대한 확신도 커질 것이다. 하지만 경영진은 이 방법을 좋아하지 않는다. 그들은 프로젝트가 시작되기도 전에 하나의 정확한 숫자를 원하기 때문이다 (ㅇㄱㄹㅇ)
경영진에게 팀, 팀의 생산성, 그리고 환경이 일정을 결정한다는 것을 이해시켜야한다. 누군가 추정해달라고 하면 "나중에 연락드릴게요"라고 일단 대답한 뒤, 위의 과정을 밟아가며 추정치를 얻어야한다.
커피머신 앞에서 허투루 말한 추정치는 여러분에게 해를 끼칠 것이다.

정말 공감이 가는 말이다. 함부로 추정했다가는 독이되어 나에게 돌아오기 마련이다. '나중에 알려드릴게요' 방법을 애용하도록 해야겠다.