[Notion]Notion과 Github Actions로 가계부 자동화 하기 - (1)

시작하기에 앞서


해당 포스트는 [Notion]Notion과 Zapier로 가계부 자동화 하기의 후속편입니다.

해당 포스트에서는 토스의 소비 서비스를 기반으로 Google Drive, Naver OCR, Github Actions, Notion API 를 사용합니다.

왜 Github Actions로 변경하게 되었을까?


기존에 가계부 자동화로 맨처음 고려 했던 방식은 Github Actions + Naver OCR을 이용한 가계부 자동화 방식이였습니다.

하지만 가계부를 쓰기 위해 코딩을 하는게 맞나? 싶은 생각에 솔루션들을 사용하기로 하였고

플랫폼들을 이용한 기존에 구성한 스택은 다음과 같습니다.

  • Google Drive : 캡쳐 이미지 저장소
  • Zapier : Google Drive 이미지 업로드시 정해진 프로세스를 진행하도록 하기 위한 플랫폼
  • Nanonets : 이미지에 OCR을 동작시켜 이미지에서 필요한 영역의 데이터를 뽑아낼 수 있음.

해당 스택으로 구성하였을때 무엇보다 좋았던 점은 코드를 한줄도 작성하지 않아도 가능하기 때문에,

개발자가 아니더라도 충분히 따라서 할 수 있다 였습니다.

하지만 해당 스택으로 구성하였을때 개발자로써 한계가 더 쉽게 다가왔고, 제가 느꼈던 문제점은 다음과 같습니다.

  • Zapier (자동화 플랫폼)

    • 무료 플랜사용시에는 월 100회 실행 무료이며, 1개의 자동화(zap)당 1개의 작업만 설정이 가능합니다.

      저의 경우 아래 두가지 자동화로 나뉘게 되어, 하나의 항목 업로드시 무료 횟수가 2회씩 차감이 됩니다.

      1. 구글 드라이브에 이미지가 업로드 되면 OCR 분석을 실행
      2. OCR 분석이 완료되면 Notion DB에 저장.
    • 자동화는 15분 간격으로 실행되기때문에, 위와 같이 2개가 처리되면 최악의 경우 30분이 걸리게 됩니다.

    • Notion의 Database에 항목(Property)이 많으면 일부만 노출되는 문제가 있어 원하는대로 매핑을 할 수 없습니다.

    • 데이터 포맷 변환 또한 Zap을 새로 추가해야해서 비용이 발생함.

      • 날짜 포맷이 토스에서는 2022년 1월 1일 14:40 이지만, Notion에는 ISO8601의 날짜 포맷인 2022/01/01 이 아니면 데이터가 오늘 날짜로 입력됩니다.
  • Nanonets (이미지 글자 인식 OCR 플랫폼)

    • 해외 플랫폼의 한계로 한글 인식률이 부족합니다.

      • 한글의 경우 글자사이에 띄어쓰기가 계속 추가되는 문제도 있습니다.
    • 무료 플랜에서는 월 100회 이미지 인식 제한이 있습니다.

    • 모델학습을 여러번 해보았지만 영역이 잘못 잡혀서 값이 누락되는 케이스가 있습니다.

      • 날짜 인식이 잘못되어 데이터가 잘못 들어감.

위와 같은 한계로 초기에 고려한 방식을 사용한다면 직접 개발해야 하는 문제를 뺀다면,

훨씬 높은 자유도를 얻어 원하는대로 설정할 수 있고

각 서비스의 API의 무료 한도도 Naver OCR의 API 한도인 300회만 고려하면 되기 때문에

한달의 가계부를 쓰기에 충분할것이라 판단하였습니다.

서비스 구성


이와 같이 구성하여 작성하였습니다.

각 영역에 대한 상세한 내용은 다음편에서 작성 예정입니다

[Notion]Notion과 Zapier로 가계부 자동화 하기

왜 가계부를 쓰나요?

저는 예전부터 가계부를 써서 돈의 사용처를 기록하고 카테고리화 해서 어디에 돈을 많이 쓰고 있는지 흐름을 보는것을 좋아했습니다.

