DeveLife

2023년 회고

Sun, 31 Dec 2023 22:12:43 GMT

들어가며

2021년 회고 이후 회고를 처음 작성한다. 사실상 한 해만 건너뛴 셈인데, 작년에는 왜 건너뛰었을까? 기억이 명확하게 나지는 않지만 아마 작성려고 시도하긴 했던 것 같은데, 시간이 없다는 미루고 미루다 해를 넘기게 됐고 결국엔 써봤자 달라지는게 있겠느냐는 식의 어리석은 생각으로 포기했던 것 같다. 그래서 그런지 2022년은 기억에 남는 장면들이 잘 떠오르지가 않는데, 나쁘게 말하면 정말 그냥 무지성으로 일만 했던 것이다. 그렇다고 해서 2021년은 기억이 생생히 나느냐? 하면 그것도 아니고, 이렇게 회고를 해두면 2024년 이맘때가 돼서 2023년이 생생히 떠오를까? 해도 그것도 아닐 것 같다.

인간은 망각의 동물이기도 하고, 두뇌 하드웨어 스펙상으로 봐도 그렇고, 무엇보다 개인적인 성향상 지나간 일을 오래 보관하는 것을 선호하지 않아 항상 가비지 컬렉션이 필요하다. 하지만 그럼에도 불구하고, 고칠건 고치고 깨달을건 깨달아서 들고 가는게 장기적인 관점에서 좋지 않을까. 고등학교 시절 모의고사 오답노트 적듯이, 내 인생과 커리어의 오답노트를 남긴다고 생각하고 앞으로는 길게는 아니더라도 꾸준히 정리해보려고 한다.

개발자로서 돌아본 2023년

회사 안에서

신규 서비스 오픈

정식으로 공개된 지 많이 지나진 않았지만 내가 소속된 개발팀 구성원의 70% 이상이 약 1년 반정도의 시간을 투입한 프로젝트가 드디어 정식으로 오픈했다. 서비스의 이름은 엔트리 탐험하기로, 기존에 서비스되고 있던 엔트리의 블록 코딩을 활용할 수 있는 웹 기반 실시간 2D 그래픽 온라인 서비스이다.

모 유저가 제작한 월드

2022년 중순 즈음에 첫 삽을 뜨고 지금까지 프로젝트를 진행해오면서 기술적인 부분, 기획적인 부분 등 다양한 방면에서 정말 말 그대로 우여곡절도 많았지만, 클로즈 베타, 사내 공개 등을 거쳐 어찌저찌 무사히 사용자들에게 공개되어 쓰임이 생기는 모습을 보니 여러 감정들 중에서 그래도 뿌듯함이 가장 크게 들었다.

하지만 아직도 구체화되지 않은 아이디어, 개발되지 않은 스펙이 산더미처럼 쌓여있기 때문에 갈 길이 멀다. 이제 막 공개 단계이니 2024년에는 더욱 보완하고 발전시켜서 더 규모있는 서비스로 성장하는 모습을 볼 수 있다면 좋겠다.

스터디

현재 소속된 회사에서는 회사 차원에서 구성원들간의 스터디를 권장하고 있다. 올 해에는 어떻게 하다보니 니즈가 맞는 분들과 몇 차례나 스터디를 진행했는데, 이에 대해 간단하게 소회를 남겨보면 좋을 것 같다.

자바스크립트 스터디

다른 팀 소속의 비슷한 연차의 동료분들과 함께 JS를 더 깊게 제대로 익혀보자는 취지에서 이 스터디를 시작했다. 모던 자바스크립트 Deep Dive라는 책을 교재로 활용해 스터디를 진행했는데, 이 책은 쪽수만 1000페이지에 달하는 굉장한 두께를 자랑하는 책이다. 그만큼 JS에 관련된 내용을 전방위적으로 다루고 있는 책인데다, poeimaweb을 운영하는 이웅모님이 저술하신 책이다보니 책 구성과 내용 자체는 굉장히 만족스러웠다.

스터디는 주 1회, 오프라인으로 한 자리에 모여 약 1시간동안 사전에 협의한 진도만큼의 챕터를 그 자리에서 읽고, 그 과정에서 생긴 궁금증이나 공유할만한 내용들을 약 30분에 걸쳐 토론하는 방식으로 진행했다. 이런 진행 방식이 개인적으로는 잘 맞고 효과적이라고 생각되었는데, 그 이유는 스터디 준비를 위해 별도로 할애해야 하는 소위 “스터디를 위한 스터디”와 같은 시간을 들이지 않아도 됐고, 다 같이 모인 자리에서 정해진 같은 분량을 소화해내는 과정이 스터디라는 목적에 더 부합한다고 느껴졌기 때문이다.

다만 이런 방식의 단점도 분명하게 체감할 수 있었는데, 하나는 스터디에 참여하는 모든 인원이 글을 읽는 속도가 동일한 것이 아니다보니 정해진 시간 안에 같은 분량을 소화해내지 못하는 인원이 생겼고, 그런 사람은 진도를 따라가기 위해 따로 시간을 할애할 수밖에 없는 부작용이 따른다는 점을 들 수 있겠다. 또 하나는, 스터디 목표로 삼은 책 자체가 워낙 두껍고 내용이 방대한데, 주 1회 1시간 30분 스터디임에도 같은 자리에서 모여 읽는 방식을 채택하다보니 완료하는 데까지 시간이 너무 오래 걸렸다는 점이다. 도중에 각자 불가피하게 스터디 날짜에 휴가를 써야 하는 날이 생기거나, 공휴일 혹은 연휴가 겹치는 등의 사유로 당초 계획했던 기간보다 완주하는 데까지 약 5주정도 시간이 지체되었다.

따라서 앞으로 또 이런 진행 방식을 스터디에 채택하게 된다면 본 스터디를 진행하기 앞서 서로 읽기 수준을 사전에 충분히 인지하고 협의할 수 있는 과정을 두면 좋을 것 같고, 공휴일이나 휴가 일정을 대략적으로 포함해 완주 기간을 넉넉하게 설정하거나 혹은 아예 기간을 타이트하게 잡고 스터디 시간이나 횟수를 늘리는 등의 방향으로 진행해볼 수도 있을 것 같다.

어쨌든 그렇게 결과적으로는 스터디를 성공적으로 마무리했으나, 시간이 반년정도 지나니 기억이 흐릿해져가는 것 같다. 아무래도 언어 자체의 철학과 구조에 대한 학습이다 보니 스터디 한 번 진행한 것 가지고는 아직 일정 수준 이상 이해했다고 하기는 어려울 것 같기도 하고, 상용 애플리케이션을 만드는 일을 하는 입장에서 평상시에 항상 사용하는 언어의 구조를 상기하면서 일하는 것도 어렵다고 생각하기 때문에, 조만간 중요하다고 체크해뒀던 부분들만이라도 복습하는 시간을 가져보면 좋을 것 같다는 생각이 들었다.

디자인 패턴 스터디

개인적으로 좀 반성의 감정이 드는 스터디 경험이다. 솔직히 말해서 이 스터디에 참여는 했으나 언제 시작해서 언제 끝났는지도 잘 기억이 나지 않을 뿐더러 진행 당시에 나름 열심히 참여했다고 생각하나 무엇을 얻었는지조차 자신있게 말하기 어려울 정도로 기억이 흐릿하다.

스터디는 patterns.dev 웹사이트를 교재삼아 진행했는데, 해당 웹사이트는 영어로 작성되어있어 한국어 버전도 있지만 당시에는 실제 원본 컨텐츠를 100% 번역한 것은 아닌 것으로 느꼈으며, 최근에 다시 확인해보니 원본 사이트에 새로운 컨텐츠가 업데이트되는데 번역 사이트에는 반영되지 않는 것으로 보인다. 웹사이트는 자바스크립트로 다룰 수 있는 여러가지 디자인 패턴에 대해 일반, 렌더링, 성능 섹션으로 나뉘고, 그 안에 세부적으로 개별 패턴에 대한 컨텐츠로 구성되어 있는데, 최근에는 Vanilla, React, Vue로 나뉘는 대분류 카테고리가 한 단계 더 생긴 것으로 보인다.

스터디 당시 주 1회, 스터디 참여자들 각자 본인이 원하는 컨텐츠를 선택하여 한 주동안 따로 공부하고 준비한 뒤에 스터디 시간에는 모여 자신이 담당한 내용을 발표하는 방식으로 진행되었는데, (핑계일 수도 있지만) 그런 진행 방식 때문인지 개인적으로는 스터디에 몰입하기 어려웠던 것이 아닐까 하는 생각이 든다. 개인적으로는 서로 다른 부분을 맡아 따로 준비해서 발표를 통해 진도 범위를 커버하는 방식이 가장 이상적이면서도 아이러니하게도 가장 최악의 스터디 진행 방식이 아닐까 생각된다.

당시의 기억을 좀 더 구체적으로 떠올려보면, 해당 주제에 대해 이미 글과 그림으로 잘 정리가 되어 있는 컨텐츠가 기본적으로 주어지다보니 이를 활용해서 혹은 해당 주제에 대해 더 깊게 다른 자료들을 찾아보기보다는 이미 있는 자료에 의존하게 되었던 것 같고, 그래서 결국 발표시간에는 화면의 글을 그냥 앵무새처럼 따라읽는 꼴이 되었으며, 내가 그런식으로 하다보니 다른 사람의 발표에도 귀 기울이지 못하게 되어 사실상 이도 저도 아닌 시간 낭비를 한 꼴이 되었던 것 같다. 또 다른 관점에서, 해당 스터디를 통해서 도출된 어떤 결과물이 전무하고, 어떤 결과물을 도출하려는 실질적인 노력 또한 딱히 없었으며, 하물며 주간 개인별 담당 주제 배정도 구두로 진행하고 기억에 의존하여 간단한 체크박스조차 기록하지 않았기 때문에 적극적으로 참여하기보단 솔직히 끌려다니는 형태가 되었던 것 같다.

돌이켜보면, 종합적으로 여러 방면에서 아쉬움이 남는 스터디다. 특히 이 스터디 경험을 통해 앞으로 새로운 어떤 스터디를 시작하게 된다면, 진행 방식에 대해서 충분한 고민이 필요하고 참여자들 간에도 충분한 협의와 인지가 바탕이 되어야 모두에게 시간 낭비 없이 건강한 방향으로 스터디가 진행될 수 있다는 점을 깨닫게 되었다. 또한, 자료 자체는 굉장히 좋았던 기억이 있고 최근에도 계속 업데이트가 되는 것으로 보아 시간을 내어 혼자서라도 하나씩 다시 차근차근 읽어보는 것도 좋을 것 같다는 생각이 들었다.

플러터 스터디

최근 들어 시작해 진행중인 스터디이다.

이전에도 크로스 플랫폼 모바일 개발에 대한 관심은 꾸준히 있었고, 그 중에도 아무래도 커리어 초기부터 React를 주로 사용하다보니 React Native에 대해서도 관심이 많았고 실제로 튜토리얼도 다뤄본 뒤로 제대로 공부해야봐야겠다는 생각을 가지고 있었다. 하지만 이러저러한 핑계로 미루던 중, 최근 1년동안 Flutter에 대한 이야기들을 자주 접하게 되어 이런 것도 있구나 인지하고 있던 차에, 팀 내 시니어 분의 스터디 모집 공고(?)를 보고 이번 기회에 한 번 찍어 먹어봐야겠다는 생각에 참여하게 되었다.

완전 최근에 시작해서 아직 스터디가 마무리되지도 않은데다 플러터에 대해 뭐가 뭔지 모르는 상황이라 코멘트하기는 어렵지만, 재미있을 것 같다는 느낌이 든다. 아이디어 노트에 모바일 앱과 관련된 것들도 꽤 있는데, 이 도구를 통해 재밌는 서비스를 만드는 계기가 됐으면 좋겠다.

재택근무

나는 입사 때부터 지금까지 원격 근무를 하고 있다. 처음 입사할 당시에는 아직은 코로나가 한창일 때였기 때문에 어찌 보면 당연한 근무 정책이라고 받아들였지만, 그로부터 2년이 넘게 지난 지금은 그때와는 상황이 많이 달라져 재택근무가 당연하다고는 말하기 어려워졌다. 듣기로는 코로나가 시들해지면서 많은 기업에서 재택근무를 철회하고 기존의 전일출근제로 돌아가는 분위기로 알고있는데, 같은 시기에 내가 근무하고 있는 회사에서는 최소 주 2회 이상 사무실로의 자율 출근 방식과 전면 재택 근무 방식을 선택할 수 있도록 정책이 시행되었고, 나는 계속해서 재택근무를 선택해서 근무하고 있다.

그렇게 결정하게 된 배경에는 어떤 생각들이 작용했을까. 솔직하게 입사때부터 계속 해오던 관성이 아예 영향을 주지 않았다고는 하기 어려울 것이다. 그리고 출근 전 준비 시간, 출퇴근 이동시간, 퇴근후 정리시간 모두 없이 씻지도 않은 채 일을 할 수 있다는 시간적인 이점 또한 한 몫 했다고 할 수 있다. 사실 조금 더 구체적으로 생각해보면 담당하고 있는 업무와 관련된 대부분의 요소들에서 대면이 꼭 필요하다거나 대면으로 했을 때 더 생산성이 올라가는 것도 아니고, 개인적인 성향상 업무 집중도가 사무실에서 유의미하게 올라간다거나 하는 것도 아니었고, 업무와 관련된 동료들 또한 대부분이 원격 혼합 형태로 근무를 하고 있었기 때문에 사무실에 나간다고 업무적인 상호작용의 정도가 올라가는 것도 아니었기 때문에 앞서 언급한 재택근무의 장점들을 애써 무시하고 출근을 할 이유가 딱히 없었다고 정리할 수 있을 것 같다.

그렇다면 이쯤에서 나는 과연 재택 근무를 “잘” 하고 있을까? 일단 재택근무로 인해 업무를 수행함에 있어서 불편함을 겪은 적이 없고 업무 집중도 차이도 크게 느끼지 못하고 있기 때문에 근무 시간 자체는 나름 재택 근무로도 잘 풀어가고 있다고 느끼는데, 재택근무를 통해 앞서 언급한 것처럼 출근에 비해 얻는 시간적 이득이 어마어마하게 많음에도 이를 장점으로써 제대로 활용하고있지 못한 것 같다. 이처럼 재택근무를 잘 한다는 것은 단지 업무 효율 측면에서 사무실에서와 큰 격차 없이 업무를 수행하는 것에 그치는 것이 아니라, 재택근무를 통해서 얻을 수 있는 시,공간적 이점을 극도로 활용하여 업무 뿐만 아니라 개인의 성장에 녹여내는 것이 아닐까 하는 생각이 든다.

지금까지는 항상 업무 시작 직전에 일어나거나, 퇴근해야할 시간에 업무가 늘어져 비생산적으로 야근을 하게 되는 등, 생활 측면에서 재택근무를 제대로 활용하지 못한 역풍을 그대로 맞고 있었는데, 앞으로는 평상시에도 사무실에 출근을 하는 것처럼 생활 패턴을 재조정해나가는 것이 우선적인 목표로 삼아야겠다는 생각이 들었다. 이 근무 제도가 언제까지 이어질 지도 모르는 일이고, 무엇보다 다른 기업으로 이직을 염두에 둔다면 사무실로 출근하는 환경에 더 익숙해지는 것이 장기적으로 나에게 득이 될 것이라고 생각된다.

회사 밖에서

사이드 프로젝트

언제부터인지 정확히 기억은 나지 않지만, 어떤 아이디어가 떠오르면 구체화시켜볼 가치가 있겠다는 생각이 들 때에는 그 생각이 휘발되기 전에 메모하는 버릇이 생겨 그렇게 하나하나 적어둔 아이디어가 지금까지 가지각색으로 이렇게나 많이 쌓였다.

공개하기는 민망하지만, 사소한 생활 속 문제 해결을 위한 아이디어부터 훗날 사업으로 뛰어들어보고 싶은 아이디어까지 다양하다.

개인적으로 개발자 실무를 처음 제대로 입문하게 되었던 산학 연계 인턴십을 수행할 당시에도 직접 체감했고, 지금도 그렇다고 생각하는건 확실히 개발 실력은 직접 뭔가 만드는 과정에서 가파른 성장을 할 수 있다는 것이다. 인턴십 당시 나는 학교 수업을 통해 갓 HTML, CSS, JS의 기초정도만 배운 수준이었고 입사 직전에 React 튜토리얼을 수강하고 그것을 완전히 이해도 하지 못한 상태였는데, 내 앞에 놓여진 문제를 어떻게 하면 해결할 수 있을까를 치밀하게 고민하고 그 문제를 나름의 방법으로 어떻게든 해결해나가는 과정에서 단지 문제 해결 능력 뿐만 아니라 거기에 사용한 기술의 숙련도가 빠르게 성장할 수 있었다.

물론 이와 별개로 나중에 깨닫게 된 것이지만, 위에서처럼 직접 부딪히는 경험에서 숙련도는 성장할 수 있겠으나 그 기술에 대한 깊은 이해도를 갖는 것은 전혀 다른 차원의 문제이다. 이러한 실전 경험을 통해 성장할 수 있는 스킬적인 면은 어느정도 제한적이라고 보이고, 그 이상의 수준에 도달하기 위해서는 어찌 보면 당연한 말이지만 그 기술의 바탕이 되는 제반 지식과 개념을 조금은 깊게 공부할 필요가 있겠다. (나는 개인적으로 이를 좀 늦게 깨달은 편인 것 같다.)

올해에는 개인적으로 프로젝트를 하나쯤은 꼭 해야겠다는 생각에, 메모에 적어둔 여러 아이디어들 중 하나인 로또 복권 응모 번호를 생성해주는 웹사이트를 채택해서 개발을 시작했다. 개인적으로 로또 복권을 소액으로 종종 구매하기도 하고, 어차피 자동 복권을 구매할 거면 내가 직접 랜덤으로 추출한 번호를 수동으로 구매해도 좋을 것 같다는 생각에서 출발했다. 화면 설계와 디자인, 세부 기능과 관련된 기획도 직접 하고, 라이브러리를 사용하면 간단한 컴포넌트들도 직접 만들어보는 등 과정에서 다양한 문제를 마주하고 나름대로 해결하면서 진행하고 있다. 4분기에 들어서 본격적으로 작업에 들어가다보니 아직 초반에 생각했던 완성 단계에는 접어들지 않아서, 이 프로젝트에 대한 구체적인 개발 후기는 작업이 어느정도 마무리가 됐을 때 따로 정리해야겠다. (웹사이트, Repo)

올해도 메모장에 잠자고 있는 아이디어를 최소한 1개 이상은 세상 밖으로 내놓기 위해 노력할것이며, 가능하다면 이를 통한 수익화도 꿈꾸고 있다.

커리어 관리

구체적으로 어떤 특별한 계기가 있었던 것은 아니지만, 현재 재직중인 회사에 입사한 뒤부터 어느정도 담당하던 굵직한 프로젝트가 마무리되거나 직무 관련 새로운 경험을 하게 되면 그 때마다 이력서에 관련된 내용을 정리해서 업데이트하고 있다. 사실 초반엔 근시일 내에 다른 회사로의 이직을 대비하기 위해 작성했던 것 같은데, 이제는 그런 것도 일부 있지만 나중에 적으려고 하면 기억이 선명하지 않을 것이 뻔하기 때문에, 내가 맡았던 일을 까먹기 전에 조금씩 정리해두는 목적이 더 커진 것 같다. 월별, 분기별 회고 형태로 글로써 정리하면 더 좋겠지만 이력서 정리를 통해 어느정도 대체하고있는 것 같다. 앞으로는 짧은 단위의 회고도 작성하려고 노력할 필요가 있겠다는 생각이 든다.

이력서는 이전에는 본 블로그의 템플릿에 포함되어있는 마크다운 파일을 기반으로 작성하곤 했는데, 텍스트나 화면 스타일을 일부 내 입맛에 맞게 수정하고 싶거나 할 때 대응이 번거로운 등의 불편함이 있어 우선은 임시로 Notion으로 이력서를 관리하고 이를 pdf로 추출해 사용하고 있다. 가까운 미래에 직접 블로그 스타터를 제작하고 싶어 계획중에 있는데, 그 스타터 내에 나름대로 고민을 녹여 나만의 이력서 웹사이트를 만들어 정착하고 싶다. 현재는 Notion 이력서에 업데이트하는 내용을 동일하게 다른 채용 및 헤드헌팅 플랫폼(LinkedIn, 프로그래머스, 원티드, 리멤버 등)에도 동일하게 업데이트하고 있는데 사실 매번 여러개를 하나씩 업데이트하는 것이 좀 번거로운 부분이 있어 사용하는 플랫폼 개수를 줄이거나 더 나은 관리 방법이 있을지 고민하고 있다.

이력서를 정리하는 것에 그치지 않고 내가 현재 채용시장에서 경쟁력이 있는지, 반대로 현재 채용시장이 어떻게 돌아가고 있는지 파악하기 위해 올해에도 여러 공고에 지원서를 넣어봤고, 그 중 두 개의 공고에서는 면접까지 진행했었다. 그 과정에서 깨달은 점 두 가지 중 하나는 내가 작성한 이력서가 생각외로 효과가 있었다는 것이고, 다른 하나는 내가 면접에서 굉장히 취약하다는 점이었다. 기술 면접에서 요구되는 지식에 부족한 부분이 은근히 적지 않고, 그나마 알고있는 지식조차 긴장을 너무 많이 하는 탓에 그마저도 제대로 대답하지 못한다는 것을 알게 됐다. 이런 소득이 있었으니 앞으로는 그와 관련된 부분을 보완하는 데 노력을 기울여야겠다.

블로그

블로그는 왠지 모르게 항상 마음 한켠의 빚처럼 느껴지는 활동이다. 내가 겪은 문제 해결 경험들을 글로 정리하는 것으로 스스로의 성장에 도움이 된다는 점이 매력적이지만, 그만큼 잘 정제된 글을 결과물로 도출해내야 한다는 부담감이 역설적으로 그 행동을 실천함에 있어 큰 방해요소가 되기도 하는 것 같다. 그런 부분에 있어서는 그나마 다행이라고 해야할지, 올 해에는 두 개 정도의 포스트를 등록했다.

어떤 분들은 블로그를 운영하면서 좋은 포스트를 많이 작성하고 많은 방문자를 유입시켜 광고 수익까지 올리는 분들도 있지만, 나는 아직 그정도의 그릇은 되지 못하는 것 같다. 그래도 이 활동을 놓지 않고 이어간다는 그 자체에 방점을 두고 내년에는 그래도 올해보다는 더 많은 포스트를 등록하기 위해 노력해야겠다는 생각을 한다.

올해 목표 점검

(모 대기업)으로 이직
(모 대기업 근처 동네)의 투룸으로 이사

막상 이렇게 다시 적어놓고 보니까 너무 부끄럽지만 올해에는 너무 비현실적인 목표를, 그리고 너무 단순하게 잡았던 것 같다. 사실 어찌보면 목표에 대해 크게 신경쓰지 않았던 것 같기도 하다.
결과는 물론 이직도 실패했고, 그 기업 주변으로 이사하지도 못했다. 일단은 무엇보다 산업 전반에 깔린 경제적으로 좋지 않은 분위기의 영향으로 해당 기업에 내가 원하는 포지션의 공고가 열리지/도 않았고, 계획(보다는 희망사항)을 세울 때에는 이런 부분을 고려는 커녕 상상조차 하지 못했다.

한 해를 이렇게 다 보내고 난 뒤에 목표를 다시 보니 이렇게 허탈할 수가 없다. 그래도 목표를 이런 식으로 잡으면 큰 의미가 없다는 것을 이번에 깨달았으니 앞으로는 나에게 의미있는 목표를 더 잘 세울 수 있는 방법을 고민해나가야겠다.

내년 목표

그런 의미에서 내년에는 조금 더 구체적이고 명확한, 그리고 실현 가능한 수준으로 목표를 잡아보고 싶다.

아침형 인간 되기
- 지금까지는 일어난지 30분도 안돼서 업무를 시작하는 경우가 많았다.
- 최소한 평일에는 8시 이전 기상해 아침 시간을 활용하자.
월 초과근무시간 20시간 미만으로 줄이기
- 올해에는 일이 많았던 탓도 있지만 너무 일하는 시간을 효율적으로 사용하지 못한 결과 업무 시간이 늘어져 야근이 잦았고, 그로 인해 초과근무를 많이 할 수밖에 없었다.
- 내년에는 실제로 바빠서 일을 많이 하는 것은 어쩔 수 없겠지만 업무시간을 최대한 효율적으로 활용해서 불필요한 야근을 줄이자.
영어 회화 공부하기
- 영어 실력은 지금보다 더 나이가 들기 전에 수능영어를 벗어나는 수준으로의 성장시켜야 한다고 생각하기 때문에 내년에는 회화 공부를 시작하자.
나만의 블로그 만들기
- 현재는 다른 개발자가 제작하신 Gatsby 스타터를 커스텀해 블로그를 운영하고 있다.
- 이 또한 사이드 프로젝트의 일환으로 나만의 블로그 스타터를 만들어 배포하고 내 블로그도 옮겨보자.
1개 이상의 사이드 프로젝트로 상용 프로덕트 만들기
- 올해 제작한 프로젝트는 수익화가 어려웠는데, 내년엔 처음부터 수익화가 가능한 구조로 시작해보자.
10권 이상 독서하기
- 올해에는 밀리의서재를 통해서 6권 정도의 책을 완독했다.
- 내년에는 소유하고 있는 종이책을 포함해 10권정도 완독을 목표로 하자.
회고 더 자주하기
- 지금까지는 너무 오랜 기간 텀을 두고 내 인생을 회고하고 있다고 생각된다.
- 앞으로는 지금보다는 더 자주 돌아보며 살자. (최소 분기별)
구직활동에 더 적극적으로 임하기
- 지금까지는 소위 말해 회사와 나의 상호간의 전투력 측정 개념에서 지원했다면
- 내년에는 정말 합격해서 이직을 하겠다는 마음가짐과 그에 맞게 준비해서 지원하자.
일주일에 운동 더 자주하기
- 올해에는 바쁘단 핑계로 가까운 거리의 헬스장도 주 2회 가는 것이 최대였다.
- 내년에는 주 4회까지 횟수를 끌어올리고, 이를 달성하지 못하는 주간을 최대한 줄여보자.
편의점 가공식품 섭취 줄이기
- 재택근무를 하는동안 식사를 간단하게 하고 싶은데 마땅한 방법이 없어 거의 매 끼니를 편의점 음식에 지금까지 너무 많이 의존해왔다.
- 내년에는 이를 대체할 최대한 비용, 노력이 최적화된 레시피로 직접 요리해먹자.

마치며

개인 생활에 대한 회고도 포함하고 싶었지만, 분량상 이미 너무 텍스트가 많기도 하고 다시 생각해보니 전체적인 문맥에 어울리지 않는다고 생각해 개인 노트에만 정리하고 포스트에는 제외하였다.
2024년 이맘때에는 지금보다 조금 더 나은 사람이 되어 지금은 미래인 한 해의 시간들을 뿌듯하게 돌아볼 수 있었으면 좋겠다.

Adieu 2023.

React에서 textarea의 입력 길이를 제한할 때 고려할 점

Mon, 21 Aug 2023 01:09:26 GMT

사건의 발단

얼마 전, 현재 소속된 조직에서 준비중인 신규 프로젝트에서 베타 오픈을 위해 사내에서 도그푸딩을 진행했는데, 그 때 올라온 이슈 중에서 100자까지만 입력이 가능한 <textarea>에 이미 입력된 텍스트의 중간에서 입력을 시작해 최대 길이에 도달하면 입력 커서가 텍스트의 맨 뒤로 밀려나는 현상을 발견했는데 이것이 의도된 스펙인지에 대한 질문을 발견하게 되었다.

당시 해당 현상이 입력 요소의 동작으로써 적절하지 않다고 판단했던 나는 해당 이슈를 담당하기로 결정하고 원인 파악을 위해 해당 <textarea>를 제어하는 코드를 살펴보기로 했고, 대략 아래와 같이 작성되어 있었다.

// 이벤트 핸들러
const handleChange: ChangeEventHandler<HTMLTextAreaElement> = e => {
  if (e.target.value > MAX_LENGTH) {
    return
  }
  setValue(e.target.value)
}

// JSX
return (
  <textarea
    // ...
    onChange={handleChange}
  />
)

위 코드를 확인하고 나서 이런 생각을 하게 되었다. “어? <textarea>에는 글자수를 제한하는 내장 prop이 있는데도 왜 핸들러에서 조건 처리를 하고 있지?” 의식의 흐름에 따라 그대로 코드를 바꿔보기로 했다.

const handleChange: ChangeEventHandler<HTMLTextAreaElement> = e => {
  setValue(e.target.value)
}

return (
  <textarea
    // ...
    maxLength={MAX_LENGTH}
    onChange={handleChange}
  />
)

변경한 코드는 기존에 발견한 문제점을 깔끔하게 해결해주었다. 입력된 텍스트의 중간에서 타이핑을 시작해 텍스트의 최대 길이에 도달하더라도 커서가 뒤로 밀려나는, 당초 검증의 대상이었던 현상이 더 이상 재현하지 않았고, 수차례 여러 방식의 문자열을 입력해 테스트해보아도 특별히 문제가 없는 것처럼 보였기 때문에 변경한 코드를 저장소에 그대로 반영했고, 이슈를 잘 처리했다고 생각했다.

결과적으로 처음 문제삼았던 현상은 해결되었지만 그 문제를 처리하는 데에만 집중한 나머지 그 결과로 인해 영향을 받을 수 있는 부분을 살피지 못하고 지나쳐 개발서버에 배포된 이후에야 수정된 코드로 인한 새로운 문제를 발견하게 되었다. 사실은 아무 문제가 없는 것이 아니라 그만큼 애초에 꼼꼼히 살펴보지 않았던 탓이다.
간단한 문제라고 해서 간단히 해결되리란 법도 없고, 현재 조명한 문제가 해결된다고 해서 다른 문제도 없다는 뜻이 되진 않는다.
이런 식의 일처리는 반성할 필요가 있다고 느꼈고, 앞으로는 간단해 보이는 이슈를 다루더라도 이런 부분에 주의하며 업무에 임해야겠다는 생각을 하게 되었다.

새로운 국면

해당 코드가 개발서버에 배포된 이후 해당 이슈의 기대결과가 정상적으로 동작하는지 확인하기 위해 배포 환경에서 몇 가지 테스트를 하던 도중, 작업하면서 테스트할 당시에는 발견하지 못했던 현상이 발생하는 것을 알게 되었다.

예시로 만든 위 gif에서 보이는 것처럼 10글자 제한이 있는 <textarea>에서 숫자, 알파벳을 입력할 때에는 아예 입력이 되지 않다가, 한글을 입력하니 최대 길이 제한을 무시한 채 입력이 가능했다. 물론 한글자 이상을 작성하려고 하면 매 글자마다 초기화가 되긴 하지만, 커서를 마우스 클릭으로 강제로 이동시켜가며 자음만 입력할 경우에는 위 예시에서처럼 몇글자가 되었든 최대 글자수 이상을 입력할 수 있었다.

우선은 발견 직후 이 동작 자체도 정상적이지 않다고 판단해 추가로 수정작업이 필요하다는 생각이 들었다.
하지만 어떻게 해결하는 것이 좋을까? 그것에 대해서는 여전히 의문이었다. textarea의 최대 길이 제한과 관련하여 여러 자료를 찾아보았지만 대부분 숫자, 알파벳과 한글의 byte 수 차이에 의한 글자 수 카운트 방식에 대한 이야기이거나, 핸들러에서 글자수를 넘어가면 slice 혹은 substring으로 처리하는 방식(하지만 이렇게 처리하게 되면 중간에서 입력 시 뒷부분이 삭제됨)이 대부분이었다.

그래서 결국은 입력 엘리먼트의 글자수 제한에 대해서 생각할 수 있는 모든 경우의 수를 실험해보자는 결론에 도달하게 되었다.

입력 엘리먼트 최대 길이 제한 실험

현재까지 주어진 현상들을 바탕으로 봤을 때, 최대 길이가 입력된 상태에서 어떤 조건 하에서 한글 입력이 가능하거나 불가능한지, 또 어떤 조건 하에서 커서가 밀리거나 밀리지 않는지를 비교하기 위한 대상이 되는 케이스들을 정리해보니 아래와 같았다.

비제어 <input> 컴포넌트
제어 <input> 컴포넌트 - maxLength
제어 <input> 컴포넌트 - onChange
비제어 <textarea> 컴포넌트
제어 <textarea> 컴포넌트 - maxLength
제어 <textarea> 컴포넌트 - onChange

그러면 각각을 실험해보고 결과를 한 번 살펴보도록 하자.

1. 비제어 `<input>` 컴포넌트

비제어 컴포넌트, 즉 React 단에서 변경되는 사용자 입력을 직접 관리하지 않는 컴포넌트는 다시말해 곧 HTML 엘리먼트 그 자체를 의미한다고 볼 수 있다. 앞서 살펴본 현상들이 React 환경에서 상태 관리와 이벤트 핸들링을 담당해서 발생했다고 의심해볼 수 있기 때문에 상태 관리 없이 순수한 상태의 엘리먼트는 어떤 현상을 보여주는지 궁금해서 실험 대상에 포함하게 되었다.

<input
  type="text"
  id="UnControlledInput"
  maxLength={10}
  defaultValue="qwerqwerqw"
/>

그래서 HTML <input> 엘리먼트의 기본 동작을 살펴보기위해 최대 길이를 지정하고 기본값으로 10글자의 무작위의 문자열을 설정한 뒤 테스트를 진행했다.

결과는 gif에서 확인할 수 있듯이 한글을 입력하면 똑같이 입력창에서 보이는 값이 변하지만, 위에서 경험했던 케이스와는 다르게 blur 이벤트를 비롯한 다른 이벤트가 발생하면 다시 원래 값으로 돌아가는 모습을 보여준다.

2. 제어 `<input>` 컴포넌트 - maxLength

다음으로는 같은 <input> 엘리먼트이지만 React에서 값 상태를 관리하는 구조를 가진 제어 컴포넌트를 살펴볼텐데, 위에서 살펴본 것과 동일하게 단순히 maxLength 속성에 의한 10글자 제한과 10글자의 기본 상태만을 설정한 뒤 테스트를 진행했다.

const [inputTxt, setInputTxt] = useState('1234123412')
// ...
return (
  <input
    type="text"
    id="ControlledInput"
    maxLength={10}
    value={inputTxt}
    onChange={e => {
      console.log(e.target.value)
      setInputTxt(e.target.value)
      console.log('onChange triggered!')
    }}
  />
)

