minzzl

QUIC 톺아보기 (1)

minzzl — Mon, 10 Jul 2023 15:28:22 +0900

개요

졸업 논물을 위해 사전 논문들을 분석하던 중, 인터넷 서비스 향상을 위한 Google의 연구 개발 분석 이라는 논문을 가장 처음으로 읽게 되었습니다.

해당 논문을 읽고 저의 향후 논문에 도움을 줄 수 있을 것 같아 좋았던 단락이나,

떠오르는 자유로운 생각들을 기반으로, 질문에 답하는 형식으로 정리해보겠습니다.

본론

향후 논문에 도움이 될 만한 단락

" IETF(Internet Engineering Task Force)의 발표에 따르면 인터넷 트 래픽의 약 90% 이상이 TCP를 이용하여 전송되고 있다[2]. 하지만, 네트워크의 속도가 지속적으로 고속화 되는 반면에 기존의 TCP 혼잡 윈도우 크기 조절을 통한 패킷 전송방식은 네트워크 자원을 충분하게 활용 하지 못하는 것으로 밝혀지게 되었다 "

" 이후, Google은 인터넷 서비스 향상을 위해서 웹페이지 반응속도 개선을 전송계층에 서 처리하는 연구개발을 시작 "

" 이러한 매우 높은 시장점유율의 원인에는 여러가지가 있겠지만, Google의 인터넷 서비스 향상을 위한 다양한 연구개발이 중요한 역할을했을 것으로 판단된다. "

" SPDY의 궁극적인 목표는 HTTP/1.1의 성능 제한을 해결하여 웹페이지의 로딩 시간을 50%로 줄이는 것 이다. 이를 실현하기 위한 SPDY의 핵심 기술은 새 바이너리 프레이밍 계층을 도입하여 하나의 커넥션으로 동시에 여러개의 메시지를 주고 받을 수 있는 요청/응답의 다중화를 지원한다.

또한, 특정 자원의 수신이 늦어질 경우, 의존성 있는 자원도 렌더링이 늦어지는 문제가 발생할 수 있는데 이러한 문제를 해결하기 위 해 자원간 의존관계를 설정하는 우선순위 지정을 지 원하며, HTTP 특성상 헤더가 중복적으로 전송하는 경우가 많은데 여러 요청에 대해 중복값이 존재하는 경우 성능향상을 위한 헤더 압축을 지원함으로써 기 본TCP 연결을보다더효율적으로사용할수있도록 했다."

"파일을 읽고 쓰는 것보다 파일을 열고 닫는 것이 자원이 많이 드는 것처럼 네트워크 소켓을 열고 닫는 부분에 대해서도 비슷한 현상이 있다"

"TCP 연결 을 여는 것은 자원을 소비하기 때문에 근본적으로 성 능상의 제약을 발생시킨다. Google의 2011년 분석 결 과, 비록 그 당시에도 TCP 연결 횟수를 줄이고자 HTTP/1.1의 경우 영속적인 연결(Persistent Connection)을 위한 Keep-Alive 기법을 사용하고 있 었지만, 크롬에서 발생한 HTTP 연결의 33%정도가 여전히 새로운 TCP 연결을 요청하는, 즉 단기적 연결 을사용하고있는것으로나타났다. 또한 그 당시웹 브라우저는 서버당 연결 개수를 높여 빠르게 웹페이 지를 로딩하려고 하고 있었는데 이는 TCP 연결 재사 용을 제한하였다.

기존 TCP에서 전통적으 로 사용해 왔던 혼잡제어 알고리즘은 인터넷 사용자 가 갑자기 증가하거나 대규모 다운로드 및 업로드 등 네트워크 트래픽이 갑자기 발생하는 경우 패킷손실이 발생하면 자동적으로 네트워크 전송속도를 절반으로 줄여 혼잡제어를 수행하고 이를 통해 패킷손실을 방 지하게 된다.

반면, BBR 알고리즘은 여러 라우터에 걸쳐 쓰루풋과 트래픽 처리시간을 지 속적으로 체크한다. 즉, 손실될 패킷의 현재 위치와 이동 경로를 미리 예측하여 네트워크에 트래픽이 갑 자기 증가하더라도 전송 속도가 느려지는 것을 방지 할 수 있다. 이를 기반으로 패킷이 네트워크를 통해 전송되는데 걸리는 시간을 계산하고 네트워크가 감당할수있는 트래픽 전송 속도를 조절한다.

논문을 읽으면 들었던 궁금한점 그리고 답변

SPDY에 바이너리 프레이밍 계층을 도입했다고 되어있는데, 이게 왜 필요하고 어떤 역할을 하는가?

HTTP/2의 모든 성능 향상의 핵심은 새로운 바이너리 프레이밍 계층으로, HTTP 메시지가 캡슐화되어 클라이언트와 서버 간에 전송된다.

