동료들과의 스터디를 통하여 어떤 것을 얻을지 고민하고 계시거나, 어떻게 진행하면 좋을지 고민하시는 분들. 혹은 그저 채널팀의 문화가 궁금하신 분들께 재미있는 글이 되리라 생각합니다 :)

https://channel.io/ko/blog/startup-study

한권으로 읽는 컴퓨터 구조와 프로그래밍 책 4장을 읽고 이해하는 시간을 가졌다.

결과

현대적 컴퓨터의 메모리, 입력과 출력, CPU 라는 세 가지 부분을 알아보고 이해할 수 있는 시간을 가졌다. 이후 다음 장에서는 각각의 요소에 대하여 보다 더 구체적으로 공부해 볼 예정이다.

한권으로 읽는 컴퓨터 구조와 프로그래밍의 3장을 읽고 정리한다.

결과

3장에서는 컴퓨터가 시간을 어떻게 인식하게 하는지 알아봤다. 순차 논리, 조합 논리, 메모리 등의 기본적인 하드웨어 요소를 알아봤다.

해당 내용에 대한 정리는 아래 게시글에 정리를 수행했다. https://limm-jk.tistory.com/63

한권으로 읽는 컴퓨터구조와 프로그래밍 2장을 읽고 정리.

결과

2장에서는 비트와 디지털 논리 부품을 조합해서 더 복잡한 장치들을 만들 수 있다는 걸 알려줬다.

3장에서는 이 출력 결과를 기억할 수 있게 해주는 순차 논리, 메모리에 대해서 알려준다고 한다.

이후의 내용도 기대가 된다.

해당 내용을 이어서 정리해서 아래와 같이 게시글로 정리했다.

https://limm-jk.tistory.com/61

https://limm-jk.tistory.com/60

인턴 / YAPP 등 바쁘고 힘들었던 상반기였지만, 많이 성장함을 느낄 수 있었다.

목표

YAPP 프로젝트 배포 후, 추가 기능 개발

YAPP에서 진행한 Studeep의 7.3 런칭 이후, 구현하지 못했던 기능을 2주간 추가 개발하기로 하였다.

결과

이 시간을 통해서 옆에 공부 중인 상태를 공유하는 기능을 추가하고, 여러명이 들어와서 함께 공부할 수 있는 환경을 테스트하였다.

• 오브젝트 1장 읽고 정리하기

요새 지속적으로 개발하면서 크게 느낀 점은 만드는 것도 중요하지만, 옳게 만드는 것이 정말 중요한 부분이라고 느낀다.

이런 점을 보안하기 위하여 TDD등의 책을 읽어보았고, 이번에는 보다 더 코드 자체에 가까운 오브젝트에 도전해보려 한다.

객체에 메세지를 보내는 개념 / 현실 세계를 그대로 녹여내야만 하는 코드 등 쉬운 듯 어려운 개념들을 배우며 성장해나가고 있다고 느껴진다.

YAPP 프로젝트 배포 완료

YAPP에서 진행한 Studeep의 7.3 런칭을 앞두고 최종 개발을 진행하였다. 스터디룸 이용에 정상적으로 진행되지 않는 부분을 해결하는 것에 시간을 많이 소모하였으며, 토이 프로젝트와 유저를 고려한 프로젝트는 다르다는 것을 많이 느낄 수 있던 시간이었다.

Studeep ✨

목표

• Kotlin 기초부터 공부해나가기
• Spring Boot 프로젝트 진행
• Dev-Event OpenSource 기여하기

6회차 모각코 회고

앞으로 수행하게 될 인턴직을 위하여 사용하는 기술 스택인 Kotlin을 공부해보았다. Coroutine등 난해한 내용이 좀 있어서 찾아보다가 인프런에서 강의를 하나 구매하게 되었으며, 방학이 끝나기 전까지 수료하는 것이 목표다.

이외에는 Dev-Event를 모아주는 저장소에서 이 내용을 주 1회 크롤링해서 메일로 보내주는 자동화 툴을 저장소 메인테이너 분들과 협의하여 진행하고 있다. 아마 이번 주 부터 선보일 수 있으리라 생각된다.

목표

• 겨울 캠프 팀 회의
• Spring Boot 프로젝트 진행
• Spring 개념공부 정리
• Alert Mananger 성공하기

5회차 모각코 회고

갑작스레 잡힌 2일 후 기술면접을 위하여 JAVA와 Spring의 개념을 공부하였다. Java 성능의 핵심 기술인 GC를 공부하여 Notion에 정리하고, 질문에 답할 수 있도록 정리해보았다.

또한 10시에 팀 회의가 있어, 팀회의에 참가해 최종발표영상의 흐름을 논의하고 Alert Manager의 Slack연동에 대하여 회의를 진행하였다.

목표

