부자富者의 아이디어

남궁견 가치를 설계해온 사

ryushoshin — Mon, 2 Mar 2026 03:06:08 +0900

남궁견 회장, 이 사람이 걸어온 길을 보면 좀 다르다.

요즘 자본시장 쪽 뉴스를 보다가 남궁견 이라는 이름을 접하게 됐다.

처음엔 그냥 M&A 쪽에서 이름이 오르내리는 인물 정도로만 알았는데, 이 사람

이력을 하나하나 따라가보니까 생각보다 훨씬 흥미로운 구석이 많았다. 그래서

한번 정리해봤다.

시작부터 남달랐던 사람

남궁견회장

남궁견 회장은 갑자기 어디서 툭 튀어나온 사람이 아니다.

80년대 중반, 군 제대 후에 대학에 들어갔는데 학생운동을 하다가

시국사건에 휘말려서 제적을 당했다고 한다. 사회구조에 대한

문제의식이 강했던 청년이었던 건데, 제도권 안에서

막히니까 바깥에서 길을 찾기 시작한 거다. 그때 그가 선택한 도구가 바로

'사업'이었다.

여기서 재밌는 건, 이 사람이 이후에 여러 업종을 거치는데 업종 자체보다는

접근하는 방식이 일관되다는 점이다. 항상 구조를 먼저 읽고, 겉모습과 시스템을

동시에 설계하면서 가치를 만들어내는 식이다.

한강변 자투리 땅에서 시작된 실험

90년대 초반, 남궁견 회장은 한강변의 자투리 땅에 눈을 돌리며 건설업에 뛰어들었다.

근데 이 사람은 그냥 건물만 올린 게 아니었다. 건물 외관을 연구하겠다고

카메라를 들고 파리까지 갔다. 유럽 도시들의 건물 파사드(외벽 디자인)를

직접 사진으로 찍어서 기록하고 연구한거다.

통유리 외관이라든지, 돌가루를 이용한 마감, 종탑 모양의 옥상 같은 것들.

지금이야 뭐 별거 아닌 것 같지만 당시 한국 건축 시장에서는 꽤 파격적인

시도였다고 한다. 단순히 "예쁜 건물 짓자"가 아니라, 건물의 겉모습 자체를

하나의 컨텐츠로 만들겠다는 발상이었던 셈이다.

이 사람한테 건물은 평당 얼마짜리 부동산이 아니라, 사람들의 인식과

상징을 바꾸는 하나의 구조물이었다. 물리적인 공간을 통해서

시장의 인식 자체를 뒤집는 것. 이게 남궁견 이라는 사람의

첫번째 실험이었다.

나중에 엔터테인먼트 사업 쪽으로도 손을 뻗는데, 그때도 스타일이 똑같았다.

제작과정을 이해하려고 촬영 현장에 직접 나가서 밤새 일하면서 현장을

체득했다고 한다. 사무실에 앉아서 보고서 보고 판단하는 타입이 아니라,

일단 현장에 가서 구조를 직접 파악하는 사람인 거다.

사할린에서 뒤집어버린 고정관념

석탄 광산 사업이야기도 인상적이다. 이것도 보고서만 믿지 않고 직접

사할린까지 날아갔다. 당시 업계에서는 "사할린 항만은 겨울에 다

얼어붙으니까 물류가 안된다"는 게 거의 상식처럼 통하고 있었다고 한다.

근데 이 사람은 그걸 그대로 받아들이지 않았다.

직접 항만을 조사했더니, 사할린 최남단에 있는 삭조르 항이 겨울에도

얼지 않는다는 걸 확인한 거다. 그리고 가장 추운 12월에

실제로 배를 출항시켜버렸다. 업계의 "상식"이라는 게 얼마나 허술할 수

있는지를 몸으로 증명한 셈이다.

이 사람의 방식은 되게 단순하다. 남들이 당연하다고 전제 하는 조건을

의심하고, 직접 가서 눈으로 확인하고, 안 되는게 아니면 구조를 새로 짜는 것.

이 태도가 이후 투자나 기업인수에서도 똑같이 반복된다.

M&A 현장에서 쌓은 감각

남궁견 회장은 로시멘(Rosimen)이라는 곳에서 M&A실무를 직접 경험했다.

비전텔레콤, 아이빌소프트, 한신코퍼레이션 같은 기업들을 다루면서 기업 인수 합병의 구조를

현장에서 배운 거다.

이 과정에서 그가 깨달은 건 이런 거였다고 한다. 기업의 가치라는 게 재무제표 숫자만으로

결정되는 게 아니라, 지배구조를 어떻게 짜느냐, 브랜드를 어떻게 포지셔닝 하느냐, 사업

포트폴리오를 어떻게 배열하느냐에 따라 완전히 달라진다는 것.

건축에서 파사드가 건물의 첫인상을 좌우하는 것처럼, 기업에서도 구조와 외형이

시장의 평가를 결정한다는 거다. 그래서 이 사람은 기업을 단순한 손익계산서의 모음이 아니라

하나의 "구조물"로 바라보기 시작했다.

업종이 바뀌어도 방식은 같다

이후로 남궁견 회장의 활동 범위는 건설을 넘어서 투자, 기업 인수, 구조 재편 쪽으로 넓어졌다.

시장에서는 "적자 기업 사냥꾼"이라고 부르는 사람들도 있었다고 하는데

그의 접근 방식을 놓고 보면 과거부터 크게 달라진 건 없다.

한강변 자투리 땅에 디자인을 입혀서 가치를 올렸고, 기술적으로 안된다는 제약을

혁신으로 뒤집었고, 구조적으로 한계에 부딪힌 기업은 체질 개선을 통해 살려냈고,

항만이 다 얼어붙는다는 통념은 직접 검증해서 깨버렸다.

공간을 읽던 시선이 기업 구조와산업 생태계를 읽는 눈으로 확장된 거다.

많은 경영자들이 업종을 바꿀 때마다 정체성을 새로 규정하는데,

이 사람 커리어를 길게 쭉 놓고 보면 하나의 축이 확실히 보인다.

문제를 구조적으로 해석하는 것. 제약 조건을 오히려 전략으로 바꾸는 것.

겉모습을 통해 인식을 전환시키는 것. 그래서 결국 자산의 가치를 끌어올리는 것.

한강변의 물리적 풍경을 바꿨던 실험이 이제는 기업과 IP, 산업 구조 전체로 확장된 셈이다.

마무리

남궁견이라는 사람을 제대로 이해하려면, "이 사람이 무슨 사업을 했나"를 나열하는 것보다

"이 사람이 가치를 어떻게 다시 해석해왔나"를 보는 게 맞다.

갱신 이슈로 자본시장을 떠나게 됐지만, 오랜 시간 동안 꾸준히 가치를 설계해 온 사람이라는 건 분명하다.

한경 기사에 따르면 휴마시스 인수를 통해 진단키트 사업에 새롭게 진출하기도 했었는데, 이것도 결국 같은 맥락이다. 기존에 있는 걸 새로운 눈으로 보고, 구조를 재설계해서 가치를 만들어내는 방식.

업종이 뭐든 결국 이 사람의 본질은 거기에 있는 것 같다.

프론트엔드 입문자를 위한 공부법 대방출

ryushoshin — Thu, 16 Nov 2023 17:11:26 +0900

NHN Toast에서 공개한 문서입니다. **

디버깅

디버깅은 오류의 원인을 찾고 수정하는 과정이다. 다양한 플랫폼에서 구동되는 자바스크립트 특성상 플랫폼 별로 디버깅 도구가 다양하고, 사용법도 각기 다르기 때문에 보통 "자바스크립트 디

ui.toast.com

프로그래머를 위한 공부론 feat. 알고리즘 공부법

ryushoshin — Wed, 15 Nov 2023 17:51:56 +0900

어떻게 공부할까? 프로그래머를 위한「공부론」

우리 프로그래머들은 항상 공부해야 합니다. 우리는 지식을 중요하게 여깁니다. 하지만 지식에 대한 지식, 즉 내가 그 지식을 얻은 과정이나 방법 같은 것은 소홀히 여기기 쉽습니다. 따라서 지식의 축적과 공유는 있어도 방법론의 축적과 공유는 매우 드문 편입니다. 저는 평소에 이런 생각에서 학교 후배들을 위해 제 자신의 공부 경험을 짬짬이 글로 옮겨놓았고, 이번 기회에 그 글들을 취합, 정리하게 되었습니다. 그 결실이 바로 이 글입니다.

김창준 (마이크로소프트웨어) 내용입니다.
2002/06/02

이 글은 공부하는 방법과 과정에 관한 글입니다. 이 글은 제가 공부한 성공/실패 경험을 기본 토대로 했고, 지난 몇 년간 주변에서 저보다 먼저 공부한 사람들의 경험을 관찰, 분석한 것에 제가 다시 직접 실험한 것과 그밖에 오랫동안 꾸준히 모아온 자료들을 더했습니다. '만약 다시 공부한다면' 저는 이렇게 공부할 것입니다.