가계부를 Notion으로 쓰는 이유

첫 가계부는 편한 가계부라는 어플을 사용했고, 그 이후 핀테크쪽 서비스가 커지면서 뱅크샐러드를 사용했었습니다.

뱅크 샐러드는 느리긴 했지만 제가 필요하다 생각했던 모든 것들을 제공 해주고 있었습니다.
토스에서 소비 라는 탭으로 연동된 계좌들의 소비 내역을 보여주는 기능도 출시하여 엄청나게 빠른 속도로 스크래핑이 되었습니다.

문제는 결혼 이후로는 제 지출 내역만 관리하는게 아니라 아내의 지출 내역도 관리가 필요했습니다.

저는 위에 가계부를 쓰는 이유가 돈의 흐름을 보고 싶은 것이라 통계들을 볼 수 없는 종이 가계부는 쓰고 싶지 않았고,

언제든 접근할 수 있고 두사람이 같이 온라인으로 관리 할 수 있는 가계부가 필요했습니다.

개발자 답게 직접 서비스를 만드는것도 고려했으나 주 목적인 가계부를 쓰기 위해 서버를 관리하고, 비용을 내고 해야한다는것이 점점 야크 털 깎기가 되어 가는 느낌이였습니다.

이러한 이유로 새로운 방법을 찾아보기 시작합니다.

앱을 알아봤을때 iOS 에는 Buboo 가계부라는 어플이 있었는데,

웬만한 공유 가계부 서비스들이 서비스 중단된 케이스가 많아서, 모든 데이터를 작은 서비스에 의존할 수 없겠다는 판단을 했습니다.

주위에 자문을 구했을때, 엑셀 템플릿을 구하여 엑셀 또는 구글 스프레드 시트를 이용하여 가계부를 쓰는 기혼자 분들이 많이 있었습니다.

그분들을 따라 블로그들을 돌아다니며 템플릿을 수집하고 가장 제가 쓰기 편한것을 3개월정도 사용했습니다.

여기서도 발견된 문제점은 제가 엑셀을 잘 사용하지 않다보니, 만들어진 템플릿을 커스텀하는데 드는 리소스가 너무 컸습니다.
여기서도 엑셀을 배우는것보단 제가 원래 많이 사용하는 노션으로 가계부를 옮기게 됩니다.
직접 만들 수도 있었지만 템플릿은 노션 강좌 유튜브에서 구해서 사용했습니다.

자동화를 하게 된 계기

  • 생활비 통장
  • 실제 결제에 사용하는 카드 N개

위와 같이 나누어 쓰고 사용한 금액을 생활비 통장에서 차감하는 방식으로 사용합니다.

처음에는 노션에만 가계부를 작성을 했는데 누락되는 케이스가 있어서 보조수단으로 토스 메모 기능을 활용했습니다.

카드로 결제를 하면 어떤것을 결제했는지(PG결제 같이 사업자명이 안 나오거나 실제 매장명과 거래처명이 다른 경우가 많음) 토스 소비 탭에서 메모를 작성을 하고,
토스에 있는 내역을 기반으로 노션에 가계부를 작성을 하고 있었습니다.

이렇게 하다보니 똑같은 일을 결제 내역당 두번씩 하고 있었습니다.

하루에 1~2건이라면 문제가 없지만 하루에 결제내역이 많으면 10건까지도 있는 경우가 있다보니 제가 해야 할 반복 작업은 N(결제건수)*2가 되어버립니다.

이를 어떻게 해결하면 좋을까 고민하다보니 제가 하는 작업은 아래와 같습니다.

  1. 토스 소비탭에서 결제 내역에 메모를 추가한다.
  2. 노션 가계부에 1의 내용을 바탕으로 저장한다.
  3. 생활비 통장에서 금액을 차감하고 결제수단을 업데이트 한다.(월별 생활비 추가)

3번 동작은 송금 기능도 들어가기때문에 자동화가 애매하지만, 2번 동작은 1번 동작에 상당히 의존적이였습니다.
그렇다면 1번이 다 되었을 때, 해당 내용을 읽어들여 최근에 나온 Notion API를 사용하면 되지 않을까? 라고 생각하게 됩니다.

