오늘 한일

- HTTP 웹 서버 구현 리팩토링

• request, respone 관련 클래스들 일부 수정

• GET/POST일때 query를 처리하는 부분 수정중

• 진행 하다 막힌 부분에 대해 포비한테 sos 요청

  1. HttpRequest클래스에 대한 테스트 코드 구현

  2. api에 대해 알게 됨

- 호눅스의 초간단 node.js 알아보기 강의

• 관심이 가서 물어보니 “hello world”만 보여주는 정도로 작업한다해서 참석 안할려다가 ios구역(?)에서 강의를 하여 참석

• node.js는 자바스크립트를 브라우저 밖에서 실행시켜주는 실행기이지 웹프레임워크가 아니다.

• 그러니 당연히 자바스크립트 런타임 실행기지 언어도 아니다.(이 부분 뜨끔했다)

• MEAN(MongoDB + Express + Angular + Node) : 웹 서버 프레임워크

• ngrok 사용

• ejs 템플릿 엔진 사용

오늘 느낀점

• InputStream을 생성자의 매개변수로 받는 클래스가 있어 테스트코드를 짜기 힘들었다. 아니, 해당 클래스는 못짰다. 근데 그게 HttpRequest 클래스이다 보니 테스트 자체가 안돼고 있었다고 보면 된다.(그덕에 TDD도 못했고, 험난한 수동 테스트시간을 보냈다) 진작에 물어볼걸…

• 이전까진 카톡api로 카카오톡 메시지 보내기, 네이버지 지도 정보 api만 api의 예로 내 머리속에 있었다. 그래서 api가 기업에서 자신의 서비스의 기능 일부를 사용할 수 있게 하거나 자신들이 소유한 정보를 이용할 수 있게 제공해주는 무언가라고 생각했다. api란걸 이전까진 기업이 사용자한테 자신의 서비스 정보를 제공 혹은 사용할수 있게 해주는 무언가라고 생각했다.(api에 대해 검색해보면 나오는 사전적인 뜻만 보곤 더더욱 이해가 안되서 저 예를만 더욱 생각하고 있었다)그리고 해당 부분에 대해 필요해지면 그걸 이해할 수 있는 상황이란 거니 필요해졌을때 보자 해서 더 이상 알아보질 않고 있었다.
  오늘 포비한테 다른부분을 질문하다 해당 키워드를 말씀하길래 물어봐서 조금은 알게됐는데 지금 생각해보니 내가 미친놈이였다.

• 개인적으로 api에 대해 포비한테 들으면서 지식적인 면 말고도 얻은게 있는데 코딩을 하다가 고민이 되는 여러가지 중에 파라미터를 무엇으로 둘 것인지, 어떤걸 반환 할 것인지 애매할때가 있었다. 지금까지는 코드를 짤때 나 하나만 염두해 두고 작업을 했었는데 그런 고민이 될때 이 클래스를, 메소드를 사용하는 이용자가 있다고 가정하고 고민하면 좀 더 쉽게 답이 나올 것 같다. 즉, 내가 짠 메소드나 클래스를 내가 이용하는건 크게 어렵지 않다. 거꾸로 내가 다른사람의 코드를 사용하는데 지금 내가 짠 몇몇 부분은 더럽게 쓰기 어렵거나 제약사항이 많을거 같다. 처음부터 그런점을 고려 하면서 만들면 또 설계만 고민하는 무간지옥에 빠질 수도 있으니 이 방식은 여러 선택지에서 고민 될때 적용하자.

• node.js 강의가 진짜 “hello world”만 보여주는 정도의 작업만 했지만 참석 안했으면 후회할뻔 했다. 실습 자체는 그 정도 선에서만 한게 사실이지만(템플릿 엔진도 사용하지만 그것도 간단했다) 실습만이 아닌 이론적인 부분도 알찼다.
  뭐든지 안해본 분야에 대해서는 처음 시작이 가장 어려운 법이다. 나중에 node.js를 공부하게 된다면 오늘 강의 덕분에 가장 어려울수도 있는 첫 시작점은 쉽게 지나 갈 것 같다.
  공부까진 아니고 체험 해보고 싶었던 목록에 있던 django, node.js에 대해선 간단히 체험해봤으니 이젠 React만 해보면 될 것 같다.