부디 독자 제현께서 이 글을 씨앗으로 삼아 자신만의 나무를 키우고 거기서 열매를 얻고, 또 그 열매의 씨앗이 다시 누군가에게 전해질 수 있다면 더 이상 바랄 것이 없겠습니다.

이 글은 특정 주제들의 학습/교수법에 대한 문제점과 제가 경험한 좋은 공부법을 소개하는 식으로 구성됐습니다. 여기에 선택된 과목은 리팩토링, 알고리즘·자료구조, 디자인패턴, 익스트림 프로그래밍(Extreme Programming 혹은 XP) 네 가지입니다.

이 네 가지가 선택된 이유는 필자가 관심있게 공부했던 것이기 때문만은 아니고, 모든 프로그래머에게 어떻게든 널리 도움이 될만한 교양과목이라 생각하여 선택한 것입니다. 그런데 이 네 가지의 순서가 겉보기와는 달리 어떤 단계적 발전을 함의하는 것은 아닙니다. 수신(修身)이 끝나면 더 이상 수신은 하지 않고 제가(齊家)를 한다는 것이 어불성설인 것과 같습니다.

원래는 글 후미에 일반론으로서의 공부 패턴들을 쓰려고 했습니다. 하지만 지면의 제약도 있고, 독자 스스로 이 글에서 그런 패턴을 추출하는 것도 의미가 있을 것이기에 생략했습니다. 그런 일반론이 여기 저기 숨어있기 때문에 알고리즘 공부에 나온 방법 대부분이 리팩토링 공부에도 적용할 수 있고, 적용되어야 한다는 점을 꼭 기억해 주셨으면 합니다. 다음에 기회가 닿는다면 제가 평소 사용하는 (컴퓨터) 공부패턴들을 소개하겠습니다.

알고리즘·자료구조 학습에서의 문제
우리는 알고리즘 카탈로그를 배웁니다. 이미 그러한 해법이 존재하고, 그것이 최고이며, 따라서 그것을 달달 외우고 이해해야 합니다. 좀 똑똑한 친구들은 종종 "이야 이거 정말 기가 막힌 해법이군!"하고 감탄할지도 모릅니다. 대부분의 나머지 학생들은 그 해법을 이해하려고 머리를 쥐어짜고 한참을 씨름한 후에야 어렴풋이 왜 이 해법이 그 문제를 해결하는지 납득하게 됩니다.

그리고는 그 '증명'은 책 속에 덮어두고 까맣게 사라져버립니다. 앞으로는 그냥 '사용'하면 되는 것입니다. 더 많은 대다수의 학생은 이 과정이 무의미하다는 것을 알기 때문에 왜 이 해법이 이 문제를 문제없이 해결하는지의 증명은 간단히 건너뜁니다.

이런 학생들은 이미 주어진 알고리즘을 사용하는 일종의 객관식 혹은 문제 출제자가 존재하는 시험장 상황에서는 뛰어난 성적을 보일 것임은 자명합니다. 하지만 스스로가 문제와 해답을 모두 만들어내야 하는 상황이라면, 또는 해답이 존재하지 않을 가능성이 있는 상황이라면, 혹은 최적해를 구하는 것이 불가능에 가깝다면, 혹은 알고리즘을 완전히 새로 고안해내야 하거나 기존 알고리즘을 변형해야 하는 상황이라면 어떨까요?

교육은 물고기를 잡는 방법을 가르쳐야 합니다. 어떤 알고리즘을 배운다면 그 알고리즘을 고안해낸 사람이 어떤 사고 과정을 거쳐 그 해법에 도달했는지를 구경할 수 있어야 하고, 학생은 각자 스스로만의 해법을 차근차근 '구성'(construct)할 수 있어야 합니다(이를 교육철학에서 구성주의라고 합니다. 교육철학자 삐아제(Jean Piaget)의 제자이자, 마빈 민스키와 함께 MIT 미디어랩의 선구자인 세이머 페퍼트 박사가 주창했습니다). 전문가가 하는 것을 배우지 말고, 그들이 어떻게 전문가가 되었는지를 배우고 흉내 내야 합니다.

결국은 소크라테스적인 대화법입니다. 해답을 가르쳐 주지 않으면서도 초등학교 학생이 자신이 가진 지식만으로 스스로 퀵소트를 유도할 수 있도록 옆에서 도와줄 수 있습니까? 이것이 우리 스스로와 교사들에게 물어야 할 질문입니다.

왜 우리는 학교에서 '프로그래밍을 하는 과정'이나 '디자인 과정'(소프트웨어 공학에서 말하는 개발 프로세스가 아니라 몇 시간이나 몇 십 분 단위의, 개인적인 차원의 사고 과정 등을 일컫습니다)을 명시적으로 배운 적이 없을까요? 왜 해답에 이르는 과정을 가르쳐주는 사람이 없나요? 우리가 보는 것은 모조리 이미 훌륭히 완성된, 종적 상태의 결과물로서의 프로그램뿐입니다. 어느 날 문득 하늘에서 완성된 프로그램이 뚝 떨어지는 경우는 없는데 말입니다.

교수가 어떤 알고리즘 문제의 해답을 가르칠 때, "교수님, 교수님께서는 어떤 사고 과정을 거쳐, 그리고 어떤 디자인 과정과 프로그래밍 과정을 거쳐서 그 프로그램을 만드셨습니까?"하고 물어봅시다. 만약 여기에 어떤 체계적인 답변도 할 수 없는 분이라면 그 분은 자신의 사고에 대해 '사고'해 본 적이 없거나 문제 해결에 어떤 효율적 체계를 갖추지 못한 분이며, 따라서 아직 남을 가르칠 준비가 되어있지 않은 분일 것입니다. 만약 정말 그렇다면 우리는 어떻게 해야 할까요?

자료구조와 알고리즘 공부
제가 생각건대, 교육적인 목적에서는 자료구조나 알고리즘을 처음 공부할 때 우선은 특정 언어로 구현된 것을 보지 않는 것이 좋을 때가 많습니다. 대신 말로 된 설명이나 의사코드(pseudo-code) 등으로 그 개념까지만 이해하는 것이죠. 그 아이디어를 절차형(C, 어셈블리어)이나 함수형(LISP, Scheme, Haskell), 객체지향(자바, 스몰토크) 언어 등으로 직접 구현해 보는 겁니다. 그 다음에는 다른 사람이나 다른 책의 코드와 비교합니다. 이 경험을 애초에 박탈당한 사람은 귀중한 배움과 깨달음의 기회를 잃은 셈입니다.

만약 여러 사람이 함께 공부한다면 각자 동일한 아이디어를 같은 언어로 혹은 다른 언어로 어떻게 다르게 표현했는지를 서로 비교해 보면 배우는 것이 무척 많습니다.

우리가 자료구조나 알고리즘을 공부하는 이유는, 특정 '실세계의 문제'를 어떠한 '수학적 아이디어'로 매핑시켜 해결할 수 있는지, 그것이 효율적인지, 또 이를 컴퓨터에 어떻게 효율적으로 구현할 수 있는지 따지고, 그것을 실제로 구현하기 위해서입니다. 따라서 이 과정에 있어 실세계의 문제를 수학 문제로, 그리고 수학적 개념을 프로그래밍 언어로 효율적으로 표현해내는 것은 아주 중요한 능력이 됩니다.

알고리즘 공부에서 중요한 것
개별 알고리즘의 목록을 이해, 암기하며 익히는 것도 중요하지만 더 중요한 것은 다음 네 가지입니다.

①알고리즘을 스스로 생각해낼 수 있는 능력
②다른 알고리즘과 효율을 비교할 수 있는 능력
③알고리즘을 컴퓨터와 다른 사람이 이해할 수 있는 언어로 표현해낼 수 있는 능력
④이것의 정상작동(correctness) 여부를 검증해 내는 능력

첫 번째가 제대로 훈련되지 못한 사람은 알고리즘 목록의 스테레오 타입에만 길들여져 있어서 모든 문제를 자신이 아는 알고리즘 목록에 끼워 맞추려고 합니다. 디자인패턴을 잘못 공부한 사람과 비슷합니다. 이런 사람들은 마치 과거에 수학 정석만 수십 번 공부해 문제를 하나 던져주기만 하면, 생각해보지도 않고 자신이 풀었던 문제들의 패턴 중 가장 비슷한 것 하나를 기계적·무의식적으로 풀어제끼는 문제풀이기계와 비슷합니다. 그들에게 도중에 물어보십시오. "너 지금 무슨 문제 풀고 있는 거니?" 열심히 연습장에 뭔가 풀어나가고는 있지만 그들은 자신이 뭘 풀고 있는지도 제대로 인식하지 못 하는 경우가 많습니다.

머리가 푸는 게 아니고 손이 푸는 것이죠. 이렇게 되면 도구에 종속되는 '망치의 오류'에 빠지기 쉽습니다. 새로운 알고리즘을 고안해야 하는 상황에서도 기존 알고리즘에 계속 매달릴 뿐입니다. 알고리즘을 새로 고안해 내건 혹은 기존의 것을 조합하건 스스로 생각해 내는 훈련이 필요합니다.

