2025년 3월 23일 일요일

AWS 레소스 중 SNS와 SQS에 대해

AWS (아마존 웹 서비스)에는 정말 많은 레소스가 제공되는데 그 중 현업에서 흔하게 쓰고 있는 것이 있는데 이게 SNS와 SQS다.  

처음에 이걸 쓸때, 도대체 뭔 차이인지 잘 몰라서 헷갈렸었다. 이름도 비슷하다.

SNS는 Simple Notification Service의 약자, SQS는 Simple Queue Service의 약자.

이미지를 찾아봤는데, 아래의 이미지는 https://www.geeksforgeeks.org/amazon-sns-vs-sqs/ 에서 카피한 이미지. 



SNS 는 이름에 notification이 들어가 있고, 이를 통해 유추할 수 있듯이, 어떤 서비스를 실행하다가 통지 (notification)을 보내고 싶을때 SNS를 쓰는거다. 테크니컬리 설명한다면, AWS 콘솔 들어가서 SNS를 생성하던지 아니면 CDK 같은 코드로 SNS를 생성한다.  AWS에 어떤 레소스를 생성하면 ARN이라는 유일한 ID 가 부여되는데 이 ARN (그 SNS의 이름 같은거다)를 가지고 이 SNS에 통보를 보낼 수 있는 것이다.  물론, 이렇게 통보를 보내려면 permission을 가져야 한다.  하여간 통보를 보내면, 이 통보 (notification)을 처리하는 방법은 원하는대로 다양하게 구현할 수가 있는 것이다.

위의 이미지에서 보면, 어떤 경우는 Lamba 함수로 그걸 처리하게 할 수도 있고, SQS로 보낼 수도 있고, 이메일을 보낼 수도 있다. 구현하기 나름이다.

이때 SQS를 활용하는 경우가 많은데, 그래서 SNS와 SQS는 거의 함께 친구처럼 쓰이게 된다.

그럼 SQS는 뭔가? 이건 말 그대로 Queue다.  SQS를 생성하겠다고 버튼을 누르면 이렇게 큐의 종류를 선택할 수 있다. Standard Queue와 FIFO 중 선택이 가능하다.  FIFO는 First-In First-Out이라고 먼저오면 먼저 나가는 거다. Standard Queue는 그 순서를 보장하지 않는다. 먼저왔어도 나중 나가기도 한다는 거다.



내가 처음 SNS와 SQS를 가지고 일을 할때, 헷갈렸던 부분은, SNS에 notification을 보내고, 이걸 그냥 람다로 처리해도 되고, SNS에 SQS를 연결하고 (이걸 subscribe 구독이라고 한다) SQS에 람다를 연결해 메시지를 처리해도 된다.  둘다 마찬가지 결과다. 근데 왜 굳이 SNS에 SQS를 연결하고 람다를 연결하는 구찮은 구조를 가질까?

나름 생각해보건데, my service -> send notification -> SNS -> SQS -> lambda.

이렇게 가져갈 경우, SQS에 메시지를 보낸후, 람다에서 이 메시지를 consume (읽어서) 하여 처리하게 되는데, 이때 만일 뭔가 잘못될 경우, 즉 람다에서 메시지 처리중 exception이 발생한다. 이때 이 메시지는 몇번 다시 consume 되어 람다에 의해 재처리가 되다가, 결국 retrial 갯수가 max에 다다를 경우, 그 메시지는 SQS에 연결된 DLQ (Dead Letter Queue)로 보내지게 된다.  물론, 이때 DLQ를 생성하여 SQS에 연결한 경우에 이렇게 된다.  그러니 꼭 DLQ를 만들어 두도록 해야 함.

DLQ에 메시지가 들어가면, 나중에 알람을 통해, 뭔가 잘못된 메시지가 있음을 알게 되고 뭐가 잘못됬는지 디버깅을 하는 것이다. 만일 SNS와 람다 사이에 SQS가 없다면, 메시지 처리 중 exception 받은 메시지가 어찌될지는 잘 모르겠다.