바이너리프레이밍계층 (출처: https://web.dev/performance-http2/)

이 때 "계층"은 소켓 인터페이스와 애플리케이션에 노출되는 상위 HTTP API 사이에 최적화된 새로운 인코딩 메커니즘을 도입하기 위한 설계 선택을 의미한다. 동사, 메서드, 헤더와 같은 HTTP 의미론은 영향을 받지 않지만 전송 중에 인코딩되는 방식이 달라졌다. 줄 바꿈으로 구분된 일반 텍스트 HTTP/1.x 프로토콜과 달리 모든 HTTP/2 통신은 더 작은 메시지와 프레임으로 나뉘며, 각 프레임은 바이너리 형식으로 인코딩된다.

따라서 클라이언트와 서버는 서로를 이해하기 위해 새로운 바이너리 인코딩 메커니즘을 사용해야 한다. HTTP/1.x 클라이언트는 HTTP/2 전용 서버를 이해할 수 없으며, 그 반대의 경우도 마찬가지이다. 다행히도 클라이언트와 서버가 우리를 대신해 필요한 모든 프레이밍 작업을 수행하기 때문에 애플리케이션은 이러한 모든 변경 사항을 인식하지 못한다.

새로운 바이너리 프레이밍 메커니즘의 도입으로 클라이언트와 서버 간에 데이터가 교환되는 방식이 변경되었다. 이 과정을 설명하기 위해 HTTP/2 용어에 대해 알아봅시다:

Stream : 하나 이상의 메시지를 전달할 수 있는 설정된 연결 내에서 바이트의 양방향 흐름.
Message : 논리적 요청 또는 응답 메시지에 매핑되는 프레임의 전체 시퀀스.
Frame : HTTP/2에서 가장 작은 통신 단위로, 프레임 헤더를 포함하며 최소한 프레임이 속한 스트림을 식별합니다.

이 용어들의 관계는 다음과 같이 요약할 수 있다:

모든 통신은 양방향 스트림을 얼마든지 전달할 수 있는 단일 TCP 연결을 통해 수행된다.
각 스트림에는 양방향 메시지를 전달하는 데 사용되는 고유 식별자와 선택적 우선순위 정보가 있다.
각 메시지는 하나 이상의 프레임으로 구성된 요청 또는 응답과 같은 논리적 HTTP 메시지.
프레임은 특정 유형의 데이터(예: HTTP 헤더, 메시지 페이로드 등)를 전달하는 가장 작은 통신 단위.

서로 다른 스트림의 프레임은 인터리빙된 후 각 프레임의 헤더에 내장된 스트림 식별자를 통해 재조합될 수 있다.

간단히 말해, HTTP/2는 HTTP 프로토콜 통신을 바이너리 인코딩된 프레임의 교환으로 분해한 다음 특정 스트림에 속한 메시지에 매핑하고, 이 모든 것이 단일 TCP 연결 내에서 다중화된다. 이는 HTTP/2 프로토콜이 제공하는 다른 모든 기능과 성능 최적화를 가능하게 하는 기반이다.

HTTP/1.x에서 클라이언트가 성능 향상을 위해 여러 개의 병렬 요청을 하려면 여러 개의 TCP 연결을 사용해야 한다. 이러한 동작은 연결당 한 번에 하나의 응답(응답 대기열)만 전달할 수 있도록 하는 HTTP/1.x 전달 모델의 직접적인 결과이다. 더 나쁜 것은 이로 인해 헤드오브라인 차단이 발생하고 기본 TCP 연결이 비효율적으로 사용된다는 점이다.

HTTP/2의 새로운 바이너리 프레이밍 계층은 이러한 제한을 없애고 클라이언트와 서버가 HTTP 메시지를 독립적인 프레임으로 분할하여 인터리빙한 다음 다른 쪽 끝에서 재조합할 수 있도록 함으로써 완전한 요청 및 응답 멀티플렉싱을 가능하게 한다.

기존의 HOL 문제는 패킷이 순서대로 처리되어야하기 때문에, 앞선 패킷의 지연이 일어나면 뒤의 패킷도 함께 지연이 일어나서 발생하는 문제이다. HTTP/2에서는 순서가 뒤바뀌어나 심지어 인터리빙될 수도 있기 때문에 이러한 HOLB가 없다.

위의 그림은 동일한 연결 내에서 전송 중인 여러 스트림을 캡처한 것이다. 클라이언트는 데이터 프레임(스트림 5)을 서버로 전송하고, 서버는 스트림 1과 3에 대해 인터리브된 프레임 시퀀스를 클라이언트로 전송한다. 결과적으로 3개의 병렬 스트림이 전송 중이다.

HTTP 메시지를 독립적인 프레임으로 분해하고 인터리빙한 다음 다른 쪽 끝에서 재조립하는 기능은 HTTP/2의 가장 중요한 개선 사항이다. 실제로 이 기능은 모든 웹 기술의 전체 스택에 걸쳐 수많은 성능상의 이점을 가져다주는 파급 효과를 가져온다.

HTTP/2의 새로운 바이너리 프레이밍 계층은 HTTP/1.x에서 발견된 헤드 오브 라인 차단 문제를 해결하고 요청과 응답의 병렬 처리 및 전달을 위해 다중 연결의 필요성을 없애줍니다. 그 결과 애플리케이션을 더 빠르고, 더 간단하고, 더 저렴하게 배포할 수 있다.

HTTP/1.1는 기본 적으로 하나의 연결(Connection)당 하나의 요청을 처리하도록설계되어있었다.이때문에동시전송이 불가능하고 요청과 응답이 순차적으로 이루어지다 보 니웹문서안에포함되어있는이미지,CSS,스크립 트등여러가지다양한자원를처리하려면요청할리 소스 개수에 비례해서 대기 시간(Latency)이 길어지게 되었다. HTTP1.1에서 하나의 연결당 하나의 요청을 처리하는문제를개선할수있는기법중파이프라이 닝(Pipelining)이 존재하는데 이것은 하나의 연결을 통 해서 다수개의 파일을 요청/응답 받을 수 있는 기법을 의미한다. 이 기법을 통해서 어느 정도의 성능 향상을 얻을 수 있었으나 큰 문제점이 발생하였는데 바로 HOL 차단(Head-of-line block)이며 속도 문제를 일으 키는 주요 원인이었다. HTTP/1.1의 HOL 차단 문제 는 HTTP/2가 TCP 상에서 멀티플렉싱을 허용함으로 써 문제를 해결했으며, 많은 HTTP 요청과 응답은 응 용 프로그램 프로토콜을 차단하지 않고 동시에 처리 될수있다.

-> 논문에 HTTP/2가 멀티플렉싱 문제를 허용함으로써 HOL 차단 문제를 해결하였다고 명시되어있다. 그러나 내가 알기로는 HTT/2에서 개선하지 못했고, 이후 QUIC에서 멀티플렉싱을 통해 HOL 차단 문제를 해결했다고 알고있음.

그렇다면 뭐가 맞을까?

HTTP/2는 여전히 TCP 수준에서 또 다른 종류의 HOL을 겪고 있다. TCP 스트림에서 하나의 패킷이 손실되면 모든 스트림이 해당 패킷이 다시 송수신될 때까지 대기하게 된다. 따라서 HTTP/2가 HOL 문제를 해결한 것은 맞지만 TCP를 기반으로 작동하기 때문에 HOLB 문제에서 완전히 벗아났다고 할 수 없다.

"파일을 읽고 쓰는 것보다 파일을 열고 닫는 것이 자원이 많이 드는 것처럼 네트워크 소켓을 열고 닫는 부분에 대해서도 비슷한 현상이 있다"

-> 논문에서 다음과 같이 언급했는데, 그렇다면 파일을 열고 닫는 것이 왜 자원이 많이 들까?

TCP에서의 3-Way Handshake 과정이 있기 때문이다.

전통적인 TCP에서는 3-way handshake (SYN, SYN-ACK, ACK) 과정이 완료되어야 송신자(클라이언트)와 수신자(서버)가 모두 실제 데이터 교환을 시작할 수 있다. 이러한 과정 때문에 대기 시간이 늘어나며 전반적인 웹페이지 로드 속도가 감소한다.

또한 TCP의 3-way handshake 방식은 연결할 때마다 이루어지기 때문에 송수신자 모두에게 부하를 준다. 따라서 TFO가 등장했다.

3-way handshake는 왜 필요할까?

클라이언트와 서버간의 신뢰할 수 있는 통신을 제공하도록 한다.

인터넷 초창기에는 인터넷프로토콜, 즉 IP 만이 인터넷 연결에 사용하는 유일한 프로토콜이었다. 그러나 IP는 메시지를 보내도 수신자가 메시지를 받은지의 여부를 확인할 수 없다는 것이었다.

이를 위해 TCP/IP가 확린되었고, 이는 보내는 모든 데이터가 수신자에게 도달하도록 보장한다. 데이터를 전송하기 전에 클라이언트와 서버에 3-way handshake라는 보안 연결을 제공함으로써 이 작업을 수행한다.

이러한 초기 상호작용은 안전한 연결을 만드는데 필수적이다. 이 단계에서 클라이언트와 서버는 수신 및 발신 데이터 패킷을 확인한다. 이러한 매개변수는 TCP 세그먼트 형태가된다.

사실 TCP/IP 연결에서 전송되는 모든 데이터는 TCP 세그먼트라고 하는 구간에서 잘라내어 구조화해야한다. 이러한 세그먼트에는 IP 주소, 포트, 플래그 비트, 시퀀스 번호, 승인번호, 선택적 데이터 또는 페이로드와 같은 정보가 포함된다.

처음 세번의 핸드셰그에서는 페이로드나 펌부 데이터가 없는 TCP 세그먼트 헤더만 포함이 된다.

TCP 세그먼트

위의 그림은 TCP에만 해당이된다. 전체 TCP/IP 세그먼트는 위의 TCP 세그먼트 위에 발신자와 수신자의 IP 주소가 모두 필요하다.

클라이언트가 서버와 통신할 때마다 양 당사자는 상호작용을 TCP 세그먼트 형식으로 형식화 해야한다. TCP 세그먼트는 전송하려는 데이터에 첨부된 TCP 세그먼트 헤드로 구성된다. 발신자는 세그먼트 헤드에 필요한 정보를 입력해야한다.

Source port : 발신자의 포트를 식별한다.
Destination port : 수신자의 포트를 식별한다.
Sequence number : 세그먼트 시퀀스를 나타냄
Acknowledgement Number : 주어진 시퀀스 번호에 1을 더하여 세그먼트가 승인되었음을 나타냄.
Flag bit : 총 6개가 있으며 핸드쉐이크에서는 다음 중 2개만 필요함.
- SYN: 시퀀스 번호를 제공한다. 이 시퀀스 번호는 나머지 상호작용에서 수신되는 모든 세그먼트 시퀀스를 계산하는데 사용됨
- ACK : SYN 번호의 수신자가 주어진 SYN 번호에 1을 더하여 연결 요청을 수락했음을 나타냄

이제 3 way handshake 과정을 알아보자.

이는 클라이언트와 호스트가 서로의 정보를 교환하고 시퀀스 번호를 확인하면 성립된다.

이름에서 알 수 있듯이 세단계로 이루어짐

먼저 클라이언트는 연결을 원하다는 순수 SYN 세그먼트를 보낸다.

그 다음으로 서버는 요청을 승인하고 클라이언트가 승인할 수 있도록 자체 SYN 번호를 전송한다는 의미의 SYN-ACK세그먼트로 응답한다.

마지막으로 클라이언트는 서버의 SYN 번호가 승인되었으며 향후 연결에 사용될 것임을 알리기 위해 서버에 ACK 세그먼트를 보낸다.

핸드셰이크 이후 클라이언트와 서버는 데이터 전송을 시작한다.

이렇듯 시퀀스 번호가 있는 이유는 세그먼트가 나중에 재조립될 때 순서를 알기위해서이다. 승인 번호는 발신자에게 세그먼트가 수신되었는지, 수신 세그먼트의 시퀀스와 일치하는지 확인하기 위한 것이다.

이렇듯 시퀀스 번호를 세그 확인하는 과정을 통해서 TCP가 누락된 데이터 없이 데이터를 안정적으로 전송할 수 있다.

그렇다면 왜 굳이 3-way handshake일까 ? 2번의 왕복으로는 부족할까?

이를 위해서 핸드 셰이크가 어떤 동작을 하는지 세분화해볼 필요가 있다.

TCP에서 두 당사자는 시퀀스 번호를 사용하여 전송한 내용을 추적한다. 사실상 시퀀스 번호는 전송된 모든 데이터의 실행 바이트 수가된다. 수신 당사자는 상대방의 시퀀스 번호를 사용하여 수신한 내용을 확인할 수 있다.

하지만 시퀀스 번호는 0에서 시작하는 것이 아니라 무작위로 선택된 값에서 시작된다. 그리고 TCP는 양방향 통신이기 때문에 양쪽 모두 말을 할 수 있다. 따라서 양쪽 모두 시퀀스 번호를 무작위로 생성해야한다. 즉 양쪽 모두 상대방에게 시작 무작위 번호를 알려야하기 때문에 3번의 handshake과정이 필요하다.

TFO란 무엇일까?

TFO은 3-way handshake 방식으로 발생하는 전송왕복시간(RTT) 및 지연의 한계를 극복하려는 노력으로 TCP SYN과정 중에 데이터를 담아서 전달함으로써 보다 빠르게 웹 컨텐츠를 전송하기 위한 기술이다. 다음과 같이 송신자가 SYN 패킷을 수신자에게 전송할 뿐만 아니라 쿠키 요청을 전송하기 때문에 정상적인 TCP 3-way handshake 가 발생하면서 작동한다. 송신자와 수신자 사이의 TFO 과정의 첫단계에서 송신자가 쿠키 요청과 함께 SYN 패킷을 보낸다. 그러면, 수신자는 요청된 쿠키를 생성한 후 쿠키와 함께 SYN-ACK를 송신자 에게 보낸다. 송신자가 특정 수신자의 IP에 대한 쿠키 를캐시한다. 송신자가수신자에의해생성된쿠키 를캐시했으므로그이후송수신자의TFO과정은다 음과같다.송신자가SYN,TFO쿠키및데이터가포 함 된 패킷을 보낸다. 그러면, 수신자는 TFO 쿠키의 유효성을 검사하고 응용 프로그램에서 데이터를 사용 할 수 있다. 수신자는 SYN-ACK을 되돌려 보내고 송 신자로더많은데이터패킷을계속전송한다. 그다 음 송신자가 수신자에게 ACK를 다시 보낸다. 이와 같은 과정이 완료되면 TCP가 정상적으로 계속되며 이를통해송신자가즉시데이터를전송할수있고통 신을더일찍시작할수있다.기존TCP의혼잡제어 (Congestion Control)는 따로 수정할 필요가 없으며 기존의 sendto, sendmsg와 같은 시스템 호출을 활용 하여 쉽게 쓸 수 있게 했다.

TCP fast open 과정

TFO 를 하는 특정 경우가 정해져 있는가?

이미 서로와 TCP 연결을 한적 있는 호스트와 클라이언트 사이는 다시 연결하고자 할 때 사용한다.

TFO는 TCP의 3 way handshake로 발생하는 RTT 및 Latency의 한계를 극복하려는 노력이다.

Handshake 할 때부터 컨텐츠를 담아 전달한다.

새로운 TCP 연결에 대한 요청은 Cold Request, 이미 연결된 TCP 연결에대한 요청을 Warm request 라고 정의한다.

새로운 연결(Cold Request) 하는데 Cost가 8~28% 더 든다.

TFO는 클라이언트와 서버 간에 한 번의 전체 RTT를 피하기 위한 전송 계층 솔루션이다. 반복 연결 시 TCP-3 방식의 핸드셰이크를 피할 수 있다.

일반적인 TCP 연결에서는 연결 설정에 한 번의 RTT가 낭비되고 세 번째 패킷부터 실제 통신이 시작된다. TFO에 따르면 클라이언트는 첫 번째 패킷 자체에서 1 RTT를 낭비하지 않고 GET 요청을 보낼 수 있다. 하지만 그렇게 하기 위한 몇 가지 조건이 있다:

(1) 새로운 연결이 아니어야함

TFO는 암호화 쿠키가 필요하기 때문에 반복 연결에서만 작동한다.

클라이언트가 서버와 처음으로 상호 작용할 때 3방향 핸드셰이크를 수행하며, 이 핸드셰이크에서 서버는 암호화 쿠키를 클라이언트와 공유한다.

이후에는 클라이언트가 SYN 패킷 자체의 GET 요청과 쿠키를 피기백합니다. 그런 다음 서버는 쿠키를 사용하여 클라이언트를 인증하고 연결 요청을 수락한 후 ACK 패킷에 데이터를 전송합니다

(2) SYN 패킷으로 피기백 된 데이터 총량은 1460바이트를 패킷에 피기백할 수 있음. 따라서 한 세그먼트의 크기는 1460B가 된다.

(3) 특정 유형의 HTTP 요청만 TFO를 사용하여 전송할 수 있음

GET 요청만 지원된다. TFO는 서버에 쓰기 작업을 허용하면 해커가 서버에 심각한 피해를 줄 수 있는 악의적인 활동을 수행할 수 있기 때문에 POST 요청을 지원하지 않는다.

* 다음의 글을 참고하여 작성했습니다.

https://web.dev/performance-http2/

https://www.makeuseof.com/what-is-three-way-handshake-how-does-it-work/

https://knight76.tistory.com/entry/%EA%B5%AC%EA%B8%80-TCP-Fast-Open-paper-TFO%EB%A5%BC-%EC%9D%BD%EA%B3%A0

Python / Set()

minzzl — Wed, 24 May 2023 16:07:55 +0900

안녕하세요!

오늘은 파이썬 set 에 대해 정리해보겠습니다 !

사실 지금껏 알고리즘 문제를 풀며 set()을 사용했던 경험은 별로 없는데요 ..

굳이 사용할 필요성을 못느꼈기 때문입니다 ㅎㅎㅎ ...

그런데 특정한 경우 set을 사용하면 연산이 빨라진다는 것을 확인했고 .. 그래서 이렇게 정리해보려고 합니다 !

x in s

제가 말한 특정한 경우는 x in s 연산입니다.

리스트에서 x in s 연산의 평균 시간 복잡도 : O(n)
세트에서 x in s 연산의 평균 시간 복잡도 : O(1)

이렇게 세트 연산에서 더욱 효율적인 이유는 무엇일까요?

파이썬의 set이 해시 테이블로 구현되어있기 때문입니다.

해시 테이블을 이해하려면 우선 해시 함수를 이해해야합니다.

해시 함수는 임의의 데이터를 인자로 받아, 특정 범위 내의 데이터로 반환하는 함수입니다. 이를 통해 반환된 데이터를 통해 해시 테이블에 데이터를 저장합니다. 해시 함수를 통해 해싱한 후 나온 결과값을 배열의 인덱스로 사용하여, 해당 위치에 데이터를 저장하는 방식입니다.

해시의 자세한 내용은 https://minzzl.tistory.com/56 을 참고해주세요.

따라서 어떤 값이 해시 테이블에 있는지 확인하려면, 해시 함수를 통해 나온 값을 이용해, 인덱스로 데이터에 접근하게 때문에 x in s 연산의 평균 시간 복잡도는 O(1)이 됩니다.

이와는 달리 리스트에서는 어떤 값이 리스트에 있는지 확인하려면, 리스트의 값을 일일이 확인해야합니다. 그렇기 때문에 O(N)의 연산이 걸리게됩니다.

그럼, set 사용법을 정리하고 이 글을 마치도록 하겠습니다.

해당 부분은 https://ctkim.tistory.com/entry/Python-%EC%9E%85%EB%AC%B8-%EA%B0%95%EC%A2%8C-12-%ED%8C%8C%EC%9D%B4%EC%8D%AC-%EC%A7%91%ED%95%A9Set-%EC%A0%95%EB%A6%AC-%EB%B0%8F-%EC%82%AC%EC%9A%A9%EB%B2%95 을 보고 작성했습니다!

파이썬 집합(set) 이란?

python 집합은 고유한 요소의 모음입니다. 집합의 목적은 단일 변수에 여러 항목을 저장하는 것입니다.

집합의 특징은 다음과 같습니다.

순서가 없다. (인덱스로 접근하지 못한다.)
중복은 허용되지 않는다.
요소는 변경 불가능한 자료형만 사용할 수 있다.

파이썬에서 집합 만들기

1. set 함수 사용

집합을 만드는 첫번째 방법은 set() 함수를 이용하는 방법입니다. 이 함수는 변경 가능한 자료형(list, dictionary, string)을 집합으로 변환할 수 있습니다. 아래 코드는 리스트를 집합으로 변환하는 예시입니다.

>>> set_example = set([1, 2, 3, 4, 5])
>>> print(set_example)
{1, 2, 3, 4, 5}

2. 집합에 직접 할당

변수에 값을 직접 할당하여 집합을 만들 수도 있습니다. 아래 코드는 정수를 집합으로 변환하는 예시입니다.

>>> set_example = {1, 2, 3, 4, 5}
>>> print(set_example)
{1, 2, 3, 4, 5}

집합의 요소 접근

1. 집합의 인덱싱

Python에서 집합은 순서가 지정되지 않습니다. 그래서 인덱스로 접근할 수 없습니다. 인덱스로 요소에 접근하려고 하면 TypeError가 발생합니다.

2. 반복문을 이용한 집합 요소 접근

집합의 요소는 반복문을 이용하여 접근할 수 있습니다. 아래 코드는 반복문을 이용해 집합의 모든 요소에 접근하는 예시입니다.

>>> set_example = {1, 2, 3, 4,5}
>>> for i in set_example:
>>> 	print(i)

3. in 연산자를 이용한 요소 확인

집합에 특정 요소가 있는지 in 연산자를 이용해서 확인할 수 있습니다. 아래 코드는 집합에 각 요소가 있는지 확인하는 코드로 값이 있다면 True를 반환하고 없다면 False값을 반환합니다.

>>> fruits = {"apple", "banana", "cherry"}
>>> print("apple" in fruits)
>>> print("grape" in fruits)
True
False

집합의 요소 추가

1. add() 메서드 사용

add() 메서드는 집합에 단일 요소를 추가하는데 사용할 수 있습니다. 아래 코드는 add() 메서드를 이용해 요소를 추가하는 예시입니다.

>>> set_example = {1, 2, 3, 4, 5}
>>> set_example.add(6)
>>> print(set_example)
{1, 2, 3, 4, 5, 6}

2. update() 메서드 사용

update() 메서드는 집합에 여러 요소를 추가하는 데 사용할 수 있습니다. 아래 코드는 update() 메서드를 이용해 리스트의 여러 요소를 집합에 추가하는 예시입니다.

>>> set_example = {1, 2, 3, 4, 5}
>>> set_example.update([6, 7, 8])
>>> print(set_example)
{1, 2, 3, 4, 5, 6, 7, 8}

집합의 요소 제거

1. remove() 메서드 사용

remove() 메서드는 집합에서 특정 요소를 제거하는데 사용할 수 있습니다. 요소가 집합에 없으면 keyError가 발생합니다. 아래 코드는 remove() 메서드를 이용해 요소를 제거하는 예시입니다.

>>> set_example = {1, 2, 3, 4, 5}
>>> set_example.remove(5)
>>> print(set_example)
{1, 2, 3, 4}

2. discard() 메서드 사용

discard() 메서드는 집합에서 특정 요소를 제거하는 데 사용할 수 있습니다. remove() 메소드와 달리, discard() 메소드는 요소가 세트에 존재하지 않는 경우 KeyTypeError를 발생하지 않습니다.

>>> set_example = {1, 2, 3, 4, 5}
>>> set_example.discard(6)
>>> print(set_example)
{1, 2, 3, 4, 5}

3. pop() 메서드 사용

pop() 메서드는 집합에서 임의의 요소를 제거하는데 사용할 수 있습니다. 아래 코드는 pop() 코드를 이용해서 임의의 요소를 제거하는 예시입니다. 이 때 맨 앞에 있는 요소가 계속해서 제거되는 것을 확인할 수 있습니다. 우리가 생각하기에 순서가 있는 것처럼 제거된다고 느낄 수 있지만 집합은 순서가 없기에 임의의 요소가 제거되는 것입니다.

>>> set_example = {1, 2, 3, 4, 5}
>>> set_example.pop()
>>> print(set_example)
{2, 3, 4, 5}

합집합, 교집합, 차집합, 대칭차집합

1. 합집합

두 집합의 합 집합은 두 집합의 모든 요소를 포함하는 집합입니다. 이는 union() 메서드 또는 '|' 연산자를 사용하여 수행할 수 있습니다 아래 코드는 union()을 통해 두 집합을 합치는 코드입니다. 이 때 집합은 중복된 요소가 있을 수 없기 때문에 4,5가 한개씩 있는 것을 확인 할 수 있습니다.

>>> set_a = {1, 2, 3, 4, 5}
>>> set_b = {4, 5, 6, 7, 8}
>>> set_c = set_a.union(set_b)
>>> print(set_c)
{1, 2, 3, 4, 5, 6, 7, 8}

>>> set_c = set_a | set_b
>>> print(set_c)
{1, 2, 3, 4, 5, 6, 7, 8}

2. 교집합

두 집합의 교집합은 두 집압에 공통인 요소만 포함하는 집합입니다. 이는 intersection() 메서드 또는 '&'연산자를 사용하여 달성할 수 있습니다.

>>> set_a = {1, 2, 3, 4, 5}
>>> set_b = {4, 5, 6, 7, 8}
>>> set_c = set_a.intersection(set_b)
>>> print(set_c)
{4, 5}

>>> set_c = set_a & set_b
>>> print(set_c)
{4, 5}

3. 차집합

두 집합의 차집합은 한 집합에는 있지만 다른 집합에는 없는 요소를 포함는 집합입니다. 이는 difference() 메소드 또는 `-` 연산자를 사용하여 달성할 수 있습니다.

>>> set_a = {1, 2, 3, 4, 5}
>>> set_b = {4, 5, 6, 7, 8}
>>> set_c = set_a.difference(set_b)
>>> print(set_c)
{1, 2, 3}

>>> set_c = set_a - set_b
>>> print(set_c)
{1, 2, 3}

4. 대칭차집합

두 집합의 대칭 차집합은 공통된 요소만 제외하고 모든 요소를 포함하는 집합입니다. 이는 symmetric_difference() 메서드 또는 `^` 연산자를 사용하여 달성할 수 있습니다.

>>> set_a = {1, 2, 3, 4, 5}
>>> set_b = {4, 5, 6, 7, 8}
>>> set_c = set_a.symmetric_difference(set_b)
>>> print(set_c)
{1, 2, 3, 6, 7, 8}

>>> set_c = set_a ^ set_b
>>> print(set_c)
{1, 2, 3, 6, 7, 8}

[후기] 경북대학교 입시홍보단 크누리

minzzl — Mon, 22 May 2023 17:29:02 +0900

안녕하세요!

개발 관련 후기만 작성하다가 기왕 적을거 했던 대외활동들을 다 적어야겠다는 생각이 들어 이렇게 글을 쓰게 되었습니다 :)