• 겨울 캠프 배포 공부
• Spring Boot 프로젝트 진행

4주차 모각코 회고

Spring Boot를 이용한 프로젝트의 수행을 위하여, Spring Boot의 Annotation 개념을 공부했다. 또한 ORM을 위한 JPA를 추가적으로 공부하여 프로젝트에 필요한 모델들을 JPA를 이용하여 구축하였다. 배포는 나중에 함께 진행해야 할 것 같다.

목표

• YOLO 저장소 분석
• Spring Boot 프로젝트 진행

3주차 모각코 회고

YOLO v5 저장소를 분석하면서 Layer를 어떻게 쌓았는 지, 이를 어떤 식으로 경량화 시켰는 지를 공부할 수 있었다.
이를 이번 겨울 캠프 프로젝트에 적용하려 하는데, 재미있을 것 같다. yolo 저장소

Spring은 하지 못했다. 내일이나 주말에 마저 공부해야 할 듯 싶다.

20.06.06 충남대학교 컴퓨터공학과 SW사업단에서 주최한 클라우드 및 도커 특강 1주차 클라우드 및 도커 기초 수업의 정리입니다. 9시간이나 들였는데, 확실히 제 것으로 만들어야죠!

1. 도커란 무엇인가?

도커는 위와 같은 로고를 가지고 있어요. 컨테이너를 싣고 있는 고래의 로고, 그리고 항만 노동자라는 의미의 Docker. 뭔가 감이 오시나요?? '컨테이너를 싣고 내리는 동작을 하는 프로그램이겠구나..' 라는 생각이 드신다면 정답입니다! 컨테이너가 무엇이냐의 문제일 뿐이죠. 컨테이너를 통해 가상화를 수행한다는 점만 아시면 퍼펙트하겠네요. 그렇다면 다른 이야기보다 가상화에 대한 이야기를 먼저 하고 도커 이야기로 다시 와볼게요!

2. 가상화

가상화는 소프트웨어 기반, 즉 가상으로 애플리케이션, 서버, 스토리지, 네트워크와 같은 어떤 사물을 표현하기 위한 과정으로서, 모든 규모의 비즈니스에서 IT 비용을 절감하면서 효율성과 대응력을 높일 수 있는 효과적인 방법이에요. 너무 어렵다구요?? 그냥 하나의 하드웨어에서 리소스를 나누어서 여러개의 하드웨어로 수행할 작업을 하나의 하드웨어에서 하도록 도와주는 프로그램이라 생각하시면 편해요.

가상화의 등장 배경을 간단히 알아볼게요

x86 서버의 한계로 인해 많은 IT 조직이 오늘날의 높은 스토리지 및 처리 요구를 충족하는 데 필요한 용량을 운영하기 위해서는 용량의 일부분만 활용하는 서버를 여러 대 구축해야 하며, 그 결과 엄청난 비효율성과 과도한 운영 비용이 발생하게 되었습니다.

여기에 가상화가 도입되면 소프트웨어로 하드웨어 기능을 시뮬레이션하여 가상 컴퓨터 시스템을 생성하며, 이를 통해 IT 조직은 하나의 서버에서 둘 이상의 가상 시스템과 다수의 운영 체제 및 애플리케이션을 실행할 수 있게 됩니다. 이에 따라 규모의 경제성, 높은 효율성과 같은 이점을 누릴 수 있습니다.

그래서 이러한 가상화를 수행하기 위해서 가상머신(VM)이 등장해요. 가상화를 도와주는 Tool인데, 이건 정말로 컴퓨터 안의 컴퓨터라고 부를만 해요. 모 수업의 실습은 한 컴퓨터에 윈도우를 세개씩 돌리고 있으니...ㅠㅠ 이러한 가상머신은 주로 VirtualBox, VMware 등등이 사용되어 왔어요.

3. 도커의 등장

컴퓨터 안의 컴퓨터, 앞서 말했던 가상머신들은 OS전체를 가상화시켜서 진짜 또 하나의 컴퓨터처럼 사용했어요. 전가상화라고 불리는 방식이죠. 하지만 위의 방법은 큰 단점이 존재했어요. OS를 두개 돌린다고 생각하면 바로 드는 생각!

'와 정말 무거운 프로그램이다....'

그렇지 않나요? 간단히, OS를 쓰기 위해 OS전체를 사용해버리자! 라는 생각이죠. 정말 간단하지만, 느리고 무겁다는 큰 단점이 존재했어요. 이러한 문제를 해결하기 위해 반가상화라는 방법이 고안되었는데요, 이 방법은 Guest OS가 필요는 하나, OS전체를 가상화시키지 않는 방법이죠. 가상화시키는 크기가 줄어드니 가벼워짐은 말할 필요도 없구요.

