밀레니얼 개발 블로그 밀레니얼 개발 블로그

이전 글에서는 카카오톡 오픈빌더를 활용해서 일기 작성에 필요한 정보를 사용자에게 받아내는 플로우를 완성했었다. 이번 글부터는 이 플로우를 적절한 백엔드와 연결해서 실제로 일기가 저장될 수 있도록 하려고 한다. 첫 번째 글에서 미리 말했었지만 AWS를 사용해서 서버리스 백엔드를 만들 예정이기 때문에... AWS 계정이 필요하다. 계정이 없다면 이런 글을 참고해서 계정을 하나 만들고 오자. 계정을 만들었고, AWS 콘솔에 로그인을 해서 이런 화면이 떴다면 준비가 끝난 것이다. 이 콘솔을 사용해서 필요한 리소스를 차근차근 만들어 보고, 서로 연결해서 백엔드를 만들 것이다. 주의사항 모든 리소스는 사용량에 따라서 과금되는 것으로 준비했고, 혼자서 테스트로 사용하는 정도면 0원이 찍힐 가능성이 높지만, 혹시 모를..

저번 글에서는 엔티티를 등록하고, 등록한 엔티티로 바로연결을 구성한 뒤, 엔티티를 기반으로 날씨 파라미터값을 받아내는 부분까지 다루었다. 이번 글에서는 드디어 마지막으로! 일기의 제목과 내용을 받아내는 부분을 완성해 보려고 한다. 정말 기본적인 뼈대가 완성되는 것이다. 👾 시작하기 전에 기존 카카오i 오픈빌더의 포럼이 사라지고, 대신 챗봇과 고객센터가 운영된다고 한다. 특히 챗봇은 Q&A 데이터가 학습되어 있다고 하니 도움이 필요한 경우 이용해 보아도 좋을 것 같다. 비정형 응답을 파라미터로 받는 방법 지금까지 챗봇에 추가했던 날짜, 날씨값과 달리 제목, 내용은 정해진 형식이 없다. 유저가 입력하는 대로 받아서 제목과 내용으로 삼아야 한다. 어떻게 하면 유저의 아무말을 파라미터값으로 받을 수 있을까? 아..

저번 글에서는 블록의 기본적인 구성 방법을 알아보고, sys.date를 기반으로 유저에게 날짜 정보를 받아보았다. 그 결과 일기의 날짜까지는 받아볼 수 있었다. 하지만 일기를 쓰기 위해서는 더 많은 정보들이 필요하다. 적어도 날씨, 제목, 내용 정도는 받을 수 있어야 한다. 이 정보들을 받기 위해서 일기 쓰기 플로우의 남은 부분을 차근차근 만들어 볼 것이다. 우선 날씨를 받는 것부터 시작하자. 이때 날씨를 사용자 엔티티로 등록해 볼 것이다. 그 이유는 바로 뒤에 알아보고, 우선은 저번 글에서 알아보았던 엔티티라는 개념에 대해서 추가 설명을 하고 넘어가자. 날씨 입력받기 엔티티(Entity)는 봇이 이해할 수 있는 용어를 체계적으로 정리한 데이터 사전입니다. 라고 저번 글에서 언급했었다. 그리고 유저의 발..

이번 글+다음 글에서는 백엔드 없이, 아주 기초적인 카카오톡 챗봇을 하나 만들고, 이 챗봇을 개발 채널과 연결시켜 휴대폰의 카카오톡으로 동작을 확인해 볼 것이다. 대충 이런 느낌의 프로토타입을 만들 수 있을 것이다. 날짜, 날씨, 제목, 그리고 내용을 입력하면서 대화형으로 일기를 작성할 수 있다. (실제로 데이터를 저장하고, 조회하는 동작은 백엔드가 필요하다. 다다음 글에서 다룰 예정이다.) 특히 날짜 부분은 4일 전, 크리스마스, 글피, 7월 13일 등 다양한 입력을 적당히 알아 듣는 똑똑함을 보여준다. 카카오i 오픈빌더가 기본 제공하는 엔티티를 통해 별다른 노력 없이도 이런 똑똑함을 장착하고 나갈 수 있다. 엔티티가 무엇인지는 조금 있다가 살펴보도록 하자. 카카오i 오픈빌더 써보기 우선은 이전 글을 ..