개요

활동 당시 찍었던 단체 사진입니다 !

( 혹시나 다른 분들의 신상이 알려져 피해가 가거나 의도치 않은 일이 일어날까 염려하여 모자이크 처리했습니다 ! )

사실은 이 글을 적기 전, 입시홍보단 크누리로 활동했던 것을 적어도 되는가에 대한 고민을 많이 했습니다.

아무래도 입시 홍보단 크누리가 경북대학교를 대표하는 활동이기 때문에, 혹시 누군가에게 피해가 가지는 않을까하는 생각으로 마음이 무거웠기 때문입니다.

그럼에도 불구하고 이렇게 글을 작성하는 것은 경북대학교 입학을 희망하거나, 입시 홍보단 크누리로서의 활동을 희망하는 분들에게 도움이 조금이 나마 도움이 되기를 바라기 때문입니다.

* 제가 써내려가는 글은 제가 활동 당시(2020년)를 바탕으로 작성한 것이며, 현재의 크누리 활동들과는 무관합니다. 추가적으로 주관적인 경험을 바탕으로 적은 것임을 밝힙니다.

경북대학교 입시홍보단 크누리

(경북대학교 입학처 크누리 소개 부분 인용)

먼저, 크누리 란 수험생의 가치를 세상(누리)에 알릴 수 있기를 바란다는 의미를 가진 말입니다. 크누리는 2019년 부터 활동을 시작하여 고교생의 눈높이에 맞춘 홍보 및 상담을 진행하고 있습니다. 입학과 관련된 홍보활동인 고교 방문 입학 설명회, 지역교육청 주관 대학 진학 박람회 등 각종 행사에 참여하여 고등학생들에게 도움을 주는 활동입니다.

지원 동기

누구나 한번쯤은 고등학교 시절, 대학 홍보대사에 대한 로망을 가져본다고 생각합니다.

저 또한 그런 학생들 중 한명이었습니다.

또한 사람 만나기를 좋아하고 많은 사람들 앞에 서서 발표하기를 부끄러워하지 않는 저의 남다른 성격이 홍보대사와 들어맞을 것이라고 생각했습니다.

그래서 경북대학교 입시 홍보대사 크누리의 모집 공고가 올라왔을 때, 지원을 망설이지 않았습니다.

왜 뽑혔다고 생각하나요?

사실 저는 크누리 1기를 지원했다가 떨어졌던 경험이 있었습니다. 1기 지원 당시 서류는 합격했지만 면접에서 떨어졌습니다.

떨어졌을 당시에는 낙담하기도 했지만, 그 경험이 2기 합격의 열쇠가 되었다고 생각합니다.

어떤 방식으로 면접이 진행될지, 또한 어떤 것을 중점적으로 물어보실지 알고 있었기 때문입니다.

그리고 1기 지원당시에는 막 대학에 입학한 새내기였던지라 .. 면접에 대해 무지했습니다.

그래서 그 흔한 자기소개도 제대로 준비해가지 않았습니다 ^^ 떨어질만 했었다고 생각합니다 .. ㅎㅎ

그래서 2기 때는, 1기 때의 절망감을 다시 느끼고 싶지 않았기에 면접 준비에 아주 힘을 썼었습니다. 1분 자기소개 때, 내가 왜 크누리로 활동하기에 알맞은 사람인지 충분히 PR하려고 애썼습니다. 지금껏 했던 경험(모교 방문단, 봉사 동아리 등)들을 바탕으로요!

약간의 면접 팁을 드리자면 그 당시 면접에서는 어떻게 입시를 준비했는지와 본인의 학과에 대해 얼마나 잘 알고 있는지에 대해 중점적으로 물어보셨습니다! 저의 경우 컴퓨터학부 학생이었기 때문에 컴퓨터학부의 심화 컴퓨터공학전공과 글로벌SW융합전공, 이 둘의 차이를 중점적으로 물어보셨습니다.

(현재 경북대학교 컴퓨터학부는 플랫폼소프트웨어전공데이터과학전공, 인공지능컴퓨팅전공,글로벌소프트웨어융합전공으로 나뉘어진답니다 .. ^^)

어떤 활동을 했나요?

고교 방문 입학 설명회

입시 시즌(여름 방학 즈음) 이 되면 크누리는 고교 방문 입학 설명회로 잦은 출장을 가게됩니다! 2020년 당시에는 코로나로 인해 제한되는 것이 많았기 때문에 대구•경북의 고등학교로만 출장을 갔습니다.

고교 방문 입학 설명회에서는 아래의 사진들처럼 고등학생들 대상으로 학생들의 눈높이에 맞춰 경북대학교에 대해서 홍보합니다.

참고로 발표 자료는 입학처에서 제공받았고 대본은 따로 없었습니다. 그래서 크누리들 각자의 경험에 빗대어 고등학생들에게 설명하게됩니다. 경북대학교 내에서 진행되는 다양한 학생 지원 프로그램(글로벌챌린저, 미국 썸머 캠프, 장학금 등)을 개인의 경험을 학생들에게 공유하며, 경북대학교를 홍보합니다.

지역교육청 주관 대학 진학 박람회

입시시즌에 진행되는 지역 교육청 주관 대학 진학 박람회에서 경북대학교 부스를 운영합니다.

학생 및 학부모님들이 경북대학교 부스에서 원활한 상담을 받을 수 있도록 안내를 도와드리기도 하고, 상담을 진행하기도 합니다.

참고로 크누리는 입시 홍보단 크누리 활동 전, 각 전형에 대한 입시 교육을 받는 수습 기간을 가지게 된답니다!

전화 상담 업무

앞서 크누리로 활동 전, 입시 관련 교육을 받는다라고 말씀을 드렸습니다.

이를 바탕으로 전화 상담 업무도 진행합니다.

입학처 홈페이지를 위한 사진 촬영

9월 쯔음에는 입학처 홈페이지에 등재될 사진 촬영도 합니다!

사진들은 입학처 홈페이지 곳곳에서 사용된답니다 ㅎㅎ 제 사진을 기준으로 보여드리고 싶은데 3년전이라 이미 내려가고 없네요 ㅜㅜ

그 당시 찍었던 사진들이라도 공유합니다!

여타 홍보와 관련된 그 밖의 활동 ..

(아래에 기재된 활동들은 크누리 활동과는 상관없는 홍보 활동들입니다!)

학교 홍보 영상 촬영

좋은 기회로 학교 홍보 영상 촬영을 하기도 했습니다.

해당 활동은 크누리로서 한 활동은 아니었지만 추가해보았습니다 !!!

https://www.youtube.com/watch?v=8CVML1v_s5Q&t=26s

합격 수기 공유

학생부 종합 전형을 어떻게 준비했는지에 대한 합격 수기를 공유하는 활동에 참가하기도 했었습니다.

https://ipsi1.knu.ac.kr/ipsi/board/guideVideo/detail.do?title=&ci=&pageNo=1&bbsNo=64013

KNU 경북대학교 입학정보

[학부모 입학 톡톡] 경대생이 말하는 전형별 지원전략 및 학교생활_학생부종합전형(일반) 컴퓨터학부 글로벌sw융합전공

ipsi1.knu.ac.kr

어떤 점을 배울 수 있었나요?

아래의 글은 제가 크누리 2기 활동을 마치고 작성했던 글입니다.

약 1년간, 크누리 활동은
저에게 다양한 경험들을 선물 해주었고 이를 통해 꽤 많은 것을 배울 수 있었답니다

학교의 대표가 되어 수 많은 사람 앞에서 나의 이야기를 하고, 듣는 이들에게 도움을 줄 수 있는 존재였다는 것은 다시는 해 볼 수 없을 값진 경험이었다고 생각해요 :)

사실 단복을 입고 활동할 수 있다는 로망에서 크누리 지원을 선택했지만,
그것 이상의 것들을 경험해 볼 수 있어서 정말 행복했어요!

크누리를 통해 무엇보다도 좋은 인연들을 만들 수 있는 기회가 많았어요!,
(크누리를 지원한 재 작년의 저를 칭찬해주고 싶네요 ㅎㅎ)
크누리 2기의 언니, 오빠, 동기들은 더욱 정이 가고 계속 보고 싶은 사람들이에요 :)
(신종원 선생님도 짱! )

또 크누리로 활동을 하며 전공에 소홀해지고 있는 것은 아닌가 하는 불안함이 들 때도 있었어요 .. !
그러나 직접 현장에서 경북대학교 컴퓨터학부를 희망하는 학생들은 만나 이야기 하는 과정 속에서
2019년 제가 입학 했을 때의 그 설렘을 다시끔 느끼게 되어 더욱 열심히 학업 임하는 계기가 되기도 했어요 :)

또 컴퓨터학부에 진학하여 가장 흥미로웠던 것이 사람들의 불편함이나 니즈를 잘 파악하고 이를 우리가 배운 전공 지식을 통해 그러한 불편함들을 해결하게끔 한다는 것이었는데요,

물론 입시에 관련된 불편함이나 니즈들에 초점이 맞추어져 있었긴 했지만, 크누리 활동을 하면서 다양한 사람들을 만나 뵙고 그 불편함을 조금이나마 덜어드리려 노력했던 것이 향후 전공과 관련된 커리어에서도 도움이 되지 않을까 하는 생각도 듭니다

그렇다면 3년이라는 흐른 지금, 다시 그 때를 떠올려보니 크누리로 활동하며 배운 점이 참 많은 것 같습니다.

가장 먼저 어떤 집단의 대표로서 가져야할 책임감과 의무를 배웠습니다. 크누리로 활동하며 말 한마디, 단어 하나에도 신중을 기하려 신경을 썼던 것이 기억납니다.

또 각종 행사에 참여하며 시간 약속의 중요성을 톡톡히 느끼기도 했습니다.

크누리로서의 1년은 정말 바빴기에 힘들기도 했지만 잘 이끌어주신 담당 선생님과 동료들이 있었기 때문에 잘 마무리할 수 있었다고 생각합니다.