어떻게 연결 하였을까

Zapier라는 서비스에서는 구글드라이브의 이벤트와 Nanonets OCR 이라는 서비스를 연결 할 수 있었습니다.

자세히 보기

2019년 하반기 회고

상반기 회고 당시에는 하반기에는 분기별 회고를 해서 더 잘 정리해야겠다 생각했는데,
하반기 회고 조차 늦어지게 되었습니다.

💼 회사


새 회사로 이직을 하게 되면서, 인수인계 기간이 지난 후 약 3주정도 휴가를 즐겼습니다.

여행도 다녀오고, 쉬는 기간동안 카페 투어도 하고 이곳 저곳 돌아다녔지만 생각보다 생산성 있는 휴가는 아니여서
아직 아쉬움이 남아있습니다.

새 회사로 오게되어 회사에 적응하는 시간을 보내고 실무에 투입되었습니다.
이정도 규모의 회사에서는 어떻게 서비스를 하고 있고, 현재 서비스에서 어떤 문제를 가지고 있어서 그것을 해결하기 위해 어떤 고민을 하고 있는지, 앞으로 어떤 계획이 있는지 등을 어깨넘어 보면서 새로운것들을 알아가고 있습니다.
생각보다 많은 일들이 동시에 빠르게 진행 되고 있으면서도 아쉬움이 느껴졌습니다.

무엇보다 업무적 문서화가 아닌 공유 목적의 개인적인 문서화와 일정 관리 체계가 이렇게 잘 되어 있는 기업에서 일해본 경험이 처음이라 이러한 부분은 너무 만족스럽습니다.

최근에 스타트업에서 성장한다는 주니어의 착각 이라는 포스팅을 접하게 되었습니다.
해당 글을 보며 과연 이전 회사에서 내가 느끼고 있었던 나는 이곳과 함께 빠르게 성장하고 있다 라는 생각이 어찌보면 혼자만의 착각이 아니였을까 다시 한번 돌아보는 기회를 준 고마운 글이었습니다.

지금은 스타트업에서 근무할때 처럼 기존의 것이 문제가 된다면 새로운걸 빠르게 도입하고 결과물을 확인하고 기존의 것은 대체 할 수 있는것은 아니지만,

오히려 많은 사람들이 쓰고 있는 솔루션에서 호환성 유지를 위해 문제 없이 기능을 개선하면서도

과연 최적의 방법일까 다시 한 번 더 고민해보면서 얻고 있는 이점들이 있습니다.

📒 블로그


블로그 배포 방식 변경

상반기에는 Travis CI로 블로그를 배포하도록 변경하였는데, Github Actions 신청이 가능해지면서 배포 방식을 Github Actions로 옮겼습니다.

Travis CI에서 Private Repo Free 제한이 Codeship 서비스와 동일하게 월 100회인줄 알았으나, 토탈 100회인것을 알고 시간여유가 있을때 빠르게 옮겨야겠다 싶었습니다.

코드는 이전과 동일하게 Dropbox에서 동기화 하면서도 Github Private Repo로 형상관리 하고있습니다.

해당 내용은 Github Actions를 이용하여 Hexo 블로그 배포하기 에 포스팅 되어있습니다만,
허원철님의 Github Actions 를 사용하는게 더 빠르게 설정하기 좋은것 같습니다.

TIL Repo 생성

새로 알게 된 것들, 오류를 해결한 경험 등을 블로그에 포스팅해서 한글로 공유하고 싶었으나,
오히려 포스팅이다보니 어느정도 갖춰 작성하려는것에 대한 부담감으로 작성을 미루게 되는 문제점이 발생했습니다.

이를 해결하고자 기존에 Notion에 간단하게 정리하거나 가볍게 정리할 내용을
TIL 레포지토리 에 작성하고 있습니다.

🏃 일상


💪 운동

상반기에 잠시나마 운동을 시작 했는데, 퇴사 시기와 맞물리게 헬스장도 끝나서 아직까지 운동을 안하고 있습니다.

