페이지

2013년 9월 9일 월요일

change is inevitable

이제 막 eclipse contributor 가 되기도 했고, 이제 막 재미가 붙고, 더 큰 건으로 contribution할 수 있는 건 수를 찾던 중 이기도 했는데 아쉽게도 회사에서의 직무에 변경이 생겼다. 자세한 스펙은 아직 미지수 이지만 context, server , analysis, big data 의 키워드가 주 일것으로 생각된다.

그래서 그동안 1년여동안의 eclipse생활을 뒤돌아 봤는데, 기간에 비해 이룬것이 적다는 생각이 들었다. 그래서 아쉽지만 그래도 이 기간동안에 의식적으로 노력한 것에 대한 결과는 얻은것 같아 안도감이 든다.

그 노력이란...
내가 하고싶어하는 일을 나의 할일로 만들지 않으면 누군가가 내가 하기 싫은 일을 나의 일로 만들어 버린다는 것.

이 고리를 잘 엮으면 난 나의 커리어와 재미를 동시에 만족시킬 수 있게 된다. 전략적으로 접근해야 해서 쉽지는 않지만 또 잘 연결을 시키다 보면 불가능한 것도 아니더라.

나의 삶을 내가 컨트롤 할 수 있는 영역을 넓혀 간다는 것. 멋진 일이다.

아듀 이클립스.
그리고 난 다시 새로운 분야로 뛰어든다.

2013년 8월 4일 일요일

Eclispe platform contributor 되다.

Eclipse에 처음으로 내 소스를 반영하여 contributor가 되었다.

내가 반영한 것은 emacs key scheme에 있는 recenter command를 enhancement한 것인데.
기존에는 cursor line이 center 로만 옯겨졌는데 이것을 오리지널 이맥스처럼 center top bottom 으로 스크롤링되게 만드는 패치를 만들어서 반영하였다.

패치를 보면 알겠지만 매우 간단한 작업이었고, 더 어려운것은 그 프로세스 적인 부분이었다.
사실 어떻게 어떻게 해서 contributor 가 될 수 있다는 정보가 별로 없고 막막한 부분이 있었는데 이번에 그런 부분을 공유해보면 혹시나 비슷한 고민을 하고 있는 분들께 도움이 되지 않을까 하여 공유해보고자 한다.

  1. 우선 내가 해결하고자 하는 이슈가 이미 진행중인지 버그질라를 통해서 검색
  2. 해당하는 이슈가 있다면 그 이슈를 이용하면 되고, 없다면 새 이슈를 등록한다. 나의 경우 이슈는 https://bugs.eclipse.org/bugs/show_bug.cgi?id=412267 이었다.
  3. 이슈 등록후, 패치를 attach함.
  4. 이렇게 패치를 등록하면 각 모듈의 maintainer가 이슈를 재할당하고 첨부된 패치에 대한 feedback을 해준다. 나의 경우는 아래 사항들을 얘기했었다
    1.  command의 설명을 업데이트 하고, 소스의 copyright, credential 업데이트
    2. CLA(Contributor license agreement) 서명
    3. coding convention, compact assignment, operator 사이는 공백 하나씩 주기
    4. 버그 리포팅 및 재현할 수 있는 테스트 케이스 기술
  5. 이렇게 몇번의 피드백이 오고간 후 최종 패치를 올렸더니
    한 달여만에 master git 에 반영이 되었다.
    http://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=1726a32434ee8a113d5ab8c3441987c7aa6fdf25
eclipse는 git을 사용하고 있어서 git의 기본적인 사용법을 알아야 더 편할것 같고, 이 외에 정보들은 eclipse wiki등을 찾아 보면 되겠다.

이렇게 eclipse platform 소스에 내 이름이 떡 하니 들어가게 된 히스토리 되겠다.

2013년 5월 23일 목요일

Susan Cain, Quiet

살다보면 외향성이 필요할 때가 있고, 그것을 가지고 있는 척 해야 할때가 있다. 내향적인 사람이 외향성인척 하면서 살 필요가 있는가? 외향적인것이 더 좋은것인가? 아니면 그 반대인가?
기질이란 있는것인가? 기질은 바뀌지 않는가 아니면 바꿀 수 있는것인가?

