sosa0sa.com

원문 : Assessing Test Driven Development at IBM

IBM에서 JavaPOS 과제에 대해 TDD를 적용한 사례 정리

기존 과제에서의 Unit Testing

• 대부분의 경우 Unit testing은 개발이 이루어진 후에 일어남.
• 일정이 빠듯한 경우 생략됨

JavaPOS 과제에서는

• 생소한 방법론이나 생산성에 대한 우려를 해소하기 위해 일정 수립에 심여를 기울임.
• 개발자와 매니저의 반발
• 기존 과제를 분석하여 400 LOC/MM 를 목표로 설정함
• 생산성 factor
  • Defect rate - defect rate in short term and long term
  • roductivity - LOC/MM
  • Test Frequency - ration of interactive vs. automated test? how often?
  • Design - more robust design?
  • integration - smoother code integration?
• XP에서는 전체 디자인을 하지 않고 코딩을 하지만, JavaPOS의 경우 요구사항이 비교적 유동적이지 않아 UML을 이용하여

Big Design Up Front를 수행함.

• 중요 클래스에 대해 unit test를 강제화함.
• 중요 클래스에 대해 80%의 자동화된 unit test를 목표로 함.
• Build & Unit testing in Daily
• Unit test는 정상 경우, 예외처리(특히 boundary value)를 포함

결과

• FVT(Functional Verification Test) 기준 기존 대비 50%의 defect rate를 보임.

• TDD(w/ Unit testing)은 개발 초기에 도입해야 함

• 핵심 항목에 대해서는 Unit Test 강제화도 고려할 필요가 있음

요즘 “소통의 부재”가 유행이다.

그런데 그 “소통의 부재”가 청와대와 국민 사이에만 있는 것은 아닐 것이다.

회사 내의 “소통의 부재”는 참 많은 생각을 하게 한다.

Agile에서 적극 추천하고 있는 “Stand-up meeting”을 시행하고 있다. 시작한 지 1년이 훨씬 넘은 듯하다.

하지만 한 번도 Agile에서 기대하고 있는 것처럼 적극적인 의사교환이나 정보 교환을 본 적이 없다.

늘 대장 노릇을 하는 사람이 주절주절 이야기를 하고, 나머지 사람들은 땅을 보거나 모니터를 보거나 가끔은 대장을 보거나.

피드백? 그런 거 별로 없다.

게다가 대장이 해주는 이야기는 대부분 진행 중인 과제의 “문제점”인 경우가 많아 듣기에 썩 좋은 이야기는 아니다. 타산지석으로 삼으면 좋겠지만 아쉽게도 전달하는 사람은 항상 “저런 저런 문제가 있었다. 우리는 이게 문제다”가 논지이기 때문에 과히 듣기 좋지는 않다. 맞는 이야기겠지만 비슷한 톤으로 비슷한 논지의 이야기를 주 5일 듣는다고 생각해 보자. 끔찍하지 않은가? 이건 마치 예전 5공때 9시 뉴스에 앵커나 늘 “오늘 대통령 각하는”으로 시작하는 기사를 매일 보도하는 거랑 다를 바가 없다.

아쉽다.

같은 이야기를 하더라도 조금만 다른 투로 친근하게, 때로는 능글맞게, 그리고 피드백을 쉽게 할 수 있는 분위기를 만들면서 한다면 좋겠는지.

그런 분위기를 만드는 게 쉽지는 않겠지만 노력을 안하는 듯 하니.

여기도 “소통”의 문제가 심각하다.

“소통”이 없으니 “팀 웍”을 꿈도 꾸지 못하고, 남이 뭐 하는 지 알 수도 없다.

우리는 왜 긍정적인 회고를 하지 못하는가?

• 짜증스런 목소리로 “왜 잘못했냐고?” 소리치는 매니저가 만들어 놓은 아픈 상처때문에?
• 짜증스런 표정으로 의자에 엉덩이를  걸치고 앉아 핸드폰 게임만 하고 있는 개발자들때문에?
• 해봐야 소용없다는 회의적인 생각때문에?
• 얄팍한 자존심때문에? 이미 패치내서 지난 간 일을 들쳐내기 싫어서?
• 왜 회고를 맨날 골방에서 큰 소리를 내가면서 해야 할까? 왜 밝은 장소에서 할 수 있는 분위기가 안 되는 걸까?

