MintyU | Feed

TCP와 QUIC 파일 전송 성능 비교 (3)

Mon, 27 Jun 2022 00:00:00 GMT

6. 실험 결과

근거리 네트워킹 실험

근거리 네트워킹 실험에서는 동일한 기기 상에서 서버와 클라이언트를 각각 실행한 환경에서 파일을 전송 후 성능을 측정했습니다.

해당 실험 환경의 Round Trip Time은 min / avg / max / stddev = 0.037 / 0.079 / 0.149 / 0.026 ms 입니다.

TCP, TCP+TLS, QUIC 각각 1개에서 6개로 연결을 병렬로 늘려가며 실험했습니다. 실험 결과는 각 케이스마다 10회 전송 후 전송 시간의 평균을 도출했습니다.

실험 결과, QUIC이 더 느린 것으로 나타났으며 TCP 연결이 오히려 더 빨랐고, TLS까지 사용했을 경우 TLS 연결에 필요한 추가적인 시간만큼 더 지연이 생겼으며 그조차도 QUIC보다는 빨랐습니다.

RTT 값이 매우 극단적으로 작은 환경에서 실험했기 때문에, 이 경우는 TCP의 문제점으로 지적했던 3-Way Handshake 연결 설정이나 HOL Blocking 문제가 크게 나타나지 않았습니다. RTT 값이 극단적으로 작기 때문에 3-Way Handshake를 통한 연결 수립에 큰 시간이 걸리지 않았을 뿐만 아니라 Packet Loss도 0%로 전혀 발생하지 않았기 때문에 HOL Blocking으로 인한 문제도 발생하지 않았기 때문입니다.

또한 근거리 네트워킹 실험에서는 연결 수립에 필요한 시간이 워낙 짧다 보니 연결 수를 늘려 병렬 파일 전송을 했을 경우 전송 시간이 줄어드는 것까지 확인할 수 있었습니다.

원거리 네트워킹 실험

이번엔 RTT 값이 매우 큰, 해외 서버에서 데이터를 전송받는 경우를 가정해봅시다. 원거리 네트워킹 실험의 환경을 구축하기 위해서 AWS EC2 서비스를 이용했습니다.

us-east-1 서버(미국 동부 - 버지니아 북부)를 이용하여, 2 vCPU와 4 GiB 메모리의 t2.medium 인스턴스로 서버를 동작했습니다.

해당 실험 환경의 Round Trip Time은 min / avg / max / stddev = 194.567 / 195.514 / 208.020 / 1.646 ms 입니다.

마찬가지로 TCP, CP+TLS, QUIC 각각 1개에서 6개로 연결을 병렬로 늘려가며 실험하였으며 각 케이스마다 10회 전송 후 전송 시간의 평균을 도출했습니다.

원거리 환경이 되자 결과가 뒤집혔습니다. 이 경우 QUIC이 TCP보다 전송 속도가 더 빨랐습니다.

자세한 결과 분석을 위해 파일 전송 시간에서 연결을 수립하는 데 걸린 시간만 따로 측정해보았습니다. 아래는 그 결과 그래프입니다.

TCP 연결의 수를 늘릴수록 점점 연결에 필요한 시간이 증가했습니다. 이에 반해, QUIC의 경우 연결 후 Stream을 늘렸지만 별다른 연결 시간 증가는 확인할 수 없었습니다.

뿐만 아니라, QUIC은 2번째 전송부터는 0-RTT로 바로 데이터 전송을 시도할 수 있습니다. 이에 따라 그래프에서 연결 시간이 기존보다 더 줄어든것까지 확인할 수 있습니다.

요약

RTT가 매우 작은 환경인 경우에는 TCP 전송이 더 빨라 유리하지만, RTT가 커지기 시작하면(일반적으로 서비스하는 경우) TCP보다 QUIC을 통한 파일 전송이 더 유리할 수도 있다.

7. 결론

앞선 실험 결과에서 알 수 있듯, RTT 값에 따라서 RTT 값이 작은 경우 TCP가 유리할 수는 있으나, 대부분의 서비스 환경에서의 RTT 수준이면 QUIC을 통한 파일 전송을 충분히 사용할 수 있을 것이라고 보이며, 충분히 경쟁력 있다고 생각합니다.

아직 QUIC이 완벽히 정착되지 않았고, 최적화도 부족하며 무엇보다 충분한 Document와 Community가 축적될 시간이 없었다는 점에서 아쉽다고 느낄 수는 있으나, 실험 결과 충분히 TCP를 대체할만한 경쟁력을 갖추고있다고 생각됩니다.

특히 병렬 전송이 필요한 경우에 TCP는 하나의 연결에 1:1 통신밖에 되지 않아서, 복수 개의 연결을 수립하고 병렬 전송해야 하기 때문에 이 과정에서 연결 추가에 따른 오버헤드가 발생했습니다. 하지만 QUIC은 Stream을 늘리는 데 별다른 시간 소모가 추가적으로 필요하지 않기 때문에 병렬 전송이 필요한 분야에서는 TCP보다 QUIC이 압도적으로 유리함을 실험을 통해 확인할 수 있었습니다.

TCP와 QUIC 파일 전송 성능 비교 (2)

Sat, 25 Jun 2022 00:00:00 GMT

4. QUIC 소개

앞선 글에서 설명했듯, QUIC은 UDP를 기반으로 만들어진 전송 계층 프로토콜입니다. 하지만, 기존에 TCP를 필요로 하던 HTTP에서 TCP의 자리를 UDP 기반의 QUIC 프로토콜이 차지했다는 사실은, UDP의 특징을 이해하고 있다면 다소 아이러니하게 들릴 수도 있습니다.

물론, UDP는 데이터 전송의 신뢰성을 보장하지 못하지만, QUIC은 UDP 위에 새로운 계층을 추가하면서 신뢰성을 제공하게 됩니다. 이 추가된 계층은, 기존 TCP의 기능이었던 패킷 재전송이나 혼잡 제어, 속도 조정과 같은 기능을 제공해주게 되면서 UDP 기반 통신에도 신뢰성을 확보할 수 있게 되었습니다. 뿐만 아니라 TCP가 원래는 커널 내부에 구현되어있었지만, QUIC의 혼잡 제어 알고리즘은 어플리케이션으로 구현되어 수정이 쉽고 최적화가 용이하다는 장점이 있습니다.

QUIC의 특징

QUIC은 기존 TCP의 단점으로 지적된 점들을 해결하기 위해 신경 쓴 모습을 많이 볼 수 있습니다. 그 첫 번째는 연결에서 볼 수 있습니다. TCP는 3-Way Handshake를 거처 연결을 수립해야 하는 반면, QUIC은 1-RTT(1-Round Trip Time)으로 연결이 수립되며, 이전에 서버에 연결한 적이 있는 클라이언트와의 연결은 0-RTT로 연결이 수립되고 이론상 Handshake가 완료되기를 기다리지 않고 바로 데이터 전송을 시작할 수 있습니다. 이를 통해 연결 수립에 필요한 시간을 획기적으로 줄일 수 있었습니다.

두 번째로 3-Way Handshake와 함께 TCP의 문제점이라고 할 수 있었던 HOL Blocking 문제를 해결한 점도 눈에 띕니다. TCP 기반의 HTTP/2를 사용하는 대부분의 브라우저는 하나의 TCP 연결을 통해 수십, 수백 개의 병렬 전송을 합니다. 하지만, QUIC은 서로 다른 여러 개의 Stream을 설정하고 독립적으로 다룰 수 있기 때문에 특정 Stream에서 전송되던 데이터의 손실에도 다른 Stream의 전송에 영향을 주지 않습니다. 따라서, 패킷 손실률이 큰 환경에서 QUIC의 성능은 더 돋보이게 됩니다.