하지만, OS를 설치해서 사용하는 이상, 성능의 문제는 해결되지 않았습니다. 전가상화든 반가상화든 추가적인 OS를 설치하여 가상화하는 방법은 어쨌거나 성능문제가 있었고 이를 개선하기 위해 프로세스를 격리하는 방식이 등장합니다. 리눅스에서는 이 방식을 리눅스 컨테이너(LXC) 라고 합니다. 단순히 프로세스를 격리시키기 때문에 가볍고 빠르게 동작하며, CPU나 메모리는 딱 프로세스가 필요한 만큼만 추가로 사용하기에 성능적으로도 거의 손실이 없습니다. 이 방식이 도커의 기초가 되죠. 이러한 가벼운 가상화기술의 수요에 인하여 도커가 등장하고 성장하게 됩니다.

4. 컨테이너

앞에서 도커가 어떤 느낌의 프로그램이라고 했죠??

'컨테이너를 싣고 내리는 동작을 하는 프로그램이겠구나..'

이제 여기서 컨테이너가 무엇을 의미하는지, 아시겠죠?? 위에서 말했던 프로세스를 격리하는 방식인 리눅스 컨테이너를 의미해요. 이해를 돕기 위해 위의 사진을 한번 더 볼게요. 양 측의 차이를 보면 오른쪽이 확 줄어들었죠??

컨테이너는 Application 실행에 필요한 바이너리만 남겨서 도커 엔진 위에 올려둔 형태랍니다.

5. 이미지

도커를 사용하다보면 또 이미지라는 개념이 있어요. 컨테이너랑 굉장히 헷갈리게 하는데 간단히 알아볼게요.

이미지 : 컨테이너 실행에 필요한 파일과 설정값등을 포함하고 있는 것

그래서 상태값을 가지지 않고 변하지 않아요. 컨테이너가 되기 이전의 상태인 것이죠. 컨테이너는 이미지를 실행한 상태라고 볼 수 있구요. 그래서 하나의 이미지에서 여러 개의 컨테이너가 만들어질 수 있고, 컨테이너 내부에서는 많은 변화가 일어나도, 이미지에는 아무런 변화가 일어나지 않죠.

정리하면, 이미지는 컨테이너를 위한 모든 정보를 들고 있고, 변하지 않는 특성을 가지고 있는거죠. 컨테이너 이전의 단계.

6. 장점 정리

• 빠르고 가벼운 가상화 솔루션

  호스트의 운영체제를 공유해 필요한 최소한의 리소스만 할당받아 동작하는 방식이에요.

  단일 호스트에서 다중 워크로드를 구동할 수 있기 때문에 하이퍼바이저 기반 가상화솔루션에 비해 훨씬 더 가볍게 가상화 환경을 구성할 수 있습니다.

• 개발자에게 자유로운 개발보장

  개발 언어나 툴에 상관없이 어떠한 애플리케이션이라도 만들 수 있으며, Docker에서 만들어진 애플리케이션은 이동성이 좋아지고 어디서나 실행될 수 있어요. DockerHub를 통해서 공유도 굉장히 편하구요.

• 뛰어난 보안성

  서비스가 해킹되더라도 격리되어있어 원래의 서버에 영향을 미치지 않는 구조로 되어있습니다.

• 협업의 이점 다른 가상화 툴을 이용하여 협업해보신 분들은 체감하시리라 생각합니다. 버전 맞추는 것이 얼마나 성가신 작업인지...

  하지만, 도커를 이용하면, 한 사람이 만들어서 DockerHub에 올려두면 협업자들 모두가 동일하게 이용할 수 있어요. 다른 고수분들이 만들어 둔 이미지를 찾아볼 수도 있겠네요.

7. 마무리

사실 Docker를 처음 써본 것은 큰 이유는 아니고, pipenv가 너무 짜증나는 것이 이유였습니다. 버전을 공유하기도 불편.. 하나하나 설치하기도 불편.. 특히 파이썬 버전이 다르면 파이썬 재설치하고,,,

이런 하찮은 이유들을 도커는 말끔히 정리해주었습니다. 정말 고마운 친구네요.

다음 시간에는 도커를 실전에 사용하는 방법을 알아보려고 합니다! 함께 가보아요!

백엔드 개발자로서의 덕목은 많고도 많지만, 이 중에 보안을 빼두고는 설명할 수 없을 것입니다. 어떠한 웹 사이트를 해도 보안은 정말 중요합니다. 이 중, 오늘은 보다 재미있었던 로그인 보안을 먼저 다루어 보겠습니다.

1. 시작하기

먼저 Security를 사용하기 위하여 pom.xml에 의존성을 추가해주어야 합니다.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security</artifactId>
</dependency>

이렇게 말이죠! 그럼 우선 사용할 준비는 끝났습니다.

먼저 security로 사용할 class를 만들어줍니다. SecurityConfig라고 만들어주세요.