우리는 안 하는 걸까? 못하는 걸까? 둘 다 겠지.

어떻게 하면 바꿔갈 수 있을까?

예전에도 한번 “잔업없는 회사”라는 내용으로 접한 적이 있었는데 우연히 어떤 글을 보고 다시금 찬찬히 그 회사의 글들을 보게 되었다.

(주)사이냅소프트

많은 IT업체가 그렇듯이 회사의 생활등을 블로그를 통해 접할 수 있다(우리도 IT업체인듯 한데 그러기엔 우린 엄살이 너무 심하지. 뭐 그리 숨길 게 많다고)

그 중에는 사이냅소프트의 전경헌 사장님과의 인터뷰 글도 볼 수 있는데 사장님의 생각을 통해 회사의 생활이 어떨 지 짐작할 수 있다(반론의 여지가 있는 말이긴 하다. 윗사람의 생각대로 회사가 움직인다고 단정지을 수 없기 때문이다. 구름 위에 있는 사람이 갖는 생각과 현실은 다를 수 있으니. 그래도 일단 들어보자)

그 중 일부다.

유용빈: 정치적 스트레스는 어떻게 해결하시나요. 회 사 내에 그런 스트레스가 얼마나 있는지 제가 잘 알지는 못합니다만 다른 회사에 비해서는 상대적으로 적으리라 생각합니다. 개발자들이 지원하는 역할에 머무르는 회사가 많은데 사이냅소프트는 저부터 시작해 영업 직원들도 개발자 출신이라 서로 이해하는 부분이 많아 갈등이 크지는 않습니다. 또 지난해 애자일 컨설팅의 컨설팅을 받으면서 회고하는 문화가 자리잡고 있습니다. 회고란 체계적으로 즐겁게 반성하고 개선점을 찾는 활동인데 그 이후로는 회사에 있던 문제들에 대해 서로 동등한 수준에서 의사 소통을 하면서 그와 같은 스트레스가 더 줄고 있다고 봅니다.

이국진: ‘가정을 지키기 위해 일찍 퇴근한다’는 글을 쓰셨는데 정시 퇴근은 잘 지켜지나요. 그 글은 2005년에 쓴 글입니다. 전에는 일을 굉장히 많이 했습니다. 결혼하고 나서도 아침에 일찍 출근하고 막차 시간이 거의 다 됐을 때나 새벽에 집에 들어갔습니다. 집에서는 잠만 자고 휴일에도 회사에 나와 일하기도 했습니다. 거의 일만 하는 사람이었죠. 일로서 성공하고 싶은 생각도 많았고요. 2005년은 큰 아들이 유치원에 다니던 해였는데 밥 먹으면서 유치원 생활에 대해 아들에게 물었는데 아이가 대답을 하지 않았습니다. 아내가 대신 이야기를 해줬지만 아들에게 직접 듣고 싶다고 말을 거니 아이가 “아빠는 알지도 못하면서 아는 체 해”라고 말했습니다. 그러고 보니 아이가 보기에는 자기가 일어나기 전에 회사에 나가고 자고 있을 때 집에 들어오니 자신에 대해 아무것도 모른다고 생각하는 게 당연하겠더군요. 물론 아내를 통해 아이가 어떻게 지내는지 늘 듣고 있었지만요. 굉장히 충격을 받았고 이게 제가 원하던 삶은 아니라는 걸 깨달았습니다. 아이가 태어날 때만 해도 크는 동안 많이 안아주고 좋은 이야기를 들려주고 싶었는데 열심히 일하다 보니 어느새 아이는 자라 학교 갈 나이가 되어 있더군요. 세상은 장기전이고 그러려면 가정도 지켜야 하고 저뿐만 아니라 직원들도 마찬가지라는 생각이 들었습니다. 그 때부터 열심히(?) 저녁에 일찍 퇴근하고 있습니다. 아이들이 굉장히 좋아하고요. 요즘은 간혹 집에서 저녁 먹고 들어오라는 전화가 옵니다.(웃음)

