2년만의 글쓰기

시간이 참 쉽게 흘러가는 듯 합니다.  마지막으로 글을 쓴게 벌써 2 년이 지났군요.  오랜만에 WordPress도 업데이트를 해줬습니다.

앞으로는 가끔이라도 글을 꾸준히 써 나가야 할 듯 합니다.  그래야 홈페이지가 살아 있는 듯 할 것 같네요.

XUL 을 사용하고 싶어요~

오늘은 XUL 의 어떤 이야기를 할껀가요?

오늘은 XUL 프로그래밍을 하면서 도움을 많이 받았던 사이트들을 정리할려고 합니다.  음.. 많은 정보들이 있는데요.  결국 그 정보들이 어디에 있는지 북마크로 정리해 두면 좋을 것 같아서요.

그럼 이것부터 말씀해 주세요.  XUL 를 시작하는데, 가장 쉽게 접근할 수 있는 방법을 설명하고 있는 사이트는 어디인가요?

음.. 어디일까요..  역시 XUL 로 무엇을 할 수 있는지 바로 볼 수 있는 XUL Periodic Table 사이트가 제일 좋은 것 같아요.  Firefox 브라우저만 있으면 바로 바로 XUL 로 무엇을 할 수 있는지 볼 수 있잖아요.

그럼 Tutorial 쪽은요?

당연히 XUL Planet 의 튜토리얼이죠.  여긴 Mozilla 재단에 운영하는 건가요?  이 사이트는 항상 최신의 정보를 유지하는 것 같아요.  레퍼런스 사이트로 그만이예요.  아~ 튜토리얼이랑 레퍼런스 문서들을 다운로드 받을 수 있는 형태로도 제공하거든요.

이전에 잠시 인터넷이 안되는 곳에서 XUL 개발을 하다가 XUL Planet 에 접근할 수 없을 때가 있었는데, 그 때 정말 답답해 죽는 줄 알았어요. ㅋ

다른 사이트들은 없어요?  좀 더 끝내주는 것들요.

저도 뭐 그리 대단하게 많이 알고 있는 것이 아니기 때문에, 제가 알고 있는 사이트들만 한번 나열해 볼께요.  제 북마크에 모두 기록되어 있는 사이트들이예요.

