챗봇을 위한 대화는 어떻게 디자인할까

엔지니어 게시판
[엔지니어 게시판 글쓰기 사용 방법]

[code]
게시글을 쓰실때 여기에 소스코드를 넣어주시면 코드가 깔끔하게 정리되어 보여집니다 :)
[/code]

챗봇을 위한 대화는 어떻게 디자인할까

Support 0 2,264 2020.12.15 23:06

대화의 형태

좋은 대화형 서비스를 위해서는 좋은 디자인의 대화 시나리오가 필요하다. 이를 위해서 대화의 형태를 조금 더 자세히 살펴볼 필요가 있다. 예를 들어 식당 예약 시나리오가 있다고 가정하고 아래와 같은 대화가 있다고 해보자.

image-20201123-173901-318.png

그림 1 식당 예약 대화 예시

그림 1에서 왼쪽은 실제 사용자, 오른쪽은 AI 에이전트, 즉 시스템이다. 식당 예약과 같이 뚜렷한 목적이 있는 대화 시나리오를 우리는 태스크 지향 다이얼로그(task oriented dialog, TOD)라고 부르며 이는 목적 없이 자유롭게 자신의 생각을 소통하는 칫챗 다이얼로그(chit-chat dialog)와 상반된다. 위 그림의 대화는 사용자가 식당 예약이라는 목적을 이루기 위해 시스템과 탁구를 치듯 서로 대화를 주고 받는 형태이다. 우리는 사용자가 목적에 도달하는 과정까지의 대화를 최대한 부드럽고 자연스럽게 사용자가 원하는 형태로 설계할 필요가 있다.

image-20201123-173913-549.png

그림 2 사용자 대화를 분류별로 묶어본 결과

사용자가 어떤 말을 할 때 그 말에는 여러 의도와 정보가 담긴다. 예를 들어 "여보세요? 오늘 5시 쯤으로 7명 예약 하려고 하는데, 거기 영업하지요?"라는 문장에서는 "오늘", "5시", "7명", "예약"이라는 정보가 있으며 이 문장은 예약을 위한 단락과 영업을 하는지 묻는 FAQ 성격의 대화가 섞여 있다. 여기서 주의할 점은 일반적으로 사용자는 기계와는 다르게 하나의 문장에 여러 요청을 담아서 말하거나 질문하는 경우가 빈번하게 일어난다는 점이다. 매끄러운 대화 시나리오 구성을 위해서는 사용자가 말한 문장 속에 존재하는 여러 의도와 정보를 찾고 최대한 짧은 구간에 사용자의 모든 요청이나 질의를 처리할 수 있도록 디자인해야 한다.

image-20201123-173924-845.png

그림 3 Happy Path와 여러 장애 상황

또한 사용자는 사람이기 때문에 대화를 하는 도중 여러 장애(failure) 상황이 발생할 수 있다는 것을 염두에 두어야 한다. 예를 들어 사용자가 식당 예약을 잘 진행하고 있다가 갑자기 식당에 가는 길을 묻는 등 갑작스럽게 대화 주제를 변경하는 상황이나 사용자가 더 이상 말을 하지 않고 가만히 있는 무응답 상황 등이 있을 수 있다. 따라서 대화 시나리오 설계에서는 갑작스럽게 발생할 수 있는 여러 장애 상황을 고칠 수 있는 리페어 처리를 구상해야 한다.

대화의 구성 요소

대화 시나리오를 설계하려면 먼저 대화를 이루는 여러 가지 구성 요소를 이해해야 한다. 대화 시나리오라는 것은 여러 가지 대화의 구성 요소를 조합하여 사용자의 목적에 도달할 수 있도록 대화 흐름을 디자인하는 것으로, 구성 요소 각각의 형태와 특징을 알아둬야 매끄러운 대화를 설계할 수 있다.

image-20201123-173938-295.png

그림 4 사용자 발화

