개발
-
서버리스 카카오톡 챗봇 만들기: 3. 비정형 응답 받아내기주제탐구/튜토리얼 2020. 7. 21. 22:28
저번 글에서는 엔티티를 등록하고, 등록한 엔티티로 바로연결을 구성한 뒤, 엔티티를 기반으로 날씨 파라미터값을 받아내는 부분까지 다루었다. 이번 글에서는 드디어 마지막으로! 일기의 제목과 내용을 받아내는 부분을 완성해 보려고 한다. 정말 기본적인 뼈대가 완성되는 것이다. 👾 시작하기 전에 기존 카카오i 오픈빌더의 포럼이 사라지고, 대신 챗봇과 고객센터가 운영된다고 한다. 특히 챗봇은 Q&A 데이터가 학습되어 있다고 하니 도움이 필요한 경우 이용해 보아도 좋을 것 같다. 비정형 응답을 파라미터로 받는 방법 지금까지 챗봇에 추가했던 날짜, 날씨값과 달리 제목, 내용은 정해진 형식이 없다. 유저가 입력하는 대로 받아서 제목과 내용으로 삼아야 한다. 어떻게 하면 유저의 아무말을 파라미터값으로 받을 수 있을까? 아..
-
새로운 기술을 사용할 때 주의해야 한다고 생각하는 것들조금 긴 생각 2020. 4. 16. 02:45
레퍼런스에서 시작해야 한다 각 기술이 보편적인 문제를 해결하는 방식은 레퍼런스에 담겨 있다. 이런 기반 지식에 익숙해지기 전에는 코드를 쓰면 안 된다. 가령 React로 처음 코드를 짠다고 할 때, state를 직접 조작하면 안 된다는 것 정도는 알고 나서 코드를 쓰기 시작해야 한다. 이런 기반 지식을 모르는 상태에서 코드를 쓰기 시작하면 일단 코드가 엄청 늘어난다. 문서에도 없는 버그들을 만나야 하고, 그것들을 땜질하느라 코드를 더 붙여야 한다. 레퍼런스를 읽은 사람이 이런 코드를 보면 일단 정신이 혼란해지고(...) 아예 새로 짤 각오를 하게 마련이다. 커뮤니케이션하는 것도 어려워진다. 가령 코드 리뷰에서 이렇게 말하는 사람이 있다면 레퍼런스를 읽은 입장에서 어떤 대답을 해줄 수 있을까? 리듀서에서 ..
-
Terraform의 첫 번째 함정: 코드 읽을 때주제탐구/인프라 2019. 9. 2. 10:39
이 글은 Terraform의 4가지 함정이라는 시리즈의 일부로 작성하고 있다. 인트로: 인프라 자동화, 쓰면 좋습니까? 첫 번째 함정: 코드 읽을 때 두 번째 함정: 코드 수정할 때 세 번째 함정: 코드 적용할 때 네 번째 함정: AWS 특수 함정 Terraform 코드 첫인상 우리 팀은 인프라 자동화에 테라폼을 많이 활용하고 있다. EC2 몇 대 올리는 간단한 리소스부터, AWS 서비스랑 얼기설기 얽히는 복잡한 리소스까지 서비스에 직접적으로 사용되는 많은 리소스에 테라폼을 쓰고 있다. 그런데 사실 우리 팀에는 몇 주 전만 해도 테라폼을 아는 개발자가 거의 없었다. 전능하신 한 팀원분에 의해 테라폼 코드가 존재하게 되었고, 서버 개발자들도 인프라 작업을 하기 위해서 테라폼을 배워야 하는 상황이 되었다. ..
-
인프라의 코드화: 쓰면 좋습니까?주제탐구/인프라 2019. 8. 26. 10:54
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개가 필요하다. 여기서는 각각의 단계가 구체적으로 어떤 역할을 하는지보다 얼마나 복잡한지에 집중하려고 한다. 이런 복잡한 과정을 매번 개발자의..
-
기술블로그 왜 버렸나: 블로그 회고조금 긴 생각 2019. 8. 15. 13:48
약 5개월 만에 블로그에 들어와서 글을 써보는 것 같다. (그 사이 티스토리 에디터가 바뀌었네! 코드 블록을 넣을 수 있게 됐어 이야아) console.log('감사합니다 티스토리') 상반기 회고를 하려고 했지만 그 전에, 왜 5개월 동안 블로그를 쓰지 않았는지부터 돌아보려고 한다. 하지만 잃어버린 습관에 대해서 이유를 대려면 수백 가지는 만들어낼 수 있기 때문에 ,, 블로그를 어떻게 쓰게 되었는지, 그리고 어떻게 쓰기를 멈추게 되었는지의 경과를 써 보려고 한다. 상상도 못한 블로그 이 블로그를 시작한 건 1월 즈음이었다. 당시의 나는 회사에서 쓰는 기술을 하루하루 벅차게 배워가며, 조그마한 개발 미션을 몇 개 끝낸 뒤였기 때문에 처음으로 개발 업무를 맡아본다는 부담감을 안고 있었다. 내가 월급을 받는 ..
-
어쩌다 DDD 공부를 시작했다개발일지 2019. 3. 25. 00:24
주말 동안 를 공부하고, Apache Kafka와 AWS Kinesis에 대해서 조금 기술조사를 했다.아직 어렵기만 하지만 곧 판단의 기준이 설 거라고 생각하고! 열심히 공부하고 있다. 오늘은 DDD를 공부하게 된 계기에 대해서 생각이 나 적어보려고 한다. 어쩌다 만난 DDD팀 내 테크 리더님의 추천으로 DDD를 조금씩 공부하고 있다.DDD를 공부하게 된 계기는 따로 있었는데... 현재 우리가 만드는 서비스는 각 도메인별로 모듈화한 상태로 개발되고 있다.즉 계정, 인증, 통계 등의 문제 영역 별로 별도의 모듈 안에서 개발되고, 별도의 DB를 사용한다.배포도 모듈 단위로, 서로 분리된 EC2 Auto Scaling Group를 통해 이루어진다. -- 여기서부터 설명 어설픔 주의 -- 이렇게 하면 문제 영역..
-
Git Branching의 가치주제탐구 2019. 1. 13. 16:47
git에 익숙하지 않으면 작업 내역을 커밋하는 데 애를 먹는 경우가 있다. 동료 개발자들과 커밋을 작업 단위로 쪼개자고 합의를 본 상태다. 나 또한 1000줄짜리 거대한 커밋을 보는 건 원치 않기 때문이다.그런데 작업하다 보니 여기저기 손을 대면서 중복 코드도 없애고, 상속 구조도 바꾸고, 오타도 수정하고...여러 가지 작업을 하고 말았다. 이제 이 작업들을 나눠서 커밋해야 한다. git은 보니까 마지막 커밋만 --amend로 수정할 수 있던데... 잘못 커밋하면 되돌리지 못하는 것 같다.파일 하나하나를 신중히 나눠 커밋하다 보니 커밋 정리만 1시간을 하는 자신을 발견하게 되었다. 남들도 이렇게 힘들게 작업하나 싶다. 다들 깔끔하게 커밋하던데 나만 힘든 것 같고 막... 이렇게 공들여 작업하면 버전 관리..