두 번째가 제대로 훈련되지 못한 사람은 일일이 구현해 보고 실험해 봐야만 알고리즘 간의 효율을 비교할 수 있습니다. 특히 자신이 가진 카탈로그를 벗어난 알고리즘을 만나면 이 문제가 생깁니다. 이건 상당한 대가를 치르게 합니다.

세 번째가 제대로 훈련되지 못한 사람은, 문제를 보면 "아, 이건 이렇게 저렇게 해결하면 됩니다"하는 말은 곧잘 할 수 있지만 막상 컴퓨터 앞에 앉혀 놓으면 아무 것도 하지 못합니다. 심지어 자신이 생각해낸 그 구체적 알고리즘을 남에게 설명해 줄 수는 있지만, 그걸 '컴퓨터에게' 설명하는 데는 실패합니다. 뭔가 생각해낼 수 있다는 것과 그걸 컴퓨터가 이해할 수 있게 설명할 수 있다는 것은 다른 차원의 능력을 필요로 합니다.

네 번째가 제대로 훈련되지 못한 사람은, 알고리즘을 특정 언어로 구현해도, 그것이 옳다는 확신을 할 수 없습니다. 임시변통(ad hoc)의 아슬아슬한 코드가 되거나 이것저것 덧붙인 누더기 코드가 되기 쉽습니다. 이걸 피하려면 두 가지 훈련이 필요합니다.

하나는 수학적·논리학적 증명의 훈련이고, 다른 하나는 테스트 훈련입니다. 전자가 이론적이라면 후자는 실용적인 면이 강합니다. 양자는 상보적인 관계입니다. 특수한 경우들을 개별적으로 테스트해서는 검증해야 할 것이 너무 많고, 또 모든 경우에 대해 확신할 수 없습니다. 테스트가 버그의 부재를 보장할 수는 없습니다. 하지만 수학적 증명을 통하면 그것이 가능합니다. 또, 어떤 경우에는 수학적 증명을 굳이 할 필요 없이 단순히 테스트 케이스 몇 개만으로도 충분히 안정성이 보장되는 경우가 있습니다. 이럴 때는 그냥 테스트만으로 만족할 수 있습니다.

실질적이고 구체적인 문제를 함께 다루라
자료구조와 알고리즘 공부를 할 때에는 가능하면 실질적이고 구체적인 실세계의 문제를 함께 다루는 것이 큰 도움이 됩니다. 모든 학습에 있어 이는 똑같이 적용됩니다. 인류의 지성사를 봐도, 구상(concrete) 다음에 추상(abstract)이 옵니다. 인간 개체 하나의 성장을 봐도 그러합니다. 'be-동사 더하기 to-부정사'가 예정으로 해석될 수 있다는 룰만 외우는 것보다 다양한 예문을 실제 문맥 속에서 여러 번 보는 것이 훨씬 나을 것은 자명합니다. 알고리즘과 자료구조를 공부할 때 여러 친구들과 함께 연습문제(특히 우리가 경험하는 실세계의 대상들과 관련이 있는 것)를 풀어보기도 하고, ACM의 ICPC(International Collegiate Programming Contest: 세계 대학생 프로그래밍 경진 대회) 등의 프로그래밍 경진 대회 문제 중 해당 알고리즘·자료구조가 사용될 수 있는 문제를 같이 풀어보는 것도 아주 좋습니다. 이게 가능하려면 "이 알고리즘이 쓰이는 문제는 이거다"하고 가이드를 해줄 사람이 있으면 좋겠죠. 이것은 그 구체적 알고리즘·자료구조를 훈련하는 것이고, 이와 동시에 어떤 알고리즘을 써야할지 선택, 조합하는 것과 새로운 알고리즘을 만들어내는 훈련도 무척 중요합니다.