• 오늘 같이 어설프게도 아예 잘못 알고 있거나, 존재조차 몰랐던 부분이 마주치게 되면 기초가 너무 부족하다고 느끼게 된다.(그렇다고 좌절까진 안한다. 모르면 알아가면 되니까) 혹은 배웠지만 제대로 숙지 못하는 것들도 많다. 위엔 따로 언급이 없었지만 mapper도 있다. 거기다 내가 인지하지도 못하고 사용하고 있던 것들도 있다. 경험이 짧으니 별수 없는거지만 확실히 이제는 슬슬 채워나가야 할 시기가 된거 같다. 펌웨어 분야를 포기한 이유가 직접적으로 하드웨어(회로)까지 신경쓰지 않고 좀더 순수하게 프로그래밍만 집중하는 분야에서 공부와 일을 하고 싶어서였다. 그 중에서 웹을 선택한 가장 큰 이유는 계속 새로운 것들이 나오고 발전해 간다는 점이였다.
  대학교 신입생때 전공이나 뭐 이런 얘기를 하다 가볍게 물어봤던 넌 뭐가 좋냐는 선배의 질문에 1분쯤 고민하다 나온 대답이 “어떤 분야가 됐던 신기술이 좋은거 같아요. 신기하고 재밌잖아요”라고 대답했던 기억이 있다. 아직도 그걸 기억하는 이유는 전자기기를 좋아해서 전자과를 갔긴 했었는데, 저 질문을 받았을때가 정말 무엇을 좋아하나에 대해 제대로 고민했던 첫 순간이였던거 같다. 그러다보니 IT나 과학 기사(비록 당시엔 전문 기술적으로 보이는 뉴스는 이해가 안돼서 패스했지만..)는 관심있게 쭉 봤다.
  덕분인지 웹(c를 하며 공부한 tcp/ip 윗단 기준으로)과 객체지향에 대해서는 생활코딩 웹앱 강의 빼곤 정말 포비와 처음 시작했는데 그런것 치고는(?) 빠르게 많이 알게된거 같다. 근데 그만큼 배운 부분에 대해서도 구멍도 많고 그냥 모르는게 더 많은거 같고, 아쉽게도 지금쯤 알아야 할 것을 모르는 경우가 있는 것 같다. 웹이 빠르게 발전 해 갔고, 가고 있다는 점이 아직도 나한텐 좋은 점이지만 지금은 단점이기도 하다. 그러고보니 그점이 현재는 내가 새로운것에 관심을 덜 가지는 이유기도 하다. 한 일년쯤 시간이 더있어서 여유롭게 관심 가는 것들 위주로 해보면서 자연스럽게 스팩트럼이 넓혀져 가면서 공부했으면 더 재밌었을거 같다.

• 생활코딩의 몇몇 강의를 코드스쿼드를 오가는 길에 보려고 폰에 넣어 놓고 안보고 있는데 실습이 중심인 강의라 눈으로 보기만 하면 집중도 안되고 머리속에도 들어오지 않아서 그렇다. 오늘은 집가는 길에 포비가 공유해준 REST API 동영상을 봤는데 많은 도움이 됐다. 일단 RESTapi의 REST는 간단히는 인증마크처럼 규제로도 볼수 있는 규약을 다 따른 api를 의미하지만 다 안따르고서도 RESTapi라고 주장 하는 경우도 많다.(그래서 진짜 다 따른 경우 쓸려고 RESTful란 용어도 생긴건가?) 해당 규약이 있는 이유는 과거와 미래에 대한 유연성 때문이고 말이다. 주말에 이와 같이 “웹”과 관련된 지식을 쌓을 수 있는 동영상들(보고, 듣고, 생각 해보는게 중심인)을 좀 찾아 봐야겠다.

• 질문을 하면서 느낀점으론 스스로 고민해서 해결 하고 싶은 욕심이 큰데 어느정도 수준까지만 해야지 적당히 줄여야겠다. 그래서 질문을 잘 안하다 어쩌다 하게되니 처음 생각보다 물어봐야 할게 더 많은 경우가 생긴다. 그러다 보니 제대로 질문 할 준비도 안된 상태의 질문들을 하게 되는 것들은 대체로 횡설수설하게 되는 경우가 있다.
  혼자 해볼려다 알게모르게 질문거리가 쌓여서 그렇게 되는거 같은데 스스로 해보는것도 좋지만 적당히 질문 혹은 조언을 요청하면서 진행하도록 해야겠다.

내일 할일