혹 크누리 지원을 망설이는 분이라면, 지원을 적극 추천 해드리는 바입니다 !

그럼 읽어주셔서 감사합니다 :)

[후기] 공공데이터 활용 경진대회 , 휠체어 사용자의 외출 시 전반적인 편의를 돕기 위한 외출 보조 앱

minzzl — Thu, 18 May 2023 17:00:19 +0900

개요

안녕하세요!

부쩍 회고 카테고리에 올라오는 글이 많은 것 같죠?

종합프로젝트설계 회고 이후, 회고글을 적는게 너무 재미있어서 이제껏 제가 해왔던 프로젝트들을 기록하기로 했답니다 ~! 호호

저는 프로젝트를 할 때가 제일 신이 나는 것 같아요 ... 뭔가 아이디어를 기획하는 것도 너무 재밌고, 그걸 구현해내는 것도 좋아해요 !! 기회가 된다면,, 이 글을 읽는 누군가와도(?) 프로젝트를 진행해보았으면 하는 바램입니다 ~!

공공데이터 활용 경진대회

경북대학교 컴퓨터학부에서는 매학기마다 다양한 경진대회들이 개최됩니다. 공공데이터 활용 경진대회도 매 학기 개최되는 사업 중 하나입니다. 이 밖에도 해커톤, 여름 방학 인도 인턴, 지역연계형 창의 문제 해결 경진대회 등 아주 많은 대회가 개최되는데요, 해당 대회들에서는 제가 진행했던 프로젝트들을 기반으로 차차 소개하도록 하겠습니다 :)

팀구성

늘 그랬듯, 친했던 친구들과 팀을 이루게되었습니다.

주제.. 그리고 선택 이유

저희가 선택한 주제는 휠체어 사용자의 외출 시 전반적인 편의를 돕기 위한 외출 보조 앱였습니다.

제가 기획한 아이디어인데요, 그 당시 유튜브를 통해서 장애인의 일상을 보게될 일이 많았습니다.

사실 유튜버는 위라클을 통해 해당 서비스 기획을 하게되었다고도 할 수 있을 것 같습니다.

유튜버 위라클 님

https://www.youtube.com/@WERACLE

위라클 WERACLE

WE + MIRACLE = WERACLE 우리 모두에게 기적을!! 비즈니스 문의 : weraclefactory@gmail.com http://www.instagram.com/we_park

www.youtube.com

위라클님이 업로드하신 아래의 영상을 보고 대한민국에서 휠체어 사용자로서 겪는 불편함들을 알게되었고, 이와 관련하여 내가 도움이 될 수 있으면 참 좋을 것 같다는 생각을 했습니다. 그래서 이번 대회를 통해 서비스를 기획하게되었습니다.

https://www.youtube.com/watch?v=gGgLmX9bdKk

그래서 니가 한건 뭐니?

공유 공간 만들기

Notion

예전에 업로드 했던 SW중심대학 공동해커톤(https://minzzl.tistory.com/46) 이후로 프로젝트 할 때는 항상 노션 페이지를 만든답니다.

혹 아직 노션을 사용하지 않은 분들이라면 정말 강추합니다 ..

Github

사실 깃허브는 프로젝트를 하게되면 당연히 만든다고 생각해서, 지난 회고글에서 한번 도 언급한 적이 없었습니다.

그런데 ... 프로젝트 시에 깃허브를 사용하지 않는 사람?도 있다는걸 얼마전에 알게되었습니다 ..

그냥 zip 파일로 메일로 전송해서 프로젝트를 한다고 하던가요 ..

여튼 저는 프로젝트를 위한 Organizaion을 만들었습니다.

https://github.com/WheelEasyWorld

TG 건설

TG 건설 has 2 repositories available. Follow their code on GitHub.

github.com

Google 계정 만들기

공유 드라이브 및 Auth 기능을 위해 필요한 Google 팀계정도 따로 생성했습니다.

Figma

또한 UI 를 위한 공유공간을 생성했습니다.

아이디어 제시 및 서비스 기획

아래의 링크는 제가 아이디어 회의 전, 노션에 공유했던 내용을 가져온 것입니다.

https://gratis-shape-ac1.notion.site/5426836673b54c67b02fed6c7700119f

김민지

1. 아이디어 한줄소개 : 휠체어 사용자를 위한 외출 보조 앱? 웹?

gratis-shape-ac1.notion.site

해당 내용을 캡쳐해가며 어떻게 기획했는지 살펴보겠습니다.

우선 전반적인 서비스의 설명을 담았고, 또 서비스에서 요구될 기능들을 명시했습니다.

공공데이터를 기반으로하는 프로젝트인만큼, 어떤 공공데이터를 쓸 수 있는지에 대한 조사도 완료하여 삽입하였습니다.

또한 시중에 해당 아이디어와 유사한 서비스가 있는지 조사한 후, 이를 삽입하였습니다.

사실 유사 서비스는 제가 기획할 때, 가장 중요하게 생각하는 것입니다.

솔직히 아이디어가 완전히 신선할 수는 없기때문에, 기획을 할 때 기존의 서비스들과 어떤 차별점이 있는가를 마련하는 것이 가장 고려해야할 점이라고 생각하기 때문입니다.

제가 미리 조사한 자료들을 바탕으로 1차 회의 때, 팀원들과 함께 주제를 더욱 구체화 할 수 있었습니다.

UI를 통한 서비스의 가치 담기

아이디어 기획 시, 기존 서비스와의 차별성을 중요히 생각했다면, 그 이후 중요하게 생각한 것은 앱의 디자인이었습니다.

물론 개발자로서 사용자로 하여금 불편함을 최소화하는 안정성있는 서비스를 구현하는 것도 중요합니다.

그러나 이러한 경진대회에서 심사위원들에게 우리가 구현한 앱의 정당성을 호소하기에 가장 우선시 되는 것이 앱의 UI라고 생각했습니다.

그래서 기존의 서비스들을 분석하는 것으로 시작했습니다.

서비스 분석시에 중점적으로 보았던 것은 세가지입니다.

어떤 기능을 포함하는가?
왜 이 색을 메인 컬러로 정했을까?
왜 앱 내의 디자인을 이렇게 구성했을까?

기능과 관련한 부분은 본 프로젝트에 참고하기 위함이었습니다.

그 밖의 메인 컬러와 디자인은 해당 UI를 통해 사용자로 하여금 해당 서비스가 어떤 이미지로 다가가게끔 하였는가를 파악하기 위함이었습니다.

또한 분석 이후에는 공유 공간 아래에 저의 생각을 정리하여 두었습니다. 이는 회의 때 팀원들에게 보다 효과적으로 저의 의견을 공유하기 위함이었습니다.

아래의 링크는 그 당시 공유 공간에 작성했던 기존 서비스 분석내용입니다. (친구들이랑 하는 프로젝트다보니 .. 남사스럽게 적은 말들도 많습니다 .. 걸러서 봐주세욥)

https://gratis-shape-ac1.notion.site/22e4c44ad27f48528ed0d980484d8d0b

민지

기존 서비스 분석

gratis-shape-ac1.notion.site

챗봇 구현하기

그 당시 저희가 진행하고자 했던 기능 중 챗봇을 담당했습니다.

사실 챗봇을 맡게된 이유는 그냥 경험해본 적이 없어서였습니다.

다른 서비스들의 경우 구현을 해본적이 있었기에, 조금은 색 다른 도전을 하고자 챗봇을 담당하게되었습니다.

처음에는 단순한 채팅프로그램과 비슷하게 구현하면되지 않을까하는 생각으로 시작했습니다.

그런데 조사를 해보니 챗봇의 종류에는 트리형 챗봇, 추천형 챗봇, 시나리오형 챗봇 등 종류가 다양했고, 그에 따른 구현 방법도 천차만별이었습니다.

그래서 어떤 챗봇을 선택할 것인지 정하는 것이 우선이었습니다.

다양한 챗봇 종류 중 NLP를 기반으로 자연스럽게 대화할 수 있는 챗봇인 대화형 챗봇을 선택하게되었습니다. 이유를 꼽자면, 휠체어 사용자의 이동 중 편의를 보장 받을 수 있도록 하는 앱인데, 한정적인 서비스를 제공하는 트리형 챗봇이나 추천형 챗봇은 서비스를 이용하는데 답답함을 줄 것이라고 생각했기 때문입니다.

그 다음은 어떤 프레임 워크를 사용해서 챗봇을 개발할 것인지 선택해야했습니다.

찾아봤을 당시 선택권이 3가지 정도 있었는데,

1) IBM 왓슨

2) Chatfuel

3) Dialogfolw

였습니다.

그 중 IBM 왓슨은 유료였고, Chatfuel는 구현이 간단하지만 한글을 지원하지 않았습니다.

그래서 자연스럽게 구글의 Dialogflow를 선택하게되었습니다. 저희가 개발하고자했던 기능을 무료로 사용할 수 있었고 한글도 지원할 수 있다는 장점이 있었기 때문입니다.

여느 챗봇 서비스 구현과 마찬가지로 시나리오 작성은 물론,

다음과 같이 데이터 설계 및 엔티티 설계를 했습니다.

이후 Flutter의 dialog_flowt 를 이용하여 Flutter와 연동 시켜주었습니다.

https://github.com/Deimos-Applications/dialog_flowtter/blob/master/example/lib/main.dart

GitHub - Deimos-Applications/dialog_flowtter: A Flutter implementation of Google's Dialog Flow improved

A Flutter implementation of Google's Dialog Flow improved - GitHub - Deimos-Applications/dialog_flowtter: A Flutter implementation of Google's Dialog Flow improved

github.com

완성된 챗봇은 다음과 같습니다.

AI 챗봇 설계시 제가 공유공간에 작성했던 부분도 공유하겠습니다.

https://www.notion.so/AI-chat-bot-e4f48edf4375423a9faadb4e31556b06

AI chat-bot

Google dialog flow 사용하여 개발 중!

www.notion.so

마무리

기획부터 구현까지 재미있게 임했던 프로젝트였는데, 최우수상이라는 수상의 영광까지 안겨주어 아주 기뻤습니다.

프로젝트 시연영상인데요, 팀원이 아주 아주 열심히 만들었으니 봐주시면 감사하겠습니당 후하하

https://www.youtube.com/watch?v=zSTqAgyHb0E

사실 지금껏 회고를 올리는 프로젝트들이 적어도 1년도 전에 진행했던 프로젝트들이었습니다.

그래서 그 당시의 카카오톡이나 공유 드라이브, 노션들을 다시 읽으며 그 당시 기억을 떠올리며 글을 적었는데요,

그때 당시의 풋풋함이 떠올라서일까요 ... 왠지모르게 적다보면 기분이 좋아집니다 ㅎㅎ

또 회고를 하며 열심히 했던 내가 대견한 느낌이 들기도 하고, 그 때 이렇게 했더라면 하는 아쉬운 점도 짚고 넘어갈 수 있는 뜻깊은 시간인것 같습니다!

다음에 다른 회고로 돌아오겠습니다 !

그럼 안녕

[4] 컨테이너, 그리고 도커

minzzl — Mon, 15 May 2023 15:35:46 +0900

지난 포스팅에서 SaaS, IaaS, PaaS 에 대해 알아보았습니다.

그리고 IaaS와 PaaS를 비교하며 IaaS는 이식성이 좋지만 운영비 효율이 낮고, PaaS는 이식성이 낮지만 비용이 절감된다고도 언급을 했습니다.

그렇다면, IaaS의 장점인 이식성, PaaS의 장점인 운영비를 갖출 수는 없을까요?

바로 도커를 이용하면 가능합니다 !

우선 어떤 서비스를 배포하는 할 때를 살표봅시다.

쿠버네티스의 공식 문서에는 어플리케이션 배포 방법을 3가지로 나눕니다.

* 배포 관련한 부분은 해당 글은 이글을 읽고 작성한 것 입니다.

전통적 배포 , Traditional Deployment
가상화된 배포 , Virtualized Deployment
컨테이너 개발 , Container Deployment

전통적 배포 , Traditional Deployment

전통적인 방식의 배포란 쉽게, 물리적인 컴퓨터 한대에 하나의 OS를 깔고, 여러가지 프로그램을 설치하는 방식입니다.

전통적인 배포 시대에는 각 조직이 보유하고 있는 물리 서버에서 애플리케이션을 구동했어야합니다. 그렇기 때문에 간단히 물리 서버에 어플리케이션을 올려놓기만 하면 되는 방식이었습니다.

그러나 이에 단점도 존재합니다.

서비스 사용자에 따른 인프라의 탄력적인 확장이 불가능했고, 서로 격리되지 않은 애플리케이션들은 영향을 주고 받는 등과 같이 말이죠.

한 예시로, 구동 중인 어떤 어플리케이션이 리소스를 점점 많이 잡아먹더니, 서버의 한계 만큼 차지한 상황을 예로들 수 있습니다.

서비스의 수요 증가에 대응하기 위해서 리소스를 더 할당해줘야하는 것은 맞지만, 이로 인해 리소스를 더 요구하는 다른 어플리케이션이 영향을 받게 된다면 그 서비스는 장애가 발생할 것 입니다. 그러나 수요가 늘어난다고 다른 서비스에 할당될 리소스까지는 할당해줄 수 있습니다. 따라서 각 어플리케이션이 서로 격리되어야할 필요성과 리소스 할당에 한계를 두어야할 필요성이 대두되게 됩니다.

후에 발전한 가상화 기술은 전통적인 배포 시대 문제점들의 해결책이 되어줍니다.

가상화 배포, Virtualized Deployment

가상화를 도입하면서 하나의 물리적인 서버를 여러대의 논리적인 서버로 나누어 사용할 수 있게 되었습니다. 이렇게 나누어진 논리적인 서버는 가상 머신(VM, Virtual Machine)이라 불리며, 이 VM들은 서로 격리되어 각각 OS를 구동합니다.