또 다른 usecase로는, 우리 팀의 서비스가 뭔가 일을 처리했다. 어떤 조건이 만족할때, 예를 들어, 어떤 요청을 처리 시, complete 상태로 바뀔때마다 이것에 관심있는 다른 팀에 이를 알려주고 싶을때, SNS를 생성하여 여기에 notification을 발송한다.


이 정보에 관심 있는 다른 팀이 있다면, 그 팀은 자기네 소유로 SQS를 만든 후, 우리에게 subscription 요청을 한다.  그러면 우리팀의 SNS와 자기네 팀의 SQS를 연결한 후, SQS에 이 관심있는 메시지를 수신하여 자기네 마음에 맞게 처리하는 것이다.

이것은 de-coupling의 좋은 예다.  우리는 그저, requestID와 requestStatus를 담아 해당 SNS로 notification을 발송한다.


연결된 SQS를 통해 메시지를 받은 다른 팀의 서비스가 이를 수신후 자기네들이 원하는대로 이정보를 사용하는 것이다. 




2025년 2월 26일 수요일

미국 주요 대학교 대입 정시 발표 3월 예정인 학교들

 2025년 3월에 미국 대학들의 정시(Regular Decision) 합격자 발표가 예정되어 있다. 아래는 일부 대학들의 예상 발표 일정일 이다.

  • 보스턴 대학교(Boston University): 3월 말
  • 브라운 대학교(Brown University): 3월 말
  • 카네기 멜론 대학교(Carnegie Mellon University): 4월 1일까지
  • 컬럼비아 대학교(Columbia University): 3월 말
  • 코넬 대학교(Cornell University): 3월 말
  • 다트머스 대학교(Dartmouth College): 3월 말
  • 듀크 대학교(Duke University): 3월 말 또는 4월 초
  • 에모리 대학교(Emory University): 4월 1일까지
  • 조지타운 대학교(Georgetown University): 4월 1일까지
  • 하버드 대학교(Harvard University): 3월 말
  • 뉴욕 대학교(New York University): 4월 1일까지
  • 노스웨스턴 대학교(Northwestern University): 3월 말
  • 펜실베이니아 대학교(University of Pennsylvania): 3월 말
  • 프린스턴 대학교(Princeton University): 3월 말
  • 스탠퍼드 대학교(Stanford University): 4월 1일까지
  • 예일 대학교(Yale University): 3월 말

이러한 일정은 대학마다 다를 수 있고, 일부 대학은 3월 중순부터 발표를 시작하기도 한다고 하며, 정확한 발표 날짜는 각 대학의 공식 입학처 웹사이트에 나와 있다고 한다.


다음은 주요 주립대 발표 예정일.

  • 캘리포니아 대학교 버클리(University of California, Berkeley): 3월 28일
  • 워싱턴 대학교(University of Washington): 3월 1일에서 15일 사이
  • 미시간 대학교 앤아버(University of Michigan – Ann Arbor): 4월 초
  • 노스캐롤라이나 대학교 채플힐(University of North Carolina – Chapel Hill): 3월 31일
  • 위스콘신 대학교 매디슨(University of Wisconsin – Madison): 3월 31일까지

2025년 2월 24일 월요일

개발시 자주 쓰는 git 명령어

회사에서 일할때 자주 쓰는 명령어 중 git이 있다. 버전 콘트롤 툴인데 command line으로 자주 쓴다. 자주쓰는 명령어를 모아 보았다.

파일 상태 확인 및 변경 사항 저장

  • git status → 변경된 파일 확인
  • git add <파일명> → 특정 파일 스테이징
  • git add . → 모든 변경된 파일 스테이징
  • git commit -m "커밋 메시지" → 변경 사항 커밋

git add . 를 쓰면 모든 변경된 파일을 스테이징하지만, 만일 어떤 파일은 git add하고 싶지 않을 경우, 그런 파일을 .gitignore 파일에 넣어두면, git add . 에서 자동으로 제외된다.