운동을 할 때는 운동을 해도 왜 이렇게 체력은 늘지 않고 피곤할까 하며 몰랐는데,
안 하면서 저질 체력을 더 크게 느끼고 있습니다….

이동욱님의 하반기 회고록 포스팅을 보며 자극되는점이 너무 많았고,
더 오래 오래 지금 하고 있는 일을 하기 위해서는 건강이 제일 우선이기때문에 상반기에는 다시 운동을 시작해야겠습니다.

신년 계획


1일 1커밋

12월즈음부터 1일 1커밋을 진행하고 있는데, 이걸로 얻을 수 있는 장점은 잠시나마 커밋을 하기 위해 시간을 내고 있다는것었습니다.

하지만 한달쯤 진행 해 보았는데 이것을 깨뜨리지 않기 위해 오히려 의미없는 커밋을 하고 있는건 아닌가라는 것을 고민하게 되었습니다.

그래도 이것을 이어가기 위해서 무언가 정리하고 공부하게 된다 라는점은 이점으로 자리잡고 있어,
상반기에는 지속하는게 목표이긴하나, 이것때문에 무언가를 포기한다거나 하는식으로 너무 얽매이지는 않도록 해야겠습니다.

프로젝트

매번 흐지부지 되는 프로젝트가 너무 많아서 그저 강의를 따라해서 만들어낸 결과물이 아닌,
혼자서 무언가 만들어낸 결과물이 나올 수 있는 프로젝트를 진행하는게 목표입니다.

진행할 아이템은 많으나 가볍게 시작해서 빠르게 결과물을 내어볼 수 있는게 이중에 무엇일지 생각해보고,
만들어보고싶습니다.

운동

자극제

남들과 나 자신을 비교하는 제 성격이 장점은 아니나, 이 부분을 자극제로 사용할 수 있는 방향으로 긍정적으로 활용 해왔습니다.
그리고 감사하게도 항상 제 가까이에 제가 자극이 될 수 있는 좋은분들이 계셔주셔서 지금의 제가 있을 수 있지 않았을까 생각합니다.

이동욱 개발자님유튜브에서 진행하여 주신 인터뷰회고록 등을 보며 더 열심히, 그리고 꾸준히 해야겠다는 자극을 얻을 수 있었습니다.
특히나 더 오래 하고 싶어서 본인에게 투자하신다는 부분에서는 뭔가 대단하시다고 느껴졌습니다.

하지만 다른사람이 편한 신발이 내게도 편할 수 없는것처럼 곧이 곧대로 따라하는게 아니라
저에게 맞는 방식을 찾아서 제게 좋은 자극이 되어주시는 분들과 같이 꾸준히, 그리고 열심히 해야겠습니다.

일정관리

내가 해오던 것, 해야할 것, 하고싶은것과 개인적인 캘린더 일정 들을 이곳 저곳에 따로 정리하다보니
매번 내가 지금 무엇을 해야할지 무엇을 하기로 했는지를 잊는 경우가 많습니다.

회사 다이어리(미팅 내용정리 및 공유 내용 정리와 일정 기입), Notion(개인적인 일정 또는 내용 정리), 캘린더 앱, 카카오톡 캘린더 등을 모두 따로 관리 하는게 필요한 것만 볼 수 있다는 장점이 있지만,
오늘 무엇을 하기로 했지? 라는 생각이 들 때는 모든것을 들여다 보아야한다는 단점을 요즘들어 느끼고 있습니다.

또한 개인적으로 무언가를 진행해야하고 진행할것이다 라는것이 주어지면 큰 틀만 잡고 잘게 나누지 않아,
기한이 없어 계속 진행이 늘어지는 문제가 있어서 개인적인 일정도 기한을 정하는게 좋을 것 같습니다.

독서

원래부터 책을 가까이 하지 않았었고 책을 읽을 시간이 있다면 관심 있는 기술 서적을 더 많이 읽는 편인데,
정리되지 않은 상태로 말을 하고 글을 적는것을 고치는데 도움이 되지 않을까 싶어
두달에 한권정도는 업무 외의 책을 읽을 수 있지 않을까 생각하고 있습니다.