세 번째 눈에 띄는 특징은 TLS(Transport Layer Security)입니다. TCP의 경우 따로 보안기능이 없었기 때문에, 보안 연결을 위해서는 반드시 TLS를 함께 사용해야 했습니다. 또한, TLS 연결을 수립하는 과정에서도 추가적인 Handshake가 필요했기에 TCP의 연결 시간 지연을 더더욱 부각시키는 상태였습니다. 하지만, QUIC은 TLS 1.3의 전송 보안을 기본으로 탑재하고 있습니다. TLS 1.3버전은 이전 버전과 비교했을 때 Handshake에 더 적은 RTT가 필요해졌기에 더 빠를 뿐만 아니라, TCP 연결 따로, TLS 연결 따로 순차적으로 진행하던것과 달리 QUIC은 연결과 동시에 TLS Handshake를 함께 진행합니다.

5. QUIC이 TCP를 대체 가능할까?

QUIC을 살펴보다 보면, 정말 TCP를 대체할 수 있을 것 같은 느낌이 듭니다. 오히려, TCP에서 고질적으로 발생하던 문제들도 해결되었고 QUIC이 속도도 더 빠를 것 같다는 생각이 듭니다.

정말 QUIC이 TCP의 대안으로 사용될 수 있을지, 실험을 통해 알아보도록 하겠습니다.

실험 설계

우선, 성능 평가 분야는 "파일 전송"으로 선정했습니다. 크기가 같은 파일을 전송 프로토콜만 다르게 하여 전송하는 시간을 측정하여 간단하게 프로토콜의 전송 성능을 측정할 수 있을 것입니다.

실험의 전체 틀은 아래와 같습니다.

전송에 사용할 파일은 mov 형식의 동영상 파일을 실험에 사용하기로 했습니다. 중간에 데이터가 손실되어 제대로 전달되지 않았을 경우, 영상이 정상적으로 재생되지 않기 때문에 영상을 실행시켜보면 정상적으로 모두 전송이 되었는지 간단하게 확인할 수 있습니다.

TCP는 1:1 통신만 가능하기 때문에, 단일 TCP 연결을 통해 병렬 전송을 하게 됩니다. Stream 세션을 병렬로 늘릴 수 있는 QUIC과의 성능을 비교해보기 위해서, TCP 연결을 병렬로 여러개 수립해서 병렬 전송을 해 보고, 전송 성능이 향상되는지 측정해 보고 QUIC의 경우와 비교해 보도록 하겠습니다.

또한 전송 속도가 빠를 때, 전송 속도가 느릴 때 속도의 차이도 비교하기 위해 근거리 네트워크, 장거리 네트워크의 경우를 각각 나누어 성능을 비교합니다.

실험의 세부 설계는 아래와 같습니다.

- 서버 SW 설계 및 개발

실험에 사용된 서버 SW는 전송할 파일을 일정한 크기로 chunk 형태로 분할합니다. 분할되는 chunk의 수는 실험 시 클라이언트와 수립되는 연결의 수와 같습니다. 각각의 chunk는 번호가 매겨지며, 각각의 연결 당 한 개의 chunk를 전달합니다. 각 연결들을 통한 멀티스레딩을 통해 동시에 이뤄집니다. TCP 연결의 경우, TLS 연결 없이 순수 TCP 연결만 1개~6개로 전송하는 경우와 TLS 연결을 포함한 TCP 연결 1개~6개로 전송하는 경우를 각각 측정하며, QUIC 또한 Stream을 1개~6개로 늘려가며 파일을 분할 전송하게 됩니다.

서버 SW는 Golang을 이용, github.com/lucas-clemente/quic-go 라이브러리를 통해 QUIC 전송을 구현했으며, TCP는 기본 패키지 net을 통해 전송을 구현했습니다. TCP+TLS는 crypto/tls 패키지를 통해 구현했습니다. TCP(+TLS) 서버는 나눠진 chunk들을 전송할 수 있도록 chunk당 하나의 TCP(+TLS) 연결을 생성합니다. 그리고 각각의 chunk들을 연결을 통해 전송합니다. chunk 순서는 클라이언트가 연결을 시도하는 순서와 같습니다. 주어진 chunk를 모두 전송한 경우, TCP(+TLS) 연결을 종료하며 클라이언트 측에 EOF를 전달합니다. QUIC 서버는 마찬가지로 나눠진 chunk들을 전송할 수 있도록 chunk당 하나의 stream 연결을 생성합니다. 그리고 각각의 chunk들을 stream을 통해 전송합니다. chunk의 순서 또한 TCP와 마찬가지로 클라이언트가 연결을 시도하는 순서와 같습니다.

주어진 chunk를 모두 전송하게 되면 EOF를 전송한 후 QUIC stream이 닫히게 되고, 모든 전송이 완료되어 모든 stream이 닫히게 되면 QUIC 연결이 끊어집니다. 이 부분에서 클라이언트에 모든 데이터들이 도달하기 전에 서버는 모든 파일을 전송 완료 후 stream을 닫아버리게 되면 QUIC 연결이 끊기고 마지막 1~2개정도의 버퍼가 클라이언트에 도달하지 않는 문제가 있으므로, 모든 전송이 완료되었는지를 확인할 수 있는 별도의 stream을 열어 클라이언트가 모든 파일 수신을 완료한 후 보내는 신호를 수신 후 stream을 닫아 조기에 QUIC 연결이 끊어지는 것을 방지해야 합니다.

- 클라이언트 SW 설계 및 개발

클라이언트는 서버에 연결 후 서버가 보내는 모든 chunk 파일들을 받습니다. 연결 시도 순서가 chunk 순서와 같기 때문에 연결 순서대로 받은 chunk에 똑같이 번호를 매긴후, 원래 파일과 같은 형태로 합쳐주는 과정을 거칩니다. 파일 수신 또한 서버와 마찬가지로 멀티스레딩을 통해 동시에 이루어집니다. 모든 클라이언트는 시작 시간부터 연결 완료 시간, 전송 완료 시간을 각각 로그를 통해 출력하여 작업 시간을 측정합니다.

TCP(+TLS) 클라이언트는 서버와 동일한 수의 TCP(+TLS) 연결을 진행하며, 각각의 연결을 통해 서버가 보낸 EOF를 받으면 수신을 종료하고 연결을 닫습니다. 모든 파일을 다 수신하면 수신한 모든 chunk를 순서에 맞춰 하나로 합쳐줍니다. TCP+TLS 클라이언트에서 서버로 복수로 연결을 시도할 시, 앞서 연결된 TCP+TLS를 통해 데이터가 한번도 이동하지 않았다면 이후 시도되는 연결은 앞의 연결과 동일한 연결 시도(동일한 인증서 사용으로 인함)로 파악해 TCP+TLS 연결의 경우 매 연결 시작 직후 데이터를 전송해 다른 연결 시도임을 확인시킵니다.

QUIC 클라이언트는 마찬가지로 서버와 동일한 수의 QUIC stream을 통해 파일 chunk들을 수신하게 되며, 추가로 stream을 하나 더 열어 모든 연결을 통해 서버로부터 EOF를 수신하고 정상적으로 파일을 모두 받은 것을 확인하면 서버를 닫아도 괜찮다는 신호를 보내게 됩니다. 그렇게 연결이 모두 끊어진 뒤, 받은 chunk들을 하나의 파일로 합칩니다.

여기까지 실험 설계를 마쳤으니, 다음 글에서 실험 결과를 보도록 하겠습니다.

TCP와 QUIC 파일 전송 성능 비교 (1)

Fri, 24 Jun 2022 00:00:00 GMT

0. 전송 계층 프로토콜의 간단한 이해

TCP와 UDP의 비교에 앞서, 전송 계층 프로토콜이 무엇인지 그 개념을 정리해보겠습니다.