그림 4의 각 말풍선은 사용자가 말한 문장으로 우리는 이런 문장을 발화(utterance)라고 부른다. 발화는 대화를 이루는 문장 그 자체로, 대화 시나리오를 처리하기 위해 가공되기 전의 형태이다. 따라서 우리는 발화를 보고 대화의 형태를 이해할 수 있지만 컴퓨터는 이 발화만을 보고 대화를 처리하기는 어렵다. 예를 들면 "예약 하려고 하는데요"라는 대화는 우리가 볼 때는 예약 처리와 관련된 발화이지만 컴퓨터는 이것이 예약 처리를 위한 것인지 예약 확인이나 취소를 위한 것인지 알 수 없다.

image-20201123-173950-639.png

그림 5 발화에서 추출한 인텐트

따라서 컴퓨터가 이해하기 위한 정보로 가공을 하는 단계를 거친다. 예를 들어 "예약 하려고 하는데요"와 "예약 할 수 있을까요?"는 얼핏 발화만을 볼 때는 서로 다른 대화이지만 의도를 분석해 보면 이 두 가지 발화 모두 예약 처리와 관련된 의미를 갖고 있다. 이런 발화의 의도를 인텐트(intent)라고 하며 인텐트는 컴퓨터가 대화 시나리오를 처리하는 용도로 사용된다. 위 그림에서는 6가지의 서로 다른 언어와 표현의 발화를  I-ask.reservation 이라는 형태의 인텐트로 표기하였다. 실제 대화 처리 과정에서는 여러 발화가 내부의 자연어 이해(NLU) 모듈을 거쳐 인텐트로 변경되며 시스템은 이 인텐트를 기준으로 대화를 처리한다.

image-20201123-174003-521.png

그림 6 발화에서 추출한 슬롯 정보

또한 사용자 발화에는 태스크 진행에 필요한 여러 정보가 포함되어 있다. 예를 들어 식당 예약을 진행하는 대화에는 언제 예약할 것인지, 몇 명이 오는지와 같은 정보가 포함될 수 있다. 이렇듯 발화에 포함된 태스크와 관련된 의미 있는 정보를 슬롯(slot)이라고 부르며, 정보의 특성에 맞게 각 슬롯에 개별적으로 저장하고 대화 시나리오에서 사용할 수 있다. 예를 들어 "오늘 오후 2시 30분"과 "내일 점심시간쯤"은 모두 식당 예약 일시 정보를 담당하는 슬롯에 저장될 수 있다. 위 그림에서는 발화에서 식당 예약 일시와 관련된 정보를  S-Datetime  슬롯에, 예약 인원과 관련된 정보를  S-PeopleNumber  슬롯에 각각 저장하였다.

image-20201123-174017-028.png

그림 7 엔티티별로 나열된 슬롯

앞서 슬롯에는 정보가 특성에 맞게 개별적으로 저장된다고 하였다. 여기서 특성이란 "식당 예약 일시", "식당 문의 일시"와 같이 그 정보를 사용하는 형태에 따라 나눈다. 다만 "식당 예약 일시"와 "식당 문의 일시" 둘 모두 날짜와 관련된 정보를 저장하는데 이렇게 슬롯에 저장되는 데이터의 타입에 따라서 슬롯을 분류할 수 있다. 우리는 이런 슬롯의 타입을 엔티티(entity)라고 부르며 엔티티는 날짜, 숫자, 이름, 주소 등 다양하다. 엔티티는 발화에서 추출한 슬롯의 형태를 설계하는 데 도움을 준다.

image-20201123-174030-109.png

그림 8 인텐트와 슬롯의 묶음 페어

때로는 대화 흐름을 설계하는데 인텐트와 슬롯이 모두 요구되는 경우가 있다. 예를 들어 식당 메뉴를 받기 위한 "메뉴 정보 보내주세요"라는 발화는  I-faq.inform.text  형태의 인텐트와 메뉴 정보를 받을 연락처 정보인  S-PhoneNumber  슬롯 모두가 필요하다. 이처럼 인텐트와 슬롯의 쌍이 있어야 대화를 처리하는 경우 편의상 이 하나의 쌍을 묶어서 하나의 개념으로 정의할 수 있는데, 이것을 인텐트 슬롯 페어(intent-slots pair) 혹은 간단하게 페어(pair)라고 한다.  I-faq-inform.text 와  S-PhoneNumber 를  L-faq.inform.text  페어로 정의하고 메뉴 전송과 관련한 대화를 디자인할 때 해당 페어를 사용하면 대화 설계를 더욱 편하고 효율적으로 할 수 있다.