AWS Dev Day Seoul, 2019 메모

틀린 내용이 있다면 제가 졸아서 잘못 메모했을 수 있습니다…..

AWS Fargate를 사용한 서버리스 컨테이너 활용 하기 - 삼성전자 개발자 포털 사례

  • ECS
  • EKS
  • Fargate for ECS
  • Fargate for EKS (on the roadmap)

ECS

쿠베 없이 간단하게 사용가능

EC2 인스턴스를 직접관리해야하는 단점

Fargate를 활용해 해결 가능

  • 서버가 없는 컨테이너 환경
  • 서비스와 컨테이너에대한설정만 관리
  • ECS 대비 EC2 관리에대한 부담만 덜어짐
  • ECR을 이용해 이미지를 배포할 수 있음
  • Networking - aws
  • LayerStorage - task당 10GB
  • VolumeStorage - 공용 볼륨

QA Automation을 중점적으로 CI/CD를 구축함

SRE

아키텍쳐 ECS 클러스터를 이용함.

Fargate 활용시 → 무중단배포전략 기본 탑재, 빠르게 deploy 가능, 비용 절감

ECS의 EC2옵션에 비해 45%절감(compute 비용만)

task 별로 관리가 가능하기때문

워크스페이스를 CloudFoundry playform 오픈 소스를 사용하여 구현
프로메테우스기반으로 VALET 대시보드 구현

task가 runtime으로 넘어갔을때만 과금이 됨.

클러스터안에 서비스가 매핑

활용 사례

백엔드기준

  • 서치, k-v DB, API

클러스터세팅

  • TG,vpc,subnet,SG

task cpu : 1024 MB , 512 task CPU

Events 탭을 이용하여, 이벤트 발생 확인 가능

build.sh → upload.sh (ECR에 업로드)

ECS workshop - https://ecsworkshop.com/

실시간 데이터 처리를 위한 현대적 애플리케이션 개발 방법

Amplify

CLI 툴체인 및 UI 구성요소 포함하는 클라이언트 프레임워크

전체 앱 구축 테스트 배포 및 호스팅을 위한 dev tool 제공

AppSync

관리형 서버리스 gQL 서비스

다양한 데이터 소스 활용 가능

디바이스가 오프라인일 경우에도 가능

오프라인시 변경된 데이터만 동기화처리

queries → get

mutation → create | update

subscriptions → pub | sub

Cognito

IAM을 모두 제공할 수 없음

Kinesis

DocumentDB

엘라스틱서치 DB 랑 유사하게보임

몽고 DB와 호환됨

초당 수백만건 요청 처리 가능

컴퓨팅과 스토리지 레이어를 분리하여 컴퓨팅 리소스만 확장 가능, 스토리지는 오토스케일됨

데이터를 파티션으로 분산저장(3개의 AZ에 복제)

AppSync를 활용하여 query와 mutation 분리

DevOps 개발자가 되기 위한 쿠버네티스 핵심 활용 예제 알아보기

3개의 az에 마스터 노드 배포

az당 두개의 인스턴스 배포

c타입 인스턴스로 배포됨

deprecated 되는 시점에 마스터노드를 강제 업데이트함.

Latest 버전부터 3개 이내의 버전으로 관리되도록 aws에서 관리해줌

EKS는 명령형 인프라가 아닌 선언형 인프라

VPC ink → Network load Balancer

How To Connect with Kubernetes

  • 쿠버네티스에서 제공하는 로드밸런서
  • ALB ingress → IP가 유동적이라 Lambda에서 처리할 수 있으나 번거로움
  • 쿠버네티스의 Node Port 이용

kube2Iam을 이용해 IAM을 관리

HPA → pod 오토스케일링

Cluster autoscaler → 노드 오토스케일링(pod를 더 이상 배치할 공간이 없을때)

Monitoring

프로메테우스를 통해 수집 → 그라파나를 통해 → cloudwatch 메트릭을 사용해 대시보드 제공

로그 : 엘라스틱서치와 클라우드워치 fluentD

클라우드워치를 두고 로그패턴을 이용해 노티 가능 → 엘라스틱서치로 전송