• HTTP 웹 서버 리팩토링

오늘 한일

- HTTP 웹 서버 구현 리팩토링

• 인터페이스와 Map을 통한 다형성 구현

• 추가 피드백을 받고 일부 수정

• 남은 사항 :

  1. HttpRequest의 첫번째 라인에 대한 클래스 제작

  2. HttpRequest와 관련된 기능 일부 수정

- 포비와 Http 및 현재 진행중인 과제에 대한 질의시간

- 파이썬 장고로 만든 사이트에 소셜 로그인 기능 구현하기

오늘 느낀점

• url에 따른 분기에 대한 리팩토링에 대한 아이디어는 여러가지 있었는데 다 마땅치 않았다. 아침에 포비가 사실상 힌트가 아닌 답을 주셔서 해당 부분은 후딱 구현이 완료 됐다. Map<K,V> 이 참 유용한거 같다. 아직은 Map을 활용하는게 익숙치 않은거 같다. Map이랑 인터페이스를 연결하니 이렇게 쉽게 해결되는데 각각은 떠올렸어도 그 두개를 붙이는건 미처 생각을 못했다. 그나마 가까웠던게 이전에 실습 해 봤던 Map에 BiFunction을 넣는 것이였으니 말이다. 미처 먼저 생각못해서 아쉽지만 Map의 가능성에 대해 제대로 느껴서 좀더 잘 활용 할 수 있을거 같다.

• 리팩토링이 거의 끝나간다. 마지막에 시간이 애매해서 오늘 마무리는 안지었지만 내일 금방 끝나지 않을까 싶다. 근데 HttpResponse를 생성하는 부분이 마음에 안드는데 여러 방법은 떠오르지만 딱히 좋은 아이디어는 안난다. 나머지를 마무리하고 포비하테 조언을 들어 봐야겠다. 아, 내일 일차적으로 작업이 마무리 되면 “HTTP 웹 서버 리팩토링 실습” 파트를 한번 봐야겠다.

• 포비와의 질의 시간을 위해 어제 자료 좀 찾다가 잤는데 그 과정에서 가장 큰 소득은 지금까지 헷갈리던 웹서버와 was의 차이였다. 이전까지의 학습을 통해 was가 무엇을 하는지는 개념적으론 알았지만 웹서버가 무엇인지 제대로 모르니 was와 webserver에 대한 차이점을 알지 못했다. 그런데 최근에 Http 웹서버 구현하기를 하면서 웹서버와 was가 하는 작업들을 일부 직접 구현하니까 그 둘이 무슨일을 하는지 알게 되었다. 그러면서 “아파치 톰캣”이란게 뭔지 궁금해서 찾아 봤는데 덕분에 “아파치 톰캣” 하나에 대해서 알려다가 “아파치”와 “톰캣”에 대해서 알수 있었다.
  질의 시간동안 직접적으로 가장 많이 알게 된건 세션인거 같다. 세션에 대해서 궁금했거나 잘못 알고 있던 부분들을 알게 되었고, 세션에 대해 배우면서도 was나 부하를 어떻게 관리 하는지 등에 대해서도 배우게 되면서 내가 부족하다고 느꼈던 지식들을 채울수 있어서 좋았다. 지식적인 부분에 대해서 학습할땐 내가 어떤 지식이 늘었는지 직접적으로 알수 있기때문인지 구현하는것과는 다른 방식으로 재미를 느낀느거 같다.

• 나도 남한테 알려줄때 바로 답을 알려주기보다는 산파술 방식으로 정답에 도달하게 유도를 하는데, 포비도 그러는 편인거 같다. 생각해보니 1:1로 내가 배우는 입장에서 해당 방식은 처음 겪은거 같다. 왜 상대방이 그냥 정답을 알려달라면서 답답해 했는지 알거 같다. 확실히 해당 방식을 선호하지 않으면 답답하기만 했을거 같다…(죄송한 몇분이 떠오른다)다행히도 나한텐 맞는 편이라서 많은 도움이 된거 같다.(사실 알려주는 사람도 답을 바로 알려주는것보다 훨씬 힘들다)
  개인적으로도 스스로 학습하고자 하는 의지가 있는 사람한테는 해당 방법이 더 많은 도움이 된다고 생각한다.(답을 바로 알려주는건 학습보단 정보전달이 주가 된다고 생각된다. 그래서 경우에 따라선 답을 알려주는게 더 좋은 상황도 있다)여담으로 이방식의 장점 중 하나는 정답으로 유도를 해주긴 했지만 정답을 생각해내서 맞췄을때 기분도 더 좋고 스스로에 대한 자신감도 상승한다는 거다. 개인적으로 가장 큰 장점은 다음에 알려주는 사람이 없는 상황에서도 스스로 생각해서 해결 할수 있는 능력을 길러주는 것이 아닐까 싶다.