가상화의 도입으로 시스템의 리소스를 하드웨어 레벨에서 나누어 각 VM에 할당할 수 있고, 전통적인 배포방식보다 더 효율적으로 리소스를 사용할 수 있게 되었습니다.

그러나 쿠버네티스 공식 사이트의 설명에 따르면 하드웨어 레벨 가상화의 VM들은 OS를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이므로 머신의 크기가 GB 단위가 넘어가며 너무나 크다는 단점이 있습니다. 이에 대한 해결책으로, 호스트 OS를 공유하여 조금 더 가벼운 격리 속성을 가진 컨테이너 기술이 등장합니다.

컨테이너 개발 , Container Deployment

컨테이너는 가벼운 VM이라고 생각하면 편한데, VM처럼 OS를 포함한 모든 종속성을 포함하는 것이 아닌, 동작할 애플리케이션의 종속성만 포함해 묶은 것이라고 할 수 있습니다. 즉 컨테이너란 우리가 구동하려는 어플리케이션을 실행 할 수 있는 환경까지 감써서, 어디서든 쉽게 실행 할 수 있도록 해주는 기술입니다.

이렇게 컨테이너를 이용함으로써 가볍고 빠르며 잘 격리된 환경에서 애플리케이션을 실행할 수 있게 되었습니다. 또한 컨테이너를 사용할 때 필요한 도구가 컨테이너 런타임입니다. 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구인데요, 종류도 여러가지가 있습니다. 그중 가장 유명한 것이 도커입니다.

도커, docker

도커는 컨테이너 기반의 오픈소스 가상화 플랫폼입니다.

다양한 프로그램들과 실행 환경을 컨테이너로 규격화시켜 프로그램의 배포관리를 단순화합니다. 프로그램의 코드뿐만아니라 실행에 필요한 모든 dependency들도 컨테이너에 담기 때문에 다른 환경에서도 빠르게 애플리케이션을 실행할 수 있습니다.

도커는 앞서 IaaS의 장점인 이식성, PaaS의 장점인 운영비가 저렴함을 갖춘 도구입니다. 기존의 종속적인 라이브러리 등의 설치 절차를 스크립트로 작성하기만 하고 배포 관련 사항을 도커스윔이나 쿠버네티스에 맞춰작성하기만 하면됩니다.

참고로 도커는 다음과 같은 과정을 거쳐 컨테이너를 만듭니다.

도커 파일이 빌드
도커 이미지 생성 및 실행
도커 컨테이너 실행

이 떄 도커 파일이란 컨테이너에 설치해야하는 패키지, 환경변수설정 등을 기록한 하나의 파일이며 도커 이미지는 도커가 도커 파일의 단계에 따라 컴퓨터의 상태를 스냅샷으로 저장한 것입니다. 도커가 이미지를 불러와 실행하면 컨테이너가 생성됩니다.

도커 등장 이후 많은 수의 애플리케이션들이 컨테이너화되어 배포되고 있습니다. 그러나 구글의 관점에서 볼 때 너무나도 많은 수의 컨테이너들이 배포되고 교체되어 관리의 복잡성이 증가하고 있었고 컨테이너 간 네트워크 또한 이 복잡성에 크게 영향을 주고 있었습니다. 이에 쿠버네티스가 개발 되고 이를 통해 여러 컨테이너들의 스케일링, 배포 등을 종합적으로 관리하기 시작했습니다.

해당 내용과 관련하여 잠깐 찾아보았는데 ...

깊이가 너무 깊네요 ...

오늘은 간단한 이해만 하기로하고 ~

물러가보겠습니다 :)

[후기] 종합프로젝트 설계2 , 내가 했던 프로젝트 중 가장 아픈 손가락?

minzzl — Sun, 14 May 2023 11:33:34 +0900

개요

안녕하세요,

어제 종합프로젝트 설계1의 회고를 마치고 나니 종합 프로젝트 설계2의 회고를 안하고 넘어갈 수 없더라구요 ...

사실 종합 프로젝트 설계 프로젝트도 2022년 3월에 했던 거라, 1년 전의 그 때를 찬찬히 되짚어봐야한답니다 .. ㅎㅎ

그래도 가장 기억에 남는게 있다면, 해당 프로젝트를 할 당시에는, 학부생으로서 마지막 프로젝트라는 생각으로 의지가 아주 활활 타 올랐던 것으로 기억이 납니다.

종합프로젝트설계2?

지난 포스팅에서도 잠깐 언급을 했었습니다만, 경북대학교 컴퓨터학부는 3학년 2학기에 종합프로젝트 설계1을, 4학년 1학기에 종합 프로젝트 설계2를 수강하도록 커리큘럼이 구성되어 있습니다.

뭔가 1,2 로 구성되어 있다보니 두 개의 과목이 연관성이 있지않느냐라는 의문을 품으실 수도 있을텐데요 ...

사실 전혀 연관성이 없답니다?

그냥 별개의 과목입니다 ..

또, 저는 컴퓨터학부의 전공 중 글로벌SW융합 전공이었는데(약간의 TMI ..?), 제 전공의 경우 종합프로젝트설계2가 필수 전공이 아니었기에 굳이 듣지 않는 친구들도 많았답니다 ..

그럼에도 불구하고 제가 해당 과목을 수강한 이유는, 종합프로젝트 설계1을 통해 많이 성장했다고 생각했기때문입니다.

저만 그런지는 모르겠지만 .. 해커톤이나 .. 여타 대회에 출전하여 프로젝트를 진행하다보면, 시간 상의 문제로 겉보기로만 작동 가능하도록(?) 구현을 한 적이 많았습니다. 또 시간상의 문제로 여타 예외처리는 그냥 무시한적도 빈번했구요. ㅎ

그래서 프로젝트가 용두사미가 된적이 많았습니다..

그런데 종합 프로젝트 설계과목을 들으며 그런 저의 모자란 부분에 개선이 되었다고 생각했습니다. "내가 구현하고 있는거, 해당 기업체의 사용자들이 쓸텐데 이러면 안되지" 하는 생각으로 말이죠 ..

그래서 조금 더 나은 개발자가 되고 싶은 마음에(?), 조금 더 성장하고자 해당 과목을 수강하게되었습니다.

팀구성

종합프로젝트 설계1을 함께 수강했던 친구들은 교환학생을 하러 ... 외국으로 갔기에 .. 다른 친구들과 팀 구성을 하게되었습니다.

저 포함 총 3명이 프로젝트 진행을 했습니다.

제가 처음에 제가 했던 프로젝트 중 가장 아픈 손가락이었다라고 언급을 했었는데 .. 그 이유가 여기에서 나온답니다 ..

함께 팀을 구성했던 친구들은 따로 종합 프로젝트 설계1을 수강하지 않아 프로젝트 경험이 거의 없었고, 졸업 준비로 한창 다들 바빴기에 .. 제가 Backend와 Frontend 부분을 도맡아 담당하는 대 참사가 일어납니다 ..

물론 다른 팀원들이 역할을 소홀히 했다거나의 의미라기 보다는 .. 저를 포함한 팀원이 할 수 있는 힘에 비해, 그냥 제 의지가 불타올랐고, 그를 다 이행하고자 스스로를 활활 태웠다고 생각합니다 ..

주제.. 그리고 선택 이유

그 당시 주어진 주제 목록은 다음과 같았습니다.

탄소중립을 위한 ESG 추천 AI 기반의 대화형 챗봇 개발
AR 증강현실을 활용한 가구 인테리어 시스템

Chatting application with WebRTC

deep-learning을 활용한 photomosaic 개발

BlackMagic 관리 서버 개발

IoT 생체신호 감지 모듈 개발

AI・AR을 활용한 관광지용 모바일 앱 개발

그 중 "deep-learning을 활용한 photomosaic 개발" 을 선택했습니다.

사진 이미지를 활용해 재미 요소를 가미한 서비스를 제공한다는 점에서 흥미를 느꼈기 때문입니다.

준비 과정

우선 빈즈 소프트라는 회사와 함께 프로젝트를 진행하게 되었습니다.

https://www.jobplanet.co.kr/companies/347106/reviews/%EB%B9%88%EC%A6%88%EC%86%8C%ED%94%84%ED%8A%B8

일 열심히 하면 다른건 터치 안함. 연차 사용을 자유롭게 할 수 있음.

일 열심히 하면 다른건 터치 안함. 연차 사용을 자유롭게 할 수 있음. (장점) 연차를 자유롭게 사용할 수 있다. 일 외에 다른건 신경 안써도 된다. (단점) 딱히 단점이라곤 잘 모르겠으나, 너무 일

www.jobplanet.co.kr

저희가 가장 처음 받았던 제안서는 아래와 같은데요,

지난 종합프로젝트 설계1에서는 기업체에서 요구하는 조건대로 프로젝트를 수행했다면, 빈즈 소프트 측에서는 아주 자유로운(?) 분위기로 프로젝트가 진행되었습니다.

기업체측의 요구 사항을 파악하기 위한 온라인 회의를 가졌었는데, 사실 주제를 제외하고는 특별히 요구하는 조건도 없었고, 회의 시에도 그냥 필요한 부분이 있으면 도와주겠다는 말씀을 남기셨습니다.

솔직히 저는 그러한 부분에서 긍정적인 입장은 아니었습니다. 왜냐하면, 우선 프로젝트를 완성도 있게 마무리해서 좋은 학점을 받고 싶은데, 프로젝트 완성도를 결정하는 기업체의 요구조건이 모호하다고 느꼈기 때문입니다. 또 기업체와의 활발한 커뮤니케이션을 원했기 때문입니다.

그 당시에는 서운하고 아쉬운 감이 많았지만, 지금 생각해보면 그 분들도 회사 업무 일로도 바쁠테고, 또 학부생에게 실제 회사에 직접적인 영향을 주는 서비스 개발을 맡긴다는 것은 서로에게 가중되는 부담이 클테니, 그랬지 않았을까하는 생각이 듭니다.

어찌되었건, 제가 그 당시 결정한 것은, 최대한 주제에서 이끌어 낼 수 있는 완성도 높은 서비스를 만들어보자는 것이었습니다.

제가 지난 종합프로젝트 설계1에서 개발을 Flutter로 진행한 적이 있었기에 이번에도 Flutter로 진행하게되었습니다.

또 기업체 측에서도 회의 당시 Flutter에 대한 언급을 해주셨기에, 팀원들도 호기심을 가지고 Flutter를 사용해보기로 결정했습니다.

저희가 수행 계획 부분에 발표 한 서비스의 기능들입니다.

저는 그 중 Photomosaic을 활용한 사진 생성의 Backend 부분과,

Photomosaic 공유, 그리고 사용자 History 관리의 전반적인 부분을 담당하게되었습니다.

조금은 여담으로 말을 덧붙여보자면 ..

저만 그런지는 모르겠으나, 프로젝트를 할 때, 항상 원하는 업무를 맡게 되지는 않는 것 같습니다.

어떤 때는 Frontend를, 또 어떤 때는 Backend 를 맡게 되기도 합니다. 그냥 어떤 서비스를 만들어낸다는 것 자체에 흥미가 있어 Frontend 든 Backend 든, 기회가 되는대로 일을 맡곤 합니다. 그런데 이렇게 Frontend와 Backend의 경계 없이 프로젝트에 뛰어들다보면 서비스의 전체적인 구조를 잘 이해할 수 있다는 점에서는 장점이 될 수도 있지만, 가끔은 스스로가 이도저도 아닌 것 같은 느낌이 들곤합니다. 그래서 이 부분이 가장 개선할 부분이라고 생각합니다. 하나의 프레임워크를 완전히 이해하기 !

그런데 달리 생각해보면, 이렇게 개발의 영역 구분없이 다 해보는거 학부 때 해보지 언제 해보겠어요 ~

라며 .. 위로하기 ^^

그래서 니가 한건 뭐니?

공유 공간을 만들자

우선 종합 프로젝트 설계1 수강 후 공유 공간의 중요성을 느끼게되었습니다.

수행 계획서를 작성하고, 발표 자료를 만들고, 최종 보고서를 작성하고 ... 각종 자료들을 공동 작업 한 후에는 항상 카카오톡으로 공유를 하곤 했었는데, 필요할 때 마다 대화방을 뒤지려니 꽤 비효율적이라고 느껴 공유 드라이브 공간을 생성했습니다.

1) 프로젝트용 드라이브 공간 만들기

또한 슬랙을 통해 업무보고를 하도록 했습니다.

카카오톡에 프로젝트 용 단체 채팅 방이 있었지만, 사적인 이야기와 업무적인 이야기가 구분되지 않았기 때문에 업무적인 내용 보고는 슬랙을 통해 보고하기로 결정했습니다.

2) 슬랙 이용하기

(지금은 기간이 만료되어 대화 내용이 안보이네요 .. ㅜ)

논문 .. 작성 ..

네.. 또 논문입니다.. 하하

개발을 진행하기 앞서, App의 주요 기술인 Photomosaic 기술을 분석함으로서 사용자에게 서비스 제공 극대화를 위해 노력했습니다. 특히 Photomosaic 기술의 성능에 영향을 주는 요인을 분석하고 평가했습니다.

포토모자이크 기술의 성능에 영향을 주는 요인을 분석하고 평가하기 위하여 알고리즘 종류, 데이터베이스를 구성하는 이미지의 개수를 변화시키며 생성되는 이미지를 비교했습니다. 또한 데이터 베이스를 구성하는 이미지에 따른 성능 비교의 경우, 단조로운 이미지와 복잡한 이미지 두 가지 경우의 원본 이미지 대비 생성되는 모자이크 이미지를 비교 분석하여 목표 이미지의 특성에 따른 결과를 확인했고,

데이터베이스 내의 소스 이미지의 개수가 많아질 수록 타깃 이미지의 각 셀마다 가지고 있는 고유한 값을 표현하기 위한 비교 가능한 셋이 많아지기 때문에 처리 시간이 증가하는 문제를 확인 할 수 있었습니다 ..

사실 뭐 그리 대단한 내용이 아니긴 하지만 , ㅎㅎ 해당 내용을 바탕으로 논문을 작성했습니다.