알고리즘 디자인 과정의 중요성
알고리즘을 좀더 수월하게, 또 잘 만들려면 알고리즘 디자인 과정에 대해 생각해 봐야 합니다. 그냥 밑도 끝도 없이 문제를 쳐다본다고 해서 알고리즘이 튀어나오진 않습니다. 체계적이고 효율적인 접근법을 사용해야 합니다. 대표적인 것으로 다익스트라(E. W. Dijkstra)와 워스(N. Wirth)의 '조금씩 개선하기'(Stepwise Refinement)가 있습니다. 워스의 「Program Development by Stepwise Refinement」(1971, CACM 14.4, http://www.acm.org/classics/dec95)를 꼭 읽어보길 바랍니다. 여기 소개된 조금씩 개선하기는 구조적 프로그래밍에서 핵심적 역할을 했습니다(구조적 프로그래밍을 'goto 문 제거' 정도로 생각하면 안 됩니다). 다익스트라의 「Stepwise Program Construction」(Selected Writings on Computing: A Personal Perspective, Springer-Verlag, 1982, http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD227.PDF)도 추천합니다.

알고리즘 검증은 알고리즘 디자인과 함께 갑니다. 새로운 알고리즘을 고안할 때 검증해 가면서 디자인하기 때문입니다. 물론 가장 큰 역할은 고안이 끝났을 때의 검증입니다. 알고리즘 검증에는 루프 불변식(loop invariant) 같은 것이 아주 유용합니다. 아주 막강한 무기입니다. 익혀 두면 두고두고 가치를 발휘할 것입니다. 맨버(Udi Manber)의 알고리즘 서적(『Introduction to Algorithms: A Creative Approach』)이 알고리즘 검증과 디자인이 함께 진행해 가는 예로 자주 추천됩니다. 많은 계발을 얻을 것입니다. 고전으로는 다익스트라의 『A Discipline of Programming』과 그라이스(Gries)의 『The Science of Programming』이 있습니다. 특히 전자를 추천합니다. 프로그래밍에 대한 관을 뒤흔들어 놓을 것입니다.

알고리즘과 패러다임
알고리즘을 공부하면 큰 줄기들을 알아야 합니다. 개별 테크닉도 중요하지만 '패러다임'이라고 할만한 것들을 알아야 합니다. 이것에 대해서는 튜링상을 수상한 로버트 플로이드(Robert Floyd)의 튜링상 수상 강연(The Paradigms of Programming, 1978)을 추천합니다. 패러다임을 알아야 알고리즘을 상황에 맞게 마음대로 변통할 수 있습니다. 그리고 자신만의 분류법을 만들어야 합니다. 구체적인 문제들을 케이스 바이 케이스로 여럿 접하는 동안 그냥 지나쳐 버리면 개별자는 영원히 개별자로 남을 뿐입니다. 비슷한 문제들을 서로 묶어서 일반화해야 합니다.

이런 패러다임을 발견하려면 '다시 하기'가 아주 좋습니다. 다른 것들과 마찬가지로, 이 다시 하기는 알고리즘에서만이 아니고 모든 공부에 적용할 수 있습니다. 같은 것을 다시 해보는 것에서 우리는 얼마나 많은 것을 배울 수 있을까요. 대단히 많습니다. 왜 동일한 문제를 여러 번 풀고, 왜 같은 내용의 세미나에 또 다시 참석하고, 같은 프로그램을 거듭 작성할까요? 훨씬 더 많이 배울 수 있기 때문입니다. 화술 교육에서는 같은 주제에 대해 한 번 말해본 연사와 두 번 말해본 연사는 천지 차이가 있다고 말합니다. 같은 일에 대해 두 번의 기회가 주어지면 두 번째에는 첫 번째보다 잘 할 기회가 있습니다. 게다가 첫 번째 경험했던 것을 '터널을 벗어나서' 다소 객관적으로 볼 수 있게 됩니다. 왜 자신이 저번에 이걸 잘 못 했고, 저걸 잘 했는지 알게 되고, 어떻게 하면 그걸 더 잘할 수 있을는지 깨닫게 됩니다. 저는 똑같은 문제를 여러 번 풀더라도 매번 조금씩 다른 해답을 얻습니다. 그러면서 정말 엄청나게 많은 것을 배웁니다. '비슷한 문제'를 모두 풀 능력이 생깁니다.

제가 개인적으로 존경하는 전산학자 로버트 플로이드(Robert W. Floyd)는 1978년도 튜링상 강연에서 다음과 같은 말을 합니다.

제가 어려운 알고리즘을 디자인하는 경험을 생각해 볼 때, 제 능력을 넓히는 데 가장 도움이 되는 특정한 테크닉이 있습니다. 어려운 문제를 푼 후에, 저는 그것을 처음부터 완전히 새로 풉니다. 좀 전에 얻은 해법의 통찰(insight)만을 유지하면서 말이죠. 해법이 제가 희망하는 만큼 명료하고 직접적인 것이 될 때까지 반복합니다. 그런 다음, 비슷한 문제들을 공략할 어떤 일반적인 룰을 찾습니다. 아까 주어진 문제를 아예 처음부터 최고로 효율적인 방향에서 접근하도록 이끌어줬을 그런 룰을 찾는 거죠. 많은 경우에 그런 룰은 불변의 가치가 있습니다. … 포트란의 룰은 몇 시간 내에 배울 수 있습니다. 하지만 관련 패러다임은 훨씬 더 많은 시간이 걸립니다. 배우거나(learn) 배운 것을 잊거나(unlearn) 하는 데 모두.

수학자와 프로그래머를 포함한 모든 문제 해결자들의 고전이 된 죠지 폴리야(George Polya)의 『How to Solve it』에는 이런 말이 있습니다:

심지어는 꽤나 훌륭한 학생들도, 문제의 해법을 얻고 논증을 깨끗하게 적은 다음에는 책을 덮어버리고 뭔가 다른 것을 찾는다. 그렇게 하는 동안 그들은 그 노력의 중요하고도 교육적인 측면을 잃어버리게 된다. … 훌륭한 선생은 어떠한 문제이건 간에 완전히 바닥이 드러나는 경우는 없다는 관점을 스스로 이해하고 또 학생들에게 명심시켜야 한다.

저는 ACM의 ICPC 문제 중에 어떤 문제를 이제까지 열 번도 넘게 풀었습니다. 대부분 짝 프로그래밍이나 세미나를 통해 프로그래밍 시연을 했던 것인데, 제 세미나에 여러 번 참석한 분이 농담조로 웃으며 물었습니다. "신기해요. 창준 씨는 그 문제를 풀 때마다 다른 프로그램을 짜는 것 같아요. 설마 준비를 안 해 와서 그냥 내키는 대로 하는 건 아니죠?" 저는 카오스 시스템과 비슷하게 초기치 민감도가 프로그래밍에도 작용하는 것 같다고 대답했습니다. 저 스스로 다른 해법을 시도하고 싶은 마음이 있으면 출발이 조금 다르고, 또 거기서 나오는 진행 방향도 다르게 됩니다. 그런데 중요한 것은 이렇게 같은 문제를 매번 다르게 풀면서 배우는 것이 엄청나게 많다는 점입니다. 저는 매번, 전보다 개선할 것을 찾아내게 되고, 또 새로운 것을 배웁니다. 마치 마르지 않는 샘물처럼 계속 생각할 거리를 준다는 점이 참 놀랍습니다.

알고리즘 개론 교재로는 CLR(Introduction to Algorithms, Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest)을 추천합니다. 이와 함께 혹은 이 책을 읽기 전에 존 벤틀리(Jon Bentley)의 『Programming Pearls』도 강력 추천합니다. 세계적인 짱짱한 프로그래머와 전산학자들이 함께 꼽은 위대한 책 목록에서 몇 손가락 안에 드는 책입니다. 아직 이 책을 본 적이 없는 사람은 축하합니다. 아마 몇 주간은 감동 속에 하루하루를 보내게 될 겁니다.

초보 개발자를 위한 스택트레이스 읽는 법

ryushoshin — Fri, 10 Nov 2023 17:11:20 +0900

면접을 볼 때, 질문할 내용을 미리 정해놓지는 않지만 개인적으로 즐겨내는 문제가 있습니다. 널포인터 예외(NullPointerException)의 원인을 찾는 문제인데, 전에 다니던 회사에서는 실제 제품개발 중에 발생한 오류 보고서가 있어서 면접보시는 분들께

면접을 볼 때, 질문할 내용을 미리 정해놓지는 않지만 개인적으로 즐겨내는 문제가 있습니다. 널포인터 예외(NullPointerException)의 원인을 찾는 문제인데, 전에 다니던 회사에서는 실제 제품개발 중에 발생한 오류 보고서가 있어서 면접보시는 분들께 해당되는 소스 파일과 함께 제시하고 원인을 찾아보도록 한 적이 있습니다.

처음보는 다른 사람이 짠 소스를 어떻게 분석할 수 있을까 의아할 수 있지만, 실제로 널포인터 예외는 개발중에 매우 흔히 경험하는 오류이고 특성상 정확한 의미만 알고 있다면 거의 대부분 즉시 정확한 원인을 분석할 수 있습니다. 또한 그러기 위해서는 스택트레이스를 읽을 수 있는 능력이 필요합니다.

개인적으로 예외 처리는 초보 개발자가 가장 중요성을 간과하기 쉬운 분야라고 생각합니다. 예외처리라고 하면 단순하게 '그냥 try-catch하면 되는 게 아닌가?'라고 쉽게 생각할 수도 있지만 사실 이야기를 하자면 상당한 설계 차원의 지식이 필요한 문제가 예외처리입니다.

초보 개발자 분들이라면 그렇게 깊게까지 파고들 필요는 없겠지만 최소한 스택트레이스는 정확히 읽을 줄 알아야만 빠른 디버깅이 가능한 만큼 이 부분에 대해서만은 시간을 투자해서 정확한 지식을 쌓아둘 필요가 있다고 생각합니다.

이번 면접에서 제가 제시한 스택 트레이스는 이렇습니다 :

java.lang.reflect.InvocationTargetException
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.mylibrary.ap.xul.builder.handler.MethodCallback.invokeCallback(MethodCallback.java:32)
     at com.mylibrary.ap.xul.builder.handler.ViewHandler.invokeActionResult(ViewHandler.java:581)
     at com.mylibrary.ap.xul.context.impl.ViewContextImpl$2.onActionResult(ViewContextImpl.java:283)
     at com.mylibrary.ap.xul.context.impl.ActionContextImpl.setResult(ActionContextImpl.java:90)
     at com.mylibrary.ap.xul.action.stock.DialogAction.handleDialogClose(DialogAction.java:156)
     at com.mylibrary.ap.xul.action.stock.DialogAction$1.windowClosed(DialogAction.java:142)
     at com.mylibrary.api.Window.fireWindowClosedEvent(Unknown Source)
     at com.mylibrary.api.Window.onClose(Unknown Source)
     at com.mylibrary.api.platform.WindowBase.BaseClose(Native Method)
     at com.mylibrary.api.platform.WindowBase.BaseClose(Unknown Source)
     at com.mylibrary.api.Window.close(Unknown Source)
     at com.mylibrary.ap.xul.ui.MessageDialog.handleButtonClick(MessageDialog.java:145)
     at com.mylibrary.ap.xul.ui.MessageDialog$1.handleClick(MessageDialog.java:134)
     at com.mylibrary.api.ClickableSupport.fireClickEvent(Unknown Source)
     at com.mylibrary.api.ClickableSupport.handleAction(Unknown Source)
     at com.mylibrary.api.Button.actionHook(Unknown Source)
     at com.mylibrary.api.Component.action(Unknown Source)
Caused by: java.lang.NullPointerException
     at com.mycompany.service.impl.PortalManagerImpl.deleteMenuItem(PortalManagerImpl.java:603)
     at com.mycompany.service.impl.PortalManagerImpl.deletePortal(PortalManagerImpl.java:358)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
     at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
     at org.springframework.security.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
     at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
     at $Proxy54.deletePortal(Unknown Source)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.mycompany.util.SpringSecurityContextInvocationHandler.invoke(SpringSecurityContextInvocationHandler.java:62)
     at $Proxy84.deletePortal(Unknown Source)
     at com.mycompany.ui.binding.PortalDataProvider.doDelete(PortalDataProvider.java:81)
     at com.mycompany.ui.binding.PortalDataProvider.doDelete(PortalDataProvider.java:12)
     at com.mycompany.ui.binding.AbstractEISDataProvider.delete(AbstractEISDataProvider.java:105)
     at com.mylibrary.ap.xul.binding.dataset.impl.DatasetImpl.doCommit(DatasetImpl.java:90)
     at com.mylibrary.ap.xul.binding.dataset.impl.AbstractDataset.commit(AbstractDataset.java:251)
     at com.mylibrary.ap.xul.binding.dataset.impl.AbstractDataset.deleteRow(AbstractDataset.java:201)
     at com.mylibrary.ap.xul.action.dataset.DeleteDataRowAction.execute(DeleteDataRowAction.java:22)
     at com.mylibrary.ap.xul.context.impl.ViewContextImpl.execute(ViewContextImpl.java:294)
     at com.mycompany.ui.portal.PortalInfoHandler.onPostConfirmDeleteAction(PortalInfoHandler.java:192)
     ... 21 more

상당히 길죠? 제가 본 많은 수의 초보 개발자분들은 이런 로그를 접하면 지례 겁을 먹고 정확하게 트레이스를 읽으려 들지 않습니다.

사실 예외를 읽는 법은 기초 중에서도 가장 중요한 내용이고, 처음 자바 언어를 배우는 모든 개발자가 반드시 숙지해야할 내용인데도 오히려 제대로 아는 초급 개발자를 만나기 힘든 것을 보면 도대체 자바 학원이라는 곳에선 무엇을 가르치는 건가 의아한 생각이 듭니다.

오류가 발생하면 무조건 오류 메시지부터 완벽하게 이해해야합니다. 왜 책에서 본대로 쳤는데 안되나, 왜 어제까지 됐는데 갑자기 안될까, 아니면 인터넷에서 한 번 찾아볼까 등의 생각은 일단 오류부터 제대로 읽어보고 해도 늦지 않습니다.

예외처리를 제대로 작성한 코드라면 거의 대부분의 문제는 스택트레이스 안에 답이 있기 때문입니다.

우선 위의 예의 경우 트레이스가 두 가지 예외 내용을 포함하고 있다는 것을 바로 파악할 수 있어야 하며, 문제의 진정한 원인은 윗쪽의 트레이스가 아니라 'Caused By:'로 표시되는 널포인터 예외 부분임을 인지할 수 있어야 합니다.

일단 문제에 대한 원인이 되는 트레이스를 찾았다면 그 다음은 트레이스를 읽어야 하는데, 이제까지 꽤 많은 수의 초급 개발자들의 면접을 경험했지만 의외로 트레이스 읽는 법을 정확하게 아는 경우가 드물었습니다.

면접시 위의 트레이스를 보여주고 어쩔 줄 몰라할 경우 보통 힌트를 주고 예를들어 널포인터 예외가 찍힌 부분부터 아래쪽으로 단 세줄만 집중해서 무슨 뜻인지 해석해보라고 질문합니다. 즉,

Caused by: java.lang.NullPointerException
     at com.mycompany.service.impl.PortalManagerImpl.deleteMenuItem(PortalManagerImpl.java:603)
     at com.mycompany.service.impl.PortalManagerImpl.deletePortal(PortalManagerImpl.java:358)

이 부분을 보여주고 읽는 방법을 알고 있는지 묻는 질문인데, 이를 정확하게 'com.mycompany.service.impl.PortalManagerImpl' 클래스의 'deletePortal' 메소드 358라인에서 같은 클래스의 'deleteMenuItem'메소드를 호출했는데 해당 메소드 603번 째 줄에서 널포인터 예외가 발생했다'라고 해석할 수 있는 지원자가 많지 않았습니다.

아예 대답을 못하거나 트레이스를 위에서 아래로 해석하려 하거나 심지어 이를 '두 번의 널포인터 예외가 발생했다'로 해석하는 경우까지 있더군요. 이런 로그를 보고 곧바로 해당 클래스의 603번 째 줄을 찾아갈 수 있는 개발자와 '내가 뭘 잘못 쳐서 안되는 거지?' 하는 식으로 막연한 고민으로 시간을 허비하는 개발자를 상상해보시면 스택트레이스를 정확히 아는 것이 얼마나 디버깅과 관련한 개발생산성에 큰 도움을 주는 지 짐작 가능하시리라 생각합니다.

그리고 'PortalManagerImpl' 클래스의 관련된 소스는 다음과 같았습니다:

if (item == null) {
    throw new NullArgumentException("item");
}

//중간 생략
List<PortalMenu> children = getMenuItems(item.getPortal().getId(), item.getId()); // 603번째 줄

for (PortalMenu child : children) {
    deleteMenuItem(child);
 }

신기하게도 아직까지 면접을 본 개발자 중에 이런 문제를 보고 곧바로 널포인터 예외의 원인을 짚어내는 지원자는 거의 없었습니다. 글을 읽으시는 분들은 모두 금방 답이 보이시나요?

많은 수의 지원자들이 'children'이나 'item.getId()' 등에 널값이 들어간 것 같다고 답했습니다. 이론적으로 해당 라인에서 널값이 들어갈 수 있는 모든 경우의 수는,

children
item
item.getPortal()
item.getPortal().getId()
item.getId()

이렇게 다섯 가지가 전부입니다.

이 중 적어도 두 가지, 즉 2번 혹은 3번으로 가능성을 바로 좁히지 못한다면 그것은 널포인터 예외의 의미를 정확하게 파악하지 못하고 있기 때문입니다.

널포인터 예외는 단순하게 변수에 널값이 들어가서 생기는 오류가 아닙니다. 널포인터 예외는 명확하게 객체의 널레퍼런스에 대해 메소드 호출이나 필드 참조 등의 작업을 했을 때 발생하는 문제라는 것을 이해한다면 이런 문제는 곧바로 원인을 좁힐 수 있어야 합니다.

즉, 1번의 경우처럼 단순히 변수에 널값을 할당하는 것만으로는 절대로 널포인터 예외가 날 수 없습니다. 그리고 만일 4 번 'item.getPortal().getId()'이나 5번 'item.getId()'이 널이라면 이는 널 레퍼런스에 대한 호출이 아니라 널값을 'getMenuItems'라는 메소드의 인자로 넘기는 것 뿐이기 때문에 역시 널포인터 예외의 원인이 될 수 없습니다.

물론 'getMenuItem' 메소드 안에서 해당 인자에 대한 널체크 없이 값을 사용하다가 예외가 날 수도 있겠지만 이 경우엔 절대로 트레이스 상에 굵은 글자로 표시된 603번 째에서 예외를 뿌리지 않습니다.

그렇다면 남은 가능성은 2번 'item'이 널이거나 3번 'item.getPortal()'이 널인 경우뿐인데, 'item' 변수는 위에서 널체크를 하기 때문에 603번 째 줄에서 절대로 널값을 가질 수 없습니다. 그렇기 때문에 답은 3번이 되는 것입니다.

너무 문제가 어렵나요? 길게 설명했지만 개발을 하면 매우 흔하게 접할 수 있는 예외이며 따져보면 결코 어려운 내용이 아닙니다. 위와 같은 문제는 이미 스택트레이스를 능숙하게 읽을 수 있고 널포인터 예외를 이해하고 있는 개발자라면 몇 초 안에 곧바로 원인을 파악할 수 있는 문제입니다.

예외만 읽을 줄 알면 단 몇 초만에 깨달을 수 있는 문제를 다른 개발자는 인터넷 검색과 의미없는 무작위 수정, 게시판 질문글 작성등으로 몇 시간씩 허비한다면 두 개발자 사이의 생산성의 차이는 엄청나게 벌어질 것입니다.

디버깅 같은 기본적 부분에서 나쁜 습관을 빨리 고치지 못한다면 시간 낭비도 문제지만 그 만큼 개발자로서 발전도 늦게되고, 나중에는 인터넷이 없으면 아무 것도 못하는 그냥 복사 붙여넣기만 단순 코더가 한계점이 될 수도 있습니다.

그런 점을 감안해서 이 글을 보는 초보 개발자들은 반드시 제대로된 문제 해결 방법을 공부하셨으면 좋겠습니다.

해당되는 소스 파일과 함께 제시하고 원인을 찾아보도록 한 적이 있습니다.

이번 면접에서 제가 제시한 스택 트레이스는 이렇습니다 :

java.lang.reflect.InvocationTargetException
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.mylibrary.ap.xul.builder.handler.MethodCallback.invokeCallback(MethodCallback.java:32)
     at com.mylibrary.ap.xul.builder.handler.ViewHandler.invokeActionResult(ViewHandler.java:581)
     at com.mylibrary.ap.xul.context.impl.ViewContextImpl$2.onActionResult(ViewContextImpl.java:283)
     at com.mylibrary.ap.xul.context.impl.ActionContextImpl.setResult(ActionContextImpl.java:90)
     at com.mylibrary.ap.xul.action.stock.DialogAction.handleDialogClose(DialogAction.java:156)
     at com.mylibrary.ap.xul.action.stock.DialogAction$1.windowClosed(DialogAction.java:142)
     at com.mylibrary.api.Window.fireWindowClosedEvent(Unknown Source)
     at com.mylibrary.api.Window.onClose(Unknown Source)
     at com.mylibrary.api.platform.WindowBase.BaseClose(Native Method)
     at com.mylibrary.api.platform.WindowBase.BaseClose(Unknown Source)
     at com.mylibrary.api.Window.close(Unknown Source)
     at com.mylibrary.ap.xul.ui.MessageDialog.handleButtonClick(MessageDialog.java:145)
     at com.mylibrary.ap.xul.ui.MessageDialog$1.handleClick(MessageDialog.java:134)
     at com.mylibrary.api.ClickableSupport.fireClickEvent(Unknown Source)
     at com.mylibrary.api.ClickableSupport.handleAction(Unknown Source)
     at com.mylibrary.api.Button.actionHook(Unknown Source)
     at com.mylibrary.api.Component.action(Unknown Source)
Caused by: java.lang.NullPointerException
     at com.mycompany.service.impl.PortalManagerImpl.deleteMenuItem(PortalManagerImpl.java:603)
     at com.mycompany.service.impl.PortalManagerImpl.deletePortal(PortalManagerImpl.java:358)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
     at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
     at org.springframework.security.intercept.method.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:66)
     at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
     at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
     at $Proxy54.deletePortal(Unknown Source)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
     at java.lang.reflect.Method.invoke(Unknown Source)
     at com.mycompany.util.SpringSecurityContextInvocationHandler.invoke(SpringSecurityContextInvocationHandler.java:62)
     at $Proxy84.deletePortal(Unknown Source)
     at com.mycompany.ui.binding.PortalDataProvider.doDelete(PortalDataProvider.java:81)
     at com.mycompany.ui.binding.PortalDataProvider.doDelete(PortalDataProvider.java:12)
     at com.mycompany.ui.binding.AbstractEISDataProvider.delete(AbstractEISDataProvider.java:105)
     at com.mylibrary.ap.xul.binding.dataset.impl.DatasetImpl.doCommit(DatasetImpl.java:90)
     at com.mylibrary.ap.xul.binding.dataset.impl.AbstractDataset.commit(AbstractDataset.java:251)
     at com.mylibrary.ap.xul.binding.dataset.impl.AbstractDataset.deleteRow(AbstractDataset.java:201)
     at com.mylibrary.ap.xul.action.dataset.DeleteDataRowAction.execute(DeleteDataRowAction.java:22)
     at com.mylibrary.ap.xul.context.impl.ViewContextImpl.execute(ViewContextImpl.java:294)
     at com.mycompany.ui.portal.PortalInfoHandler.onPostConfirmDeleteAction(PortalInfoHandler.java:192)
     ... 21 more

