웹 서비스에 대하여..

나는 크롬이고, 서버는 고양이다

그렇다. 나는 크롬이고, 서버는 사실 고양이였다.
내가 크롬이라니? 서버가 고양이라니? 이게 무슨 소리일까?

오늘은 app.py 를 통한 호스팅에 대해 알아보도록 하자.

일단 내가 고양이의 엉덩이를 톡톡톡톡 두들겨주면 그릉그릉하며 나에게 애교를 부린다.
그러니까, 내가 고양이에게 톡톡톡톡하며 요청을 하면 고양이는 그릉그릉하며 응답을 한다!
서버도 이와 똑같다!! 이 예시를 생각하며 글을 계속 읽어보도록 하자.

보통 우리가 서버와 상호작용을 할 때 client와 server 로 나누어진다.

이를 좀 더 알기 쉽게 설명을 하자면 아래와 같다.

나 + 내가 쓰는 브라우저 -> client
컴퓨터 -> server

그리고! 우리가 웹을 사용할 때에는 이런 과정이 있는 것이다.

1. 나는 브라우저라는 도구를 들고 있는 client다.
2. 그리고 server와 통신을 위해 컴퓨터에게 가 요청(request)을 한다.
3. 그럼 server는 우리의 요청을 받고 그에 맞는 응답(response)을 해준다.
4. 나는 그에 맞는 응답(html 같은 것)을 받게 되고 원하는 바를 이루었다!

그리고 이 request 라는 상호작용은 url 로 한다 ! (url을 통해 내가 어떤 것을 주문할 건지 요청하는 것)

두 가지 주소

아하! 이제 우리는 app.py 로 호스팅을 하기위한 기초적인 client 와 server 의 관계를 알게되었다.

이제 app.py에 적혀있는 것들을 토대로 우리가 대체 뭔 코드를 적었는지 알아보자.

일단 우리가 만들어 둔 app.py 를 실행시켜보자.
그러면 아래에 이러한 문구가 나올것이다.
Running on http://127.0.0.1:포트번호
이는 localhost:포트번호이라는 url로 app.py라는 서버가 실행되었다라는 의미이다.

그렇다면 127.0.0.1 은 뭘까? -> 이는 내 컴퓨터의 주소를 뜻한다.
정확히는 각 local 환경의 장치 주소, 그러니까 나 자신 을 가리키는 IP 주소이다.
(이를 루프백 IP 주소라고 한다.)
(포트에 대해서는 조금 더 아래에 설명하겠다.)

아하, 이제 알겠다. 그런데 여기서 한가지 의문이 생긴다.
app.py를 실행했을 때, Running on http://127.0.0.1:5000 은 왜 뜨는지 알겠다!

그렇다면 그 아래에 떠있는 주소 는 뭐지?

이는 인터넷 연결 주소로 추정된다.

그러니까, 127.0.0.1는 나 자신이고,
그 아래에 뜬 xxx.xxx.xxx.xxx는 내 컴퓨터(클라이언트) -> 인터넷(브라우저) -> 내컴퓨터(서버)라는 여정을 통해!!
인터넷을 들어갈 때 받은 나의 인터넷 ip 주소라는 것이다.
(사실 좀 더 정확하게는 라우터를 통하고 어쩌고 저쩌고 인듯 하지만 지금은 중요하지 않으니 넘어가자)

서버는 사실 한반도였다.

그럼 이제 app.py 에 적힌 코드들을 분석해보자.

일단 이 부분부터 살펴보면 route 라는 단어가 눈에 보인다.
음? route? route 란 뭘까?

검색을 해보면 사전적 의미는 이러하다. (네이버 사전 검색 결과)
그렇다! route는 서버로 가는 경로를 뜻하는 것이였다.

그러니까 client 가 server에 요청을 하게 되면, 서버는 / 라는 장소로 보내준다.

client 에게 요청이 오면 요청에 맞는 곳으로 보내주는 것이 @app.route('/')의 정체였던 것이다.

여기까지 이해가 되었다면 우리는 이제 port에 대해 배울 차례이다.

port 란 뭘까 ??
바로 검색을 해보도록 하자.

사전적 의미는 항구였다. (네이버 사전 검색 결과)

그렇다.. 사실 서버는 한반도였고, 이 서버라는 한반도에는 인천항, 부산항 등의 포트라는 항구가 있었던 것이다.

한반도에 있는 항구를 숫자로 표현했다고 생각해보자.
인천항은 80.. 부산항은 5000...

그런데, 이 포트들은 기본적으로 닫혀있다.
이는 보안과 관련된 부분인데 이에대해 조금만 알아보고 다음으로 넘어가자.

일단 위에서 server는 방금 한반도라고 했다.
그런데 만약 이 server의 항구인 port들이 모두 개방되어있으면..
아무나 server로 접속 할 수 있지 않겠는가?

이를 좀 더 생각해보자면, 필자는 server는 컴퓨터라고 했다.
그렇다면 나의 컴퓨터도 server가 될 수 있다는 의미이다.
그런데 인터넷에 연결된 내 컴퓨터가 완전개방이 되어있으면... 모두가 내 컴퓨터로 들어오지 않겠는가?