image-20201203-132725-363.png그림 9 컨텍스트 예시

실제 대화는 AI 스피커의 단발성 질의 응답과는 다르게 하나의 암묵적으로 진행되는 대화 주제 아래에서 대화를 이어가게 된다. 그림 9를 보면 FAQ와 예약이라는 두 가지의 주제에 대한 대화가 이어진다. FAQ에 대한 대화가 끝나고 시스템 에이전트는 FAQ 주제 이전에 대화하던 예약에 대한 주제로 돌아와 예약 진행에 대해서 질문을 했고 사용자는 "내일 2시"라고 일시에 대한 정보를 발화했다. 시스템은 예약에 대한 주제로 대화를 하고 있다는 것을 알고 있으므로 "내일 2시"는 "예약 일시"라는 것을 알 수 있다.

이렇듯 사용자의 발화는 때로는 중의적인 표현으로 일부 정보가 숨겨져 있을 수 있다. 이때 컨텍스트(context)라고 부르는 대화의 문맥 정보를 바탕으로 시스템은 사용자의 중의적인 표현을 보충하여 사용자의 정확한 질의나 요청을 처리할 수 있다. 컨텍스트가 없다면 대화의 흐름이 엉키고 딱딱한 느낌의 대화로 이어질 것이다. 대화는 시작부터 끝까지 하나의 컨텍스트로 이루어지지 않고 대화 진행 과정에서 컨텍스트가 새로 생기거나 이전 컨텍스트로 돌아오는 등 여러 번 그 형태가 바뀔 수 있다. 다시 그림 9를 보면 FAQ 컨텍스트에서 시스템은 식당에 가는 방법을 알려주었고 사용자가 식당 가는 법을 묻기 전에 있었던 예약 진행 컨텍스트로 변경해서 대화를 이어가고 있다. 컨텍스트는 대화를 진행하며 변경될 수 있고 컨텍스트가 끝날 때 이전에 진행했던 컨텍스트로 돌아올 수 있다.

image-20201123-174050-258.png

그림 10 대화의 턴

그리고 대화는 (turn)이라고 부르는 단위로 이루어져 있다. 그림 10을 보면 대화는 시스템이 발화하고 사용자가 발화하는 순서로 마치 탁구를 치듯 진행된다. 이때 시스템과 사용자가 번갈아 대화를 하는 각각의 쌍을 턴으로 볼 수 있다. 대화는 이런 턴이 겹겹이 쌓여나가면서 진행된다.

image-20201123-174059-914.png

그림 11 멀티 턴 구조와 슬롯 필링

턴이 진행되며 사용자의 목적을 이루는 과정에서 사용자의 발화만으로 태스크를 해결하기 어려운 경우가 존재한다. 태스크 해결을 위해 추가 정보가 필요한 경우인데, 그림 11을 보면 예약 진행을 위해서 예약 일시, 예약 인원, 예약 시간 등의 정보를 더 알아야 한다. 따라서 시스템은 추가 턴에서 부족한 정보를 질문하고 사용자는 그 정보를 답변해주는 형태로 부족한 정보를 채우는 과정이 발생한다. 이것을 슬롯 필링(slot filling)이라 부르고 이런 턴의 형태를 멀티 턴(multi-turn)이라 부른다. 대화 시나리오에서 멀티 턴은 빈번하게 발생하고 정보가 부족한 슬롯의 형태는 굉장히 다양한 케이스로 존재하기 때문에 슬롯 필링의 시나리오를 꼼꼼하게 설계하는 것은 대화 설계에서 굉장히 중요하다. 또한 슬롯 필링 과정이 기계적으로 이루어진다면 사용자는 이 단계에서 지칠 수 있기 때문에 주의가 필요하다.

image-20201123-174110-639.png

