Dharma

IT 업을 하신 분들에게 빠질 수 없는 두가지 질병이 있는데 첫째가 위염이요 둘째가 허리 통증 입니다. 저도 당연히 이걸로 고생했고요, 이미 미리 고통 받으신 선배분들이 저에게 전수해준 방법으로 많이 좋아져서 저또한 후배님들에게 이 방법을 전하고자 합니다. 

일단 둘째 허리통증 입니다. 허리는 아픔이 있으면 무조건 누워서 쉬는게 최고의 허리 보약 입니다. '아플때는 쉬어라' 

만약 허리의 통증이 어느정도 가시고 허리를 좀 강화 시키고 싶다 라는 생각이 들것입니다. 그러면 무조건 '등산'입니다. 미켈란젤로는 중세시대에 평균 수명 40대인 바로 그 시대에 89세 가깝게 살았습니다. 죽기 삼일전까지 '산'에 돌캐러 갔다는 건 유명한 사실입니다. 주변에 등산 열심히 다니는 사람들 특징이 나이 상관 없이 허리 꼿꼿하고 정정하죠? 등산이 답입니다. 

그런데 IT 인들이 언제 등산하러 다닙니까, 게임에서는 산을 올라가도 현실에서는 올라가기 싫은게 사람의 마음이죠, 그런 분들을 위한 운동이 '계단 오르기' 입니다. 더도 말고 일주일에 랜덤 3-4일 정도 하면 딱 좋은데 , 날마다 해도 괜찮습니다. 제일 좋은 시간이 식사 하고 나서 입니다. 혈당도 낮추고 무산소 유산소 운동을 병행하는 효과도 있고 정말 좋습니다. 

첫째 위염입니다. 위염이나 위경련, 특히나 급성 위경련은 진짜 무지 막지하게 아픕니다. (본인도 경험이 있슴) '명치끝을 쥐어짜는 고통', '견디기 힘들정도의 고통', '주저앉을 정도의 고통', '잠을 잘 수 없을 정도의 고통'등 묘사도 다양한데, 심하면 멀쩡했던 허리까지 아파서 허리가 펴지지 않아서 허리를 굽은 상태로 걸어야 하고 잠도 똑바로 잘 수가 없을 정도 입니다. 진짜 다시 겪고 싶지 않을 정도의 고통입니다. 

주요 원인은 '스트레스' 라고 합니다. (제 회사를 날려먹고 두 세달 있다가 온거 보면 일리가 있습니다.) 또 다른 주요 원인으로는 물처럼 마시는 '커피', 그리고 의외지만 '우유' 입니다. 이 세가지를 다 합쳐지면 젊은 나이를 벗어나자 마자 그 극한의 고통을 맛 볼 수 있습니다. 즉 스트레스를 받은 상태에서 '찬' '까페라떼'를 자주 자주 마셔주면 위가 선천적으로 튼튼한 사람이 아니면 바로 일단 위염부터 심하면 위경련을 맞이합니다. 

개발자들이 커피나 까페라떼를 마시면서 머리를 쥐어짜면서 개발하는 행동이 위에 얼마나 안 좋은지 아시겠죠? 그래서 보통 위를 좋게 하기 위해서는 방법은 간단합니다. '양배추'입니다. 양배추를 자주 자주 먹어줘야 위가 건강해집니다. 제가 아팠던 시절에는 아침에 일어나서 '양배추'와 '요구르트' 하나를 갈아서 아침 대신 마셨습니다. 6개월쯤 이렇게 아침에 먹어주면 강철의 위를 소지하게 됩니다. 물론 먹기 좋은 맛은 아닙니다. 

그런데 아침에 바빠 죽겠는데 언제 양배추 갈고 있겠습니까? 그럴때를 위한 좋은 약이 있습니다. 일본의 국민약 '카베진' 입니다. 

양배추 갈아서 만든 약입니다. 

자 열심히 노력해서 개발자들 힘들게 하는 두가지 질병을 극복해 봅시다!! 

일이 있어 아침에 일찍 일어나야 해서 피곤한 몸을 이끌고 회사에 일찍 출근했다. 지하 주차장에서 주차하고 '잠깐 눈을 감는 것 정도는 괜찮겠지' 잠깐 눈을 감았다가 눈을 떴는데, 지하 주차장이 아니라 도로 한복판에 있는 나를 발견했다.