그렇다! 아무나 막 접속해서 헤집어놓고 갈 수 있는 것이였다!

이를 미연에 방지하기 위해서 위대한 이순신 장군님은 이런 생각을 해내고 만다.
-> 항구를 다 뚫어놓고 하나씩 막는것 보다는 그냥 항구를 다 막아놓고 필요할때만 뚫는게 낫지 않을까??

그렇기 때문에 보통 port는 막혀있고 우리가 해당 port를 사용하기 위해서는 값을 할당해주어야 한다.

어? 근데 port 5000이라고 한적 없는데 ???
사실 있었다..

app.py 코드의 마지막 부분을 보면...

이렇게 적혀있는 것을 확인 할 수 있었다.

결국 우리는 우리도 모르는 사이 route도 지정해주고 port도 할당하고 서버에 필요한 것들을 모두 해주고 있었던 것이다..

공구상자와 몽키스패너

일단 공구고 나발이고 먼저 위에서 본 route 부분을 다시 한번 살펴보자.

그럼 우리가 위에서 생각해보지 않은 def 즉, 함수에 대해 알아보지 않았다는 것을 알 수 있다.

def 의 역할은 뭘까??
그것은 def 바로 아래에 적혀있다.
return 해준다는 뜻이다.

그런데 뭘??

home 이라는 애가 아무것도 없이() 불렸을 때!
render_template 를 return ! 즉, 반환해준다는 것이다.

또 새로운 단어가 나왔다!
바로 render_template
이를 반으로 쪼개 해석해보면 이렇다.

render -> 주다
template -> 템플릿

그렇다! home이라는 녀석이 불리면, 템플릿을 준다는 것이다!
어떤 템플릿?
바로 index.html 이라는 템플릿!!

어? 그런데 뭔가 이상하다..
render도 template 도 나는 뭐 아무것도 설정한 적이 없는데???

그건..

플라스크로 가져왔던 것!!!

결국 플라스크라는 공구상자에서 rener_template라는 몽키스패너를 나도 모르게 꺼내 쓴 것 이였다.

GET/POST 와 파라미터

이제 GET과 POST에 대해 알아보자
이 두방식에는 어떤 차이가 있을까?

그것은.. 파라미터를 노출하느냐 안하느냐!!

엥? 파라미터는 뭐지??

검색해보면 매개변수라는 의미로 쓰이는 것을 알 수 있었다.

예를 들어, (아이디, 패스워드)를 적고 로그인을 누르면 (아이디, 패스워드)가 서버로 보내진다!! -> 이 (아이디)와 (패스워드)를 서버가 보고 판단해야 하는데 이걸 담은 변수가 파라미터!

아무튼 위의 예시처럼 로그인을 할 때 app.py 에서는 이런 일이 발생한다.

id = request.form['id'] 라는 코드를 통해 -> id(파이썬 파일의 변수)라는 변수에 'id'(파라미터) 라는 이름을 가진 변수가 오면 받도록 해!

근데.. GET 방식에서는 이 아이디, 비밀번호 값이 다 노출이 된다..

www.naver.com/id=awesome_gomyammii/password=handsome_gomyammii
이런 식으로 id와 password가 전부 보여져버리는 것...

어? 이러면.. 내 개인정보가 다 빠져나가는데??
-> 이래서 POST 방식을 주로 쓴다 (그래서 우리는 DB를 주고 받을 때 POST 를 썼던 것...)

잉? 그러면 GET 은 언제써요??
-> 간단한 랜더링 할 때!!

동기와 비동기

동기와 비동기..?
뭔 소린지 잘 모르겠으니 일단 검색을 해보자.

동기는 이런 의미고... (네이버 사전)

영어로는 이러하다. (검색결과)

그렇다면 동기는 뭐가 동시에 발생한다는 것일까?
바로.. client의 요청과 server의 응답이 동시에 일어난다는 뜻이다.

이는 바꿔말하면, 요청 -> 응답 의 값이 나올때까지 기다려야 한다는 의미이다..
설령 그게 1분이던..1시간이던...1억년이던 말이지...

그에 반해 비동기는 동기의 반대 개념이다.
client의 요청과 server의 응답이 동시에 일어나지 않는다!

그러니까 여러가지 요청 (로그인 버튼 누르기, 팝업창 닫기, 페이지 검색하기 등)을 한번에 하면 각각 그에 맞는 응답을 찾자마자 응답이 완료된다는 것이다.

이는 skeleton ui 라는 것을 통해 예시를 들 수 있다.

웹에서 이런 상태를 본적이 있는가?
이것이 비동기 방식의 대표적인 예시이다.

그래서 오늘은 서버와 클라이언트, 그리고 어쩌고 저쩌고에 대해 배웠다.
그리고 이것 하나만 기억하자.

나는 크롬이자 네이버 웨일이자 마이크로 엣지이고, 서버는 고양이다.