컴퓨터 통신이 활성화되면서, 각각의 통신망 별로 각자 다 다른 규칙을 마련하는 것은 너무 비효율적이었습니다. 따라서 어떤 제조사에서 만든 통신 기기에서도, 어떤 네트워크인지 상관 없이 상호 통신이 가능한 규칙이 필요했습니다. 이 과정에서 OSI 7 Layer(OSI 7계층) 개념이 도입되었습니다.

OSI 7 Layer에서는 통신이 일어나는 과정을 7단계로 나누고, 각 단계 별로 통신에서 수행하는 역할을 구분해 두었습니다.

이 중, 전송 계층(Transport Layer)는 4계층에 속합니다. 전송 계층은 하위 계층에 신뢰할 수 있는 데이터 전송 서비스를 제공하는 것이 주 목적이라고 할 수 있습니다. 쉽게 말해서, 컴퓨터와 컴퓨터 간에 통신을 할 때 데이터가 의도한 대로 잘 갔는지 확인하는 역할을 전송 계층이 해준다는 의미입니다. 그리고 이런 전송 계층을 담당하는 대표적인 프로토콜엔 TCP와 UDP가 있습니다.

- TCP

TCP는 전송 제어 프로토콜(Transmission Control Protocol)의 약자로, 연결 지향적 프로토콜입니다. 따라서 데이터가 전송되기 전, 반드시 클라이언트와 서버의 연결이 이루어지며, 이 연결 과정은 3-Way Handshake 라고 합니다. Handshake가 가진 악수라는 뜻처럼, 네트워크 관련 분야에서는 통신이 시작되기 전 양 측이 악수하는 것처럼 통신 채널의 변수를 설정하는 일련의 과정을 의미합니다.

클라이언트에서 서버에 연결 요청을 하기 위해 SYN 데이터를 보낸다.
서버에서 SYN 데이터를 받은 후 정상적으로 데이터를 수신했다는 대답(ACK)와 함께 클라이언트도 포트를 열어달라는 신호인 SYN을 함께 보낸다.
클라이언트는 SYN, ACK 신호를 받고 포트를 열고 서버에 ACK를 전송하게 된다.

TCP는 패킷이라는 가장 작은 단위로 데이터를 전송합니다. 데이터를 전송하는 과정에서 송신자(Sender)가 데이터를 패킷의 형태로 전송하면, 수신자(Reciever)는 데이터를 받은 후 ACK(확인)신호를 송신자에게 다시 전송하게 됩니다. 따라서 송신자는 수신자가 제대로 데이터를 받았는지 확인할 수 있으며, 만약 제대로 전송이 안되었다면 다시 전송해서 수신자가 모든 데이터를 다 받았음을 보장합니다. TCP는 전송하는 패킷에 Sequence number를 매겨서 전송 순서까지 보장할 수 있습니다. 이 과정에서 TCP는 신뢰성 있는 데이터를 전송할 수 있습니다.(빠진 데이터 없이 모두 전송되었는지, 순서는 맞게 전송되었는지 신뢰성을 보장)

- UDP

UDP는 사용자 데이터그램 프로토콜(User Datagram Protocol)의 약자로, 비연결 지향적 프로토콜입니다. TCP의 전송 단위는 패킷인것처럼, UDP는 데이터그램(Datagram)의 단위로 데이터를 전송하게 됩니다.

TCP에서는 데이터의 전송을 위해 일단 연결을 먼저 수립한것과 반대로, UDP는 연결 과정을 거치지 않고 송신자가 그냥 일방적으로 데이터를 전송하게 됩니다. 연결 과정이 없기 때문에 TCP에 비해 빠른 속도로 데이터를 전송할 수는 있지만, 데이터 전달의 신뢰성은 떨어지게 됩니다. 또한, 직접 연결을 수립한 것이 아니기 때문에 각각의 데이터그램들은 모두 다른 경로로 독립적으로 전송되게 됩니다. 이 과정에서 어떤 경로는 전송 속도가 빠르고, 어떤 경로는 느린 경우가 존재하기 때문에 먼저 전송했다고 먼저 도착할것이라고 보장할 수가 없습니다. 따라서 UDP는 데이터 전송의 순서는 보장받을 수 없습니다.

1. 어떤 프로토콜을 이용하는 것이 좋은가?

그렇다면 어떤 프로토콜을 이용해야 하는가?

예상했겠지만, TCP와 UDP 모두 각각의 특징이 뚜렷하기 때문에 무엇을 사용하는 것이 정답이라고 할 수는 없습니다. 구현하고자 하는 서비스가 어떤 프로토콜을 이용했을 때 잘 맞을지 생각해보고, 이를 적용하는 것이 최선이라고 할수 있습니다.

가령, 파일을 전송한다고 해봅시다. 파일을 전송하는 경우 사용자의 입장에서 물론 파일의 전송이 빠르면 빠를 수록 좋을 것입니다. 하지만, 전달받은 데이터가 뒤죽박죽이 되거나 중간중간 일부분이 전송 실패로 온전하지 못한 파일을 전송받기는 싫을 것입니다. 아무리 속도가 빠르다고 해도, 열수도 없는 파일을 전달받고자 하는 사용자는 아무도 없을 것입니다. 이 경우, 속도에서 어느 정도 타협이 있더라도 전달하고자 하는 파일에 대한 신뢰성을 보장받을 수 있어야 하기 때문에 TCP를 사용하는 것이 더 적합하다고 볼 수 있습니다.

UDP의 경우는 신뢰성있는 데이터의 전송은 보장해주지 못하기 때문에, 신뢰성이 중요한 파일 전송과 같은 서비스보다는 속도가 중요한 스트리밍 서비스 등에 이용할 수 있습니다.

2. 성능 향상?

사실 TCP와 UDP 모두 설계되고 사용된지 상당히 오래된 프로토콜이고, 그에 따라 프로토콜의 성능을 향상시키려는 시도가 많이 있었습니다. 특히 TCP의 단점인 느린 속도를 커버하기 위해 다양한 노력들이 있었지만, TCP의 느린 속도의 주범이라고 지목받은 3-Way Handshake를 근본적으로 해결할 수가 없었습니다.

또한, TCP는 HOL Blocking(Head Of Line Blocking)이라는 문제를 안고 있었습니다. TCP를 사용한 HTTP의 전송 지연 시간을 줄이기 위해 Pipelining을 통해 한 번에 여러 개의 요청을 보내게 되면, ACK가 도착하기 전까지 발생하는 지연을 줄일 수가 있었습니다. 하지만, 가장 먼저 전송된 요청에 대해 처리가 늦어지면 그 뒤에 전송된 요청들에 대한 처리도 함께 밀리게 되는 상태가 됩니다. 이를 HOL Blocking이라고 하게 됩니다. Pipelining을 통해 지연 시간은 조금 줄일 수 있어도 TCP를 사용하는 이상 HOL Blocking에 대한 문제는 안고 갈 수밖에 없었습니다.

사실상 3-Way Handshake와 HOL Blocking 문제를 근본적으로 해결하기 위해서는 TCP를 포기해야만 했고, 그로 인해 구글은 UDP로 눈을 돌립니다.

3. QUIC의 탄생

QUIC은 UDP를 기반으로 한 전송 계층 프로토콜로, 구글의 짐 로스킨드가 처음 설계한 프로토콜입니다.

QUIC이 생소할 수도 있지만, 이미 구글은 많은 서비스에서 이를 사용하고 있습니다.

