|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
Studio2008이라고 쓰신 것이 C++빌더를 말씀하신 것인지요. 그러면 아마도 C++빌더 2009나 2007을 잘못 쓰신 것이라고 생각되네요. 말씀하신 대로라면 최신 버전들도 VC++에 비해서는 아직 많이 불편한가봅니다.
C# 프로젝트를 주위에서 많이 보신다니, 그런 업계도 있을 수 있습니다. 그런데 주위에서 많이 보신다는 닷넷 프로젝트가 어떤 분야의 프로젝트인지요..? 패키지나 솔루션 프로젝트인지, 아니면 하드웨어 제어 관련인지, 수치 계산이나 알고리즘 관련인지... 설마 업무 개발 프로젝트를 가지고 말씀하시는 것은 아니겠지요. 시장이 결정내려준다는 말씀, 절대적으로 맞는 말씀입니다. 하지만 VC++이 시장은 아닙니다. 지금으로서도 VC++과의 경쟁은 시장의 일부일 뿐이고, 앞으로는 더 VC++과 직접 경쟁할 일은 점점 더 적어질 겁니다. 말씀하신대로 제가 코드기어, 정확하게는 지사에서 분사해서 데브기어의 임직원입니다. 그런데 그냥 한 사람의 개발자로서 커뮤니티를 운영하던 제가 왜 벤더에 조인했는지는 모르시겠지요. 말씀하신 것과 같은 부족한 부분들, 그것이 기술적인 문제이든, 시장의 문제이든, 인식의 문제이든 문제들을 한번 제대로 만들어보기 위해 조인한 것입니다. 그런데 개발자3님의 의견에는 불만이 있을 뿐 개선에 대한 희망은 안보이네요. 구체적으로 이렇게 되었으면 좋겠다는 얘기는 없고 이것도 싫어, 저것도 싫어, 다 문제점 투성이야, 이런 얘기입니다. 개발자3님은 한번이라도 볼랜드/코드기어의 QC 사이트에 기능 개선이나 기능 요청 글을 올려보신 적이 있으신가요. 그런 사이트나 시스템이 있는지도 모르셨는지요. 그걸 개발자들이 모르는 결과 앞에서는 그것도 역시 벤더의 잘못일 뿐인가요. 사이트에 뻔히 링크가 있어도 말이죠. 의외로 많은 분들이 불만의 단순한 토로와 개선 요청을 혼돈하는 것 같습니다. 화이팅과 격려를 바라는 것이 아닙니다. 하지만 뭔가 요청하려면 구체적으로, 그리고 제대로 된 방법과 경로로 요청해야 하지 않겠습니까. QC가 바로 공식적인 버그 신고 및 기능 요청 사이트입니다. 이런 것은 당연히 알 것이다, 라고 생각하시는 분들도 많습니다. 나에게 당연하니까, 내 주위의 개발자들에게 당연하니까 C++빌더의 벤더인 코드기어, 엠바카데로에서는 당연히 알 것이다, 라고 생각하시죠. 안그런 사례가 많습니다. 한국에서 이슈가 되는 기능들 상당수가 본사에서는 파악도 안되고 있습니다. 요청이 없었으니까요. 반면 해외의 개발자들은 QC 사이트를 적극적으로 활용하고 있습니다. 그래서 개선되고 추가되는 기능들도 해외 개발자들이 요청한 기능들 위주로 진행되고 있습니다. 그렇다고 한번쯤 요청 글을 올리면 반영될까요? 그렇지 않습니다. 더 많은 요청을 받은 기능들이 우선적으로 반영됩니다. 그럼 저라도 열심히 요청을 올리고 하면 되겠군요. 맞습니다. 그런데 제가 하루종일 그 일만 할 수 있을까요. 또 도배성으로 찬성을 표시하는 것을 방지하기 위해 한사람이 QC에 찬성 표를 할 수 있는 데에 한계도 있습니다. 당연하겠죠? 그러면 왜 그 많은 한국의 C++빌더 개발자들은 QC 사이트에 아무런 의견을 표시하지 않을까요. 가끔은 정말 급한 버그 때문에 여기 볼랜드포럼에도 찬성 표 좀 올려달라고 하는데도 저와 가까운 몇사람을 제외하면 기껏 두세 표 정도 올라갑니다. 왜 그런지에는, 제가 아는 것만도 몇가지 이유가 있습니다. 첫번째로, 일단 참여가 귀찮은 사람들이 많습니다. 뭔가 불만이 있어도 최소한의 노력이라도 들여 의견을 표시하는 자체가 귀찮은 분들이 많습니다. 아 그럴 수 있습니다. 두번째로, 영어 사이트에 영어로 쓰는 것이 어렵고 힘든 분들이 많습니다. 아 있을 수 있는 일입니다. 그런 경우에 제게 요청하시면 대신 올릴 수 있습니다만, 역시 저 한 계정에 여러가지로 집중되기 때문에 직접 올리는 것이 가장 좋습니다. 세번째로, 불법사용자가 많습니다. 사실 정품 사용자보다 불법 사용자가 압도적으로 많습니다. 이런 분들은 당연히 벤더 사이트에 뭔가 글을 쓰지 않습니다. 물론 그동안 벤더에서 잘못한 것이 많습니다. 하지만 개발자 각각의 분들이 가진 불만의 대상이 되었던 기능에 대해 요청도, 찬성 표시도 하지 않았다면 적어도 그 부분까지 벤더나 제 잘못은 아닙니다. C++빌더는 VC++ 자체가 아니고, VC++과 경쟁하는 문제에 올인하는 것도 아니기 때문에, 누구도 요청하지 않았거나 요청이 적은 기능들까지 100% 쫓아갈 이유는 없기 때문입니다. 뭐 이쪽은 일하는 분야차가 있으니 부정확하다고 말씀을 드렷지만 C#정말 많이 늘어나고 있습니다. 부정하시는 근거모르겠네요.
한전, LGT등등 많이 봣는데요?.. 거참.. 어느 분야만 보신건진.. 그리고 제가 불만만 있고 개선에 대한 희망이 안보인다고 하시는데.. 저 불만사항들이 해결된다면 좋겠다고 쓰신건 못보셨나봅니다. 불만사항은 뒤집어 말하면 개선 해야할 사항이라고 생각 안되시나요? 제가 볼땐 박지훈님은 오히려 안좋은 점이나 단점을 지적하는 사람들을 무조건 VC++칭찬맨 + 빌더까로 보시는걸로 보이는데요? 그리고 개선사항이나 불만사항들을 갖고 있으면 무조건 메일을 보내야 하는거고 개선 해달라고 들이대야 하는건가요? 고객은 고객이지 Q/A센타나 테스터가 아닙니다. 보고할 의무도 없고 아무것도 없습니다. 저는 MS에 아무런 보고나 불만사항 접수 안했습니다. 근데 그쪽은 점차 개선이 되는데요? 개선해야 하고 바꿔 나가고 혁신하는것은 기업에서 할일이지 그걸 고객이 안해줬다느니 식이시면 참... 제가 읽은 뉘앙스는 대략 그런것도 안올리면서 왠 불만이 많냐는 것 같은 느낌입니다. 저라면 불만=개선사항이라고 받고 개선하도록 하는게 좋겠다고 글한줄 남기겠습니가. 그리고 지적해줘서 고맙다고요. 근데 박지훈님은 꼭 대학생들 이나 초보 프로그래머들 프로그래밍 해놓은거 문제사항들 꼬장꼬장 집어내면 뭘 그렇게 집어내느냐. 하면서 문제사항과 버그, 에러검출에 오히려 고마워 하는것보다 넌 잘알지도 못하면서 지적한다라고 하는듯한 느낌이 드는군요.. "C++빌더는 VC++ 자체가 아니고, VC++과 경쟁하는 문제에 올인하는 것도 아니기 때문에, 누구도 요청하지 않았거나 요청이 적은 기능들까지 100% 쫓아갈 이유는 없기 때문입니다." 경쟁하는 툴이 아니라면 비교조차 할 필요는 없을텐데요?.. 좀.. 앞뒤가 안맞는군요.. 어쨌건 만약 제가 말한 기능들이 필요 없다면 결국 빌더는 소단위 프로젝트또는 1~2명의 개인 개발툴에서 더 벗어 나기 힘들겁니다. 컴파일하는데 1시간 2시간씩 걸려버리면 RAD로 아무리 빨리 개발해봐야 어따 쓰겠습니까?. 뭐 얘기 한사람은 있을듯 싶군요.. 마지막으로 기업입장에서 고객불만사항=개선필요사항 입니다. 위기능들이 필요 없는 것이라고 생각 된다면..... 저를 또한명의 빌더까로 보실테지만 10년넘게 이짓하면서 빌더 퍼트린곳 많습니다. "그런것도 안올리면서 왠 불만이 많냐"는 것이 아니라, "요청하시지 않았는데 왜 이루어지길 바라시느냐"는 말입니다. 의미상 완전히 다른 말입니다만, 비슷하게 느껴지시나봅니다.
"VC++과 경쟁하는 문제에 올인하는 것"이 아니라고 했습니다. VC++과 경쟁하는 툴이 아니라고 한 것이 아니구요. 코드기어/엠바카데로의 QC 사이트는 Q/A도 담당하지만 고객이 원하는 기능을 요청하는 기능들을 접수하는 역할도 합니다. 버그 레포팅을 하라는 말이 아니고 원하는 기능이 있으면 요청하시면 된다는 말씀을 드린 겁니다. QC에 올라온 의견이나 제안 등은 찬성 수에 따라 실제로 반영되기 때문입니다. 벤더는 점쟁이가 아니기 때문에, 자체적으로 필요하겠다고 판단해서 추가하는 기능들도 있지만, 고객이 원하는 기능에 대해 말해주지 않으면 그 기능이 반영되기는 어렵다고 말씀드린 겁니다. 당연한 말씀을 드린 건데 감정적으로 받으시는 것 같습니다. 여러차례 제 글의 느낌이나 뉘앙스를 강조하면서 말씀하시는데, 내용이 반박성이니까 주관적으로 받아들이신 게 아닌가 싶습니다. 느낌으로 말씀하시지 마시고 제가 드린 말 자체를 보시면 좋겠습니다. 개발자3님은 경쟁툴보다 못한 부분만 줄줄이 나열해서 요구사항이라고 접수를 받으면 지적해줘서 고맙다라고 말씀하실 수도 있겠습니다만, 안타깝게도 개발자3님의 글은 제가 본사에 기능을 요청하고 요구하는 데에 거의 도움이 안되었습니다. '고객불만사항 = 개선필요사항'이라고 받아들인다면 그건 영업사원의 입장일 것입니다. 저도 엔지니어이고, 제가 기능을 요청할 대상도 본사의 엔지니어이기 때문에 구체적이지도 않고 알아듣기 힘든 대충대충의 내용으로 기능을 요청할 수는 없습니다. 마지막으로, 개발자3님을 빌더까(?)로 간주하지 않았습니다. 만약 그랬다면 위에 쓴 것처럼 나름 성의있게 답변을 쓰지도 않았을 것입니다. 가지신 불만을 생산적으로 반영할 방법으로 QC 같은 통로를 제안드린 것입니다. 개발자3님이 받아들이고 반응하신 글을 볼 때, C++빌더가 VC++과 경쟁하는 문제에 올인하지 않는다고 드린 말씀을 다시 곱씹어보시면 좋을 듯 합니다. VC++이 모든 C++ 개발자들이 꿈꾸는 궁극의 C++ 개발툴이 아닌 이상, C++빌더가 VC++을 흉내내는 문제에만 올인할 수 없다는 것입니다.
VC++에 익숙한 개발자의 입장에서는 당연히 C++빌더가 VC++의 모든 기능을 다 흡수하고 또 한편으로 더 나은 기능들을 유지하기를 바랄 것입니다. 하지만 실제 비즈니스의 관점으로 예상해보면 아마도 그런 일은 영원히 없을 것입니다. 저는 C++빌더가 멀티플랫폼으로 가는 것이 (물론 개발자3님의 관점에서는 현재 없는 기능이므로 아무 소용없는 것일 수 있겠습니다만) 지금 VC++이 가진 어떤 장점보다도 더 뛰어난 비젼이라고 생각합니다. 그리고 적어도 제가 바라보기에는, VC++을 흉내내는 문제보다 멀티플랫폼 지원에 더 열광하는 개발자들이 훨씬 더 많습니다. 그렇기 때문에, 설사 앞으로도 영영 VC++을 100% 따라가지 못하더라도 벤더로서는 바른 길로 가고 있다고 생각됩니다. 아래 다른 글에도 댓글로 썼다시피, 지금으로서도 VC++이 따라오지 못하는 C++빌더만의 큰 장점도 많기 때문입니다. "물론 개발자3님의 관점에서는 현재 없는 기능이므로 아무 소용없는 것일 수 있겠습니다만" 요건 그렇게 생각하지 않구요.
제가 첨에 쓴글에 보면 어중간한 위치가 되어 버린 지금보다는 확실한걸 찾는게 맞겠다는 식으로 쓴게 있는데요.. .. 쩝.. 100만년만에 글쓰려니 영... 아무튼... 제가 말씀드린 사항들이 구체적이지 않아서 도움이 안된다니. 뭐 할말이 없습니다. 저위에 제가 말씀드린것들은 앞으로도 전혀 본사쪽이든 개선사항으로 언급이 없으시리라고 믿습니다. 다양한 개발환경지원(이건 박지훈님이 말씀하신 멀티플랫폼과 비슷하죠?), 컴파일 속도 개선, 병렬 컴파일, 네트웍 분산 컴파일, 코딩환경 개선등등... 마지막으로 비교 자료라는것이 이건 되고 저건 안되고 등등 나오는거 아닌가요? 이전에 박지훈님이 몇년전에 만든 자료에도 VC++에서 안되고 빌더에선 되고 둘다 되고 하는 식의 비교 자료 였던거 같은데요? 결국 비슷한 종류의 제품이나 물건을 비교 하게되면 이건되고 저건 안되고의 의견이 나오는건 정상인것 같은데요? 변함이 없네요.. 쩝.. 아쉽습니다. 새로운 모바일 플랫폼을 지원하는 개발툴이 코드기어에서 나온다고 해도, 그 플랫폼 시장이 제대로 생겨서 "돈" 이 만들어 지기까지의 시간이 오래걸린다면(코드기어가 아니라 개발자의 돈) 그건 지금 빌더 유저에게 어떤 매력이 있을까요.
멀티플랫폼 지원에 열광하는 개발자가 훨씬 더 많은지 아닌지는 모르겠습니다. 하지만 맞다고 가정 하고 그쪽을 집중적으로 강화한다고 하면 조강지처(Win32 개발자) 를 버리고 새장가 가는것과 다를 바 없습니다. 적어도 지금상태로 봤을때 양쪽 다 제대로 신경 쓸 만한 여력이 있는 것 같지도 않구요. 언제 개발툴이 나올 지도 모르는(그리고 개발툴이 나온다 해도 언제 시장이 활성화 될 지도 모르는) 새로운 플랫폼의 개발툴을 기다리는 것은 성공 시점을 알수 없는 프로젝트에서 밀린월급(업데이트)를 기다리며 무작정 시간 보내는것과 별 다를바 없다고 보여집니다. 취미로 개발을 하는 사람이 아닌 이상에야 단지 좋아하는 회사의 툴이 나왔다고 바로 사용 할 수는 없으니까요. 이 글의 원본글이 BC++ vs VC++이었고, BC++과 VC++이 부딛히는 영역이 꽤 많은만큼 그 부분에서 어느정도 대등한 능력을 가지지 않으면 점유율은 더 떨어질 것으로만 보이네요. BC++이 유리하고 많이 쓰이는 분야에서만 경쟁 한다면, 그 외의 분야에서는 매력을 완전히 상실할겁니다. 개발자3님이 써주신 글의 내용은 기능 비교라기보다는 불만스러운 부분들로 보여서 제가 만들 자료에 참고하라는 의미로 받아들이지 못했군요. 아니면, 사람의 당연한 심리상 VC++에 비해 없는 기능이나 미약한 기능을 말하려고 하면 감정 섞인 불만이 터져나오는 것이 당연하든지 말입니다.
개발자3님뿐만 아니라 지금까지 댓글들을 보면 다들 C++빌더에 대해 단순히 RAD 개발 외에는 장점을 거의 알지 못하시고 계신데, 처음부터 제가 제안을 잘못 했던 거 같습니다. 여러 분들이 VC++ 대비로 생각하는 관점이 제가 자료를 만들어보려고 하는 관점과 너무 달라서, 자료를 만들려고 했던 것은 포기하기로 했습니다. 마이너스가 훨 더 클 거 같군요. C++빌더는 VC++ 클론이 아니라고 생각해왔는데, 의외로 그런 관점에서 보시는 분들이 많군요. 개발자3님께는 괜히 심기를 건드리는 글을 써서 머리만 어지럽혀서 죄송하게 되었습니다. 불만스러워하시는 정도로 볼 때 그냥 VC++로 옮겨가시는 것이 낫지 않을까 싶습니다. VC++에 비해 불만스러운 기능들이 다 지원되기도 어렵겠지만 설사 된다고 해도 여러 해가 지나야 할 것이니까요. 시장은 시장일 뿐이므로 마음에 들지 않는 부분이 더 많다면 더 마음에 드시는 툴을 선택하시는 것이 맞는 일이죠. 혹은... 이렇게 불만으로 가득한 툴인데 저도 따라서 C++빌더를 포기하는게 더 맞는지도 모르겠네요. 지금까지 C++빌더가 환영받고 있다고 생각해왔는데, 완전히 저 혼자만의 착각이었네요. 델파이에만 집중하든지, 아니면 델파이도 비슷할 거라고 보고 그것도 관두든지... 저 자신이 벤더의 일원이기도 하지만 나름 잘먹고 살다가 이짓을 해서 돈이 되는 것도 아니고... 커뮤니티의 여러분이 함께하고 있다는 착각이 아니었으면 절대로 선택하지 않았을 길이었거든요. VC++과 C++빌더의 공통점을 바라보는 시점으로 다시 조사하는건 어떨까요?
전 두가지 툴을 쓰면서 거의 비슷한데 타성에 젖은 팀의 분위기로 인해 수년간 VC++이 선택되는걸 봤습니다. 이는 두가지 툴을 익히는게 힘들다거나 서로가 만든 라이브러리 호환이안된다거나 하는 이유가 많았습니다. 하지만 VC++ 쓰는 실력이면 빌더 익히는거 힘달다는 표현은 빌더 익힐 시간을 들이기 싫다가 더 맞을 것입니다. (귀찮다.. ㅎㅎ) 공통점을 보여주는 주제들을 모으고 잘 된 튜토리얼을 만들면 상당히 좋은 자료가 될 것 같습니다. MP나 인크레드빌드 같은 기능은 분명 효과적인 기능들이었습니다. 하지만 그것 없이도 얼마든지 개발 가능합니다. 주요 모듈을 라이브러리로 효과적으로 묶거나 등등... 게임 엔진 코드 혹은 클라이언트 코드 등은 나중에 리빌드하는데 코드 인클루드 구조에 따라서도 엄청난 차이를 보입니다. 직접 그런 고급? 코드들을 보아도 실망스런 인클루드 구조를 많이 봅니다. (뭐 급해서 그랬다고 할 수 있겠지만... ㅎㅎ) 이런 공통적인 이슈들을 모아서 시장별로 접근해 보는것도 좋을것 같습니다. 차이점이 아니라 공통점으로... 데브피아의 인기 자료를 빌더에 적용하고 빌더 사용이 부드러운 분들의 코드를 보여서 쉬우면서 효과적인 것들을 모아봅시다. 요즘 시간이 남다보니(사실 스스로 바쁘지만.. ^^;) 한 2년은 집중할 수 있는데 관심있는 분들이 있다면 C++ 연합을 만들고 싶습니다. 관심있는 분들은 댓글 바랍니다. ^^ 제가 볼땐 박지훈님이 빌더에 너무나 많은 애정을 쏟다 보니 받아 들이지 못하시는 부분도 있어 보이네요..
무리는 아니십니다. 혼자 사이트 운영에 그긴 세월을... 한 10년넘었죠? 특별한 애정 같은게 있어야 가능한 일이죠.. 근데요. 박지훈님은 툴이란것이 개인적으로 좋고, 싫고, 불만이 많고에 따라서 사용여부를 결정하시나요? 저는 그 업무를 분석하고 그 업무에서 가장 최고의 Performance(기간, 편의성, 등등)를 낼수 있는 것을 선택합니다. Tool은 그냥 망치나 톱정도라고 봅니다.. 뭐 더 애착가는 것이 있을 지언정 낫이 좋다고 나무깍는데 낫을 쓸수는 없죠. 물론 윈도우 환경하에서 가장 강력하다고 생각하는 것이 빌더입니다. 따라서 빌더에 불만이 있다고 뭐 빌더를 떠나서 VC로 가고 자시고가 아니죠.. 다만. 빌더라는 좋은 툴이 대단위 프로젝트에서 먹히지 않는것(계속 얘기한..) 다양한 개발환경의 지원 안되는것등...이 개선되야 하고 VC++에 비해서 안좋다고 얘기 한겁니다. 뒤집어서 VC++이 빌더에 비해서 안좋은것 많죠. 수두룩 둑둑 합니다. 그걸 나열하길 바라셨는지.. 모르겠네요. 그거야 여기 들어오는 사람은 다 알죠.. 굳이 적을껏까진.. 그리고 업무분야가 많이 틀리다보니 빌더의 전체 기능을 모를수 있습니다. 제가 아는 부분들과 필요한 부분들 없어서 아쉬웠던것들 비교 대상은 결국 제가 알고 있는 분야에 한정되죠..모바일, 대단위 프로젝트, 개발환경등..... 좀 떨어져서 보시는것도 괜찮습니다... 덧붙여서.. 지원하는데 안쓰는것과 그 기능을 다른 식으로 대체 하는것은 엄연한 차이가 있습니다.. 저희도 라이브러리 많이 나눠쓰긴 하지만 라이브러리로 나누는것도 어느정도 한계가 있습니다. 숫하게 변경될 부분을 라이브러리화 하진 못하죠.. 2년전에 영상처리쪽 일할때 빌더로 컴파일 해서 1시간 30분 걸린적이 있습니다. 나누고 나누고 또 나눠서 40분까지 되었지만... 40분이라.... 생산성.. 쥐약이죠... 제가 컴파일 속도에 이렇게 예민한것은 제가 만나서 추천했을때 reject당한 대부분의 사유가 컴파일 속도 였습니다. 아마 저는 앞으로도 계속 빌더를 사용은 할겁니다. VC++도 사용 할 꺼구요. 팀프로젝트에서는 불가능 하겠지만 팀원들을 위한 툴이라든가 개인적인 툴. 소단위는 계속 쓸껍니다... 그리고 제가 뚝딱뚝딱 툴 만들어 내는것 보고 눈 휘둥그래지는 부하직원들한테도 추천을 할꺼구요. 지난세월처럼요. 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
그리고 모바일 지원은 전 WM만을 예로 든건 아닙니다. 그냥 툴로서 다른쪽에도 가능하냐 안하냐는 거였죠.. S60지원 툴이였다는건 첨듣는데 그랬군요. 근데 지금도 그렇게 되는지요?...
시장적 관점을 몰때 많은 차이가 있네요.. 제가 볼때 C#많이 사용하던데요?.. 성장속도는 느리지만 점점 늘어 나곤 있습니다. MS환경하에서 C#은 상당히 괜찮은데요... 그리고 자바로 서버 개발하는 분들, 모바일 자바 개발자분들, 등등 JBuilder쓴느 분들은 한명도 못만나봤습니다. 당장 잡코리아에서 뒤져봐도 되겠네요.. 뭐가 사용율이 높은지는요...
뭐 이건. 어찌됐건. 정확한 근거 자료를 서로 들이 밀기 전엔 너무 차이나는 관점이라 답없겠으니.. 논외조치~
어찌됐건. VC6:CB6, VC2008:Studio2008, 또는 VC2005 기준입니다. 속도 늦죠. 병렬 컴파일, 네트워크 이용한 분산 컴파일, 지원 X, 그리고 윈도우즈에뮬레이터를 지원가능한 방안.. 등등. 제기준에섭니다.
음 씨빌더 애착가는 사용자의 비교된 아쉬운점이라고 보시면 되겠군요..
아래 글보니 코드기어 직원이신듯한데요 제가 만나봤던 수많은 C++사용자들의 대부분 불만 및 비교사항이였습니다.
반영하시고. 좋아 진다면 좋은지 안좋은지는 시장이 결정 내려 줄겁니다.