그림 12 슬롯 필링을 위한 팔로업 퀘스천(follow up questions)

앞서 설명한 내용과 유사한 개념으로 팔로업 퀘스천(follow up question)이 있다. 사용자의 대화를 진행하기 위해 추가 질문으로 정보를 얻어야 하는데 이때 추가 질문이 팔로업 퀘스천에 해당한다. 슬롯 필링을 위해 어떤 팔로업 퀘스천을 디자인하고 어떤 타이밍에 그 질문을 할 것인지는 대화 설계 과정에서 고민이 필요하다. 너무 많은 질문을 한 번에 하거나 사용자 입장에서 모호한 질문을 하면 대화를 진행하는 과정에 차질이 발생할 수 있기 떄문에 팔로업 퀘스천을 정의하는 과정은 신중해야 한다.

image-20201123-174120-527.png

그림 13 서로 다른 컨텍스트 발화로부터 대화 리페어

사용자와 대화하는 도중 예상하지 못한 대화의 오류로 인식될 수 있는 상황에 빠질 수 있다. 예를 들어 식당 예약을 진행하는 도중 사용자가 식당에 가는 방법을 묻는다거나 주차장의 위치를 묻는 등 기존 컨텍스트와는 전혀 관련 없는 사항에 대한 새로운 대화를 진행하는 경우가 존재한다. 이 경우 시스템은 새로운 컨텍스트에 대한 대화를 처리하고 기존 컨텍스트로 자연스럽게 돌아와 사용자의 태스크를 충족할 수 있는 시나리오에 대한 구성이 필요하다. 사용자가 갑작스러운 문의를 하는 경우 문의에 대해서 대답할 수 있는 리페어 패스를 준비해두어야 한다.

image-20201123-174132-341.png

그림 14 응답이 없는 사용자로부터 대화 리페어

마찬가지로 식당 예약을 진행하는 중 사용자가 다른 일이 생겨 응답을 못하거나 더 이상의 발화가 수신이 되지 않는 문제가 발생할 수도 있다. 이 경우에도 사용자의 미응답에 따른 리페어 패스를 통해 사용자가 응답할 때까지 대기하며 질의를 하거나 특정 횟수 이상 응답하지 않는 경우 통화를 끊는 등의 처리가 필요하다.

image-20201123-174141-519.png

그림 15 동일한 대화를 paraphrases 처리

사용자가 시스템 에이전트와 대화를 할 때 시스템 에이전트가 변화가 없는 동일한 반복된 문장을 말하는 경우 대화의 자연스러움이 떨어지고 위화감을 느낄 수 있다. 특히 사용자가 시스템의 질문과 다른 대답을 하여 시스템이 되묻는 경우나 새로운 컨텍스트로부터 이전 컨텍스트 대화 흐름이 돌아와 이전 컨텍스트에 질문을 다시 하는 경우에 반복되는 문장을 발화하는 문제가 발생한다. 따라서 이런 케이스에 대비하여 paraphrases를 적용하는 것을 고려해볼 수 있다. 예를 들어 그림 15의 "언제로 예약 도와드릴까요?"라는 문장은 "오시는 날짜가 어떻게 되세요?", "혹시 언제 오시나요?", "언제쯤으로 예약 도와드릴까요?", "예약은 언제로 도와드릴까요?"로 표현해도 그 의미는 거의 같다. 즉 하나의 문장이라도 그 문장과 의미가 같지만 표현이 다른 여러 문장이 존재하기 때문에 그 여러 문장을 랜덤하게 선택하여 발화하면 보다 자연스러운 대화 구성이 가능해진다.

대화 시나리오

image-20201123-174152-017.png

그림 16 대화 서비스를 위한 구조 및 대화 시나리오