결과를 보면, 제어 컴포넌트도 비제어 컴포넌트의 케이스와 동일하게 처음 입력창에 보이는 값이 변했다가, blur 이벤트가 발생하자 다시 원래 값으로 돌아가는 모습을 보여줬다.

그래서 이번 케이스에서는 이 동작이 어떻게 돌아가는지 조금 더 자세히 확인해보고자 핸들러에 로그를 찍어봤는데, 이미 입력값이 최대 길이인 상태에서 한글을 입력하자 onChange 이벤트 핸들러가 실제로 실행이 되고, 그 이벤트의 실행 값인 e.target.value에 한글을 포함한 문자열도 실제로 들어오는 것을 확인할 수 있었다.
나아가, 대상 <input>에 focus를 해제할 경우 다시 한번 더 onChange가 실행되면서 그 실행값으로 직전 실행으로 한글이 포함되기 전 초기 상태값이 다시 입력되는 것을 확인해볼 수 있었다. 그리고 e.target.value가 위처럼 변화함에 따라 이벤트 핸들러 동작에 의해 setInputTxt 함수도 각각 실행되어 inputTxt의 상태값도 두 차례 변경되는 모습 또한 확인할 수 있었다.

이를 짧게 정리해보면, <input> 엘리먼트는 maxLength 속성을 통해 입력 길이를 제한할 수 있지만 한글 입력 시 onChange이벤트가 실행되고, 이를 교정하기 위해 blur 등 다른 이벤트가 발생했을 때 다시 직전 onChange 발생 이전의 값으로 onChange가 한번 더 실행되어 최대 길이를 초과하지 않도록 제어한다고 볼 수 있겠다.

3. 제어 `<input>` 컴포넌트 - onChange

이번 케이스는 본 글의 발단에서 설명한 기존 코드에서처럼 제어 컴포넌트로 구성을 하되, onChange 이벤트 핸들러에서 직접 현재 입력된 길이를 최대 길이와 비교해 작을 때에만 상태 업데이트가 이뤄지도록 하는 방식으로 구성해 테스트를 진행했다.

const [inputTxt2, setInputTxt2] = useState('abcdabcdab')
// ...
return (
  <input
    type="text"
    id="ControlledInput2"
    maxLength={10}
    value={inputTxt2}
    onChange={e => {
      console.log('onChange triggered!')
      if (e.target.value.length > 10) {
        return
      }
      setInputTxt2(e.target.value)
    }}
  />
)

조건문 이후의 라인이 실행되기 이전까지는 2번 케이스와 다를 것이 없기 때문에 동일하게 onChange 이벤트 자체는 실행은 되지만 가장 처음 이슈라고 판단했던 입력 커서가 맨 뒤로 밀리는 현상이 똑같이 나타났는데, 사실 이 커서 밀림 현상에 대해서 설명할만큼 명확한 근거는 아직까지 잘 모르겠다.
다만 그래도 추리를 해보자면 2번 케이스에서 정리한 것처럼 onChange 이벤트가 두 번 실행되는데, 초과된 길이의 문자열을 value로 갖는 첫 번째 이벤트가 실행될 때에는 조건문에 의해 중간에 종료되지만, 초기값 문자열을 value로 갖는 두 번째 이벤트는 setInputTxt2까지 정상적으로 실행되므로 입력 커서가 문자열의 끝으로 밀려나게 되는 것이라고 생각해볼 수 있을 것 같다.

4. 비제어 `<textarea>` 컴포넌트

이번에는 1번 케이스와 마찬가지로 React에 의한 상태 제어를 받지 않는 기본 HTML <textarea> 엘리먼트와 동일한 형태이다. 사실 본 글이 시작한 출발점이 <textarea> 엘리먼트의 동작 관련된 부분이었기 때문에 이 이후의 결과가 가장 중요하다고 볼 수 있겠다.

<textarea
  id="UncontrolledTextArea"
  maxLength={20}
  defaultValue="qwerqwerqwerqwerqwer"
/>

결과는 기대했던대로 1번 케이스의 결과와 동일하다. React에 의한 제어가 포함되지 않은 경우에는 <input>이든 <textarea>든 무관하게 최대 길이를 초과하는 입력 이벤트를 교정하도록 설정되어있는 것으로 추측된다.

5. 제어 `<textarea>` 컴포넌트 - maxLength

사실상 이번 실험의 주인공이면서, 새로운 국면에서 확인했듯 의아한 동작을 보여주는 케이스이다. 앞서 문제를 발견하면서 어떻게 동작하는지 확인했지만 다시 한번 더 동작을 살펴보자.

const [areaTxt, setAreaTxt] = useState('12341234123412341234')
// ...
return (
  <textarea
    id="ControlledTextArea"
    maxLength={20}
    value={areaTxt}
    onChange={e => {
      console.log(e.target.value)
      setAreaTxt(e.target.value)
      console.log('onChange triggered!')
    }}
  />
)

결과는 역시 겪었던 대로, 예상했던 대로 동일한 모습을 볼 수 있다. 그런데 원래대로라면 대응되는 2번 케이스, 즉 제어 <input>과 동일하게 동작하는것을 기대해볼 수 있었는데, 로그와 함께 살펴보면 2번 케이스와 다르게 길이를 초과한 입력이 반영된 직후에 초기값으로 교정되는 두 번쨰 onChange 이벤트가 실행되지 않고 처음 길이를 초과되도록 입력한 동작 1회에만 실행되는 것을 확인할 수 있었다.

다만 아쉬운 점은 이 역시 동일한 제어 컴포넌트이더라도 <input>과 <textarea> 각각 최대 길이를 초과하는 한글 입력에 대해서 처리 방식이 다르다는 사실 자체를 육안으로 확인해볼 수는 있었으나 이 둘이 구체적으로 어떤 이유에 의해서 이런 차이를 나타내고 있는지에 대한 근거는 관련된 자료를 찾아보거나 추측해보기가 조금 어렵다는 것이다.

이와 관련된 구체적인 근거 자료를 찾게 된다면 추후에 후속 포스팅을 작성할 예정이다.

6. 제어 `<textarea>` 컴포넌트 - onChange

마지막으로 3번 케이스에 대응되는 케이스이다.

const [areaTxt2, setAreaTxt2] = useState('abcdabcdabcdabcdabcd')
// ...
return (
  <textarea
    id="ControlledTextArea2"
    maxLength={20}
    value={areaTxt2}
    onChange={e => {
      console.log('onChange triggered!')
      if (e.target.value.length > 20) {
        return
      }
      setAreaTxt2(e.target.value)
    }}
  />
)

이 케이스에서도 역시 결과는 겪었던 대로, 예상했던 대로 동일한 모습을 볼 수 있었다. 여기에서의 커서 밀림 동작에 대한 근거도 3번에서 추측했던 것과 동일하게 적용해도 무방할 것으로 보인다.

결론

결과적으로 실험을 통해 얻어낼 수 있었던 것은, 구체적인 이유는 밝혀내지 못했지만 <textarea>를 React적으로 다룰 때 발생하는 HTML에서와의 기본 동작 차이에서 비롯한 현상이라는 점이다. 그런데 글자수가 제한된 <textarea> 를 어찌됐든 사용해야 하는 입장에서 이에 대한 완벽한 해결책이 아직까지 없다는 사실은 결국 한글이 입력이 가능하도록 하든지 문장 중간에서 타이핑을 하더라도 최대 길이 도달 시 입력 커서가 맨 뒤로 가도록 하든지 둘 중에 한 가지를 선택해야 한다는 것을 의미한다.

따라서 둘 중에 하나를 굳이 골라야 한다면, 지금까지 살펴본 것처럼 maxLength 속성이 적용되었음에도 길이를 초과해 한글이 입력되고 다시 원상복구 되지 않는 현상이 단순히 커서가 입력값의 맨 끝으로 이동하는 현상보다는 실 서비스에서 더 큰 문제를 발생시킬 여지가 크다고 판단해서 결국은 다시 6번 케이스처럼 이벤트 핸들러 내부에서 길이를 비교하는 조건을 활용하는 초기 코드로 롤백하게 되었다.

여담

지금까지 살펴본 엘리먼트들이 결국 form 관련 엘리먼트들이다보니 간단한 비교를 위해 프로젝트에서 사용하던 react-hook-form 라이브러리의 로직이 적용된 컴포넌트를 살펴봤더니 같은 제어 <textarea> 컴포넌트이더라도 비제어의 케이스에서와 같이 최대 길이를 초과한 한글 입력이 다시 교정되는 것을 볼 수 있었다.

이 라이브러리에 대해서 자세히 다루기에는 분량이 난감하지만, 간단하게 설명하자면 이 라이브러리에서 제공하는 Form 내에 각 항목별 입력 요소들, 즉 여러 타입의 <input> 및 <textarea>를 제어하는 props를 생성하는 register라는 함수의 반환값을 살펴보면, 내부에 직접 별도의 로직으로 구현된 onChange 가 존재하고, onBlur함수에 onChange함수가 할당되어있는 것을 볼 수 있다. (코드 링크)

<input id="title" {...register('title')} />

간단한 예시로, register 함수는 위와 같이 사용되기 때문에 자연스럽게 본문에서 추리했던 것과 같은 2번의 onChange 이벤트 핸들러가 첫 차례에는 실제 change 이벤트, 두 번째는 blur 이벤트에 의해서 실행되는 것은 아닐지 또 추측해볼 수 있을 것 같다. 따라서 React에서 form을 다룰 때, 이 라이브러리를 사용한다면 웬만한 경우 본문과 같은 이슈를 겪을 일이 없을 것으로 생각되지만, 이 이슈를 작업한 컴포넌트는 단순히 단 하나의 <textarea>만 존재하는 스펙의 사용자 입력이었기 때문에 해당 라이브러리를 사용하는 것 자체가 불필요하게 컴포넌트 사이즈와 관리 포인트를 늘리는 것 같다고 판단해 단순한 방식으로 처리하는 것으로 결론을 지었다. (이 라이브러리에서 제공하는 로직을 사용하기 위해서 Form을 다루는 대상 컴포넌트 내부에 작업해줘야 할 보일러플레이트 코드가 생각보다 적지 않은 편이다.)

(번역) 최고의 성능을 위한 Next.js 애플리케이션 아키텍처

Tue, 28 Feb 2023 13:07:57 GMT

원문: NextJs Application Architecture for best performance

이 글에서는 아와 같이 여러 섹션으로 구성된 Next.js 애플리케이션의 고수준 아키텍처 설계에 대해 기술합니다.

초기 요청
Next-React 애플리케이션의 API 호출
보안 계층의 인증 및 사용
로드 시간 및 SEO
배포 아키텍처

개요

개별 설계에 대해 더 깊게 알아보기 전에, 고수준에서 몇 가지 알아두어야 할 사항들이 있습니다.

위 그림은 세 가지 섹션으로 구분할 수 있습니다.

네트워크 계층 (요청이 애플리케이션에게 응답하는 방식)
Next 애플리케이션 인스턴스와 SSR
외부 서비스

1. 네트워크 계층

이 섹션에서는 사용자가 웹사이트를 요청할 때 요청이 서버로 이동하는 방법과 사용해야 하는 프로토콜에 대해서 설명합니다.

사용자가 애플리케이션을 요청하면 요청을 로드 밸런서로 보내야 합니다.
로드 밸런서를 통해 요청이 웹사이트 HTML 콘텐츠를 로드하기 위한 것이라면 요청을 애플리케이션 서버로 보내고, 관리자 패널에서 업로드한 이미지, 빌드 파일, 폰트 등과 같은 정적 콘텐츠를 로드하기 위한 요청인 경우에는 요청을 CDN으로 보내고 컨텐츠를 CDN에서 로드해야 합니다.

이러한 방식으로 우리는 엣지 로케이션에서 모든 정적 콘텐츠를 전달할 수 있을 것이며, 애플리케이션 서버의 정적 부하 요청을 줄일 수 있을 것입니다.

두 경우 모두 HTTP/2 또는 HTTP/3를 사용해야 하며, HTTP/2보다 HTTP/3이 더 선호됩니다.

2. Next 애플리케이션 인스턴스와 SSR

이 섹션에서는 애플리케이션 코드와 작동 방식에 대해 설명합니다.
모든 요청은 들어오는 어떤 요청이든 캐싱하는 next-boost 캐시 커스텀 서버를 거치게 됩니다.
next-boost를 사용하는 이유는 SQLite 데이터베이스에서 실행되는 고성능 라이브러리이기 때문입니다.
결과적으로 처리량이 매우 높으며, 이 계층을 쉽게 구성할 수 있습니다.
요청은 주로 서로 다른 5가지 유형의 요청으로 구성됩니다.

페이지 요청은 대부분 Next 애플리케이션이 모든 리소스들을 로드하고 요청된 페이지의 HTML 단계의 페이지를 생성하는 SSR 요청입니다.
HTML과 함께 로드할 동적 데이터가 필요한 경우 Next.js의 메소드 중 하나인 getServerSideProps를 사용해야 합니다.
이 요청은 사용자가 한 페이지에서 다른 페이지로 변경할 때 만들어지며, 두 번째 페이지에 getServerSideProps가 포함되어 있으면 이 요청이 만들어집니다.
next-boost는 이 요청을 캐싱하지 않으므로 이러한 코드를 위해 redis 캐시와 같은 자체 캐시 레이어가 필요합니다.
Next의 API 요청은 Next.js API 정의에 대한 요청이며, 플랫폼이 대부분의 경우 브라우저 수준에서 요청하기 때문에 특수한 케이스가 아니면 일반적으로는 이 계층을 캐싱할 필요가 없습니다.
웹사이트에 로드되는 모든 사진에 대해 next/image를 사용해야 합니다.
Next Image는 인터넷을 통한 전송 시간을 최소화하기 위해 이미지를 특정 크기와 형식으로 트랜스코딩하는 로더입니다.
여기에서 next-boost 캐시를 활성화하고 대부분의 webp 및 avip 형식의 이미지를 지정할 수 있습니다.
파일 요청은 동적으로 정적인 콘텐츠를 제공해야 하는 경우가 아니면 필요하지 않습니다.
이전에 언급했듯이 모든 정적 콘텐츠는 CDN으로 이동되므로 이 경로가 필요하지 않습니다.
그러나 매우 동적이고 정기적으로 자동 업데이트되는 사이트맵을 제공해야 하는 경우에는 웹사이트 자체와 함께 저장해야 할 수도 있습니다.
이러한 경우에 이 경로를 사용할 수 있습니다.

3. 외부 서비스

여기에는 우리가 사용하는 모든 외부 서비스, 예를 들어 DB 엔진, redis 및 기타 Google 클라우드 서비스 등이 포함됩니다.

초기 요청

브라우저와 관련된 단계는 아래와 같습니다.

HTML 마크업
1. 사용자가 웹사이트 URL을 입력하면 브라우저는 첫 번째 초기 페이지 요청을 보냅니다.
2. 로드 밸런서가 그 요청을 수신합니다.
3. 로드 밸런서는 요청을 사용자 지정 서버의 Next 애플리케이션으로 라우팅합니다.
4. 파일이 이미 캐싱된 경우 사용자 지정 서버는 파일을 확인하고 캐싱된 데이터를 반환합니다.
5. 그렇지 않은 경우 Next 애플리케이션을 로드하고 GetServerSideProps와 같은 Next 서버 실행 파일을 실행한 다음 전체 Next 애플리케이션을 로드하고 마지막으로 이 페이지를 HTML로 변환합니다.
6. 파싱된 HTML을 캐싱합니다.
7. 클라이언트로 해당 데이터를 반환합니다.
후속 호출
1. HTML 마크업이 다운로드되어 브라우저에 로드됩니다.
2. 이후 CSS, JS, 폰트, 이미지 등과 같은 모든 필수 파일들을 로드하라는 요청을 보냅니다.
3. 로드 밸런서가 이 요청을 수신합니다.
4. 그 다음 로드 밸런서는 이 요청을 CDN과 같이 파일이 보관되는 스토리지 버킷으로 보냅니다.
5. 애플리케이션 로드밸런서를 우회하여 하위 도메인을 구축하고, CDN을 Storage Bucket에 직접 연결할 수 있습니다.
6. 웹사이트에서 react가 모두 로드되면 클라이언트에서 초기화됩니다.
7. 동적 로딩을 위해 프론트엔드 API 호출이 필요한 경우 react는 호출을 수행하고 데이터를 redux에 저장합니다.
Next 페이지 로딩
1. 사용자가 페이지 A에서 페이지 B로 이동할 떄 두 번째 페이지를 초기화하는 데 필요한 JavaScript가 미리 로드되고, getServerSideProps를 가져오기 위한 API 요청이 생성됩니다.
2. API 요청이 성공하면 다른 모든 동적 JavaScript 콘텐츠와 함께 두 번째 페이지가 표시됩니다.
3. JavaScript 외에도 시스템은 페이지 B에 필요한 이미지 및 정적 콘텐츠를 로드하도록 요청합니다.

Next-React 애플리케이션의 API 호출

API 호출에는 크게 세 가지 유형이 있습니다.

SSR API 호출

SSR API 호출(GetServerSideProps)을 최적화해야 하는 이유는, 자칫하면 애플리케이션의 단일 실패 지점이 될 수 있기 때문입니다.
즉, 직접 링크나 프론트엔드 라우팅이 있는 모든 페이지 방문에 대해 Next.js는 자동으로 API를 호출하여 getServerSideProps를 가져옵니다.
즉, 1000명이 웹사이트를 방문하면 불필요하게 서버 부하가 증가하게 되는 것입니다.

모든 getServerSideProps 요청은 먼저 redis 캐시를 기반으로 하는 캐시 계층으로 이동해 API가 이미 캐싱되었는지 여부를 확인합니다.
API가 캐싱되어 있다면 간단히 데이터를 반환할 수 있으며, API가 캐시되지 않은 경우에 이 요청은 API 계층으로 이동해 외부 API를 호출하고 데이터를 검색합니다.
마지막으로 이 요청에 대한 응답이 프론트엔트로 전송됩니다. 이 방법을 사용하게 되면 하나의 요청만 처리하면 됩니다.

Redux 기반 API 호출

이 섹션을 이해하려면 먼저 두 가지 질문을 제기해야 합니다.

Redux가 왜 필요할까?
왜 react-query나 다른 라이브러리를 사용해 API 호출할 수 없을까?

이 문제에 대한 해답은 Redux가 단순한 API 호출 이상의 용도로 사용된다는 것입니다.
또한 Redux는 전체 애플리케이션 상태와 캐싱 및 수정이 필요한 API 호출을 처리하는 데에 사용됩니다.

예를 들어, 페이지에서 전체 사용자가 만든 모든 콘텐츠를 로드해야 하고, 사용자의 선택에 따라 항목을 정렬해야 할 수도 있을 것입니다.
이 경우 전체 데이터를 프론트엔드에 로드하고 컴포넌트로 가져오기 전에 redux 저장소에서 직접 데이터를 정렬할 수 있습니다.

Redux와 함께 사용할 수 있는 구조는 다음과 같습니다. (상태는 세 가지 영역으로 나뉩니다.)

인증(Auth): 모든 인증 정보를 저장하기 위해
엔티티(Entities): 로컬 상태와 서버 상태를 동시에 추가하고 변경할 수 있도록 서버 표현 데이터(Representation Data)를 저장하기 위해
UI: 모든 UI 관련 상태를 추적하기 위해

API 호출을 하려면 컴포넌트가 모두 API 호출 여부를 결정하는 각각의 액션 생성자(Action Creator)를 거쳐야 합니다.
데이터를 사용할 수 있다면 다시 API를 호출할 필요가 없습니다.

데이터를 사용할 수 없는 경우, 액션 생성자는 API 이벤트를 보내고, API 계층(API Layer)에서는 이를 인터셉트하여 API 호출을 수행하고 적절한 리듀서(Reducer)를 실행하는 데 사용할 것입니다.

리듀서는 저장소 내의 데이터를 처리해서 반환값에 기록합니다.

컴포넌트는 셀렉터(Selectors)를 사용하여 저장소 내에 정의된 redux에서 데이터를 읽어오고 컴포넌트로 반환되기 전에 데이터를 변경할 수 있습니다.

Redux 기반 접근 방식의 또 다른 이점은 API를 사용할 컴포넌트가 로드되기 전에 API를 미리 로드(Preload)할 수 있다는 것입니다.
우리는 그저 액션 생성자를 호출하기만 하면 됩니다.

Redux는 중앙화된 상태관리의 강력함을 가지고 있어 데이터에 대한 어떤 변경사항이 발생하더라도 리스너가 자동으로 업데이트됩니다.

직접, 혹은 캐시된 API 호출

직접적인 API 호출은 왜 필요할까요? Redux 안에 데이터를 저장하고 재사용하고자 하는 경우가 아니라면, Redux를 통해 모든 API를 호출을 수행하는 것은 권장되지 않습니다.
따라서, 우리는 Redux에 데이터를 저장하고 이를 재사용하려는 목적이 아니라면 Redux를 통해 API 호출을 할 필요가 없습니다.

이러한 상황에서는 직접 API 호출을 사용하게 됩니다.

보안 계층의 인증 및 사용

인증 정보를 쿠키나 브라우저 로컬 스토리지(LocalStorage)에 직접 저장하는 방식은 SPA를 다룰 때 많은 이들이 흔히 저지르는 실수지만, 이러한 방식의 문제는 공격자가 이 정보를 매우 빠르게 훔칠 수 있다는 것입니다.

이 문제를 해결하기 위한 최고의 해결책은 암호화된 로컬 스토리지에 저장하는 것입니다. 그러나, 모든 디바이스에 대한 저장 키로 데이터를 암호화하게 되면 공격자는 로컬 스토리지 또는 쿠키 정보를 한 브라우저에서 다른 브라우저로 복사할 수 있으며 동일한 애플리케이션을 실행하는 다른 브라우저에서 데이터를 해독할 수 있게 됩니다. 이는 해결해야 하는 또 다른 문제입니다.

이 문제를 해결하기 위해서는 암호화된 브라우저에서만 볼 수 있는 안전한 데이터 저장 방법을 사용해야 합니다. 이를 가능하게 하기 위해서는 먼저 각 브라우저에 대해 고유한 키를 생성한 다음, 해당 키를 사용해서 복호화해야 합니다. 이를 위해 브라우저의 지문 키(fingerprint key)를 암호화 키로 활용하고 데이터를 보존할 수 있습니다.

API 계층의 보안

이는 프론트엔드에 있어 필수 사항은 아니지만, 전체 API가 악용되지 않도록 보호하기 위해서 필요합니다. 일반적으로, 사용자가 인증 토큰을 받으면 해당 토큰을 사용해 접근할 수 있는 모든 경로에 대해 요청을 보낼 수 있습니다.

이 문제를 해결하기 위해 클라이언트와 서버가 각 요청에 대해 해시 키를 공유하는 보안 환경을 설정할 수 있습니다.

API 계층은 총 네 단게로 구성되며, 첫 번째 단계는 요청 URL을 생성하고 요청 매개변수를 정의하는 API 생성기(Generator)입니다.

두 번째 단계는 이러한 모든 인수를 사용하여 요청 객체를 만드는 것입니다. 일반적으로 요청객체에는 아래에 나열된 필드가 포함됩니다.

URL
Method
Body
Header
User-Agent / 브라우저 지문(fingerprint)
Authorization Token (인증 토큰)

다음 단계에서는 요청 객체를 통해 보안 키를 사용해서 해시 키를 생성하고 실제 요청의 헤더에 필드를 추가한 뒤,

마지막 단계에서는 데이터를 서버로 보내고 동일한 로직을 사용해 서버에서 또 해시 키를 생성하는 것입니다.

공격자는 각 요청의 해시 키가 모든 브라우저와 사용자에 대해 고유하기 때문에 시스템을 공격하기 위해 유출된 토큰을 사용할 수 없으며 애플리케이션만이 유일하게 보안 키를 사용하여 이 해시 키를 생성할 수 있습니다. 따라서 토큰이 유출되더라도 공격자는 시스템을 악용할 수 없게 됩니다.

로드 시간 및 SEO

Next.js를 사용하는 주된 이유는 보통 SEO를 기본적으로 지원하기 위해서입니다. 이런 경우 우리는 SEO 및 로드 시간을 향상시킬 방법을 찾게 됩니다.

서드 파티 라이브러리 서드 파티 라이브러리를 로드하려면 Next.js의 <Script> 태그와 함께 다른 전략을 사용해서 컨텐츠가 로드되기 전에 필요한 라이브러리들을 로드합니다. 다른 모든 라이브러리는

배포 아키텍처

자바스크립트 let 키워드의 스코프와 TDZ

Sun, 26 Feb 2023 22:03:16 GMT

의문의 출발점

최근 모던 자바스크립트 Deep Dive 책의 15챕터 ‘let, const 키워드와 블록 레벨 스코프’를 공부하다 보니 아래와 같은 두 가지 예제를 만나게 되었다.

// 런타임 이전에 선언 단계가 실행된다. 아직 변수가 초기화되지 않았다.
// 초기화 이전의 일시적 사각지대에서는 변수를 참조할 수 없다.
console.log(foo) // (#1) ReferenceError: foo is not defined

let foo // 변수 선언문에서 초기화 단계가 실행된다.
console.log(foo) // undefined

foo = 1 // 할당문에서 할당 단계가 실행된다.
console.log(foo) // 1

let 키워드와 var 키워드와의 차이점 중 변수 호이스팅에 대해 비교하여 설명하는 흐름 중간에 나온 내용으로,

var 키워드는 자바스크립트 엔진에 의해 스코프의 최상단으로 호이스팅 되며 선언과 (암묵적) 초기화 단계가 함께 수행되어 선언 이전에 참조하더라도 오류가 발생하지 않고 undefined를 출력하게 되고, let 키워드는 선언 단계와 초기화 단계가 분리되어 진행되기 때문에 스코프의 시작 지점부터 초기화 단계가 수행되는 변수 선언문 이전까지 변수를 참조할 수 없는 구간이 생기고, 이를 일시적 사각지대, TDZ라고 부른다.

라는 내용을 설명하다가 등장한 예시였다.

아래는 let 변수의 생명주기와 일시적 사각지대, 그리고 TDZ에 대해 설명하는 그림이다. (출처)

이어서, let 키워드로 선언한 변수는 변수 호이스팅이 발생하지 않는 것처럼 보이지만, 실제로는 그렇지 않다는 것을 보여주는 다음의 예제이다.

let foo = 1 // 전역 변수

{
  console.log(foo) // (#2) ReferenceError: Cannot access 'foo' before initialization.
  let foo = 2 // 지역변수
}

let 키워드로 선언한 변수에서 변수 호이스팅이 발생하지 않는다면 전역 변수 foo의 값을 출력해야 하지만, 블록 스코프에서도 최상단으로 호이스팅이 발생하기 때문에, 두 번째 foo에 대한 참조 에러가 발생한다.

그런데 나는 여기서 문득 위 두 예제의 각 #1, #2 에 해당하는 참조 에러의 차이가 왜 발생하는지 궁금해졌다.

위 2가지 예제에서 의문의 핵심이 되는 부분만 축약하면 아래와 같다.

console.log(foo) // ReferenceError: foo is not defined
let foo = 1

// -----

{
  console.log(bar) // ReferenceError: Cannot access 'foo' before initialization.
  let bar = 213
}

한차례 이상 블록으로 래핑된 스코프에서건, 전역 스코프에서건 var 키워드와 달리 전역 객체의 영향을 받지 않는 let 키워드를 사용한 변수에서는 동일한 생명주기와 동일한 TDZ를 가지게 되어야 할 텐데, 출력되는 에러는 동일하지만 메시지가 다르다는 점이 의아했다.

에러 메시지를 각각 내 나름대로 해석해보면

foo is not defined
- foo 라는 변수가 정의되지 않았다, 즉 스코프 내에서 해당 식별자를 아예 찾을 수 없다는 의미.
Cannot access ‘foo’ before initialization
- 위에서 살펴본 것처럼, let 키워드는 선언과 초기화 단계가 분리되어 있기 때문에 호이스팅 이후, 초기화 되기 이전에 참조할 수 없다는 의미.
- 내가 이해한 대로면 이 오류가 발생하는 영역이 TDZ인 것으로 해석된다.

예제의 오류인지 아닌지를 체크해보기 위해 이를 직접 출력해보기로 했다.

콘솔 출력 테스트

Chrome 콘솔

예제와 동일하게 출력된다. 그렇다면 예제가 잘못된 것이 아니라는 얘기가 되는데… 그런데, 위에서 내가 해석하는 메시지의 의미대로 살펴보면 아래의 경우 반증이 된다. 블록 내에서 선언한 블록 스코프 변수를 블록 외부에서 참조하려고 했을 때, 내가 생각한 것처럼 “해당 스코프에서 식별자를 찾을 수 없기 때문에” not defined가 출력되고 있다. 그러면 왜 전역 스코프에서는 “정의되지 않았다” 라는 메시지가 출력되고, 명시적인 블록 스코프 내에서는 “초기화 이전에 접근할 수 없다”고 나오는걸까?

위 결과를 보고 다른 브라우저에서도 동일한 결과를 나타내는지 궁금해서 출력해 비교해보기로 했다.

Firefox 콘솔

내 가설과 동일하게, 블록 여부와 관계 없이 동일 스코프 내의 TDZ 구간에서 초기화되지 않은 변수를 참조할 경우 초기화 관련된 참조 오류 메시지가 발생하고 스코프를 벗어난 영역에서 변수를 참조하려고 하는 경우에는 정의되지 않았다는 메시지가 발생한다.

Safari 콘솔

마찬가지로 Safari에서도 FireFox와 동일하게 지역 스코프인지 전역 스코프인지에 관계 없이 동일 스코프에서 TDZ 구간에 있는 변수를 참조할 때는 초기화 관련 메시지를, 다른 스코프의 변수를 참조하는 경우 정의되지 않았다는 메시지를 출력한다.

Safari에서는 다른 브라우저와 달리 단순 { } 블록은 정상적은 블록으로 인식하지 않는 것 같아 (참조 오류가 아닌 별개의 오류를 뱉음) 정상적인 블록 구문인 if문을 활용해 예시를 출력했다.

혹시나 싶은 마음에 여러 경우의 수를 테스트해봤지만 역시나 전역 스코프에서의 TDZ는 예상했던것과는 다르게 동작하는 것 같았다.

const 키워드의 경우에는 var, let과 달리 변수에 값을 재할당하는 것이 불가능하기 때문에 선언과 동시에 초기화 하는 문이 함께 작성되어야 해서 “Missing initializer”라는 오류를 출력하고 있다. 하지만 정상적으로 초기화된 경우라면 let의 경우와 마찬가지로 전역 스코프에서는 “정의되지 않음”, 블록 스코프에서는 “초기화되지 않은 변수에 접근” 오류가 발생하고 있다.

잠정적 결론

이쯤 살펴보고 나니 처음과 질문이 조금 달라졌다.

왜 크롬에서만 예상했던것과 다르게 동작할까?

위에서 실험해본 것처럼 브라우저마다 콘솔에서 각기 다른 결과와 에러 메시지를 출력하게 되는 것은 브라우저마다 각기 다른 자바스크립트 엔진을 사용하기 때문인데, 크롬은 V8 엔진을 채택하고 있다.

즉, 이는 Chrome 브라우저의 V8 엔진에서 let 키워드의 스코프에 대해서 FireFox의 SpiderMonkey, Safari의 Webkit과는 다르게 처리하고 있다는 것을 의미한다.

이 궁금증을 명쾌하게 해결하기 위해 V8엔진의 코드에서 스코프를 처리하는 부분을 살펴보면 좋을 것 같은데, 나는 V8엔진의 코드가 작성된 주력 언어인 C++에 대해서 잘 알지 못하기도 하고, V8 자체가 워낙 거대한 코드베이스를 가지고 있다보니 쉽사리 뜯어볼 엄두가 나지 않는 것이 사실이다.

우선은 현재는 이 궁금증을 정리한 것으로 만족하도록 하고, 가능하다면 가까운 미래에 V8 엔진의 스코프 관련 에러 처리의 프로세스를 함께 살펴보는 2편으로 돌아오기로 하자.

Comming Someday…

내맘대로 2021년 회고하기

Fri, 31 Dec 2021 01:12:14 GMT

나는 한 해의 끝을 앞둔 지금 이제야 막 4개월차가 된 햇병아리 웹 개발자다.
사실 개발자로서 회고를 어떻게 작성해야 하는지도 모르고 글재주도 딱히 없는 편이라 어떤 식으로 써나가야 할지 잘 모르겠다.
지금은 별 볼일 없는 사람이지만 단순히 성장처럼 추상적인 목적을 떠나 오늘보다 내일, 올해보다 내년에는 조금이라도 그나마 더 나은 인간이 되기 위해서 한 해를 돌아보고 기록해보고자 한다.
개발자가 되고 나서 처음으로 작성하는 회고이지만 개발과 관련된 내용보다는 전체적인 한 해의 일상들을 돌아보게 될 것 같다.
지속된 팬데믹으로 어찌 보면 썩 유쾌하지만은 않은 1년이었지만 그래도 나에게 일어났던 이런저런 사건들로 구성해보려고 한다.
내년에는 반기 단위로도 회고를 작성하고,조금 더 알찬 스스로의 진짜 성장을 꾸준히 기록할 수 있는 한 해를 보내기를 희망해본다.

취업

가장 먼저 올해 나는 취업을 했다.
짧다면 짧고 길다면 긴 여정이었지만 어찌됐든 취준이라는 길고 깜깜한 터널같은, 혹은 높은 벽 같았던 시간의 끝을 냈다.
작년 하반기부터 취업 시장에 뛰어들고부터 참 수없이도 많은 포지션에 이력서와 자기소개를 썼고 수십번의 탈락의 고배를 마셨다.
어떤 기업으로부터는 서류를 내고 단 몇시간 만에 탈락 통보를 받아보기도 하고, 지금의 회사 이외에 한 기업에서는 최종 면접까지 가서 탈락해보기도 하는 등 참 다양한 경험을 했고, 계속해서 스스로를 갈고 닦는 과정이었던 것 같다.
작년에도 취준을 하면서 참 다양한 경험이 있었지만, 올해에는 굵직하게 기억이 남는 다음과 같은 경험들이 있었던 것 같다.

삼성전자 공채 코딩테스트 응시