다음은 class에 @EnableWebSecurity를 붙여주세요. 이렇게 된다면 현 상황에서는 모든 페이지를 로그인 이후에 들어갈 수 있게 된답니다. 하지만, 이렇게 된다면 결론적으로는 좋겠지만, 테스트하는 동안은 너무 불편하겠죠?? 게다가 아직 로그인 세션도 안 만들었는데....

그래서 아래와 같이 configure 메소드를 override받아서 만들어줍니다. 위 사진 중에서 아래 authorizeRequests메소드와 antMatchers메소드를 확인하시면 되는데, 먼저 authorizeRequests는 '앞으로 시큐리티를 ~~하게 처리하겠다' 라고 생각하시면 됩니다. 그리고 그 아래의 antMatchers는 이 시큐리티를 지정할 특정 경로를 지정합니다.

결론적으로 저 의미는 localhost:8080/, /user/, /follow/, /image/의 직접 접근을 제한하겠다라는 뜻입니다. 그리하여 다른 컨트롤러의 요청은 로그인 이후에 허락되며, 테스트컨트롤러에서의 /test/형식의 요청만이 직접 접속이 가능합니다. 물론 완성이후에는 제거해야만 할 것 같습니다. 백도어의 밥이 되겠네요.

0. 결론부터 보자!

웹 소켓이란 효율적인 Server와 Client 간의 통신을 위하여 개발된 구조입니다. 웹 소켓의 API를 확인해보면 굉장히 간단한 구조로 되어있는데, 이런 구조를 통해서 하나의 http접속으로 원활한 통신이 가능하죠. 이전에 쓰던 HTTP 규약의 하나의 정보는 하나의 URL을 호출해야하거나, Client의 요청 없이는 정보를 반환할 수 없는 Ajax와는 다르죠.

1. Web Socket 등장의 배경 1 - HTTP

웹소켓을 설명하기 이전에 HTTP와 AJAX부터 간단히 차근차근 밟아나가려 합니다.

HTTP 이전의 통신은 정말 전문가 말고는 어려운 체계였습니다.
FTP, NNTP등의 프로토콜들이 사용되었는데, 사용이 전문가 말고는 정말 어려우며, 터미널 위에서만 통신이 가능한 정도의 퍼포먼스였습니다. 하지만, 1989년 팀 버너스리와 CERN은 Server와 Client간의 일련의 흐름을 하나의 약속으로 지정해둔 프로토콜, HTTP를 만들어냅니다! (코드 자체의 관계는 없는 내용이지만, 이런 곳에서 연락을 한다니, 끔찍하지 않나요?)

HyperText Transfer Protocol, 즉 HTTP의 출현은 굉장한 변화를 가져왔습니다. 위와 같이 터미널을 통하여 하얀 글만 보던 통신에서, 사진을 직접 받아보고, 방대한 양의 통신이 가능해진 것이죠. HTTP 통신과정은 다음과 같습니다. Client가 어떠한 정보를 요청하면, Server는 그런 정보를 처리해서 HTML화 시킨 후, 응답하는 것이죠. 하지만, 이 방법은 큰 문제점이 하나 있었어요. 위의 초록색 화살표를 확인해보면, 결과를 보기위해서 무조건 페이지 이동이 필요함을 알 수 있습니다. 무엇을 하던 새로운 창으로 확인해야한다는 것은 굉장히 불편한 일이 아닐 수가 없지요. 그래서 어떠한 결과를 봐야할 때 팝업을 많이 이용했습니다. 하지만, 이젠 그런 것도 옛날 이야기! 구글이 자신의 서비스에 빛을 받지 못하던 한 기술에 힘을 실어주는데요, 이 기술이 바로 AJAX! 답답하던 HTTP를 약간 우회(?)할 수 있는 멋진 기술이죠.

2. Web Socket 등장의 배경 2 - AJAX

Asynchronous Javascript And Xml, AJAX는 JavaScript의 라이브러리 중 하나입니다. 직역해보면 비동기적인 자바스크립트와 XML?이네요. 적당히 양념을 해서 정의해보자면, XMLHttpRequest 객체를 이용하여 전체 페이지를 불러오지 않고 부분만 불러오는 JavaScript를 사용한 비동기 통신 정도가 되겠네요. 조금 더 알아보겠습니다~

AJAX의 도입으로 많은 것들이 향상되었는데, 특히 AJAX의 특성인 비동기 방식으로 인하여 많이 바뀌었습니다. 자세한 설명 이전에 비동기 방식에 대하여 간단히 정리해 볼게요.

비동기 방식은 웹페이지를 리로드하지 않고 데이터를 불러오는 방식입니다. 이 방식의 장점은 페이지 리로드의 경우 전체 리소스를 다시 불러와야하는데 이미지, 스크립트 , 기타 코드등을 모두 재요청할 경우 불필요한 리소스 낭비가 발생하게 되지만 비동기식 방식을 이용할 경우 필요한 부분만 불러와 사용할 수 있으므로 큰 이익을 볼 수 있습니다.