우리는 앞서 대화를 구성하는 구성 요소를 살펴보았다. 대화 구성 요소를 조합하여 사용자의 태스크를 해결할 수 있는 대화 시나리오를 구성하여 챗봇 서비스, AI 에이전트 서비스에 활용할 수 있으며 이때 대화 시나리오는 그림 16의 노란색 사각형에 해당한다. 서비스 모듈 구조를 살펴보면 사용자는 음성 인식 모듈(ASR: AI Speech Recognition)과 가장 가까이 위치하고 이곳에서 사용자의 음성을 텍스트로 변환하는 역할을 한다. 이렇게 변환된 음성 텍스트는 자연어 이해(NLU: Natual Language Understand) 모듈을 거쳐 인텐트와 기타 메타 정보로 해석되고 이 메타 정보를 파란색 영역인 다이얼로그(dialog) 모듈에서 해석하여 사용자에게 응답(Response)을 보낸다. 이때 다이얼로그 모듈은 대화 시나리오를 바탕으로 대화를 처리하기 때문에 대화 시나리오는 서비스의 질을 좌우하는 중요한 역할을 한다. 따라서 좋은 서비스를 위해서는 좋은 대화 시나리오 설계가 필연적이다.

image-20201123-174200-896.png

그림 17 대화의 계층 구조

여태까지는 미시적 관점에서 가장 기본적인 대화 구성 요소를 살펴보았다. 조금 더 넓게 거시적 관점에서 대화를 살펴본다면, 대화는 계층적 구조이며 각 계층에 서로 다른 대화 구성 요소가 모여 이루어져 있다. 대화의 목적 서비스를 프로젝트라고 칭한다면 프로젝트 하위에 각각의 태스크(task)와 액티비티(activity)라고 부르는 계층이 존재한다. 대화를 계층으로 관리하는 이유는 대화에는 결국 목적이 있기 때문이다. 목적이라는 큰 주제에 대해서 테스트와 액티비티를 통해 대화 시나리오를 구성한다. 잘 이해되지 않는다면 아래 그림을 보자.

image-20201123-174210-557.png

그림 18 대화 구조 예시(식당 예약 프로젝트)

예를 들어 식당 예약 프로젝트라는 대화 시나리오가 있다고 가정해보자. 식당 예약을 위해 통화를 할 때 통화 시작에 대한 안내 태스크, 예약 진행을 위한 태스크, 문의를 위한 FAQ 등 대화의 커다란 범위의 주제들이 존재할 것이다. 그리고 안내 태스크에서는 인삿말을 위한 액티비티, 예약 진행에서는 좌석 확인, 예약 확정 등 다양한 하위 분류의 액티비티가 존재하고 그 목적에 따라 대화가 구성될 것이다. 이와 같이 대화 시나리오를 디자인할 때 태스크와 액티비티를 각각 구성하고 그 하위에 대화 구성 요소를 조합하여 최종적으로 대화 시나리오를 설계한다.

원자적 대화 구조

image-20201123-174220-716.png

그림 19 원자적 대화 구조

만약 여러분의 대화 시나리오가 네이버의 Chatbot이나 구글의 Dialog Flow처럼 하나의 다이얼로그 시스템을 사용하는 것이 아니라 여러 시스템에서 사용될 수 있는 경우 대화 구성 요소를 한 가지 시스템에만 의존하지 않는, 최소의 단위로만 구성된 중립적인 구조로 설계해야 한다. 따라서 대화의 구성 요소를 원자적으로 쪼개어 원자적 대화 구성 요소를 나열하고 그것을 병합하여 커다랗고 복잡한 대화 시나리오를 구성하는 형태로 대화 시나리오를 설계할 수 있는데, 이런 방법을 우리는 원자적 대화 디자인이라고 부른다.

대화 구성 요소를 원자적 디자인으로 관리할 때 장점은 다이얼로그 시스템의 의존이 줄어들고 설계된 대화 시나리오가 시스템에 종속되지 않고 통용적으로 사용될 수 있다는 것이다. 그림 19를 보면 액티비티라는 대화 계층 하위에 박스(box)와 버블(bubble)로 대화 구성 요소가 이루어져 있고 버블은 다른 박스나 버블과 이어질 수 있다. 이런 단순한 규칙을 바탕으로 박스와 버블이라는 단위를 통해 대화를 디자인할 수 있다.

image-20201123-174228-642.png

그림 20 사용자 발화 수신 대화 노드