사실 왠지 모르겠지만 당연하게 서류에서 떨어질 것이라고 생각했었다.
하지만 정말 생각지 못하게 몇 주만의 서류 심사 결과, 합격 통보와 코딩테스트 전형 안내를 받게 되었다.
사실 코딩테스트는 이전까지 계속해서 프로그래머스와 BOJ, 그리고 leetcode의 문제들을 통해 나름대로 꾸준히 준비를 해왔지만 삼성에서 치르는 테스트는 처음 치뤄보기에 BOJ의 삼성 SW역량테스트 문제집, 그리고 삼성 SW Experts 사이트를 통해 유형에 익숙해지는 연습을 더 하면서 준비했다.
그리고 항상 온라인으로만 테스트를 보다가 처음으로 오프라인으로 시험장에 가서 테스트를 봤다.
고사장이 수원이었기에 시험 전날 숙소까지 잡고 응시를 했으나 좋은 결과를 얻진 못했다.
이 이상 길어지면 회고보다는 코딩테스트 후기가 되어버릴 것 같아 이만 줄여야겠다.
(그 당시, 직후에 후기를 작성할 걸 하는 후회가 밀려온다.)

카카오 신입공채 2차 코딩테스트 응시

카카오는 개발자라면, 특히 미취업 개발자라면 누구나 한번쯤 꿈꿔봤을 만한 선망의 기업이다.
하지만 나의 평범한 알고리즘, PS 실력으로는 “아, 꿈만 꿔야겠구나”라는 생각이 들게 만드는 극악의 신입공채 코딩테스트 난이도로 인해 인턴십 전형을 포함해서 2019년부터 참 여러번도 그 1차의 문턱조차 넘지 못했던 것 같다.
그런데 올 해 무슨 바람이 들었는지, 여러 기업의 프론트엔드 포지션의 전형들을 겪은 뒤 코딩테스트 주력 언어를 Javascript로 바꿔서인지, 1차 테스트에서 총 7문제 중 4개의 문제를 풀어낼 수 있었고 처음으로 2차에 응시해보게 되었다.
2차는 일반적인 알고리즘 테스트와 달리, 아니 사실 결국은 알고리즘 테스트이지만 온라인 에디터를 통해 직접 제출 방식이 아닌 응시자의 PC에서 시험에서 제공하는 API를 활용해 HTTP 요청을 통해서 스코어보드를 업데이트하는 재미있는 방식이었다.
이 테스트는 재미있었지만 처리해야할 요구사항들이 뒤로 갈수록 참 어려웠던 기억이 난다.
무엇보다 카카오는 시험을 길게 보는 것으로 유명한데, 오랜 시간을 들여서 2차까지 응시했지만, 스스로 만든 결과가 조금 아쉽게 느껴진다.

현재 재직중인 회사

지금의 회사는 정말 우연한 계기로 만나게 되었다.
사실은 입사 전까지 이 회사가 무슨 회사인지 전혀 몰랐고, 지원하기 전까지 회사 이름을 들어본 적도 없었다.
그러나 그 당시 나는 졸업을 코앞에 두고 마지막 학기가 끝난 뒤 지푸라기라도 잡고 싶은 처지였고, 이 회사는 나에게 훌륭한 지푸라기가 되어 주었다.
보통 코딩테스트 포함 총 전형이 거의 4단계로 이뤄진 다른 많은 기업들과 달리 1차 코딩테스트와 2차 면접+라이브코딩으로 단순하게 구성된 전형이었기에 전형 기간은 짧았고 운이 좋게도 합격할 수 있었다.
입사 후에는 채용 연계형으로 8주간의 인턴십을 거친 뒤 평가가 진행되어 정규직으로 전환되는 방식이었는데, 시작부터 마냥 좋은 분위기는 아니었다.
처음 인턴십 합격과 함께 받은 인턴십 과정에 대한 안내를 통해 Java와 JSP를 주력으로 다루는 과정인 것을 보고 정말 수십번의 고민 끝에 입사 포기를 결정했었다. 나는 학부 과정 내내 프론트엔드 개발자를 지망하고 준비해왔기 때문이다.
당시 인턴십을 총괄하셨던 지금의 리더님께서 사용 언어가 맞는 팀으로 배정해주시겠다는 배려와 설득 덕분에 결정을 재고하게 되었고 약 20명의 인턴들 중 유일하게 다른 코스로 인턴십을 시작하게 되었다. (리더님 죄송합니다..)
그래서 결국에는, 그렇게 8주간의 인턴 과정을 마치고 같은 팀에서 Node.js를 메인으로 다루는 풀스택 개발자로(…) 지금까지 일할 수 있게 되었다.
이제 전환된지 만으로 4개월이 다 되어가지만, 아직도 일이 어렵고 적응해가는 중이다. 사실 업무 자체가 어려운것도 아니고 네 달동안 적응하는 중이란게 정말 부끄럽지만, 소속된 팀의 매우 큰 코드베이스에서 아주 일부분을 담당하고 있는데도 결국 기저의 코드 동작들을 다 알아야 문제 해결이 수월하고, 지식과 경험이 부족한 백엔드와 인프라쪽까지 고려하고 다뤄야 한다는 것 등의 것들이 여간 어려운 게 아니라는 것을 체감하고 있는 중이다.
투정해봤자 달라지는 것은 없으니, 아직 제대로 1인분도 못하고 있는 나에게 돈을 주고 고용해준 회사에 무한히 감사하며 얼른 제 값 하는 개발자가 되어야겠다고 다짐해본다.

졸업

나는 올해에 대학교를 5학년을 꽉 채워서 졸업했다. 다행히 초등학생과 동급이 되는 상황은 면했다.
전과생으로서 부족한 실력을 메우기 위해 2019년을 보냈고, 졸업 동시에 취업을 하기 위해 학점을 욱여 넣어 2020년을 보냈다.
코로나 때문(덕분)에 비대면 수업도 경험해볼 수 있어 좋았지만, 말그대로 정신이 없게 스케줄을 구성한 탓인지 하루 하루를 보내면서 놓치는 것들이 생겼고, 그렇게 2020년 하반기에 2개의 과목에서 출석시수 미달로 F를 받고 졸업이 한학기 늦어지게 되었다.
학기를 마친 직후에는 걷잡을 수 없는 자괴감에 빠져 폐인처럼 지냈다. 자고 일어나서 게임하고, 배달음식 시켜먹고, 다시 자고… 그런 지난하고 무의미한 시간들의 반복이었다.
번아웃인 것 같다고, 이만큼 달려왔으면 이정도는 쉬어도 된다고 말도 안되는 핑계를 위안 삼았다.
난 그렇게 가장 중요한 터닝 포인트가 될 수 있었던 두달이라는 시간을 그대로 쓰레기통에 처박아버린 셈이었다. 이 시간을 이렇게 보냈다는 사실은 아직까지도 큰 후회로 남아있다.
그랬지만 어찌됐든 시간은 흘러 학기가 시작되었고, 2개의 전공 과목을 들으며 이전보다는 조금 더 수월하게 시간을 활용하며 취업 준비를 시작했다.
마지막 학기인 이번 상반기에는 작년부터 계속해서 흥미 있었던 데이터/인공지능 과목들의 연장선인 딥러닝과 처음 개설된 인간과 컴퓨터 상호작용이라는 과목을 수강했고, 딱 평균적인 성적으로 학점을 채울 수 있었다.
마찬가지로 코로나 때문에 남들 다 흔히 하는 졸업식도 못했지만 그렇게 힘이 들고 오래 걸려서 졸업이란 것을 하니, 마냥 뿌듯하고 시원할 법도 한데 그렇지 않고 이제 오랫동안 달고 있던 이 대학생이라는 타이틀이 없어진다는 것이 참 서운하기도 하고 아쉽기도 한 그런.. 이상한 감정을 당시에 많이 느꼈던 것 같다.
어찌됐든 그렇게 나는, 입학한지 8년 반이라는 시간 끝에 졸업이란 것을 하게 되었다.

독립, 그리고 이사

자취를 결정한 것은 작년 6월이었다.
군 전역 후 복학생으로 다시 대학생활을 시작하면서 학교에서 1년의 거의 3/4를 보냈고, 집은 그저 씻고 어쩌다 한번씩 침대에서 잘 수 있는 공간 정도였다.
그랬지만 마음 속으로 집이라는 공간에 대해서 두가지 생각이 자리잡기 시작했다.
하나는 그동안 내가 부모님의 보살핌에 무신경해지고 당연하다고 느끼고 있었다는 것. 어느 순간 문득 생각하니 어머니께서 집안일을 하시는 모습을 더 이상 눈 앞에 두고 보기가 힘들다는 생각이 들었다. 내 몫의 청소, 빨래, 설거지라도 덜어드리고 내 몫은 내 손으로 하면서 살고 싶었다.
다른 하나는 독립적인 내 공간에 대한 갈망이었다. 물론 본가에도 방이 있었지만 매우 좁았고 방 안에 만성으로 피어나는 곰팡이와 이별하고 싶었다.
그렇게 다음 달, 나는 부모님의 강력한 만류에도 불구하고 학교와 도보 30분 거리에 있는 본가를 떠나 임시로 단기 원룸을 구해 첫 독립 생활을 시작하게 되었다. 그렇게 처음으로 자취를 시작하고 나서, 나는 올해에만 세 번의 이사를 했다.

첫번째 이사

첫번째로 자취를 시작한 집주인이 비대면 기간동안 자리를 비운 오피스텔에서 약 7개월을 지내고, 다시 방을 비워줘야 하는 상황이 되어 학교 근처 원룸촌의 신축 원룸으로 마찬가지로 단기, 하지만 처음으로 계약 당사자가 되어 부동산 계약을 해본 경험이었다.
지금도 사실 크게 다르지 않지만, 그 당시에는 지금처럼 정착하게 될 시기를 대비해 본가에 당장 필요하지 않은 짐들을 두고 정말 최소한의 짐으로만 생활하는 미니멀 라이프를 실천했다.
하지만 그래도 사람의 살림살이라는 것이 살다 보면 자연스레 나도 모르게 늘어난다는 것을 이 때 처음 알았다.
고작 그정도의 짐으로 용달이나 이삿짐 센터를 부르기엔 배보다 배꼽을 키우는 격이 되기에 부끄럽게도 독립은 했지만 아버지에게 도움을 받아 두번째 집으로 이사를 할 수 있었다.

두번째 이사

두번째 집에서 지내면서 마지막 학기를 잘 마무리지을 수 있었다.
지방 치곤 좀 크기에 비해 비싸다고 생각했지만, 신축 원룸이어서 그런지 깔끔하고 쾌적하다는 점이 가장 좋았지만 역시 방음이 매우 하자였다.
옆 건물에 같은 과 후배들이 살아서 종종 마주치며 대화도 나누고 썩 그렇게 외롭지 않았다는 생각을 했던 것이 기억난다.
일찍 다가온 여름 때문에 적잖이 벌레와의 사투를 벌여야 했지만 정말 다행히도 바퀴벌레는 만나지 못했다.
좌우지간 그렇게 지내던 집에서 계약 기간 만료가 다가왔지만 학기가 끝나고 취업 준비에 박차를 가하면서 연장에 대한 결정을 해야 했는데, 인턴 합격 시기가 애매하게 걸치는 바람에 때를 놓쳐 이미 다른 사람이 계약이 된 상황까지 돼버려 어쩔 수 없이 새로운 집을 구했어야 했다.
마찬가지로 또 학교에서 멀지 않은 근처의 원룸으로 단기 계약을 하게 되었고, 또 부끄럽지만 아버지의 도움을 받아 세 번째 집으로 이사를 하게 되었다.

세번째 이사, 그리고 현재

세번쨰 집은 정말이지 마음에 드는 구석이 단 하나도 없었다.
하지만 지금까지 지냈던 원룸들보다 짧은 기간의 단기로 구할 수 있는 곳이 흔치 않았기에 어쩔 수 없이 결정하게 되었다.
원룸이라 말하기도 민망한, 고시텔이라고 부르기에 적당한 낡고 허름한, 그리고 매우 특이한 구조를 가진(…) 그리고 예상대로 벌레가 득실대는 하여튼 이상한 집이었다.
그럼에도 불구하고 고마운 감정이 드는 곳이긴 하다. 결국 그 곳에서 보낸 시간 덕분에 지금 이 회사에서 일하게 되었으니 말이다.
그렇게 정규직이 되었지만 회사의 재택근무 정책으로 인해 사무실 출근을 위해 미리 이사할 시기가 애매했고, 무엇보다 이제 정규직도 되었으니 앞서 말한 것처럼 그 허름한 집을 떠나고 싶은 마음이 점점 커졌다.
그래서 바로 회사 근처의 전세 매물과 전세대출을 알아보기 시작했다.
사실 이 주제만으로도 몇 시간은 떠들 수 있지만, 간략히 하자면 전세 매물 품귀로 인해 회사에서 먼 곳들 위주로 방을 알아보다가 정말 운이 좋게도 적당히 넓고 쾌적한 지금의 집을 찾게 되었고 전세 대출에 대해서 공부하고 회사에서 지원해주는 대출까지 정말 말 그대로 영혼까지 끌어 모아 이런 저런 서류 준비와 부동산과의 협의 등 긴 우여곡절 끝에 계약하게 되었다. 돌이켜보면 정말 다신 하기 싫을 만큼 복잡하고 지난한 과정이었다.
마찬가지로 짐은 매우 적은 편이었지만 이번에는 타지로 이동하는 만큼 용달을 이용해서 이사를 마쳤다.
아직 부족한 것들이 있지만, 전세금을 제외하고 당시 있는 돈을 다 털어 살 수 있는 가구들을 구매했다. 지금까지 지냈던 곳들은 모두 풀옵션이었지만 지금의 집은 그에 비해선 텅텅 비어있었다.
결론짓자면, 내 손으로 전세 계약을 하고, 대출을 받아보고, 가구를 구매하고, 조립해보고 배치하고 하는 모든 과정들이 처음으로 해보게 된 집이지만, 한 명의 사회인(?)으로서 뜻깊은 경험이었다고 생각한다.
앞으로 이 집에서도 지금까지의 자취방들에서 그랬듯 한걸음씩 더 나아가는 경험으로 채워나갔으면 좋겠다.

2021년 총평

막상 적고 보니 정말 뭔가 크게 한 건 없는 것 같아 부끄러워진다.
그럴 것도 한 것이, 정말 한 해 동안 한 일이 사실상 이게 전부이기 때문인 것 같다.
취업과 졸업이라는 목표만을 바라보며 한 해의 절반을 맹목적으로 달리기만 했는데, 많은 개발자들이 이야기하듯 취업은 끝이 아닌 시작이었다는 것을 지금에 와서야 몸소 깨닫는다.
나머지 절반은 나 자신의 생활을 정착하는 데 많은 시간과 노력을 들인 탓에 개발자로서의 성장에 많이 게을렀던 것 같다.
사실 이런 게으름을 마냥 재택근무를 탓할수는 없지만, 일단은 나랑 잘 안맞는 방식인 것 같다는 생각을 지울 수 없는 건 어쩔 수 없을 것 같다.
재택근무가 잘 맞는 사람도 있는 반면, 나는 개인적으로 출근과 퇴근이라는 시간 개념, 그리고 업무를 하는 공간이 곧 내가 생활하는 공간이라는 개념이 아직도 완벽하게는 적응이 잘 되지 않는 것 같다.
하지만 역시 앞서 말한 것처럼 투정만 부려서는 나아지는 것이 없으니 이제는 나도 이런 제도(22년 3월까지 재택…) 속에서 심리적이든 물리적이든 나만의 극복 방법을 찾아내 실천해야겠다는 생각이 강하게 든다.

결론적으로, 그 시간들을 보내온 나로서는 최선이었다고 생각하지만, 돌이켜보면 남는 아쉬움은 지울 수가 없는 것 같다. 더 잘 할 수 있었을텐데.
하지만 지나간 과거에는 미련 두지 않고, 앞으로 더 잘 해낼 수 있다고 믿으면서 행동하는 방법밖에 없는 것 같다.

2022년에는

더 실력있는 개발자가 되자
- 회사 업무와 내부 서비스에 더 능숙해지기
- 결제해놓고 안 듣던 강좌들 듣기
- 자바스크립트 기본/핵심 꼼꼼히 공부하기
- 사이드 프로젝트 2개 이상 진행하기
더 신체적으로 건강한 사람이 되자
- 웨이트 다시 시작하기
- 영양제 다시 챙겨먹기
더 정신적으로 건강한 사람이 되자
- 다양한 책 읽고 실천하기
- 그동안 하고 싶었던 취미 시작해보기
더 부자가 되자
- 차곡차곡 시드머니 모으기
- 주식 좀 더 공부하기
- 부동산 공부 시작하기
- 불필요한 지출 줄이고 절약하기
- 작더라도 가능한 부수입 만들어보기

다 이루진 못하더라도 이루려고 노력하다보면 그래도 반은 실천할 수 있지 않을까.
항상 모든 일들을 제대로 각 잡고 시작하려고 하고, 크게 생각하고 계획해서 행동하려고 했기 때문에 많은 것들을 하나씩 뒤로 미뤄두었던 것 같다.
앞으로는 Just Do It. 그냥 하자. 하나라도 꾸준히 실천하다보면 작더라도 결실이 있을테니.

글을 쓰기 위해 하나하나 돌이켜보다 보니 처음 생각했던 것과는 달리 그래도 꽤 많은 일들이 나에게 있었구나 하는 생각을 하게 되었다. 텍스트로만 다 적게 되면 정말 별의 별 소리까지 다 쓸 것 같아 많은 부분을 날렸다.
막상 다 작성하고 보니 정말 내맘대로 너무 막 쓴 것 같은 느낌이 든다.
아쉬운 대로 올 해의 회고는 이렇게 마치는 것으로 하고, 앞으로는 과거를 돌아볼 때 무용담처럼 자랑스럽게 얘기할 수 있는 이야깃거리들로 가득했으면 좋겠다.

읽어주셔서 감사합니다.
신년에는 모두들 목표하는 바를 이루시는 한 해가 되길 바라겠습니다.

HAPPY NEW YEAR!

about

Fri, 03 Sep 2021 14:12:30 GMT

_{최근 수정한 날짜: 2023.6.18}

민윤기 (Anthony)

소개

저는 이런 개발자입니다.

호기심 많고, 도전적이며 문제 해결 과정에 열정적입니다.
적어도 개발에 있어서만큼은 Grit을 발휘합니다.
작지만 큰 차이를 만든다고 믿는 디테일에 몰입합니다.
좋은 동료와 함께하고 싶고, 저 또한 타인에게 좋은 동료가 되고자 합니다.
항상 배우려는 자세로 임하고, 지식과 경험 앞에 겸손하려 합니다.


Github	https://github.com/anthonyminyungi
Blog	https://yungis.dev
Email	yungi.anthony.min@gmail.com

학업

충남대학교 컴퓨터공학과

(2013.03) 화학공학과 입학
(2015.03) 컴퓨터공학과 전입
(2021.08) 학부 졸업

업무 경험

N-Tech Service (NTS)


기간	2021.09 ~ 현재
역할/직책	SW교육플랫폼 개발 / 웹 개발자

엔트리 신규 프로젝트 개발 (진행중)

2022.08 ~
Typescript, Next.js, Node.js, Express, MongoDB, Mongoose, Type-GraphQL, DataLoader, Jotai, React-Query, MSW, Storybook, React-Bootstrap, Zeplin, Emotion, Nginx, ElasticSearch, monorepo(lerna), i18n

상세 설명

어드민 기획서를 바탕으로 데이터 타입 명세, API 설계 및 구현, 설계된 API와 화면설계서를 활용하여 어드민 페이지 구현
서비스 기획서와 어드민 API를 바탕으로 서비스 API 설계 및 구현, 설계된 API와 화면설계서를 바탕으로 서비스 페이지 구현
기획팀과 직,간접적으로 의사소통하여 스펙 구체화 논의 및 개발 완료건 QA 대응 진행
타 부서 개발팀과 의사소통하며 서비스 마크업 및 라이브러리 개발 협업

엔트리 발견 컨텐츠 기능 런칭 및 리뉴얼

2021.09 ~ 2022.04
Next.js, Node.js, MongoDB, Mongoose, GraphQL, DataLoader, React-Query, Storybook, Zeplin, Emotion, Nginx, i18n

상세설명

인턴 기간부터 작업하던 내용을 이어서 실제 서비스용 코드로 발전시키면서 개발 진행
신규 컨텐츠 기획의 요구사항을 분석해 데이터 모델링, GraphQL API 작성
사내 admin 및 서비스 웹의 관리자 페이지 구현, 스마트에디터 적용
다국어 기반 서비스 웹의 사용자 페이지 구현
기획자, 디자이너와 직접 커뮤니케이션하며 기획 및 디자인 수정 및 개선사항 대응

엔트리 서스테이닝

2022.02 ~ 2022.12
Next.js, Node.js, Express, MongoDB, Mongoose, GraphQL, DataLoader, React-Query, Storybook, Zeplin, Emotion, Nginx, ElasticSearch, monorepo(lerna), i18n

상세설명

엔트리 admin/서비스 웹 관련 기능 및 UI 오류 개선 등 중소규모 마일스톤 이슈 처리
(22.05~ 22.08) 일본 라인엔트리 리뉴얼 프로젝트 QA 대응을 지원하며 다국어, 마크업 이슈 등과 함께 한국 엔트리와 공통된 이슈 처리 (리뉴얼 중단, fade-out)
신규 프로젝트 투입으로 서스테이닝 업무 축소

수동 작업 자동화 스크립트 작성

Node.js, mongoose, Octokit, Lambda

상세설명

수기로 Mongoose 스키마를 csv 테이블 형태로 각 필드에 대한 설명을 문서화하던 작업을 반자동화하여 스크립트 실행으로 기존 스키마 수정 및 신규 스키마 생성 시 csv를 만들도록 작업
매주 수기로 팀 내에서 처리한 이슈들을 내부 양식에 맞게 정리하여 작성하는 주간보고서를 github의 octokit api를 사용한 스크립트로 반자동화하여 스크립트 실행으로 이슈 리스트를 불러와 마크다운으로 포매팅하여 보고서 이슈를 생성하도록 작업

N-Tech Service (NTS)


기간	2021.07 ~ 2021.09
역할/직책	개발 인턴

엔트리 발견 컨텐츠 어드민, 서비스 웹 구현

2021.07 ~ 2021.09
Next.js, Node.js, MongoDB, Mongoose, GraphQL, React-Query, Class-based CSS(internal), Emotion, Nginx

상세설명

인턴십 과정의 일환으로 실제 서비스 코드베이스가 아닌 일부만 클론된 환경에서 파일럿 프로젝트 형식으로 작업하고, 멘토와 1:1 코드리뷰 진행.
기획서를 바탕으로 발견 컨텐츠 관련 일부 DB 모델 설계 및 admin의 리스트/생성/수정/미리보기 페이지 구현.
기획 및 Storybook 마크업을 바탕으로 발견 컨텐츠 관련 일부 GraphQL API 정의 및 엔트리 서비스 웹의 상세/수정 페이지 구현.

(주) 하얀마인드


기간	2020.06 ~ 2020.08
역할/직책	백오피스 개발 인턴

인턴십 기간 중 깃허브를 통한 협업과 커뮤니케이션 과정에서 많은 고민을 하게 되어
이 부분에 대한 생각을 담은 글을 작성.

COVID-19 알림 챗봇 제작

2020.07 ~ 2020.08
Facebook workplace chat API, Firebase functions, Typescript, Axios, Cheerio

상세설명

코로나19로 인해 사내에서 규정하는 원격근무 여부 결정 및 현황 정보 전달을 용이하게 하기 위해 직접 회사에 제안 후 진행한 사이드 프로젝트.
보건복지부, 대전광역시 코로나19 현황판 페이지를 크롤링하여 메신저의 단체방으로 매일 오전 10시에 전송하도록 스케줄링하여 구현.

문서 동시편집 방지 기능 구현

2020.06 ~ 2020.08
Firebase, React, react-admin, GraphQL

상세설명

기존 백오피스의 유저 간 동시 편집으로 인한 덮어쓰기 이슈를 방지하기 위해 인턴십 기간동안 단독 장기 프로젝트로 진행.
Firestore에 신규 컬렉션 추가 및 그에 대응하는 서버사이드 API scheme과 resolver를 GraphQL로 구성하고 Transaction을 통해 편집 상태 변경 요청을 처리하는 로직 구현.
문서 상세 뷰에서 편집 상태에 따른 UI와 편집 상태 업데이트 및 해지를 Mutation 할 수 있도록 구현.

(주) 하얀마인드


기간	2019.12 ~ 2020.03
역할/직책	백오피스 개발 인턴

백오피스 유지보수 및 기능 개선

2020.01 ~ 2020.03
Firebase, React, react-admin, Material-UI, Algolia

상세설명

백오피스의 컨텐츠 문서 생성 페이지의 태그 선택 기능을 기존의 가독성이 떨어지는 Dropdown List 방식에서 Checkbox를 활용한 UI로 변경하는 작업 수행.
백오피스에 검색 기능을 추가하는 소규모 프로젝트 진행.
- Algolia를 활용해 컬렉션 별 검색 인덱스를 생성하고 Firesotre의 데이터 변경이 이루어질때마다 검색 인덱스를 업데이트 하도록 트리거 구성.
- API 호출 최소화를 위해 Search Input에 대해 Debounce 적용.
이외 백오피스 프로젝트 내 마일스톤 이슈 해결 및 유지보수 업무 수행.

사내 홈페이지 리뉴얼

2019.12 ~ 2020.03
React, CSS, React-i18n

상세설명

기존 Jekyll로 제작된 회사 홈페이지를 새로운 React SPA로 리뉴얼한 프로젝트.
Zeplin을 활용해 디자이너와 1:1 협업하여 초기 개발부터 배포까지 진행.
https://hayanmind.com

오픈소스 기여

React.js 공식 문서 한국어 번역

Github: https://github.com/reactjs/ko.reactjs.org/pull/222
문서: https://ko.reactjs.org/docs/error-boundaries.html

프로젝트

0Auth (Zero-Auth)


기간	2020.07 ~ 2020.11
역할	라이브러리 개발 / 크롬 익스텐션 개발
팀 구성	2명
Github	https://github.com/0-Auth/0Auth
비고	2020 공개SW 개발자대회 출품 (동상 수상)

상세설명

Node, Typescript, Crypto-js, Elliptic, React, Material-UI
전자서명을 활용해 서버에 데이터 저장 없이 사용자 인증을 수행하는 라이브러리.
전자서명과 암호화 모듈을 활용한 사용자 인증 라이브러리 개발 및 크롬 확장 프로그램 UI 개발 작업 수행.

SoundsHub


기간	2019.06 ~ 2019.08
역할	팀장 / 백엔드 개발
팀 구성	3명
Github	https://github.com/cnu-bottomup-3m/Team_3m_Projcet
비고	2019 교내 프로젝트 경진대회 출품 (대상 수상)

상세설명

HTML, CSS, Javascript, PHP, MySQL, Python, YouTube Data API
무료 음악 스트리밍 웹사이트
NCP 무료 우분투 서버를 기반으로 서버 및 DB 환경 구축.
BeautifulSoup을 활용해 Melon 차트, YouTube Video id를 크롤링하고 Crontab을 통해 자동화.
19년 8월 배포, 무료서버 만료 이후 종료.

읽어주셔서 감사합니다.

_{^{Software Engineer, @Anthony Min}}

좋은 PR에 대한 단상 🤔

Mon, 07 Sep 2020 12:09:37 GMT

본 게시물은 하얀마인드 기술블로그에 본인이 기고한 글을 옮겨 작성했습니다.

이 글을 쓰게 된 이유

이 내용은 영어로 작성하고 싶었으나, 좋지 못한 영어 실력때문에 남기고자 하는 의미가 왜곡될 수도 있고, 올바른 표현과 어휘를 찾기 위한 시간을 들이기 보다는 글을 더 잘 작성하는 데 집중하고자 한국어로 작성하려고 한다.

우선 이 주제는 지난 겨울 인턴 시절(당시 나는 Github와 Git을 능숙하게 다루지 못해 이들에 익숙해지기 위한 노력에만 급급했다.)부터 혼자서 계속해서 분투하고 고민하던 것이지만 “계속 하다보면 늘겠지”, “어떻게 처음부터 잘하겠어” 라는 안일한 생각으로 나에게만 편한 PR을 작성하며(당시에는 몰랐지만 지금 생각해보니 그랬던 것 같다.) 시간이 흘렀고, 스스로의 문서 작성 능력과 커뮤니케이션 능력은 전혀 발전하지 못한 채로 지금에 이르게 되었다.

때문에 현재 진행중인 프로젝트에 대한 PR 관리에도 미흡한 자신을 보며 이 문제는 꼭 되짚고 넘어 가야겠다 라는 생각에 작성하게 되었다.

PR을 작성함에 있어, 가장 우선이 되는 요소는 그 PR에 포함된 코드인데, 이 점에 대해서도 고민이 많다. 개인적으로 낯선 분야에 대한, 혹은 낯선 방식으로 작성된 코드는 읽고 이해하는 데에도 많은 시간이 소요되며, 이를 바탕으로 새로운 코드를 작성하려 해도 선행되어야 할 이해가 완벽히 되지 않았으니 그를 되짚고 작성하기를 반복하며 또 많은 시간이 소요된다. 시간 뿐만 아니라 코드의 퀄리티에 대한 고민 또한 자주 하게 된다. 이 고민에 대해서는 이 문서에서는 다루지 않기로 하고, 나중에 기회가 되어 별도의 문서로 남기게 됐으면 좋겠다.

이 문서에서 나는 어떻게 하면 좋은 PR을 작성할 수 있을지에 대한 가르침을 준다거나, 구체적인 가이드라인 및 교육을 제공하려는 것이 아니다. 다만 조금 이기적일 수 있지만 이렇게 글로 남김으로써 스스로 이 고민에 대한 내용들을 머릿속에서 정리하고, 가능하다면 돌파구를 찾아 성장의 발판으로 삼고자 이 글을 남기게 되었다.

좋은 PR이란 무엇인가?

먼저, PR이란?

좋은 PR에 대한 고민을 하다보니, 이 PR이라는 것의 본질과 역할에 대해서도 다시 생각해보게 되었다.

PR이란, Pull Request의 약자로, 기존 깃허브 저장소에 보관된 코드 베이스에서 내 작업으로 인해 생긴 변경사항들, 즉 코드 라인들의 추가와 삭제를 코드 베이스에 포함시켜달라고 보내는 요청이다.

우리 회사는 이슈(issue)를 통해 작업하고자 하는, 혹은 수행되어야 하는 하위 작업들에 대한 명세를 하고, 그 이슈를 통해 작업 내용을 제한한다. 때문에 이슈 제목과 설명을 통해 이 개발자가 무엇을 하려는 것인지를 알 수 있다. 이를 바탕으로 개발자는 병합의 단위가 되는 기존 코드와 동일하게 복제된 브랜치(branch)를 생성해 그 브랜치의 이름을 이슈 번호와 제목으로 구성하여 이 브랜치에서 무슨 작업이 진행되는지를 알게 한다.

작업을 마치게 되면, 작업 브랜치(사내에서는 feature/ 라는 디렉토리 형식의 컨벤션을 사용하고 있다)를 베이스 브랜치(develop이라는 이름의 개발이 완료된 단계의 코드가 모여있는 브랜치)에 병합(merge)하기 위한 요청을 보낸다. 이를 Pull Request라고 하며, 앞서 서술한 내용대로, 작업 내용을 명세하는 이슈를 바탕으로 브랜치를 생성 후 PR을 열기 때문에, 대개 1 branch 1 PR로 작업한다(명시적인 컨벤션인지는 잘 모르겠으나 개인적으로 생각하기에 그렇다). 이 PR에서는 아무렇게나 작성된 혹은 제대로 동작하지 않는 코드가 포함되거나 기존 코드의 무분별한 삭제 등을 막기 위해 회사에서는 코드 리뷰(review)를 거쳐 이 코드가 베이스 브랜치에 포함되어도 될지 승인(approve)하거나 변경 요청(change request)를 통해 결정되도록 하는 검증 절차를 통과하도록 규정하고 있다.
코드 검증 절차

앞서 설명한 것처럼, 자신의 작업 내용이 반영되어야 한다면 반드시 자신의 작업 브랜치로부터 베이스 브랜치로의 PR을 열고 작업 내용에 대한 리뷰를 통해 승인을 받은 뒤 병합해야 한다.

그럼 누구에게 review를 요청해야 하는가?

이는 생각보다 간단한 문제이다. 자신이 Github를 통해 작업하기로 한 내용에 대해서 사전에 논의한, 혹은 작업을 배정한 이가 있을 것인데, 그 분에게 리뷰를 요청하면 될 것이다. 혹여 그런 사람이 없다면, 본인을 담당하고 있는 매니저나 임원분들과 논의를 통해 리뷰어를 지정하는 과정이 필요할 것이다. 만약 코드를 추가하는 것이 아니라 변경하는 경우에는 Github 저장소 내 커밋 기록, 에디터의 Git 플러그인(예: GitLens) 등을 통해 그 코드의 최초 작성자를 리뷰어에 포함시키는 것도 하나의 방법으로 생각해볼 수 있다.

위 사진에서 보이듯이, 우리 회사는 저장소 내에 Pull Request에 대한 템플릿을 가지고 있다. 이 양식은 리뷰어를 위한 첫 번째 가이드라인이다. 이 브랜치와 작업 내용이 어떤 이슈와 연결되어 있는지, 어떤 작업을 어떤 식으로 진행했으니 무엇을 중점적으로, 혹은 어떤 순서에 의거하여 리뷰를 진행하면 되는지에 대한 안내와 관련 부가 정보들을 포함한 간략한 설명을 리뷰를 요청하는 사람이 작성하게 된다.

이어서, 리뷰어를 위한 두 번째 가이드라인으로, 변경 사항이 적지 않거나 구조가 복잡해진 경우에는 리뷰를 요청하는 사람이 자신의 작업 내용을 ‘셀프 리뷰’하면서 리뷰 가이드(Review guide)를 작성하는 것이다. PR 웹페이지 내에서 자신의 변경사항 한 줄 혹은 몇 줄마다 자신이 작성한 코드에 대한 조금 더 자세한 설명을 적는다. 보통은 이 코드에 사용된 기법, 혹은 추가된 위치에 대한 근거, 특정 라이브러리를 사용한 이유 등에 대해 적고, 그에 대한 결과(client 단의 작업이라면 UI상의 변화, server 단의 작업이라면 로그 등)를 보여주는 것이 좋다. 이를 위해서라도 자신이 수행한 작업에 대한 내용은 반드시 의도한 바대로 동작하는지 테스트를 해보고, 기존 프로덕트의 성능에 영향을 주지 않는지를 점검해야 한다.