최근 학교 과제로 이렇게 생긴 카카오톡 챗봇을 만들게 되었다. (그렇다 학교 과제... 일과 학업을 병행 중이다!) 이너푸드라는 챗봇인데, 아래 스크린샷에 나온 것처럼 대화형으로 식사를 기록하고 확인할 수 있는 챗봇이다. 물론 혼자 만든 것은 아니고 팀 프로젝트로 한 학기 내내 만든 결과물이다. 생각해보면 다른 팀들은 모두 발로 뛰면서 관악구 주변 맛집, 학교 동아리, 학교 안 인쇄소 등의 데이터를 싹싹 긁어모았는데 우리만 호기롭게 식사를 기록하는 챗봇을 기획했다. 좀만 더 나갔다면 애플리케이션 하나 만들지 않았을까? 하하하 아무튼 이런 애플리케이션 스타일의 챗봇을 만드는 과정은 데이터를 미리 모아서 만드는 챗봇과는 다르다. 카카오톡 챗봇 제작 도구가 아무리 좋다고 한들 카카오의 소중한 DB까지 제공해 ..

레퍼런스에서 시작해야 한다 각 기술이 보편적인 문제를 해결하는 방식은 레퍼런스에 담겨 있다. 이런 기반 지식에 익숙해지기 전에는 코드를 쓰면 안 된다. 가령 React로 처음 코드를 짠다고 할 때, state를 직접 조작하면 안 된다는 것 정도는 알고 나서 코드를 쓰기 시작해야 한다. 이런 기반 지식을 모르는 상태에서 코드를 쓰기 시작하면 일단 코드가 엄청 늘어난다. 문서에도 없는 버그들을 만나야 하고, 그것들을 땜질하느라 코드를 더 붙여야 한다. 레퍼런스를 읽은 사람이 이런 코드를 보면 일단 정신이 혼란해지고(...) 아예 새로 짤 각오를 하게 마련이다. 커뮤니케이션하는 것도 어려워진다. 가령 코드 리뷰에서 이렇게 말하는 사람이 있다면 레퍼런스를 읽은 입장에서 어떤 대답을 해줄 수 있을까? 리듀서에서 ..

개발자는 기계와 일하지 않는다. 개발자는 사람과 함께 일한다. 물론 컴퓨터랑 싸워서 이겨야 하는(?) 상황도 가끔 있지만, 기존의 관습을 놓쳤거나 이해하지 못했을 때 발생하는 에러도 상당하다. 그리고 '기존의 관습'은 사람이 만든다. 하물며 로우 레벨의 칩셋이라도 입출력과 인터페이스는 사람이 정의했으니까. 그래서 개발자는 사람과 함께 일할 수 있는지가 개인의 기술 수준만큼이나 중요하다고 생각한다. 특히 비즈니스를 향해 한 배를 타고 있는 개발자들이라면 더더욱. 개개인의 다양성을 해치지 않는 수준에서 협업하기 어렵다고 생각하는 개발자의 특성을 뽑아봤다. 무접점 개발자 우직하게 개발만 하는 개발자. 같이 어울릴 수 있는 모든 기회를 차단한 채 자신의 코드에만 몰입한다. 항상 일하는 모습만 보는데 정작 무슨 ..

이 글은 Terraform의 4가지 함정이라는 시리즈의 일부로 작성하고 있다. 인트로: 인프라 자동화, 쓰면 좋습니까? 첫 번째 함정: 코드 읽을 때 두 번째 함정: 코드 수정할 때 세 번째 함정: 코드 적용할 때 네 번째 함정: AWS 특수 함정 Terraform 코드 첫인상 우리 팀은 인프라 자동화에 테라폼을 많이 활용하고 있다. EC2 몇 대 올리는 간단한 리소스부터, AWS 서비스랑 얼기설기 얽히는 복잡한 리소스까지 서비스에 직접적으로 사용되는 많은 리소스에 테라폼을 쓰고 있다. 그런데 사실 우리 팀에는 몇 주 전만 해도 테라폼을 아는 개발자가 거의 없었다. 전능하신 한 팀원분에 의해 테라폼 코드가 존재하게 되었고, 서버 개발자들도 인프라 작업을 하기 위해서 테라폼을 배워야 하는 상황이 되었다. ..