• codacy 결과 분석 시간과 피드백을 받기 전까지의 남는 시간을 주말에 실패했던 파이썬&장고 소셜로그인 기능 구현을 잠시 해봤다. 끔찍하게도 localhost라서 제대로 동작이 안했던 거다. 혹시나해서 ec2에 올려봤는데 잘 된다. 호눅스가 영상을 찍을 당시 + 트램이 한달전쯤 노드로 해봤을때까진 가능했는데 어느순간 페이스북 내부적으로 바꼈나 보다.
  사람들이 화이트과정때부터 “오어서, 오어서” 얘기하는걸 보고 당장 중요한 개념은 아닌거 같은데다 흥미도 안가고 해서 해당 키워드만 대강 기억해 두고 있었는데 그게 “allauth” 이건가 싶다. db관련해서 orm이랑 친구인 용어인줄 알았는데 아니였던거 같다. 지식이 +1 되었다. (혹시 지금도 잘못 알고 있는거라면 제보 바랍니다)(내가 들었던 해당 용어는 OAuth였다. allauth는 파이썬의 OAuth관련 라이브러리)

• 아 세션을 배우면서 나온 내용 중 Map<sessionId, name>, Map<name, data> 맵에 맵을 넣지 않고도 두개의 맵이 연결이 되었다. 사실 알고나면 어려울것 없는 방식이다. 하지만 처음으로 그런 발상을 하는건 쉽지 않을텐데 정말 대단한거 같다. 이런 발상들을 보면 신기하다. 충분히 다양하게 응용가능 할것 같으니 해당 방식을 기억해두자.

내일 할일

• HTTP 웹 서버 리팩토링

• 몇가지 개념 정리하는 시간

오늘 한일

- HTTP 웹 서버 구현 리팩토링

• HttpResponse 클래스 제작

• 남은 사항 : 기능이 추가되더라도 if문을 추가하지 않고 다른 코드에 영향을 미치지 않으면서 확장 가능하도록 구현

오늘 느낀점

• HttpResponse 클래스를 구현하면서 두번 동작하게 만들고선 지저분하게 동작해서 너무 깊이 생각하지 않고 일단 간단히 제작 해봤다. 할때 제대로 해볼려는 욕심때문에 여러가지 사항을 고려해서 제작해보려다가 시간만 너무 잡아먹은거 같다. 몇번 경험해봐서 안그럴려고 그러긴 하는데 이번에도 좀 그래버렸다. 해당 부분은 계속 조심해야 겠다.

• HttpResponse를 세번째 구현한게 최종인데 이전 두개는 테스트 코드를 작성 하고 마지막은 테스트 코드없이 그냥 작성해봤는데 지금 TIL을 작성하는 순간에도 웹페이지 상에서 동작은 잘 되는걸 확인 해도 “제대로 동작하는게 맞나??” 테스트 코드가 없으니까 계속 찝찝하다. 솔직히 가슴에 손을 얹고 고백하자면 10월달 부터 몇몇 메소드는 테스트 코드를 어떻게 짜야할지 고민되서 못 짰던 경우는 있었다… 그렇지만 이렇게 한 클래스에 대해서(그것도 중요한) 통으로 테스트 코드를 작성 안해본건 처음이다. 확실히 테스트 코드가 없는 메소드 혹은 클래스에 대해서 신뢰가 안가는게 어떤건지 알것 같다.

• 지금 배우고 있는 과정에 대해 잠시 글을 써볼일이 있었는데 내 자신에 대해서도 생각해볼 시간을 가진거 같다. 근데 글을 잘 쓰는것, 생각을 잘 정리하는 건 쉽지 않은거 같다.

• 솔직히 작업이 늦어지고 있다. 고백도 했으니 정신차리고 후딱하자.

내일 할일

• HTTP 웹 서버 리팩토링 마무리하자

• HTTP에 대해 포비와 질의시간

주말에 한일

- 인프런의 파이썬 웹 프로그래밍 - Django로 웹 서비스 개발하기 강의의 사진 SNS앱 만들기