오랜 기간 몸에 밴 야근이란 습관을 되돌리는 데 반발은 없었나요. 야 근을 하느냐 하지 않느냐가 좋은 개발자를 판단하는 기준은 아닐 겁니다. 책임감이 굉장히 강한 개발자들은 맡은 일이 진전되는 것을 확인하려고 야근을 하기도 합니다. 야근 금지를 반대하는 개발자들도 있었습니다. 회사에서 뭐라 하든 ‘내 일이기 때문에’ 야근을 해도 상관 없다는 이유 때문이었죠. 소프트웨어 개발은 장기전이고 몇 달 바짝 해서 성공하는 게 아니기 때문에 자신의 건강과 가정을 지키며 일하자고 계속 설득해 지금은 야근 금지가 많이 정착되어 특별한 일이 있지 않는 한 다들 일찍 퇴근합니다.

지금도 개발을 하시나요. 예. 수시로 하고 있습니다. 직원들이 개발을 하다 문제에 부딪히면 같이 살펴보기도 하구요. 프로그래밍 공부도 꾸준히 하고 있습니다. 제품 코딩보다는 직원 교육을 위한 코딩 위주로 하고 있습니다. 최근에는 파이썬을 많이 쓰는데 아이디어가 떠오르면 파이썬으로 빠른 시간 안에 구현할 수 있어 직원들이 어떤 문제에 막혔을 때 그것을 푸는 데 도움이 될 만한 코드를 파이썬으로 짜서 보여주기도 합니다. 개발이 여전히 좋아 은퇴 후에도 코드를 짜는 걸 즐기지 않을까 합니다.

앞으로 구상이 있으시다면 소개해 주세요. 지 금까지 한국 소프트웨어 개발사들을 보면 유명 개발자 한두 명에게 크게 의존하는 경우가 많았는데 그런 방식에는 한계가 있다고 봅니다. 문화를 잘 가꾸며 체계적으로 개발을 하는 회사가 성공하는 사례가 나와야 할 것 같습니다. 좋은 소프트웨어를 만드는 데 필요한 것이 있다면 기꺼이 받아들여 배우고 적용할 계획입니다.

또 다른 글,

다양한 기능은 어떻습니까? 마이크로소프트 오피스에는 수없이 많은 기능이 있습니다. 그러나 우리가 사용하는 기능은 매우 단순한 몇가지에 지나지 않습니다. 그 많은 다양한 기능은 어디다 쓰는 것이죠? 그 기능들을 개발하느라고 수없이 많은 개발자들이 시간을 쏟아 부었을텐데… 우리한테 어떤 의미가 있습니까? 사실상 거의 의미가 없죠. 일반인들이 워드에서 XML로 저장하는 기능을 사용할 일이 있겠습니까? 엑셀에서 포아송분포를 계산할 필요가 얼마나 있겠습니까? 그러한 다양한 기능들은 영업을 위한 자료에 사용될 문장 몇개 만드는 것 이상의 용도가 없습니다. 핵심기능이 잘되는 것이 훨씬 중요합니다. 일정과 기능도 무시 못할 요소이기는 하지만, 결코 품질보다 중요하지는 않습니다.

…

먼저, 정치적 환경입니다. 이건 언제나 발생하고 가장 골치아프고, 해결하기 어려운 것 중에 하나 입니다. 팀장이상 급에서는 어느 정도 신경을 쓸 수 밖에 없죠. 정치적 환경에서 발생하는 문제는 임원들에게 알려주세요. 임원들이 해결하도록 하겠습니다. 정치적 환경 때문에 골치아파 하지 마십시오. 임원들이 해야하는 역할 중에 하나가 정치적 문제를 없애는 것입니다.

두번째로는 기술적 환경이 있습니다. AIX에서 돌아가는 프로그램을 짜야하는데 AIX가 없으면 안되겠죠. PC가 2대 있으면 금방 해결할 수 있는 문제라면 한대 더 사야겠구요. 지금 쓰고 있는 컴퓨터가 느려서 컴파일시간이 오래걸리면 바꿔야죠. 메모리가 부족하면 늘려야겠구요. 기술적인 환경은 약간의 비용을 들이면 쉽게 해결이 가능합니다.

…