주소창에 chrome://flags/로 들어가면 다양한 기능을 사용할 수 있습니다. 이 중, "Experimental QUIC protocol" 항목을 활성화시켜주시면, QUIC 프로토콜을 사용한 전송을 허용할 수 있습니다. 만약 인터넷을 사용하는데 들어간 사이트가 QUIC 프로토콜을 지원한다면, QUIC을 통한 전송을 허용하는 것입니다. 아직 완벽한 상태는 아니기에 크롬에서도 실험항목으로 남겨둔 것 같습니다.

그러고 유튜브로 들어가서 프로토콜을 확인하면 h3(HTTP/3) 프로토콜이 적용된 것을 확인할 수 있습니다. HTTP/3 버전의 표준이 QUIC 프로토콜이므로 잘 적용된 것을 확인할 수가 있습니다.

지금까지 HTTP는 TCP를 기반으로 작성되었고, 앞서 말한 TCP의 고질적인 문제를 고칠 수 없었기에 구글은 QUIC 프로토콜을 제안하였으며 이는 HTTP/3의 표준으로 인정받게 됩니다.

여기까지 전송 계층 프로토콜에 대한 설명과, QUIC의 탄생 배경에 대해서 알아보았습니다. 다음 글에서는 어떻게 UDP를 통한 QUIC으로 신뢰성있는 전송이 필요한 HTTP 프로토콜의 기반으로 쓰일 수 있었는지, 그리고 QUIC 프로토콜의 특징은 무엇인지 알아보도록 하겠습니다.

카카오톡 봇 제작기 (1) - 구동 원리, 준비물

Tue, 22 Mar 2022 00:00:00 GMT

카카오톡 봇

게임 캐릭터 정보를 확인하기 위해 따로 인터넷 검색을 해야 하는 번거로운 작업을 줄이고, 간단한 편의성 기능을 제공하기 위해 개인적으로 사용할 목적의 카카오톡 봇을 만들어보기로 결심했습니다.

봇 최초 컴파일(3월 7일) 이후 2주가 지난 지금, 어느정도 봇도 안정화되었고 개발 과정에 대해 궁금해하시는 분들이 있어서 개발 과정을 간단하게 공개해보려 합니다.

작동 원리

지금까지 카카오톡 단체 채팅방이나 오픈 톡방에서 방장봇을 제외한 사설 봇을 보았다면, 아마 99.9% 모두 같은 원리로 동작하는 봇들입니다.

한 때 카카오톡의 통신 프로토콜인 LOCO Protocol(2011년 10월 13일 릴리즈, 기존 HTTP/TCP 프로토콜에서 자체 개발한 LOCO 프로토콜로 변경)을 통해 카카오톡 클라이언트인 척 메시지를 보내는 봇들도 있었으나, 해당 부분은 보안에 취약하기도 하고 약관에 위배되기 때문에 해당 방법을 이용한 봇들을 사용하면 계정이 정지당할 수 있습니다.

이 때문에 현재 카카오톡 봇 앱을 통해 구동되는 봇들이 대부분이라고 볼 수 있습니다.

봇 구동을 위해 많이 사용하는 앱은 메신저봇 R, 채팅 자동응답 봇입니다. 제가 사용한 앱은 메신저봇 R이며, 앞으로의 설명들은 모두 해당 앱을 기준으로 진행됩니다.

해당 앱의 작동 원리는 아래와 같습니다.

NotificationListenerService를 통해 알림을 파싱한다.
Rhino JavaScript Engine을 사용하여 사용자가 작성한 자바스크립트로 알림 정보를 전달하여 처리한다.
WearableExtender를 통해 답장을 전달한다.

1번에서 받게 되는 알림의 내용에는 채팅이 온 방의 이름, 메시지 내용, 전송자의 이름 등의 정보가 있습니다.

해당 정보들을 받으면 2번 과정에서 사용자가 작성한 자바스크립트의 내용에 따라 정보를 처리하게 됩니다. (인터넷에서 해당 정보를 찾아온다던가, 결과값을 더 예쁘게 보일 수 있도록 처리)

그리고 해당 결과를 다시 채팅방에 reply 해주면서 챗봇이 동작하게 됩니다.

준비물

애석하게도, 현재 카카오톡의 정책 때문에 준비할것이 조금 있습니다.

저는 공기계(갤럭시 S9+ 기기)를 통해 봇을 동작시킬것이기 때문에, 하나의 본계정을 두개의 기기에 모두 로그인해서 사용할 수 없는 카카오톡의 정책 상 부계정을 하나 새로 만들었습니다.

(공기계가 아닌 본인의 기기로 본계정을 통해 봇을 구동할 경우, 사용자의 도배나 악용으로 인해 제재를 받는 경우 대처하기가 어려워집니다.)

부계정을 만드는 방법에는 크게 두 가지 정도가 있습니다.

통신사의 투넘버 서비스(번호 두개 이용)를 통해 계정을 하나 더 생성한다.
가상 해외 번호를 통해 계정을 하나 더 생성한다.

두 방법은 장단점이 있습니다. 1번 방식은 통신사에 추가 비용을 지불해야 한다는 단점이 있으며, 카카오톡 임시조치 제한을 받지 않는다는 장점이 있습니다(계정 바로 이용 가능) 하지만, 2번 방식은 앱을 통해 가상 해외 번호를 받아서 카카오톡 인증만 진행하면 되기 때문에 추가 비용이 들지 않는다는 장점이 있습니다. 하지만, 카카오톡의 정책으로 인한 임시조치 제한을 받습니다.

여기서 임시조치 제한이란?

1) 짧은 기간 다수의 사용자가 카카오톡 친구로 추가되는 경우

2) 서비스 악용 유저가 활동한 서비스 환경과 유사한 환경에서 서비스를 사용한 경우

3) 불법 사행성 사이트 홍보 및 음란물 발송 이력이 있는 서비스 이용 환경에서 카카오톡을 사용한 경우

4) 짧은 기간 동안 채팅방 및 오픈 채팅방을 다수 개설한 경우

5) 오픈 채팅방 참여 속도 및 빈도가 비정상적으로 많을 경우

6) 통신사 확인이 되지 않는 해외 가상번호를 사용하는 경우

7) 메시지 신고 접수가 많이 된 경우

8) 오픈 채팅방 사용자 신고 접수가 증가할 경우

9) PC 에뮬레이터 등 비정상적인 환경에서 카카오톡을 사용할 경우

해당 사례 중 한 가지, 혹은 두 가지 이상 해당되었을 때 적용되는 보호조치로, 오픈채팅을 이용하지 못하며 친구추가 수에 제한이 걸리게 됩니다.

물론 임시로 적용되는 제한이기 때문에 일정 기간 정상적으로 카카오톡을 이용하는 것이 카카오톡 내부 매커니즘(봇에 의해 자동으로 이루어지는 것으로 추정)에 의해 확인이 된다면 해제되긴 합니다만, 언제 풀릴지는 정확히 알 수 없습니다.

가상 해외 번호를 통해 인증한 경우 거의 무조건 임시조치 제한에 걸리게 되니 참고해주세요.(6번 내용에 해당)

저는 급한 프로젝트가 아니었으므로 해외 번호로 가입 후 제한이 풀리기를 기다렸습니다.

공기계와 카카오톡 부계정, 이 두 개가 준비되면 일단 1차적인 준비는 끝입니다. 이제 다음 게시물부터는 본격적으로 봇 구동 과정을 보여드리도록 하겠습니다.

자연어 처리(NLP) 실습 - LSTM

Mon, 07 Jun 2021 00:00:00 GMT

LSTM(Long Short Term Memory) 실습

Kaggle의 영화 리뷰에 대한 감정 예측 데이터셋에 대해 LSTM으로 자연어차리 실습을 해보도록 하겠습니다.

Kaggle 링크를 통해 실습 데이터셋을 받을 수 있습니다.

Data 탭에서 train.tsv.zip, test.tsv.zip 을 내려받아 압축을 풀면 각각 train set과 test set의 tsv 파일을 얻을 수 있습니다.