• 오랜만에 들은거라 일부 세팅에서 에러가 나서 다시 파이썬 가상환경을 맞춰줬다.

• 로그인 및 회원가입 구현

• 사진 업로드 구현

• 소셜로그인(페이스북) 기능 추가, 하지만 아쉽게도 아래의 문제로 실패
  

- 쓰레드 공부

• 쓰레드를 만드는 두가지 방법 :

  1. Runnable을 implement한 클래스를 만든다.

  2. Runnable을 implement한 Thread를 상속 받는 클래스를 만든다.
     (둘다 Runnable의 run()메소드를 구현 해야 한다.)

  3. 기본적으로 ‘Thread-번호’ 형태의 이름을 가진다.

• 쓰레드 풀 : 쓰레드 생성/수거에는 무시못할 자원을 소모한다. 그렇기 때문에 10개 혹은 100개의 정해진 쓰레드를 생성해 놓고 작업 큐에 들어오는 작업들을 쓰레드가 맡아 처리하고 작업이 끝난 쓰레드가 다시 작업큐에서 새로운 작업을 받아와 처리한다.

주말에 느낀점

• HTTP 웹 서버 리팩토링을 마저 하려고 했는데, 주말은 개인적으로 관심 가는 부분이나 보고 싶던 부분을 보기로 했다. 과정을 빨리 하는 측면에서는 주말에도 과정에 집중 하거나, 주중 동안 하던걸 지속적으로 하고 싶기도 했지만 의도적으로 작업에 손을 안댔다. 그 차원에서 이전부터 보다가 멈췄던 파이썬&장고 강의를 보기로 했다.(9월달에 2/3를 수강하고 남겨 뒀던게 계속 마음에 걸렸다) 그리고 내일은 요번주 과정을 진행하면서 개인적으로 신경 쓰이던 쓰레드 부분을 다시 봤다.

• HTTP 웹서버 만들기를 하면서 계속 쓰레드 부분이 신경 쓰였다.

  00:05:59.787 [INFO ] [Thread-357]
  00:05:59.785 [INFO ] [Thread-355]
  00:05:59.787 [DEBUG] [Thread-358]
  00:05:59.787 [INFO ] [Thread-355]

  결국 발견한게 저 부분이였다. 쓰레드 번호가 늘어나기만 한다. 작업이 끝났으면 다시 1부터 사용해도 될거 같은데 자꾸 늘어나기만 했다. 그래서 쓰레드를 다시 찾아보다 9월에 공부하다 봤던 스레드풀도 다시 보면서 그땐 크게 와닿지 않았던 점들이 지금에선 이해되는 좋은 기회가 됐던거 같다.
  해당 내용들을 찾아 보기만 했는데 다른 사람들처럼 정리해보고 싶어졌다. 오늘은 늦었으니 또 너무 늦게 잘거 같으니 별일이 없으면 이따 저녁 8시엔 HTTP 웹서버는 손놓고 정리해서 블로깅 하는 시간을 가져봐야겠다.

• 파이썬&장고를 간단히 보면서 느낀게 확실히 왜 장고를 이용하면 빠른 개발이 가능한지 알수 있는거 같다. 많은걸 장고에서 지원해준다. 그만큼 개발자가 신경쓸부분이 적어진다. 확실히 파이썬도 그렇지만 장고도 나름의 매력이 있는것 같다. 하지만 장고는 지금선에선 해당 강의정도로 간단히 경험을해 보는게 목적인지라 좋은 경험을 하고 있는것 같고 아직은 그 이상의 관심은 안가고 있다. 아! 소셜로그인 기능 구현을 처음 접해봤는데(비록 아직 성공은 못했지만) 일단 한번 경험하고 보니 자바에서도 생각보다 어려울거 없을것 같다.