엘라스틱 서치 Authentication은 cognito

nginx 리버스프록시로 사용해 키바나접근

AWS Xray를 이용해 APM 체크

배포는 Spinnaker를 이용해서 쿠버네티스 배포할때 용이

pod는 엔드포인트도 계속 변경됨
eks 자체 기능으로 IAM과 쿠버네티스의 IAM을 연결하는 기능 제공예정

Monitor

기존에는 가장 성능 좋은 쿠버네티스 로깅 플랫폼 fluentd(루비로 작성됨)
→ fluent Bit이 C로 만들어진 더 고성능을 요구할때 사용할 수 있는 플랫폼

Networking

어노테이션만으로 nlb alb 등 선택 가능
ALB는 L7형태로 ingress controller에서 해석해서 처리

Logging

EFK
pod → fluentd → cloudwatch→ kibana
FluentBit을 사용하면 더 Optimized 할 수 있다.

Application Mesh

기존 서비스 Mesh는 envoy proxy를 사용
AppMesh는 EKS만 쓸 수 있는게 아닌 Fargate ECS EC2 EKS Kube on EC2등에서도 사용가능

Distribute Logging

전체 콜스택 모니터링하기 어려움
X-Ray를 활용
모든 쿼리스트링 모니터링 가능

코드 기반 인프라(IaC)를 활용한 현대 애플리케이션 개발 가속화, 우리도 할 수 있어요

Re-host
데이터센터 → EC2

Re-platform
가상머신 → 컨테이너

Re-factor
모놀리스 → 마이크로 서비스

Re-invent
호스트플릿 → 서버리스

자동화

  • 인프라 구성 자동화
    • 서비스에 필요한 리소스 프로비저닝
  • 애플리케이션 배포 자동화
    • 애플리케이션을 더 효율적, 안전하며, 빠르게 배포
    • 애플리케이션을 빌드, 테스트, 배포

코드기반 인프라의 목적

인프라 변경 사항을 반복적이고 예측 가능하게 함.

CloudFormation

클라우드 인프라 템플릿을 정의하기 위한 언어 - JSON | YAML

1
2
3
4
$ cdk init
$ cdk diff
$ cdk deploy [paramter]
# if you type "y", deploy the app

CDK Deploy 를 활용하면 Cloudformation을 활용해 배포하게됨

cdk를 사용하면 table.grantReadWriteData(fn); 과 같은 함수를 통해 권한을 얻을 수 있음

APIGateway.LambdaRestApi()를 사용하면 API Gateway에 대한 IAM 권한을 가질 수 있음.

→ serverless framework 사용시 serverless.yml 파일에 iam을 설정하던 부분을 함수로 명시 하는거였음.

Loader

ECS Clustuer, ECS Fargate를 이용해 클러스터 생성(규모에 상관없이 재사용가능하도록함)

Monitor

cdk-watchful를 활용하여 cloud watch와 연결 가능

jsii →js로 만든것을 다른언어에서 사용가능하도록 해줌 cdk에서 활용됨

프로세스

Code Commit → CDK 앱과 Lambda 함수 코드는 동일한 리포지토리에 저장됨

Code Build → CdkCodeBuild 프로젝트는 CDK 앱을 synthesize하여 CloudFormation 템플릿을 생성

배포환경은 동일하게 로컬환경은 개발자 본인만을 위한것이다.

클라우드9이나 CloudFormation, 도커등 동일한 환경을 제공할 수 있어야함.

점심 도시락


닭강정, 새우튀김, 갈비찜?돼지고기찜? + 된장국 (나머진 안 먹어봐서 모르겠습니다)

굿즈(SWAGS)

  • 티셔츠
  • 머그컵
  • 방향제
  • 담요
  • 보틀
  • 디퓨저
  • 다이어리

애드센스-테러를-당하다

아침에 눈을 떠서 메일을 확인 하는데,
구글 애드센스팀으로부터 아래와 같은 메일이 도착하였습니다.

애드센스 계정이 30일동안 정지 되었다는 메일이였는데,
하루 수입이 $0.01도 안 됐기 때문에 그냥 그런가보다 했습니다.