경험해본 이들은 알겠지만 코드 변경 사항을 리뷰하는 것은 꽤나 골치아픈 일이다. 이러한 사전 정보들조차 없다면 이 부분을 왜 이렇게 변경했는지에 대한 의도와 근거 등을 문답하는 데에만 매우 길고 불필요한 시간이 소모될 것이다. 때문에 리뷰를 요청하는 사람에게도 리뷰어를 배려하는 태도를 바탕으로 한 구체적인 설명을 작성하려는 노력이 필요하고(물론 리뷰 요청을 하기 전에 먼저 코드를 명확하고 근거있게 작성해야 한다.), 리뷰어에게도 정확히 부가적인 논의 혹은 수정이 필요한 부분에 대해 정확하게 지적할 수 있는 능력과 이를 잘 전달하기 위한 노력이 필요할 것이다. 간혹 크기가 큰 PR이거나 논의가 필요한 사안을 포함하고 있는 경우, 아예 리뷰어와 시간을 따로 잡고 공동 리뷰(Co-review)를 진행하는 경우도 있다.

방금 이야기 한 것처럼 PR 내에서의 리뷰이와 리뷰어 모두에게 필요한 공통적인 노력은 의사소통이다. 작성된 코드를 매개로 서로의 시간을 절약해주기 위해 절제되어 있으면서도 구체적인 의사소통을 통해 작업 내용에 대한 검토를 빠르고 정확하게 마치는 것이 바람직한 검토 과정이라 할 수 있다. 이를 달성하기 위한 방법에 대해서는 뒤에서 조금 더 자세히 고민해보도록 하겠다.

평소 내가 하던 방식 (+ 어떤 PR이 안 좋은 것인가?)

이 부분을 어떻게 작성하면 좋을까 생각하다가, 내가 작성했던 지난 PR들 중 대표적인 사례 몇 개를 골라 돌이켜 보면서 구체적으로 어떤 점이 미흡했는지, 무엇이 어떻게 잘못됐는지에 대한 회고와 논평을 해보려고 한다.

원문에는 PR 링크가 포함되어 있지만, Private 저장소의 PR이기 때문에 링크를 제거하였다.

#6954

이 PR은 약 반년 전 회사 내 백오피스인 TMS에 검색 기능을 도입하면서 검색 입력부 UI와 Algolia를 활용한 API 동작 및 결과를 보여줄 화면 UI를 구성하기 위해 작업했던 PR이었다. 이 PR에서의 문제는 무엇이냐면, PR의 규모를 너무 크게 가져갔다는 것이다. 당시엔 Github를 능숙하게 다루지 못하던 시절이고 어떤 효율적인 작업 흐름이나 기법에 대해서 크게 고민을 하지 않고 무작정 하던 시기여서 그런 점도 있는 것 같다.

그런데 이러한 방식을 취할 때의 단점은, 결론부터 말하자면 리뷰어와 리뷰이 모두가 힘들어진다는 것이다. 왜냐하면 변경사항의 규모가 크기 때문에(이 PR은 추가된 라인이 800여 줄에 이른다. 상당히 많은 양이다.) 리뷰이의 입장에서는 아무리 코드를 완전하게 작성하려고 해도, 한번에 많은 양의 코드를 작성하게 되면 자신이 테스트 해본 부분 이상의 예상치 못한 오류가 무더기로 발견되는 경험을 할 가능성이 높아진다. 그렇게 되면 수정하고 반영해야할 사항들이 많아지고, 그만큼 PR은 계속해서 커져만 가게 된다.

여기서 PR이 커진다 라는 문장의 의미를 단순히 변경사항의 수치로만 판단하지 않고, Conversation의 개수와 그 내용의 퀄리티에도 영향을 받는다고 생각했다. 왜냐하면 변경사항은 예를들어 dependency들의 무더기 업데이트로 인해 yarn.lock file에 추가된 변경사항이 천 단위로 많은 경우도 있을 수 있고, 코드를 무성의하게 작성하는 등의 이유로 변경 요청 등의 리뷰어와의 논쟁이 길어지는 경우 Conversation의 개수는 계속 늘어만 갈 것이기 때문이다.

리뷰어의 입장에서는, 대량의 변경사항을 한 곳에서 보고 코드의 적합성을 판단해야 하기 때문에 전체적인 시각에서 볼 수 없게 되는 경우가 있을 수 있다. 코드의 동작 여부는 해당 브랜치로 이동해 직접 실행을 시켜보면 알수 있겠지만, 변경사항은 PR 페이지 내에서 확인하고 검토해야 하기 때문에 한 PR에 장시간을 투자해야 하며, 한 번의 리뷰로는 끝나지 않을 것이기 때문에 이 과정을 반복하게 되어 쉽게 피로해질 수 있을 것이다.

이 부분에 대해서는 최근을 돌이켜봐도 아직도 잘 지켜지지 않고 있는 것 같다. 이 부분의 개선 방향은 뒤에 나올 본론에서 더 자세하게 정리된 생각을 적어보도록 하겠다.
#7255

이 PR은 겨울 인턴 끝자락에 검색 기능 구현 당시 함께 작업한 내용이다. 닫힌 채로 무덤에 들어가있던 PR을 다시 입사하면서 되살려내어 작업했다. 이 PR에서는 두 가지를 살펴볼 수 있는데, 우선 이들는 나의 기초적인 부분에서의 실수들로부터 기인하였다. 무엇이냐면, 기존 코드에 부가적인 내용을 추가하면서, 컨벤션과 벗어나게 변경될 수 있는 자동 코드 포맷팅을 비활성화 하지 않았고, 리뷰를 반영 중일 때 다시 작업중이라는 표시를 하지 않았다는 것이다. 이들을 제외하고는 이 PR내에서 큰 어려움을 겪지는 않았고, 여기서 하고싶은 말은 아래에서 자세하게 정리하겠다.
#7253

이 PR도 위의 것과 연관된 내용이다. 이제 와서 말이지만, 다시 인턴을 시작하자마자 이 코드들을 다루게 되면서 이 코드의 원래 동작을 파악하는 데 많은 시간을 소모하면서도 한편으로는 빨리 끝내고 싶은 마음에 억지로 끼워맞춘 감이 없지 않아 있다. 스스로가 무엇을 하고 있는지도 모르는데 어떻게 좋은 PR을 작성할 수 있겠는가? 이 PR에서 내가 적은 “알 수 없는 오류가 발생해서 다른 방식을 취했다”와 같은 말은 절대로 밖으로 뱉어내서는 안 될 아마추어같은 생각이다.

어떻게 하면 더 잘 할 수 있을까?

사실상 이 부분이 본론이다. 스스로의 고민 과정을 정리하고 돌이키다 보니 서론이 길어졌다. 본론에서는 어떻게 하는 것이 옳은 방향인가 에 대한 내용을 나 자신에게 하는 말이기도 하므로 명령문을 함께 포함하여 작성하겠다.

리뷰어를 배려하라

코드 컨벤션을 잘 지켜라. 깔끔하고 잘 동작하는 코드를 만들기 위해서 정해 놓은 규칙인데 이를 무시하거나 인지하지 못한 채로 커밋을 작성하게 되면 이에 대한 리뷰가 먼저 들어올 것이다. 이는 불필요한 코멘트이고 시간 낭비가 될 수 있으니 지양하는 것이 좋다.
리뷰 가이드라인을 잘 작성해라. 모든 코드 변경사항에는 의도가 필요하다. 의도치 않게 변경된 부분이 있다면 되돌려 놓아야 하고, 줄바꿈과 같이 아주 단순한 변경사항이라도 그 부분을 리뷰어가 볼 필요가 없다면 “Just line change” 와 같은 코멘트를 달아 명시하여 리뷰 시간을 줄여줄 수 있을 것이다. 또는 사용된 라이브러리 업데이트가 포함되었다면 해당 라이브러리의 릴리즈 노트 링크나 스크린샷을 첨부하는 것도 좋은 방법이다.
작업중, 리뷰 가능 여부를 잘 명시해라. 아직 코드를 작성 중일 때에는 [WiP] 를 타이틀 앞에 추가하고, 만약 작업이 끝났으면 이를 제거하고 review-needed 태그를 설정해라. 그러나 한 번 작업을 마쳤다고 끝난 것이 아니기 때문에 리뷰를 반영하는 중에도 이 과정을 반복하여 명시하라.

내가 쓴 코드는 내가 책임져라

자신이 작성한 코드에 대해서는 100% 이해하라. 위에서 언급한 것처럼 모든 변경사항에는 근거가 필요하다. 내가 만들어낸 변경사항임에도 스스로 납득하고 있지 못하거나 남에게 설명할 수 없다면, 그것은 스스로 짠 코드라고 할 수 없다. 기존에 존재하는 소스코드를 복사 붙여넣기 한 뒤 세부사항만 바꿔 넣는 상황이더라도 그 기존의 코드가 어떻게 동작하는지에 대해서는 당연히 이해하고 있어야 할 것이다. 자신이 완벽하게 이해는 못했지만 정상적으로 동작하며 필요한 코드라면 해당 라이브러리의 공식 문서를 참조해 자신의 코드에 대한 근거를 획득하고 나아가 코드를 이해하는 데에도 도움이 될 것이다.
무엇을 알고 무엇을 모르는지를 명확히 해라. 위에서 서술한 내용과 같은 흐름이지만 조금 다르다. 자신이 어디까지 알고, 어디부터는 모르겠는지를 스스로 파악할 수 있다면 머릿속으로 정리가 명확해질 것이다. 아는 부분에 대해서는 자신의 근거를 들어 설명하면 되고, 모르는 부분에 대해서는 신빙성 있는 문서들과 자료들에 의해 학습을 한 뒤 그들을 근거로써도 활용할 수 있다. 이 내용은 경험을 통해 힘들지만 코드 작업을 함에 있어 꼭 필요한 과정이라고 생각했다.

반드시 테스트하라

베이스 브랜치에 포함되기 위한 코드는 모두 정상적으로 동작해야 한다. 너무도 당연한 얘기지만 리뷰어가 내 코드를 직접 돌려보고 테스트하도록 만드는 것보다 내가 직접 돌려본 결과 이상이 없다는 것을 증명하는 것이 더 빠르고 효율적인 방법이다. 예를 들어, 앞서 셀프리뷰에 대해 이야기할 때에도 언급한 것처럼 PR에 포함된 결과물에 대한 스크린샷, GIF, 혹은 라이브 데모가 가능하도록 샘플API를 첨부할 수도 있다. 만약 직접 실행을 통해 확인이 필요한 기능이라도 스스로 검증한 내용은 첨부하되, 어떻게 테스트하면 될지에 대한 가이드라인을 리뷰어에게 주는 것 또한 하나의 방법일 것이다.

자신의 예상 작업량을 잘 측정하라

잘 재고, 잘 쪼개라. 자신이 해야할 업무 분량에 대해서 명확하게 계산이 되어야 한다. 그래야만 큰 PR을 만들지 않고 일정 단위로 잘 분리된 여러 개의 PR을 빠르고 정확하게 리뷰받고 병합할 수 있다. 예를 들어 작업이 UI 컴포넌트 개발이라면 그 내부에 필요한 하위 컴포넌트들을 먼저 성질 단위로 나누어 작업할 수도 있고, API 개발이라면 그 기능과 동작에 따라 분리하여 작업할 수도 있을 것이다. 이 부분은 나에게도 연습이 더 필요할 것 같다.
이슈 베이스 브랜치를 활용하라. 잘 분리한다 하더라도 결국에는 그 전체가 합해져야만 정상적으로 동작하는 완성된 하나의 기능일 경우가 있다. 그럴 경우에는 이슈에 전체 기능에 대한 명세와, 그 분리될 작업에 대해서도 상세히 기술한다. 그 뒤에 feature/#1234 처럼 브랜치를 만든 뒤, 이 하위에 feature/#1234/develop 과feature/#1234/feature/separate-task 와 같이 새로운 베이스 브랜치와 세부 작업에 대한 브랜치를 두고 작업하게 되면, 작은 크기의 PR을 만드는 데 도움이 될 것이다.

결론

글을 두서없이 작성하다 보니 길어지게 되었다. 이 또한 고쳐 나가야 할 점 중 하나라고 생각한다. 본론에서 언급한 여러 개선사항들은 나에게도 더 연습이 필요한 것들이 대부분이다. 사실 PR을 통한 커뮤니케이션에 있어 나에게 어떤 문제가 있긴 한데 그 문제가 무엇인지 머릿속에서 명확하지가 않아 답답했다. 그래서 이 글을 작성하게 되었으며, 정리하고 보니 스스로의 문제가 무엇인지 조금 더 명확해졌고, 어떻게 고쳐나가야 할 지도 더 생각해볼 수 있게 되었다. 이 글은 사실 회사의 미래의 주니어 개발자에게 전하는 이야기에 더 초점이 맞춰져 있긴 하지만, 당장은 스스로에 대한 고민을 정리한 글이기 때문에 많은 분들에게 생각해볼만 한 주제가 된다면 좋겠다.

긴 글 읽어주셔서 감사합니다 😂

이미지 출처: https://velog.io/@zansol/Pull-Request-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

[course] 모두를 위한 딥러닝 강좌 08

Mon, 17 Feb 2020 22:02:11 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

Lecture 8. Deep learning Basic : History

이번 강의부터 본격적으로 Deep neural network에 관한 이야기를 다룰 것이다. 이번 장은 이 딥러닝이라는 아이디어가 어떻게 시작되었는지, 그리고 어떠한 문제가 있었고 그 문제들을 인류가 어떻게 해결해왔는지에 대해서 수학적,컴퓨터적인 자세한 내용을 배제하고 설명될 것이다.

우리 인류의 궁극적인 목표는 어떻게 보면 우리를 대신해 골치아픈 문제를 대신 생각해주는 기계를 만드는 것일 것이다. 그것을 해결하기 위한 시작점은 어디였을까? 생각이라는 것은 우리가 하는 것이므로 우리, 즉 사람의 뇌를 연구하기 시작했던 것이다.

연구자들은 몇 가지 사실에 크게 놀랐는데, 하나는 우리의 뇌는 굉장히 복잡하게 연결 되어있다는 것이었고, 또 그 연결된 부분들을 자세하게 살펴보았더니 뉴런이라고 불리는 하나의 단위, 즉 unit들이 너무나 단순하게 동작하고 있다는 사실이었다고 한다. 이렇게 단순하게 동작하는데 이 것을 통해 어떻게 우리가 생각이라는 것을 한다는 것일까? 정도가 되지 않을까 싶다.

그림에서 보는 것처럼 이 뉴런(neuron)이라는 것이 동작하는 방식은 다음과 같다고 한다. 어떠한 input signal이 있고, 이를 전달해주는 것의 길이에 따라 전달되는 신호의 양이 달라지게 된다. (X * W) 이후 세포 핵에 모여서 이 신호 물질들이 하나로 합쳐지는 과정을 거친다. (sum, 즉 sigma) 그런 다음, 내부에서 말단으로 통과하는 과정에서 어떠한 항목 (bias)가 더해지면서 전달되더라는 것이다. 이 때, 이 과정에서 조금 전에 언급한 합쳐진 물질들이 어떠한 정해진 일정 값을 넘어야 활성화(activation)이 되고, 그 이하일 때에는 활성화되지 않는다고 한다. (생물학에서는 이를 역치라고 한다.)

그래서 이 사실들을 발견한 이들은 사람의 뇌에 있는 뉴런을 수학적으로 표현할 수 있지 않을까 하는 생각에서 출발하여 위와 같은 Activation Functions이라는 것을 고안해냈다고 한다. 원리는 뉴런으 동작과 같다. x라는 입력이 다른 뉴런으로부터 들어오면, synapse의 길이에 따라 다른 가중치 w와 곱해지게 되고, 여러 synapse에서 들어오는 이 값들을 모두 본체에서 더한 뒤, bias 값을 더한 이 값이 Activation Function을 통해 일정 수준을 넘으면 출력으로 예를 들어 1, 넘지 않으면 0을 내보내도록 동작하는 이러한 단순한 형태로 만들어볼 수 있겠다고 생각했었다고 한다.

위 사진의 왼 쪽에 있는 그림은 지난 강의에서 본 적이 있는 그림일 것이다. Logistic regression을 설명하기 위한 그림이었는데, 앞서 설명한 Activation function의 개념과 닮아 보인다. 이렇게 여러 입력들을 어떠한 다음 단계의 여러 unit으로 보내주어서 학습하게 된다면 우측의 그림처럼 나타날 것이다.

동일한 형태의 갖는 기계를 직접 하드웨어만 가지고도 만들 수가 있다고 한다. 아니, 실제로 과거에 만들었다고 한다. 왼쪽 기계의 사진에서 보이는 수많은 선들은 예상컨대 이전 슬라이드의 오른쪽 그림에서처럼 각 unit들을 이전 계층과 서로 연결해주는 간선의 역할일 것으로 보인다. 이 기계를 제작한지 3년이 지나, 더 발전하여 각 unit에 입력되는 가중치, 즉 w의 값을 조절하기 위한 다이얼이 추가된 형태를 볼 수 있다. 당시에는 이러한 기계들을 보면서 이러한 것들이 인공지능이라고 생각했다고 한다.

이러한 시기에 위와 같은 연구 결과와 기계들이 사람들의 많은 관심을 끌자, 연구자들은 점점 허황된 예언과 약속을 하기 시작한다. 이전 슬라이드의 왼쪽 사진에 있던 Perceptron을 만든 Frank 박사는 이 기계들을 두고 이것이 곳 걷기도 하고, 말도 하고, 볼 수도 있고, 글도 쓰며 스스로를 재생산하고, 자신의 존재를 자각하게 될 것이라고 예측했다고 한다. (지금도 못하고 있는 것들인데…) 허황된 얘기였지만, 당시로서는 어느정도 성공했다고 볼 수 있는 점이 있다.

그 당시에는 위와 같은 AND/OR 로직을 풀 수가 있다면 이것들을 조합해서 생각할 수 있는 기계를 만들 수 있을 것이라고 생각했다고 한다. 그래서 이 것을 기계가 예측할 수 있도록 하는 것이 그 당시에 굉장히 중요한 문제중의 하나였다. OR란 둘 중 하나만 참값을 가지는 것을 말한다. 두 값이 모두 0이면 거짓이 되고, 둘 중 하나, 혹은 둘 모두 1의 값을 갖는다면 참을 뜻하게 되는 것이다. AND란 이와 반대(?)로 둘 모두 참의 값을 가져야만 참을 의미하게 되고 둘 중 하나, 혹은 둘 모두 0의 값을 갖는다면 0, 즉 거짓을 의미하게 된다.

그림에서 보는 것처럼, 이 논리는 Linear한 개념이기 때문에 적당하게 선을 그어서 구분할 수 있게 된다. Binary Classification이 된다는 것이다. 그림의 +와 -가 그것이다. 때문에 당시 사람들은 박수를 치며 만들 수 있겠다는 희망에 부풀어 있었는데 여기에 찬물을 확 끼얹은 것이 마찬가지로 단순하지만, 조금 다른 XOR이라는 로직이었다. XOR이란 Exclusive OR의 줄임말로, 이 Exclusive하다는 것은 서로 같은 값일 때 거짓을 의미하게 된다는 것이다. 즉, 0과 1에 대해서는 참이지만 0과 0, 1과 1에 대해서는 거짓을 뜻한다.

이 또한 매우 단순한 로직인데, 문제는 같은 기계를 가지고 이 로직을 학습시키려고 했지만 동작하지 않는다는 것이었다. 이 로직은 Linear한 방식으로 분리되지 않기 때문에 100%로 해결되지 않고 어떻게 해도 50%만 맞을 수밖에 없어 정확도가 매우 떨어진다는 것이다.

당시 MIT AI 연구소의 수장이었던 Minsky 교수는 저서 Perceptrons에서 XOR은 현재 기술로는 해결할 수 없다는 사실을 수학적으로 증명했다. 그러면서 하나의 unit으로는 할 수 없고, 여러 개의 unit, 즉 MultiLayer Perceptrons에서는 가능할수도 있다고 했다. 하지만 동시에, 이 각각의 unit에 들어가는 W(weight)과 b(bias)를 지구상 그 누구도 학습시킬 수가 없다고 주장하며 많은 이들에게 실망감을 안겼다고 한다. 이 책에 큰 많은 사람들이 영향을 받아, neural network분야에 있어 10년 내지 20년 가량 후퇴하고 이 기간동안 침체기에 빠졌다고 한다.

이러한 침체기에 이 문제를 해결한 사람이 있었는데, Paul이라는 사람이 박사 과정 논문에 새로운 해결 방식을 소개했다. 어떠한 network이 있고, 각 unit마다 존재하는 W와 b 를 통해 학습을 진행해 출력을 만들어나가는데, 이 결과물에 해당하는 출력이 잘못되었을 때 W와 b를 조절하도록 하는 부분이 이전까지 불가능하고 문제가 되었던 부분이다. Paul이 도입한 방식은 Backpropagation(역전파)라고 불리며, network의 전반부에서 W와 b를 조절하기 어려우므로 가장 마지막 결과를 보고 발생한 에러를 다시 이름 그대로 뒤로 전달하여 값을 조정하는 알고리즘인 것이다.

그러나 앞서 말했다시피 그 당시에는 이러한 연구가 아예 불가능한 것이라고 낙인이 찍혀버린 상태였기 때문에 아무도 관심을 갖지 않았고 70년대 후반에 이르러 심지어는 이 침체기의 근원이었던 Minsky교수를 만나 이 문제를 해결했음을 알려보았지만 그 교수 또한 전혀 관심을 주지 않았다고 한다. 그럼에도 불구하고 82년도에 다시 논문을 발표해보지만 마찬가지로 아무도 읽지 않고 묻혀버렸다. 약간 어이없게도, 이와는 독립적으로 같은 연구를 진행하고 있던 Hinton이라는 사람이 86년도에 이 연구를 발표하면서, 많은 주목을 받았고, XOR과 그 이상의 더 복잡한 문제들을 예측할 수 있는 해결책이 되었다.

다른 한 편으로는 LeCun이라는 교수는 다른 방법으로 이 문제에 대해서 접근했는데, 고양이에게 여러 도형을 보여준 후에 고양이의 시신경에 있는 뉴런들이 어떻게 동작하는지를 관찰해보니 수많은 시신경들 중에서 특정 도형마다 일부의 다른 뉴런들만 활성화된다는 사실을 알아냈다고 한다. 이 실험 결과에 대한 생각에서 출발한 것이, 바로 현재에도 널리 알려져 있는 CNN(Convolutional Neural Networks)이다. 어떠한 이미지가 있을 때, 이 이미지를 Network에 한 번에 입력시키게 되면 동작이 복잡해지고 학습이 많이 일어나야 하기 때문에, 이 이미지의 부분들을 잘라서 다음 레이어로 보내는 과정을 반복하여 나중에 합치는 방법으로 Network을 개발했다고 하며 우리가 익히 아는 AlphaGo도 이 CNN이 적용되었다고 한다. 현재에도 문자와 숫자 이미지에 대한 정확도가 90%를 넘을 정도로 잘 동작하기 때문에 수표가 널리 사용되는 미국에서는 90년도에 수표를 읽어내는 시스템을 만들기도 했다고 한다.

84년부터 94년까지 카네기 멜론 대학교에서 자율주행 자동차 프로젝트를 진행하기도 했고, 91년에 개봉한 영화 터미네이터의 대사에서도 사람처럼 학습할 수 있냐는 질문에 터미네이터는 자신의 CPU가 neural-net으로 되어 있어 학습하는 컴퓨터라고 대답하기도 한다. 이처럼 Hinton의 논문을 통해 다시 부흥을 맞는 줄 알았던 Neural network 분야는 95년도에 다시 한번 큰 문제에 봉착하게 된다.

긴 침체기를 깨고 다시 많은 사람의 주목을 받게 되었던 계기인 역전파 알고리즘은 Layer를 몇 개만 가지고 있는 Network에서는 잘 동작을 하는데 실제로 복잡한 문제를 풀기 위해 필요한 Network에서는 10여 개 정도의 Layer를 필요로 하기 때문에 제대로 동작하지 않는다. Backpropagation은 가장 마지막으로 출력되는 결과값을 비교하여 그 Error를 다시 끝에서부터 입력 부분까지 전달하면서 값을 바꾸는 것인데, 층을 거듭할수록 그 에러의 의미가 퇴색된다. 또한 가장 중요하게 W와 b값이 변경되어야 하는 부분은 입력 부분인데 이와 같은 이유 때문에 역전파로는 입력 부분까지 값을 조절하면서 학습이 이루어지기 힘들다는 것이다. 때문에 한편으로는 다른 형태의 알고리즘들이 다수 등장하기 시작했는데, 어떻게 보면 Neural Network보다 훨씬 간단한 알고리즘인데 더 잘 동작하는 것이었다. 급기야 앞서 등장한 바 있는 LeCun 교수조차 자신도 이 인공신경망 분야의 전문가이지만, SVM이나 RandomForest와 같은 대체 알고리즘들이 훨씬 쉽고, 잘 동작하는 사실을 인정했다고 한다.

이렇게 다계층 학습 문제 해결이라는 벽을 만나면서 Backpropagation이 유일한 해결책이던 인공신경망 분야는 이렇게 두 번째 침체기를 맞게 되고, 대중들의 신뢰도 많이 잃었다고 한다.

이야기를 계속하기 전에, 한 단체를 언급하고 넘어가야 하는데, CIFAR라는 이름의 단체이다. 이 연구 기관은 당장 가까운 미래에 직접적으로 사용되지 않는 주제일지라도 계속해서 연구할 것을 장려했고, 지금까지 이야기한 것처럼 neural network이라는 제목만 들어가도 논문이 reject되고, 더이상의 연구비를 지원받기도 어려웠던 당시의 냉랭했던 이 분야의 전문가였던 Hinton 교수는 여기에 매력을 느껴 캐나다로 이주하게 되어 이후의 연구에 대해서 지원을 받을 수 있었다고 한다. 이 때문인지 최근 딥러닝 분야의 발전을 주도하고 있는 많은 학교와 연구자들이 캐나다 출신이라고 한다. 당시를 회고했을 때, 가장 힘든 시기라고 이야기할 만큼 이 분야에 대해 어려웠던 시기에 도박을 걸었던 이 단체에 크게 칭찬하지 않을 수 없다고 한다.

이러한 지원에 힘입어 Hinton과 Bengio 교수는 이 시기에 큰 돌파구가 될 논문을 2006년, 2007년에 각각 발표했다. 이 논문의 주요한 내용을 살펴보면, 지금까지의 큰 장벽이었던 여러 계층에 있어서의 학습 문제는, 각 Layer마다 W 값들은 처음에 초기값을 줘서 학습을 진행하게 되는데 이 처음에 주어진 초기값을 제대로 주지 못한 것이 원인이었다는 것이다. 이 초기값만 잘 주면 학습을 시킬 수 있다는 것이 2006년 발표된 논문의 주 내용이다. 2007년도 논문에도 같은 내용을 담고 있었으나 더 나아가 이를 통해 기존의 신경망을 더 깊게 구축하면 더 복잡한 문제를 해결할 수 있다는 사실을 증명한 것이다. 이 논문들을 통해 다시 사람들에게 한 번 더 주목받는 계기가 되었는데, 이 과정에서 neural network이라는 이름 때문에 사람들이 거부감을 갖지 않도록 하기 위해 Deep learning으로 이름을 바꿔 마치 다른 학문 분야인 것처럼 다가가게 되었고 이때부터 다시 많은 연구가 활성화되었다.

이렇게 점점 분야가 활발해지면서, 대중적으로 주목을 받게 된 계기가 또 하나 있는데, 이 IMAGENET이라는 이름의 컴퓨터에게 어떤 사진을 주고 이 사진을 묘사하는 내용을 맞춰보도록 하는 챌린지이다. 이를 정확하게 묘사하고 맞추는 것은 사실 쉽지만은 않은 일이다. 따라서 컴퓨터비전 분야에서는 이 문제를 굉장히 중요하게 다루고 있었는데, 2010년에는 30% 정도의 에러율을 가지고 있었고 해를 거듭하면서 1~2%정도의 개선을 보이고 있었다. 사실 이 기술은 정확도가 90%정도에 육박해야지만 실제로 적용할 수 있는 성능을 보인다고 판단하여 해당 범위에 들어가려면 못해도 10년정도는 걸릴 것이라고 모두가 예측하고 있는 상황이었다. 그런데 2012년에 ALEX 박사의 논문에서, ALEXNET이라는 이름의 시스템이 이 에러율을 15%정도로 확 줄여내어 많은 이들을 깜짝 놀라게 하였다. 이 시기부터 CNN이 접목되었던 시기였으며 해를 거듭하면서 에러율이 큰 폭으로 감소하다가 결국에 2015년에 만들어진 CNN기반의 시스템에서 3%대의 에러율까지 도달하게 되었다.

이렇게 매우 빠른속도로 Deep Learning 분야가 발젼하게 되면서 하나하나 다 읊어낼 수 없을 정도로 많은 기술의 발전이 일어나고 있었다. 몇 가지 예를 들면

이미지에 대한 단순 묘사가 아닌 문장 수준의 설명
딥 API Learning (API의 동작과 절차를 단순한 명령어를 통해 처리) - 홍콩과기대
Noise가 많은 환경에서 90%까지 사람의 말을 알아든는 시스템 - 바이두
딥러닝 기반의 벽돌깨기 자동화
우리가 너무나도 잘 아는 AlphaGo

그리고 현대에 이르러, 우리 실생활에서도 밀접하게 녹아있는 기술들도 있다.

유튜브 자동 생성 자막 - 영어는 꽤 정확함
페이스북 뉴스피드 - 사용자 개인화 추천 알고리즘
구글 검색 엔진 - 검색어 기반 및 개인 관련성 추천 알고리즘
넷플릭스 비디오 추천 시스템
아마존 상품 추천 시스템

위 두 슬라이드들은 교수님이 이번 강의를 진행하시면서 수강생들에게 이 분야에 대해서 약간의 홍보(?)를 하시는 듯한 느낌을 받았다. 요약하자면, 지금 당장 이 분야의 연구자라거나 컴퓨터 과학자가 아니더라도 데이터를 가지고 있거나 사업을 하고 있는 사람이라면 충분히 관심을 가져볼만한 분야라는 것이고, 시기적으로도 학생이나 연구자들에게 있어서는 지금까지 설명한 것처럼 크게 성장한 기간이 그리 길지 않은 분야이기 때문에 지금 뛰어들어도 여러분도 전문가가 될수 있다는 이야기, 실용주의자들에게는 현재 나와있는 많은 이론들이 꽤 실질적이고 정확하며, TensorFlow와 같이 잘 만들어진 툴도 많이 있는데다가 Python처럼 시작하기에 매우 쉽고 간단한 언어들도 있다는 이야기를 전달하는 내용이었다.

맺음말

학교에서 진행하는 프로그램 때문에 자습 목적으로 진행한 연재 방식의 글을 제대로는 처음으로 진행해보았습니다. 앞으로 학기가 시작하면서 졸업 프로젝트 마무리에 박차를 가해야 하기 때문에 머신러닝을 실질적으로 많이 다루게 될 것 같지만, 이렇게 온라인 강의를 들으면서 직접 글로써 정리하는 일 자체가 아시다시피 매우 귀찮고 번거로운 일이기 때문에, 실제 프로젝트 진행에 필요한 개념들과 이론적인 내용을 부분적으로 학습할 듯 보이고, 또 기본적이고 기초가 되는 내용들은 지금까지의 강의들을 통해서 충분히 정리했다고도 생각하고 있기 때문에 잠정적으로 아니, 거의 확정적으로 중단하도록 하겠습니다.

아마도 같은 제목으로 새로운 글이 연재될 일은 없을 것으로 보이고, 만약 그렇다고 한다면 제가 모든걸 다 제치고 인공지능과 데이터 과학 분야로 진로를 정하고 여기에 올인해서 다시 공부를 시작한다는 시나리오 밖에는 없을 것 같습니다. 시작한지도 얼마 되지 않았고 인강 내용을 정리한 글밖에 없는 블로그라 누가 읽었을 것이라고 생각도 하지 않지만, 지금까지 읽어주신 분들이 계시다면 감사드리면서 이번 연재는 여기서 마치도록 하겠습니다.

앞으로 이 블로그에 게시되는 글과 함께 더욱 더 성장하는 개발자가 되도록 하겠습니다. 감사합니다.

[course] 모두를 위한 딥러닝 강좌 07

Mon, 03 Feb 2020 20:02:58 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

Lecture 7. Application & Tips

이번 강의는 Machine Learning Algorithm을 실제로 적용함에 있어서 중요한 몇 가지 팁들에 대해서 알아 볼 것이다.

팁들에 대한 주제의 갈래는 크게 다음과 같다.

Learning rate
Data preprocessing
Overfitting

Learning rate

그림은 우리가 지금까지 Cost function을 정의하고, 그 Cost 값을 최소화(Minimize) 하기 위해 사용한 알고리즘인 경사 하강법(Gradient descent)에 대해 보여주고 있다.

이 알고리즘을 적용할 때, 특정 W값에 대해 cost function을 미분한 기울기를 구하고 거기에 우리가 임의로 정한 learning rate라는 것을 곱으로 적용함으로서 최소 비용을 찾는 데에 활용해왔고 그 용법은 상단에 보이는 소스코드에서와 같았다.

Large learning rate

만약에 우리가 모델을 설계하면서 learning rate를 너무 크게 잡았다고 가정해보자. 학습을 시작하게 되면 가장 처음에 무작위의 지점에서 시작을 하게 될 것인데, learning rate란 앞서 언급했듯이 기울기 앞에 곱해지는 상수 값이므로 기울기를 타고 내려가는 한 발짝의 step이라고 생각하면 될 것이다. 이 step이 너무 크다고 하면 cost가 최소가 되는 지점을 찾지 못하고 우리의 cost function 그래프의 양 옆을 그저 왔다갔다만 하게 되어버린다는 것이다.

그리고 이 learning rate가 매우 크다고 한다면 학습이 제대로, 아니 아예 이루어지지 않을 뿐만 아니라 이미 우리가 초기에 설정된 지점만큼의 값보다 더 크다고 한다면 최소 지저이 존재하는 가운데로 수렴하지 못하고 그래프의 바깥 부분으로 발산하게 되므로 학습 과정에서 cost 함수를 출력해보면 숫자가 아닌 값이 나올 수도 있다.

이렇듯 너무 큰 learning rate를 가지는 경우를 Overshooting이라고 부른다.