상당히 길죠? 제가 본 많은 수의 초보 개발자분들은 이런 로그를 접하면 지례 겁을 먹고 정확하게 트레이스를 읽으려 들지 않습니다.

예외처리를 제대로 작성한 코드라면 거의 대부분의 문제는 스택트레이스 안에 답이 있기 때문입니다.

Caused by: java.lang.NullPointerException
     at com.mycompany.service.impl.PortalManagerImpl.deleteMenuItem(PortalManagerImpl.java:603)
     at com.mycompany.service.impl.PortalManagerImpl.deletePortal(PortalManagerImpl.java:358)

그리고 'PortalManagerImpl' 클래스의 관련된 소스는 다음과 같았습니다:

if (item == null) {
    throw new NullArgumentException("item");
}

//중간 생략
List<PortalMenu> children = getMenuItems(item.getPortal().getId(), item.getId()); // 603번째 줄

for (PortalMenu child : children) {
    deleteMenuItem(child);
 }

children
item
item.getPortal()
item.getPortal().getId()
item.getId()

이렇게 다섯 가지가 전부입니다.

그런 점을 감안해서 이 글을 보는 초보 개발자들은 반드시 제대로된 문제 해결 방법을 공부하셨으면 좋겠습니다.

코딩 잘하는법

ryushoshin — Thu, 9 Nov 2023 18:23:46 +0900