우리 인트라원 자유게시판에 보면 “빌게이츠 찾아가는 법”이라는 제목으로 지도 3장이 올려져 있을 것입니다. 아마 관심있게 본 사람들은 알 수 있었겠지만 마이크로소프트 메인 캠퍼스의 대부분 건물들은 십자(+)형이나 에이취자(H)형으로 되어있습니다. 우리나라 건물들이 대부분 박스(ㅁ)형인 걸 생각하면 매우 특이한 것입니다. 마이크로소프트 메인 캠퍼스에도 박스형 건물들이 몇개 있지만 강당 등 공통 공간인 경우입니다. 직원들이 일하는 공간은 대부분 십자형과 에이취자형 건물입니다. 박스형건물이 건축비가 싸게 먹힌다는데… 왜? 십자형과 에이취자형으로 건물을 지었을까요? 십자형과 에이취자형 건물의 특징은 좁은 복도와 복도 양쪽으로 창이 딸린 방을 배치할 수 있다는 것입니다. 즉, 마이크로소프트는 메인 캠퍼스에 근무하는 모든 사람에게 창이 딸린 작은 방(1인실 또는 2인실)을 주고 있습니다. 너무 돈이 많아서, 돈질을 하는 걸로 보이나요? 빌게이츠씨가 헛 돈 쓰는 거 봤습니까? 차라리 기부를 하면 했지, 과시를 위해서 돈쓰는 건 아닐 겁니다. 또, 빌아저씨쯤되면 과시하지 않아도 누구나 인정하는 세계에서 제일 돈이 많은 사람이잖아요. 빌아저씨가 소프트웨어 회사에서 생산성과 품질을 높이는 가장 좋은 업무 환경을 연구해서(연구비줘서 시켰겠죠) 실현한 것이라 생각합니다.

자, 어떤가?

흔한 말로 생각이 바로 박혀있는 것처럼 보이지 않는가? 어떤 회사의 사장이란 사람이 저런 위험한(?) 말을 할 수 있을까? MS의 건물 배치에 대해서는 피플웨어에서도 언급했던 내용인데 우리 회사 매니저중에 얼마나 많은 사람들이 그 책을 봤을까? 내 근처 사람중에 단 한 사람이라도 본 적이 있을까?(이런 S/W 생산성에 관한 책을 정리해서 공유 해볼까?)

구글 리더에 등록했는데 최근 10개만 보여서 열심히 블로그 페이지에서 직접 글들을 읽고 있다. 볼만한 내용이 너무 많다.

• 사이냅은 이렇게 개발합니다
• XP적용하면서 사무실분위기가 달라졌어요
• SW개발에서 ‘Peer Review’의 중요성
• 운전배우기
• 가정을 지키러 갑니다
• 새 사무실 인테리어에 관한 이야기
• 좋은 프로그래머가 되기 위한 방법
• 우리가 만들어야하는 좋은 소프트웨어란 무엇인가?
• [김익환의 '대한민국에 SW는 있다'] 진정한 SW 전문가란…’과거형’과 ‘미래형’의 차이
• 정말 좋은 소프트웨어 개발하려는 사이냅 개발체계
• 이런 개발자면 더할 나위 없이 좋겠습니다!
• 사이냅소프트가 괜찮은 회사인 이유 10가지

다만 블로그에 댓글이 그리 많은 편이 아닌 것이 아쉽다.

과연 우리 회사는? 우리 회사 역시 세상이 좋다고 하는 것 중 몇 개는 따라 하려고 한다. 다만 항상

• Top-down
• 수치를 통관 관리
• 안하면 갈금

의 형식을 갖는다. 왜 해야 하는 지에 대해 충분히 설명하고(당연한 것도 있겠지만) 자발적으로 하는 문화를 만들기 보다는 늘 명령하달식으로 진행한다. 위키를 설치해서 사용하는 것을 몇 번 보여줬는데 맘에 들었나 보다. 위키를 많이 사용하라고 권고하기 시작했다. 조만간 주간별 포스팅 수등을 관리하면서 1인당 포스팅 갯수를 할당하지 않을까 걱정이다 -_-

코드와 로그는 나만을 위한 것이 아니다.

• 나의 코드를 받아서 책임 지게될 후임자의 것이다.
• 나와 관계된 블럭 담당자의 것이다.
• 내  블럭이 제공하는 기능을 시험하는 시험자의 것이다.

자기만 사용할 거라고, 자기만 볼 거라고, 이전 담당자가 코드를 엉망으로 작성해서 그런 거라는 핑계는 대지 말자.

현재 그 코드를 담당하는 사람이 자신이면, 자신이 모든 걸 책임져야 하는 것이다.

자신의 외모에 신경쓰는 것의 일부만이라도 코드에 신경을 써주자.