해당 데이터셋에서 감정을 나타내는 label들의 의미는 다음과 같습니다.

0 : negative
1 : somewhat negative
2 : neutral
3 : somewhat positive
4 : positive

데이터 가져오기

우선 실습에 필요한 library들을 불러옵니다.

import numpy as np
import pandas as pd
from matplotlib import pyplot as plt
plt.style.use('dark_background')
from keras.preprocessing.text import Tokenizer
from keras.preprocessing.sequence import pad_sequences
from sklearn.model_selection import train_test_split
from keras.utils.np_utils import to_categorical
from keras.models import Sequential
from keras.layers import Dense, Dropout, Embedding, LSTM, GlobalMaxPooling1D, SpatialDropout1D

to_categorical은 keras의 버전에 따라

from keras.utils.np_utils import to_categorical

혹은

from keras.utils import to_categorical

둘 중 동작하는 것으로 진행하면 됩니다.

df_train = pd.read_csv('train.tsv', sep='\t')
print('train set: {0}'.format(df_train.shape))
df_train.head(10)

우선 train 데이터셋을 불러왔습니다. tsv 파일이므로 sep='\t'옵션으로 데이터를 불러옵니다.

df_test = pd.read_csv('test.tsv', sep='\t')
print('test set: {0}'.format(df_test.shape))
df_test.head(10)

마찬가지로, test 데이터셋도 불러와줍니다.

데이터 전처리

replace_list = {r"i'm": 'i am',
                r"'re": ' are',
                r"let’s": 'let us',
                r"'s":  ' is',
                r"'ve": ' have',
                r"can't": 'can not',
                r"cannot": 'can not',
                r"shan’t": 'shall not',
                r"n't": ' not',
                r"'d": ' would',
                r"'ll": ' will',
                r"'scuse": 'excuse',
                ',': ' ,',
                '.': ' .',
                '!': ' !',
                '?': ' ?',
                '\s+': ' '}
def clean_text(text):
    text = text.lower()
    for s in replace_list:
        text = text.replace(s, replace_list[s])
    text = ' '.join(text.split())
    return text

원활한 학습을 위해 전처리를 진행해줍니다. i'm 과 i am은 같은 단어이지만 다르게 인식될 수 있으므로 형태를 통일해주고, 단어 뒤에 문장 부호가 붙어있는 경우에도 다른 단어로 인식되므로 빈 칸을 추가하여 단어와 문장 부호가 서로 다른 단어로 인식될 수 있게끔 전처리를 해줍니다. 또한, 대문자와 소문자의 차이도 제거하기 위해 모든 단어의 글자들을 .lower()함수를 통해 소문자로 만들어 줍니다.

아래 코드를 통해 적용해줍니다.

X_train = df_train['Phrase'].apply(lambda p: clean_text(p))

이제, corpus(말뭉치)에 있는 구문의 길이를 시각화해보겠습니다.

phrase_len = X_train.apply(lambda p: len(p.split(' ')))
max_phrase_len = phrase_len.max()
print('max phrase len: {0}'.format(max_phrase_len))
plt.figure(figsize = (10, 8))
plt.hist(phrase_len, alpha = 0.2, density = True)
plt.xlabel('phrase len')
plt.ylabel('probability')
plt.grid(alpha = 0.25)

max phrase len: 53

가장 긴 문장의 길이는 53이며, 단어 길이의 분포는 위와 같습니다.

신경망에 대한 모든 입력은 길이가 같아야합니다. 따라서 가장 긴 길이를 나중에 모델에 대한 입력을 정의하는 데 사용할 변수로 저장합니다.

y_train = df_train['Sentiment']

감정 데이터가 있는 Sentiment 항목으로 train set을 만들어줍니다.

이제 tokenizer를 통해 토큰화를 진행합니다. 또한, filters= 옵션을 통해 특수문자들을 제거해줍니다.

max_words = 8192
tokenizer = Tokenizer(
    num_words = max_words,
    filters = '"#$%&()*+-/:;<=>@[\]^_`{|}~'
)
tokenizer.fit_on_texts(X_train)
X_train = tokenizer.texts_to_sequences(X_train)
X_train = pad_sequences(X_train, maxlen = max_phrase_len)
y_train = to_categorical(y_train)

to_categorical 함수를 통해, y_train 값을 원-핫 벡터로 바꿔주어 인코딩 과정도 진행해줍니다.

Training

model_lstm = Sequential()
model_lstm.add(Embedding(input_dim = max_words, output_dim = 256, input_length = max_phrase_len))
model_lstm.add(SpatialDropout1D(0.3))
model_lstm.add(LSTM(256, dropout = 0.3, recurrent_dropout = 0.3))
model_lstm.add(Dense(256, activation = 'relu'))
model_lstm.add(Dropout(0.3))
model_lstm.add(Dense(5, activation = 'softmax'))
model_lstm.compile(
    loss='categorical_crossentropy',
    optimizer='Adam',
    metrics=['accuracy']
)

LSTM 레이어를 만들어 모델을 작성합니다.

history = model_lstm.fit(
    X_train,
    y_train,
    validation_split = 0.1,
    epochs = 8,
    batch_size = 512
)

epochs는 8, batch_size는 512로 설정하고 10%만큼을 validation set으로 이용하게 됩니다.

train이 완료되었습니다. history에는 LSTM fitting 과정에서 각 epoch마다의 loss와 accuracy 데이터가 저장됩니다.

loss와 accuracy 데이터를 시각화하면 다음과 같습니다.

plt.clf()
loss = history.history['loss']
val_loss = history.history['val_loss']
epochs = range(1, len(loss) + 1)
plt.figure(figsize=(10, 8))
plt.plot(epochs, loss, 'g', label='Training loss')
plt.plot(epochs, val_loss, 'y', label='Validation loss')
plt.title('Training and validation loss')
plt.xlabel('Epochs')
plt.ylabel('Loss')
plt.legend()
plt.show()

plt.clf()
acc = history.history['accuracy']
val_acc = history.history['val_accuracy']
plt.figure(figsize=(10, 8))
plt.plot(epochs, acc, 'g', label='Training acc')
plt.plot(epochs, val_acc, 'y', label='Validation acc')
plt.title('Training and validation accuracy')
plt.xlabel('Epochs')
plt.ylabel('Accuracy')
plt.legend()
plt.show()

자연어 처리(NLP)의 전처리 - Word2Vec(워드투벡터) 실습

Sat, 29 May 2021 00:00:00 GMT

Word2Vec 실습(EN)

영어 데이터를 통해 Word2Vec을 학습시켜보도록 하겠습니다. gensim이라는 파이썬 패키지에 Word2Vec이 이미 구현되어 있으므로, 우리는 이를 따로 구현할 필요 없이 Word2Vec을 사용할 수 있습니다.

우선 필요한 도구들을 import해주겠습니다.

import nltk
nltk.download('punkt')

import urllib.request
import zipfile
from lxml import etree
import re
from nltk.tokenize import word_tokenize, sent_tokenize

훈련 데이터

사용할 훈련 데이터는, ted 영상들의 자막 데이터입니다. 파일의 형식은 xml 파일입니다.

해당 링크를 통해 내려받고 압축을 풀어서 ted_en-20160408.xml라는 이름의 파일을 설치할 수도 있고, 파이썬 코드를 통해 자동으로 설치할 수도 있습니다.

# 데이터 다운로드
urllib.request.urlretrieve("https://raw.githubusercontent.com/GaoleMeng/RNN-and-FFNN-textClassification/master/ted_en-20160408.xml", filename="ted_en-20160408.xml")