이런 물음들에 대한 새로운 각도의 답을 주는 책이다.

난 쭉 우리 아들이 좀 더 외향적이었으면 하고 바라고 있었는데(내가 그렇지 않아서 인가?)  이 책을 읽고는 그런 걱정을 하지 않기로 했다. 기질을 존중하고 기질에 반하는 행동을 해야 할때 그것을 소화할 만큼의 멘탈만 있으면 되는 것이다.

별 다섯.

38.
이 책에서 가져갈 수 있는 오직 한가지 통찰이 있다면, '자기 자신을 그대로 받아들여도 된다' 라는 느낌이라면 좋겠다.

58
외향성 선호는 사실이다. 이 특성은 아시아와 아프리카에는 덜 나타나고 유럽과 아메리카에는  더 나타나는데, 이들 대륙의 후손들은 상당부분 이주민이었다. 심리학자들은 여행하던 사람들이 집에 머무르던 사람들보다 외향적이라는 점, 그리고 그러한 특성을 후손에게 물려주었다는 점이 이치에 맞는다.

98
사람들의 인식은 문화적인 편견이 반영된 것에 불과할 때가 많다.

99
외향적인 지도자들은 직원들이 수동적일때 집단의 성과를 향상시키는 반면, 내향적인 지도자들은 직원들이 능동적일때 더 효과적이다.

146
과학적 근거를 보면 기업 사람들이 집단으로 브레인 스토밍을 하는것은 정신 나간 짓이다.
단, 온라인 브레인스토밍은 효과가 있다.

162
고반응과 저반응은 각각 내향성과 외향성에 연결된다.
164
고반응 아이들은 외향적이기 때문이 아니라 그 작은 몸이 새로운 물체와 소리와 냄새에 강하게 반응했기 때문에 그렇게 한것이다. 저반응 아이들은 조용했던 이유도 내향적으로 될 아이들이었기 때문이 아니라 실제는 정반대로 신경계가 새로운 것에 별 감흥이 없기 때문이었다.

175
케이건에 따르면 천성 탓이냐 양육 탓이냐는 질문은 눈보라가 기온때문인지 아니면 습도 때문인지 묻는것과 마찬가지다. 둘의 복잡 미묘한 결합이 지금의 우리가 있게 된 원인이다.

178
난초가설
반응성이 높은 아이가 좋은 교육과 보살핌을 받고 안정된 가정환경에서 자라면, 반응성이 낮은 아이에 비해 정서문제가 적고 사교 기술도 뛰어나다는 연구결과가 나왔다. 이들은 공감을 잘하고, 다정하고, 협조적이고 타인과 잘 협동한다. 친절하고 양심적이며, 잔혹함이나 부당함이나 무책임함에 쉽게 흥분한다. 또 자신에게 중요한 일에 성공적이다.

186
우리는 성격을 개조할 수는 있지만, 그것도 어느 정도까지다. 타고난 기질은 우리가 어떻게 살았든 간에 우리에게 영향을 미친다. 우리라는 존재의 상당한 부분은 유전자, 두뇌, 신경계에 따라 정해진다.

196
일단 내향성과 외향성을 자극 수준에 대한 선호도 정도로 이해하고 나면, 자신의 성격에 잘 맞는 환경을 의식적으로 만들어 낼 수 있다. 자극이 과하지 않고 부족하지도 않게, 지루하지도 않고 불안하지도 않게 말이다. sweet spot!

203
신념에서 나오는 용기를 담아 말하는 사람보다 더 용감한 사람은 없다

221
고 반응성인 내향적인 사람은 땀을 더 흘리고, 외향적인 사람은 땀을 적게 흘린다. 이들의 피부는 말그대로 두껍고, 자극에 영향을 덜 받고, 만져보면 시원하다. 바로 여기에서 사회적으로 '쿨하다'는 개념이 생겨났다고 한다

319
Free Traits Theory: 우리는 특정한 성격 특성을 타고나거나 문화적으로 함양되지만,  "개인에게 핵심이 되는 프로젝트"를 위해 거기에서 벗어난 행동을 할 수 있다.