Small learning rate

반대의 경우도 마찬가지로 학습 과정에 있어 좋지 않은 영향을 미친다. 이러한 경우, cost 함수를 학습 과정과 함께 iteration 과정에서 출력해보았을 때, cost 값이 매우 작은 폭으로 변화하는 것을 확인할 수 있다.

이러한 상황에서는 최소 지점을 찾는 데에 너무 많은 시간이 소요될 뿐만 아니라, 학습 과정이 짧다면 최소 지점에 전혀 도달하지도 못하고 local minimum에서 멈춰버리게 되는 것이다.

Try several learning rates

Observe the cost function
Check it goes down in a reasonable rate

이상적인 learning rate를 구하는 데에는 아쉽게도 정답은 없다. 각자가 가진 데이터와 환경에 따라 다르기 때문에 어찌 보면 당연하다. 때문에 대부분의 경우 0.01로 처음 learning rate를 설정하곤 하는데, 이 값으로 인해 cost가 발산이 된다고 하면 조금 더 작게, 너무 느리게 움직인다고 하면 조금 더 크게, 이러한 방식으로 조율해나가는 것이 좋다.

Data preprocessing

우리가 가지고 있는 데이터, 특히 feature data라고 하는 x_data를 전처리해야 할 필요성이 가끔씩 존재한다. 이 상황은 주로 weight가 여러 개일 때에 주로 나타나는데, 여기서는 weight가 2개인 경우에 대해서 살펴보도록 한다. 그림의 그래프를 살펴보면 나이테와 같은 모양을 한 것을 볼 수 있는데, cost 축을 z축으로 하는 3차원 그래프를 떠올리면 될 것 같다. 따라서 w1과 w2에 대한 2차원 그래프에서는 이처럼 여러 개의 원으로 보일 수 있는 것이다.

간단하게 지금까지 살펴보았던 밥그릇 모양의 cost function을 위에서 바라봤다고 생각하자. 그러면 이 그래프에서는 중심이 최소 cost를 갖는 지점이 될 것이며 마찬가지로 무작위의 지점에서 학습을 시작하게 되어 경사면을 타고 중심을 향해 내려가게 될 것이다.

좌측의 표와 같이 x1,x2 두 개의 feature data를 갖는 데이터가 있다고 생각해보자. cost 함수는 이 x1과 w1, x2와 w2를 각각 곱해서 더한 값을 최소화하는 방향으로 나아갈 것인데, 표를 살펴보면 이 x1과 x2 값이 서로 매우 큰 차이를 보이기 때문에 이를 우측의 w1,w2 축으로 이루어진 그래프에 위에서 살펴본 것과 같은 등고선 형태의 그래프를 그리게 되면 옆으로 넓고 납작한 모양으로 그려지게 될 것이다. 그림은 2차원에서 살펴본 모습이지만, 다차원에서도 마찬가지로 한 쪽으로 치우친, 매우 왜곡된 형태가 나타나게 될 것이다.

x_data간에 값의 매우 큰 차이가 발생하기 때문에 이 그래프 또한 한 쪽으로만 왜곡되어 성장하는 형태를 가지게 된다. 이 때문에 그래프를 이루는 선분들 간의 폭이 매우 좁기 때문에 alpha값, 즉 learning rate가 매우 좋은 값이더라도 그래프 위의 파란 선분과 같이 조금이라도 잘못되면 중심으로 향하지 못하고 그래프 바깥으로 튀어 나간다는 것이다.

그래서 이렇게 데이터 값 사이에 큰 차이가 있을 경우 Normalize할 필요가 있다고 한다.

Normalize

우리가 가진 Original Data의 분포가 왼쪽 그래프와 같이 흩어져 있다고 했을 때, 보통 사용되는 방법으로 zero-centered data 라고 불리는 데이터 값의 중심이 0으로 이동하도록 조정하는 작업을 일컫는다. 또, 가장 많이 사용되는 방법으로 어떠한 값의 범위가 어떠한 형태의 범위 안에 항상 들어가도록 normalize하는 것이다.

learning rate도 잘 잡은 것 같은데 이상하게 학습이 이루어지지 않고 cost가 발산한다거나 정상적이지 않은 동작을 보인다면 data set 중에 차이가 크게 나는 데이터들이 있는지, 데이터 pre-processing 과정을 거쳤는지 한 번 점검해 볼 필요가 있다고 한다.

Standardization

normalize를 수행하는 방법은 간단하다. x_data를 x_data값에서 평균 값을 빼고, 계산한 분산 값으로 나누어 재설정해주면 된다. python 코드로 나타내면 그림의 하단과 같은데, 특히 이러한 형태의 normalize를 standardization이라고 하며 여러가지 다른 형태의 normalization 또한 존재한다. 이러한 normalization 과정을 통해 x_data를 이렇게 처리 해보는 것이 실제로 좋은 성능을 발휘하기 위한 좋은 방법일 수 있다고 한다.

Overfitting

Our model is very good with training data set (with memorization)
Not good at test data set or in real use

다음으로는 머신러닝에 있어 가장 큰 문제인 Overfitting이다. Overfitting이라는 것은 한 마디로 머신러닝이 학습을 통해서 모델을 만들어 나가는데, 그러다보니 이 학습 데이터에만 딱 맞는 모델을 만들어낼 수 있다는 것이다.

이렇게 되면, 학습 데이터를 가지고 질문을 하면 제대로 된 대답을 하겠지만, 시험용 데이터나 실제 데이터를 가지고 테스트를 해보면 제대로 된 답을 하지 못한다는 것이다.

Example of overfitting

위의 그림과 같이 +와 -를 구분하도록 하는 문제가 주어졌다고 하자. 일반적으로 생각할 때 좌측과 같이 구분할 수 있을 것이다. 그러나 우리의 학습 모델은 우측과 같이 주어진 training data set에만 정확하게 일치하도록 학습을 하기 때문에 다른 data set과 함께 같은 문제를 던져도 올바른 대답을 하지 못할 가능성이 높다. 따라서 좌측과 같은 모델이 다른 데이터와도 잘 맞을수 있기 때문에 좋은 모델이라 할 수 있고 우측과 같은 모델은 Over fitting되었다고 이야기 할 수 있다.

그렇다면 어떻게 Overfitting을 줄일 수 있을까 ?

Solutions for overfitting

More training data!
Reduce the number of features
Regularization

이러한 문제를 극복하기 위해서는 여러 데이터의 상황을 학습할 수 있도록 매우 많은 학습 데이터를 가지고 학습시키거나, 중복되는 feature data를 삭제하는 등의 노력을 할 수 있을 것이다.

또 다른 기술적인 방법으로, 일반화 시킨다는 의미로 Regularization이 있다.

Regularization

Let’s not have too big numbers in the weight

주로 Overfitting이라고 설명할 때, 데이터의 Decision boundary를 위의 그림과 같이 특정한 데이터에 맞게 구부리게 되는 것 자체를 Overfitting이라고 하는데, Regularization은 이 구부러지는 것을 하지 말고 펴자라는 뉘앙스로 생각하면 되겠다.

여기서 편다는 작은 weight 값을 갖는다는 의미이고, 구부린다는 의미는 어떤 weight 이 큰 값을 가질 때를 의미한다.

이 W의 값이 크면 클수록 구부러진다고 했으므로 쫙쫙 펴도록 다음과 같은 방법을 사용할 수 있다.

W의 각 엘리먼트를 제곱하여 하나로 합한 값을 cost 값에 더해주어 함께 학습시킴으로서 이 W값 또한 최소가 되도록 하는 방향으로 학습하게 될 것이다. 그 앞에 lambda와 같은 모양의 상수가 있음을 볼 수 있는데, 이 것을 regularization strength라고 부른다고 한다. 이 값이 0이 되면 regularization을 사용하지 않겠다는 의미가 될 것이고, 1이 되면 regularization을 매우 중요하게 생각한다는 의미가 될 것이다. 따라서 이 값 또한 learning rate와 마찬가지로 사용자의 입장에서 정할 수 있다는 것이다.

이 것을 TensorFlow에서 구현하려고 한다면 매우 간단하다.

l2reg = 0.001 * tf.reduce_sum(tf.square(W))
cost = cost + l2reg

위와 같이 작성하여 이 cost를 minimize하는 알고리즘을 적용시키게 되면, 그 모델은 Overfitting되지 않은 모델이 될 가능성이 높아질 것이다.

Performance Evaluation

우리는 지금까지 머신 러닝 모델을 데이터를 가지고 학습을 시켰다. 그런데 이 모델이 얼마나 훌륭한지, 얼마나 성공적으로 예측하는지를 평가하려면 어떻게 해야 할까?

우리는 위와 같은 형태의 데이터 셋을 통해 모델을 학습시켜왔는데, 만약 이렇게 학습한 모델에게 이 데이터 셋에 포함된 요소를 입력으로 주면 어떻게 될까 ? 매우 정확한 예측 값을 출력할 것이다. 왜냐하면 앞에서 말했다시피, 모델은 이 데이터를 기반으로 학습을 진행했기 때문이다. 모델은 당연하게도, 학습한 내용을 기억하고 있기 때문에 이미 알고 있는 것을 질문하게 된다면 기억하고 있는 실제 값을 출력할 것이다. 따라서 이와 같이 테스팅을 할 때, 이미 학습에 사용한 데이터 셋에 포함된 데이터를 가지고 테스트를 하는 것은 매우 좋지 않으며 무의미한 행위라고 할 수 있다.

이 것을 실생활에 비유하여 예를 들자면, 마치 학교에서 시험을 보는데, 이미 한 번 시험을 본 문제와 동일한 문제를, 그것도 답을 알려준 상태에서 중간고사를 보는 것과 유사한 뉘앙스라고 볼 수 있으며 마찬가지로 좋지 않은 방법이라는 것이다.

그렇다면 학습시킨 모델을 테스트하는 좋은 방법은 무엇일까?

Training and Test set

일반적으로, 활용할 수 있는 전체 데이터의 7:3 으로 나누어 구분지어두고, 70%를 모델 학습을 위한 training data set, 30%를 테스트를 위한 test data set 으로 구분지어 활용한다고 한다. 이렇게 구분한 뒤에 test set은 절대로 학습 과정에 포함시키지 않고 존재하지 않는 데이터라고 생각해야 한다.

이렇게 70%에 해당하는 데이터, training set을 통해 우리의 모델을 학습시키는 과정이 완벽히 끝났다고 생각될 때, 나머지 30%에 해당하는 test set을 학습이 완료된 모델에 입력을 주고, 모델이 test set의 x_data에 대해 예측하는 Y hat 값과 실제 test set 의 y_data 값을 비교하여 정확도를 예측할 수 있으며 이것이 올바른 모델 평가 방법이다.

마찬가지로 여기에 비유하자면, training set은 교과서라고 볼 수 있고 test set은 실제로 시험장에 들어가서 마주하는 시험지의 문제라고 볼 수 있겠다. 따라서 이렇듯 머신 러닝 모델도 training set과 test set을 반드시 나누어 적용하고 평가해야 한다는 것이다.

조금 전까지 이야기했던 것처럼 training set과 test set 이렇게 두 가지로 데이터를 구분하는 것이 일반적인데, 그림에서 보는 것과 같이 이 training set을 또 두 가지로 나누어 둔 것을 볼 수 있을 것이다. 적혀있듯이 Validation이란, 위에서 살펴보았던 learing rate 혹은 lambda 와 같은 학습에 필요한 상수 값을 tuning할 필요가 있을 때 이를 주로 평가하기 위한 목적으로 사용된다. 학습 과정에서 이런 상수 값들 또한 학습의 성패에 영항을 미치게 되므로 이들 또한 올바른 값을 가져야 하기 때문에 이를 조율하기 위한 데이터를 별도로 분리하는 것이다.

여기서도 같은 비유를 적용하자면, 교과서를 통해 우리가 열심히 공부를 하고(training set) 실제로 시험장에 들어가서 시험을 보기 전에 (test set), 실전 모의고사를 푸는 것을 validation set 으로 빗대어 생각해볼 수 있을 것이다.

Online learning

그리고, 학습 시키려는 데이터가 너무 많아 한 번에 학습을 시키기가 힘든 경우가 있을 수 있다. 이럴 때 Online-learning이라는 형태의 학습 방법을 적용시켜 볼 수도 있다.

예를 들어 training set이 100만 개가 있다고 할 때, 이를 한 번에 학습시키려면 메모리와 저장 공간도 많이 필요하기도 하고 현실적으로 어려운 상황이기 때문에 이를 10만개 씩 나누어 차례대로 학습시키는 것이다. 이 때, 이전 데이터로 학습한 결과가 모델에 남아있어야 한다. 그래야만 다음 데이터를 학습시킬 때, 여기에 추가적으로 학습이 되어야 한다는 것이다.

이러한 방식을 Online learning이라고 하며, 좋은 방법인 이유는 위처럼 100만개의 데이터를 바탕으로 학습을 시켰는데, 시간이 흐른 뒤 기존 것에 추가된 10만개의 데이터가 있다고 할 때, 이를 처음부터 다시 새로 학습시키는 것이 아니라, 이미 100만개를 학습한 모델에 추가적으로 새로운 10만개를 학습시키면 되는 것이기 때문에 Online이라고 부르며 매우 유용하다고 한다.

실제 데이터를 한 번 살펴보자. 이 것이 유명한 MNIST Dataset인데, 이 것은 사람이 손으로 직접 적은 숫자를 컴퓨터가 이를 이해할 수 있도록 학습시키고 테스트하는 데이터 셋이라고 한다. 이 것이 필요했던 이유는, 미국 우체국에서 사람이 손으로 적은 알아보기 힘든 우편 번호(Zip code)를 분류하는 것을 기계 학습을 통해 자동화 하고자 했기 때문이라고 한다.

빨간 글씨를 보게 되면, 우리가 조금 전에 배운 것과 같이 training set과 test set이 나누어져 있는 것을 알 수 있을 것이다.

Accuracy

결론적으로 우리가 test set을 가지고 우리가 학습시킨 모델이 얼마나 정확한지를 측정하기 위해서는 우리가 가진 test set의 실제 데이터 Y값(label 값)과 우리 모델이 예측한 값 Y hat을 비교해서 예측을 시도한 개수와 일치한 개수를 백분율로 환산하여 그 값을 비율로서 측정하면 되겠다. 최근 들어, 분야에 따라 다르지만 이미지 처리 분야에서는 이 정확도 측면에서 95%를 넘어서고 있다고 한다.

TensorFlow Practice

이번 실습에서 가장 중요한 포인트는 우리가 가지고 있는 data set을 training set과 test set으로 구분하여 사용한다는 것이다. 이전까지의 실습에서는 이러한 구분이 없이 우리가 가지고 있는 데이터를 통해 모델을 학습시키고, 테스트도 했었지만 엄밀히 말하면 이 방법은 틀린 것이다. 지금까지는 예시를 간단히 하기 위해 그렇게 했었지만, 이제부터는 반드시 데이터 셋을 구분하여 사용할 것이다.

그러면 나누어서 어떻게 하는가? training set은 이름 그대로 이 데이터는 모델을 학습시키기 위해서만 사용한다. 이렇게 학습이 완료되었다면 그 시점에서 test set을 도입하는데, 이 데이터는 모델의 입장에서 지금껏 한 번도 본 적이 없는 데이터이다. 이 데이터를 통해 모델이 예측한 값을 평가함으로써 공정한 평가가 가능하다는 것이다. test set은 비밀 데이터처럼 숨겨두었다가 학습이 끝난 다음에, 모델을 테스트하기 위해서만 사용한다.

Practice 1

데이터만 두 분류로 구분되었을 뿐, 파이썬 코드를 작성하는 방식은 변하지 않았다. X,Y 데이터에 대한 placeholder와 W,b를 선언한 뒤 hypothesis와 cost, optimizer를 차례로 명세한 뒤에 이미 살펴본 적이 있는 바와 같이 prediction과 accuracy를 정의한 뒤에 세션을 시작하고, 변수들을 초기화해준 뒤, 학습을 시키는데, 이 과정에서 training set에 포함된 데이터만 feed_dict를 통해 전달해준다. 여기서 placeholder의 장점이 나타나는 것이다. 이후에 이미 정의해둔 예측 값과 정확도를 검증하기 위해 세션을 통해 해당 변수를 실행할 때, 이 때 test set 이 사용되는 것이다.

아래는 이 예제에 대한 전체 코드와 출력 예시이다.

# Lab 7 Learning rate and Evaluation
import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

# Model Training by this training dataset
x_data = [[1, 2, 1],
          [1, 3, 2],
          [1, 3, 4],
          [1, 5, 5],
          [1, 7, 5],
          [1, 2, 5],
          [1, 6, 6],
          [1, 7, 7]]
y_data = [[0, 0, 1],
          [0, 0, 1],
          [0, 0, 1],
          [0, 1, 0],
          [0, 1, 0],
          [0, 1, 0],
          [1, 0, 0],
          [1, 0, 0]]

# Evaluation our model using this test dataset
x_test = [[2, 1, 1],
          [3, 1, 2],
          [3, 3, 4]]
y_test = [[0, 0, 1],
          [0, 0, 1],
          [0, 0, 1]]

X = tf.placeholder("float", [None, 3])
Y = tf.placeholder("float", [None, 3])

W = tf.Variable(tf.random_normal([3, 3]))
b = tf.Variable(tf.random_normal([3]))

# tf.nn.softmax computes softmax activations
# softmax = exp(logits) / reduce_sum(exp(logits), dim)
hypothesis = tf.nn.softmax(tf.matmul(X, W) + b)

# Cross entropy cost/loss
cost = tf.reduce_mean(-tf.reduce_sum(Y * tf.log(hypothesis), axis=1))
# Try to change learning_rate to small numbers
optimizer = tf.train.GradientDescentOptimizer(learning_rate=0.1).minimize(cost)

# Correct prediction Test model
prediction = tf.argmax(hypothesis, 1)
is_correct = tf.equal(prediction, tf.argmax(Y, 1))
accuracy = tf.reduce_mean(tf.cast(is_correct, tf.float32))

# Launch graph
with tf.Session() as sess:
    # Initialize TensorFlow variables
    sess.run(tf.global_variables_initializer())

    # Training Step
    for step in range(201):
        #feeds training dataset
        cost_val, W_val, _ = sess.run([cost, W, optimizer], feed_dict={X: x_data, Y: y_data})
        print(step, cost_val, W_val)

    # Test step
    # predict
    print("Prediction:", sess.run(prediction, feed_dict={X: x_test})) # feeds test dataset
    # Calculate the accuracy
    print("Accuracy: ", sess.run(accuracy, feed_dict={X: x_test, Y: y_test}))

'''
각 학습 과정에 따른 출력 - step, cost값, W벡터 순서
0 5.73203 [[ 0.72881663  0.71536207 -1.18015325]
 [-0.57753736 -0.12988332  1.60729778]
 [ 0.48373488 -0.51433605 -2.02127004]]
1 3.318 [[ 0.66219079  0.74796319 -1.14612854]
 [-0.81948912  0.03000021  1.68936598]
 [ 0.23214608 -0.33772916 -1.94628811]]
...
199 0.672261 [[-1.15377033  0.28146935  1.13632679]
 [ 0.37484586  0.18958236  0.33544877]
 [-0.35609841 -0.43973011 -1.25604188]]
200 0.670909 [[-1.15885413  0.28058422  1.14229572]
 [ 0.37609792  0.19073224  0.33304682]
 [-0.35536593 -0.44033223 -1.2561723 ]]

test dataset을 통한 학습 성공 평가에 대한 출력.
예측 값과 이 예측이 정확하게 일치하는 것을 볼 수 있다.

Prediction: [2 2 2]
Accuracy:  1.0 #
'''

Learning rate: NaN

이론 시간에 알아보았듯이 learning rate가 올바른, 좋은 값으로 결정되지 않았을 때 두 가지 종류의 문제가 발생한다. Learning rate이란 한 지점에서 구한 기울기 값이 다음 step에서 얼마만큼 움직일 것인가에 대한 가중치 값인데, 첫 번째 경우는 이 값이 너무 클 경우이다.

우리는 W값의 변화가 작게 움직이길 바라는데, learning rate가 너무 크다면 그래프 내에서 이동이 매우 큰 폭으로 점프하게 될 것이다. 학습 중 이러한 과정이 반복된다면 W값은 점점 더 큰 폭으로 변하면서 결국에는 계속해서 바깥으로 값이 튕겨나가 버리게, 발산하게 될 것이다.

반대로 이러한 경우를 조심하려는 차원에서 learning rate 값을 너무 작은 값으로 준다면 학습이 굉장히 더디게 일어날 것이며, 나아가 cost function의 중간에 일정치 않은 폭의 변화가 있다고 한다면 이 최소점을 찾지 못하고 local minimum에 갇혀버리게 될 것이다.

앞서 보았던 소스코드와 완전히 동일하지만 learning rate 값에만 변화를 주고 앞서 설명한 내용을 직접 결과로 확인해보도록 하자.

optimizer = tf.train.GradientDescentOptimizer(learning_rate=1.5).minimize(cost)
# 더 과감하게 10.0과 같은 값을 줘도 된다.

실행 결과는 아래와 같다.

'''
when lr = 1.5
0 5.73203 [[-0.30548954  1.22985029 -0.66033536]
 [-4.39069986  2.29670858  2.99386835]
 [-3.34510708  2.09743214 -0.80419564]]
1 23.1494 [[ 0.06951046  0.29449689 -0.0999819 ]
 [-1.95319986 -1.63627958  4.48935604]
 [-0.90760708 -1.65020132  0.50593793]]
2 27.2798 [[ 0.44451016  0.85699677 -1.03748143]
 [ 0.48429942  0.98872018 -0.57314301]
 [ 1.52989244  1.16229868 -4.74406147]]
3 8.668 [[ 0.12396193  0.61504567 -0.47498202]
 [ 0.22003263 -0.2470119   0.9268558 ]
 [ 0.96035379  0.41933775 -3.43156195]]
4 5.77111 [[-0.9524312   1.13037777  0.08607888]
 [-3.78651619  2.26245379  2.42393875]
 [-3.07170963  3.14037919 -2.12054014]]
5 inf [[ nan  nan  nan]
 [ nan  nan  nan]
 [ nan  nan  nan]]
6 nan [[ nan  nan  nan]
 [ nan  nan  nan]
 [ nan  nan  nan]]
 ...
Prediction: [0 0 0]
Accuracy:  0.0
'''

학습이 진행되는 각 step마다 출력을 통해 값의 변화를 살펴볼 수 있었는데, 초기 cost 값이 5에서 시작하여 23으로 점프하더니 학습 반복 6회차부터 무한대로 발산하여 W값이 NaN (Not a Number)이 되어버리고, cost값마저 NaN이 되어버림을 확인할 수 있었다. 때문에 학습을 시키는 도중에 숫자가 나와야 하는 출력에서 nan이라는 값이 나오는 것을 확인한다면 learning rate로 너무 큰 값을 준 것이 아닌지 의심해볼 필요가 있다는 것이다.

반대로 learning rate이 매우 작은 경우의 결과를 살펴보자.

optimizer = tf.train.GradientDescentOptimizer(learning_rate=1e-10).minimize(cost)

'''
When lr = 1e-10
0 5.73203 [[ 0.80269563  0.67861295 -1.21728313]
 [-0.3051686  -0.3032113   1.50825703]
 [ 0.75722361 -0.7008909  -2.10820389]]
1 5.73203 [[ 0.80269563  0.67861295 -1.21728313]
 [-0.3051686  -0.3032113   1.50825703]
 [ 0.75722361 -0.7008909  -2.10820389]]
...
199 5.73203 [[ 0.80269563  0.67861295 -1.21728313]
 [-0.3051686  -0.3032113   1.50825703]
 [ 0.75722361 -0.7008909  -2.10820389]]
200 5.73203 [[ 0.80269563  0.67861295 -1.21728313]
 [-0.3051686  -0.3032113   1.50825703]
 [ 0.75722361 -0.7008909  -2.10820389]]
Prediction: [0 0 0]
Accuracy:  0.0
'''

마찬가지로 여기서도 cost 값의 출력을 통해서 학습 상태를 유추해볼 수 있는데, 0에서 잡힌 cost 값이 5.73203이었는데 200회 반복을 통해도 값이 변하지 않는 것을 확인할 수 있다. W벡터 내의 값들도 마찬가지이고, 학습이 전혀 진행되고 있지 않음을 알 수 있다. 따라서 학습 과정에서 이처럼 cost 값의 변화가 현저하게 적은 것을 출력으로 확인하게 된다면 learning rate가 너무 작은 것이 아닌지를 의심해봐야 한다는 것이다.

Non-normalized inputs

이렇게 learning rate를 잘 조절했음에도 불구하고 무시무시한 nan을 만나게 될 수도 있다. 이 이유중에 하나가 Data가 Normalize 되어있지 않을 경우이다.

xy = np.array([[828.659973, 833.450012, 908100, 828.349976, 831.659973],
               [823.02002, 828.070007, 1828100, 821.655029, 828.070007],
               [819.929993, 824.400024, 1438100, 818.97998, 824.159973],
               [816, 820.958984, 1008100, 815.48999, 819.23999],
               [819.359985, 823, 1188100, 818.469971, 818.97998],
               [819, 823, 1198100, 816, 820.450012],
               [811.700012, 815.25, 1098100, 809.780029, 813.669983],
               [809.51001, 816.659973, 1398100, 804.539978, 809.559998]])

이러한 데이터가 있다고 했을 때, 데이터들을 살펴보면 1,000에 가까운 큰 값들로 이루어져있는데 중간중간에 100,000 내외의 큰 편차가 있는 매우 큰 숫자들이 존재하는 것을 살펴볼 수 있다. 이런 값들을 그대로 사용하게 된다면, Cost function을 위에서 내려다봤을 때 이러한 형태의 한쪽 방향으로 치우친 그래프가 형성된다.

이러한 그래프를 갖는 cost function의 문제점은 어떤 임의의 점에서 cost를 minimize하기 위해서 경사를 타고 내려오게 될텐데, 그래프의 하향 변화 폭이 W의 클래스에 따라서 일정치가 않기 때문에 중앙을 향해 내려오면 좋겠으나 바깥으로 튕겨 나가버릴 가능성이 존재하게 된다.

Linear regression에 대한 예제 전체 코드를 한 번 살펴보도록 하자.

import tensorflow as tf
import numpy as np
tf.set_random_seed(777)  # for reproducibility


xy = np.array([[828.659973, 833.450012, 908100, 828.349976, 831.659973],
               [823.02002, 828.070007, 1828100, 821.655029, 828.070007],
               [819.929993, 824.400024, 1438100, 818.97998, 824.159973],
               [816, 820.958984, 1008100, 815.48999, 819.23999],
               [819.359985, 823, 1188100, 818.469971, 818.97998],
               [819, 823, 1198100, 816, 820.450012],
               [811.700012, 815.25, 1098100, 809.780029, 813.669983],
               [809.51001, 816.659973, 1398100, 804.539978, 809.559998]])
            #  |         여기까지 x_data에 해당한다.           |  y_data
x_data = xy[:, 0:-1] # 전체 data행렬을 열에 따라 분리한다.
y_data = xy[:, [-1]]

# placeholders for a tensor that will be always fed.
X = tf.placeholder(tf.float32, shape=[None, 4])
Y = tf.placeholder(tf.float32, shape=[None, 1])

W = tf.Variable(tf.random_normal([4, 1]), name='weight')
b = tf.Variable(tf.random_normal([1]), name='bias')

# Hypothesis
hypothesis = tf.matmul(X, W) + b

# Simplified cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))

# Minimize
optimizer = tf.train.GradientDescentOptimizer(learning_rate=1e-5)
train = optimizer.minimize(cost)

# Launch the graph in a session.
sess = tf.Session()
# Initializes global variables in the graph.
sess.run(tf.global_variables_initializer())

for step in range(101):
    cost_val, hy_val, _ = sess.run(
        [cost, hypothesis, train], feed_dict={X: x_data, Y: y_data})
    print(step, "Cost: ", cost_val, "\nPrediction:\n", hy_val)

분명히 소스코드만을 살펴 보면 우리가 배운 바와 동일한, 아무런 문제가 없고,심플한 모델이다. 그러나 실행을 시켜보면 학습 과정에서 아래와 같은 해괴망측한 결과를 얻게 된다.

'''
0 Cost:  2.45533e+12
Prediction:
 [[-1104436.375]
 [-2224342.75 ]
 [-1749606.75 ]
 [-1226179.375]
 [-1445287.125]
 [-1457459.5  ]
 [-1335740.5  ]
 [-1700924.625]]
1 Cost:  2.69762e+27
Prediction:
 [[  3.66371490e+13]
 [  7.37543360e+13]
 [  5.80198785e+13]
 [  4.06716290e+13]
 [  4.79336847e+13]
 [  4.83371348e+13]
 [  4.43026590e+13]
 [  5.64060907e+13]]

 ...중략

 5 Cost:  inf
Prediction:
 [[ inf]
 [ inf]
 [ inf]
 [ inf]
 [ inf]
 [ inf]
 [ inf]
 [ inf]]
6 Cost:  nan
Prediction:
 [[ nan]
 [ nan]
 [ nan]
 [ nan]
 [ nan]
 [ nan]
 [ nan]
 [ nan]]
'''

이러한 결과가 도출되는 이유는, input data가 Normalize되어 있지 않기 때문이다. 우리가 이론 시간에 배운 것처럼 직접 Normalize한다거나, 최근에 많이 쓰이는 방법인

xy = MinMaxScaler(xy)
print(xy)

와 같은 방법을 사용하면 간단하게 data를 normalize시킬 수 있고, 결과는 아래와 같이 min을 0, max를 1로 하여 가중치가 매겨진 데이터들로 고르게 정리된 것을 볼 수 있다.

'''
[[0.99999999 0.99999999 0.         1.         1.        ]
 [0.70548491 0.70439552 1.         0.71881782 0.83755791]
 [0.54412549 0.50274824 0.57608696 0.606468   0.6606331 ]
 [0.33890353 0.31368023 0.10869565 0.45989134 0.43800918]
 [0.51436    0.42582389 0.30434783 0.58504805 0.42624401]
 [0.49556179 0.42582389 0.31521739 0.48131134 0.49276137]
 [0.11436064 0.         0.20652174 0.22007776 0.18597238]
 [0.         0.07747099 0.5326087  0.         0.        ]]
'''

이렇게 데이터를 잘 정규화시키게 되면 앞서 본 것처럼 얇고 넓게 한 방향으로 치우친 그래프가 아닌 아래와 같이 고르게 분포된 cost function의 그래프를 확인할 수 있다. 때문에 cost를 minimize하는 과정에서 어느 방향으로 가더라도 한 번만에 밖으로 튕겨나가지 않고 웬만하면 수렴하게 될 것이다.

기존과 동일한 소스코드에서 주어진 data에 MinMaxScaler 함수만을 적용하여 얻어낸 결과를 살펴보면 아래와 같이 초반부터 안정적인 cost 값을 갖고 진행하므로 정상적으로 학습이 이루어질 것을 예상해볼 수 있다.

이처럼 데이터가 너무 크거나 또는 데이터의 형태가 들쭉날쭉할 때에는 반드시 Normalize 과정을 거치는 것이 좋은 선택이 될 것이다.

'''
0 Cost: 0.15230925
Prediction:
 [[ 1.6346191 ]
 [ 0.06613699]
 [ 0.3500818 ]
 [ 0.6707252 ]
 [ 0.61130744]
 [ 0.61464405]
 [ 0.23171967]
 [-0.1372836 ]]
1 Cost: 0.15230872
Prediction:
 [[ 1.634618  ]
 [ 0.06613836]
 [ 0.35008252]
 [ 0.670725  ]
 [ 0.6113076 ]
 [ 0.6146443 ]
 [ 0.23172   ]
 [-0.13728246]]
 '''

Practice 2

이번 실습에서는 실전 데이터를 이용하여 직접 학습모델을 만들어 볼 것이다. 실습에 활용할 데이터는 MNIST라는 이름의 데이터로, 미 우체국에서 우편번호 처리를(?) 컴퓨터를 통해 자동화하고자 손 글씨로 쓰여진 숫자 이미지를 컴퓨터에서 쓰이는 숫자로서 식별하도록 하기 위한 데이터라고 한다. 데이터는 이 링크에서 다운받을 수 있다.

위 이미지는 우리가 분류하고자 하는 숫자 이미지의 모습이다. 28 x 28 픽셀로 이루어져 있으며 각 픽셀은 흑과 백, 그리고 그 채도에 따라서 다른 값을 갖고 가로 세로 28개씩, 총 784개의 픽셀로 구성되어 있으며 이 픽셀 하나 하나가 모두 우리가 사용할 x_data에 해당한다. 지금까지는 3개 내지 5개의 x feature들을 가지고 실습에 활용하였으나 이 데이터는 무려 x feature가 784개에 달하는 것이다.

MNIST classification의 전체 소스코드는 아래와 같다. 자세한 설명은 각 코드 사이에 주석으로서 덧붙이도록 하겠다.

# Lab 7 Learning rate and Evaluation
import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

from tensorflow.examples.tutorials.mnist import input_data
# 이러한 내용을 직접적으로 구현하기에는 복잡하므로 TensorFlow 내에 포함된 이를 간단하게
# 구현할 수 있도록 도와주는 라이브러리를 사용해 실습하도록 한다.

# Check out https://www.tensorflow.org/get_started/mnist/beginners for
# more information about the mnist dataset
mnist = input_data.read_data_sets("MNIST_data/", one_hot=True)
# 데이터 파일을 읽어오기 위해 디렉토리를 지정해준다.
# 처음 데이터를 가져오기 위해 조금 느릴 수 있지만, 이후에는 보다 빠르게 실행된다.
# one_hot=True로 전달하게 되면 y 값을 우리가 원하는 one_hot으로 불러오기 때문에
# 따로 one_hot format으로 만들어줄 필요가 없고 읽어옴과 동시에 처리된다.

nb_classes = 10 # 숫자가 0부터 9까지 10개 종류를 예측해야 하고
# 보통 이러한 경우에 Softmax Classification에서 처럼 One-Hot encoding을 사용한다.

# MNIST data image of shape 28 * 28 = 784
X = tf.placeholder(tf.float32, [None, 784])
# 0 - 9 digits recognition = 10 classes
Y = tf.placeholder(tf.float32, [None, nb_classes])

W = tf.Variable(tf.random_normal([784, nb_classes])) # 입력이 784개, 출력이 10개
b = tf.Variable(tf.random_normal([nb_classes])) # bias도 마찬가지로 10개의 출력