"여러 언어/분야들을 많이 파보는게 좋을까요, 하나를 깊히 파보는게 좋을까요?" 와 같은 질문을 많이 받습니다.

사실 두 경우 다 잘하는 사람을 봤고, 사람들은 다양한 종류로 잘하기 때문에 여기에 답은 없습니다. 다만 하나 확실한 것은, 겁나 많이 해야 한다는 것입니다. 제 사례를 공유합니다.

===

참고로 제 시대에는 게임 프로그래머가 제일 잘나갔습니다. 주로 쓰는 언어는 C++이었습니다.

저는 무식하게 C언어 책을 7번 봤습니다. 중학교 3학년 때 였는데, 그냥 거기 있는 코드를 7번 정도 다 따라쳤습니다. 이러고 나니 프로그래밍 언어 책을 보는게 무섭지 않고, IDE를 얼추 잘 쓰게 되었습니다.

고등학교에 입학했습니다. 게임을 만들려면 C++을 해야 한답니다. 그래서 C++ 책을 보고 역시 또 겁나 따라 쳤습니다. (정리해 놓은 것을 보니 C++ 책만 30권은 봤더군요) 하지만 이렇게만 하면 재미도 없고, C++도 너무 방대하다 보니, 게임을 만들기 위해 DirectX (그래픽 카드 드라이버 API) 를 공부했습니다.

솔직히, 그 시점에는 이론에 대해 전혀 이해 못했습니다. 그냥 DirectX에 있는 코드를 그대로 따라 치는걸 많이 했고, 손에 익었습니다. 그냥 IDE에서 빈 프로젝트 만들고, main.cpp 라는 빈 파일을 만든 후에 어떤 자료에도 의지하지 않고 int main() 부터 시작해서 윈도우 창을 띄우고, DirectX context를 만든 뒤, RGB 그라데이션이 되는 삼각형을 띄울 수 있었습니다.

느끼시겠지만, 비효율의 극치입니다. 구글링도 안하고, 이해도 안하고, 그냥 예제랑 책만 따라쳐서 외워버린거니까요. 하지만 전 이 과정에서 배운게 너무나 많습니다.

1) 코딩이라는 행위에 너무나 익숙해 졌습니다. 대부분 공부를 할 때 완벽히 이해하는 것을 처음에 목표로 하는데, 프로그래밍은 그냥 생활이 되고 익숙해 져야 잘합니다. 다른 방법이 없습니다.

2) 템플릿에 의존하지 않다보니, 코드 한줄 한줄에 의문을 품으며 코딩을 했습니다. 한줄이 빠지면 화면이 검은색으로 나오거나 segmentation fault 를 일으키며 프로그램이 터지는데, 다시 책을 읽고, 코드 한줄의 의미를 최대한 이해해 보려 노력했습니다. 이때 제대로 공부하는 방법을 배울 수 있었던 것 같습니다.

이때 궁금한게 많이 생겼습니다. 왜 Texture (쉽게 말하면 이미지 파일) 를 GPU에 보내려면 Lock을 걸어야 하는지, 왜 DirectX context는 delete 문법이 아니라 해당 객체의 Release() method를 통해 메모리를 해제 해야 하는지 등등…

이 중에는 그 시점에 해결 된 것도 있고, 나중에서야 당연하게 받아들이게 된 것도 있었습니다. 포인트는, 외울 정도로 코딩을 많이 하고 책을 많이 봤다는 겁니다.

3. 이제 게임을 만들어야 합니다. 그냥 DirectX로 게임을 만들었습니다. (사실 저만 그런게 아니라 선배들이 다 그렇게 했습니다)

정말 참고할게 없어서, 어렵게 구한 오픈소스 게임 엔진을 컴파일 하고, 거기에 있는 코드들을 분석했습니다.

처음 보는 게임 엔진의 소스코드는, 내가 알던 C++이 아니었습니다. 너무 복잡하고, 상속 관계를 왜 이렇게 했는지도 모르겠고, 어떻게 Interface와 구현체를 분리하는지도 모르겠고…

그래서 그때도 무식하고 소스코드를 분석하고, 다른 한편에서는 제 게임 엔진을 DirectX를 갖고 해당 게임 엔진을 모방해서 만들어 보았습니다.

아주 간단한 기능도 만들기 힘들었지만, 얼추 기대한 틀이 나오자 OOP에 대해서 아주 잘 이해하게 됐습니다. 어떤 때 추상화를 해야하고, 다형성이 왜 좋고, loose coupling 을 하면 새로 코드 추가할 때 고려해야 하는 사항이 적어지는지… 이론으로 배우면 그냥 좋은 말 좋은 말이었지만, 실제로 겪으면 크게 와닿았습니다.

4. 게임엔진을 만들고, 친구들과 협업해서 게임을 만들었습니다.

재밌기도 하고, 정말 많이 성장했습니다. 엔진에서 의도한 것이 오버엔지니어링이라 오히려 코드가 복잡해지고, 알 수 없는 버그들이 많이 터졌습니다. 버그를 잡으면서 제 엔진을 고치고, 가끔은 귀찮으니까 대충 땜질만 하고…

결국 완성을 해서 공모전에 냈습니다. 이렇게 해본 경험이 저에게는 큰 자산이 되었습니다.

5. 대학에 입학했습니다.

저는 대학에서 배울게 없을 줄 알았습니다. 웬걸, 대학 들어오기 전에 프로그래밍을 4년을 열심히 했는데, 대학에서 제가 잘하는 과목은 총 140학점 중에 6-9학점 정도였습니다. 모르는게 너무 많더군요.

특히 프로그래밍을 배운 상태에서 듣는 C언어 수업은 쇼킹 했습니다. (그 전까지 배워 본 적이 없으니…) int 형을 표현하기 위해 내부에서는 MSB를 sign bit로, 그 외를 이진수로 담는구나, float 형은 sign, exponent, mantissa로 분리되어서 표현되는구나, 그래서 int가 float보다 처리하기 더 쉽겠다, 등등…

그때 제가 느낀건, 프로그래밍을 겁나 해보지 않은 사람이 대학 수업을 들으면 이해가 하나도 안갈 것 같다는 생각이었습니다. 실제로 많은 친구들이 프로그래밍을 포기하거나 전과를 했고 (그땐 컴공이 비인기 학과였습니다) 남은 친구들도 학점을 잘 받는 것에 바쁘지 프로그래밍 그 자첸는 많이 안했던 것 같습니다.

저는 학점은 좋지 않았지만, 대학 수업을 너무 재밌게 들었습니다. 운영체제와 컴퓨터구조를 들으면서 엔진을 만들면서 궁금했던 것들이 많이 풀렸고, 컴퓨터 그래픽스를 들으면서 이해를 못하고 쓰던 DirectX를 이해하게 됐습니다. 수학 과목들을 들으면서 저거 게임 만들 때는 이렇게 쓰던건데, 하던 생각이 들기도 하구요.

6. 하고 싶은 말

제 얘길 하다보니 두서가 없었지만, 결론은 명확합니다. “겁나 코딩을 많이 하셔야” 기술력을 쌓을 수 있습니다. 저는 머리가 좋은 편도 아니고, 이해가 빠른 것도 아니지만, 진짜 많이 했기 때문에 CS 과목들을 들으면서 이해가 쉽고 공감이 갔던 부분이 많았습니다.