이미 커밋하고 난 후, 만일 커밋 메시지를 변경하고 싶으면 git commit --amend 하면 고칠 수 있다.

두개 이상의 커밋을 스쿼시 (합치고 싶을때) git rebase -i 를 쓴다.

브랜치 관련 명령어

  • git branch → 현재 브랜치 목록 보기
  • git branch <브랜치명> → 새 브랜치 생성
  • git checkout <브랜치명> → 특정 브랜치로 이동
  • git switch <브랜치명> → 최신 방식으로 브랜치 이동
  • git checkout -b <브랜치명> → 새 브랜치 생성 후 이동
  • git switch -c <브랜치명> → 새 브랜치 생성 후 이동 (최신 명령어)
  • git merge <브랜치명> → 현재 브랜치에 다른 브랜치 병합
  • git branch -d <브랜치명> → 브랜치 삭제

원격 저장소 관련 명령어

  • git remote add origin <저장소 URL> → 원격 저장소 추가
  • git remote -v → 원격 저장소 목록 확인
  • git push origin <브랜치명> → 변경 사항을 원격 저장소로 푸시
  • git push -u origin <브랜치명> → 브랜치를 원격 저장소에 업로드하고 추적 설정
  • git pull origin <브랜치명> → 원격 저장소의 변경 사항을 가져와 병합
  • git fetch → 원격 저장소의 변경 사항 가져오기 (병합 X)

로그 및 변경 사항 확인

  • git log → 커밋 내역 확인
  • git log --oneline --graph → 간략한 커밋 내역 확인
  • git diff → 변경된 파일 내용 비교
  • git diff --staged → 스테이징된 파일과 최신 커밋 비교

되돌리기 및 리셋

  • git reset --soft HEAD~1 → 마지막 커밋 취소 (변경 사항 유지)
  • git reset --mixed HEAD~1 → 마지막 커밋 및 git add 취소 (파일 변경 내용 유지)
  • git reset --hard HEAD~1 → 마지막 커밋 및 변경 사항 모두 삭제
  • git revert <커밋ID> → 특정 커밋 되돌리기 (기록은 유지)

기타 유용한 명령어

  • git stash → 현재 변경 사항을 임시 저장
  • git stash pop → 저장된 변경 사항을 다시 적용
  • git tag <태그명> → 태그 추가
  • git show <태그명> → 태그 정보 확인

2025년 2월 23일 일요일

아마존 6주년 - 100% RTO (Return To Office)

어느새 다음주면 아마존에서 일한지 6주년이 다가온다. 2019년 2월의 어느날 미국 시애틀에 새로이 둥지를 튼지 벌써 6년이 되었다는 얘기.

초등학교를 졸업하고 미국으로 온 우리 아이들은 어느새 고등학교 시니어 주니어가 되어있다.

올해 초부터 100% RTO (사무실 복귀) 명령이 내려져, 이제는 다시 매일 시애틀로 출근해야 하는 일상이 펼쳐졌다.  

100% RTO??  어떨까 걱정했는데,  정말 힘들다.  많은 이들이 불만을 가지고 있으나, 어쩌겠냐. 나가야지.

그나마 다행인건, 작년 가을부터 첫째 아이가 차를 몰고 직접 학교를 가게 되어, 둘의 등교는 알아서 가는걸로.  하교 스케줄이 달라, 내가 둘째 하교만 챙겨주면 되기 때문에 한결 편해졌다. 정말 죽으라는 법은 없는지, 아이들 학교 등하교와 여러가지 액티비티를 어떻게 챙길 것인가. 하는 찰나, 코비드가 발발.  남편은 계속 회사에 가야 했으나, 나는 집에서 일을 할 수 있었고.  아이들이 학교로 돌아간 후에도 나는 한동안 원격 근무로 아이들을 실어나를 수 있었던 것에 감사한다.