위의 사진과 같이 빙 돌아가야 할 업무를 깔끔하게 처리할 수 있는 것이죠.

비동기 방식이라는 큰 특징을 가진 AJAX를 채택함으로서 얻는 이점을 두가지로 나누어서 설명해 볼 수 있을 것 같아요.

• 첫째! 부분적으로 변화시킬 수 있음. 서버에 요청을 할 때 언제나 모든 페이지의 변화를 요구하지는 않을 거에요. 예를 들어서 게시판 리스트를 접고 늘릴 때, 꼭 모든 페이지의 변화가 필요하지는 않잖아요. AJAX는 이러한 일이 가능합니다. AJAX는 html 페이지 전체가 아닌 일부분만 갱신할 수 있도록 XML HttpRequest객체를 통해 서버에 request를 합니다. 이 경우 Json이나 XML형태로 필요한 데이터만 받아 갱신하기 때문에 그만큼의 자원과 시간을 아낄 수 있습니다. 한국에서 빠른 인터넷 속도는 덕목이라 할 수 있죠. 속도 하나만 생각해도 정말 큰 장점이라 할 수 있습니다.

• 둘째! 변경사항이 발생할 때 마다 페이지를 이동할 필요가 없음 옛날에 회원가입 할 때, 아이디 유효성 검사를 위해서 굳이 팝업을 띄워서 하셨던 기억이 다들 있으시리라 생각합니다. 그 때는 어쩔 수 없는 것이었죠. Response시에 무조건 페이지를 이동해야 하는데, 회원가입 중에 그러기는 쉽지 않은 일이니까요. 하지만 이제는 그런 것? 필요 없습니다! AJAX를 이용하면 그냥 ID를 쓰면 바로 그 창에서 유효검사를 해줍니다. 정-말 편해진거죠!!

이런 식으로 통신이 이루어지기에, 부분적으로 변경이 가능한 것입니다. 열심히 그려봤는데.. 이해에 도움이 1이라도 되었을 지 모르겠네요...ㅎ...

하지만 언제나 부족한 점은 있는 법! AJAX는 부분적인 변화의 가능으로 인한 Client의 요청에 페이지 이동이 없이 응답이 가능했습니다. 하지만, Client의 요청 없이도 응답을 받아야 하는 상황이 존재합니다. 예를 들어서 저희의 휴대폰의 push메세지 같은 경우에 웹에서 언제나 오는 것을 대기하고 있지는 않으리라 생각합니다. 또한 웹 상에서 채팅방을 운영한다면, 상대방이 들어오고, 채팅을 날리는 것을 Client의 요청을 받을 때만 응답해준다니, 정말 불편하지 않으신가요??

그런 불편함을 HTML5과 함께 등장한 WebSocket이 해결해줍니다.

이 메인 이야기에 관하여는 2편에서 뵙겠습니다~

1. 20.03.29 start!

들어가기 전에 30일 간 절대 어뷰징(날짜를 바꾸는 등)은 없었으며, 앞으로도 연속 커밋이 깨지는 한이 있더라도 어뷰징을 하지 않을 것입니다.

30일이라는 시간이 적으니까 굉장히 짧아보이는데 개인적으로 아직 30일 밖에 안되었나 싶네요..ㅎㅎ 일일커밋의 시작은 Co-Duck의 일일커밋 스티커를 한번 얻어보고 싶었을 뿐이었습니다. 하지만 Commit은 매일 했지만 push는 매일 하지 않았기 때문에...ㅠㅠ

일일커밋의 최대 장점은 공부가 너~무 하기 싫어도 지금까지 한게 아까워서 노트북을 켜게 만든다는게 큰 장점이었네요 ㅋㅋㅋㅋㅋ

2. 배운 점

2-1. Spring Boot

Java의 개발 과정의 재미와 Django의 쉬운 결과의 즐거움을 합친 듯한 Spring boot. 물론 화나게 할 때가 더 많은 것 같지만 뭐.. 재밌으니까 계속 하고 있는 것 아닐까요? 일일 커밋을 시작하며 그 근처에 함께 시작한 친구인 만큼 내 일일커밋의 온전한 성과라고 봐도 되리라! ...ㅎㅎㅎ 그런가... 시작할 때 어노테이션이 뭐죠..? 하고 Spring MVC가 어찌 동작하는 지 1도 몰랐던 이전과 비교하면 많~이 발전했다! 하지만 웹의 세계는 너무 방대하고 난 아직 기초인걸...ㅠㅠ

2-2. Algorithm

