카테고리 없음

2025 ACC 컨퍼런스 방문기

이히당 2025. 6. 16. 11:32

레딧, 해커뉴스
오픈소스 컨트리뷰터

좋은 개발자는?

  • 고객의 문제를 잘 해결하는 것
    • 새로운 기술을 배우고
    • 다른 분야를 배우고
    • 고객이 원하는게 뭔지 배워야한다.
  • 필요하면 다 배우고

개발자의 본질은 무엇일까..
라이브러리르 쓸 줄 아는 개발자는 많다 그럼 좋은 개발자는?
고객, 제품, 비지니스 등 문제와 솔루션을 이해하고 해결하는 개발자가 귀한 귀하다.

go, rust,

rhrordml answpfmf 이해하고 해결하려고하지 않았기 때문이다.

그럼 뭘 배워야하지?

(고객의 문제를 잘 해결하는데 필요한)

  1. 모든 인접 기술
    1. 기획자는 불친절하다 : 요청으로, "색상 필터를 만들어주세요"
    2. 색상추출.. 히스토그램?이런것을 알아서 알아야함
  2. 모든 고객, 시장, 제품, 비즈니스 지식

그럼 무엇을 해야할까?

  1. 개발하는 과정을 즐기세요
    1. 새로 배우는 것들 ,
  2. 언어 프레임워크에 집착하지, 말고 그 아래 시간이 흘러도 바뀌지 않는 것에 집중하자.
    1. 코어 개발은 살아남는다.
    2. 아래로 갈수록 더 오랜 시간을 견딘다.
  3. 적어도 커리어 초기엔 "다양한 경험"과 "배움"을 최우선으로
    1. 즐기면서 할 수 있는걸
  4. 프엔 백엔?
    1. 그냥 하고싶은거..
    2. 장기적으로는 별거아님

principal engineer track : 진짜 개발이 좋다.
leadership track : 넓은 범위의 기술을 다루고 싶다..vp of engineering. 넓고 얕게.
founder track : 처음부터 하고싶다. 창업..

개발을 할 줄 아는 디자이너, 기획자, 마케터 다좋음..

breath103

2nd session

내가 ai보다 나은게 뭐냐..

  1. ai도구 활용 > 내업무를 빠르게 개선
  2. 창의적 문제 해결에 집중 > 반복작업은 ai에 맡기고, 기획, 디자인같은 창의적 작업에 집중
  3. 새로운 기술 배우기

뭘 준비하냐

  • 템플릿화 > 새로운 플젝에 빨리 적용
  • 시스템 연결
  • 소통
  • 프롬프트 설계

인프런 : AWS 강의실
메타 프롬프트 : 23화 메타 프롬프트로 단계별 프롬프트 생성하기
자동화에 참여하기

모니터링 도구
prometheus
amazon cloudwatch

관측 가능성 3요소
metric : 일정 시간 동안 측정된 데이터를 집계한거 -> 이상 징후 감지
tracing : 요청의 이동 경로, 부모자식 관계로 어쩌구.. 전반의 흐름을 확인할 수 있음 -> 전체 흐름 확인
log : 애플리케이션 실행 중 발생하는 텍스트 기록, JSON 혹은 비구조 텍스트 형식 -> 어디서 문제가 발생했는지 확인 가능(디버깅에 용이)

좋은 로그?

  1. 구조화된 로그
  2. 맥락 정보 포함 :어떤 api, 환경, 사용자였는지
  3. 로그 레벨 구분 : 로그 스캔시 중요도에 따라 파악가능
  4. stack trace, 예외 메시지 기록 : 코드 호출의 이력서 같은 거임 -> 어디서 에러 발생했는지 확인가능
  5. 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
728x90