333
자신에게 핵심이 되는 프로젝트를 알아내려면
- 어렸을때 무엇을 좋아했는지 회상해보라. 그때의 구체적인 답변은 표적에서 빗나갔을 수도 있지만, 그 아래 깔려있던 충동은 그렇지 않을 것이다.
- 자신이 끌리는 일에 주의를 기울이자
- 자신이 부러워 하는 일에 주의를 기울이자. 질투는 추한 감정이지만 진실을 알게 해준다.

337
자유특성계약; 일정시간은 자신의 성격에 맞지 않는 행동을 하기로 하되, 나머지 시간에는 자신의 모습 그대로 지낼 수 있게 하는 것이다.

354
내향적인 사람들은 우호적인 상황에서 만난 사람들을 좋아하지만, 외향적인 사람들은 자기와 경쟁하는 사람들을 더 좋아한다
내향적인 환자들은 부드럽고 편안하게 말하는 로봇과 훈련할때 더 나은 반응을 보이고(잘하셨네요. 계속 그렇게 하세요.)
반면 외향적인 환자들은 자극적이고 공격적으로 말하는 로봇과 훈련할때 더 열심히 했다. (고작 그것밖에 못하세요! 더 잘하실 수 있잖아요!)

381
"한번도 만난 적 없는 애랑 노는게 좀 이상 할 수도 있다는 건 아빠도 알지만, 네가 먼저 놀자고 하면 저 애는 좋아서 트럭 놀이를 같이 할걸"
"어제 모르는 아이들한테 말 걸었지? 힘들 수도 있었을텐데, 잘 했네"

382
아이에게 수줍음이 많다는 말을 해서는 안된다. 아이는 부모의 말을 믿을 테고, 그러면 자신의 감정이 통제할 수 있는 것이라기보다는 이미 고정된 특성이라고 믿어버리고 만다.아이는 수줍음이 부정적 의미로 쓰인다는 점도 아주 잘 알고 있다. 무엇보다 수줍음을 탄다는 이유로 아이를 부끄럽게 만드어선 안된다.

388
사실 수많은 학교가 외향적인 아이들에게 맞게 구성되어 있다.
학교의 목적은 아이가 평생을 살아가도록 준비시키는 것이어야 하지만, 실제로 아이들이 준비해야 할것은 학교에서 하루하루 살아남는 방법일 때가 많다



2013년 1월 28일 월요일

xml catalog in Eclipse

xml catalog in Eclipse

History

  • 2013-01-28, initial version
  • 2013-06-04, using catalogue extension point

overview

eclipse는 xml의
  • element나 attribute의 자동완성 기능
  • validation 기능
을 제공한다. 이 기능을 사용하기 위해서는 그 xml문서의 문법책이라고 볼 수 있는 dtd 혹은 xsd파일이 있어야 한다.
보통 이런 xsd 파일은 http로 공개되어져 있고 eclipse 같은 훌륭한 IDE에선 그 파일을 가져와서 xml 파일은 validation할 수 있다.
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
...
위 maven xml의 경우 http://maven.apache.org/xsd/maven-4.0.0.xsd 에 xsd가 있다. 그래서 대부분의 경우 xsd가 resolve가 되면 validation이 가능하다.
하지만 특정한 경우에 xsd를 override하고 싶은 경우가 있을 수 있다. 예를 들면
  • 내부 테스트 환경에서는 xsd위치가 다르다거나
  • 로컬에서 xsd를 바꿔가며 테스트 해보고 싶은 경우
  • 서버 이상으로 xsd에 접근을 못할 경우
그럴때 eclipse에서의 xml catalog를 사용해서 xsd를 override 할 수 있다.

xml fundamental

아래 설명을 이해하려면 최소한의 xml schema에 대한 지식이 있어야 한다.
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   targetNamespace="http://example.org/publishing"
   xmlns:tns="http://example.org/publishing"
>

   <!-- type definitions -->
   <xsd:simpleType name="AuthorId">
      <!-- define value space details here -->
      ...
   </xsd:simpleType>

   <xsd:complexType name="AuthorType">
      <!-- define structural details here -->
      ...
   </xsd:complexType>

   <!-- global element/attribute declarations -->
   <xsd:element name="author" type="tns:AuthorType"/>
   <xsd:attribute name="authorId" type="tns:AuthorId"/>
   ...