'꿈이구나' 피식 거리며 주위를 둘러보고 '이제 일어나야지' 하는데 반응이 없다.

'응? 왜 안 일어나지지?' 다시 한번 집중해서 일어나야지 하는데 주변 상황에 변화가 없다.

뒤에서 엄청나게 다른 차들이 빵빵거려서 나도 모르게 습관적으로 차를 출발 시키고 주변을 둘러보았다. 도로 공사를 하고 있고, 바쁘게 움직이는 인부들과 거기에 무단 횡단 하는 사람들 까지 너무나 자연스럽고 그들이 떠드는 소리까지 들린다.

'꿈이 아닌가? 그렇다면 주차장에서 눈을 감았던 기억은 뭐지?' 혼란스러워하며 목적지도 정하지 않은 채 차를 운전하고 있었다가. 문득 하늘에 커다란 비행체가 있는 것을 보았다.

'뭐지? 저만한 크기라니?'

그것은 바로 그랜다이저 였다 -ㅅ- . 심지어 스페이저와 크로스 된 형태였다 (즉 UFO 형태). 하늘에서 차분하게 내려오는 광경을 지켜보고 있다가 혼잣말을 했다.

'에이 꿈이구나'

그리고 꿈이라는 것을 알아채고 눈을 뜨니 주차장 안이었다. 시간은 무려 30분이 넘게 흐른 뒤였다. '이 정도 느낌의 VR 이면 돈이 안 아깝겠네' 라는 생각을 하며 사무실로 들어갔다. 

먼저 원 글은 루리웹에서 봤습니다. 일본 사람으로 보이는 분이 쓴 글인데, 담담한 필치로 자신의 경험을 이야기 하고 있는데, 그 사연에 깊은 공감을 했습니다. 

원글은 여기 클릭

 '여름 방학 때 아빠가 도쿄에 뮤 배포회 데려가주신대!' '좋겠다! 그런데 포켓몬청, 언제 오려나'
종이 울리자마자 떠들석해지는 교실에서 눈을 빛내는 친구들. 초등학교의 화제 중심에는 항상 포켓몬이 있었다.
그럴때는 나 혼자 맨날 바닥을 보고 있었다. 우리집은 게임보이도, 슈패미도 없었으니까.

'패미컴은 눈이 나빠지니까'.
나와 남동생이 조를 때마다 어머니는 곤란하다는 표정을 지으셨지만 결코 굽히진 않으셨다.
도감, 세계명작전집, 개미 관찰 세트.
산타는 매년 내 요청을 무시하고 고급 백화점의 포장에 쌓인 훌륭한 선물을 주었다.
기쁘지 않지만 기쁜 척 하는게 힘들었다.

은행원인 아버지가 매일밤 늦게까지 일하는 와중에 전문대를 졸업하고 전업주부가 된 어머니는 분투하고 계셨다.
세탁물은 항상 가지런히 정돈되어 있었다.
그녀가 믿는 이상적인 육아란 구몬과 수영과 피아노의 로테이션이며 게임보이 같은 퇴폐적인 오락은 끼어들 여지가 없었다.

어른에게 있어 이상적인 자식은, 아이들 세상에서는 이물질이나 다름없다.
포켓몬에 대한 화제에 따라가지 못하는 나를 기다리던건 소외감이었다.
수영 기록이 빨라져도 초등학생이 소인수분해를 풀어도, 아무도 내게 관심을 주지 않았다.
다들, 방과후에는 통신 케이블을 들고 다나카집에 모여 통신대전에 열중했었다.

드퀘도 FF도 크로노트리거도 TV로 친구들의 플레이 화면을 보는 것만으로도 참을 수 있었다.
하지만 포켓몬은 달랐다.
게임보이 화면은 너무 작아서 가까이 보려고 다가가면  '가깝잖아, 안보여' 라며 매정하게 거절당했다.
통신대전으로 불타오르는 친구들 옆에서 혼자 책장에 꽂힌 오래된 만화잡지를 봤다.
눈물을 참기위해 필사적이었다.

용돈을 모아서 포켓몬 공략본을 샀다.
구석부터 구석까지 너덜너덜해질 때까지 읽었다.
기술머신의 번호와 기술명을 전부 외웠다.
모든 포켓몬의 진화 패턴도 암기했다.
하지만 그곳에는 내가 움직일 수 있는 피카츄도 뮤츠도 었었다.
오히려 허무해질 뿐이라는 걸 깨닫는데는 그렇게 긴 시간이 걸리지 않았다.