2학년의 전공과목으로 배우며 BFS가 뭐고 DFS가 뭐야..? 하면서 그냥 따라 쓰기만 했던 알고리즘을 드디어 다시 뜯어보기 시작했다! 전공으로 할 때는 정말 이게 쓰일까..? 싶고 했던 아이디어들이, 다시 공부해보니 그저 굉장한 아이디어임을 느낀다. 하면서 전공과목들의 중요성을 다시 크게 느꼈으나, 적용은 안되고 있는 실태... 반성합니다. 일일커밋을 통하여 머리에서 빙글빙글 떠돌던 알고리즘 지식들이 조금 정리되었다. 문제에 완벽히 응용함은 아직 시간이 많이 필요해보이나, 원래 진리에 도달하는 것이 어려운 것 아니겠어요~? ㅎㅎㅎㅎ 그리고 나의 경쟁심을 불러일으키는 solved.ac. 휴.. 내가 문제 수가 적을 때는 그럴 수 있다 생각했는데, 실버는 용서할 수 없다 이 말입니다!! 곧 골드달고 골드 회고를 올리겠습니다!

2-3. Crawling

진짜 정말 재밌다. 진짜루 적은 노력에 비하여 큰 결과를 볼 수 있어서 정말 즐겁게 행했던 작업이었다. 물론 간단한 것만 자세히 설명되어있고 응용이 안보여서 내 취침시간을 갉아먹는 주범이 되어버렸으나... 재밌잖아! 그거면 된거야! 지금은 Selenium과 Bs4를 사용하는 Crawling들을 하고 있지만, 앞으로는 Jsoup를 이용하여 내가 공부하는 Spring Boot와 연계해보고 싶다. 파이썬은,,, 연동하기가 힘들잖아...

3. 보완할 점

3-1. Commit을 위한 공부?

물론 어떤 식으로든 공부를 한다는 것은 좋겠으나, Commit이 주체가 되면 안되겠다는 생각이 들었습니다. 능동적으로 자기개발을 익히는 개발자가 좋은 개발자가 될 수 있겠죠?? 노력하겠습니다.

3-2. 과제가 밀린다...

위의 알고리즘 티어 올리는 재미나, Spring Boot의 재미가 너무 커서, 다른 공부가 뒷전이 되는 듯한 느낌이 있다. 과제가 밀린다는 것은, 그만큼 전공공부에 신경을 덜 쓴다는 뜻이 아닐까..? 신경을 덜 쓰고 있음은 나도 느끼고 있는 것 같다. 이건 정말 조심해야겠다.

3-3. 이론이 뒷전

Commit이라는 결과를 내보려고 이론적인 공부가 뒷전이 되가는 것 같다. 당장 Spring이 그런데, 지금 Spring Boot의 기능이 어찌 Spring을 간편하게 만들어 주었는지 물어보면 얼마나 답할 수 있을까. 학문을 할 때 가장 위험한게 결과를 위한 공부라고 했는데...

4. 결론

그저 아직 많이 부족한 주니어 개발자. 자만하지 않고 꾸준히 해나감이 중요함을 이번 회고를 통하여 다시 한번 느낍니다. 다음 회고에는 이번 보완할 점이 없었으면 좋겠네요! 그럼 코딩하러 갑니다~

우리가 이러한 작업을 처리해주기 위하여 어떻게 해야 할 지 생각할 때 우리는 두가지 HTTP Method를 생각하게 됩니다.

바로 GET방식과 POST방식.

공부하며 이 두가지가 어떠한 차이 점이 존재하는 지 혼동이 왔고, 이번 기회에 각 방식의 장,단점과 차이점을 알아보며 깔끔하게 정리해보려 합니다.

1. GET

눈에 보이게 구분할 수 있는 방식이 하나 있습니다. URL. GET방식은 URL에 정보를 포함시켜서 보내는 방식입니다. 이러한 속성에 따라 도출되는 특징을 정리해보겠습니다.

• URL에 데이터를 붙여서 전송한다.
• URL에 데이터가 부착되어 있으므로 보안에 취약하다.
• 위와 같은 이유로 공유성이 뛰어나다.(같은 URL을 가진 사람은 같은 화면을 볼 수 있음.)
• 전송하는 길이에 제한이 있다.
• 캐싱에 용이하다.

GET방식은 URL에 정보를 붙여서 간단히 전송할 수 있게 합니다. 이에 따라 URL에 모든 정보가 포함되어 있으며, 같은 URL을 가진 사람은 같은 결과를 볼 수 있게 합니다. 또한 URL을 이용하는 형식이므로, 포함할 수 있는 정보에 제한이 있습니다. 또한, URL에 들어갈 형식에 맞지 않는 값은 모종의 처리를 해준 후에 투입해주어야 합니다. 변수의 값을 제외하면 전송하는 데이터가 없으므로 보통 body가 비어있습니다.