서버를 제공받을 수 없다면 만들자 !

서비스 시스템 아키텍쳐

서버는 기업체에서 제공 받고자 하였으나 기업체에서 물리 서버의 gpu를 사용 및 보안 상의 문제로 제공받지 못하였습니다. 이와 같은 문제를 해결하고자 처음에는 multipass에서 제공하는 가상 환경 및 docker를 이용해 서버를 구축하였습니다. 또한 향후에는 안정성을 위해 연구실에서 쓰지 않는 데스크톱을 제공 받아 포트 포워딩 등의 작업을 추가적으로 해주었습니다.

DB 부하를 고려하기

저희는 photomosaic 서비스를 제공하는 앱을 만들기로 결정했었습니다.

그래서 가장 먼저 걱정했던 것이, 이미지 관리를 위한 데이터 베이스를 어떻게 하면 좋을지에 대한 부분이었습니다.

흔히 많이 사용하는 MSSQL에 이미지 파일이 저장은 가능하나, 해당 서비스의 경우 대용량의 이미지 파일을 저장해야하기 때문에 DB 부하가 걱정되었기 때문입니다. 그래서 기업체에 해당 부분에 대한 조언을 구했고, 따로 이미지 파일 저장을 위해 사용중인 데이터 베이스가 없었기에, 무료로 사용가능한 Minio Object Storage를 사용하기로 결정했습니다.

참고로 이미지 객체는 Minio에 저장하고 이미지의 메타 데이터는 PostgreSQL을 사용했습니다.

Pixabay로 소스 이미지 Crawling

앞선 서비스를 위해서는 소스 이미지들이 대량으로 필요했습니다. 특히 저작권이 없는 대량의 이미지들이 필요했는데요, 이에 Pixabay를 사용하기로 결정했고, Pixabay에서 이미지를 Crawling 해오기 위한 코드도 작성했습니다.

사실 Pixabay에서는 이미지 크롤링을 위한 API가 존재합니다. 그런데 버전의 문제인지? 그 당시에는 작동하지 않았습니다.

그래서 Pixabay에서 제공하는 API를 일부 수정하여 키워드에 맞게 이미지를 Crawling 해오도록 하는 코드를 작성하였습니다.

해당 코드는 아래의 깃허브에 업로드 해두었습니다.

https://github.com/wlwl1011/Pixabay_Crawler_2

GitHub - wlwl1011/Pixabay_Crawler_2: Pixabay Crawler using pixabay api

Pixabay Crawler using pixabay api. Contribute to wlwl1011/Pixabay_Crawler_2 development by creating an account on GitHub.

github.com

처음 해보는 언어 Go...

Go를 선택한 것은 .. 연구실 선배의 역할이 컸습니다.

왜냐하면 현재 연구실에 있는 선배가 Go 장인이시거든요 ....

Photomosaic 생성 관련 된 서버는 아래 같이 작성했습니다. model 파일은 DB에 접근하는 실제적 코드를, router파일은 태스크별로 생성한 컨트롤러 연결 및 컨트롤러 초기화를, photomosaic.py는 Photomosaic 모델을 모듈화 한 것입니다.

우선 사용자가 Photomosaic 생성을 위한 동작 과정은 아래와 같으며 서버와의 통신이 필요한 부분은 붉은 색으로 표시했습니다.

참고로 .. 서버와 주고 받는 정보는 다음과 같았습니다.

App	Server
- uid : User ID - theme : source image theme - files : Photomosaic target image	- status : 생성 성공 여부

우선 UserID는 회원가입 시 FireBase 사용자 별로 고유로 부여되는 값이며, Theme은 사용자가 선택한 soure image의 주제입니다. 이 때 해당 주제에 따라 Target 이미지를 이루는 소스 이미지가 선택이 되며 주제는 총 6가지로 분류하였습니다. 해당 주제에 따라 저장된 이미지는 Pixavay에서 크롤링 해 온 값이며 Phomosaic 생성을 휘한 타깃 이미지는 file form 형태로 전송하였습니다.

커뮤니티

커뮤니티를 통한 사용자 간 교류 기능도 구현했습니다.

Flutter 앱에서 Stream을 사용하기 위해 StreamBuilder 위젯을 사용했고 이 때 StreamBuilder란 이벤트를 구독 가능하도록하여 매번 이벤트 전달 시 새롭게 리빌드 하여 최신 데이터를 반영 가능하도록 했습니다.

이 밖에 제가 구현한 것은 아니지만 SNS 로그인 및 카카오톡 공유하기 기능또한 구현했습니다.

가장 힘들었던 것

해당 프로젝트를 진행하며 가장 힘들었던 것은 팀원들과의 소통문제였습니다.

팀원 중 한 명이 모종의 이유로 잘 참여를 하지 않았습니다 ..

3월 17일에 만든 깃허브에 4월 28일까지 한 번도 코드를 올리지 않았었는데요 ...

사실 처음있는 일이라 어떻게 해야할지에 대한 감이 잡히지 않아 그 당시에 혼자 속을 태웠습니다.

또 그냥 화를 내서 서로 마음 상하기보다는 그냥 제가 그 일은 대신해서 하는게 마음 편하다고 생각했기에 프로젝트 동안에 이러한 일이 반복되곤 했습니다 ㅜㅜ

그래서 해당 프로젝트 후에 팀원 간의 소통에 대해 끊임없이 고민해오곤했는데, 지난 미국 샌프란 시스코에서 만난 에디님께 해결책을 얻었답니다!

PM을 하시는 분이셨는데, 팀원들에게 Positive Pressure을 하려고 한다고 하셨습니다. 단순히 일 얼마만큼 했니가 아니라, "나 정말 궁금해서 그런데, 일이 어디까지 진행이 됐어?? 혹시 도움이 필요한 건 있어?"라고 반복적으로 물으며, 어찌보면 무언의 압박일 수도 있으나 결론적으로 일을 효과적으로 시킬 수 있는 좋은 방법이라며 조언해주셨습니다 !

사실 해당 프로젝트 이후에 마주한 프로젝트들에서는 팀원들끼리의 합이 잘 맞아 일이 순조롭게 진행되어 아직 사용해본 적은 없지만, 나중에 기회가 된다면 꼭 써먹어봐야겠습니다 !!

마무리

저에게 주어진 분량도 많았고, 일도 순조롭게 진행되지는 않았어서 했던 프로젝트들 중 가장 마음이 아픈, 그런 프로젝트입니다 ..

그래도 이렇게 회고를 하니 한편으로는 홀가분한 기분이네용

프로젝트 코드는 아래에 있답니당 ~

https://github.com/wlwl1011/Photomosaic-DMM

GitHub - wlwl1011/Photomosaic-DMM: Deep learning을 활용한 Photomosaic 서비스 개발

Deep learning을 활용한 Photomosaic 서비스 개발. Contribute to wlwl1011/Photomosaic-DMM development by creating an account on GitHub.

github.com

긴 글 읽어주셔서 감사합니당

[3] 클라우드, SaaS, IaaS, Paas

minzzl — Sat, 13 May 2023 15:46:07 +0900

왕 !!! 오늘 해야 할 분을 해서 기뻐요 ~!

그렇다면 호기롭게 클라우드, SaaS, IaaS, Paas 에 대해 알아봅시당

사실 해당 단어들을 지난 공개개발자대회에서 들은 적이 있습니당 ! 그 당시에는 멘토님이 너희 서비스의 취지에 맞도록 결정해라라는 식으로 말씀해주셔서 그냥 그런 개념이 있다보다? 라고 생각했었습니다 .. 그런데 면접에 꽤나 질문이 나오는 건가보네요 ? .. 호호 -

그럼 뭐 ~ 알아가면 되는거죵 후하하

우리는 클라우드라는 개념을 익히 들어왔습니다.

깊게 접근하지 않더라도, 평소에 사용하는 아이클라우드, 삼성클라우드가 쉽게 접근할 수 있는 클라우드의 예가 아닐까 싶습니다.

이러한 클라우드를 간단히 정의해보자면, 나의 물리적 장비를 사용하지 않고 온라인 상으로 분산되어 존재하는 것을 의미합니다.

나의 휴대폰에 저장되어 있지 않더라도, 아이클라우드에 저장되어 있는 사진을 노트북으로 쉽게 다운 받을 수 있는 것 처럼 말이죠!

그럼 이제, 직관적인 클라우드의 개념이 아닌, 정확한 의미를 알아보겠습니다!

클라우드

클라우드란 인터넷을 통해 접근할 수 있는 서버, 그리고 그 안에서 구동되는 소프트웨어를 의미합니다.

즉 우리는 클라우드를 통해, 우리의 컴퓨터 장비를 사용하지 않고, 컴퓨터 장비를 구축해야할 작업을 온라인에 분산되어 존재하는 데이터 센터인 클라우드에 맡겨 수행할 수 있습니다.

출처 : https://www.cloudflare.com/ko-kr/learning/cloud/what-is-the-cloud/

이러한 클라우드를 통해서, 우리는 서버를 직접 구매할 필요도, 네트워크를 구축할 필요도, 그에 필요한 전력 소모를 걱정할 필요도 없게됩니다. 따라서 우리는 이를 통해 서비스에만 집중할 수 있습니다. 이러한 방식을 off-premise 방식이라고 합니다.

이와는 반대로 실제 서버를 구축할 수도 있습니다. 이를 on-premise 방식이라고 하는데요, 이는 카카오 데이터센터, 네이버 데이터 센터 등을 예로 들 수 있습니다.

우리가 이번 포스팅에서 집중할 것은 클라우드, 즉 off-premise 방식입니다.

클라우드 컴퓨팅의 대표적인 서비스 모델에는 SaaS, IaaS, PaaS 총 3가지가 있는데요, 이에 대해 알아보겠습니다.

출처 : https://www.cloudflare.com/ko-kr/learning/cloud/what-is-the-cloud/

SaaS (Software - as - a - Service)

이는 인터넷을 통해 소프트웨어를 제공하는 것입니다. 구글 드라이브, N드라이브, 구글 독스와 같은 완제품을 의미합니다.

인터넷을 통해 접근하기 때문에 On-premise 방식인 기존의 소프트웨어 전달 방식과는 다르게, SaaS는 개별 컴퓨터에 응용 프로그램을 다운로드하고 설치할 필요가 없습니다. SaaS를 통해 서비스를 공급하는 업체는 데이터, 미들웨어, 서버 및 스토리지와 같은 모든 잠재적인 기술적 문제를 관리하기 때문에 고객은 유지 보수 및 자원을 간소화할 수 있습니다.

PaaS (Platform - as - a - Service)

소프트웨어 개발을 돕는 플랫폼을 제공합니다. PaaS는 고객에게 OS, 미들웨어, 런타임과 같은 소프트웨어 작성을 플랫폼을 가상화하여 제공하고 관리합니다. 이 가상화된 플랫폼은 웹을 통해 제공되며 개발자는 운영체제, 소프트웨어 업데이트, 저장소 또는 인프라에 대한 관리없이 소프트웨어 개발에 집중할 수 있습니다. PaaS를 사용하면 기업에서는 특수 소프트웨어 구성 요소를 사용하여 PaaS에 내장된 응용프로그램을 설계하고 만들 수 있습니다.

IaaS (Infrastructure - as - a - Service)

이는 가상화된 물리적 자원을 UI 형태의 대시보드 또는 API로 제공합니다. IaaS의 고객들은 서버와 스토리지에 접근할 수 있지만 사실상 클라우드에 있는 가상 데이터 센터를 통해 리소스를 전달받는 형태입니다. IaaS의 제공업체는 서버, 하드 드라이브, 네트워킹, 가상화 및 스토리지를 관리하며 고객은 OS, 미들웨어, 애플리케이션 및 데이터와 같은 자원들을 관리해야 합니다. 따라서 PaaS에 비해 유지비용이 더 듭니다.

* 다음의 글을 기반으로 작성했습니다.

https://www.cloudflare.com/ko-kr/learning/cloud/what-is-the-cloud/

https://www.whatap.io/ko/blog/9/

[2] API

minzzl — Sat, 13 May 2023 14:55:59 +0900

안녕하세용

호기롭게 2일차에 놀아버려 .. 오늘 2,3일차를 몰아서 할 예정입니다 ~ ^^

괜찮아요 !

중요한건 꺽였는데도 그냥 하는 마음이자나요 ? ㅎ

API

API (Application Programming Interface)는 둘 이상의 컴퓨터 프로그램이 서로 통신하는 방법이자 컴퓨터 사이에 중계 계층을 의미합니다.

사실 이렇게 들으면 조금 어려운 감이 있습니다.

그래서 아래의 그림을 살펴보겠습니다.

두 대의 컴퓨터가 데이터를 주고 받을 때를 나타낸 그림입니다.

이 때에 각 컴퓨터는 HTTP, 혹은 HTTPS와 같이 어떤 프로토콜을 사용할지 결정해야합니다. 또한 Get 요청일지 Post 요청일지, XML 혹은 JSON 과 같이 어떤 데이터 교환 형식을 사용해야할지 정의되어져있어야합니다. 이러한 것들이 정의된 중계계층이 API입니다.

API는 Application Programming Interface 는 약자인데요,

여기 단어에서 Interface 에 집중해 볼 필요가 있습니다.

우리가 평소에 접하는 Interface는 어떤게 있을까요?

네, 어플리케이션을 사용할 때 User Interface를 접합니다!

우리는 해당 앱의 서버가 어떻게 구성되어있는지, 어떤 데이터 처리 방식에 의해서 로그인이 되는지는 모르지만 User Interface를 통해 우리가 사용하고 싶은대로 사용할 수 있습니다. 다시말해, 그 안의 세세한 구성원리는 모르더라도 Interface를 통해 서비스를 이용할 수 있습니다.

Application Programming Interface도 이와 마찬가지 입니다.