# Hypothesis (using softmax)
hypothesis = tf.nn.softmax(tf.matmul(X, W) + b)
# 배운 것과 동일하게 X,W의 행렬곱과 bias를 더한 값을 softmax 함수를 활용하여 가설 정의

cost = tf.reduce_mean(-tf.reduce_sum(Y * tf.log(hypothesis), axis=1))
train = tf.train.GradientDescentOptimizer(learning_rate=0.1).minimize(cost)
# cost function은 softmax에 알맞게 cross-entropy 수식의 형태에 따라 정의한다.
# optimizer는 역시 동일하게 경사 하강법을 이용한다.

# Test model
is_correct = tf.equal(tf.argmax(hypothesis, 1), tf.argmax(Y, 1)) # True/ False
# Calculate accuracy
accuracy = tf.reduce_mean(tf.cast(is_correct, tf.float32))

# parameters
num_epochs = 15
batch_size = 100
num_iterations = int(mnist.train.num_examples / batch_size)
# 전체 데이터를 한 번 학습시키는 것을 1 epoch이라고 한다.
# 학습을 시키기 위한 전체 데이터가 굉장히 커서 다 읽어서 학습시킬수 없기 때문에
# 한 배치에 100개씩 잘라서 학습시키게 된다.
# 예를 들어 전체 데이터가 1000개이고 batch size가 500이라고 한다면
# 2회 반복을 통해 1 epoch을 완료할 수 있다고 한다는 것이다.

with tf.Session() as sess:  # 굉장히 일반적인 학습 방법
    # Initialize TensorFlow variables
    sess.run(tf.global_variables_initializer())
    # Training cycle
    for epoch in range(num_epochs): # epoch = 15
        avg_cost = 0

        for i in range(num_iterations): # 1 epoch 달성을 위한 total batch size
            batch_xs, batch_ys = mnist.train.next_batch(batch_size)
            # 모든 데이터를 한 번에 메모리에 올릴 필요가 없으므로 100개씩 불러오게 되고
            # 다음 반복에서는 새로운 그 다음 100개의 데이터를 불러오게 된다.
            _, cost_val = sess.run([train, cost], feed_dict={X: batch_xs, Y: batch_ys})
            avg_cost += cost_val / num_iterations

        print("Epoch: {:04d}, Cost: {:.9f}".format(epoch + 1, avg_cost))

    print("Learning finished")

    # Test the model using test sets
    print(
        "Accuracy: ",
        accuracy.eval( # 특정 tensor에 직접적으로 eval()이라는 함수를 호출함으로써 하나만 실행시킬때는 간단하게 사용하기도 한다.
            session=sess, feed_dict={X: mnist.test.images, Y: mnist.test.labels}
        ), # 학습에 한 번도 사용되지 않은 test dataset을 통해 학습한 모델을 평가하게 된다.
    )

이러한 소스코드를 실행하게 되면 아래와 같은 출력을 얻을 수 있다. 출력은 전체 데이터를 한 번 학습하는 단위인 epoch의 반복으로 나타나는데, 이 epoch을 거듭할수록 cost 값은 점점 작은 값으로 수렴하게 되며, 가장 아래에 test dataset을 통해 평가했을 때에 예측에 대한 정확도 값이 출력된다. 위에서 살펴본 바와 같이 상당히 간단한 모델임에도 불구하고 89.5%의 정확도를 보여주는 결과를 확인할 수 있다.

'''
Epoch: 0001, Cost: 2.826302672
Epoch: 0002, Cost: 1.061668952
Epoch: 0003, Cost: 0.838061315
Epoch: 0004, Cost: 0.733232745
Epoch: 0005, Cost: 0.669279885
Epoch: 0006, Cost: 0.624611836
Epoch: 0007, Cost: 0.591160344
Epoch: 0008, Cost: 0.563868987
Epoch: 0009, Cost: 0.541745171
Epoch: 0010, Cost: 0.522673578
Epoch: 0011, Cost: 0.506782325
Epoch: 0012, Cost: 0.492447643
Epoch: 0013, Cost: 0.479955837
Epoch: 0014, Cost: 0.468893674
Epoch: 0015, Cost: 0.458703488
Learning finished
Accuracy:  0.8951
'''

더 나아가 실제로 모델이 예측한 숫자가 어떠한 모습으로 보이는지 알고 싶다면 위 코드에 이를 시각화시켜주는 라이브러리를 활용하여 예측 이미지를 확인해볼 수 있다.

import matplotlib.pyplot as plt
import random

# Get one and predict
r = random.randint(0, mnist.test.num_examples - 1) # 0~9 중 랜덤한 정수 1개 선택
print("Label: ", sess.run(tf.argmax(mnist.test.labels[r : r + 1], 1))) # 해당 정수에 해당하는 test label 선택
print(
    "Prediction: ",
    # 이 label에 해당하는 image의 x_data 값을 입력하여 argmax가 one-hot의 어떠한 값을 예측하는지 실행
    sess.run(tf.argmax(hypothesis, 1), feed_dict={X: mnist.test.images[r : r + 1]}),
)

plt.imshow( # imshow라는 함수를 통해 해당 image의 x_data값을 format에 맞춰 reshape하여 전달
    mnist.test.images[r : r + 1].reshape(28, 28),
    cmap="Greys",
    interpolation="nearest",
)
plt.show()

코드의 주석으로 간략한 설명을 포함하였고, 위의 코드를 추가하여 도출되는 결과는 랜덤 값이므로 하나의 예를 들면 아래와 같다.

이렇게 모두를 위한 딥러닝 7섹션 강좌에 대한 내용 정리를 마치도록 하겠다.

[course] 모두를 위한 딥러닝 강좌 06

Tue, 28 Jan 2020 21:02:25 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

Lecture 6. Softmax Classification

여러 개의 클래스가 있을 때, 그 것을 예측하는 방법을 Multinomial Classification
이라고 하며, 그 중에 가장 많이 사용되는 Softmax Classification에 대하여 배워보도록 한다.

본격적으로 Softmax Classification에 대해 이야기를 시작하기 전에 지난 시간까지의 이론적인 내용들을 짚고 넘어가도록 하자.

기본적으로 출발은 H(X) = WX라는 Linear한 Hypothesis와 함께하였다. 이러한 WX와 같은 형태의 단점은 리턴하는 값이 어떠한 실수의 값 (100, -10 … 등) 이 되기 때문에 둘 중 하나를 선택하는 Binary Classification을 수행하려 할 때 적합하지 않았다. 그래서 이를 해결하기 위한 방안으로 z = H(X)라고 하고, 어떠한 g(z)라는 함수를 통해 앞서 언급한 큰 실수 값들을 압축하여 0 또는 1 혹은 그 사이의 값으로 표현할 수 있도록 하는 것이었다. 이를 적합하게 표현한 g(z)를 sigmoid function 혹은 logistic function 이라고 부른다고 하였다.

이를 우측 하단에 보이는 그림과 함께 다시 정리하여 설명하면, X라는 입력이 있고 연산 유닛에서 W를 가지고 Linear한 계산 과정을 거친 뒤에 나오는 값이 z이며, sigmoid라는 함수에 입력하게 된다. 이를 통과하고 난 뒤에는 어떠한 값이 나오게 되는데, 이는 0과 1 사이에 해당하는 값이고 이를 통상적으로 Y hat이라고 부른다. 흔히 Y는 실제 데이터에 해당하고 예측(predict)값에 해당하는 것을 구분하여 부르기 위해 Y hat이라고 한다.

Logistic classification이 하는 일을 직관적으로 살펴보기 위해 예를 들면 x1, x2라는 값을 가지고 있고, 우리가 분류해야 할 네모와 X 모양의 두 데이터가 있다고 할 때, Logistic classification을 한다 혹은 W를 학습시킨다 는 말은 이 두 모양의 데이터를 구분하는 어떠한 선을 찾아낸다는 이야기이다.

Multinomial classification

자, 그러면 이 아이디어를 그대로 multinomial classification에 적용할 수 있다. multinomial이라는 것은 여러 개의 클래스가 있다는 것이다. 지금까지 자주 언급되고 사용되던 예제의 맥락을 그대로 확장하여 살펴보도록 하자.

x1(hours)	x2(attendance)	y(grade)
10	5	A
9	5	A
3	2	B
2	4	B
11	1	C

Multinomial 이라는 것은 여러 개의 클래스가 있다는 의미이다. 데이터가 위의 표와 같은 형태로 주어졌을 때 그래프에 나타내면 대략 아래와 같다.

이처럼 A,B,C 세 개로 구분되는 Multinomial 형태를 갖더라도 이전까지 우리가 알고 있던 Binary Classification만으로도 구현이 가능하다.

Hypothesis

위의 그림에서와 같이 A인지 아닌지, B인지 아닌지, C인지 아닌지의 3개의 경우로 나누어 구분할 수 있고, 앞서 본 도식을 각각 적용하여 3개의 독립된 Classifier들을 가지고 구현이 가능하다고 할 수 있는 것이다.

이 3개의 Classifier들을 실제로 구현할 때에는 그림에서와 같은 수식을 사용하게 되는데 이는 우리가 알고 있던 W * X = H(X)와 같은 형태를 갖는 행렬 곱의 수식이다. 우리는 3개의 Classifier들을 구하려고 하기 때문에 각각 독립된 벡터를 가지고 3번의 계산을 수행해내야 한다. 그런데 이렇게 독립적으로 계산하면 계산하는 데에도, 구현하는 데에도 복잡하게 느껴지는데, 우리는 행렬 곱셈을 알고 있기 때문에 하나로 표현할 수가 있다.

W에 해당하는 벡터들을 나란히 하나로 묶어 위와 같이 각 첨자를 A,B,C에 해당하게 바꾸어주고 9 * 9 행렬로 표현한 뒤, 동일한 곱셈 연산을 수행하게 되어 얻게 되는 결과가 바로 우리가 원했던 Ha(X), Hb(X), Hc(X)에 해당하는 가설에 해당하게 된다. 이렇게 3개의 독립된 Classifier를 각각 구현해야 하지만 하나의 벡터로 한 번에 처리가 가능하고 이 것은 세 개의 독립된 Classification처럼 동작하게 된다.

다시 말해서, 사진의 오른쪽 도식과 같이 세 개의 Classifier들을 따로따로 나누어 표현하고 연산하는 것은 불필요하고 복잡하므로 행렬 연산을 단일화하여 간단히 나타내고 계산을 쉽게 할 수 있다는 것이다.

그런데 위처럼 가설 함수를 하나의 벡터로 한 데 묶어 구했다고 하더라도, 이 값들은 결국 이전에 언급한 것처럼 실수 값에 해당한다. 그 값의 크기 따라 정답을 도출해낼 수는 있겠지만, 이는 우리가 알던 Logistic의 방식이 아니기 때문에 Sigmoid function을 적용하여 0에서 1사이의 값이 나오도록 해야 한다.

위 사진에서 A,B,C 각각에 해당하는 Classifier들은 어떠한 과정을 거쳐서 0과 1사이의 값을 도출하게 되고, 결론적으로 한 벡터 안의 이 모든 클래스들의 결과 값의 합이 1이 되게 하는 이 방식이 Softmax classification이다.

위 그림이 바로 Softmax function이다. 가설 함수 결과값의 행렬 벡터를 (예시에서는 3개이지만 이 행렬의 행의 개수는 n개일 것이다.) 이 함수에 입력하면, 앞서 말한 것과 같은 0과 1사이의 값이고 모든 값의 합이 1이 되는 확률 값이 될 것이다.

이렇게 Softmax function을 거쳐 변환된 확률 값들을 바탕으로 One-Hot Encoding이라는 절차를 거쳐서 (실습 시간에 다룰 것이다.) 가장 큰 값만 1로 바꾸고 나머지를 0으로 변경하여 하나의 클래스를 채택하는 결과를 얻게 된다.

Cost function

지금까지의 과정을 통해 예측하는 모델 (Hypothesis)를 구해보았고 이제 예측 값이 실제의 값과 얼마나 차이를 나타내는가에 대한 Cost function 을 설계하는 방법에 대해 알아보도록 하겠다.

Softmax Classification 을 수행하는 과정에서 Cost function을 구할 때, Cross-Entropy라는 함수를 사용하여 도출하게 된다. 위 그림에서의 S는 Softmax function을 거쳐 도출된 확률 값이자, 달리 말하면 가설 함수의 결과값에 해당하므로 예측 값에 해당하며 도입부에 언급된 Y hat이라 할 수 있다. L은 Label 값이라는 의미이며, 바로 이전 사진에서 본 것처럼 One-hot Encoding 과정을 거쳐 변환된 실제 값, 즉 Y 값에 해당한다.

이제 이 수식이 어떻게 정상적으로 동작하고 적용이 가능한지에 대해서 알아보자.

- 기호의 위치를 바꾸어 곱셈 기호를 명시적으로 표현하면 사진에서 제목 아래에 보이는 공식처럼 표현할 수 있다. 이 곱셈 기호는 (필자도 이 강의를 들으며 처음 알게 되었는데) 요소별 곱셈(element-wise multiplication) 이라고 불리는 곱셈 방식인데, 피연산자인 행렬에서 각 요소별로 연산을 수행하는 방식이다. 사진에서 원 안에 점을 찍어 표현한 기호가 바로 그 곱셈 기호이다. 아다마르 곱 (Hadamard product)이라고도 불린다고 한다.

여기서 -log() 형태의 표현은 Logistic Classification 에서 도입한 것처럼 우측의 그래프로 나타낼 수 있음을 알 수 있다. 간단한 예를 통해서 이 공식을 증명해보면 사진의 하단부에 보이는 것과 같다. A, B 두 클래스를 갖는다고 가정하면L은 실제 값 벡터에 해당하며 B를 채택한다는 것을 알 수 있다.

초록색 글씨로 표현된 예측 벡터는 B를 예측하고 있으며 공식에 대입하게 되면 L에 해당하는 [0, 1]벡터와 Y hat에 해당하는 예측 벡터에 -log를 취한 것에 곱을 수행하는 구조가 되는 것을 확인할 수 있는데, 이 때 -log를 취하게 되면 우측 그래프를 통해 알 수 있듯이 0에 해당하는 값은 무한대가 되고, 1에 해당하는 값은 0을 갖게 된다. 따라서 결과는 [inf, 0]이 되며, 이들을 element-wise 곱셈을 수행하게 되면 [0, 0]이 되고, 공식의 가장 왼 쪽에 있는 sigma, 즉 각 요소를 모두 합해주게 되면 0이라는 결과를 얻게 된다. 이 값이 구하려는 Cost가 된다.

보라색 글씨로 표현된 예측 벡터는 A를 예측하고 있으며 잘못된 예측을 하고 있다. 이를 공식에 대입하게 되면 L에 해당하는 벡터와 Y hat에 해당하는 예측 벡터에 -log를 취한 것을 마찬가지로 element-wise 곱셈을 수행한다. 마찬가지로 그래프를 통해 알 수 있듯, (간단한 예이므로 직관적으로 반대라고 생각하면 되겠다.) 1에 해당하는 값은 0을 갖게 되고, 0에 해당하는 값은 무한대를 갖게 되어 [0, inf]라는 결과를 얻게 됨을 알 수 있다. 이를 L = [0, 1]과 각 요소를 곱셈의 결과는 [0, inf]가 되고, 최종 결과는 무한대가 됨을 알 수 있다. 따라서 잘못된 예측을 하는 가설은 무한대가 된다는 것이다.

반대의 경우도 마찬가지이다.

위의 예를 이어서 실제 Label L이 A를 채택하는 결과 [1, 0]를 가지고 있고 예측 벡터는 동일하다고 할 때, 이제는 초록색이 잘못된 예측을 하고 있으므로 무한대의 값을 갖고, 보라색이 올바른 예측을 하고 있으므로 0의 cost 값을 갖게 되는 것을 알 수 있다.

지금까지 우리가 살펴본 Cross Entropy cost function은 지난 강의에서 우리가 배웠던 Logistic Classification의 Cost function과 완전히 동일하다. Logistic cost에서의 C는 Cost를 의미하고, Cross entropy의 D는 Distance를 의미한다. 또한 Logistic cost의 H(x)와 y 값은 예측값(가설)과 실제 값을 의미하므로 Cross entropy의 Softmax 값과 Label 값과 일맥상통한다.

교수님께서 우측에 나타나는 공식 또한 동일한 논리를 가지고 있다고 설명하시면서 그 이유는 숙제로 남겨두겠다며 생각해보라고 말씀하셨는데, 지금까지 배운 것을 토대로 생각해봤을 때, 사실상 Cross entropy의 공식은 Logistic cost 공식이 압축되어 있다고 생각할 수 있으며 (H(x) = S, y = L이라고 했으므로) 단지 차이점이라고 하자면 Cross entropy에서는 각 클래스들에 해당하는 값이 한 벡터에 묶여있기 때문에 cost 값을 sum해주는 과정이 포함되는 것 뿐이라고 생각된다.

지금까지는 하나의 Training set에 대한 cost function을 설명한 내용이었고, 여러 개의 Training Data Set이 있다면 각 Set의 Cost를 모두 더하여 평균을 내주면 전체에 대한 Cost/Loss function을 정의할 수 있게 된다.

Gradient Descent

항상 그랬듯이 마지막 단계로 직전까지 논했던 Cost를 최소화 시키는 값, (여기에서는 W에 해당하는 벡터)를 찾아내는 알고리즘을 적용해야 하는데 항상 등장하던 Gradient Descent를 마찬가지로 적용하게 될 것이다.

어떤 점에서 시작하더라도 경사면을 따라 내려가서 반드시 최소값을 찾을 수 있음을 보장하는 것이 이 알고리즘이며 경사면을 뜻하는 것이 그래프에서의 기울기이다. 기울기를 구하기 위해서는 수식을 미분해야 하는데, 진도를 거듭하면서 수식이 복잡해졌기 때문에 미분 과정은 다루지 않는다. 다만 기억해야 할 것은 사진에서 보이는 것처럼 learning rate 값인 alpha 만큼씩 내려가면서 위치를 업데이트 시켜 기울기를 구하며 최소값을 찾아가는 과정이라는 것이다.

TensorFlow Practice

실습 강좌에서는 Softmax Classifier를 TensorFlow를 이용하여 직접 구현해본다. 그 전에, 이론 시간에 학습했던 내용을 한번 더 요약하여 짚고 넘어간다.

Softmax function이라는 것은 여러개의 클래스를 예측할 때 매우 유용하다. 이 것을 다루기 이전까지의 Binary Classification은 0이냐 1이냐와 같은 예측만이 가능했는데, 사실 실생활에서는 두 개보다는 여러개를 예측하는 경우가 더 많을 것이다. 따라서 N개의 예측할 거리가 있을 때, 이 Softmadx Classification을 사용하는 것이 좋다.

시작은 항상 동일하게 주어진 X 값에, 학습시킬 W를 곱해서 값을 만들어낸다. 그런데 이렇게 만들어진 값은 Score에 해당하는 실수 값에 불과하므로 우리는 이것을 Softmax라고 불리는 함수를 통과시키면 확률 값이 결과로 나오게 된다. 만약 각 Label을 A, B, C라고 한다면 A가 0.7, B가 0.2, C가 0.1 과 같이 확률로 표현할 수 있게 된다. 그리고 또 하나의 특징은 여기서 모든 클래스의 확률을 합치면 이 값은 반드시 1이 될 것이다.

그러면 이것을 TensorFlow로 어떻게 구현할 것인가?

TensorFlow를 이용하여 Softmax Classification을 구현하는 것은 어렵지 않다. 그림에 나와 있는 것처럼 실수 예측 값 수식을 그대로 옮겨 작성해주면 되는데, (이 Scores에 해당하는 값들을 다른 말로 Logit이라고 부르기도 한다.) 주어진 X-data와 W 행렬을 TensorFlow의 Matrix Multiplication 내장 함수인 tf.matmul을 이용하여 곱셈을 수행한 뒤 b(bias) 값을 더해주면 된다. 그리고 이 가설을 통해 보기에 매우 복잡한 Softmax function을 통과시키는 방법은 마찬가지로 TensorFlow의 내장 함수인 tf.nn.softmax 함수를 이용하여 Logit값을 전달해주면 우리가 원하는 확률 값으로 구성된 벡터를 얻을 수 있고, 이 것이 우리의 Hypothesis이다.

다음으로는 Cost(loss) function이다. Loss function은 수업 시간에 이야기 한 것처럼 기본적으로 Y 와 Y hat(hypothesis)에 log를 취한 형태를 띠고 이를 Cross entropy 라고 설명했었다. 그림에서 보이는 L이 Y에 해당하고, S(softmax function)이 Y hat에 해당한다. 이를 D(distance, 즉 앞서 언급한 Cross entropy function을 거친 결과) 라고 하고, 그 D의 결과들을 모두 더해 평균을 낸 것이 우리가 원하는 최종적인 Cost function인 것이다. 그리고 어김없이 이 Cost를 minimize하기 위해 경사면 내려가기 (Gradient Descent) 함수가 등장하는데, 여기서도 마찬가지로 Cost 함수를 미분한 기울기를 alpha(learning rate)값을 곱하여 weight 값에서 빼주면서 최소 cost를 찾아가는 방식이다. 따라서 결론적으로 optimizer의 선언은 지금까지와 항상 똑같은 한 문장으로 정의할 수 있다.

그럼 전체 코드를 한 번 살펴보도록 하자.

Practice 1 - Softmax Classifier

# Lab 6 Softmax Classifier
import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

#x1, x2, x3, x4
x_data = [[1, 2, 1, 1],
          [2, 1, 3, 2],
          [3, 1, 3, 4],
          [4, 1, 5, 5],
          [1, 7, 5, 5],
          [1, 2, 5, 6],
          [1, 6, 6, 6],
          [1, 7, 7, 7]]

#One-Hot Encoding
y_data = [[0, 0, 1],
          [0, 0, 1],
          [0, 0, 1],
          [0, 1, 0],
          [0, 1, 0],
          [0, 1, 0],
          [1, 0, 0],
          [1, 0, 0]]
#의미에 따라 표현하자면 y_data는 [2, 2, 2, 1, 1, 1, 0, 0]이 될 것이다.

X = tf.placeholder("float", [None, 4])
Y = tf.placeholder("float", [None, 3])
nb_classes = 3 #number of class

W = tf.Variable(tf.random_normal([4, nb_classes]), name='weight')
b = tf.Variable(tf.random_normal([nb_classes]), name='bias')

# tf.nn.softmax computes softmax activations
# softmax = exp(logits) / reduce_sum(exp(logits), dim)
hypothesis = tf.nn.softmax(tf.matmul(X, W) + b)

# Cross entropy cost/loss
cost = tf.reduce_mean(-tf.reduce_sum(Y * tf.log(hypothesis), axis=1))

optimizer = tf.train.GradientDescentOptimizer(learning_rate=0.1).minimize(cost)

# Launch graph
with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())

    for step in range(2001):
            _, cost_val = sess.run([optimizer, cost], feed_dict={X: x_data, Y: y_data})

            if step % 200 == 0:
                print(step, cost_val)

x_data를 먼저 살펴보면, x1 ~ x4에 해당하는 4개의 element로 구성된 데이터임을 알 수 있고, y_data는 One-Hot Encoding 방식을 통해 표현되어 있는 것을 확인할 수 있다. 여기서 One-Hot encoding이란, 이론 수업에서도 언급했지만 이름대로 하나만 뜨겁게 한다 라는 의미로 받아들이면 이해가 쉽다. 다시 말해서 우리는 여기서 세 개의 클래스의 구분을 표현하고 싶은데, 첫 번째 클래스를 의미하도록 하기 위해서는 [1, 0, 0] 두 번째 클래스를 의미하려면 [0, 1, 0]과 같은 방식으로 작성하면 된다는 것이다.

따라서 placeholder를 정의할 때에도 shape을 작성하는 데 있어서 x_data는 직관적으로 None(instance의 개수 제한 없음)과 4(element의 개수)를 부여하면 되고 y_data는 One-Hot-Encoding 방식으로 작성했기 때문에 element의 개수는 3으로 전달해줘야 한다. 반대로 말해서, One-Hot으로 표현할 때y_data의 shape은 Label의 개수(우리가 구하려는 class의 종류의 수 nb_classes = 3)가 되는 것을 알 수 있다.

W와 b를 TensorFlow Variable로 정의할 때에도 shape을 주의해야 하는데 weight에서는 입력되는 x_data의 element 수가 4개이므로 4를 주고 bias에는 출력되는 Y의 클래스 수와 같은 종류 만큼 출력되어야 하므로 nb_classes 값이 된다.

이후에 그래프를 명세하는 과정은 앞서 언급한 것처럼 변경된 수식에 대한 내용만 수정하면 나머지 절차는 이전부터 행하던 방식과 동일하다. Hypothesis는 X와 W의 행렬 곱셈 결과에 b값을 더해주고 softmax 함수를 통과시킨 것으로 정의할 수 있을 것이고, cost 또한 Cross entropy 함수의 수식대로 작성한 뒤 모두 더해서 평균을 구하는 함수로 정의하고 나서 경사 하강법으로 optimizer를 선언해주면 되는 것이다.

학습이 이루어지는 과정 또한 마찬가지이다. 세션을 열고, 초기화를 시켜준 뒤에 Loop을 돌면서 optimizer를 세션에서 실행시키면서 feed_dict를 통해 x_data,y_data를 입력으로 던져주게 된다.

위 코드의 결과는 다음과 같이 출력된다. 각 200회 마다 step의 값과 해당 시점의 cost값이 출력되며 그 cost값이 처음에 무작위한 값으로 시작하여 학습 회수를 거듭하면서 값이 점차 매우 작은 값으로 수렴하는 것을 확인 할 수 있다.

0 6.926112
200 0.6005015
400 0.47295815
600 0.37342924
800 0.28018373
1000 0.23280522
1200 0.21065344
1400 0.19229904
1600 0.17682323
1800 0.16359556
2000 0.15216158

다음은 우리가 작성한 모델이 학습한 결과가 올바른지에 대해 테스트하는 내용이다.

    print('--------------')
    # Testing & One-hot encoding
    a = sess.run(hypothesis, feed_dict={X: [[1, 11, 7, 9]]})
    print(a, sess.run(tf.argmax(a, 1)))

    print('--------------')
    b = sess.run(hypothesis, feed_dict={X: [[1, 3, 4, 3]]})
    print(b, sess.run(tf.argmax(b, 1)))

    print('--------------')
    c = sess.run(hypothesis, feed_dict={X: [[1, 1, 0, 1]]})
    print(c, sess.run(tf.argmax(c, 1)))

    print('--------------')
    all = sess.run(hypothesis, feed_dict={X: [[1, 11, 7, 9], [1, 3, 4, 3], [1, 1, 0, 1]]})
    print(all, sess.run(tf.argmax(all, 1)))

tf.argmax

위 코드에서, 교수님께서 tf.argmax에 대해서 설명해주셨는데, 두 번째 인자로 전달되는 axis에 대한 내용이 이해가 되지 않아서 구글에 검색을 통해 찾아보았다.

이 axis, 다시 말해 축에 대한 개념은 우리가 이 강의의 초반부에서 공부했던 기본적인 내용 중의 하나인 Rank라는 개념과 동일하다. Rank란 달리 말해 배열의 차원 수를 뜻하는데, 1차원 배열의 Rank는 1, 2차원 배열의 Rank는 2 와 같은 느낌인 것이다.

첫 번째 인자로 전달된 배열이 일차원 배열일 경우에는 axis값으로 0만을 사용할 수 있으며 이는 배열의 열(세로축)만을 기준으로 최대값을 찾아내 반환한다. 2차원 배열, 즉 Rank가 2인 행렬일 경우에는 axis값으로 0과 1을 사용할 수 있으며 0일 경우 앞에서의 설명과 마찬가지, 1일 경우에는 각 행에 대하여 최대값이 위치한 인덱스를 묶어 하나의 배열로 반환하게 된다.

이를 일반화시키면, axis의 값으로는 첫 번째 인자에 해당하는 배열의 Rank 값 - 1 부터 0까지에 해당하는 값이 전달 가능한 경우의 수가 될 것이다.

덧붙여 이 argmax함수를 사용하는 이유는 우리가 위에서 y_data를 정의할 때 One-Hot-Encoding 방식을 통해 표현하였기 때문에 이 Label이 의미하는 숫자를 찾기 위해서 사용된다고 한다.

따라서 간단한 예시를 들어 다음과 같은 a라는 Rank가 2인 행렬이 있다고 할 때

a = tf.constant([[3, 10, 1],
                 [4, 5, 6],
                 [0, 8, 7]])
print(session.run(tf.argmax(a, 0))) #1
print(session.run(tf.argmax(a, 1))) #2

1번과 같은 경우에는 a행렬에서 세로 축만을 기준으로 최대값을 탐색하고, 2번과 같은 경우에는 a행렬에서 각 행에 대한 최대값을 탐색하므로

[1, 0, 2]
[1, 2, 1]

와 같은 1차원 배열을 반환하게 될 것이다. 위 내용의 출처

따라서 위 학습 결과 테스트에 대한 결과는 아래와 같다. 우리는 데이터와 모델을 명세할 때 y_data를 One-Hot-Encoding 방식을 사용하여 Rank가 2인 행렬로 작성하였으며 각 Label이 의미를 갖는 단위가 각 행에 해당하므로 axis = 1을 전달해 아래와 같은 일차원 배열로 반횐되는 결과를 얻을 수 있다.

[[1.3890490e-03 9.9860185e-01 9.0613084e-06]] [1]
-------------
[[0.9311919  0.06290216 0.00590591]] [0]
-------------
[[1.2732815e-08 3.3411323e-04 9.9966586e-01]] [2]
-------------
[[1.3890490e-03 9.9860185e-01 9.0613084e-06]
 [9.3119192e-01 6.2902197e-02 5.9059085e-03]
 [1.2732815e-08 3.3411323e-04 9.9966586e-01]] [1 0 2]

Practice 2 - Fancy Softmax Classifier

두 번째 실습에 들어가기 앞서, Softmax function의 Cost function을 정의하는 새로운 방식에 대해 도입해보도록 한다.

본 실습을 도입하면서 Logit이라는 개념에 대해서 도입했는데, 어떤 Label이 될지에 대한 확률값을 반환하는 Hypothesis를 정의할 때 Softmax 함수를 통과시키기 전의, 기본적인 형태의 값을 의미한다. (다른 말로 Scores, 즉 예측 값.)

이전 실습에서 우리가 작성했던 Cost function은 사진에서 1번에 해당하는, 수식을 그대로 풀어 옮긴 한 줄짜리 코드였지만, softmax_cross_entropy_with_logits라는 TensorFlow 함수를 이용하여 2번과 같이 간단히 요약해 작성할 수 있다. 여기서 cost_i는 -tf.reduce_sum ~에 해당하는 부분으로 대치됨을 알 수 있다.

이 과정을 통해 단순히 tf.nn.softmax함수를 통해 Hypothesis를 정의한 뒤 cost를 수식으로 작성하지 않고 tf.matmul(X, W) + b를 logits이라는 변수로 둔 뒤 동명의 Property로 전달해주면 된다. 여기서 labels로 전달되는 것은 우리가 1번 방식에서 전달한 Y 벡터가 One-Hot-Encoding 방식으로 전달되었기 때문에 이를 명시적으로 이름을 명시적으로 변경한 뒤에 전달해준 것이다.

따라서 결론적으로 이 두 방식 모두에 해당하는 cost 함수는 정확하게 일치한다.

이번 실습의 예제는 위와 같은 데이터를 갖는다. 동물들이 갖는 여러 특징들을 통해서 (다리가 몇개인지, 뿔이 달렸는지, 등등…) 어떤 동물인지를 예측하는 예제이다. 표를 살펴보았을 때, 0번 째부터 마지막 직전까지에 해당하는 열은 각 동물들의 특징에 대해, 즉 x1 ~ xn에 해당할 것이고 마지막 열은 분류된 결과, 즉 Label 값에 대응하는 Y값이 될 것이다. 또한 행은 instance의 수, 즉 주어진 동물의 수라고 생각하면 되겠다.

이 데이터에 대해서 조금 더 자세히 살펴보자.

tf.reshape

이 슬라이드에 대한 설명에서 조금은 복잡한 Reshape에 대한 개념이 등장한다. 우선 우리가 사용할 마지막 열에 해당하는 Y 행렬의 shape은 n개의 행에 1열을 갖는다. 나아가, 앞서 설명한 것처럼 우리가 사용할 Y 데이터는 결론적으로 One-Hot 방식으로 인코딩 되어야 하므로 tf.one_hot 함수를 이용하여 7종류의 클래스 수를 인자로 함께 전달해 구할 수 있다.

그러나 슬라이드의 하단에 적혀있는 것처럼, tf.one_hot 함수를 사용하게 되면 Y의 각 Label들이 인코딩되면서 Rank가 한 차원 늘어나게 된다. 무슨 말이냐 하면, 0은 [1, 0, 0, 0, 0, 0, 0]으로, 3은 [0, 0, 0, 1, 0, 0, 0]으로 차원 축이 하나 늘어나게 되면서 우리가 원하는 y_data의 shape을 잃게 된다.

따라서 이를 해결하기 위해 tf.reshape 함수를 사용하여 이 늘어난 한 차원을 줄이는 작업을 수행하도록 한다. (여기서 등장하는 -1에 대해서는 명확하게 이해하지는 못했지만 TensorFlow 공식 문서 를 참조한 결과 구조를 암시(infer)하기 위해 사용된다고 한다. shape을 적절히 조절하는 용도로 사용되는 것으로 추정.)

여기까지 이해했다면 실행하는 방법은 간단하며 그래프에 대한 코드는 다음과 같다.

# Lab 6 Softmax Classifier
import tensorflow as tf
import numpy as np
tf.set_random_seed(777)  # for reproducibility

# Predicting animal type based on various features
xy = np.loadtxt('data-04-zoo.csv', delimiter=',', dtype=np.float32)
x_data = xy[:, 0:-1]
y_data = xy[:, [-1]]

print(x_data.shape, y_data.shape)

'''
(101, 16) (101, 1)
'''

nb_classes = 7  # 0 ~ 6

X = tf.placeholder(tf.float32, [None, 16]) # x_data의 개수 16개.
Y = tf.placeholder(tf.int32, [None, 1])  # 0 ~ 6

Y_one_hot = tf.one_hot(Y, nb_classes)  # one hot
print("one_hot:", Y_one_hot)
Y_one_hot = tf.reshape(Y_one_hot, [-1, nb_classes])
print("reshape one_hot:", Y_one_hot)