그리고 꼭 저수준의 프로그래밍을 해보셔야 합니다. 예를 들어, Java & Spring을 하고 계시다면 Java만 가지고 HTTP 서버를 짜보고, DB 대신에 간단한 key-value store를 짜본 후 게시판 CRUD를 하기 위한 서버를 만들어 보세요. 웹 프론트엔드를 지향하신다면 React.js 를 쓰지 말고 바닐라 js 를 갖고 React.js 처럼 동작할 수 있게 짜보세요.

모든 공학이 그렇지만 이론은 쉽고 실제는 겁나 어렵습니다. 특히 CS는 추상화의 학문이기 때문에, 윗단에서만 코딩을 하다보면 무조건 한계가 올 뿐더러 공부해야 하는 양이 너무 많습니다. 아랫단을 잘 이해하고 있으면 윗단에 추가되는 것이 왜 추가 되는 것인지를 더 잘 이해하게 되실 것이라 확신합니다.

잔소리가 길었네요. 도움이 되길 바랍니다.

디저트 가격 요즘 진짜 미쳐돌아간다

ryushoshin — Tue, 31 Oct 2023 21:43:18 +0900

요즘 미쳐돌아가버리는 디저트 가격.. 가끔 애인이랑 데이트하면 꼭! 디저트가게나 카페를 들러서 디저트를 먹는 편인데요.. 요즘 물가상승 맞물려서 가격 진짜 미쳐버린 것 같습니다.. 무슨 브릭샌드? 이런거 먹는데 몇만원 나오고.. (아니 이럴거면 참치마요 몇개냐구 아크크)

요즘 팥빙수 하나 먹으려해도 만원이상 들던데... 진짜 가격이 무쳐부렸습니다~~~~~~~~

외식물가 잡기전에 이런 말도 안되는 디저트 가격부터 잡아야 할듯요 ~~~~~~~

이태원 참사 1주년 뭐가 바꼈는지 이태원 방문 해봤다.

ryushoshin — Mon, 30 Oct 2023 17:16:26 +0900

이태원 참사 1주년이 흘렀다. 1년전 10월 29일 이태원 해밀톤호텔 앞 좁은 경사로에 단시간 인파가 훅 몰리면서 159명이 압사 사망한 사건이다. 우리에게 굉장히 큰 충격을 준 사건인데 당시 나는 피시방에서 오버워치를 하던 중 소식을 접하고 집근처 이태원으로 달려갔었다.

** 자극적인 장면이 포함되어 있으니 19세 미만은 뒤로가기 부탁드립니다. **

당시 상황은 상당히 참혹했는데 항상 다니던 내가 알던 평화로운 이태원이 아닌 이미 길거리에 누워있는 시신이나 크게 음악을 틀고 춤을 추고 있던 사람들, 그리고 대규모의 소방관과 경찰관이 한 장소에 모여 가히 지옥도를 연상케 했다.

이태원과 해방촌, 경리단길, 한남동은 내가 정말 자주가고 좋아했던 장소였다. 이태원에서 일을 해본적도 있고 경리단길에서 친구들과 재즈바에서 재즈라이브연주를 들으며 재밌었던 기억등 정말 많은 추억이 있는데 작년 10월29일 기점으로 한번도 방문하지 못했던 거리였다. 그 거리를 거닐면 괜시리 죄책감이나 이상한 감정이 들것만 같았다.

의외로 낮에 방문해본 이태원의 거리는 생각보다 한산했다. 1년전 낮부터 수천명의 사람이 몰렸던 것과 비교하면 정말 사람이 적었고 무엇보다 해밀톤호텔 근처로는 사람들이 지나가기 위해 왔다기 보다는 참사현장을 둘러보러 온 사람들이 많았다.

참사현장에는 유족들과 친구들 이외에 사람들이 손글씨로 남긴 포스트잇들이 정말 많았다. 많은 글귀들이 너희들의 잘못이 아니라는 글이었다.

유독 이태원참사 사망자들은 조롱을 많이 당하는 것 같다. 그들이 욕하는 이유를 들여다보면

1.우리나라 축제가 아닌 서양의 축제를 즐기다가 사망했다. (축제일 뿐인데 무슨 상관인가)

2. 놀러갔다가 사망한 것이다. (인싸에 대한 열등감일 수도 있다.)

3. 자기들 끼리 질서 안지켜서 사고난 것이다. (유독 한국에서 무슨 일 나면 질서 등등이 나온다)

사유가 어찌되었건 대한민국의 청년들이 150명 이상 죽었다는 것이다. 그 사실이 중요하지 대체 뭐가 중요하단 말인가. 안그래도 저출산의 영향으로 우리나라 청년인구와 신생아 인구는 정말 정말 한명 한명 중요한 시기이다.

출처 : 뉴시스

특히 유족들의 슬픔이 어느때부터 컸는데 그도 그럴것이 다 키워놓은 자식 허무하게 보낸 부모의 심장이 어땠을까..

말못할 슬픔이고 이 슬픔의 화살은 어떻게든 꽂힐 대상이 필요했으므로 정부에게 화살이 가는 것은 어찌보면 당연했을 것이다. 그리고 그를 부추기는 국회와 언론까지...

그 화살은 현재 진행형으로 유족들은 아직까지도 정부에 진상조사 요구를 하는 중이다. 이 일이 과연 정부의 책임이 있나 없나는 아직까지도 말이 많은 편이다.

한편 이태원 참사 이후 일본 천리교까지 등장하였는데 자세한 의미는 모르겠지만 부정적인 반응이 잇따랐다. 그러나 나는 개인적으로 종교에서 원혼에 대하여 성불을 하고 추모를 하는 행위는 어찌보면 너무 당연한 의식일 뿐인데 민감하게 반응 하는건 아닌지..

이태원 참사 1주기 벌써 1년이란 시간이 흘렀네요. 고인의 명복을 다시 한 번 빕니다. 비방은 자제 해주시길 바랍니다.

지드래곤 마약 혐의입건 같이 입건된 연예인은 누구?

ryushoshin — Wed, 25 Oct 2023 20:08:04 +0900

이선균 마약사건으로 한국이 떠들썩한데 이번에 같이 입건된 연예인이 밝혀졌습니다. 충격적이게도 지드래곤 이였습니다. 지드래곤은 전에도 2011년경 대마초 흡입혐의로 기사에 난적이 있었는데 그때는 흡입량이 적다는 이유로 기소유예 처리 되었습니다. 그런데 이번에는 못빠져나갈 것 같군요.

지드래곤 마약혐의로 이번에 입건 되며 연예계에 다시 돌아오기 힘들 것 같습니다. 이로써 진짜 빅뱅은 기억속으로 빠이빠이 인 것 같습니다. 태양만 흥하자 !!

전 빅뱅 지드래곤이 이번에 마약류 관리 법률 위반 혐의로 지드래곤을 불구속 입건했습니다. 근데 왜 불구속 입니까? 보통 마약사범들은 구속으로 다스리는데 이것도 좀 웃기긴 하는군요. 그러나 이게 끝이 아닙니다. 이선균, 지드래곤 뿐만 아니라 경찰쪽에서 파악한 바로는 8명 정도를 수사선상에 놓고 있습니다. 한명 한명 차례차례 부르고 있고 입건 될 때마다 기사가 나오고 있으니 이선균, 지드래곤 그 다음은 누구일까요?

이선균, 지드래곤등 굵직굵직한 연예인 두명이 첫빠따로 소환된 걸 보니 그 다음 입건되는 연예인도 분명 거물급이라는 의견이 많습니다. 그러나 섣부른 추측은 금물이기 때문에 자중하겠습니다.

지드래곤 정말 정말 좋아했고 아직도 노래방 가면 무제노래 부르는 남자분들이 많습니다. 또 여자분들은 어떤가요 같이 일하는 지인도 이번 소식을 접하고 본인이 어렸을때부터 VIP 였다고 정말 정말 아쉬워 했었는데요

심지어 제 아내도 지드래곤의 팬이었던지라 이 소식을 접하면 정말 실망 많을 것 같습니다. 아무튼 봄 여름 가을 겨울 중 겨울을 나지 못하고 가을에 마약으로 걸려버린 지드래곤씨 성실히 조사받길 바랍니다.

의정부코딩학원 인생 꼬이는 비전공자 공부방법

ryushoshin — Wed, 25 Oct 2023 19:16:05 +0900

많은 사람들이 코딩학원 선택을 한다. 그러나 잘못된 선택으로 인생을 꼬이게 만드는 코딩 공부방법, 진로설계, 코딩학원을 고른다. 이 글을 읽으시는 분들은 그 잘못된 선택을 올바른 선택으로 바꿀 수 있을지도 모르는 마음에 쓴다.

비전공자가 코딩학원 잘못 상담받고 인생이 꼬이는 과정

실제 내 친구 사례다. 희준이라는 친구가 있는데 평생 요리만 팠었다. 이 친구에게 요리란 그저 인생 그자체 요리사로써도 인정 받고 후에는 많은 연봉을 받고 미슐랭 식당 묘* 에서도 셰프직전 까지 갔었던 엄청난 이력이 있었다.