제발 부탁이다.

• 우리는 책임 있는 프로그래머로서 코멘트를 잘 달아야 할 의무가 있다.
• 코멘트가 필요없을 정도로 좋은 코드(스스로 문서화 하는)를 작성하라.
• 코드를 묘사하지 말고, 왜에 대해서 설명하는 코멘트를 작성하라.
• 과거에 무엇을 했는지 기록하지마라. 그것은 리비전 컨트롤 시스템이 알아서 할 것이다.
• 나쁜 코드는 문서화하지 말고 다시 작성하라.
• 명료하고 일관성있게 작성하라.
• 하나의 사실은 한 곳에만 작성하라.
• 코멘트는 과거가 아니라 현재 속에서 살아야 한다. 코드가 바뀌었다거나 예전에 뭐가 어땠었다는 기술은 하지 마라.
• 코드를 변경할 때 그 주변에 있는 코드도 모두 유지보수하라.

Agile 관련 책에서도 유사한 내용이 나오지만 코멘트는없으면 없을 수록 좋다. 코드만으로도 이해할수 있는 코드가 가장 좋기 때문이다.

그렇지 못하다면 위에서 처럼 코드와 똑같은 내용을 문장으로 적는 것이 아니라 알고르즘이나 코드의 존재 이유에 대해 적어야 한다. 불필요한 코멘트는 코드의 가독성만 떨어뜨린다.

출처 : birdkr’s home by (버드)

“The practice of an Agile developer”를 보면 Architect가 설계만 하면 안된다고 했다. 전적으로 동감하는 말이다. 회사에서 일을 하다면 “현실”을 알지 못하고 이론만 아는 설계팀과 충돌할 때가 많다.

책에서 보면, 다른 회사의 feature를 보면 그리고 혼자서 생각을 하면 A라는 기능은 이 제품에 꼭 필요한 기능이다. 그래서 말한다. “A라는 기능이 없는 제품은 본 적이 없다고”

그럴 때 S/W 개발자는 말한다. “와서 만들어 놓고 가라” 어찌보면 개발자 입장에서 “못한다”라고 말하는 것은 무척 자존심 상하는 일이다. 왜냐하면 S/W 개발자가 못한다고 하는 것은 다른 이유가 아니라 실력/능력이 부족해서 못한다고 생각하는 사람이 대부분이기 때문이다.

하지만 S/W 개발자에게 자원들이 무한정 주어진 것이 아니다. CPU power 그리고 메모리등. 한정된 자원을 주고 게다가 한정된 개발 시간을 주면서 모든 일을 하라고 하니 어떤 일을 할 수 있는 것도 있고, 또 어떤 일을 할 수 없게 되는 것이다.

그리고 Agile에서는 S/W에서 요구사항의 변경은 피할 수 없는 것이므로 어쩔 수 없는 그 상황에도 잘 대처할 수 있도록 하라고 한다. 하나의 water fall 구조가 아니라 잦은 iteration을 이용하라는. 아쉽지만 현실이 그렇지 못할때가 많다. 여러 사람이 함께 개발을 하다 보면 블럭간의 인터페이스를 함께 바꿔야 하는데 이때는 아쉬지만 기술적인 이슈보다는 정치적인 이슈가 개입될때가 많다 -_- (Agile 책을 보면 큰 프로젝트일 수록 water fall이 실패한다고 했는데 정말로 Agile 방법론을 사용할 수가 있는 걸까 늘 궁금하다. 이해 당사자가 무척 많을 텐데)