'''
one_hot: Tensor("one_hot:0", shape=(?, 1, 7), dtype=float32)
reshape one_hot: Tensor("Reshape:0", shape=(?, 7), dtype=float32)
'''

W = tf.Variable(tf.random_normal([16, nb_classes]), name='weight')
b = tf.Variable(tf.random_normal([nb_classes]), name='bias')

# tf.nn.softmax computes softmax activations
# softmax = exp(logits) / reduce_sum(exp(logits), dim)
logits = tf.matmul(X, W) + b
hypothesis = tf.nn.softmax(logits)

# Cross entropy cost/loss
# softmax_cross_entropy_with_logits
cost = tf.reduce_mean(tf.nn.softmax_cross_entropy_with_logits_v2(logits=logits,
                                                                 labels=tf.stop_gradient([Y_one_hot])))
optimizer = tf.train.GradientDescentOptimizer(learning_rate=0.1).minimize(cost)

위 코드는 앞서 설명한 내용과 기존에 진행하던 실습 내용들과 상당 부분 중복되므로 자세한 설명은 생략하도록 하겠다.

조금 더 새로운 내용은 학습 과정 부분에서 등장한다.

prediction = tf.argmax(hypothesis, 1)
correct_prediction = tf.equal(prediction, tf.argmax(Y_one_hot, 1))
accuracy = tf.reduce_mean(tf.cast(correct_prediction, tf.float32))

# Launch graph
with tf.Session() as sess:
    sess.run(tf.global_variables_initializer())

    for step in range(2001): # Optimizer, cost와 accuracy를 학습시켜 100회에  한 번씩 출력한다.
        _, cost_val, acc_val = sess.run([optimizer, cost, accuracy], feed_dict={X: x_data, Y: y_data})

        if step % 100 == 0:
            print("Step: {:5}\tCost: {:.3f}\tAcc: {:.2%}".format(step, cost_val, acc_val))

    # 학습이 완료된 후 X 데이터만 던져주고 예측이 정확한지 확인하는 과정
    pred = sess.run(prediction, feed_dict={X: x_data})
    # y_data: (N,1) = flatten => (N, ) matches pred.shape
    for p, y in zip(pred, y_data.flatten()):
        print("[{}] Prediction: {} True Y: {}".format(p == int(y), p, int(y)))

''' 출력 결과
Step:     0 Loss: 5.106 Acc: 37.62%
Step:   100 Loss: 0.800 Acc: 79.21%
Step:   200 Loss: 0.486 Acc: 88.12%
...
Step:  1800	Loss: 0.060	Acc: 100.00%
Step:  1900	Loss: 0.057	Acc: 100.00%
Step:  2000	Loss: 0.054	Acc: 100.00%
[True] Prediction: 0 True Y: 0
[True] Prediction: 0 True Y: 0
[True] Prediction: 3 True Y: 3
...
[True] Prediction: 0 True Y: 0
[True] Prediction: 6 True Y: 6
[True] Prediction: 1 True Y: 1
'''

코드의 흐름에 따른 부연 설명은 주석으로 작성하였고 축약된 출력 결과는 코드 블럭의 하단부와 같다. 학습 과정과 확인 과정에서 볼 수 있듯이 예측 결과가 매우 정확한 것을 알 수 있다.

prediction은 가설 함수의 예측 값을 바탕으로 한 결과 Label에 해당한다. correct 값은 실제 결과 Label과 일치하는지에 대한 참, 거짓 결과를 뜻하며, accuracy는 위의 두 예측,실제 값의 일치 여부를 전체에 대해 평균을 매긴 정확도 값이다.

zip과 flatten은 파이썬 표준 라이브러리에 포함된 내장 함수로서 flatten은 다차원 배열을 일차원 배열로 이름 그대로 평평하게 펴주는 역할을 하고 zip 함수는 같은 개수로 이루어진 자료형을 하나로 묶어주는 역할을 한다고 한다.

여기까지 Softmax Classification에 대한 이론적인 내용을 공부하고 실습을 진행해 보았다.

[course] 모두를 위한 딥러닝 강좌 05

Mon, 20 Jan 2020 21:02:11 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

Lecture 5. Logistic Classification

Logistic classification은 classification algorithm들 중에서 정확도가 높은 것으로 알려져 있다.
때문에 실제 문제에도 바로 적용해볼 수 있고, Neural Network와 Deep learning을 이해하는 데 중요한 컴포넌트이다.

Logistic Classification에 대해 이야기를 도입하기 앞서, 지난 시간까지의 Linear Regression에 대한 정리를 하고 넘어가자.

우선 가장 먼저 가설을 세운다. 가설은 변수 x에 대하여 선형적이며 우리가 가진 데이터가 어떠한 방식으로 나타날지를 가정하는 일차 함수이다.
비용 함수를 정의한다. 비용 함수는 학습 목표인 W에 대한 함수이며 가정한 값과 참값 y값의 차의 제곱을 평균을 취한 것이다.
이 비용 함수는 그림으로 그려보면 밥그릇을 뒤집은 모양으로 나타남을 알 수 있는데, 이러한 그래프를 띠는 함수를 Convex function이라고 한다.
그리고 이러한 비용 함수에 대하여 결국 비용이 가장 작은 값을 갖게 되는 W 값을 찾는 것이 목적인데, 이를 찾는 알고리즘이 경사를 내려간다는 의미의 Gradient descent알고리즘이다.
이 알고리즘은 현재의 W깂에서 그 점에서의 기울기를 뺀 값으로 나타나고, 이를 반복 적용함으로서 결과를 도출한다. 기울기는 Cost function을 미분한 값이며 alpha 값은 learning rate라고 불리는 작은 상수 값이다.

Classification

Linear Regression은 어떠한 숫자를 예측하는 것이었다면, 오늘 다룰 Classification은 Binary의 개념 (둘 중 하나를 고르는) 이라고 할 수 있다. 예를 들면 이러한 것이다.

스팸 메일인지 아닌지를 탐지하는 것
Facebook에서 News feed 선별 알고리즘
신용 카드 학습 패턴 분류를 통한 도난 여부 식별
두뇌 이미지 분석을 통해 종양 악성 여부 판별
주식 시장 동향 분석을 통해 매입,매도 여부 판별

pass(1)/fail(0) based on study hours

아래와 같은 그림과 함께 생각해보자. 어떤 학생이 공부한 시간에 따라서 시험에 합격과 불합격을 분류하도록 학습 모델을 만들려고 할 때, 직관적으로 생각하면 그냥 Linear regression으로도 가능할 것이라는 생각이 들 수 있다.

그러나 여기에는 몇 가지 오류가 존재한다. 기존에 3개의 합격, 3개의 불합격 데이터를 가지고 합,불 여부를 결정짓는 어떤 지점을 찾았다고 가정하면 만약에 50시간을 공부해 합격한 학생이 있다고 했을 때, 이 모델은 결국 모든 데이터를 아울러 선형적으로 결정되기 때문에 그 값이 변할 수 있고, 결국 원래 합격이라고 판단되어야 할 학생이 불합격 기준으로 넘어갈 수밖에 없는 상황이 발생한다.

또 다른 문제는, Classification에서는 반드시 값이 0 또는 1로 결정되어야 하는데, Linear regression에서의 Hypothesis는 0보다 훨씬 작거나 1보다 훨씬 큰 값이 나올 수가 있게 된다.

Logistic Hypothesis

따라서 Logistic Classification에는 값의 범위를 0과 1로 제한하는 함수가 필요하다. 많은 이들의 연구 끝에 다음과 같은 함수가 이 모델에 가장 적합한 모습으로 채택되었다고 한다. 기존에 알고 있던 WX를 z로, H(x)를 g(z)로 변환하여 Logistic의 가설 함수를 표현한다.

이와 같은 함수를 Logistic function, 혹은 Sigmoid function 이라고 부른다. 가로 축 z값이 무한히 커질수록 g(z) 값은 1에 수렴하게 되고, z가 무한히 작아지면 0에 수렴하게 된다.

정리하면 Logistic Classification의 가설 함수는 위와 같이 형태가 된다.

5-2 Cost function & Gradient descent in Logistic classification

cost function

기존의 우리의 Cost function은 위와 같은 형태를 띠고 있었다. 이러한 형태의 함수가 가지는 장점은 어느 지점에서 시작하더라도 Cost가 최소가 되는 지점을 반드시 찾을 수 있다는 것이었다.

기존의 Hypothesis를 바탕으로 한 Cost function에서는 이차 방정식의 그래프의 형태를 가지기 때문에 어느 지점에서 시작하든 cost가 최소가 되는 지점을 찾을 수 있었던 데 반해,

Sigmoid function을 가설 함수로 갖는 Logistic classification에 동일한 Cost function을 적용하게 되면 그림 우측 하단과 같이 구불구불한 형태를 가지게 된다. 이로 인해서 시작하는 지점에 따라서 함수 전체의 최소 값(global minimum)을 찾을 수 없게 되고, Local Minimum이라는 특정 부분의 최소 지점에서 멈춰버리게 된다. 따라서 Linear에서와 다르게 변화된 Hypothesis에 맞추어 cost function 또한 다르게 적용해야 모델이 올바르게 예측할 수 있도록 할 수 있다.

Logistic Classification의 Cost function은 사진의 제목 아래에 보이는 것과 같이 y의 값이 0일 때와 1일 때로 나누어서 살펴볼 수 있다. 앞서 우리가 세운 새로운 가설 함수에 e 즉, exponential이 포함되어 있어 그래프가 구불구불해지는 현상 때문에 그와 상극인 log를 취해주어 부드러운 곡선의 형태로 만들어주게 된다. 그리고 이 정의에서 0과 1로 나눈 중요한 포인트는 각 경우마다 예측이 성공했을 경우 0의 값을 갖고, 틀렸을 경우 무한대로 수렴하도록 하는 로직이 포함되어 있기 때문이다. 이를 c function이라고 이름 짓고, 이들의 합을 구해 평균을 취한 것이 우리가 찾고자 하는 cost function이 된다.

위의 유도 과정에서 조건식을 배제하고 한 줄의 수식으로 표현하면 사진과 같다. 이는 복잡해보일 수 있지만 사실 y의 값이 0 혹은 1이기 때문에 둘 중 하나를 대입하게 되면 한 개의 항은 사라지게 되고, 앞서 살펴본 조건에서와 같은 수식이 나타난다.

Gradient descent 알고리즘의 큰 틀은 Linear regression과 동일하다. 처음 Gradient를 다룰 때에는 이 알고리즘의 원리를 이해하기 위해서 미분하는 과정까지 설명했지만 사실상 이 단계 이후부터는 그러한 과정은 필요하지 않고 사진에서와 같이 Cost function만 잘 세워주고 코드를 작성할 때 제공되는 라이브러리를 잘 사용하기만 하면 된다고 한다.

5-3 TensorFlow Practice (Logistic)

실습에 들어가기에 앞서, 우리가 이론 시간에 학습한 Hypothesis, Cost function, Gradient descent 수식은 위와 같다.

Practice 1

전체 코드를 살펴보면서 하나하나 짚어보도록 하자.

# Lab 5 Logistic Regression Classifier
import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

x_data = [[1, 2],
          [2, 3],
          [3, 1],
          [4, 3],
          [5, 3],
          [6, 2]]
y_data = [[0],
          [0],
          [0],
          [1],
          [1],
          [1]]

# placeholders for a tensor that will be always fed.
X = tf.placeholder(tf.float32, shape=[None, 2])
Y = tf.placeholder(tf.float32, shape=[None, 1])

W = tf.Variable(tf.random_normal([2, 1]), name='weight')
b = tf.Variable(tf.random_normal([1]), name='bias')

# Hypothesis using sigmoid: tf.div(1., 1. + tf.exp(tf.matmul(X, W)))
hypothesis = tf.sigmoid(tf.matmul(X, W) + b)

# cost/loss function
cost = -tf.reduce_mean(Y * tf.log(hypothesis) + (1 - Y) *
                       tf.log(1 - hypothesis))

train = tf.train.GradientDescentOptimizer(learning_rate=0.01).minimize(cost)

# 이 위까지 Graph 정의

# Accuracy computation
# True if hypothesis>0.5 else False
predicted = tf.cast(hypothesis > 0.5, dtype=tf.float32)
accuracy = tf.reduce_mean(tf.cast(tf.equal(predicted, Y), dtype=tf.float32))

# 아랫부분은 Model을 Train하는 과정

# Launch graph
with tf.Session() as sess:
    # Initialize TensorFlow variables
    sess.run(tf.global_variables_initializer())

    for step in range(10001):
        cost_val, _ = sess.run([cost, train], feed_dict={X: x_data, Y: y_data})
        if step % 200 == 0:
            print(step, cost_val)

    # Accuracy report
    h, c, a = sess.run([hypothesis, predicted, accuracy],
                       feed_dict={X: x_data, Y: y_data})
    print("\nHypothesis: ", h, "\nCorrect (Y): ", c, "\nAccuracy: ", a)

우선 x와 y의 데이터를 명세하는 부분을 살펴보면, x는 x1, x2의 array로 구성되고 y는 0과 1, 혹은true와 false의 값을 갖게 된다. 이해를 위해 우리가 항상 예제에서 사용하던 예시를 인용하면, 어떤 학생이 x1시간만큼 x2개의 동영상 강좌를 통해 학습하였을 때, y의 결과 (pass/fail)을 갖는다고 상황을 설정해볼 수 있겠다. 또한 placeholder를 선언하면서 shape을 명세할 때, 이전 섹션에서 살펴보았던 Matrix와 관련된 개념이 포함된다.

Logistic Classification의 hypothesis는 Sigmoid function의 형태를 갖기 때문에 기존에 우리가 알고 있던 X * W + b와 같은 수식에서 끝나는 것이 아니라 TensorFlow의 내장 함수인 tf.sigmoid를 통해 쉽게 표현할 수 있다고 한다. 코드의 주석에서 확인할 수 있듯이, 수식으로 직접 표현하려면 tf에 포함된 내장 수학 함수들을 통하여 표현할 수도 있다고 한다.

또한 Cost function의 경우에는 앞서 우리가 도출한 수식을 그대로 코드로 옮겨 적으면 되고, Minimize도 GradientDescentOptimizer를 사용하여 동일하게 작성해주면 된다.

predicted는 예측한 값이 0.5(0과 1사이의 값 중 보통 기준이 되는)와 크기 비교를 하여 true와 false가 아닌 type casting을 통해 0 또는 1의 값을 갖게 된다. 그리고 accuracy는 Y값과 predicted값이 일치하는지를 마찬가지로 0과 1로 표현하여 평균을 취한 값을 갖는다.

위 코드의 실행 결과는 아래와 같다.

0 1.73078
200 0.571512
400 0.507414
600 0.471824
800 0.447585
...
9200 0.159066
9400 0.15656
9600 0.154132
9800 0.151778
10000 0.149496
Hypothesis:
[[ 0.03074029]
 [ 0.15884677]
 [ 0.30486736]
 [ 0.78138196]
 [ 0.93957496]
 [ 0.98016882]]
Correct (Y):
[[ 0.]
 [ 0.]
 [ 0.]
 [ 1.]
 [ 1.]
 [ 1.]]
Accuracy:  1.0

10000번의 반복에서 매 Step을 지날수록 Cost는 점점 매우 작은 값으로 작아짐을 알 수 있고, 학습에 의한 결과값과 예측값, 정확도까지 코드를 보면서 생각할 수 있었던 대로 결과가 도출됨을 확인할 수 있었다.

Practice 2 - Classifying diabetes

이번 실습은 주어진 혈당 수치 데이터가 있고, 이를 바탕으로 어떤 환자의 당뇨병을 예측해보는 실습이다. 이번 실습에서는 데이터가 많기 때문에 아래와 같은 데이터를 파일 형태로 저장하여 numpy의 loadtext를 매개로 사용한다.

# Lab 5 Logistic Regression Classifier
import tensorflow as tf
import numpy as np
tf.set_random_seed(777)  # for reproducibility

xy = np.loadtxt('data-03-diabetes.csv', delimiter=',', dtype=np.float32)
x_data = xy[:, 0:-1]
y_data = xy[:, [-1]]

print(x_data.shape, y_data.shape)

# placeholders for a tensor that will be always fed.
X = tf.placeholder(tf.float32, shape=[None, 8])
Y = tf.placeholder(tf.float32, shape=[None, 1])

W = tf.Variable(tf.random_normal([8, 1]), name='weight')
b = tf.Variable(tf.random_normal([1]), name='bias')

# Hypothesis using sigmoid: tf.div(1., 1. + tf.exp(-tf.matmul(X, W)))
hypothesis = tf.sigmoid(tf.matmul(X, W) + b)

# cost/loss function
cost = -tf.reduce_mean(Y * tf.log(hypothesis) + (1 - Y) *
                       tf.log(1 - hypothesis))

train = tf.train.GradientDescentOptimizer(learning_rate=0.01).minimize(cost)

# Accuracy computation
# True if hypothesis>0.5 else False
predicted = tf.cast(hypothesis > 0.5, dtype=tf.float32)
accuracy = tf.reduce_mean(tf.cast(tf.equal(predicted, Y), dtype=tf.float32))

# Launch graph
with tf.Session() as sess:
    # Initialize TensorFlow variables
    sess.run(tf.global_variables_initializer())

    for step in range(10001):
        cost_val, _ = sess.run([cost, train], feed_dict={X: x_data, Y: y_data})
        if step % 200 == 0:
            print(step, cost_val)

    # Accuracy report
    h, c, a = sess.run([hypothesis, predicted, accuracy],
                       feed_dict={X: x_data, Y: y_data})
    print("\nHypothesis: ", h, "\nCorrect (Y): ", c, "\nAccuracy: ", a)

Python List 표현식에 따라 x_data는 전체 인스턴스(:)에서 마지막 열을 제외한 모든 값(0:-1)를 저장하고, y_data는 마찬가지로 전체 인스턴스를 가져오되 마지막 열에만 해당하는 ([-1])값을 취하여 리스트로 저장한다.

shape은 데이터의 크기에 맞게 x는 8개의 변수를 가지므로 8, 결과값 y는 1개의 열을 가지므로 1을 지정해준다.

나머지의 경우 실습 1번과 마찬가지로 학습 모델을 작성해준 뒤 결과를 확인해보면 아래와 같다.

0 0.82794
200 0.755181
400 0.726355
600 0.705179
800 0.686631
...
9600 0.492056
9800 0.491396
10000 0.490767

Hypothesis:
...
[0.74610120]
[0.79919308]
[0.72995949]
[0.882917188]

Correct (Y):
...
 [ 1.]
 [ 1.]
 [ 1.]]
Accuracy:  0.762846

전체 출력이 모두 작성되어있지는 않고, 예측값은 끝부분에 해당하는 결과만을 살펴보면 학습 결과값과 예측값은 모두 정상인데, 정확도가 100%가 아닌 것을 보면 출력되지 않은 부분에서 예측이 틀린 값이 존재했던 것으로 생각해볼 수 있다.

[course] 모두를 위한 딥러닝 강좌 04

Thu, 16 Jan 2020 21:02:05 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

Lecture 4. Multi-Variable Linear Regression

How to handle multi-variable

Predicting exam score

regression using one input (x)
- one-variable, one-feature

x(hours)	y(score)
10	90
9	80
3	50
2	60
11	40

기존에 수행하던 방식은 위와 같은 단일 변수에 의한 데이터에 기반하고 있다.

regression using three inputs (x1, x2, x3)
- multi-variable/feature

x1 (quiz 1)	x2 (quiz 2)	x3 (midterm)	y(final)
73	80	75	152
93	88	93	185
89	91	90	180
96	98	100	196
73	66	70	142

이처럼 여러 개의 변수를 다뤄야 하는 경우 Hypothesis는 어떻게 구할까?

위처럼 간단히 생각해서 각각에 대한 W와 x의 값을 곱해서 모두 더해주면 된다. 그렇지만 기존의 방식과 달리 학습시켜야 할 내용이 늘어난 것이다.

그렇다면 Cost function의 경우는 어떨까?

Cost function의 틀은 결국 같으나 바뀐 것은 우리의 가설, 즉 Hypothesis이다.

변수가 두세개가 아닌 훨씬 더 많을 때에도 마찬가지이다.

그저 마찬가지로 변수의 개수를 늘려주면 되는데, 변수가 많으면 많아질수록 항의 개수에 따라 수식을 길게 늘어뜨려 써야 해서 불편함이 발생하게 된다. 이것을 처리하기 위해서 Matrix의 개념을 도입하게 되는데, Matrix의 곱셈만을 사용할 것이다.

Hypothesis using matrix

Matrix를 사용하게 되면 길게 늘어진 수식을 위와 같이 간단하게 표현하고 연산할 수 있다. X에 대한 집합을 1*3 Matrix, W에 대한 집합을 3*1 Matrix로 두고 곱셈을 수행하면 우리가 원하던 수식을 연산할 수 있으며 하단과 같이 Matrix간의 곱셈 식으로 우리의 Hypothesis를 표현할 수 있다. (Matrix에서는 보통 X를 앞에 둔다.)

이 개념을 도입해서 위의 표에서 살펴본 x변수가 세 개인 성적 예측 문제를 다뤄볼 수 있다. 그런데 위의 표에서 확인한 것처럼 x1, x2, x3로 이루어진 한 묶음의 데이터 셋이 하나가 아니고 여러 줄로 이루어진 것을 알 수 있는데, 이 한 줄의 묶음을 instance라고 부르며, 이 instance들이 지금처럼 많을 때에는 물론 이를 반복적으로 수행하는 것도 방법이겠지만, 효율성 면에서 좋지 않다고 판단할 수 있다. 이 상황에서 Matrix의 굉장히 놀라운 장점은, x 변수들로 이루어진 각 인스턴스들에 대하여 표의 모양 그대로 하나의 Matrix를 줄 수 있다는 점이다.

다시말해, Hypothesis를 구성할 때, 아래처럼 x 변수에 대한 인스턴스들을 전부 하나의 Matrix로 만들고 하나의 W와 곱셈을 수행하기만 하면 되는 것이다.

그러면 이러한 형태의 Matrix 연산을 많이 하게 될 텐데 x에 대한 Variable의 개수와 Instance의 개수는 이미 주어진 상태이므로 Matrix X가 주어진 상태라고 볼 수 있게 된다. 또한 곱셈의 결과인 H는 행의 개수가 instance의 개수이고 y값은 하나이므로 이 또한 마찬가지로 주어진다고 볼 수 있다. 대부분의 경우 이러한 상황에서 W에 대한 매트릭스의 크기를 결정하는 것이 가설 설정의 일부분이라고 할 수 있다.

이는결국 행렬 곱셈의 원리를 알고 있다면 충분히 직관적으로 떠올릴 수 있는데 W는 곱셈의 우측에 해당하므로 행의 크기로 X의 Variable 개수, 그리고 열의 크기로는 결과에 해당하는 y의 개수이므로 1이 됨을 알 수 있다. 출력의 개수가 한 개가 아니더라도, 우리가 원하는 출력의 개수에 대해서는 우리가 이미 알고 있다는 가정이 존재하므로 그에 따라서 W의 열의 개수를 결정할 수 있다.

또한 위 예젱서는 우리가 instance의 개수를 5개로 두었지만, 이는 데이터의 개수가 늘어남에 따라 가변적으로 달라질 수 있기 때문에 n으로 둔다. (Numpy에서는 -1, TensorFlow에서는 None이라는 값으로 표현)

### lab 04-1: Multi-Variable linear regression을 TensorFlow로 구현

이론 시간에 표와 함께 살펴본 것과 같이 x 변수가 세 개로 구성된 성적 예측 문제를 실습할 것이다.

import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

x1_data = [73., 93., 89., 96., 73.]
x2_data = [80., 88., 91., 98., 66.]
x3_data = [75., 93., 90., 100., 70.]

y_data = [152., 185., 180., 196., 142.]

# placeholders for a tensor that will be always fed.
x1 = tf.placeholder(tf.float32)
x2 = tf.placeholder(tf.float32)
x3 = tf.placeholder(tf.float32)

Y = tf.placeholder(tf.float32)

w1 = tf.Variable(tf.random_normal([1]), name='weight1')
w2 = tf.Variable(tf.random_normal([1]), name='weight2')
w3 = tf.Variable(tf.random_normal([1]), name='weight3')
b = tf.Variable(tf.random_normal([1]), name='bias')

hypothesis = x1 * w1 + x2 * w2 + x3 * w3 + b

# cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))

# Minimize. Need a very small learning rate for this data set
optimizer = tf.train.GradientDescentOptimizer(learning_rate=1e-5)
train = optimizer.minimize(cost)

# Launch the graph in a session.
sess = tf.Session()
# Initializes global variables in the graph.
sess.run(tf.global_variables_initializer())

for step in range(2001):
    cost_val, hy_val, _ = sess.run([cost, hypothesis, train],
                                   feed_dict={x1: x1_data, x2: x2_data, x3: x3_data, Y: y_data})
    if step % 10 == 0:
        print(step, "Cost: ", cost_val, "\nPrediction:\n", hy_val)

이론 시간에 살펴봤던 표를 바탕으로 코드를 위와 같이 작성할 수 있다. 이전과 크게 다를 것이 없으나, x_data와 placeholder, weight를 정의하는 부분이 개수가 늘어남에 따라 확장되었다는 것이 차이점이 되겠다.

결과는 아래와 같다.

0 Cost: 19614.8
Prediction:
[ 21.69748688 39.10213089 31.82624626 35.14236832 32.55316544]
10 Cost: 14.0682
Prediction:
[ 145.56100464 187.94958496 178.50236511 194.86721802 146.08096313]
...
1990 Cost: 4.9197
Prediction:
[ 148.15084839 186.88632202 179.6293335 195.81796265 144.46044922]
2000 Cost: 4.89449
Prediction:
[ 148.15931702 186.8805542 179.63194275 195.81971741 144.45298767]

이론 시간에 배웠던 내용을 떠올려 보면, 위와 같은 코드는 아름답지 않다는 알 수 있을 것이다. 만약 x_data가 지금은 3개이지만, 100개가 된다면? 매우 복잡해질 것이므로 이러한 방법은 권장되지 않고 사용되지 않는다. 따라서 Matrix를 사용한다.

import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

x_data = [[73., 80., 75.],
          [93., 88., 93.],
          [89., 91., 90.],
          [96., 98., 100.],
          [73., 66., 70.]]
y_data = [[152.],
          [185.],
          [180.],
          [196.],
          [142.]]


# placeholders for a tensor that will be always fed.
X = tf.placeholder(tf.float32, shape=[None, 3])
Y = tf.placeholder(tf.float32, shape=[None, 1])

W = tf.Variable(tf.random_normal([3, 1]), name='weight')
b = tf.Variable(tf.random_normal([1]), name='bias')

# Hypothesis
hypothesis = tf.matmul(X, W) + b # matrix multiplication.

# Simplified cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))

# Minimize
optimizer = tf.train.GradientDescentOptimizer(learning_rate=1e-5)
train = optimizer.minimize(cost)

# Launch the graph in a session.
sess = tf.Session()
# Initializes global variables in the graph.
sess.run(tf.global_variables_initializer())

for step in range(2001):
    cost_val, hy_val, _ = sess.run(
        [cost, hypothesis, train], feed_dict={X: x_data, Y: y_data})
    if step % 10 == 0:
        print(step, "Cost: ", cost_val, "\nPrediction:\n", hy_val)

Matrix를 사용하게 되면 data를 표현하는 부분에 행렬식으로 표현을 해야해서 복잡해 보이는 것을 제외하면 나머지 부분들은 매우 간소화된 것을 확인할 수 있다. 몇 가지 짚고 넘어가면, X와 Y의 placeholder를 정의하는 부분에서 shape을 지정할 때, 변수 x에 대한 인스턴스의 개수는 5개로 위에서 정의했지만 몇 개가 되든 표현할 수 있게 하기 위해서 None이라는 필드를 통해 n개의 인스턴스를 표현할 수 있다.

또한 hypothesis를 지정하는 부분에서 보듯이, 행렬의 곱셈을 TensorFlow 함수인 matmul을 활용할 수 있음을 알 수 있다.(matrix multiplication)

실행 결과는 기존과 동일하다.

lab 04-2: Loading data from file

데이터가 점점 많아질수록, 데이터를 일일히 코드에 직접 적어서 사용하는 것이 불편하고 천개, 만개가 된다면 더더욱 불가능한 일이 될 것이다. 그래서 text file에 미리 데이터를 정의해두고 사용하는 방식을 채택하는데, 주로 많이들 사용하는 형식이 ,csv라는 확장자이다. 코드를 살펴보기 전에, Python에서 제공하는 list의 강력한 기능 중 하나인 Slicing에 대해서 살펴본다.

사실 필자도 이 강의를 보면서 처음 접한 내용이기도 한데 살펴보면 이러한 내용인 것 같다. 0,1,2,3,4 를 원소로 갖는 리스트가 있는데 nums[2:4]라고 작성하게 되면, index 2번에서부터 4번째 위치한 원소까지를 리스트로 반환한다. (개인적으로 왜 이렇게 하는지 모르겠다.) 또한 nums[:]와 같이 작성하게 되면 리스트 전체를 반환하고, nums[:-1]과 같이 작성하면 마지막 원소를 제외하고 반환한다고 한다.

또한 Numpy에서는 더 강력한 slicing과 indexing을 제공한다고 하는데, 이는 기본 기능과 유사하며 사진을 참고하고 나중에 더 자세히 살펴보면 될 것 같다.

data-01-test-score.csv

# EXAM1,EXAM2,EXAM3,FINAL
73,80,75,152
93,88,93,185
89,91,90,180
96,98,100,196
73,66,70,142
53,46,55,101

위와 같은 데이터를 .csv 확장자를 활용하여 파일 형태로 정의한 뒤, 아래와 같은 코드를 통해 다루는 실습을 해보자.

import tensorflow as tf
import numpy as np
tf.set_random_seed(777)  # for reproducibility

xy = np.loadtxt('data-01-test-score.csv', delimiter=',', dtype=np.float32)
x_data = xy[:, 0:-1] # 전체 n개의 행과 마지막을 제외한 열 전체를 취하겠다는 의미.
y_data = xy[:, [-1]] # 전체 n개의 행과 마지막 열에 해당하는 리스트를 반환.

# Make sure the shape and data are OK --> 학습시키기 전 가져온 데이터가 맞는지 확인.
print(x_data, "\nx_data shape:", x_data.shape)
print(y_data, "\ny_data shape:", y_data.shape)

# placeholders for a tensor that will be always fed.
X = tf.placeholder(tf.float32, shape=[None, 3])
Y = tf.placeholder(tf.float32, shape=[None, 1])

W = tf.Variable(tf.random_normal([3, 1]), name='weight') # W의 shape은 X와 Y의 shape의 조합.
b = tf.Variable(tf.random_normal([1]), name='bias')

# Hypothesis
hypothesis = tf.matmul(X, W) + b

# Simplified cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))

# Minimize
optimizer = tf.train.GradientDescentOptimizer(learning_rate=1e-5)
train = optimizer.minimize(cost)

# Launch the graph in a session.
sess = tf.Session()
# Initializes global variables in the graph.
sess.run(tf.global_variables_initializer())

for step in range(2001):
    cost_val, hy_val, _ = sess.run([cost, hypothesis, train],
                                   feed_dict={X: x_data, Y: y_data})
    if step % 10 == 0:
        print(step, "Cost:", cost_val, "\nPrediction:\n", hy_val)

위와 같은 코드를 통해 학습을 시킨 후, 아래와 같이 실행하여 학습 여부를 확인해볼 수 있다.

# Ask my score
print("Your score will be ", sess.run(hypothesis,
                                      feed_dict={X: [[100, 70, 101]]}))

print("Other scores will be ", sess.run(hypothesis,
                                        feed_dict={X: [[60, 70, 110], [90, 100, 80]]}))

Your score will be  [[ 181.73277283]]
Other scores will be  [[ 145.86265564]
 [ 187.23129272]]

이처럼 Numpy를 활용하여 파일을 통해 데이터를 가져오고, 그것을 처리하는 실습을 진행했다. 그런데 File이 크거나 많아서 메모리에 한번에 올릴 수 없는 경우가 있을 수도 있다. 그래서 TensorFlow에서는 Queue Runners라는 것이 존재하는데, 이러한 문제를 TensorFlow 내에서 알아서 처리해주도록 만들어준 프로세스라고 한다. 그 동작 과정이 대략 아래와 같다.

처리하고자 하는 파일들의 리스트를 만들어준다.
사용할 File Reader를 정의한다.
읽어온 value 값을 어떻게 파싱할지를 결정한다. (예시에서는 decode_csv)

이러한 과정들을 거친 뒤 TensorFlow에서 제공하는 batch라는 함수를 통해서 분류하고 한 번에 묶어주는 작업을 진행한다. (batch의 사전적 의미가 “일괄”이다.) (교수님은 이 batch를 펌프에 비유하심.)

Queue Runners 방식으로 학습 데이터를 가져오는 전체 실습 코드는 아래와 같다.

import tensorflow as tf
tf.set_random_seed(777)  # for reproducibility

filename_queue = tf.train.string_input_producer(
    ['data-01-test-score.csv'], shuffle=False, name='filename_queue')

reader = tf.TextLineReader()
key, value = reader.read(filename_queue)

# Default values, in case of empty columns. Also specifies the type of the
# decoded result.
record_defaults = [[0.], [0.], [0.], [0.]]
xy = tf.decode_csv(value, record_defaults=record_defaults)

# collect batches of csv in
train_x_batch, train_y_batch = \
    tf.train.batch([xy[0:-1], xy[-1:]], batch_size=10)

# placeholders for a tensor that will be always fed.
X = tf.placeholder(tf.float32, shape=[None, 3])
Y = tf.placeholder(tf.float32, shape=[None, 1])

W = tf.Variable(tf.random_normal([3, 1]), name='weight')
b = tf.Variable(tf.random_normal([1]), name='bias')

# Hypothesis
hypothesis = tf.matmul(X, W) + b

# Simplified cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))

# Minimize
optimizer = tf.train.GradientDescentOptimizer(learning_rate=1e-5)
train = optimizer.minimize(cost)

# Launch the graph in a session.
sess = tf.Session()
# Initializes global variables in the graph.
sess.run(tf.global_variables_initializer())

# Start populating the filename queue.
coord = tf.train.Coordinator()
threads = tf.train.start_queue_runners(sess=sess, coord=coord)

for step in range(2001):
    x_batch, y_batch = sess.run([train_x_batch, train_y_batch])
    cost_val, hy_val, _ = sess.run(
        [cost, hypothesis, train], feed_dict={X: x_batch, Y: y_batch})
    if step % 10 == 0:
        print(step, "Cost: ", cost_val, "\nPrediction:\n", hy_val)