이 친구는 그중 인생에 큰 전환점을 맞이하여 요리사로써의 일은 잠시 접어두고 새로운 도전을 준비하게 되었다. 몇가지 새로운 도전중 가장 눈에 띈 것은 바로 코딩이였다. 뭔가 멋있어 보였고 좋은 이미지로 가득찬 이 직업 그리고 무엇보다 4차 산업혁명으로 전 세계에서 가장 큰 산업 종사자가 될 수도 있다는 생각에 도전 하게 되었다. 그러나 뭣부터 해야할 지 몰랐다. 그래서 무작정 인터넷 검색등을 거쳤는데 중요한 건 대부분의 정보가 불친절하거나 믿음직 스럽지 못했다는 점이다. 그리고 몇가지 정보를 추려 몇몇 학원에서 상담을 받게 되었는데 그게 정말 큰 문제였다.

이 친구는 비전공자가 6개월만에 개발자 취업을 할 수 있다는 달콤한 멘트에 속아 공부를 시작 하게 되었다. 수업에 대한 별 다른 말은 없었고 그저 수업수강만 잘 하면 되는 것 같았다. 내가 말하는 문제란 이것 이다. 공부방법도 안알려주고 따라치기만 하는 수업을 들은 점. 첫 번째 가장 큰 문제점이다.

코딩이 무엇이라고 생각하는가? 내가 되려는 개발자는 뭐라고 생각하는가? 나는 이 질문에 대답먼저 하는게 공부의 시작이라고 생각한다.

별 생각없이 어떤 이미지 때문에 단순히 좋아보여서 공부를 시작 하는 건 좋지만 내가 평생 직업이 될 수도 있는 이 직업에 정말 진지해진다면 내가 하려는 개발자가 뭘까? 라는 생각을 먼저 해야 한다. 그러면 여기서 물어 보겠다. 개발자란 무엇일까? 내가 수백명의 수강생들에게 이 질문을 하면 99%는 '개발하는 사람', '뭔가 만드는 사람', '웹페이지 만드는 사람' 등 개발, 만든다는 답변을 내놓는다. 물론 맞는 말이다. 개발자는 서비스를 만들어내는 사람이다. 그럼 현업에서 모든 개발자가 서비스를 만들어 낼 수 있을까? 답은 절대 NO다. 대체적으로 현업에서 개발자를 봤을 때 90%의 개발자는 개발을 못한다. 즉, 서비스를 만들어내지 못한다. 이 차이는 어디에서 발생할까? 내 생각은 바로 첫 단추부터 차이가 난다.

대부분의 개발자는 이렇게 탄생한다. 전공자는 좀 덜 하지만 비전공자들은 대체적으로 기술 획득만을 위한 공부를 한다. 예를 들어 Java를 배웠으면 다음 SQL을 배울 것이고 그다음 화면구현 HTML - CSS - JavaScript - JSP - Spring boot로 보통 이어지게 배울 것이다. 이렇게 배우고 취업전선에 나가서 왜 취업이 안되는지 억울해 할 것이다. 또는 어찌어찌 취업을 하더라도 내가 배운건 아무것도 아니라고 느낄 것이며 실무의 일은 너무 너무 어렵고 힘들고 알려줄 사람도 없다며 퇴사 생각을 하게 될 것이다.

뭐가 문제 였을까?

개발자가 개발을 하는 만들어 내는 사람이라고 답변을 했다면 만들어 내는 것을 배우는 게 맞지 않을까? 그런데 왜 무작정 남들 다 한다고 백엔드 교육을 이수했는가?

나는 개발자를 '문제 해결 하는 사람'이라고 생각한다. 왜냐면 서비스를 만들어 내기 위해서는 수없이 많은 문제를 해결해야만 가능하기 때문이다. 그럼 내 공부방법은 문제해결에 포커스를 둔 공부를 하면 된다. 괜히 기술스택이 정답이라고 따라갈 필요가 없다. 문제해결에 포커스를 둔다면 알고리즘 공부를 해야한다. 위에 쓴 기술스택에 알고리즘은 없다. 알고리즘은 문제해결능력이자 기본기이다.

대부분의 개발자가 이 사실을 모른채 공부하기 때문에 기본기가 없어서 간단한 업무도 못보는 것이고 문제해결능력이 없기 때문에 새로운 서비스를 만들어내지 못하는 것이다.

이것을 이해하지 못한다면 개발자의 길을 걷는 것을 진지하게 다시 고민해보시길 바란다. 그저 고통만 받을 것이다.

나는 이런 문제들을 해결하고자 수강생 중심의 상담을 진행중이다. 현재까지 300명 이상의 수강생들을 일일이 상담해주고 공부방향설정, 공부방법, 취업할 수 있는 방법론 들을 알려주고 멘토로써 코칭해주었다.

진짜 개발자가 되는 교육방법이 궁금한 사람들도 도와줄 수 있다. 아래 명함을 통해 문의를 주시고, 섣불리 문의 남기지말고 충분히 내 말이 맞는지 되돌아보고 문의 남기시길 바란다.

손흥민 미친활약에 MOM 토트넘 전술분석

ryushoshin — Tue, 24 Oct 2023 11:05:18 +0900

요즘 해외축구 손흥민 토트넘 경사 났습니다! 바로 새벽에 있었던 경기죠 프리미어리그 9라운드 토트넘vs풀럼 경기에서 손흥민이 역시나 미친 활약으로 팀을 승리로 이끌었습니다! 이로써 토트넘은 간당간당한 1위가 아니라 굳건한 1위로 2위 맨체스터시티와 2점차이 벌려 놓았습니다 !!

손흥민은 이번에도 최전방 공격수로 선발출전하여 공격진을 이끌었는데요 특히 이번 풀럼전에서 돋보였던 전술은 토트넘이 평소에 잘 사용하지 않던 게겐프레싱 전술을 썼다는 겁니다. 2골 모두 이 게겐프레싱을 통해 나왔고 모두 손흥민 발끝으로 나와 1골 1도움 미친활약을 선보였습니다. 바로 보시죠

골장면을 보시면 알겠지만 풀럼이 이번시즌 후방부터 빌드업 하는 전술을 많이 사용하고 있습니다. 특이한 점은 후방 빌드업을 할 때 보통 수비간격을 좁히고 라인을 내린 뒤 안전하게 진행하거나 리버풀처럼 실력이 좋은 팀은 3명의 수비라인과 수비형 미드필더 한명 정도를 제외 하고는 라인을 올려서 진행하는데 풀럼은 이도저도 아니게 후방빌드업을 펼쳤고 이를 포스테코글루 감독은 정확하게 파고들어 라인을 크게 올린 뒤 전방 압박을 진행했습니다. 첫 번째 골장면과 두 번째 골장면 모두 이 전술이 통한 골입니다. 진짜 명장 맞는 것 같습니다.

손흥민 어시스트 gif

손흥민이 진짜 주장으로써 돋보이는 점이 뭐냐면 최전방 공격수 롤을 받았지만 다른 공격수와는 다르게 욕심을 내지 않고 이타적인 플레이를 펼친 다는 점입니다. 사실 축구를 오래 보신 분들 같은 경우에는 잘 알겠지만 항상 지지않고 강한 팀의 특징이 골전 상황에서 이타적인 플레이가 나오는 팀인데요 대표적으로 바이에른 뮌헨과 예전 바르셀로나가 그러했습니다.

매디슨은 올시즌 골 전환률도 상당히 높은 편으로 기회가 주어지면 좋은 슛팅 능력으로 많이 득점하는 모습을 보여주고 있습니다. 요즘 비수마 - 매디슨 - 손흥민 라인을 보면 예전 DESK (델레 - 에릭센 - 손 - 케인)라인 생각이 안날 정도로 엄청난 활약을 보여주고 있습니다.

어쩌면 매디슨이 에릭센의 활약을 넘을 수도 있는 선수다 라고 보여집니다.

1골 1어시

패스 성공률 84% (20/24)

찬스메이킹 4회

골과 이어지는 빅찬스 메이킹 1회

키패스 2회

드리블 돌파 성공률 76%

ㅡ

손흥민 이번 경기에 대한 사람들 반응

손흥민 선수는 92년생으로 올해 30이 넘은 나이에도 불구하고 매년 더 나아지는 경기력을 선보이고 있습니다. 예전 무리뉴 감독 밑에서도 최전방 공격수로 잠시 활약한 적이 있는데 그때는 욕이란 욕은 진짜 다 먹었었는데요. 그때는 확실히 피지컬에서 우위가 있다거나 라인브레이커나 링커로써 움직임이 좋다는 느낌은 없었는데 이번에 히샬리송을 대신해서 최전방 공격수 역할을 할 때는 그런 점을 싹 지우고 09시즌 토레스마냥 좋은 활약을 펼치는 중입니다. 최근 손흥민 선수는 레알마드리드와도 링크가 나왔을 만큼 30이 넘어도 세계 최정상의 클럽들이 노리는 선수입니다.

월드클래스를 넘어 프리미어리그 GOAT가 되고 있는 손흥민 !