예를 들어 사용자가 특정 인텐트를 입력으로 제공할 때 인텐트 박스(intent box)를 통해 매치되면 다른 대화 박스나 버블로 연결할 수 있다. 이렇게 구성한 경우 사용자가 특정 인텐트를 말하면 다른 대화 흐름으로 이동할 수 있다.

image-20201123-174236-231.png

그림 21 시스템 발화 출력 대화 노드

마찬가지로 시스템이 발화를 출력하거나 녹음된 오디오를 재생하는 경우 시스템 발화에 대한 정보와 오디오 효과에 대한 파라미터를 바탕으로 시스템 박스(system box)를 통해 오디오를 출력하고 다른 대화 흐름으로 연결할 수 있다. 시스템 박스를 앞선 인텐트 박스의 Next로 연결하여 제공하는 경우 사용자로부터 특정 인텐트를 입력받으면 특정 오디오나 발화를 재생할 수 있다.

image-20201123-174244-743.png

그림 22 여러 사용자 인텐트로 기반한 분기 노드

또한 분기 박스(branch box)를 통해 여러 인텐트를 각각의 대화 흐름으로 분기하는 박스를 배치하여 대화의 흐름을 세분화하여 관리할 수 있다. 분기의 조건으로 인텐트뿐만 아니라 슬롯 충족 여부, 슬롯 검증 여부 등 내부 변수에 조건을 추가하여 보다 세밀한 대화 흐름을 제공할 수 있다.

image-20201123-174252-063.png

그림 23 대화 노드로부터 다른 대화 그룹으로 진입하기 위한 연결 노드

마지막으로 액티비티에서 액티비티 혹은 액티비티에서 태스크와 같이 대화 컨텍스트를 건너뛰는 경우가 있다. 예를 들어 예약이 확정되여 예약 진행이 완료된 사용자가 예약 조회나 예약 취소에 대한 대화 컨텍스트로 건너뛰거나 사용자가 갑작스럽게 문의를 하는 경우 문의 액티비티를 끝내고 가장 마지막 컨텍스트로 돌아오는 등 액티비티와 태스크를 넘나들며 대화 박스를 연결해야 하는 경우가 존재한다. 따라서 분기점을 기준으로 흐름 박스(flow box) 등을 배치하여 대화를 설계하는 경우 더욱 유연한 대화 설계가 가능하다.

대화의 흐름

image-20201123-174303-805.png

그림 24 대화 흐름의 형태

대화는 흘러가며 진행하는 구조이므로 대화를 구성하는 박스와 버블은 서로 연결되며 대화 흐름이 이루어진다. 대화가 시작될 때 시작점이 되는 엔트리포인트(entrypoint)로부터 이어진 다른 박스와 버블로 나아가며 대화가 진행되어 사용자의 요구를 만족시킨다.

image-20201123-174312-621.png

그림 25 최종적인 대화 구조

대화를 거시적인 관점에서 보았을 때 태스크와 액티비티도 대화의 구성 요소인 박스와 버블과 같이 서로 이어져 있으며 흐름이 있다, 태스크와 액티비티의 연결 구조를 보면 상태 변화의 규칙을 발견할 수 있다. 예를 들어 좌석을 확인하는 과정에서 신규 예약 액티비티로 옮겨갈 수는 없다.

 

 

 

<원문/출처:https://d2.naver.com/helloworld/2110494>

Comments