그래서 대개 설계인력은 S/W나 H/W 개발 경력이 최소한 얼마정도는 있는 사람으로 구성하기 나름이다(물론 늘 그런 것은 아니다. 박사인력인 경우 대부분 S/W 개발보다는 바로 설계 업무를 배정하는 경우가 대부분이다. 누군가 말한 것처럼 박사과정이 하나의 토픽에 대해 전문성을 갖는 것보다 문제를 풀어가는 방법을 배우는 과정을 배운 것이 더 의미가 있다고 하는 것처럼 대부분 실무적인 S/W 개발 경험이 없더라도 잘 하는 경우가 많다(혹은 석/박사과정에서 산학 협력등의 경험을 한 경우도 많고)

다만 그렇지 못한 고급인력(박사로 한정하는 것은 아니다)들이 다른 사람을 힘들게 하는 것이다. 머리는 똑똑하고 나름대로 정보 습득 능력은 높기때문에 보고 들은 것은 많은 데 그것을 자기가 가진(자기가 속한 회사가 만드는) 제품군에 무조건적으로 적용하려다 보니 실무자인 개발자와 충돌하는 경우가 많다.

갑자기 이런 글을 적는 이유는 아침에(토요일이니 새벽이군) 블로그 뉴스를 보다 보니 이런 내용이 있어서이다.

그는 알만한 이들만 아는 회사인 ‘마이크로소프트’라는 회사에 근무하고 있고, 하는 일은 마이크로소프트 개발자 사업부 총괄책임자(전무)다. 소프트웨어를 만들 때 사용하는 개발 툴인 비주얼 스튜디오(Visual Studio) 제품과 닷넷(.Net) 프레임워크 기술 개발을 책임지고 있다. 그가 이끄는 팀은 총 620명. 그는 개발자 사업부 총괄 책임자지만 여전히 매일 서너시간은 코딩을 한다. 그가 하는 코딩은 이미 제품화 된 것보다는 대부분 새로운 아이디어를 시도하는 프로토타입으로 그치는 경우가 많지만 끊임없이 새로운 시도를 추구하고 있다.

와우. 정말 말로만 듣던 코딩하는(프로토타입이라는데 당연히 그래야 하는 것 아닌가? 620명을 총괄하는 살마이 문제점 해결하겠다고 코드 리뷰하는 것도 우스운 일이니-우리 회사엔 그런 사람이 있다고 하는데) Architect(심지어는 project manager) 아닌가. 난 주변에서 코딩한다는 architect를 본적도, 있다는 소문을 들은 적도 없다. 대부분의 사람들이 모두 엑셀이나 파워포인트만 다루고 있다.

너무나도 다른 사람, 회사 분위기가 놀라울 따름이다.

그 외에도 기억하고 싶은 글은

그는 국내 개발자들과의 대화에서 ‘초기 평개발자로서 새로운 시도가 쉽지 않았지 않았느냐’는 질문에 “마이크로소프트에서는 ‘Code wins’라는 말이 있습니다. 개발자라면 직급이 아니라 코드를 통해 해결책을 내놓는 것으로 인정받는다는 것입니다“라고 밝혔다. 그는 또 “ASP.NET도 처음에 나 혼자 프로토타입을 개발하고 나서 그 이후 3-4명의 작은 팀이 생겼습니다. 서버를 통해 코드를 관리하는 것이 효율적이라는 것을 스스로 믿고 강하게 주변 사람들을 설득하는 것이 중요했습니다”라고 조언을 아끼지 않았다. “목표한 바는 결과로 반드시 만들어 내는 것도 중요합니다. 개발자들은 코드로 보상을 받는 것이라고 생각합니다. ‘개발 작업’을 하는 것이 아닌 ‘좋은 제품’을 만들어 내는 것이 중요합니다”라고 관리자로서의 개발자 역할도 강조했다. 스콧 구슬리는 “블로깅은 4년여 전에 시작했는데, 약 2년 전부터 심층적 기술문서들을 올리면서 많은 개발자들이 조회하고 참고하는 정보소스가 됐습니다. 한 달에 보통 10-15회 문서를 올립니다. 이 과정을 통해 우리 기술팀이 개발한 기능들을 더 잘 이해하게 되기도 합니다”라고 밝혔다 스콧 구슬리 전무는 “항상 고객을 염두에 두는 개발자가 되십시오”라는 말로 이번 방한을 마무리 했다

그의 블로그 주소는 http://weblogs.asp.net/Scottgu 이다

꼬랑지) 당연한 이야기지만 설계인력이 늘 현실을 무시하고 과하게 요구하고, 늘 S/W 개발자가 맞는 말만 하는 것은 아니다. 또 많은 경우에는 S/W 개발자의 능력 부족이나 게으름, 혹은 잘못된 태도때문에 타당한 요구사항을 수용하지 못하겠다고 거부한다. 결국 답은 서로가 서로를 좀 더 이해(알기도 하고, 배려/인정도 하고) 서로 지식을 공유하고 많은 대화를 가져야 한다. 누구나 아는 답이 아닐까? 누구나가 다 하는 것이 아니기때문에 문제지만.