• XUL Programmer’s Reference
  (http://www.mozilla.org/xpfe/xulref/)
  여긴 모질라 재단에서 제공해 주는 레퍼런스 사이트예요.  근데 솔직히 저 입장에서 눈에 잘 들어오는 건 아니더군요.
• Developing XUL-Applications with Mozilla
  처음 RDF 를 다루게 되면서 context-type 을 제대로 정해주지 않아 애먹었을 때 찾은 사이트입니다.  처음 RDF 를 다룰 때 만나게 되는 바로 그 문제! 
  여러분도 같은 어려움에 빠지지 마세요. ㅋㅋ
• Creating Applications with Mozilla
  이건 책인것 같은데, 웹에 있군요.  근데 별로 도움받은 기억이 없어요.
• XUL tree NEW
  나중에 한번쯤은 사용하게 될 tree 를 어떻게 만들 수 있는지 자세하게 설명한 문서예요.
• XUL Tutorial: Styling a Tree
  여러분의 Tree 를 좀 더 colorful 하게 만들 좋은 방법이 없을까요?  CSS 파일과의 조합이 제대로인 XUL 프로그래밍을 해보세요. ㅋ  각 열마다 다른 색상을 입히거나 열의 특정 부분만 색상을 바꾼다거나 여러가지 재미있는 색상입히기를 할 수 있습니다.
• Creating a C++ XPCOM component
  생각보다 유명한 사이트인지 모르겠지만, XPCOM 을 짜고 싶은 사용자라면 꼭 한번쯤은 방문해 봤은 궁긍의 one click 예제가 있는 곳~  XPCOM 예제가 있어서 너무 행복한 곳이죠? ㅋ 근데 나중에 Javascript 로도 XPCOM Interface 를 작성할 수 있다는 사실을 알고 멍해졌다는..
• Debugging a XULRunner Application
  역시 개발의 백미?는 디버깅.. XUL 환경에서 디버깅하는 것은 그렇게 어렵지 않지만, 역시 gdb 같이 breakpoint 걸고 싶은 기분은 왜 일까요.  좋은 디버거가 있을려나 모르겠습니다. 
• Adding a New Protocol to Mozilla
  만약 여러분이 http:// 라는 프로토콜 대신에 blahdotcom:// 과 같은 새로운 프로토콜을 정하고 싶다면 어떻게 하실 건가요?  iTunes 의 경우 자기들 프로토콜인 items:// 사용하던데..  저도 이걸 이용해서 fileauction:// 이걸 넣었습니다. ㅋ
• Profile folder
  만약 여러분의 XUL 프로그램이 임시 파일이나 기록 파일을 생성해야 되면 어디에 저장해야 할까요?  바로 Profile Folder 입니당~  이에 대한 자세한 정보를 볼 수 있는 곳.
• nsIAlertService
  Firefox 의 경우, 다운로드가 완료되면 윈도우즈 혹은 리눅스 용의 경우 오른쪽 하단에서 alert 이 멋있게 뜨고 사라집니다.  바로 그 서비스를 여러분의 XUL 프로그램에서 할 수 있도록 하는 정보.
• Using the Clipboard
  XUL 프로그램과 시스템의 클립보드와의 연동을 어떻게 하는지 알려줍니다.

위의 링크들을 보시면 의외로 XPCOM 부분이 좀 있습니다.  시스템 및 OS 와 연동되어야 하는 작업들은 대부분 XPCOM 으로 구현이 되어 있으며, Javascript 에서는 XPCOM Interface 를 통해서 접근할 수 있도록 되어 있어요.

@_@ 왜 이렇게 좀 어려운 것 같죠?  개념 잡기가 힘들어요..  그냥 튜토리얼부터 봐야 할 것 같아요.

ㅠ.ㅠ 저도 첨에 개념잡기 힘들었어요.  이젠 좀 적응이 되서 그나마 좀 나아진 거예요.  튜토리얼부터 차근차근 조금씩 보세요.  직접 XUL 프로그램이라도 간단한 것을 짜보는게 가장 중요하거든요?

전 영어 free-talking 하러 갈 시간이예요~  나중에 더 잼나는 거 많이 해 줄께요. 담에 봐요.

XUL 이 뭐예요?

[항상 feedback/의견 댓글로 받습니다.  오류 사항, XUL에 관한 질문이 있을 경우, 모두모두 댓글로 남겨주세요.] 

Q. XUL 이 뭐예요? 

저도 잘 모릅니다.  조금 밖에 지식이 없으며, ‘파일경매‘라는 프로그램을 만들면서 처음 접한 언어이기도 합니다.

이게 XUL 을 설명한 한국어 버전입니다.

XUL (XML User Interface Language)은 Mozilla의 XML 기반 언어로 인터넷과 연결되거나 또는 연결되지 않은 채로 동작하는 풍부한 기능을 제공하는 크로스 플랫폼 응용프로그램을 만들 수 있게 해줍니다. 이렇게 만들어진 응용프로그램은 텍스트나 그래픽, 배치 등을 쉽게 바꿀 수 있기 때문에 여러가지 요구에 맞게 즉시 상품화나 지역화 해 내어놓을 수 있습니다. 다이나믹 HTML (DHTML)에 친숙한 웹 개발자들은 XUL을 금방 배워서 바로 응용프로그램을 만들어 볼 수 있을 것입니다.

이해가 되나요? 단순하게 말하면 XML 로 UI 를 만들 수 있다는 말인 것 같네요.  대부분 HTML 코드를 읽을 줄 알고 쓸수 있는 사람이면 쉽게 XUL 로 프로그래밍을 할 수 있는 것 같습니다.

Q. 그럼 UI 만 XUL 로 작성하고 안에 내부 루틴은요? Visual Basic 으로 내부 루틴을 작성하고 UI 만 XUL 로 하면 안될까요?

제가 조사한 바에 의하면 XUL 로 UI 로 작성하였다면 Javascript 로 내부 루틴을 작성하면 되었습니다.

Q. 그럼 모든 루틴을 Javascript 로 작성하란 말입니까?  우리에겐 속도가 생명입니다.  제일 빠른 C 나 C++ 로 작성하고 싶은데..

속도가 생명이라구요? 근데 왜 XUL 로 작성하세요?  다른 솔루션들이 많을텐데.. 꼭 XUL 작성이 필요하다면 걱정하지 마세요.  Javascript 의 친구 XPCOM 이 있거든요.  XPCOM 은 나중에 얘기되겠지만 채워주지 못했던 2% 를 보충해 주지 않을까 생각이 되네요.

음.. 그럼 대충 프로그램은 어떻게 작성할지 윤곽이 나오는군요.  UI 는 XUL 로 하고 내부 루틴은 Javascript 와 XPCOM 으로 한다라..  괜찮은 조합인지는 좀 더 살펴봐야 하겠어요.  근데 뭐가 대단하길래 XUL 을 써서 프로그래밍하라고 하는지 이해를 할 수 가 없군요.

그러게요.  저도 처음엔 XUL 을 가지고 어떻게 프로그래밍할지도 몰랐고 뭐 부터 시작해야 할지 몰랐는데요.   저에게 가장 큰 문제는 UI 였어요.  비록 wxWindows 나 gtk, 매우 기본적인 윈도우즈 UI 는 할 수 있었는데요.. 왜 제 머리 속에서는 그렇게 복잡하던지.. ㅋㅋ

아! 저에게 제일 중요한 것은 label 이나 button 같은 것들은 1px 단위로 정교하게 조절하는 것이였어요.

근데 XUL 같은 경우는 HTML 코드에서 CSS 로 margin 주고 padding 주고 더군다나 *-top, *-left, *-right, *-bottom 같은 문법으로 정교하게 할 수 있으니까, 지금 가진 지식가지고 나름대로 쉽게 UI 를 할 수 있을 것 같더라구요.

그리고 Firefox 내 확장 모듈로 작성할 수 있고, standalone 형식으로 할려면 XULRunner 를 사용해서 배포할 수 있다고 장점으로 말하길래, 먼가 대단한 줄 알고 사용해 보게 되었죠. 

그리고 XULRunner 가 윈도우즈용, 맥용, 리눅스용 전부 지원한다고 하길래, 우와! XUL 로 한번 만들어 놓으면 모든 플랫폼에서 다 쓸 수 있는거야? 라고 생각했죠. -_-;

왜 이리 말투가 썩소를 지으며 말하는 것 같죠?  뭐 별로 안좋은 기억이라도 있나봐요?

ㅡ.ㅡ;  말투가 그래요?  흠흠.. 뭐 원래 제 말투가 썩소가 주가 되기 때문에 크게 마음 상하지 마세요.  좋지 않은 기억이라…  생각을 좀 해봐야 알겠지만..

근데 저의 경우, XULRunner 를 이용해서 standalone 형식으로 배포를 해봤기 때문에 다른 확장팩 배포가 아니라 그냥 안좋은 기억 말해도 돼요?

음.. 배포판 크기가 넘 커요.  최소 배포판 크기가 6M (lzma? 로 압축을 극한으로 해서) 정도 되요.  이게 생각보다 걸리더라구요. ㅋ  어떻게 alert 하나 뛰우고 끝내는 프로그램 배포판 크기가 6M 씩이나 해야 하는 거냐구요.  ㅋ 물론 XUL 프레임워크이 있어야 하니까, 어쩔 수 없이 같이 배포해야 하니 당연히 용량이 커지는 건 마땅한데 말이죠.  제 생각에서는 윈도우즈 비스타에 built-in 되서 마이크로소프트에서 배포해 줬으면 좋겠어요.  아니면 XP 서비스팩에 넣어서 배포해 주면 빌에게 유혹의 키스를 보낼텐데..

음.. 다른 건.. XUL 어플리케이션을 만들면서 “그냥 차라리 XUL 프로그램으로 만들지 말고 웹 어플리케이션으로 만들 걸 그랬어“라고 한번쯤 생각해 봤다는 거예요.  XUL 프로그램도 HTTP 서버랑 통신할 때 Ajax 처럼 통신을 하기 때문에 (물론 다른 방법 많지만..), 그냥 웹 어플리케이션으로 만드는 거랑 XUL 랑 만드는 거랑 뭐가 이점인지 헷갈릴 때가 있더군요.  웹 어플리케이션으로 XUL 인터페이스를 대체할 경우, 사용자는 배포판을 설치할 필요도 없을꺼고, 웹 브라우저 성격도 타지 않을 꺼고, 오히려 이득인데 말이죠.

그럼 XUL 어플리케이션에는 XUL 만 할 수 있는 기능을 중점으로 최소화해서 배포하면 되잖아요?

음.. 좋은 생각이지만 그것도 생각해 봤죠.  XULRunner 를 통해서 standalone 형식으로 실행할 경우, local 자원을 모두 access 할 수 있기 때문에 많은 일을 할 수 있었는데요, 문제는 그럼 그냥 윈도우즈 UI 로 짜지 구지 XUL 로 짤 필요가 있을까?  배포판도 6M 가 넘고, 리눅스용 맥용은 10M 하는데..

크로스 플랫폼이라고 하지만 XPCOM 단에서는 결국 크로스 플랫폼 생각하면서 C/C++ 코딩해야 하니..

그럼 뭐가 장점이지?  헷갈리더라구요.

아닛! 이사람이.  XUL 을 써라는 거야 말라는 거야?

지금 머리 속의 결론은 써도 그만, 안써도 그만.  단 firefox 확장팩은 저도 몰라요.

간단한 UI + 간단한 내부 루틴이 필요하다면 해당 플랫폼 언어를 사용하는 것을 추천하고, 복잡한 UI + 복잡한 내부 루틴을 쓴다고 해도 해당 플랫폼 언어를 추천합니다.

크로스 플랫폼을 지향하며, 윈도우즈용, 맥용, 리눅스용 모두 같은 look & feel 을 원한다면 잠시 XUL 사용을 권해드리지만 원츄!하지는 않아요.

어차피 XPCOM 단에서는 모두 크로스 플랫폼으로 코딩을 하는게 필수~

새로운 UI 언어에 대한 경험을 원한다면 원츄!  XPCOM 을 알고 배우고 사용해 보고 싶다면 원츄!

[항상 feedback/의견 댓글로 받습니다.  오류 사항, XUL에 관한 질문이 있을 경우, 모두모두 댓글로 남겨주세요.]

SpiderMonkey 를 이용한 개발 일기

오픈 소스 브라우저인 firefox 의 JavaScript 엔진인 SpiderMonkey 에 대한 제 개발 및 사용 경험담에 대해서 조금씩 적은 문서를 만들어 봤습니다.

http://weongyo.org/docs/

홈페이지 및 게시물 첨부 파일로 다운로드 받으실 수 있으며 아래의 이미지을 통해서 목차를 보실 수 있습니다. 아직 문서가 처음 공개하는 것이라 내용이 조금 서툴 수 있지만 feedback 은 언제나 환영입니다. 여러분의 질문 및 feedback 을 기반으로 조금씩 업데이트 하겠습니다.

그리고 LaTeX 원본 파일과 pdf, dvi 를 LGPL 하에 공개합니다.

http://weongyo.org/docs/SpiderMonkey/

에서 컴파일을 위한 style 등등이 있습니다.

회사를 퇴사하며

초창기 멤버로써 또한 PS ScanW3B 의 엔진 개발자로써 그 동안 일해 온 회사를 정식으로 그만두게 되었습니다. 원인은 저의 의지와는 상관없는 내부적인 분열로 이루어졌습니다.

앞으로의 미래에 어떤 일들이 기다릴지 궁금합니다. 전율이 느껴집니다. 이제 어떤 선택을 하면 좋을까요?

기억력 감퇴.

최근들어 메모의 중요성을 절감하고 있습니다. 한국에서 먹어보지 못한 맥주들을 한번씩 마셔보자는 의도로 접근을 했었는데, 이게 문제를 일으키고 있는 듯 하네요. 술이 저의 뇌에 많은 영향을 주는 듯 하고 이전과 비교해서 기억력이 많이 떨어져 있는 듯 합니다.

그래서 컴퓨터로 메모를 잘 할 수 있는 도구나 기억을 기록하는 방법이나 여러 자료들을 찾아 요즘 급격히 떨어져 버린 *흥미*라는 녀석을 북돋을려고 노력하고 있습니다.

그 중 찾은 것은 Freemind 라는 Mind Map 도구입니다. UI 도 깔끔한 편이고 조작도 간단해서 기억을 정리할 때 이용하고 있습니다.

맥주을 즐겨 마시는 버릇을 없애는 것이 가장 현명한 방법이겠지만, 이렇게 된 바에 메모하는 습관이라도 나중을 위해 좀 키워 놓아야 할 것 같습니다.

멜번이여 안녕.

4 개월 동안 몸 담고 있었던, 멜번 생활을 오늘 (2006 년 3 월 27 일)로써 마감하게 됩니다.  나 자신에게 많은 일들이 있었고 많은 생각을 할 수 있도록 한 기간들.  인생에 있어서 결코 잊지 못할 기억들로 남을 것입니다.

로벗, 슬리너, 리사와 같은 좋은 친구들을 만날 수 있어 너무 좋았고, 근 4 개월 동안 주변에서 한국 사람 만날 일이 없어서 또 좋았던 것 같습니다.  그리고 내 맘을 설레게 했던 알프스 소녀두요.
내일 화요일 (오전 8:05) 비행기로 브리즈번으로 날라갑니다.  다시 그 곳에서 생활을 계속 하게 되겠지요.
다시 survival english 가 시작될려고 합니다. 그 동안의 호주 생활은 여기에서 보실 수 있습니다.

안녕 멜번.

ROVM (원격 객체 가상 머신) v0.1.35a 릴리즈.

그 동안 암호화 통신에 대한 작업을 계속 하였는데, 그에 대한 결실을 조금 맺게 되었습니다. 처음해보는 OpenSSL 사용에 대해서 미숙하게 나마 mod_ssl 을 빼끼다 시피 하였네요. ^^; 역시 컴퓨터 실력이 별로 인가 봅니다. 암호화 통신은 ROVM 서버에서 중요한 위치를 차지하는 부분인 만큼, minor version 을 올리게 되었습니다.

http://rovm.sf.net 에서 자세한 내용 및 파일 다운로드를 할 수 있습니다. (KLDP.net 의 경우 SCP 접근이 현재 안되는 군요.)

아래는 ChangeLog 입니다.

0.0.35a -> 0.1.35a

• ROVM Server
  • OpenSSL 을 이용한 암호화 통신을 기본으로 사용하도록 수정되었습니다. ROVM Server 의 현재 버전과 통신하기 위해서는 반드시 ROVM Client 및 ROVM Interface 를 업그레이드 해주셔야 합니다.
  • 사용자 인증 기능이 새롭게 추가되었습니다. conf/passwd 파일을 htpasswd 를 이용하여 생성해 주셔야 합니다.
  • 파일 옵션 기능이 새롭게 추가되었습니다. 이제 바이너리를 수정하지 않고 옵션을 변경할 수 있게 되었습니다. conf/rovm.conf 파일을 참조하시기 바랍니다.
• ROVM Client v0.0.1g
  • 암호화 통신이 가능하도록 소스가 수정되었습니다.
  • 사용자 인증이 가능하도록 소스가 수정되었으며, e://<userid>@<hostname>:<port> 형식으로 접근할 수 있습니다.
• ROVM Interface v0.0.1c
  • 암호화 통신이 가능하도록 소스가 수정되었습니다. 하지만 사용자 인증 기능은 Anonymous 모드만 지원하고 있습니다.
• ROVM Library v0.0.1g
  • SHA1 모듈이 추가되었습니다.
  • math 모듈이 추가되었습니다.

문서 작업은 언제나 피곤해.

ROVM 패키지는 모두 준비되었습니다. 이제 릴리즈만 하면 됩니다. 하지만 릴리즈하고 나면 끝이 아니라서 문제입니다. 마지막으로 문서 작업을 하지 않으면 의미가 없어져 버립니다. 결국 릴리즈를 하고 싶어도 몸이 근질근질거려도 문서 작업을 하지 않고 릴리즈를 해버리면 이 세상에 저 혼자만 바뀐 내용을 알 수 있을 겁니다.

오늘은 문서 작업을 하였습니다. 이제 내일 쯤으로 홈페이지 내용 추가 및 LaTeX 컴파일을 완료하고 정식 릴리즈를 할 생각입니다. freshmeat.net 의 내용도 업데이트를 해야 겠군요. 릴리즈를 하기 전에 반드시 해야 할 내용에 대해서 아래에서 정리해 보겠습니다. 아래는 업데이트해야 할 목록입니다.

• ROVM Server 문서
• ROVM Tutorial 문서
• ROVM Client 문서
• ROVM Interface
• ROVM Install 문서
• ROVM Extension 문서
• 그리고 위에서 언급된 문서들의 영어 문서 번역 작업
• LaTeX 컴파일 (ps 작성, pdf 작성)
• ChangeLog 작성
• 홈페이지 내용 업데이트
• KLDP.net 에 파일 릴리즈
• 메일링 리스트에 릴리즈 사실 공표
• KLDP.org 에 릴리즈 사실 공표
• KLDP.net 에 릴리즈 사실 공표
• freshmeat.net 에 릴리즈 사실 공표

에휴.. 왜 이렇게 릴리즈 하나 하기 전에 챙겨야 할 것이 많은지 모르겠습니다. 자동화라도 된다면 자동화하겠지만, 자동화될 대상들이 못되니..

오늘도 열심히 잡일을 합니다.

ROVM 의 정체성은?

아파치는 언제부터 개발되었는지 모르겠으나 내부 구조는 매우 잘 구현된 소스 코드이다. 소스 코드를 보면 알 수 있다. 모듈 부분을 보면 알수 있다. 이 사람들이 얼마나 구조를 유연하게 만들려고 노력을 하였는지 말이다.

ROVM 의 기본 구조는 아파치 서버 구조를 택하고 있다. 왜냐하면 Network 통신에 대한 개발이 많이 익숙하지 않은 나에겐 최고의 reference 이기 때문이다. 하지만 아파치 구조의 장점을 전혀 살리지 못하고 있는 것이 현실이다. 물론 ROVM 이 Apache 와 똑같이 되기를 원하지도 않으며, 똑같기를 원했다면 apache 모듈 형태로 ROVM 을 개발했을 것이다. (실제로 apache module 로 개발한 적도 있다. 물론 나 자신이 만족을 못해 그 코드를 버렸고 다음에 나온 것이 ROVM 이다.)

드디어 ROVM 의 OpenSSL 인증 및 설정 파일 기능, 인증 기능이 오늘 모두 삽입되어 마무리 되게 되었다. 하지만 돌이켜 보면 Apache Portable Runtime 라이브러리의 역활과 기존 Apache 의 SSL 모듈, 설정 기능들이 대부분 흡수되는 형식으로 프로그램이 짜여져 버렸다. (세상에서 제일 싫어하는 건 남이 짜놓은 코드가 인터넷에 있는데, 그걸 사용하지 않고 내가 다시 짜는 것이다. 내가 Apache 설정 기능 및 SSL 모듈들을 짜놓은 사람들보다 똑똑하고 경험이 많다면 다시 짜는 것이 맞겠지만 그 사람들보다 똑똑하다고 생각되지 않고 그냥 평범한 사람이라고 나 자신은 생각한다. 공부 목적으로 스스로 짜라면? 흥이다.)

Apache 와 비슷하지만 Apache 가 아닌.. APR 라이브러리와 APR-Util 라이브러리를 내부적으로 사용하면서 Apache 가 아닌 프로그램이 되었다. 정체성에 대한 혼란이 올 수 있는 시기라고 생각한다.

어디서 ROVM 만의 정체성을 찾아야 할까? Apache 는 HTTP 프로토콜을 처리하기 위해 존재하며, ROVM 은 ROVM 프로토콜을 지원하기 위해 존재한다. HTTP 프로토콜을 처리하기 전까지의 Apache 껍데기는 안정적이며 잘 설계되었으며 많은 System 에 이식될 수 있고 좋은 MPM 모듈을 갖추고 있는 매우 좋은 영양소이다. 즉, 이런 특징을 가지는 네트워크 통신 데몬을 만들고자 하는 사람에겐 천국이란 말이다.

ROVM 은 Apache 껍데기만 현재 삼키고 있다. 어디서 부터 껍데기의 시작이고 끝인지 현재 불분명하여 정체성의 문제를 격고 있다고 생각한다. 남의 좋은 점은 흡수하고 나 자신의 장점을 계속 발전시켜 간다면 언젠가 정체성의 해결은 둘째치고 다른 사람들에게 도움이 될 수 있는 프로그램으로 발전해 나갈 것이다. (사실 현재로썬 모든 기능의 구현이 정체성보다 우선되는 문제이다.)

그런 날이 오기를 기대하면 오늘도 컴퓨터 앞에서 잡생각 + 프로그래밍 생각을 하고 있다.