어른이 된 지금이라면 알 수 있다.
건전한 것들에 둘러싸여 유혹에 지지 않고 건강하게 자라주길 바란다는 어머니의 마음은 세상에서 사랑이라고 부르는 것이라는 걸.
내가 사립대라고는 해도 와세다를 나와서, 나름대로 이름 있는 기업에 들어가 일하게 된 것은 어머니의 사랑 덕분이다.
하지만, 유소년기에 충족되지 못한 마음은, 갈증은, 지금도 여전히 확실하게 남아있다.

'우와, 바이올렛이다! 만세! 아빠, 고마워요!'
아침에 거실에서 아마존 포장 박스를 뜯어보며 난리치는 아들.
'생일도 크리스마스도 아닌데, 아직 SAPIX(중학교 입시) 숙제도 다 안했잖아' 라며 찌푸린 표정을 짓는 아내.
이건 아들을 위해서만이 아닌, 내 상처를 치유하기 위한 의식이라 말해도 이해받지는 못할 것이다.

'그러고 보니 a1의 켄타군은 집에 스위치가 없대. 엄마가 엄하시다고. 불쌍하더라'
아들의 지나가는 한마디에 심장 고동이 거칠어 진다.
아이들 세계에서 공통 언어를 가지지 못하고 어머니의 감시속에서 편차치를 올리기 위해 일일 문제집을 묵묵히 푸는 초등학교 남학생.
얼굴도 모르는 켄타군의 일상을 떠올리자 가슴이 조여들었다.

심야에 가족이 모두 잠든 아파트 저층의 거실에서 혼자 스위치에 전원을 넣는다.
나오하가 마스카냐까지 진화해도, 챔피온 로드에서 테사를 쓰러트려도
놀라움이나 기쁨을 공유할 친구는 어디에도 없다.
맥주를 한모금 마신다.
내가 진짜로 바랐던 건, 이제 두 번 다시 손에 넣을 수 없다. 

길게 주저리 주저리 글을 썼다가 다 지웠다.  결론 부터 간단히 말하겠다.

전공 vs 비전공

압도적으로 전공자가 유리하다. 이건 논란의 여지조차 존재하지 않는다. 대부분의 비 전공자들의 안타까움은 잘 이해하고 있다. 나도 20년간의 개발자 경력동안 어느정도 경력자 사이에서는 전공이 의미가 희미해 지는 순간이 온다는 것을 절대적으로 이해한다. 하지만 신입에서는 이야기가 다르다.

'당신이 그냥 전공자를 편애하는 개발 리더 아닌가?' 라고 말할 수도 있겠지만, 내 인생에서 첫 사수가 역사학과 출신 개발자 였다. 엄청나게 코딩을 잘하시는 훌륭한 개발자셨다. 그리고 오랫동안 같은 팀으로 회사를 옮겨도 같이 일하는 클라이언트 개발자는 처음에 뽑을때부터 비전공자 출신이였다. 나도 비전공자가 훌륭한 개발자가 될 수 있다는 것을 누구보다 잘 아는 개발 리더라는 이야기가 하고 싶은 거다.

그럼에도 불구하고 요즘 학원에서 천편일률적으로 배우고 나오는 비전공 개발자들의 이력서에는 특별함이 존재하지 않다. 즉 나는 현실을 말하는 것이다. 대부분의 사람들 심지어 비전공자 본인 조차도 전공자와의 서류 싸움에서는 힘들 것이라는 것을 이해한다. 비전공 개발자들은 서류 부분 트라이부터 엄청나게 큰 핸디캡을 가지고 전공자들과 싸워야 한다. 단지 학원에서 프로젝트 했다는 것으로는 개발 리더의 흥미를 끌기가 어렵다.

그래서 추천한다. 물론 엄청나게 어려울 것이다. 하지만 그러한 과정을 거치고 나서 당당히 그 내용을 기재했다면 개발 리더는 조금이라도 다르게 지원자를 바라보게 될 것이다. 학원을 졸업해서 취업 준비 기간중에 개인 프로젝트를 하라는 것이다. 아 물론 하는 사람들 엄청나게 많다는 것을 안다. 실제로도 이력서를 보면 개인 프로젝트 엄청나게들 많이 한다. 하지만 그 수 많은 사람중에 실제로 제품화 까지 도달하는 사람은 거의 없다. 개인 프로젝트 라지만 학원 강사의 지원을 받지 않으면 github 에 README 하나 작성하지 못하는 지원자들이 수두룩 하다.