번호 분류 제목 글쓴이 날짜 조회
57 커뮤니티 넥슨 디벨로퍼 컨퍼런스 6/9 ~6/11 센스장이 06.11 737
56 커뮤니티 네이버 클라우드, 오픈소스 후원자에서 참여자로 변신 jack 06.10 662
55 커뮤니티 How to Migrate from CentOS 8 to AlmaLinux 8.4 jack 06.09 707
54 커뮤니티 딥러닝 텐서플로 교과서 JakeMin 06.04 702
53 커뮤니티 개발자 한 명이 백 명의 일을 할수 있나? JakeMin 05.27 927
52 커뮤니티 개발자 유튜버, 구독자 1000명 달성까지의 여정. 그리고 수익창출 실리콘밸리 05.26 1043
51 커뮤니티 유용한 테스트 캐이스를 위한 개발자의 자세 Doge 05.25 872
50 커뮤니티 당신은 주니어 인가요 시니어 인가요? Doge 05.25 946
49 커뮤니티 압축파일 풀때 오류 생기면? 댓글+1 후니 05.23 654
48 커뮤니티 소프트웨어 인력 대책 SVKOREANS 05.13 1014
47 커뮤니티 [안드로이드로 배우는 OpenCV] 이미지 필터링 (공간적 필터링) Support 04.29 941
46 커뮤니티 40주간 진행한 사이트 프로젝트 후기 Support 04.27 851
45 커뮤니티 개발자의 연봉 상승 모멘텀, -그리고 환상 보라고래 04.16 961
44 커뮤니티 Stack Overflow 카피 사이트. 더 이상 보기 싫다면? 보라고래 04.16 929
43 커뮤니티 [NVIDIA AI Developer Meetup 공식 온라인 행사 안내] SVKOREANS 02.14 1854
42 커뮤니티 스타벅스를 통해서 소프트웨어 확장성 배우기 보라고래 01.18 1908
41 커뮤니티 MS에서 주관하는 가상화 데스크탑 웨비나 Support 2020.12.21 1861
열람중 커뮤니티 챗봇을 위한 대화는 어떻게 디자인할까 Support 2020.12.15 2265
39 커뮤니티 Deep Learning 2.0 Virtual Summit SVKOREANS 2020.12.07 2174
38 커뮤니티 Microsoft Azure Virtual Training Day: Azure에서 클라우드 네이티브 앱 개발 SVKOREANS 2020.12.06 2240
37 커뮤니티 Server-side with Kotlin Webinar Series SVKOREANS 2020.12.03 2505
36 커뮤니티 GraphQL Galaxy Conference - Dec 7-8, 2020(PST) SVKOREANS 2020.12.03 2356
35 커뮤니티 Chrome Dev Summit 2020 SVKOREANS 2020.12.03 2470
34 커뮤니티 MongoDB Online Conference SVKOREANS 2020.12.01 2406
33 커뮤니티 개발자를 위한 정보 검색 팁 Support 2020.11.20 2643
32 커뮤니티 개발자를 위한 인프라 기초 총정리 Support 2020.11.13 5404
31 커뮤니티 <Cloud> 컨테이너 역사 Support 2020.11.05 2886
30 커뮤니티 개발자들은 왜 Slack 을 쓸까? SVKOREANS 2020.10.13 3717
29 커뮤니티 초보 개발 팀장의 1년 회고 - 좋은 팀장이 되기 위한 노력들 SVKOREANS 2020.09.17 4103
28 커뮤니티 [번역] 진정한 선임 개발자는 어떤 사람인가? SVKOREANS 2020.09.07 3815
27 커뮤니티 현직 개발자가 추천하는 꼭 배워야 할 프로그래밍 언어! 보라고래 2020.08.29 3510
26 커뮤니티 초보 개발자, 이것만 안 해도 평균 이상 갑니다 (흔히 하는 실수 공개) 보라고래 2020.08.29 3445
25 커뮤니티 [IT 개발자와 일할 때 필요한 모든 개발지식] A to Z 자료 모음집 SVKOREANS 2020.08.27 4239
24 커뮤니티 같이 일하기 힘든 뛰어난 개발자 - 입개발자, 손개발자, 뇌개발자 SVKOREANS 2020.08.25 4258
23 커뮤니티 개발자가 공부로 살아남는 방법 Support 2020.08.18 3779
22 커뮤니티 좋은 개발문화란 무엇일까? Support 2020.08.10 4103
Category

State
  • 현재 접속자 65 명
  • 오늘 방문자 349 명
  • 어제 방문자 542 명
  • 최대 방문자 2,210 명
  • 전체 방문자 148,411 명
  • 전체 게시물 2,868 개
  • 전체 댓글수 373 개
  • 전체 회원수 469 명