• 이팩티브 자바의 규칙 세개정도를 보면서 느낀게 있다. 만약 내가 일반적으로 남들 배우듯이 공부를 했으면 지금 해당 규칙들이 뭔소리를 하는지 이해하지 못했을것 같다. 어려운 전공책 읽듯이 글로서만 읽어 갔을거 같다.(아마 암기를 할려고 했을듯 싶다) 예를 들면

  규칙 13. 클래스와 멤버의 접근 권한은 최소화하라
  모듈 사이의 의존성을 낮춰서(decouple), 각자 개별적으로 개발하고, 시험하고, 최적화하고, 이해하고, 변경할 수 있도록 한다는 사실에 기초한다. 그렇게 되면 시스템 개발 속도가 올라가는데, 각각의 모듈을 병렬적으로 개발할 수 있기 때문이다. 유지보수의 부담도 낮아지는데, 모듈 각각을 좀 더 빨리 이해할 수 있을 뿐 아니라 다른 모듈에 영향을 끼칠 걱정 없이 디버깅을 진행할 수 있기 때문이다.

  여기서 언급한 것들을 모두 경험해본 덕에 의존성이 낮춰질때의 장점이 무엇인지 글이 아닌 내 경험을 떠올리며 다시한번 곱씹게 됐다. 포비가 없었다면 지금 저 내용들을 제대로 이해할수 없었을거다. 아직은 많이 부족하다고 느끼지만, 자바를 공부 하는 사람들은 코드스쿼드내 사람들 외엔 본 적이 없어(화이트과정을 마치고 현재 계속 다니고 계신 나머지분들도 저 내용은 아시니까, 비록 저 내용은 크게 어려운 내용은 아니지만) 내가 어느 상태인지, 어느정도인지 가늠이 안돼서 조금은 불안했는데 착실히 잘 알아가는것 같다고 느꼈다.
  (특히 더 그렇게 느꼈던건 9월달에 잠시 몇 규칙을 봤을땐 일정부분은 책을 읽는 느낌이라 잘 안읽혀서 보다 말았었는데 이번엔 확실히 이해되는 느낌이라 내가 성장하고 있다는걸 더 느낀거 같다)

내일 할일

• HTTP 웹 서버 리팩토링

• 자바 쓰레드 좀더 공부해서 정리해서 블로그에 올려보자

오늘 한일

- HTTP 웹 서버 구현 리팩토링

• 위치가 애매한 메소드 위치 변경

• HttpRequest라는 클래스를 만들어 request의 내용들을 관리

• cookie를 관리하는 클래스 생성

• 몇몇 하드코딩된 부분을 enum으로 변경

• 남은 사항 :

  1. response를 관리하는 클래스 만들기

  2. 다양한 요청에 따른 지속적인 if문의 발생을 없게 다른 코드에 영향을 미치지 않게 확장 가능하도록 구현

오늘 느낀점

• request나 response를 관리할 클래스를 만드는건 처음 어느정도 작업을 했을때부터 생각은 했었는데, step by step으로서 차후 작업이 있겠거니 하고서 단순히 현재 직접적(혹은 표면적)으로 언급된 내용들만을 가지고서 작업을 하자는 생각으로 작업을 했었다. 솔직히 생각해보면 너무 따라만하고 있었던게 아닌가 싶다. 스스로가 사고의 확장을 줄이고 있었던게 된거 같은데 지금 생각해보면 안일했던거 같다.
  짧다면 짧은 기간동안(어떻게보면 그렇게 짧지도 않은거 같다) 웹에 대한 공부를 해야한다는 생각에 남들보다 그 기간을 허튼짓을 안하고 배울때 혹은 무언갈 구현할때 내 생각보다는 옳은 틀을 익히고자 그 틀에 맞출려고 한거 같다.(딱히 틀이란 것도 존재하지 않았는데 말이다. 그러다보니 뭐라고 표현도 잘 못하겠다) 그 덕에 불필요한 생각 및 추가적인 생각도 안하게 되다보니 구현속도도 느려지고 뭔가 학습 효율도 떨어졌던거 같다. 내가 주체가 되서 요구사항들을 해결해 나가야하는데 요구사항이 주체가 되서 그 안에 스스로를 가둘려고 한거 같다. 그러다 보니 요구사항에 직접적으로 써진 내용을 최종 명세서 마냥 토씨하나도 벗어나지 않을려고 하는 식으로 주객이 전도 되서 발전이 더뎠던거 같다. 이제는 요구사항에 제시되는 어떤 동작을 해야하는지에 대한 기능적인 측면 정도만 신경쓰고 구현해가는 과정은 내가 생각한 방식에 중점을 둬서 만들어야겠다.
  솔직히 요즘 스스로가 작년만 못하다는 생각이 드는데, 잘못하고 있는걸 발견하고 어느정도 원인이 파악되었으니 그걸 고칠 기회가 생겼다.

내일 할일

• HTTP 웹 서버 리팩토링