URL을 통해 동일하게 접근할 수 있다는 것은 장단점이 있는 것 같습니다. URL에 필요한 정보가 모두 있으므로 캐싱을 통하여 편리하게 사용할 수 있습니다. 예를 들면 이 URL을 저장하여 이 상태로 바로 접근할 수 있을 것입니다. 하지만, 중요한 정보를 보내야 할 경우에, 누구나 볼 수 있는 URL에 보내기는 부담스러운 면이 있을 것입니다.

2. POST

POST방식은 서류를 제출한다고 생각하면 편합니다. 서류봉투에 들어간 서류를 받으면, 직접적으로는 정보를 확인할 수 없습니다. 밀봉을 해제하는 작업 후에 볼 수 있겠지요. 이런 방식으로 POST방식은 Body에 정보를 넣어서 보내는 방식입니다. POST방식도 특성을 한번 정리해보도록 하겠습니다.

• URL에 데이터를 노출하지 않고 전송한다.
• Body에 데이터를 넣어서 전송한다.
• 직접적으로 데이터의 확인이 불가능하여 간단한 보안이 보장된다.
• 캐싱이 불가능하다.
• 전송하는 길이의 제한이 없다.

위에서 설명한 GET방식과는 다르게 POST방식은 Body에 넣어서 전송하므로, 길이의 제한이 없다는 큰 이점이 존재합니다. 허나, 무제한으로 늘릴 수는 없는데, 왜냐하면 서버에는 요청을 받는 시간의 제한이 존재하는데, 이 시간 내에 모두 호출이 이루어져야 하기 때문입니다. 또한, Body의 Parameter로 전송이 이루어지기 때문에 URL로 전송이 까다로웠던 정보까지 전송할 수 있다는 장점이 있습니다.

크롤링은 인터넷 상에 있는 수많은 자료들을 가져와 프로그래밍하기 쉽게, 혹은 데이터 분석하기 쉬운 형태로 가공하는 작업을 의미합니다. 예를 들어서 공지를 자주 확인해야 한다면, 크롤링을 통하여 한번에 다양한 공지들을 한번에 확인할 수 있습니다. 크롤링의 방법은 여러 방법들이 있겠지만, 파이썬을 이용한 크롤링을 해보려 합니다.

1. 어떤 라이브러리 / 프레임워크를 사용하나요??

아는 방법은 두 가지가 있습니다.

• request와 beautifulSoup 이용
• Selenium과 WebDriver 이용

이 두 방안 중 오늘은 request와 beautifulSoup를 이용하는 방안을 이야기 해보려 합니다.

위의 requests와 beautifulSoup는

pip install request
pip install beautifulsoup4

위와 같은 명령어로 설치해주시면 됩니다. pip가 설치되지 않았다면, pip부터 설치해주셔야 합니다.

2. requests

requests는 HTTP요청을 보내는 모듈입니다. 간결한 코드로 HTTP요청을 보낼 수 있기에 많이 쓰입니다.

import requests

위와 같이 라이브러리를 먼저 import시켜주고 시작합니다.

최초에 url에 따른 객체를 만들어 주어야 합니다.

response = requests.get(url)

url을 객체화 시켜서 response라는 변수에 저장하였습니다. 그 다음은, 탐색하기 위해 웹의 소스코드를 추출해야 합니다. 소스코드는 크롬에서 ctrl+U로 접근이 가능합니다.

html = response.text

html을 출력하는 방식으로 콘솔 창에서 소스코드를 볼 수 있겠지만, 그냥 크롬에서 위의 방식으로 체크하시는 것을 추천드립니다.

이제 이 소스코드를 필요에 맞게 조작,탐색해야합니다. 지금부터 필요한 것이 위에서 말했던 beautifulsoup4입니다.

3. BeautifulSoup

beautifulsoup는 HTML 파싱 라이브러리로서, 몇 개의 메소드만으로 손쉽게 추출이 가능합니다.

from bs4 import BeautifulSoup

최상단에 BeautifulSoup를 위와 같은 코드로 import해줍니다.

HTML추출 이후부터 다시 진행해보겠습니다. 입력받은 소스코드를 파이썬에 맞게 파이썬 객체로 변환하여야 합니다.

soup = BeautifulSoup(html, 'html.parser')

위의 코드를 통해 추출한 url의 소스코드가 파이썬 객체로 저장되었습니다. 이제 이 soup를 통해 필요한 값을 찾아가는 일만 남았습니다.

찾기 전에 내가 필요한 값이 a태그 내부에 있음을 알기에 select를 통해 a태그의 값만 빼내주겠습니다.

links = soup.select('a')

이 코드를 조금 응용하면 select함수의 인자로 들어가는 자리에 'a > div'라고 사용한다면, a태그 내부의 div태그 내부의 소스를 저장해줍니다.

..2에서 계속