앞서 API란 서로 다른 소프트웨어가 서로 통신 할 수 있게 하는 메커니즘이라고 언급한 바 있습니다. 이러한 메커니즘을 통해 각자에게 필요한 서비스를 요청하고, 그에 따른 데이터나 기능을 제공할 수 있습니다. 또한 Interface 라는 용어에 걸맞게 내부 구성원리를 모르더라도 말이죠.

종류

API를 굳이 종류로 나누어보자면, 접근 방식에 따라 유형을 나눌 수 있습니다.

1) Private API

Private API는 내부 API로, 기업이나 연구 단체 등에서 자체 제품과 운영 개선을 위해 단체 내부에서만 사용하는 것과 같이 제 삼자에게 노출되지 않는 API를 의미합니다. 흔히 내부 서버간 통신에 이용되며 사용자는 이를 알지 못합니다.

2) Public API

Public API는 말 그대로 개방형 API이며 모두에게 공개 됩니다. Public API 중에서도 접속하는 대상에 대한 제약이 없는 경우를 OpenAPI라고 합니다. 그러나 모든 사람이 사용할 수 있기 때문에 많은 트래픽을 방지하기 위해 하루 요청수 제한, 계정 당 몇개 등으로 관리하기도 합니다.

카카오에서 제공하는 Open API

API의 장점

그렇다면 API를 사용하면 어떤 장점들이 있을까요?

데이터 접속의 표준화와 편의성

API는 모든 접속을 표준화 합니다. 그렇기 때문에 디바이스/운영체제 등과 상관없이 조건만 맞다면, 범용 플로그처럼 누구나 동일한 액세스를 약속합니다. 또한 조직에서 애플리케이션을 개발할 때, 기능적 API만 사용하면 필요한 기능들을 매번 개발/업데이트 할 필요없이 손 쉽게 사용할 수 있습니다.

자동화와 확장성

API를 통한 CRUD 처리에 따라 관련 데이터와 콘텐프가 자동으로 생성되고 사용자의 환경에 맞춰서 정보가 전달되어 개발 워크 플로우가 간소화되고 애플리케이션 확장이 용의합니다.

서비스의 중요한 부분을 드러내지 않아도된다.

예를들어 DB설계 구조나 드러내고 시지 않은 데이터 베이스의 테이블 정보, 서버의 상수값 등을 드러내지 않고 드러내고 싶은 부분만 드러낼 수 있습니다. 또한 사용자는 해당 서비스가 어떻게 구현되는지 알 필요없이 필요한 정보를 얻을 수 있습니다.

시간 절약 및 단축

OPEN API의 경우 앱 개발 프로세스를 단순화 시키고 시간과 비용을 절약할 수 있습니다.

API의 단점

API의 가장 큰 단점은 보안성입니다. 이는 API의 단일 진입점인 API 게이트웨이는 해커의 타겟 대상이 될 수 있기 때문입니다.

API는 단순히 HTTP 메서드를 사용하여 엑세스를 할 수 있는데, 이 때문에 다른 일반적 인터넷 기반 리소스와 마찬가지로 메시지 가로채기 공격 , CSRF 공격, XSS 공격 등에 취약합니다.

사실 API 는 매번 사용도 해왔고 그리 어려운 개념이 아닌데도, 누가 저한테 갑자기 API가 뭐야? 라고 물으면 당황할게 뻔했습니다 ..

이번 기회에 확실히 짚고 나니 한결 가벼운 마음입니다 ~

모두들 화이팅 합시당

* 다음의 글을 참고하여 작성했습니다.

https://www.hanl.tech/blog/api%EB%9E%80-api%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%EC%A2%85%EB%A5%98-%EC%9E%A5%EB%8B%A8%EC%A0%90/

[후기] 종합프로젝트 설계1 - 종프는 학점받는 외주 ?

minzzl — Fri, 12 May 2023 17:12:21 +0900

개요

안녕하세요. 오늘은 무려 2년전 프로젝트에 대한 회고를 해보려고합니다.

너무도 오래된 프로젝트라 기억이 날까 싶기도 하지만 ... 해당 프로젝트로 어떤 것을 배울 수 있었는지, 어떤 점이 바뀌었는지는 짚고 넘어가보고 싶어 이렇게 글을 쓰게되었습니다.

아무 것도 몰랐지만 열심히 했던, 뭘 위해 열심히 했는지도 모르겠지만 맹목적으로 열심히했던 그때가 왠지 그리워지는 요즘입니당 ㅜㅜ

요즘은 열심히 해야겠다는 마음이 들지만, 왜 이리도 막상 하려하면 하기가 싫어지는지 ...

그래서 풋풋했던 그 때를 기억하며 .. 마음을 다 잡아보고자 글을 적는 것도 있습니다 ... 하하하

종합프로젝트설계?

아마 컴퓨터공학을 전공하는 대부분의 학교에서는 4학년 과목으로 설계과목이 편성되어 있을 겁니다. 흔히들 캡스톤과목이라고 하나요?

제가 졸업한 학교의 경우 3학년 2학기에 종합프로젝트 설계1, 4학년 1학기에 종합프로젝트 설계2를 수강하도록 편성되어있었습니다.

사실 종합 프로젝트 설계1과 종합 프로젝트 설계2는 완전히 독립된 과목으로, 연관성은 없으나 ... 1,2로 분리해두어 뭔가 이어서 프로젝트를 진행해야할 것만 같은 혼란을 주기도 합니다 .;;

종합프로젝트설계는, 다른 설계과목과 마찬가지로 특정 서비스를 개발하는 과목이었습니다.

그러나 특별한 점이 있다면, 지역 기업체와 연계하여 프로젝트를 진행한다는 것이었습니다. 평소 프로젝트를 진행할 때에 팀원 간에 임의로 주제를 선정하곤 했었는데, 기업체가 원하는 서비스 개발을 한다는 점에서 참 신선한 과목이었다고 생각합니다.

또 한 학기 동안 기획에서 설계 구현까지 완료해야했고, 그 과정동안 기업체와 지도 교수님의 피드백을 받을 수 있었습니다. 중간 중간 기업체와 회의를 하기도 했고, 중간 발표, 최종발표를 통해 교수님께 피드백을 받으며 진행했습니다.

뭐 .. 이런 표현이 맞는지는 모르겠습니다만, 학점을 받는 외주를 하는 느낌이었습니다..

다른 팀들을 보니 기업체의 성격마다 진행과정이 다른 것 같긴 했으나, 저희와 함께한 기업체는 "확실히 원하는 요구사항"이 있으셨고, 그래서 회의도 다른 기업체들에 비해 빈번히 진행했습니다. 그 때 당시에는 회의를 자주해야한다는 점에서, 수정을 빈번히 해야한다는 점에서, 조금 귀찮다는 생각을 하기도 했었으나, 돌이켜 생각해보니 참 좋았다고 생각합니다. 현업에서 일하는 분과 학생의 관점은 다를 것이 자명하고, 또 얻을 수 있는게 현저히 많기 때문입니다. 아마 이 프로젝트를 계기로, 사용자에게 불편을 최소화하는 서비스를 구현하는 눈이 조금은 더 밝아졌다고 생각합니다.

팀구성

팀은 친한 동기들과 구성하였습니다.

총 4명의 인원이었고, Frontend와 Backend 각 2명씩 배정되어 프로젝트를 진행했습니다.

주제.. 그리고 선택 이유

그 당시 저희에게 주어졌던 기업체들의 프로젝트 제안 과제명은 다음과 같았습니다.

교통 체증 상황 전달을 위한 스마트 폰 스트리밍 응용 개발 및 통신 방법 연구
Person-owned Health Record 시스템 개발
실내 위치 정확도 최적화를 위한 자동 거리 교정을 사용한 가중 사각형 위치 알고리즘 개발/연구
인공지능 기반 장애인 주차표시 인식 시스템
시맨틱 검색을 위한 지식 임베딩 기반 하이브리드 인덱스 구조 개발
모바일 사용자를 위한 딥러닝 기반 적응형 비디오 스트리밍
실내에서 여러 카메라를 이용한 소수인원 트래킹
푸른들소프트 온라인 동영상 플랫폼 솔루션 개발
블록체인 기반 분산 신원증명 기술을 도입한 주차 관제 플랫폼 개발
생체 신호를 활용한 콘텐츠 서비스 기획 및 개발
모바일 단말기 보안 인증과 미디어 서버 컨트롤 앱 개발

저희가 선택한 주제는 "모바일 단발기 보안인증과 미디어서버 컨트롤 앱 개발" 이었습니다.

해당 주제를 선택한 이유는, 저희가 가진 개발 스택내에서 가장 완벽하게 구현해낼 수 있을것이라는 자신감이 있었기 때문입니다.

다른 주제들의 경우 너무 생소했기에, 처음으로 하나의 프로젝트로의 구현을 시작하는 학부생 입장으로서는 해당 주제가 저희에게 가장 알맞다고 생각했습니다.

준비 과정

조은캠프라는 회사가 참여했고, 조은 캠프에서 제시한 주제에 맞추어 프로젝트를 진행했습니다.

https://www.saramin.co.kr/zf_user/company-info/view/csn/L3VQVklKMDRlN0Z5WEJxaTdYTlNlUT09/company_nm/(%EC%A3%BC)%EC%A1%B0%EC%9D%80%EC%BA%A0%ED%94%84

(주)조은캠프 2023년 기업정보 | 사원수, 회사소개, 근무환경, 복리후생 등 - 사람인

(주)조은캠프의 사원수, 연봉, 채용, 재무정보, 복리후생 등이 궁금하시다면, 사람인에서 더 많은 정보를 확인해보세요.

www.saramin.co.kr

아래 사진은 저희가 주제 선정 당시 받은 제안서 입니다.

주제 선정 이후, 회사 대표님을 만나뵙고 회의를 가졌습니다. 최종적으로 해당 기업체에서 저희에게 요구한 것은, 본인의 회사에 이미 사용자에게 제공되는 웹사이트가 있으니 이를 앱으로 접근이 가능하도록 앱을 만들어줬으면 좋겠다는 것이었습니다. 특히 안드로이드 및 IOS에서도 작동이 가능하도록 했으면 좋겠다고 말씀하셨습니다. 또한 조은 캠프의 경우 온라인 강의를 제공해주는 기업체인데, 아이디 공유 등의 부정한 방법으로 콘텐츠를 사용하는 사용자가 없도록 모바일 단말기 인증 시스템을 구축해달라고도 하셨습니다.

해당 요구에 맞추어 크로스 개발 프레임 워크인 Flutter를 이용해 웹/앱 에서 모두 사용가능하도록 제작할 것을 목표로 하였습니다.

또한 모바일 단말기 인증 시스템 구축을 위해 UUID를 통해 사용자를 식별하고 서버로 전공하여 인증하는 방식을 통해 해킹/부정 수강 행위를 방지하는 것을 계획했습니다.

저희가 크게 수행하고자 했던 목표를 정리하면 위와 같았습니다.

(최종 발표 PPT에 있던거 훔쳐왔어요 ㅎ)

아래의 그림은 실제 저희가 썼던 개발 프레임 워크입니다.

서버는 기업에서 제공했기에 기업체에서 제공하는 ASP와 SQL을 기반으로 진행했고, Client 단은 Flutter를 통해 프로젝트를 진행했습니다.

그래서 니가 한건 뭐니?

논문 작성 및 제출

네 ... 논문도 썼답니다 ...

수행 계획에 있었던 부정 시청 방지를 위한 설계 기법을 기반으로 논문을 작성했습니다. 사실 종합프로젝트 설계 과목에서 논문 제출은 필수는 아니었지만, 프로젝트의 실적을 증빙하는데에는 도움이 된다고 생각했기에 추진하게되었습니다.

(사진에 스티커 말고 모자이크 하고 싶은데 .. 모자이크만 하면 사진이 사라지네요 .. ㅜㅜ)

해당 논문에는 온라인 강의 시장의 증가와, 문제점들을 제시한 후 사용자 인증에 필요한 설계 방법을 제안하였습니다.

기기 등록 과정 및 동시 시청 방지 과정 (논문 삽입)

그리고 운이 좋게도 .. 상도 받았답니다 ..?

이거 다주는건가요 ???

UUID 를 이용한 사용자 인증 시스템 구축

논문 작성 후에는 본격적인 개발로 돌입했습니다.

그 중 저는 UUID 관련 부분을 맡았습니다. 참고로 UUID란 다음과 같습니다.

기기고유값인 IMEI가 있지만, 이는 보안상의 문제로 현재 사용하고 있지 않기에 저희는 개인 정보 사용에 대한 문제도 해결하고, 고유 기기를 인식 할 수 있는 UUID를 활용하기로 했습니다. 이 값을 통하여 개별 기기를 인식 할 수 있었습니다.

특히 로그인 시에 UUID 관련 플로우를 추가할 예정이었기에 그에 수반되는 모든 기능을 구현해야했습니다. 늦은감이 있는 듯 하지만, 저는 프론트엔드 부분을 맡았기에 Flutter를 기반으로 진행했습니다.

참고로 동시시청 방지 전에 이러한 기기 등록 과정을 별도로 두는 이유는, 기기 등록을 2대의 기기로 제한함으로써 동시 시청을 미연에 방지하는 효과를 두고자했기 때문입니다.

정리해보면, 제가 맡은 부분은 크게 2가지 였습니다.

로그인 기능 구현
OTP 인증 구현

이렇게 보면 작아보이지만 ... ㅜㅜ

Flutter도 처음인데다가 프로젝트 관련 경험이 없으니 처음부터 끝까지 다 찾아봐야했습니다.

그 당시에는 할 일이 어찌나 많던지 ... 그 때를 생각하면 약간의 우울감도 느껴지는 것 같습니다 ㅜㅜ

로그인 기능 구현

아래의 사진은 로그인 기능개발과 관련한 UI입니다.

로그인 기능 UI

사실 로그인의 경우 특별한 Auth 를 사용하지 않고 서버에 바로 통신을 날린터라 크게 어려움은 없었습니다.

OTP 인증 기능

그러나 로그인 이후에는 기기등록과정이 있었습니다.