위의 코드를 통해 xml 파일을 내려받으면, 다음과 같은 파일을 볼 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<xml language="en"><file id="1">
  <head>
    <url>http://www.ted.com/talks/knut_haanaes_two_reasons_companies_fail_and_how_to_avoid_them</url>

    ...

    <content>Here are two reasons companies fail: they only do more of the same, or they only do what's new.

    ...

    So let me leave you with this. Whether you're an explorer by nature or whether you tend to exploit what you already know, don't forget: the beauty is in the balance.
    Thank you.
    (Applause)</content>
</file>
<file id="2">
  <head>
    <url>http://www.ted.com/talks/lisa_nip_how_humans_could_evolve_to_survive_in_space</url>
    
    ...

    (Applause)</content>
</file>
</xml>

전처리

targetXML=open('ted_en-20160408.xml', 'r', encoding='UTF8')
# xml 파일과 python 실행 위치가 같은 경로일 경우의 코드!
target_text = etree.parse(targetXML)
parse_text = '\n'.join(target_text.xpath('//content/text()'))
# xml 파일로부터 <content>와 </content> 사이의 내용만 가져온다.

content_text = re.sub(r'\([^)]*\)', '', parse_text)
# 정규 표현식의 sub 모듈을 통해 content 중간에 등장하는 (Audio), (Laughter) 등의 배경음 부분을 제거.
# 해당 코드는 괄호로 구성된 내용을 제거.

sent_text = sent_tokenize(content_text)
# 입력 코퍼스에 대해서 NLTK를 이용하여 문장 토큰화를 수행.

normalized_text = []
for string in sent_text:
     tokens = re.sub(r"[^a-z0-9]+", " ", string.lower())
     normalized_text.append(tokens)
# 각 문장에 대해서 구두점을 제거하고, 대문자를 소문자로 변환.

result = []
result = [word_tokenize(sentence) for sentence in normalized_text]
# 각 문장에 대해서 NLTK를 이용하여 단어 토큰화를 수행.

전처리 과정 후, 샘플의 수를 출력하면 다음과 같습니다.

print('총 샘플의 개수 : {}'.format(len(result)))

총 샘플의 개수 : 273424

전처리가 되었으니, 이제 Word2Vec을 통해 텍스트 데이터를 학습시켜줍니다.

Word2Vec 학습

Word2Vec 훈련에 앞서, gensim 모듈이 없다면 설치해줍니다.

$ pip install gensim

설치가 완료되었다면, 아래의 코드를 통해 아까 전처리한 데이터를 Word2Vec 모델로 학습시켜줍니다.

from gensim.models import Word2Vec, KeyedVectors
model = Word2Vec(sentences=result, vector_size=100, window=5, min_count=5, workers=4, sg=0)

여기서 Word2Vec의 하이퍼파라미터값은 다음과 같습니다.

vector_size = 워드 벡터의 특징 값. 즉, 임베딩 된 벡터의 차원.
window = 컨텍스트 윈도우 크기
min_count = 단어 최소 빈도 수 제한 (빈도가 적은 단어들은 학습하지 않는다.)
workers = 학습을 위한 프로세스 수
sg = 0은 CBOW, 1은 Skip-gram.

Word2Vec에 대해서 학습을 진행하였습니다. Word2Vec는 입력한 단어에 대해서 가장 유사한 단어들을 출력하는 model.wv.most_similar을 지원합니다.

earth와 유사한 단어는 어떤 것들이 있을까요?

model_result = model.wv.most_similar("earth")
print(model_result)

[('planet', 0.8294868469238281), 
('mars', 0.7876790165901184), 
('surface', 0.683158278465271), 
('sun', 0.6683340072631836), 
('ocean', 0.6607442498207092), 
('moon', 0.6605572700500488), 
('continent', 0.6459723711013794), 
('universe', 0.6119515895843506), 
('galaxy', 0.6062458753585815), 
('orbit', 0.6049789786338806)]

earth와 유사한 단어로 planet, mars, surface, sun 등 정말 그럴싸한 단어들을 내놓는 것을 볼 수 있었습니다.

모델 저장, 로드

이렇게 학습시킨 Word2Vec 모델은 저장해두었다가 나중에 다시 로드해서 사용할 수 있습니다.

model.wv.save_word2vec_format('./eng_w2v') # 모델 저장
loaded_model = KeyedVectors.load_word2vec_format("eng_w2v") # 모델 로드

위의 loaded_model은 앞선 예제의 model.wv 변수와 동일하게 사용하면 됩니다.

model_result = loaded_model.most_similar("earth")
print(model_result)

자연어 처리(NLP)의 전처리 - Word2Vec(워드투벡터)

Wed, 12 May 2021 00:00:00 GMT

Word2Vec(워드투벡터)

원-핫 인코딩에서 언급했듯, 원-핫 벡터와 같은 희소 표현(Sparce Representation)은 단어 간 의미의 유사도를 표현할 수 없습니다.

그래서 단어 간 의미의 유사도를 표현할 수 있도록 단어를 벡터화 할 수 있는 방법이 필요합니다.

이 방법을 분산 표현(Distributed Representation)이라 합니다. 그리고, 이를 위해 사용되는 가장 대표적인 방식이 Word2Vec이라 할 수 있습니다.

분산 표현(Distributed Representation)

분산 표현(distributed representation) 방법은 기본적으로 분포 가설(distributional hypothesis)이라는 가정 하에 만들어진 표현 방법입니다. 이 가정은 '비슷한 위치에서 등장하는 단어들은 비슷한 의미를 가진다'라는 가정입니다.

분산 표현은 분포 가설을 이용하여 단어들의 집합을 학습하고, 벡터에 단어의 의미를 여러 차원에 분산하여 표현합니다.

분산 표현으로 벡터화하게 되면, 원-핫 벡터처럼 벡터의 차원이 단어 집합의 크기와 같지 않아도 됩니다. 이에 따라 벡터의 차원은 원-핫 벡터로 표현할 때보다 상대적으로 줄어들게 됩니다.

분산 표현 학습 방법에는 NNLM, RNNLM 등이 있지만, 해당 방법들의 속도를 개선한 Word2Vec이 많이 쓰입니다.

CBOW(Continuous Bag of Words)

Word2Vec에는 CBOW와 Skip-Gram 두 가지 방법이 있습니다. CBOW는 주변에 있는 단어들을 가지고 중간에 있는 단어들을 예측하는 방법이고, 반대로 Skip-Gram은 중간에 있는 단어로 주변 단어들을 예측하는 방법입니다.

CBOW 방식의 예를 들면, 예문으로 "The fat cat sat on the mat"과 같은 문장이 있다고 할 때, {"The", "fat", "cat", "on", "the", "mat"}으로부터 sat을 예측해내는 것입니다. 이 때 예측해야하는 단어 sat을 중심 단어(center word)라고 하고, 예측에 사용되는 단어들을 주변 단어(context word)라고 합니다.

중심 단어를 예측하기 위해서 앞, 뒤로 몇 개의 단어를 볼지를 결정했다면 이 범위를 윈도우(window)라고 합니다. 예를 들어서 윈도우 크기가 2이고, 예측하고자 하는 중심 단어가 sat이라고 한다면 앞의 두 단어인 fat와 cat, 그리고 뒤의 두 단어인 on, the를 참고합니다. 윈도우 크기가 n이라고 한다면, 실제 중심 단어를 예측하기 위해 참고하려고 하는 주변 단어의 개수는 2n이 될 것입니다.

윈도우 크기를 정했다면, 윈도우를 계속 움직여서 주변 단어와 중심 단어 선택을 바꿔가며 학습을 위한 데이터 셋을 만들 수 있는데, 이 방법을 슬라이딩 윈도우(sliding window)라고 합니다.

