레딧, 해커뉴스
오픈소스 컨트리뷰터
좋은 개발자는?
- 고객의 문제를 잘 해결하는 것
- 새로운 기술을 배우고
- 다른 분야를 배우고
- 고객이 원하는게 뭔지 배워야한다.
- 필요하면 다 배우고
개발자의 본질은 무엇일까..
라이브러리르 쓸 줄 아는 개발자는 많다 그럼 좋은 개발자는?
고객, 제품, 비지니스 등 문제와 솔루션을 이해하고 해결하는 개발자가 귀한 귀하다.
go, rust,
rhrordml answpfmf 이해하고 해결하려고하지 않았기 때문이다.
그럼 뭘 배워야하지?
(고객의 문제를 잘 해결하는데 필요한)
- 모든 인접 기술
- 기획자는 불친절하다 : 요청으로, "색상 필터를 만들어주세요"
- 색상추출.. 히스토그램?이런것을 알아서 알아야함
- 모든 고객, 시장, 제품, 비즈니스 지식
그럼 무엇을 해야할까?
- 개발하는 과정을 즐기세요
- 새로 배우는 것들 ,
- 언어 프레임워크에 집착하지, 말고 그 아래 시간이 흘러도 바뀌지 않는 것에 집중하자.
- 코어 개발은 살아남는다.
- 아래로 갈수록 더 오랜 시간을 견딘다.
- 적어도 커리어 초기엔 "다양한 경험"과 "배움"을 최우선으로
- 즐기면서 할 수 있는걸
- 프엔 백엔?
- 그냥 하고싶은거..
- 장기적으로는 별거아님
principal engineer track : 진짜 개발이 좋다.
leadership track : 넓은 범위의 기술을 다루고 싶다..vp of engineering. 넓고 얕게.
founder track : 처음부터 하고싶다. 창업..
개발을 할 줄 아는 디자이너, 기획자, 마케터 다좋음..
breath103
2nd session
내가 ai보다 나은게 뭐냐..
- ai도구 활용 > 내업무를 빠르게 개선
- 창의적 문제 해결에 집중 > 반복작업은 ai에 맡기고, 기획, 디자인같은 창의적 작업에 집중
- 새로운 기술 배우기
뭘 준비하냐
- 템플릿화 > 새로운 플젝에 빨리 적용
- 시스템 연결
- 소통
- 프롬프트 설계
인프런 : AWS 강의실
메타 프롬프트 : 23화 메타 프롬프트로 단계별 프롬프트 생성하기
자동화에 참여하기
모니터링 도구
prometheus
amazon cloudwatch
관측 가능성 3요소
metric : 일정 시간 동안 측정된 데이터를 집계한거 -> 이상 징후 감지
tracing : 요청의 이동 경로, 부모자식 관계로 어쩌구.. 전반의 흐름을 확인할 수 있음 -> 전체 흐름 확인
log : 애플리케이션 실행 중 발생하는 텍스트 기록, JSON 혹은 비구조 텍스트 형식 -> 어디서 문제가 발생했는지 확인 가능(디버깅에 용이)
좋은 로그?
- 구조화된 로그
- 맥락 정보 포함 :어떤 api, 환경, 사용자였는지
- 로그 레벨 구분 : 로그 스캔시 중요도에 따라 파악가능
- stack trace, 예외 메시지 기록 : 코드 호출의 이력서 같은 거임 -> 어디서 에러 발생했는지 확인가능
- trace ID, reqeust idㅗ아 같은 식별자 포함 :
문맥이 살아있는 좋은 로그을 남기느게 관측가능석
aws X-ray : 욫ㅇ 데이터를 수집 분석해 문제 원인 식별 및 성능 최적홯는 기능
- computhing, networking, db, messaging연동 가능
- trace map같은걸 제공해 전체적으로 확인이 가능
eventBridge -> lambda-> x-ray
그 외의 모니터링 도구
datadog : saas 기반
open telemetry
ip
레딧
round robin
least connection
트래픽이 몰릴때,,
95%는 round robin, 5%least
실제로는 여러개의 db가 필요함
rock
읽기와 쓰기 db로 분리되어있는게 좋음.
읽기 전용 db가 더 많은 일을 한다? 하지만, read가 더 많다. 더 많이 씀.따라서 트래픽이 많으면 더 많이 사용함
영속성
리더에서는 아직 반영이 안되기때문.
cdn : 정적인거를 다룸, 캐싱
청크된 조각들을 볼수있도록해서서 영상처리
메인서버, 잡무서버(워커)
메인서버 부하가커서
워커가 필요할때 메이서버에서 가져올 수 있도록 : polling
message queue & worker - 티켓팅같은거에 많이쓰임..
카프카와같은 큐를써서 밀어넣어
msa?
엘라스틱 서치? : indexing
mau?
다이나모 디비 - nosql
시스템 디자인
- 해시디자인
- 인덱싱
- 웹소켓 커넥션
- godb,, 지도를 어떻게 구역을 나눌거냐
동적인 맥락을 이해하는 시스템
LLM & RAG
context가 중요하다
vector RAG : 원본데이터를 청크 단위로 나누고 > 각 청크를 임베딩 모델에 넣으면 > 각 문자열을 숫자로 만들고 > 그 숫자를 벡터 디비에 넣는다. > 본격적 rag
질문을 임베딩 모델에 넣음 > 벡터 디비 >llm 에 넣음 > 결과반환
의미적 유사한것 뿐만 아니라 밖에있는 정보들을 합쳐서 만들어야한다.
Graph RAG
선수지식: knowledge Graph : 현실 세계에서 사람(entity > property)과 관계(relationship)들을 그래프(triple) 꼴로 나타낸것
이런것들이 저장되어있는게 graph RAG - modern AI
HITL
: garbage in, garbage out를 방지하는 흐름. 중간에 validation을 넣는다. -> 사용자가 해당 피드백을 받고 다시 넣는다.
Amazon OpenSearch Service (aws vector db)
Amazon Nepture(aws graph db)
queue에 넣어서
sagemaker?
aws graphRAG Toolkit
- indexing
- quering
amazon bedrock knowledge bases graphRAG
클라우드네이티브 : 클라우드 기수을 잘 쓰는 sw를 만드는 방식
gitops : git코드 기반으로 인프라를 자동화를 만드는 방식
argo vs. flux
요구사항 분석 도구 비교 (poc) > 도입 후 비교
깃헙 : hnnynh
서버리스
- 인프라 관리 = 클라우드
- 서버는 있다.
- 사용한만큼 지불
- 빠르게 구현가능
- 비용 효율성
- 안정적 서버
-
- 예측 불가 비용
-
- coldstart문제 > 동시성, warm-up lib로 해결가능
-
- 클라우드 플랫폼 종속
-
- 불편한 테스트 / 인프라 관리 어려움 > aws sam으로 극복가능
- 람다 : FaaS
- lambda trigger : 자동으로 실행시키는 이벤트 소스
- eventBridge
- 이벤트 버스 존재
- api gateway
- rest api~ websocket api지원
- api를 쉽게 게시, 유지 관리..
- dynamoDB
- 파티션 키, 정렬 키의 개념이 존재
- 조인 불가. 따라서 테이블 설계가 중요/ rdbms와 역순으로 테이블 설계 필요
- 일관된 반응 속도 보장
- ttl
full serverless architecture
- 빠르게 애플리케이션을 만들 수 있음
- 여러 serverless resource와 통합
- 쉽게 이벤트 드리븐 아키텍처 구현
다른 서비스와 통합
lambdaLith