coord.request_stop()
coord.join(threads)

# Ask my score
print("Your score will be ",
      sess.run(hypothesis, feed_dict={X: [[100, 70, 101]]}))

print("Other scores will be ",
      sess.run(hypothesis, feed_dict={X: [[60, 70, 110], [90, 100, 80]]}))

결과는 Numpy로 데이터를 가져왔을 때와 동일하다.

[course] 모두를 위한 딥러닝 강좌 03

Mon, 13 Jan 2020 21:01:11 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

~~이론 부분에 해당하는 내용은 수식을 표현하는 플러그인을 잘 다룰줄 몰라서 사진으로 찍을수밖에 없어 길어진다…~~

Lecture 3. Linear Regression cost 함수 최소화

How to minimize cost

Cost(W)은 어떻게 생겼을까?

설명을 위해, Hypothesis를 간소화시켜 살펴보자.

bias 를 의미하는 b를 0이라고 생각하고, Cost function을 W의 함수라고 생각하고 아래의 표와 같은 데이터가 있다고 생각해보자.

x	y
1	1
2	2
3	3

이와 같은 데이터를 가지고, Cost function에 대입해보면, 아래와 같은 결과를 도출할 수 있다.

W가 2일 경우에도 마찬가지로 4.67과 같은 값을 결과로 갖는다. 이를 토대로 여러 값을 대입하여 cost 결과값을 구해보면 우리가 기존에 가정한 H(x) = Wx는 위의 표와 같은 데이터에 대해 y축을 cost, x축을 W로 둔 그래프에서 아래와 같은 Cost의 분포를 가진다고 할 수 있다.

우리가 목적하는 Cost가 최소가 되는 지점의 W값은 1이 된다는 것을 직관적으로 알 수 있다. 하지만 이를 눈으로 보고 아는 것이 아닌, 기계적으로 찾아내려고 한다면 어떻게 해야 할까?

Gradient descent algorithm

직역하면, “경사를 따라 내려가는” 알고리즘이다.

특징

Minimize cost function
Gradient descent is used many minimization problems
For a given cost function, cost(W, b), it will find W, b to minimize cost
It can be applied to more general function: cost(w1, w2, …)

이 알고리즘은 어떻게 동작할까?

어느 점에서나 시작할 수 있고
cost를 줄이는 방향으로W와 b 값을 아주 조금씩 변경한다.
최소가 되는 지점을 만날 때까지 계속해서 반복한다.

경사도(Gradient)에 대해서 설명하기 위해 미분의 개념을 도입할텐데, 적용하기에 앞서 기울기에 대한 공식을 먼저 정리한다.

우선, 원래의 Cost function에서 2를 더 나눈 이유는, 사실상 2로 나눈 것이 값에 큰 차이를 주지는 않으나, 뒤에서 도출될 수식을 간단하게 하기 위해서라고 한다.
아래의 공식은, 최저점을 찾기 위해 W에서 cost를 미분한 값을 빼서 아주 작은 좌표이동을 하겠다는 의미라고 생각하면 된다. (여기서 alpha는 learning rate를 가리키며 매우 작은 상수 값을 의미한다고 한다.)

이 알고리즘을 여러 번 실행 시켜 W값이 계속해서 변화되면, 그 값이 초반에 살펴보았던 cost를 minimize하는 값이 되는 것이다.

아래의 파란 박스로 표시한 수식이 최종적인 Gradient descent algorithm이다. 이 알고리즘을 기계적으로 적용하면, cost function을 최소화 하는 W 값을 구할 수 있고 그 것이 바로 Linear Regression의 핵심인 학습을 통해 model을 만드는 과정이라고 이해하면 되겠다.

끝으로

위의 그림에서와 같은 그래프를 갖는 cost function에서는 우리가 지금까지 생각한 알고리즘이 정상적으로 동작하지 않는다. 왜냐하면 시작점을 다르게 잡았을 때, 경사를 타고 최종 도착하는 최저점이 다른 위치가 되기 때문이다.

다행히도, 우리의 Hypothesis와 Cost function을 가지고 그래프를 그리게 되면 위와 같은 그래프를 얻을 수 있는데, 이와 같은 그래프를 Convex Function이라고 한다. 이런 경우에는 어느 점에서 시작하든, 도착하는 지점이 우리가 원하는 지점이고 우리의 Gradient descent algorithm이 항상 답을 찾는다는 것을 보장해주게 된다.

Cost function을 설계할 때, 반드시 모양이 Convex function이 되는지를 확인하는 것이 굉장히 중요하다.

TensorFlow 실습

import tensorflow as tf
import mathplotlib as plt
X = [1, 2, 3]
Y = [1, 2, 3]

W = tf.placeholder(tf.float32)
# Our hypothesis for linear model X * W
hypothesis = X * W

# cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))
# Launch the graph in a session.
sess = tf.Session()
# Initialize global variables in the graph.
sess.run(tf.global_variables_initializer())
# Variables for plotting cost function
W_val = []
cost_val = []
for i in range(-30, 50):
    feed_W = i * 0.1
    curr_cost, curr_W = sess.run([cost, W], feed_dict={W: feed_W})
    W_val.append(curr_W)
    cost_val.append(curr_cost)

# Show the cost function
plt.plot(W_val, cost_val)
plt.show()

위의 코드는 주어진 데이터 X와 Y에 대하여 우리의 가설 함수 H(x) = W * X의 cost function의 그래프를 그리는 프로그램이라고 할 수 있겠다. -3에서부터 5까지 W를 0.1만큼씩 변화하도록 실행하여 현재의 cost, 그리고 W 값을 리스트에 저장하여 그 리스트로 하여금 어떠한 그래프를 나타내는지를 시각화해주는 코드이다. (mathplot이라는 라이브러리가 그러한 동작을 하도록 하는 모양이다.)

plot.show()를 통해 나타나는 결과는 아래와 같다.

이제 Gradient descent를 적용할 단계인데, 그에 대한 설명이 이어진다.

이론 시간에 학습했던 것처럼, 경사를 타고 내려가는 알고리즘이 동작하는 방식은 현재의 W 값에서 cost function을 미분한 값(그래프의 기울기)를 빼줌으로서 조정하여 그래프의 면을 타고 내려가는 방식이다. (기울기가 음수일때는 커지는 방향으로)

이를 tensorflow로 구현하는 것은 수식을 그대로 옮겨서 표현하면 된다.

learning_rate = 0.1
gradient = tf.reduce_mean((W * X - Y) * X) # cost를 미분한 기울기값.
descent = W - learning_rate * gradient
update = W.assign(descent) # 새로운 W 획득 (할당), =으로 assign 할 수 없음.

전체 코드를 살펴보면 다음과 같다.

import tensorflow as tf
x_data = [1, 2, 3]
y_data = [1, 2, 3]

W = tf.Variable(tf.random_normal([1]), name='weight')
X = tf.placeholder(tf.float32)
Y = tf.placeholder(tf.float32)
# Our hypothesis for linear model X * W
hypothesis = X * W

# cost/loss function
cost = tf.reduce_sum(tf.square(hypothesis - Y))

# Minimize: Gradient Descent using derivative: W -= learning rate * derivative
learning_rate = 0.1
gradient = tf.reduce_mean((W * X - Y) * X)
descent = W - learning_rate * gradient
update = W.assign(descent)

# Launch the graph in a session.
sess = tf.Session()
# Initialize global variables in the graph.
sess.run(tf.global_variables_initializer())
for step in range(21):
    sess.run(update, feed_dict={X: x_data, Y: y_data})
    print(step, sess_run(cost, feed_dict={X: x_data, Y: y_daa}), sess.run(W))

이 코드에 대한 결과는 아래와 같다.

프린트 문에 의해 한 라인에 출력된 내용은 step, cost, W의 순서인데 수동으로 직접 구현해서 실행해보았는데도 매우 잘 동작하는 것을 확인할 수 있었다.

Gradient Descent의 원리를 직접 실습하기 위해 직접 미분하여 결과를 도출했지만 우리의 cost function이 간단하게 주어졌기 때문에 간단하게 미분하여 작성할 수 있었고 이는 매우 복잡해질 수 있기 때문에 TensorFlow를 사용할 때 이를 일일히 작성하는 것은 힘든 일이다.

아래와 같이 코드를 작성하면 TensorFlow가 일을 직접 자동으로 실행해준다.

# Minimize: Gradient Descent Magic
optimizer = tf.train.GradientDescentOptimizer(learning_rate=0.1)
train = optimizer.minimize(cost)

위의 전체 코드에서 W = tf.Variable(tf.random_normal([1]), name='weight') 을 5.0 혹은 -3.0과 같이 멀리 떨어진 값으로 직접 값을 지정해 주어도 올바른 결과를 도출하는 모습을 확인할 수 있었다.

Optional: computegradient and applygradient

만약에 TensorFlow가 제공하는 gradient 값을 임의로 조정하고 싶다면 아래와 같은 로직을 확인해볼 수 있다.

import tensorflow as tf
x_data = [1, 2, 3]
y_data = [1, 2, 3]

# Set  wrong model weights
W = tf.Variable(5.)

# Our hypothesis for linear model X * W
hypothesis = X * W
# Manual gradient
gradient = tf.reduce_mean((W * X - Y) * X) * 2
# cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - Y))
optimizer = tf.train.GradientDescentOptimizer(learning_rate=0.01)

# Get gradients
gvs = optimizer.compute_gradients(cost)
# Apply gradients
apply_gradients = optimizer.apply_gradients(gvs)

# Launch the graph in a session.
sess = tf.Session()
sess.run(tf.global_variables_initializer())

for step in range(100):
    print(step, sess_run([gradient, W, gvs]))
    sess.run(apply_gradients)

위 코드는 직접 수식으로 작성한 gradient와 실제로 minimize를 할 때 optimizer가 도출하는 gradient 값이 차이를 보일지를 실험해보기 위한 코드이다.

compute_gradient를 통해 gradient를 조작할수 있다고 한다. 여기서는 조작 없이 값을 원래대로 넣어 비교 실험을 위해 작성하였다.

결과는 아래와 같다.

수식을 직접 작성한 gradient와 optimizer가 생성하는 gradient의 값, 그리고 그로 인해 연산된 W 값은 소수점 정밀도의 미미한 차이만 있을 뿐 같은 값을 가진다는 것을 확인할 수 있었다.

결과와 출력문의 구조가 혼동될 수도 있을 것 같아 덧붙이자면, print(step, sess.run([gradient, W, gvs]))와 같이 작성하였는데 출력의 첫 줄과 비교해보면 0 은 step에 해당하고, 37.333332는 gradient, 5.0은 W, 그 뒤에 뒤따르는 배열 내의 두 원소는 compute_gradient에 의한 gradient와 W값을 의미한다.

[course] 모두를 위한 딥러닝 강좌 02-2

Sat, 11 Jan 2020 21:01:52 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

섹션 2 실습 (Linear regression 구현)

실습하기 전에, Hypothesis와 Cost function 복습!

Hypothesis란, 주어진 x에 대하여 우리가 예측을 어떻게 할 것인가 라는 것을 말한다. 이는 W와 x 의 곱, 그리고 bias와의 합으로 결정된다. 그리고 이 것을 얼마나 잘 예측했는가를 측정하기 위해 예측 값과 참 값의 차이의 제곱을 전체 데이터의 개수로 나눈 평균이 바로 Cost function이라고 한다. 따라서 Cost function은 W와 b에 대한 함수이며, 학습을 한다라는 것은 이 W와 b를 조작하여 Cost function을 가장 작은 값이 되도록(Minimize) 하는 것이라고 볼 수 있다.

또한 TensorFlow로 실습을 할 때에는 다음과 같은 과정을 진행하는 것이다.(지난 시간 복습)

첫 번째로, TensorFlow Operation을 이용해서 Graph(Tensors)를 빌드해야 한다.
그 다음, sess.run을 통해 data를 넣은 뒤 우리가 만든 Graph를 실행시킨다.
그 결과로, 그래프 안에 있는 어떠한 값들이 update되거나, 어떠한 값을 return하게 된다.

1. Build graph using TF operations

# X and Y data
x_train = [1, 2, 3]
y_train = [1, 2, 3]

W = tf.Variable(tf.random_normal([1]), name='weight') # [1] -> 값이 하나인 1차원 array (shape)
b = tf.Variable(tf.random_normal([1]), name='bias')

# Our hypothesis Wx + b
hypothesis = x_train * W + b

위의 코드에서 보는 것처럼, H(x)를 만들기 위해서 W와 b를 정의해야 하는데, 이는 TensorFlow의 Variable이라는 함수로 정의할 수 있다. 그런데 이 Variable이라는 것은 우리가 기존에 알던 프로그래밍에서의 변수와는 조금 다른 개념인데, 우리가 사용하는 것이 아닌, TensorFlow가 사용하는 변수이고, 텐서플로를 실행시키면 텐서플로가 학습하는 과정에서 자체적으로 변경시키는 값이라고 보면 된다. (Trainable한 변수이다.)

텐서플로에서 Variable을 만들 때, 그 변수의 shape을 결정하고, 값을 주면 된다. 여기서는 W와 b의 값을 모르기 때문에, tf의 함수 random_normal을 이용해서 shape을 결정하여 정의한다.

# cost/loss function
cost = tf.reduce_mean(tf.square(hypothesis - y_train))

위 코드 또한 마찬가지로 위의 그림에서와 같이 Cost function에 해당하는 수식을 그대로 옮긴 것이다. square라는 함수를 이용하여 예측 값에서 참 값을 뺀 것을 제곱하고, reduce_mean 함수를 통해 값을 평균내준다.

그리고 여기서 우리의 목적은 이 Cost를 Minimize 하는 것이기 때문에, TensorFlow에는 여러가지 방법이 있지만 여기서는 GradientDescent 라는 것을 이용한다. 지금 단계에서는 그냥 Magic이라고 생각하면 된다.

# Minimize
optimizer = tf.train.GradientDescentOptimizer(learning_rate=0.01)
train = optimizer.minimize(cost)

즉, GradientDescent를 사용하여 optimizer를 정의하고, 그것의 minimize라는 함수를 호출하여 우리가 정의한 cost를 주면, 텐서플로가 우리가 앞서 정의한 W와 b를 조정하여 스스로 Minimize하게 된다. 아직 이 부분은 매직이라고 생각하고, 여기까지가 Graph를 만드는 과정이었다.

####2,3 Run/update graph and get results 그래프를 만들었다고 실행되는 것이 아니므로 아래와 같은 과정을 거쳐야 한다.

# Launch the graph in a session.
sess = tf.Session();
# Initializes global variables in the graph.
sess.run(tf.global_variables_initializer())

# Fit the line
for step range(2001):
    sess.run(train)
    if step % 20 == 0:
        print(step, sess.run(cost), sess.run(W), sess.run(b))

앞서 우리는 W와 b라는 Tesnorflow Variable을 만들어 주었는데, 이를 사용하여 실행하기 전에는 반드시 global_variables_initializer을 실행시켜 주어야 한다.

또, 코드의 아랫부분을 확인해보면, sess.run(train)을 통해 train 노드만 실행시키는 것을 확인할 수 있는데, 이는 우리가 위에서 만든 그래프의 대강의 모양새가 아래와 같기 때문이다.

train이 루트 노드에 해당하고, 그래프를 따라 들어가서 W와 b에 어떠한 값을 저장할 수 있게 연결되어 있기 때문에 이러한 방식으로 학습이 일어나게 되는 것이다.

전체의 코드를 실제로 실행시켰을 때의 결과는 아래와 같다.

처음에는 정말 Random한 값이었지만, 학습을 반복할수록 cost는 매우 작은 값으로, W와 b의 값이 우리가 원하는 값(1과 0)으로 수렴하는 것을 볼 수 있다.

Placeholders

지난 시간에 배운 것처럼, Placeholder라는 개념이 있었는데, 이를 활용해서도 Linear regression을 실행해볼 수 있다.

총 정리

아마 이 그림을 통한 텐서플로우의 동작 과정을 이해하는 것이 가장 중요하기 때문에 반복적으로 설명하시는 것 같다. 그런 의미에서 다시 한번 복습!

첫 번째로, TensorFlow Operation을 이용해서 Graph(Tensors)를 빌드해야 한다.
그 다음, sess.run을 통해 data를 넣은 뒤 우리가 만든 Graph를 실행시킨다.
그 결과로, 그래프 안에 있는 어떠한 값들이 update되거나, 어떠한 값을 return하게 된다.

~~다음엔 꼭 한 섹션(이론 + 실습)을 한 편으로 구성해서 작성해야겠다…~~

[course] 모두를 위한 딥러닝 강좌 02-1

Thu, 09 Jan 2020 21:01:39 GMT

이 포스팅은 인프런 머신러닝 강좌 를 수강하며 공부한 내용을 정리한 것입니다.
코드 출처

지난 시간에 못한 TensorFlow 실습

섹션 1 실습 (기본적인 operations)

import tensorflow as tf

hello = tf.constant("Hello, TensorFlow!")

sess = tf.Session()

print(sess.run(hello))

위의 코드는 우리가 프로그래밍을 배우면서 가장 흔히 알고, 가장 기본적인 hello world를 텐서플로에서 실행하는 코드이다. 정말 간단하지만, 나 스스로도 텐서플로와 머신러닝을 처음 접하기 때문에, 하나하나 살펴보자면 tensorflow 를 import 하여 tf라는 이름으로 사용하기로 했었다. tf.constant라는 함수를 호출하여 "Hello, TensorFlow!"라는 문자열을 hello라는 변수에 저장하는 것이다. 이렇게 되면 앞서 배운 것과 같이 아무 Edge도 없는 Data Flow Graph에 hello라는 이름의 하나의 노드 가 생긴 것이다. 여기서 그냥 출력을 해도 되지만, Computational Graph를 실행하기 위해서는 Session이라는 것을 만들어야 하고 이 세션을 통해 .run을 호출하여 sess라는 이름의 텐서플로 세션을 통해 hello라는 노드를 실헹하겠다는 것을 의미한다.

이러한 과정을 통해 출력된 결과는 다음과 같다.

b'Hello, TesorFlow!'

여기서 b는 Byte literals라는 것임을 의미한다. 바이트 스트링에 대한 자세한 예는 이 곳에 나와있다고 한다.

다음 예제는 위와 같은 Computational Graph를 구현하는 것이다. a라는 노드와 b라는 노드를 하나의 다른 노드로 연결시키는 것이다. 아래와 같이 작성해보자.

node1 = tf.constant(3.0, tf.float32)
node2 = tf.constant(4.0) #also tf.float32 implicitly
node3 = tf.add(node1, node2) #node3 = node1 + node2

print("node1:", node1, "node2:", node2)
print("node3:", node3)

이에 대한 출력 결과는 아래와 같다.

node1: Tensor("Const_1:0, shape=(), dtype=float32) node2: Tensor("Const_2:0, shape=(), dtype=float32)
node3: Tensor("Add:0, shape=(), dtype=float32)

이를 출력하면 텐서플로가 이들은 그저 그래프 안의 요소(Tensor)라고 대답한다. 일반적인 경우처럼 연산에 대한 결과값이 나오는 것이 아니라, 각 Tensor들의 속성에 대한 정보만 출력한다.

그렇다면 연산을 실행하려면 어떻게 해야할까?

앞서 Hello TensorFlow!를 출력했던 것과 같이 Session을 만들어 주어야 한다.

sess = tf.Session()
print("sess.run([node1, node2]): ", sess.run([node1, node2]))
print("sess.run(node3): ", sess.run(node3))

이렇게 작성해야 비로소 우리가 얻고 싶은 결과를 얻을 수 있다.

sess.run([node1, node2]): [3.0, 4.0]
sess.run(node3): 7.0

여기까지 공부하면서, 우리는 다음과 같이 정리해볼 수 있다.

텐서플로우는 기존에 우리가 생각하는 프로그램과 약간 다르게 동작한다.

첫 번째로, TensorFlow Operation을 이용해서 Graph(Tensors)를 빌드해야 한다.
그 다음, sess.run을 통해 data를 넣은 뒤 우리가 만든 Graph를 실행시킨다.
그 결과로, 그래프 안에 있는 어떠한 값들이 update되거나, 어떠한 값을 return하게 된다.

그래프는 미리 만들어두고 실행시키는 단계에서 입력을 줄 수는 없을까?

a = tf.placeholder(tf.float32)
b = tf.placeholder(tf.float32)
adder_node = a + b

print(sess.run(adder_node, feed_dict={a: 3, b:4.5}))
print(sess.run(adder_node, feed_dict={a: [1, 3], b: [2,4]}))

7.5
[ 3.  7. ]

이처럼 placeholder를 활용하여 처음에 값을 지정하지 않은 노드를 만들 수 있고, feed_dict를 통해 sess.run을 실행하는 과정 중에 동적으로 값을 전달할 수 있다. sess.run(op, feed_dict={x: x_data}) 와 같은 용법으로 사용할 수 있다.

Tensor란 그래서 정확히 무엇인가?

기본적으로 배열로 표현되는 모든 것이 Tensor라고 한다.

Tensor는 Rank, Shape, Types 로 나누어 이야기 할 수 있는데,

Rank란 몇 차원 배열이냐 라는 의미에 해당한다.
- s = 483 은 Rank 0이며 수학적으로는 Scala 라고 불린다. 1차원은 Vector, 2차원은 Matrix …

Shape란 각 Element에 몇 개씩 들어있는가?
- 다시 말해, 각 Rank에 해당하는 element들이 몇 개씩인지를 의미한다.
- Tensor 설계 시 Shape는 매우 중요한 개념이라고 한다…
- 예를 들면 아래의 배열은 [2,2,3] Shape이다.

[
    [
        [1,2,3],[4,5,6]
    ],
    [
        [7,8,9],[10,11,12]
    ]
]

Type이란 말 그대로 data type을 말한다.
- 주로 tf.float32, tf.int32를 주로 사용한다고 한다.

내용이 조금 길어지는 것 같아서 나누어 다루어야 할 것 같다. ~~실습 한 강좌인데 정리하면서 들으려니까 왜이렇게 오래걸리는지…~~

[course] 모두를 위한 딥러닝 강좌 01

Mon, 06 Jan 2020 22:02:24 GMT

이 포스팅은 인프런 머신러닝 강좌를 수강하며 공부한 내용을 정리한 것입니다.

사실 이 강좌에 대해서 접한 지는 꽤 오랜 시간이 지났는데, 수강하게 된 것도, 이 분야를 접하게 된 것도 지금에 와서야 라서 아쉬운 감이 있다.

섹션1. 머신러닝의 개념과 용어

머신러닝이란 무엇인가?

머신러닝은 일종의 소프트웨어, 프로그램. 우리가 보는 앱과 같은 프로그램은 explicit programming. 주어진 환경에서 특정한 반응을 하도록 만들어 두었기 때문에. 스팸 필터, 자율 주행과 같은 경우에는 Too many rules에 부딪히는 한계. 1959년 Arthur Samuel에 의하여 제안된 개념으로 명시적으로 프로그래밍 하지 않고 컴퓨터가 스스로 학습할수 있는 능력을 부여하는 것에 대해 연구하는 분야를 머신 러닝이라고 한다.

학습하는 방법

Supervised learning

어떤 레이블들이 정해져 있는 데이터(=Training set이라고도 함)를 갖고 학습하는 것. 일례로, 이미지를 주고, cat, dog, mug, hat 등등을 식별하게 하는 것도 각 이미지에 식별 대상에 대한 정보인 label를 달아서 데이터를 제공 받아서 학습한 것이다.

Unsupervised learning

일일히 label을 주어서 학습할 수 없는 경우. supervised learning과 반대되는 개념이다. 예로, 구글 뉴스는 자동적으로 유사한 뉴스들을 그루핑해주는데, 이 경우에는 그 전에 미리 label을 정해주기 어렵다. word clustering과 같은 경우에도 마찬가지.

이 강좌에서는 주로 지도 학습(Supervised learning)에 대하여 다룰 것아다.

ML에서의 일반적인 문제 유형

Image labeling
Email spam filter
Predicting exam score

Training data set

특정한 입력 값 x와 결과 값 y로 이루어진 label을 제공하여 어떠한 임의의 입력을 주었을 때, 그에 맞는 결과가 나오게끔 ML 모델이 학습하도록 하는 data set, 즉 앞서 말한 label을 말한다. 반드시 필요하다.

AlphaGo를 예로 들면, 기존에 존재하던 바둑 기보들이 학습을 위한 training data set이 될 것이고, 이세돌 9단과 대국 중에 놓여진 바둑판의 정보가 입력이 되며, 알파고가 돌을 두는 위치가 출력이라고 할 수 있다.

지도 학습의 유형

Predicting final exam score based on time spent 을 기준으로 예를 들어

이를 넓은 점수 범위에 대해서 예측하는 것을 regression 이라고 한다.
regression model

x(hours)	y(score)
10	90
9	80
3	50
2	30

혹은 pass/fail과 같은 이분법적으로 나누어 예측하는 것을 binary-classification이라고 한다.
binary-classification model

x(hours)	y(score)
10	P
9	P
3	F
2	F

문자화된 grade를 매기려고 하는데, A,B,C,D,F와 같이 점수를 매기는 것을 예측하려고 한다면 multi-label classification이라고 한다.
regression model

x(hours)	y(score)
10	A
9	B
3	D
2	F

TensorFlow

Tensorflow란 Machine intelligence를 위한 Open source library이다. 당시(꽤 오래 전 강좌이므로) Github 내에서 여러 딥러닝 오픈소스 라이브러리들을 컨트리뷰션과 이슈, 포크 수 등으로 점수를 매겨서 나열했을 때, 여러 방식으로 점수를 매겨봐도 TensorFlow가 단연 일등이다.

TesnorFlow란 무엇인가?

data flow graph를 사용하여 numerical computation을 할 수 있는 오픈소스 소프트웨어 라이브러리다.(그리고 Python 사용!)

What is data flow graph?

그래프 안의 노드들은 각각 어떠한 수학적 연산을 의미한다. 그 노드들 사이의 edge들 (다른 말로 tensor들)은 다차원의 data array를 의미하며 상호작용하는 데이터라고 볼 수 있다. 이처럼 DFG내에서 Tensor들이 흐른다고 하여 TensorFlow라고 부른다고 한다.

Installing TensorFlow

(sudo -H) pip install --upgrade tensorflow

꽤 오래걸린다. 한시간 내외 가량 소요되는 듯하다. 이건 예상 못했기 때문에 이 부분에 대한 실습 관련 내용은 추가적인 포스팅으로 다루도록 해야겠다.

실습과 관련된 코드는 이 코스를 운영하시는 교수님의 Repository에 있다고 한다.

섹션2. Linear Regression의 개념.

Linear Regression의 Hypothesis와 cost

Predicting exam score: regression

(앞서 예로 들었던) 어떠한 학생이 공부한 시간 만큼 어떠한 성적(0~100)이 나온다는 데이터를 가지고 Supervised learning을 시킨다고 하자.

regression model

x(hours)	y(score)
10	90
9	80
3	50
2	30

Regression이란 모델이 Training data를 가지고 Regression model이 학습을 하게 되었을 때, 7시간 공부한 학생에 대한 점수를 요청하면, 그에 대한 y값을 준다는 맥락이다.

x	y
1	1
2	2
3	3

위와 같은 training data가 있다고 했을 때, regression 모델을 학습시킨다고 하면 다음과 같은 형태의 그래프가 만들어진다.

(Linear) Hypothesis

Regression Model을 학습시킨다는 것은 하나의 가설을 세울 필요가 있는데

어떤 Linear한 Model이 우리가 가지고 있는 데이터에 맞을 것이다

와 같은 것이 Linear Regression이라고 한다. 이것은 굉장히 효과적인데, 세상에 있는 많은 데이터와 현상들이 이처럼 Linear한 것으로 드러나거나 설명될 수 있는 것이 많기 때문이다.

가설을 세운다는 것은 어떠한 데이터가 있다면 거기에 잘 맞는 선을 찾는 과정으로 생각할 수 있다. 아래의 그림과 같이 어떤 선이 우리가 가지고 있는 데이터에 잘 맞을까를 찾는 것이 바로 학습을 한다는 것이라고 할 수 있다.

위 그림에서 H(x)는 우리가 세운 가설이고, 각 직선들은 W와 b에 의해서 결정된다. 이처럼 우리는 우리의 데이터가 이차원 평면에서 일차방정식 H(x) = Wx + b 형태를 따르는 직선이 될 것이라는 가설을 세웠다고 한다.

어떠한 선이 가장 잘 맞는가?

어떤 W와 b값이 더 좋은지를 알아낼 수 있어야 한다. 가장 기본적으로는 어떤 가설이 좋은가를 알려면 실제 데이터와 가설이 나타내는 선 사이의 거리를 측정, 비교하여 거리가 멀면 나쁜 것, 가까우면 좋은 것이라 할 수 있다. 이를 Linear Regression에서는 Cost function이라고 한다.

Cost(or Loss) function

우리가 세운 가설과 실제 데이터가 얼마나 차이를 보이는가를 나타내는 함수. H(x) - y 로 생각할 수 있지만, +가 될수도, -가 될 수도 있기 때문에 보통 Distance를 계산할 때에는 (H(x) - y)^2와 같은 형태로 작성하여 차이를 일정하게 양수로 표현해주고 제곱을 통해 큰 차이는 큰 페널티를 부여하는 중요한 값을 나타내게 된다. 조금 더 formal하게 정리하면 아래와 같다.

여기서, 우리의 가설인 H(x) = Wx + b와 같이 주어진다고 했으므로 이를 cost function에 직접적으로 대입하게 되면 아래와 같이 W와 b의 함수로 만들 수 있다.

여기서 Linear Regression의 숙제는, 가장 작은 결과값을 가지도록 하는 W와 b를 구하도록 하는 것이 Linear Regression의 학습의 목표라고 한다.

블로그를 시작해보려고 합니다.

Sat, 04 Jan 2020 16:01:54 GMT

지금까지는..

사실 블로그라는 개념은 이미 많이 익숙하고, 많은 플랫폼을 경험해보기도 했습니다.
네이버, 티스토리, 워드프레스, 브런치 등등 가입형 블로그나
(최근에는 velopert님께서 만든 velog도 접해보았습니다.)

이미 유명하고 널리 사용되는 Jekyll을 적용한 Github page와 같은
정적 웹사이트 방식 (설치형 블로그) 또한
만들어만 두고 글 한두 개 정도 써보면서 사용해보았습니다.

그럼에도 불구하고 하나를 붙잡고 꾸준히 블로깅을 할 수 없었던 이유는
~~정말 그냥 단순히 귀찮아서~~ 도 있지만
아직 개발에 관심이 없던 시절부터 아무것도 모르는 갓 입문자일때까지는

꾸준하게 블로그를 할만 한 꺼리도 없었고
글을 어떻게 써야 할지도 모르겠어서

와 같은 이유들로 그저 방치되어 버리곤 했던 것 같습니다.

앞으로는!

그러나 이제는 새해를 맞아 자신이 배운 것을 글로 정리하고 작성하는 과정에서 배운 것을
더 견고히 하고,새로운 것을 배우는 동기가 될 것을 믿어 의심치 않기에
귀찮고 어렵고 힘들어도 이 블로그만큼은 꾸준히 만들어 가보려고 합니다.

앞으로 어떠한 주제들로 채워가야 할지,어떤 식으로 글을 써야 할지
그리고 아직 마크다운도 완전히 익숙하지는 않아서 해보면서 감을 잡아야 할 것 같네요 😅

다음 글로는 왜 블로그 플랫폼으로 Gatsby를 선택하게 되었는지,
Gatsby 블로그를 시작하면서 겪은 약간의 삽질과 우여곡절에 대한 내용을 공유해보면 어떨까 하고 생각하고 있습니다.

읽어주셔서 감사합니다 😄

about

Sun, 27 Jan 2019 16:21:13 GMT

Your name

Thank you for reading my resume. If you want to contact me, Please send me an email.

DeveLife

2023년 회고

들어가며

개발자로서 돌아본 2023년

회사 안에서

신규 서비스 오픈

스터디

재택근무

회사 밖에서

사이드 프로젝트

커리어 관리

블로그

올해 목표 점검

내년 목표

마치며

React에서 textarea의 입력 길이를 제한할 때 고려할 점

사건의 발단

새로운 국면

입력 엘리먼트 최대 길이 제한 실험

1. 비제어 <input> 컴포넌트

2. 제어 <input> 컴포넌트 - maxLength

3. 제어 <input> 컴포넌트 - onChange

4. 비제어 <textarea> 컴포넌트

5. 제어 <textarea> 컴포넌트 - maxLength

6. 제어 <textarea> 컴포넌트 - onChange

결론

여담

(번역) 최고의 성능을 위한 Next.js 애플리케이션 아키텍처

개요

1. 네트워크 계층

2. Next 애플리케이션 인스턴스와 SSR

3. 외부 서비스

초기 요청

Next-React 애플리케이션의 API 호출

SSR API 호출

Redux 기반 API 호출

직접, 혹은 캐시된 API 호출

보안 계층의 인증 및 사용

API 계층의 보안

로드 시간 및 SEO

배포 아키텍처

자바스크립트 let 키워드의 스코프와 TDZ

의문의 출발점

콘솔 출력 테스트

Chrome 콘솔

Firefox 콘솔

Safari 콘솔

잠정적 결론

내맘대로 2021년 회고하기

취업

삼성전자 공채 코딩테스트 응시

카카오 신입공채 2차 코딩테스트 응시

현재 재직중인 회사

졸업

독립, 그리고 이사

첫번째 이사

두번째 이사

세번째 이사, 그리고 현재

2021년 총평

2022년에는

about

민윤기 (Anthony)

소개

학업

충남대학교 컴퓨터공학과

업무 경험

N-Tech Service (NTS)

엔트리 신규 프로젝트 개발 (진행중)

상세 설명

엔트리 발견 컨텐츠 기능 런칭 및 리뉴얼

상세설명

엔트리 서스테이닝

상세설명

수동 작업 자동화 스크립트 작성

상세설명

N-Tech Service (NTS)

엔트리 발견 컨텐츠 어드민, 서비스 웹 구현

상세설명

(주) 하얀마인드

COVID-19 알림 챗봇 제작

1. 비제어 `<input>` 컴포넌트

2. 제어 `<input>` 컴포넌트 - maxLength

3. 제어 `<input>` 컴포넌트 - onChange

4. 비제어 `<textarea>` 컴포넌트

5. 제어 `<textarea>` 컴포넌트 - maxLength

6. 제어 `<textarea>` 컴포넌트 - onChange