즉 클라이언트라면 실제로 제품을 만들어서 스토어에 올리고, 서버 개발자라면 실제로 제품을 런칭해서 URL 까지 입혀서 출시해서 실제로 클릭해서 동작하게 만들라는 거다. 아 물론 이래도 관심을 가지지 않는 개발 리더가 존재할 수도 있다. 그래도 어쩌겠는가? 개발은 그만큼 전공자가 유리한 필드다. 그 천장을 무너뜨리려면 그정도 정성을 기울여야 이력서를 보고 한 번 이야기라도 할려고 서류를 통과 시킬 것이다.

요약하면 비전공자들은 이력서에 더욱더 노력을 기울이고 '색안경을 끼고' 바라보는 개발 리더가 흥미를 가지게 할려면 무엇을 해야 할지 고민하라는 것이다. 제품을 출시하는 것이 크나큰 강점이 될 것이라는 것이 내 의견이다.

ps. 실제로 나는 클라이언트 개발자가 다른 회사에 거의 50번의 면접에서 떨어지고 우리 회사에 지원 했을 때 그 친구가 만든 제품을 실제로 스토어에 올린것을 깔아보고 나서 면접을 거쳐 뽑게 되었다. 그 친구는 아주 훌륭한 개발자로 성장했다. 

gtpai 를 이용하니 Multibyte 처리가 안되어 있는 함수를 이용하기 때문에 제대로 동작하지 않는다. 그거와 최대한 유사하게 가장 간단한 기능만을 옮겨봤다. 

(defvar gpt-base-url "https://api.openai.com/v1/completions")
(defvar gpt-chat-url "https://api.openai.com/v1/chat/completions")

(defcustom gpt-model ""
  "API Model for OpenAI."
  :type 'string
  :group 'crutil)
(defcustom gpt-api-key ""
  "API key for OpenAI."
  :type 'string
  :group 'crutil)



(defun send-query-to-gpt (text)
  "ask to gpt"
  (interactive
   (list (read-string "물어봐: ")))

  (when (null gpt-api-key)
    (error "OpenAI API key is not set"))

  (let* ((url-headers
	  `(("Content-Type" . "application/json")
	    ("Authorization" . ,(format "Bearer %s" gpt-api-key))))
	 (url-data
	  (json-encode `(("model" . ,gpt-model)
			 ("prompt" . ,text)
			 ("temperature" . 0.7)
			 ("max_tokens" . 1000)))))
    (request
      gpt-base-url
      :type "POST"
      :data url-data
      :headers url-headers
      :parser 'json-read
      :success (cl-function
		(lambda (&key data &allow-other-keys)
		  (insert (cdr (assoc 'text (elt (cdr (assoc 'choices data)) 0))))))))

  )

적당히 load 될 수 있는 곳에 이 함수를 만들어 두고 