그래도 왜 그럴까 싶어 알아보다가 GA를 확인해보니 해당 시간대에 155 세션이 잡혔고,
모두 디바이스가 데스크탑인 국가 정보가 없는 경우 였습니다.

슬프게도 제 블로그는 일 조회수가 155가 안되기 때문에 이럴일이 없었죠….😂

애드센스 관리 페이지를 확인 하였을때도 이와 같이 무효 클릭: 직접 클릭 으로 정지를 당했습니다.

혹시나 애드센스 테러 라는 키워드로 구글에 검색을 해보았더니 유사 사례가 꽤나 있었습니다.

다른분들의 코멘트를 참조하여 이의제기는 신청 했지만, 메일에 기재되어 있듯이 이의제기가 받아 들여질거 같진 않습니다…

그래도 가끔 애드센스 눌리는 재미도 쏠쏠 했는데 아쉽습니다…

2019년 상반기 회고

일년이 어떻게 흘러간지 한해가 지날수록 더 기억이 안 나서
정리의 필요성을 느껴, 올해부터는 회고를 진행해볼까 합니다.

💼 회사


01월~02월

서버리스 아키텍쳐 구현 마무리


12월부터 설계 및 개발을 진행하였던 서버리스 아키텍처를 12월 중순쯤 배포하였으나,
이슈 사항들이 많아 마무리 짓는데 생각보다 오래 걸렸습니다.

외부 싱크 여부를 판단하기 위한 데이터들을 Insert 또는 Update 하다 보니,
RDS 콘솔 상에서 IOPS 쓰기가 1000 이상이 되는 경우가 발생했습니다.

해당 데이터를 레디스(Elastic Cache)나 noSQL(DynamoDB)에 쌓은 후, 다시 RDS로 옮기는 것도 검토해보았지만, 실제 구현할 경우 관리 포인트가 너무 많이 발생하게 되어 연동 속도를 줄이더라도 Lambda의 동시성을 조절하는 것으로 처리하였습니다.

02월~03월

자세히 보기

[ETC]시니어 개발자의 조건을 다시 읽고

시니어 개발자의 조건이라는 포스팅을 2017년 초에 접하고,

북마크에 담아두었다가 오늘에서야 다시 열어보게 되었습니다.

주요 키워드는 아래의 6가지였습니다.

  • 시스템을 알고 서비스를 개발 해야한다.
  • 기반기술을 중요시 해야한다.
  • 적절한 엔지니어링을 택해야 한다.
  • 클린코드가 모든 경우에 정답은 아니다.
  • 애자일은 만능이 아니다.
  • 오픈소스를 무분별하게 가져다 쓰는것 보다, 내부 동작 원리를 이해하고 용도에 맞게 사용해야한다.

    부족한 부분을 기여할 수 있는 프로슈머가 되어야 한다.

필자분께서 결론에 담아주신 내용이 가장 인상이 깊었습니다.

쥬니어와 시니어가 같은 일을 하고 같은 품질의 결과물을 만들어 낸다면
나이는 많고 연봉은 높은 시니어를 반길 이유가 없다.
시니어는 기반 기술에 대한 높은 이해를 바탕으로 쥬니어와는 다른 고품질의 결과물을 만들 수 있어야 한다.
그리고 쥬니어가 성장하고 본받을 수 있는 높은 기술력을 갖추고 리딩할 수 있어야 한다.
단순히 1년의 경력을 10번 반복한 시니어는 아무런 경쟁력이 없다.

2019년의 저는 얼마만큼 위의 여섯가지 키워드에 근접하였을까요

2019년의 저에 대해 되돌아 보았습니다.

자세히 보기

[Database] postgresql와 mysql 뭐가 다를까?

PostgreSQL 과 MySQL의 차이점

  • PostgreSQL은 기본적으로 트랜잭션을 지원합니다(MySQL의 경우 테이블이 InnoDB 타입일 경우에만 지원합니다.)
  • Databse의 하위개념으로 Schema가 있습니다.(MySQL의 Database의 개념은 PostgreSQL의 스키마와 개념이 비슷합니다.)
자세히 보기