위 그림에서 좌측의 중심 단어와 주변 단어의 변화는 윈도우 크기가 2일때, 슬라이딩 윈도우가 어떤 식으로 이루어지면서 데이터 셋을 만드는지 보여줍니다. 또한 Word2Vec에서 입력은 모두 원-핫 벡터가 되어야 하는데, 우측 그림은 중심 단어와 주변 단어를 어떻게 선택했을 때에 따라서 각각 어떤 원-핫 벡터가 되는지를 보여줍니다. 위 그림은 결국 CBOW를 위한 전체 데이터 셋을 보여주는 것입니다.

위는 크기가 $M$ 인 $v$ 벡터, 즉 투사층(Projection Layer)을 계산하는 과정입니다. 좌측의 입력층(Input Layer)에는 앞서 사용자가 정한 윈도우 크기 범위 내에 있는 주변 단어들의 원-핫 벡터들이 입력으로 주어지게 됩니다.

이 입력값들에 크기가 $V \times M$ ( $V$ : 입력에 사용된 원-핫 벡터의 크기, $M$ : 투사층 벡터 $v$ 의 크기)인 가중치(Weight) 행렬 $W_{V \times M}$ 을 각각 곱해서 모두 더한 뒤, 그 벡터에 window size에 2를 곱한 값을 나눈 벡터, 즉 평균인 $v$ 를 계산하게 됩니다.

이렇게 구한 벡터는 두번째 가중치 행렬 $W^ \prime _{M \times V}$ 와 곱해지게 됩니다. 여기에서 나온 결과값은 입력층에서 입력으로 받은 원-핫 벡터의 크기와 같아집니다.

이 벡터에 CBOW는 소프트맥스(softmax) 함수를 취하는데, 소프트맥스 함수로 인한 출력값은 0과 1사이의 실수로, 각 원소의 총 합은 1이 되는 상태로 바뀝니다. 이렇게 나온 벡터를 스코어 벡터(score vector)라고 합니다. 스코어 벡터의 각 차원 안에서의 값이 의미하는 것은 아래와 같습니다.

스코어 벡터의 j번째 인덱스가 가진 0과 1사이의 값은 j번째 단어가 중심 단어일 확률을 나타냅니다. 그리고 이 스코어 벡터는 우리가 실제로 값을 알고있는 벡터인 중심 단어 원-핫 벡터의 값에 가까워져야 합니다.

스코어 벡터를 $\hat{y}$ , 중심 단어를 $y$ 라고 했을 때, 이 두 벡터값의 오차를 줄이기위해 CBOW는 손실 함수(loss function)로 cross-entropy 함수를 사용합니다.

H(\hat{y}, y) = - \sum_{j=1}^{\left\vert V \right\vert} y_j \log(\hat{y_i})

cross-entropy 함수에 실제 중심 단어인 원-핫 벡터와 스코어 벡터를 입력값으로 넣은 수식은 위와 같습니다.

H(\hat{y}, y) = - y_i \log(\hat{y_i})

중심 단어가 원-핫 벡터라는 것을 감안하면, 식을 위처럼 쓸 수도 있습니다. ( $i$ 는 원-핫 벡터에서 0이 아닌 index)

만약 정확하게 예측한 경우, $\hat{y_i} = 1$ 이 되며, cross-entropy의 값은 $-1 \times \log(1) = 0$ 이 됩니다. 따라서 해당 식을 최소화하는 방향으로 학습해야 합니다.

이제 역전파(Back Propagation)를 수행하면 $W$ 와 $W^ \prime$ 이 학습이 되는데, 학습이 다 되었다면 $M$ 차원의 크기를 갖는 $W$ 의 행이나 $W^ \prime$ 의 열로부터 어떤 것을 임베딩 벡터로 사용할지를 결정하면 됩니다. 때로는 $W$ 와 $W^ \prime$ 의 평균치를 가지고 임베딩 벡터를 선택하기도 합니다.

Skip-gram

Skip-gram은 앞서 설명한 CBOW와 반대의 과정입니다. Skip-gram은 중심 단어를 보고, 어떤 주변 단어들이 올지 예측하기 위한 방법입니다.

위 사진과 같은 과정으로 이루어지며, 중심 단어 하나에 대해서만 입력을 받기 때문에, CBOW처럼 평균을 구하는 과정은 없습니다.

자연어 처리(NLP)의 전처리 - 워드 임베딩

Sun, 02 May 2021 00:00:00 GMT

희소 표현(Sparce Representation)

희소 표현이란 데이터가 희소하다는 의미입니다. 여기서 데이터란 '우리가 관심을 갖는, 의미있는 정보'정도로 해석할 수 있을 것 같습니다.

이해하기 쉽게 예를 들어 설명해봅시다.

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

...

위의 벡터들은 희소 벡터라고 할 수 있습니다. 우리가 알고싶어 하는 정보의 인덱스만 1로 표현되고, 나머지 원소들은 0으로 이루어진 벡터입니다. 따라서 실제 표현하는 데이터의 양은 희소(Sparse)하며, 데이터를 표현하지 않는 나머지는 모두 0으로 표현됩니다.

이와 같이 표현하는 것을 희소 표현이라고 합니다.

지난 원-핫 인코딩 게시물에서 배운 원-핫 인코딩을 통해 나온 원-핫 벡터 또한 희소 벡터입니다.

밀집 표현(Dense Representation)

밀집 표현(Dense Representation)은 희소 표현(Sparse Representation)과 반대대는 표현입니다. 희소 표현의 일종인 원-핫 인코딩에서는 벡터의 차원이 곧 단어 집합의 크기이고, 표현하고자 하는 단어의 인덱스의 값만 1이고 나머지는 모두 0인 ex) [0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0] 표현 방식이지만, 밀집 표현은 다릅니다.

만약 단어 집합의 크기가 10000이라 가정해본다면, 이를 원-핫 인코딩을 통해 희소 벡터(희소 표현을 통해 생성된 벡터)로 표현하게 되면 차원이 10000인 희소 벡터가 생성될 것입니다.

하지만 이를 밀집 표현으로 나타내고 사용자가 밀집 표현의 차원을 128로 설정했다면, 밀집 벡터(밀집 표현을 통해 생성된 벡터)의 차원은 128이 되며 벡터 안의 모든 값들은 실수가 됩니다.

이와 같이 단어를 밀집 벡터로 표현하는 과정을 워드 임베딩이라고 합니다.

워드 임베딩(Word Embedding)

워드 임베딩이란, 단어를 밀집 벡터(Dense Vector)의 형태로 표현하는 방법입니다. 또한 이 워드 임베딩 과정을 거쳐 나온 밀집 벡터의 이름을 임베딩 벡터(Embedding Vector)라고 합니다.

아래는 원-핫 벡터와 임베딩 벡터의 차이를 나타낸 표입니다.

	원-핫 벡터	임베딩 벡터
차원	고차원	저차원
다른 표현	희소 벡터의 일종	밀집 벡터의 일종
표현 방법	수동	훈련 데이터로부터 학습
값의 타입	0, 1	real number

자연어 처리(NLP)의 전처리 - 원-핫 인코딩

Sun, 25 Apr 2021 00:00:00 GMT

원-핫 인코딩(One-Hot Encoding)

지난 게시물인 정수 인코딩에서는 Vocabulary의 각 단어에 인덱스를 부여하는 정수 인코딩까지 마쳤습니다. 그리고 이후 원-핫 인코딩과 워드 임베딩을 통해 단어들을 벡터로 바꿔준다고 말미에 언급했었습니다. 이번 게시물은 그 중 "원-핫 인코딩(One-Hot Encoding)"에 대한 내용입니다.

원-핫 인코딩이란?

원-핫 인코딩이란, 단어 집합의 크기를 차원으로 하고 표현하고 싶은 단어의 인덱스에 1의 값을 부여하고, 다른 인덱스에는 0을 부여하는 단어의 벡터 표현 방식입니다. 이렇게 표현된 벡터의 이름이 원-핫 벡터(One-Hot Vector)입니다. 여기서 단어의 인덱스는 앞서 정수 인코딩을 통해 맵핑한 데이터를 기반으로 합니다.