(require 'cr-utils)
(setq gpt-model "text-davinci-003")
(setq gpt-api-key "<INSERT YOUR API KEY>")

(global-set-key (kbd "C-c o") 'send-query-to-gpt)

맨 위의 cr-utils 는 send-query-to-gpt 함수가 위치한 파일이다. 

이러면 편리하게 사용할 수 있다. GPT 는 상당한 구라쟁이지만 말이다. 

요리와 칼질에 익숙해 졌다고 생각했을 때, 쉴새 없이 칼을 놀리다가 손가락의 일부를 썰어버렸다. 1 cm 정도 상처는 작았지만 피가 멈추지 않아서 응급실에 갔다. 간김에 파상풍 주사도 맞고 항생제도 맞음, 이제 10년간 파상풍 주사를 맞지 않아도 된다고 하니, 그나마 다행일려나? 

조금 익숙해졌다고 방심한 탓인지, 이번 부상이 뼈 아프게 다가온다. 관절 부분이 다쳐서 다 낫더라도 예전만큼 완벽하게 구부러 지지는 않을거라고 겁을 준다. 흑흑.. 

방심이 최대의 적이로다. 

  부제: 경영의 난제, 어떻게 풀 것인가?
  원제: The Hard Thing About Hard Things
  저자: 벤 호러위츠
  옮김: 안진환

  스타트업 대표를 거쳐서 지금은 경영의 구루라는 평을 듣고 있는 벤 호러위츠의 CEO 시절과 벤쳐 캐피탈 회사를 만들때의 이야기를 담고 있다. 실상 캐피탈 회사는 거의 부록에 가깝고, 주로 본인이 CEO 를 맡았던 시절의 난제를 담고 있다.

  나는 넘지 못했던 문턱을 넘어섰던 사람들을 만나는 요즘, 나보다 전에 내가 넘어서지 못했던 문턱을 넘어선 사람의 성공적인 이야기가 나에게 감탄과 묘한 씁쓸함을 전해준다.

  혹자의 평은 군주론을 IT 회사에 맞춰서 요약한 것, 회사 초창기의 대표들은 말이 안된다고 생각할지 모르지만, 연배가 있는 사업가들은 당연한 이야기네? 라고 끄덕거릴 만한 내용들이다.

  내 입장에서는 이런 내용을 이렇게 설명할 수 있는 능력에 감탄을 했다. 머리로는 알고 있지만 표현하기 어려운 부분을 잘 설명하고 있다.

  어려운 '자리'고 누구도 믿기 어렵다. 그리고 결단을 내리는 '자리'고 그 누구의 조언도 진심으로 나에게 맞지도 않는다. 다들 본인의 입장에서만 이야기를 한다. 전부 들어보고 판단을 해서 본인의 힘으로 결정을 내리는 '자리' 즉 CEO. 그래서 내린 결정이 맞아 들어가면 극한의 쾌감을 느낄 수 있다. 물론 실패했을때는 그 교훈을 뼈에 새기게 된다. 그만큼 어렵고도 중요한 '자리' 

  그런 '자리'에서 고민을 느끼고 있다면 일독을 권할 수는 있으나, 기술자로 창업을 한 입장에서는 책에서 다루는 고민은 어느정도 발전을 시킨 회사에서 할 만한 고민들로 이루어 졌다고 생각할 수 있다. 창업 한지 얼마 안되는 창업자는 저런 고민 같은 것도 사치다. 살기 위해서 총알이 빗발치는 전장을 뛰어다니는 입장일테니. 

이번에 회사에서 새로운 기능을 런칭했다. 내려오는 데이터 량이 좀 된다. 150K 정도 

스테이징 서버(한국에 있다)에서 혹독한 테스트를 거쳐도 문제가 없고, 론칭후 테스트에서도 별 이상이 밝혀지지 않았다. WI-FI 환경하에서도 동작을 잘하고 

문제는 내 폰에서 발생했다. 참고로 나는 SKT 폰을 사용중이다. SKT 의 LTE 환경하에서는 멈춘거처럼 동작하는 것이다. 150K 다.. 다시 말하면. 그정도 데이터를 내려 봤는데 멈춘다고? 

개발자를 소집해서 물어봤더니 전혀 안 느리다고 한다. 내 폰을 실제로 보여주니 개발자들이 다들 당황하는 것이다. 결국 이런 저런 테스트를 통해서 내린 결론은 SKT - LTE 가 완전 개 구리다는 것이다. 국내는 별 문제가 없으나 특히 해외가

KT, LG, WI-FI 망에서는 아주 잘 동작한다. 이렇게 쓰는 것도 웃기다. 겨우 150K 인데.. 

결국 SKT 의 LTE 환경이 개선되길 바라는 것은 코로나 19가 자연적으로 사라지길 바라는 것만큼 이루어지기 힘든 바람일테니, 우리가 패킷을 다이어트 시켰다. 1/3 로 줄였더니 시간이 많이 단축 됐다. 하.. 5G 시대에 150K 때문에 이런 난리가 일어나다니.. 

결론은 SKT-LTE 가 해외에 있는 서버랑 연결할때 극악의 효율을 보여준다는 것이다. 해외 서비스 준비할때 이런 것도 고려해야 할 것이다. 

저번 글에 관한 제 실제 사례 언급을 하겠습니다. 

패치 전략에 대한 단상에 대한 저번 포스트글

사실 이 외에도 많은 실제 사례가 있지만 이게 가장 최근의 사례 입니다. 

참고로 저는 KPOP 관련 회사에서 일하고 있습니다. 

1. 회사에서 라이브 방송의 필요를 이야기함.

 새로운 먹거리를 찾기 위해서 이거 저거 시도하는 중에서 나온 이야기 

2. 아마존 미디어 라이브를 이용해서 빠르게 구현

 클라이언트 작업량 말고 서버 단에서는 작업 자체는 그리 오래 걸리지 않음, SaaS 를 쓰면 좋은 점중 하나

3. 이슈 발생

 - 가격이 쎄다. 1채널 이용시 하루 대략 80만원 비용 나옴 

 - 송출 영상과 클라이언트 간의 영상이 대략 30초 딜레이 발생 (유튜브 12초, 아프리카 6초)

4. 직접 솔루션 만들기로 결정

 - 기존에 비싼 AWS 의 트랜스 코더를 직접 만들어서 비용 절감한 케이스가 있어서 생각보다는 쉬울거라 예상 

 - 결국 예상보다 훨씬 빠른 기간 안에 솔루션 완성

5. 베타 방송시 이슈 발생

 - 영상 송출시 윈도우 머신과 nginx 를 이용한 방식이 동시 분배가 안되고 한쪽에 영상이 안나오는 현상 발견

6. OSX 에서는 그런 현상이 발견 안되고, 윈도우에서 플러그인으로 해결하는 방식으로 해결

 - 송출하는 프로그램과 연결하는 프로그램에서 문제가 발생하는 것으로 원인 파악 

7. 두번째 베타방송시 기술적으로는 성공.

결론적으로는 아마존 미디어 라이브 이용시 하루종일 방송하는 것을 기준으로 할때 한달 방송 1채널 2400만원 , 6채널 일때는 1억 4천 400만원 가량 소요 예정 (방송 딜레이 30초)

새로 만든 솔루션을 이용할때는 하루종일 방송한다는 기준으로 한달에 200만원 가량 소요 예정 (방송 딜레이 7-10 초)

충분히 아이디어 단으로 기획이 충분하고 개발자들이 개발을 진행할 수 있을 정도로만 정리되는 기획과, 이용할 수 있는게 있으면 빠르게 제품을 제작해서 빠르게 기존 전략을 수정하며 개발 방향도 맞춰서 수정하는 쪽으로 대응하는 방식만으로도 시장 속도에 맞출 수 있게 된다는 것을 알게되는게 충분합니다. 

  저번 글 에서 언급했던 것과 같은 사례가 있어서 소개합니다.  바로 Boney M. 이라는 그룹입니다.

https://www.youtube.com/watch?v=l3QxT-w3WMo

  1974년, 독일의 대중음악 프로듀서 프랑크 파리안(Frank Farian) 이 흑인들이 나오는 수사물을 보고 영감을 받아서 노래를 한 곡 작곡합니다. 흑인 분위기만 날뿐 실제로는 프랑크가 노래를 직접 부르고 녹음해서 빠르게 앨범을 내 봤는데 이 앨범이 히트를 쳐서 여기 저기서 공연 요청이 쇄도 했다고 합니다.

  그래서 빠르게 자메이카 출신들과 다른 한명의 흑인들을 조합해서 그룹을 만들고 그 그룹으로 여기 저기 공연을 다니면서 엄청난 인기를 누렸습니다. 전설적인 그룹 아바 와 유럽 팝계를 양분했을 정도니 어마 어마한 인기였겠지요.

  게다가 그룹의 이름을 유지한 채 , 멤버들이 교체되면 계속 유지하는 전통도 만들어 낸 그룹이라고 합니다.

  빠른 기획 실행의 전형적인 과정입니다.

  재미 있는 아이디어 -> 빠른 기획 (거의 아이디어와 동시에 대충 이렇게 하면 되겠다 정도) -> 초 빠르 실행 (실행하는데 전혀 머뭇거리면 안됩니다.) -> 이슈 발생 (실제로 그룹이 존재하지 않는다) -> 패치 (그러면 그룹을 만들면 되지) -> 이슈 발생(멤버가 나감) -> 패치 (새로 뽑고 기존 멤버는 졸업이라 함 )

  이슈 큰 것만 꼽아 봤는데 긴 기간 동안 얼마나 많은 이슈가 있었을까요? 그 수 많은 이슈를 패치해 가며 그룹 (프러덕트)을 유지해 왔을 것입니다.