100% 사무실 복귀라고는 하지만, 교통 체증이 엄청 심한 시간대를 피하기 위해, 나는 아침 일찍 집을 나서고 점심시간 쯤 집으로 돌아온다.  오전에 일일 회의나 대부분의 회의들을 주로 잡아 회의를 마치면 집에 돌아와 점심먹고 오후 업무를 하고. 저녁 먹고 조금 더 일을 하는 일상이다.

우리 팀의 다른 팀원들은 대부분 11시쯤 회사에 출근한다. 어떤 애는 1시가 되어 나오는 애도 있다. 그러면, 나는 집에 가고 그애는 나오고 마주칠일이 거의 없다. 

우리팀 대부분이 20대 젊은이 들이라, 아침에 일찍 나오는 사람은 나밖에 없다.  나두 젋었을때를 되돌아보면 아침 잠이 많았었는데, 나이 들수록 아침잠이 줄어드는거 같기도 하다. 

미국 주식 - QBTS 어떤가요

요즘 미국 주식 안하는 사람은 없을 것이다. 더군다나 미국에 살고 있으니 자연히 미국 주식에 투자를 하고 있다.

내가 관심있어 하는 종목 몇 가지를 좀 뒤져 보았다.

오늘은 QBTS에 대해 살펴볼까 한다. QBTS는 티커이고 회사의 정식이름은 D-Wave Quantum.

어떤회사인가?

D-Wave Quantum Inc. (NYSE: QBTS)는 1999년에 설립된 양자 컴퓨팅 시스템, 소프트웨어 및 서비스를 개발하고 제공하는 선도 기업이다.  D-Wave Systems

세계 최초로 상용 양자 컴퓨터를 공급한 회사로, Advantage라는 양자 컴퓨터를 비롯해 오픈 소스 파이썬 도구 모음인 Ocean, 클라우드 기반 서비스인 Leap 등을 제공한다.

작년 양자컴퓨터 돌풍이 불면서 주가가 상승한 회사 중 하나다.

현재 주가수준과 주가전망

 2025년 2월 22일 기준으로 $7.25 이다.  

애널리스트들의 1년 평균 목표 주가는 $7.75로, 최고 $11.55에서 최저 $2.52까지 다양함.

또한, 2029년까지의 평균 주가 전망은 $8.22로, 최고 $11.47, 최저 $4.97로 예측된다고 함.

한편, 일부 애널리스트는 목표 주가를 $3.00에서 $4.00 사이로 설정하기도 함.  




나의 매수가와 시점

2월 23일 현재 400주를 보유 중인데, 두번에 걸쳐 매수하였다.
(1차 매수) 2025/01/08 : 100주  평균단가 $6.14
(2차 매수) 2025/01/27: 300주 평균단가 $5.68

현재 주가 7.25달라를 기준으로 25.10%의 수익을 기록 중이다.
지금은 주가가 조금 주춤한 상태인데, 2025년 1월 13일, 메타의 CEO인 마크 저커버그는 양자 컴퓨팅의 실용화에 대해 회의적인 견해를 밝혔다. 그는 "양자 컴퓨팅이 진정한 실용적인 패러다임이 되기에는 아직 멀었다"고 언급했다.

이와 유사하게, 엔비디아의 젠슨 황 CEO가 CES 2025에서 "실용적인 양자 컴퓨팅은 15~30년 후에나 가능할 것"이라고 말했다. 이런 견해들이 주가 하락에 영향을 미쳤다.

하지만, 양자컴퓨터가 한 순간의 테마로 사그라들거라 생각하지는 않는다.  그래서 좀더 길게 가져가 볼 생각이다.



AWS 레소스 중 SNS와 SQS에 대해

AWS (아마존 웹 서비스)에는 정말 많은 레소스가 제공되는데 그 중 현업에서 흔하게 쓰고 있는 것이 있는데 이게 SNS와 SQS다.   처음에 이걸 쓸때, 도대체 뭔 차이인지 잘 몰라서 헷갈렸었다. 이름도 비슷하다. SNS는 Simple Notifi...