</xsd:schema>
  • 위에서 xmlns:xxx는 xxx에대한 namespace정의다.
  • schema 에 있는 targetNamespace 는 이 스키마의 namespace가 http://example.org/publishing 이라는 것
  • xmlns:tns가 targetNamespace와 같은 것으로 한번 더 정의한 이유는 이 스키마 내부에서 특정 엘리먼트를 reference하기 위해서다. tns:AuthorType 이나 tns:AuthorId 처럼
위 xsd에 맞게 xml을 쓸때는 아래처럼 쓴다
<x:author xmlns:x="http://example.org/publishing"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://example.org/publishing pubs.xsd"
>
...
  • xmlns:x 가 위 xsd에서 정의한 nampspace이고 그것을 사용하고 있다
  • schemaLocation에서 <namespace> <xsd uri> pair를 한개 이상 정의할 수 있다

Defining xml catalog with dtd

Defining xml catalog with xsd

Preferences>XML>Xml Catalog 에서 xml catalog를 설정할 수 있다.
<c:Catalogue xmlns:c="http://www.eclipse.org/webtools/Catalogue" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eclipse.org/webtools/Catalogue http://www.eclipse.org/webtools/Catalogue/Catalogue.xsd ">
    <c:Book>
        <title>Professional XML Schema</title>
        <date>2001</date>
        <isbn>1-861005-47-4</isbn>
        <publisher>Wrox Press</publisher>
    </c:Book>
</c:Catalogue>
방법은 2가지
namespace name으로 할경우, xsi:schemaLocation은 xml에서 제거를 해야 동작한다
이렇게 정의한 xml catalog는 import/export도 가능하다.

Defining xml catalog using extension point

preference를 이용한 xml catalog는 설정은 자신의 eclipse workspace에만 적용되는 local한 것인 한계가 있다. 내가 개발한 plugin을 사용하는 사람에게 설정을 해주고 싶다면 extension point를 이용해서 설정을 하는것도 가능하다.
org.eclipse.wst feature에 있는 "org.eclipse.wst.xml.core.catalogContributions" extension point를 이용하면 된다. 예제는 org.eclipse.wst.standard.schemas plugin의 소스를 import해서 살펴보면 어떻게 정의하고 사용하였는지 알 수 있다.

ex>
             point="org.eclipse.wst.xml.core.catalogContributions">
                        id="org.tizen.nativecpp.misc.manifest.catalog">
                              name="http://schemas.tizen.org/2012/12/manifest"
                  uri="xsd/manifest.xsd">
           

         



2013년 1월 20일 일요일

scot anderson, 최고의 아빠(dad)


아이를 키우다보면 참 어렵다고 느낄때가 많다. 어떻게 해야 좋은 아빠가 되는것인지, 좀 더 친해지려면 어떻게 해야하는지 자신감을 키워주고 싶을때 어떻게 해야하는지..
요즘 아들과 티격태격하는 나를 보더니 와이프가 빌려온 책이다. 내용도 좋고,  번역의 질도 좋다. 아마존에서 찾아보니 dad란 제목으로 parenting 부분에서 베스트셀러였다. 역시나 라고 생각했다.
약간 의외였던 것은 저자는 엄마가 집에서 아이들을 돌봐야 한다고 생각하는 것이였다. 우리의 생각과 다르지 않은 이유에서. 할머니와 베이비시터가 엄마 같은 사랑을 줄 수 있을까 생각해보면 나도 그 의견과 다르지 않다. 하지만 와이프의 커리어가 단절되는 부작용도 무시할 수 없다. 어려운 문제다.

이 책을 감히 요약해보면 이렇게 된다.