이는 UUID를 이용하여 사용자가 로그인을 시도 할 때 해당 기기가 등록되어있는 기기인지 확인하고, 등록되지 않은 기기라면 기기 등록 과정을 수행하도록 하였습니다.

이 때 기기 등록 방법은 현재 기기의 UUID를 읽어온 후, 사용자가 회원가입 시 저장해놓은 휴대전화를 통해 서버와의 인증 절차를 거치도록 합니다. 해당 사용자가 실제 유저가 맞다는 것을 확인 한 후에 기기의 UUID를 데이터베이스에 저장이 되도록 하였습니다.

사용자 인증 UI

참고로 문자 전송을 위해서는 Firebase 문자 전송 기능을 사용했습니다. 사실 이부분이 가장 어려웠습니다.

우리 서버의 DB에 있는 회원이 맞는지 인증을 하기 위해, DB에 저장된 핸드폰 번호로 문자 인증을 해오는 과정이 필요했는데, 해당 프로젝트를 할 당시(2021년 3월)에는 Flutter가 아주 따끈 따끈한 프레임 워크 였기 때문에 문자 전송 서비스와 연동되지 않았습니다 ..

연동은 되었을 수 있으나, 문자 전송 서비스 업체에서 Flutter에 대한 가이드라인은 없었습니다 ㅜㅜ

그래서 제가 수 많은 구글링 중에 채택을 했던 방식은 FirebaseAuth를 사용하는 것이었습니다.

이를 위해 로그인 시 Firebase에도, 기업체에서 제공하는 웹서버에도 통신을 진행하습니다 .. 즉 문자 전송을 위해서 Firebase를 별도로 쓰는 ... 그런 방법을 채택한 것입니다 ㅜㅜ

지금 와서 생각해보니 기업체에서 제공하는 웹 서버 말고, 그냥 Auth를 썼더라면 .. 이라는 생각과 또 지금 개발을 했더라면 다른 문자 인증 서비스를 쓸 수 있어서 이런 복잡한 작업을 거치지 않아도 될 텐데..(네이버 클라우드 문자 서비스)라는 생각이 듭니다 ....

그리고 만약 사용자가 새로운 기기로 로그인을 시도할 때 이미 2개 이상의 기기가 등록되어 있는 경우, 사용자가 기존에 등록된 기기들 중 삭제할 기기를 선택할 수도 있도록하였습니다. 이때 기존에 등록된 기기들은 서버와의 통신을 통해 전달받았습니다.

그런데 프로젝트를 진행하면서 다소 아쉬운 점을 발견했습니다.

이는 업체에서 제공하는 웹서버가 HTTP로 통신을 제공한다는 것이었습니다. 사실 완벽한 서비스를 구현한다는 입장에서 HTTP를 기반으로 통신을 할 경우, 손해가 되는 점이 너무 많았기에 해당 부분을 개선하고 싶다는 생각이 들었습니다.

특히 HTTP는 사용자 정보가 평문(plaintext)로 전송되기 때문에 타인이 통신 내용을 볼 수 있기 때문에, 보안상으로 큰 문제를 일으킬 수도 있기 때문입니다.

따라서 프로젝트 진행 도중 웹 서버에 TLS 기반의 HTTPS를 도입하여 보안을 강화하기로 했습니다.

이를 위해 인증 기관에서 SSL 인증서를 발급받아 직접 설정해주는 과정을 거쳤습니다.

사실 순조롭게 인증서를 설치해주었던 것은 아닙니다.. 제공 받은 서버와의 호환에 문제가 있었기 때문입니다.

2020년 상반기부터 TLS 1.0및 1.1 보안 프로토콜에 대한 지원이 공식적으로 종료 되었습니다. 하지만 저희가 제공 받았던 서버는 Window Server 2008 R2 로 기본 설정 프로토콜이 TLS 1.0으로 되어 있습니다. 따라서 TLS 1.2 버전을 기본 사용하기 위하여 별도의 설정이 필요했습니다. 이를 통해 HTTPS는 클라이언트와 서버가 서로 인증을 하기 때문에 악의적인 사용자의 개입을 차단할 수 있는 효과를 기대할 수 있었습니다.

이 뿐만 아니라 중복 시청 방지를 위해 현재 해당 아이디로 강의를 수강 중인 기기가 있는지에 대한 데이터 관리를 했습니다. 이를 위해 Class 및 데이터 베이스 테이블을 생성했고, 지속적으로 통신을 통해 이를 관리해주었습니다. 다만 해당 부분은 제가 전적으로 맡은 부분이 아니기에 간단하게 짚고만 넘어가겠습니다.

아래의 사진과 같이 사용자가 강의 재생 버튼을 클릭하면 서버 측에서 미디어 재생 관련 데이터와 현재 시청 중인 기기가 있는지에 대한 정보를 받고 다음과 같은 과정으로 미디어를 실행하였습니다. 이미 기존에 다른 기기로 강의를 시청 중이었다면, 기기 변경 여부를 묻고 사용자가 원한다면 플레이어를 실행하도록 했습니다.

마무리

아래에 삽입한 기대효과 및 활용방안의 최종 발표를 위해 구구절절히 작성한 것입니다 ..

아까우니 한번만 읽고 가주세요 ..

사실 이 때까지만 해도, 언제 git push를 날려야할지, 언제 commit을 해야할지 조차 모르는 상태였습니다.

그래서 보시면 알겠지만 (wlwl1011 이 접니다) 추가된 코드 수에 안맞게 commit이 매우 적습니다 ...

git 사용도 능숙하지 않았기에 삽질을 많이한 기억도 있네요 ...

처음으로 진심을 다했던 프로젝트라 그런지, 지금 보면 별로 형편없는 코드지만, 엄청 애정이 갑니다.

그래서 은근슬쩍 ... 여기에 두고 가겠습니다 :)

https://github.com/thing-zoo/edutopik

GitHub - thing-zoo/edutopik: 2021-2 산학협력 프로젝트 | 모바일 단말기 보안인증과 미디어서버 컨트롤

2021-2 산학협력 프로젝트 | 모바일 단말기 보안인증과 미디어서버 컨트롤 앱 개발. Contribute to thing-zoo/edutopik development by creating an account on GitHub.

github.com

말의 서두에서 해당 프로젝트로 어떤 것을 배울 수 있었는지, 어떤 점이 바뀌었는지는 짚고 넘어가보고 싶어 이렇게 글을 쓰게되었다고 언급했었습니다.

그렇다면 어떤 점을 배울 수 있었고 바뀌었는지 찬찬히 짚어볼까합니다.

우선 실제 사용자가 있는 서비스를 만든게 처음이었기에 엄청 공을 들여 개발을 했습니다. 그래서 예외 처리에도 굉장히 신경을 썼구요. 이런 부분이 제가 프로젝트를 임하는 태도와, 실력 향상에 큰 도움을 주었다고 생각합니다. 실제 사용자가 있다는 것이 프로젝트를 임하는데에 있어 큰 책임감을 주었던 것 같습니다.

또 깃허브를 사용하는 방법에 대해 공부하게 되었습니다.

기존에도 깃허브를 사용하기는 했으나, 사실 보여주기 용으로만 존재했습니다. 그저 토이 프로젝트를 전시하는 용으로 깃허브를 두었었다면, 해당 프로젝트 이후에는 팀원과의 협업을 위해 깃허브를 사용하는 방법을 익히려고 노력했습니다.

따로 말을 하지 않더라도, 깃 커밋만 보고 현재 내가 어디까지 개발을 했는지, 개발시 어떤 에러 사항이 있었는지에 대해 보고 하기 위해서 말이죠.

또 Fronted와 Backend 가 하는 일에 대해 차이를 극명하게 느낄 수 있는 계기가 되었습니다.

기존에 프로젝트를 진행하다보면, 그냥 Front 단에서 처리 할 수 있는 일이라서 행동을 자처 할 때가 많았는데, 해당 프로젝트를 하면서 그 때에 했던 것들이 Back에서 처리해줘야할 일들이구나 라는 것을 알 수 있는 계기가 되었습니다.

그리고 문서정리의 중요함도 알게되었습니다.

프로젝트 완료 후, 해당 기업체에서는 개발자 문서를 써줄 것을 요청해왔습니다. 사실 처음 개발자 문서를 써달라고 요청을 받았을 때는 막막했던 것이 사실입니다. 처음 해보는 일이었으니까요 ..

해당 과제를 처음 접한 개발자도 이해 가도록, 정말 A-Z까지 상세히 기록했습니다.

좋은 팀원들과 함께해 합이 아주 잘 맞았던 프로젝트였던 것 같습니다.

언제 또 기회가 되면 또 좋은 프로젝트로 만났으면 하는 바램입니당

모두 화이팅

[1] 데이터 포맷 - JSON / XML

minzzl — Thu, 11 May 2023 14:41:10 +0900

안녕하세용

저는 취업 준비를 슬슬 시작해볼까합니다 ....

그래서 이렇게 하는게 맞는지는 모르겠어나 .. 코테 공부와 CS 공부를 병행해볼까합니다 !

어떻게 공부를 해볼까하다가 .. 뭔가 가이드라인이 있으면 좋을 것 같아 책을 사보았습니다.

이 책을 토대로 공부하고, 네트워크, 데이터 베이스, 알고리즘과 같이 본격적인 전공 공부로 들어갔을 때 마주 할 부족한 내용은 KMOOK로 채워볼 생각입니당!

근데 하루에 얼마나 해야할지에 대한 감이 안 잡혀 좀 애를 먹었는데요 ...

사실 전전긍긍해봤자 답은 없는 것 같아 우선 천천히 시작하며 부족하다 싶으면 양을 늘리는 방식으로 진행할 것 입니다!

오늘은 데이터 포맷에 대한 내용을 배웠습니다 :)

우선 우리는 "데이터" 와는 단어와 아주 친숙합니다. 이를 개발의 관점에서 바라본다면 어떻게 정의할 수 있을까요?

데이터

데이터란 이론을 세우는데 기초가 되는 사실. 또는 바탕이 되는 자료나 관찰이나 실험, 조사로 얻은 자료 등을 의미합니다.

너무 어렵고 딱딱해보이죠?

우리는 서비스를 개발할 때, 데이터를 근간으로합니다.

예를 들어 교통 정보 시스템을 구현한다고 합시다. 각 지역의 교통 정보를 수집하여, 이를 지도에 나타낸다고 할 때, 우리가 수집한 이 교통 정보 "데이터"는 서비스의 기초가 됩니다. 그렇게에 우리는 데이터에 주목할 필요가 있습니다.

또한 이러한 데이터를 나타내는 형식은 아주 다양합니다.

출처 : http://nationalatlas.ngii.go.kr/pages/page_320.php

다음과 같이 표로 나타낼 수도, 그렇지 않을 수도 있습니다.

즉 데이터를 나타낼 수 있는 방법은 무궁무진합니다.

우리는 이렇듯, 표현방법이 무궁무진한 데이터를 기반으로 서비스를 구축하고 나아가 컴퓨터간 통신이 가능하도록해야합니다.

그렇게 떄문에 이러한 데이터들을 주고받을 때의 양식을 규제할 필요가 있습니다. 즉, 어떻게 표현할지 약속을 할 필요가 있습니다!

대표적으로는 JSON과 XML이 있습니다!

이들은 일반적으로 서버에서 클라이언트로 데이터를 보낼때 사용되는 파일언어이며, 요즘은 JSON을 사용하는 추세입니다.

먼저 JSON부터 살펴보겠습니다 :)

JSON

JSON(Javascript Objet Notation) 은 Javascript 객체 문법으로 구조화된 데이터를 표현하기 위한 표준 포멧입니다. 여기서 javascript 객체 문법으로 구조화되었다는 것은 javascript 객체 문법을 따르는 문자열이라는 것입니다.

다시말해, JSON은 javascript의 undefined를 제외한 기본 데이터 타입인 문자열, 숫자, 배열, 불리언, 그리고 다른 객체를 포함할 수 있습니다.

저의 정보를 JSON 양식으로 표현해보겠습니다.

{
	"이름" : "김민지",
    "키우는애완동물이름" : "밀크",
    "취미" : ["수영","플라잉요가"]
}

다음과 같이 우리는 key : value 형태로 나타낼 수 있는 것도 확인 할 수 있습니다 ! 다만 JSON은 순수한 데이터 포맷이기 때문에 key - value 만 담을 수 있을뿐 메서드는 담을 수 없습니다! 그리고 undefined도 불가능합니다.

그 다음은 XML입니다!

XML

출처 : https://opensource.com/article/18/12/xml-browser

XML(Extensible Markup Language) 는 위의 그림과 같이 중괄호가 아니라 열린 태그 닫힌 태그로 이루어진 구조의 데이터를 의미합니다. 우리가 흔히 알고 있는 HTML과 매우 유사한 마크업 언어입니다. 그러나 HTML이 div body와 같이 정해진 tag가 있는 반면에, XML은 기본 제공이름이 없습니다.

제일 위에 보이는 버전 및 인코딩 방법에 대한 것은 프롤로그라고합니다.

참고로 JSON과 비교했을 때, XML의 경우 열린태그와 닫힌태그를 모두 써야하므로 글자수가 더 많이 듭니다. 따라서 XML이 JSON에 비해 무겁습니다.

공통점	차이점
1. 데이터를 저장하고 전달하기 위해 만들어짐 2. 기계뿐만 아니라 사람도 쉽게 읽을 수 있음 3. 계층적인 데이터 구조 4. 다양한 프로그래밍 언어에 의해 파싱 될 수 있음 5. XMLHttpRequest 객체를 이용하여 서버로 부터 데이터를 전송받을 수 있음	1. JSON은 종료 태그를 사용하지 않음 2. JSON 구문이 XML의 구문보다 더 짧음 3. JSON 데이터가 XML 데이터보다 더 빨리 읽고 쓸 수 있음 4. XML은 배열을 사용할 수 없지만, JSON은 배열을 사용할 수 있음 5. XML은 XML 파서로 파싱되며, JSON은 자바스크립트 표준함수인 eval() 함수로 파싱됨