람다식(Lambda Expression)은 def같이 함수를 선언하지 않고 임시로 사용할 수 있도록 간단히 선언한 함수를 의미합니다. 다른 함수의 인수로 넣을 때, 간편하게 작성할 수 있어 주로 사용됩니다. 선언 없이 사용하며 재사용이 불가능하기 때문에 익명함수라고도 불립니다.

• 람다식의 장점

1. 코드를 간결히 만들 수 있습니다.
2. 간결해지므로 가독성이 향상됩니다.
3. 함수를 따로 만들 필요가 없으므로 개발 시간이 단축됩니다.
4. 병렬프로그래밍에 용이합니다.

• 람다식의 단점

1. 람다식으로 만든 함수는 재사용이 불가능합니다.
2. 이로 인하여 같은 함수를 중복 생성하여 비 효율적인 코드를 만들 확률이 높아집니다.
3. 디버깅이 까다로운 것 같습니다.

   1. 기본 사용법

   람다식은 이렇게 사용할 수 있습니다.

   lambda x : x + 10

   허나 이렇게 사용하면 함수를 호출하는 것이 되므로 값을 얻을 수 없을 것입니다. 이대로 실행해봤더니 함수 객체가 출력되었습니다. 그렇다면 어떻게 써야할까요??

   function = lambda x : x + 10
   function(1)

   이렇게 사용하면 1에 10을 더한 11을 반환받을 수 있습니다. 위의 그림은 람다식을 변수에 할당하여 사용한 모습입니다.

허나, 익명함수인데 뭔가 더 간단하게 써야할 것 같지 않나요?? 그래서 변수에 할당 없이 아래와 같이도 사용이 가능합니다.

(lambda x : x + 10) (1)

이것도 똑같이 11이라는 출력을 받을 수 있습니다.

2. 응용

변수 하나만이 아닌 두개도 가능합니다.

(lambda x, y : x + y) (10, 20)

이렇게 사용하면 30을 반환받을 수 있습니다.

다음은 다른 함수와 사용해볼까요?? 입력받을 때 많이 쓰는 map()함수를 이용해보겠습니다.

• map함수 응용 map함수는 map(함수,리스트)로 사용되는데 이 함수 자리에 람다식을 사용하여 표현해보겠습니다. 배열 arr이 존재한다고 가정하고, 이 배열을 모두 어떠한 값 N으로 나누려면 저희는 for문을 이용해서 많이들 접근하리라 생각합니다. 이때 map함수를 이용하여 아래와 같이 표현하면, 간단한 식으로 표현할 수 있습니다.

  list(map(lambda x : x/N, arr))

  이렇게 표현하면 arr를 모두 N으로 나눈 값을 다시 리스트에 담을 수 있습니다.

다음은 이번에 공부하면서 새로배운 reduce함수를 이용하여 응용해보겠습니다.

• reduce함수 응용 reduce함수는 reduce(함수,리스트)로 이용됩니다. 이렇게 사용하면, 이전 연산에 누적해서 함수연산을 하는데요, 예를 들면, 함수가 x+y이고 리스트가 1,2,3,4,5,6이라면, 1+2=3 다음에 3+3=6 6+4 = 10 ... 이런 식으로 이전 연산의 결과와 재연산을 한답니다. 문자열에도 사용이 가능합니다. 람다식이 적용된 식에서 예시를 볼까요??

  reduce(lambda x,y : y+x, arr)

  그럴듯한 결과를 보고 싶어서 람다식을 y+x로 해두었습니다. 무슨 차이가 있냐구요?? 차이는 문자열일때 발생합니다. arr가 a,b,c,d,e의 문자열이라고 가정하면 위 식의 결과는 b에 a를 붙여서 ba -> c에 ba를 붙여서 cba ... 결과적으로 edcba가 반환됩니다. 신기하네요.

3. 결론

람다식은 함수를 매개로 받는 함수 내에서 굉장히 유용하게 쓰이는 것 같습니다! 잘 활용하면 간소화 시킬 수 있는 식이 많을 것 같네요. 최근 람다식의 활용이 각광받는 만큼 의식적으로 사용해보고, 어디에서의 활용이 효율적이고 어디에서 비효율적인지 몸에 익혀야 할 것 같습니다.

감사합니다!

03.31 - 04.02 ... jsp연동 드디어 성공! 문제는 의존성 추가 이후 clean을 안해줘서 그런 듯 하다.. jsp폴더의 파일 위치는 리소스 내부가 아닌 메인 하위에! 의존성 추가 이후에는 아래 코드로 clean후 dependency를 설치할 것!

./mvnw clean

실행은 run쓰지말고

./mvnw spring-boot:run

사용하자!!

2. 후기

Run 말고 명령어 씁시다... 오류 해결해서 행복합니다.

3. 내일 목표

내일은 DB를 열심히 하고 만들어 낸 DB를 Spring과 연동해보자!