먼저 훌륭한 아빠가 되겠다는 비전을 세워야 한다. 사람은 비전이 없으면 스스로를 억제하지 못하기 때문이다.(p21)
아이들과 시간이 아닌 관계를 쌓고(양보다 질), 그 관계를 위해선 신뢰라는 기초공사를 단단히 해야 한다.(p56)
그 신뢰를 얻기위해 가장먼저 할 것은 아내를 사랑하는 일이다. 아이들의 인생에서 가장 중요한 엄마를 사랑하지 않는 아빠를 아이들이 어떻게 신뢰할 수 있을까. 훌륭한 남편 다음이 훌륭한 아빠의 자격이 있다. (p72)
아내의 사랑을 얻기위한 방법들:
. 퇴근해 집에 온후 15분은 아내를 위한 시간으로 할애하라
. 아내의 필요를 충족하라(아이와 함께 엄마의 선물을 준비)
. 이혼을 입에 올리지 말고
. 아내와 정기적으로 데이트 하고
. 사랑한다고 소리내어 말하고
. 애정을 표시하고
. 아내와 한편이 되어라

가족과 좋은 추억을 쌓아라.
명심하라. 인생이란 추억거리를 만다는 과정이다. 가족의 추억을 만드는 것은 아빠의 책임이다. 어릴때 다양한 추억을 만들어주고 함께 시간을 보낸다면, 아이들은 커서도 당신과 계속해서 추억이 될 시간을 함께 부내고 싶어할 것이다. 가족에게 멋진추억을 심어주지 않았으니 멋진 추억을 수확한다는 것은 당연히 불가능하다.(p126)
. 아이들이 어릴때부터 당신과 함께 보내는 시간을 소중하게 여긴다면, 당신이 나이가 들었을때 그들도 당신과 보내는 시간을 소중히 여길 것이다.(p134)

아이들과의 약속은 꼭 지켜야 한다. 신뢰의 문제이므로..
약속을 할때는 지킬 수 있다는 확신이 있을때에만 하라(p168)


아들의 사랑의 언어를 파악하고 그 언어로 사랑을 말하자. (사람마다 사랑을 표현하는 방식과 느끼는 방식이 다르다)
5가지 사랑의 언어
. 선물
. 도움
. 함께 보내는 시간
. 격려
. 애정표현

듣기는 속히 하고 말하기와 성내기는 더디하라(p215)

말다툼에서 이기는 유일한 방법은 말다툼을 피하는 것이다.(p225) 왜냐하면 상대방의 의견이 틀렸다는 것을 설득했다 하더라도 그의 의견은 변하지 않기 때문이다. (p226)


격려와 칭찬을 통해 아이의 자존감을 키워줘야 한다. 능력이 있든 없든 매력이 있든 없든 계속해서 우리에게 좋은 말들을 해주는 머릿속 녹음기를 우리는 자존감이라고 부른다.(p257)

예를 들면 이렇게 말해주며 같이 꾸준히 야구 연습을 해준다. 그러다 보면 진짜 실력이 좋아질 것이고.. 뭐든 노력하면 이렇게 할 수 있구나 란 것을 느끼게 해주면 된다.
- 야구못하겠어요.
+ 아들아 너는 아주 잘하고 있어. 넌 뭐든 노력하면 잘하잖니? 이번주에 조금만 더 연습하면 돼. 방금전에 네가 잡아냈던 공 기억하지? 정말 대단했어
- 하지만 아빠. 난 매번 삼진아웃 당하는 걸요.
+ 아들아, 지난 번에 아빠랑 같이 봤던 야구 경기 기억나? 세계 최고의 타자인 새미소사도 삼진아웃 당했잖니(p260)
. 내가 내 자신을 어떻게 보느냐에 따라서 세상이 나를 어떻게 보느냐가 결정된다. (p266)

낳아준 아빠 -> 부양하고 보살피는 아빠 -> 관계를 쌓는 아빠 로 진화해 가야 한다(283)


아이들은 자기행동의 결과를 예상할수 있을때 훨씬 안정적이고 행복하게 지낼수 있다. 그러므
로 훈육에 일관성이 있어야 한다. (p312)

아이가 무언가 실수를 했을때는 이런 패턴으로 말을 하자.
유리잔에 우유가 들어있을때는 조심해서 행동해야지. 자 흘린 우유는 네가 치우렴. 유리잔에 든 우유를 네 스스로 책임지지 못한다면 할 수 있을때까지 빨대를 사용할 거야(332)

통계적으로 책을 처음 한번 읽으면 전체 내용의 20파센트만 기억한다고 한다.(348) 그러니 이책을 몇번 더 읽으라