예시로, "자연어 전처리 과정입니다." 라는 한글로 된 문장을 원-핫 벡터로 만드는 과정을 보겠습니다.

from konlpy.tag import Okt  
okt = Okt()  
token = okt.morphs("자연어 전처리 과정입니다.")  
print(token)

konlpy 모듈의 Okt 형태소 분석기를 통해 문장에 대해 토큰화를 수행하는 과정입니다.

이 과정에서 konlpy 모듈이 설치되지 않았다면 $pip install konlpy 명령어를 통해 설치해주시면 되고, 실행 과정에서 No JVM 오류가 발생한다면 JVM 설치를 진행해주시면 됩니다. 필자의 경우 도커 컨테이너 상에서 실습을 진행하고 있기에 $apt install default-jdk를 통해 설치를 진행했습니다. (각자의 운영체제 상황에 맞는 설치 방법으로 설치하시면 됩니다.)

실행 결과는 다음과 같습니다.

그리고 아래와 같이 각 토큰에 대해 인덱스를 부여해줍니다.

word2index = {}
for voca in token:
     if voca not in word2index.keys():
       word2index[voca] = len(word2index)
print(word2index)

결과는 다음과 같습니다.

def one_hot_encoding(word, word2index):
    one_hot_vector = [0]*(len(word2index))
    index = word2index[word]
    one_hot_vector[index] = 1
    return one_hot_vector

위는 토큰을 입력하면 그에 해당하는 원-핫 벡터를 반환해주는 one_hot_encoding함수입니다.

다음과 같이 토큰을 통해 함수를 호출하면, 원-핫 벡터를 얻을 수 있습니다.

one_hot_encoding("자연어",word2index)

함수에 "자연어" 라는 토큰을 입력으로 넣었더니, [1, 0, 0, 0, 0, 0] 이라는 원-핫 벡터를 리턴했습니다.

앞에서 "자연어" 토큰은 인덱스 0번으로 정수 인코딩이 되었으니, 해당하는 0번 인덱스만 1의 값을 갖는 원-핫 벡터가 나오게 됩니다.

원-핫 인코딩의 한계

원-핫 인코딩과 같은 표현 방식은, 단어의 수가 늘어날 수록 벡터의 크기가 점점 커진다는 단점이 있습니다. 단어 집합(Vocabulary)의 크기가 곧 원-핫 벡터의 차수이기 때문에, 단어의 수가 많으면 벡터를 저장하는데 리소스가 많이 필요할 뿐만 아니라 연산에서도 불리합니다.

또한, 원-핫 벡터는 단어의 유사도를 표현하지 못합니다. 원-핫 인코딩을 통해서는 ['오렌지', '사과', '개', '고양이'] 이와 같은 단어 집합이 있을 때, 원-핫 인코딩을 거치면 [1, 0, 0, 0], [0, 1, 0, 0], [0, 0, 1, 0], [0, 0, 0, 1] 의 4개의 벡터로 표현됩니다. 인간은 단어 집합을 보고 오렌지와 사과는 과일이며 개와 고양이는 동물이므로 서로 유사한 특징을 묶어낼 수 있지만, 원-핫 벡터로는 그런 내용들을 포함할 수 없습니다. 인간도 단어 집합을 모르는 상태에서 원-핫 벡터만 봐서는 무엇과 무엇이 서로 유사한지 전혀 알 수 없을 것입니다.

따라서 단어 간 유사도까지 표현할 수 있는 워드 임베딩 방식을 많이 채택합니다.

자연어 처리(NLP)의 전처리 - 정수 인코딩, 패딩

Thu, 15 Apr 2021 00:00:00 GMT

정수 인코딩

enumerate()는 순서가 있는 자료형(list, set, tuple, dictionary, string)을 입력으로 받아, 인덱스를 순차적으로 리턴해줍니다. 앞선 Vocabulary 게시물에서 만든 단어 집합을 가져와서 정수로 바꿔줍니다.

인덱스 0과 1은 다른 용도로 사용하기 위해 남겨두고, 나머지 인덱스인 2부터 차례대로 부여합니다.

word_to_index = {word[0] : index + 2 for index, word in enumerate(vocab)}
word_to_index['pad'] = 1
word_to_index['unk'] = 0

encoded = []
for line in tokenized: #입력 데이터에서 1줄씩 문장을 읽음
    temp = []
    for w in line: #각 줄에서 1개씩 글자를 읽음
    	try:
        	temp.append(word_to_index[w]) # 글자를 해당되는 정수로 변환
      	except KeyError: # 단어 집합에 없는 단어일 경우 unk로 대체된다.
        	temp.append(word_to_index['unk']) # unk의 인덱스로 변환

    encoded.append(temp)

print(encoded[:10]) # 10개 항목만 출력

출력 결과를 보면 다음과 같습니다.

이 결과에서 볼 수 있듯, 문장들의 길이는 다 다르며, 문장마다 배열의 길이가 다릅니다.

max_len = max(len(l) for l in encoded)
print('리뷰의 최대 길이 : %d' % max_len)
print('리뷰의 최소 길이 : %d' % min(len(l) for l in encoded))
print('리뷰의 평균 길이 : %f' % (sum(map(len, encoded))/len(encoded)))
plt.hist([len(s) for s in encoded], bins=50)
plt.xlabel('length of sample')
plt.ylabel('number of sample')
plt.show()

문장의 최대 길이는 63, 최소 길이는 1, 평균은 15.62로 균일하지 않음을 알 수 있습니다. 여기에서, 가장 긴 문장의 길이인 63으로 길이를 맞춰주어야 합니다. 이 때 필요한 것이 앞에서 본 pad 토큰입니다. 앞서, (정수 인코딩을 진행하며 0번 인덱스에는 unk, 1번 인덱스에는 pad을 할당했었습니다.) 길이가 63보다 짧은 문장의 남는 공간에 pad 토큰을 넣음으로써 길이를 맞춰줄 수 있습니다.

for line in encoded:
    if len(line) < max_len: # 현재 샘플이 정해준 길이보다 짧으면
        line += [word_to_index['pad']] * (max_len - len(line)) # 나머지는 전부 'pad' 토큰으로 채운다.

다시 결과를 출력해보겠습니다.

max_len = max(len(l) for l in encoded)
print('리뷰의 최대 길이 : %d' % max_len)
print('리뷰의 최소 길이 : %d' % min(len(l) for l in encoded))
print('리뷰의 평균 길이 : %f' % (sum(map(len, encoded))/len(encoded)))
plt.hist([len(s) for s in encoded], bins=50)
plt.xlabel('length of sample')
plt.ylabel('number of sample')
plt.show()

패딩을 통해 길이가 모두 63으로 통일된 것을 확인할 수 있습니다!

이렇게 만들어진 전처리의 결과물의 형태는 다음과 같습니다.

print(encoded[:3])

길이가 모두 63으로 맞춰졌으며, 빈 공간은 모두 1로 채워진 것을 직접 눈으로 확인해 보았습니다.

이제 단어들을 고유한 정수로 맵핑하였으니, 각 정수를 고유한 단어 벡터로 바꾸는 작업이 필요합니다. 이 작업을 임베딩(Embedding)이라고 합니다. 단어 벡터를 얻는 방법은 크게 원-핫 인코딩과 워드 임베딩이 있는데, 주로 워드 임베딩이 사용됩니다.

다음 게시물에서는 원-핫 인코딩은 무엇인지, 또 무슨 문제 때문에 주로 Word2Vec을 사용하는지에 대해 다루도록 하겠습니다.