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

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

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

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

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

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

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

AWS의 각종 서비스들을 콘솔로 관리하다 보면 정말 여러 페이지를 오가야 할 때가 있다. 가령 정식 구성으로 서버 하나를 띄운다고 생각해도... EC2 인스턴스용 Security Group(SG) 생성 1번과 미리 준비한(!) AMI를 가지고 Launch Template 생성 Target Group 생성 2번과 3번을 가지고 Auto Scaling Group(ASG) 생성 3번을 가지고 Load Balancer(LB) 생성. 이때 LB용 SG도 생성됨 5번에서 생성된 SG를 1번에 등록 마지막으로 5번의 도메인을 가지고 Route53 Record 생성! 리소스만 6개가 필요하다. 여기서는 각각의 단계가 구체적으로 어떤 역할을 하는지보다 얼마나 복잡한지에 집중하려고 한다. 이런 복잡한 과정을 매번 개발자의..

git에 익숙하지 않으면 작업 내역을 커밋하는 데 애를 먹는 경우가 있다. 동료 개발자들과 커밋을 작업 단위로 쪼개자고 합의를 본 상태다. 나 또한 1000줄짜리 거대한 커밋을 보는 건 원치 않기 때문이다.그런데 작업하다 보니 여기저기 손을 대면서 중복 코드도 없애고, 상속 구조도 바꾸고, 오타도 수정하고...여러 가지 작업을 하고 말았다. 이제 이 작업들을 나눠서 커밋해야 한다. git은 보니까 마지막 커밋만 --amend로 수정할 수 있던데... 잘못 커밋하면 되돌리지 못하는 것 같다.파일 하나하나를 신중히 나눠 커밋하다 보니 커밋 정리만 1시간을 하는 자신을 발견하게 되었다. 남들도 이렇게 힘들게 작업하나 싶다. 다들 깔끔하게 커밋하던데 나만 힘든 것 같고 막... 이렇게 공들여 작업하면 버전 관리..