2013년 1월 19일 토요일

git

내가 여지껏 써본 revison control software(RCS) 는 소시적 MS SourceSafe , Rational ClearCase, Perforce, Git 등이 있다.

Clearse에서 Peforce로 처음 바꿨을때 그 속도에 감탄했었다.  Peforce가 빨랐다기 보다는 ClearCase가 너무나 느렸던 탓이다. 실제로 Perforce와 SVN의 속도를 비교해보면 p4가 더 빠르긴 하지만 큰 차이는 없는 것으로 알고 있다.

git을 반년정도 써오고 있는데 지금까지는 아주 basic한 workflow만 써오다가, 복수개의 remote 서버를 추가해서 로컬 브랜치로 만들고 각 브랜치 간의 머지 및 integration을 로컬에서 할 수 있음을 알고는 git의 강력함을 느꼈다.

시나리오를 만들어 보면

  • git remote 서버들
    • team의 master 서버인 origin
    • 오픈소스여서 대외적으로 공개될 git인 rsa
  • 로컬 브랜치들
    • develop : origin/develop
    • release : origin/release
    • rsa : rsa/master
  • workflows
    • dev 에 비교적 unstable한 코드들을 넣고  커미하고 자가 검증
    • integration을 하기 위해 최신 develop 브랜치 로 release로 overwrite하고 integration build를 만들어서 검증팀에 주고 디펙 수정
    • 각 마일스톤 별로 release criteria를 만족하면 rsa로 push
    • rsa에서 디펙 어싸인이 되면 rsa브랜치에 quick fix를 하고 develop 브랜치에 머지
    • release 디펙 어싸인되면 release브랜치에 quick fix를 하고 develop에 머지
위 workflow를 git이 아닌 p4로 한다고 생각하면 일이 생각보다 복잡해진다.
  1. 우선 develop/ release, rsa의 working copy를 만들어야 한다. 대부분의 코드는 같을 것이기 때문에 여기서 많은 하드 공간이 낭비된다. git은 같은 hash를 가지면 그것을 브랜치 간에 share하기 때문에 엄청난 효율을 가질 수 있다. perforce도 서버단에서는 같은 오브젝트임을 알지만 로컬에  N번의 working copy를 sync해야 하는 것은 어쩔 수 없는 비효율
  2. 1에서 만약 rsa가 물리적으로 다른 서버라면 서버단에서도 같은 오브젝트가 아닌 다른 오브젝트로 인식할 것이므로 또 비효율이 발생할 수 있다.
위 시나리오에서 브랜치가 더 늘어나고 remote더 늘어날 수록 개발자가 감당해야 하는 복잡함은 perforce쪽이 더 많아 진다. peforce 대신에 Centralized RCS 로 단어를 바꿔도 같은 뜻이 된다. 즉, Centralized계열의 한계라고 볼 수 있다.

게다가 훌륭한 code review툴인 gerrit까지 무료로 쓸 수 있지 않은가
RCS가 git으로 천하통일 될 수 밖에 없는 이유 되겠다.






2013년 1월 15일 화요일

돈으로 의지를 살 수 있는가

요즘 레슨을 받으며 느끼는 것이 있다.

레슨을 받으면
불과 이십분만에 땀을 뻘뻘 흘리고 숨이 차다.
근데 이것을 혼자서 이렇게 해보려고 하면 절대 이런강도가 나오지 않는다.
너무 힘들면 그만해 버리기 때문이다.

PT도 마찬가지
PT할때는 운동도 잘되고 근육붙는게 눈에 보인다.
하지만 PT가 끝나고 혼자 헬스장을 다녀보면
그 근육들은 금방 풀어져 버린다.
한번씩 빠지기도 하고
음식 조절에도 실패하기 때문에

돈을 내고 레슨/PT을 받으면
내가 지불한 돈의 가치때문에
빠뜨리지 않고 하게 되고
강사가 극한으로 잘 이끌어 준다.

이는
돈으로 강사의 시간을 사서 나의 시간을 save하는 것이며
한편으로는
나약한 의지를 돈으로 사는 것이다.

매일 운동 하는게 힘들다면
적지않은 돈을 지불하고 운동을 해보자
의지가 충만해질테니까