WEEK 18 나만무 폴리싱 TIL(7월15일 화요일)

Devkty·2025년 7월 16일

크래프톤 정글(나만의 무기 만들기 WEEK 14 ~ 20)

목록 보기

41/57

[목표]
~~기술적 챌린지 정리!!!!~~
프로젝트 요약 및 본인 커밋 및 댓글 기반 본인 기여도 분석 요약 Ai 기능 추가(저장 및 API 개선)
~~AWS 오피스 아워 참여~~
~~코치님 커피챗 두번(16:30, 17:30)~~
~~더미데이터 생성(진혁이형 진행중)~~
~~발표자료 제작~~

AWS 아마존 오피스 아워(10:00 ~ 12:00)

목적

Jira와 같은 이슈트레킹을 학습하고 각 기업들에 이슈처리 프로세스를 벤치마킹하여 소규모, 대학생 등의 소단위 프로젝트에 도입할만한 이슈트레킹 서비스이다. 추가 기능으로 Ai를 통한 이슈 자동 생성, 코드 품질 검사를 통해 편리함을 제공하기도 한다. (+ 자신의 프로젝트에 대한 정리도 제공)

질문 내용

주제: 현재 제가 구축한 AWS 시스템에 대한 전체적인 평가를 받고, 개선 방안에 대한 조언을 얻고 싶습니다.

AWS를 다음과 같이 구축하였고, EC2는 프론트엔드와 백엔드를 Nginx를 사용하여 통신하는데, 현업에서도 사용하는 방식인지 알고 싶습니다.
→ 각자 따로 분리해서 구현한다. 프론트랑 백엔드랑
현재 구성방식에서 더 높은 가용성을 위한 개선 방법과 현업에서는 어떻게 구축하는지 알고 싶습니다.
→
현재 오토스케일링을 사용하면 오토스케일링을 통해 구축된 EC2는 main 업데이트 시에 수동으로 업데이트를 해야하는데, 개선할 방법에 대해 알고 싶습니다. (자동 업데이트 되게 구현 가능할지?)
→ 깃허브 AMI을 넣는게 맞으면 , 코드 디플로이를 쓰자.
현재 과부하 테스트를 k6를 통해 수행하는데, k6는 EC2 한대에서의 루프 테스트 밖에 안됩니다. 도메인 기반 과부하 테스트를 통해 ALB까지 테스트 할 수 있는 AWS 서비스가 있는지 알고 싶습니다.
(즉, 과부하 테스트를 통해 유저 사용자 수가 급증할 때, 동적으로 EC2가 만들어지는걸 눈으로 확인하고 싶습니다.)
→ 타깃을 API 로 테스트, K6룰 독립적인 EC2로 만들고 계속해서 부하테스트를한다.
현재는 EC2 실시간 모니터링 및 CMD SSH를 통한 pm2 log를 확인하는 방법을 사용하고 있는데, AWS 상태에 대해서 효과적으로 확인할 방법이 있을지 알고 싶습니다. (실시간 모니터링이 반영이 느립니다)
→ 어플리케이션 포퍼먼스, Cloudwatch?, 오픈 텔레멘터리, x레이더?
소켓 통신 서버를 구축하려면 EC2를 따로 올려서 채팅 서비스를 전개하는게 나을지?
→
CORS와 헤더 허용을 CloudFront에서 수동으로 허용해 주는게 맞을지? (Nginx 허용으로만 안됨)
→ 맞음. 바로 ALB로 보내는것도 방법
환경파일인 env 파일은 S3, Codedeploy를 통해 업데이트하는게 맞을지?
→
S3 버킷 연동 추가해도 될지. 이미지, 동영상 업로드 때문에 사용할 것 같다.
→
위와 같이 구성이 되었을때, 탄력적 IP를 제거해도 괜찮을지?
→
오토스케일링 EC2가 생길 때마다 해당 EC2의 보안그룹을 수동으로 열어줘야하나?
→ 수동으로 열어준다. 원래는 분리가 되어 있어서
클라우드 프론트가 캐싱이 계속 되서 무효화를 업데이트마다 설정해줘야하는가?
→ 보통 업데이트를 할 때마다 무효화를 하는게 맞다.

306호 3팀
람다 서버.
도커를 ECR로 띄움. 컨테이너로 도커로 올린다. Fargate, Capacity
추가 질문 사항들은패들렛에 문의하면 된다.

12:00 ~ 14:00

식사를 하고 왔다. 졸려서 강의실에서 졸았다.

14:00 ~ 16:30

AI 서비스 강화를 위한 AWS Bedrock 도입

어제 지성이가 소개한 AWS Bedrock을 사용하여 기존의 Gemini 무료 모델(Flash 2.0)에서 클루드 모델로 업그레이드 하기로 결정했다. 먼저 AWS에서 API, 엑세스키, 비밀 엑세스 키를 발급 받았다.

코치님에게 말씀드릴 이야기 시나리오/상황, 기술적 챌린지 후보군을 작성했다. 자세한 내용은 Codeplanner 종합 내용 확인!

프로젝트 환경설정 파일 .env 사용 방식 변경 요망. (API 유출 가능성 있음)

16:30 ~ 18:10

30분 코치님 커피챗을 진행했다.

18:10 ~ 19:00

식사는 10시에 하고 이야기를 나누었다. 프로젝트와 코치님들의 피드백에 대해서 생각을 했다.

19:00 ~ 23:00

보안 관련 문제가 발생, env와 deploy 파일을 대체할 방법을 강구하여야 한다.
.env파일에 Gemini API값이 들어가 있는데, 해당 파일이 문제이다.

1. .env 파일들을 제거 해야한다.

확인해본 결과 ecosystem.config.js 와 deploy.yml 같은 경우는 깃허브에 올려도 되고, deploy.yml의 문제 되는 EC2 유저명과 서버 IP 주소는 Github Secret으로 해결하는 걸로 했다.

원래는 env 파일의 환경 변수 값들을 모두 Secret으로 해결하려 했지만, 이름이 GITHUB로 시작하면 등록이 안되서 어쩔 수 없이 AWS의 Code Deploy를 쓰는게 좋을 것 같다.

일단 쓰는 방식이 너무 복잡할 것 같은데 본격적으로 작업하기 전에 GPT 코덱스를 써보기로 했다.

일단 deploy.yml에는

ssh -o StrictHostKeyChecking=no ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} << 'EOF’

원래의 배포 코드를 수정했다. 원래는 서버 IP 주소가 평문으로 쓰여 있었는데, 없애기 위해 깃허브 Secret에 해당 내용을 포함시켰다.

뭔가 깨달았다. .gitignore를 사용하면 해당 파일은 아예 안올라가진다. pull을 당기지도 않기 때문에 해당 env파일만 로컬에서 유지만 해주고, 업데이트 될때만 EC2에 수정하면 사용하는데 문제가 없을 것이다. 일단 env 파일을 브렌치와 main에 모두 삭제하고 새로 만든 deploy 파일이 적용되는지 확인해봐야겠다.

새로 업데이트 된다면 어떻게 처리를 하는가?
만약에 서버 파일을 모두 지워야되는 상황이라면, 클론 받아 올때, env는 수동으로 올려주는게 맞나?

그에 관한 GPT 설명은 다음과 같다.
.env 파일을 Git에서 언트랙(untrack) 처리한 상태라면, Git 동기화(풀·머지)만으로는 업데이트가 반영되지 않으므로 서버에 수동으로 적용해야 합니다. 예를 들어 SSH로 접속해 에디터로 직접 수정하거나, scp·rsync 명령으로 로컬에 있는 최신 .env를 전송하는 식입니다.

하지만, 매번 수동으로 올리는 것은 운영상 실수가 생기기 쉽고 번거롭습니다. 따라서 업데이트 프로세스를 자동화하려면 다음과 같은 방식을 고려하십시오.

1. AWS SSM Parameter Store / Secrets Manager 활용

환경변수는 .env 파일이 아니라 AWS SSM(Parameter Store)이나 Secrets Manager에 저장
값이 변경되면 AWS 콘솔 또는 CLI로 한 번만 수정

배포 스크립트에서 매번 SSM에서 값을 불러와 .env를 재생성

aws ssm get-parameters \
  --names VAR1 VAR2 VAR3 \
  --with-decryption \
  --query 'Parameters[].{Key:Name,Value:Value}' \
  --output text \
| awk '{print $1"="$2}' > /path/to/project/.env

이렇게 하면 환경변수 업데이트 시 수동 업로드 없이 배포 자동화 파이프라인에 반영됩니다.

2. 전용 구성관리 도구 도입

Ansible, Chef, Puppet 같은 도구로 .env 파일을 관리
변경된 값만 중앙에서 관리 서버(또는 Git 레포지토리 암호화된 비밀 저장소)에 커밋
배포할 때 구성관리 툴로 EC2에 자동 배포

3. 간단한 스크립트 자동화

만약 AWS 서비스를 사용하지 않는다면,
1. 보안이 보장된 S3 버킷(암호화 활성화)에 .env 저장
2. 배포 스크립트에서 aws s3 cp s3://bucket/.env /path/to/project/.env
3. Git pull 이후 항상 최신 .env를 내려받도록 설정

결론

지금처럼 서버에만 두고 싶다면: 예, 서버에 SSH로 접속해 수동으로 올려야 합니다.
반복적·안전한 운영을 원한다면: AWS SSM / Secrets Manager나 구성관리 도구, S3 기반 자동화 중 하나를 도입해 수동 단계를 제거하십시오.

일단 일차적으로 고친 방법은 다음과 같다. 백엔드 프론트 둘다 같다.

1..gitignore에 .env가 제외 처리한다.

# CI/CD 관련
.env

.env을 깃허브에서만 삭제한다. 캐시를 날리는 것이다.

git rm --cached .env.production
git rm --cached .env.development

로 깃허브에서 삭제한다. 로컬에선 X
그다음 커밋을 한다.

git commit -m "25/07/15 .env 파일 트래킹하지 않음. 그러나 만약, 업데이트를
한다면 수동으로 업로딩 필요. 그리고 deploy.yml의 ip주소및 사용자명 깃허브 시크릿으로 대체"

다음과 같은 과정을 프론트와 백엔드 둘 다 수행하면된다. 추가적으로 다른 팀원들에게 env 파일을 공유해서 pull 당겼을때, 사라지는것을 방지해야한다. 그리고 각자 한명마다 정상적으로 배포가 되는지도 확인하는 것이 좋다.

Github 액션의 deploy.yml 파일 해결

deploy.yml을 다음과 같이 수정하고, 프론트와 백엔드 깃허브 Secret 설정에 들어가서, 해당 값들을 미리 입력해두면 된다. 그러면 알아서 불러와준다.

ssh -o StrictHostKeyChecking=no [ubuntu@3.38.25.129](mailto:ubuntu@3.38.25.129) << 'EOF'

ssh -o StrictHostKeyChecking=no ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} << 'EOF'

위의 방식대로 deploy.yml로 수정한 다음에 깃허브에 올라가는 값을 다른 사람이 확인하지 못하게 패치했다. deploy.yml을 따로 관리하지 않아도 우리의 EC2 IP를 보호할 수 있어 좋아진것 같다.

23:00 ~ 23:45

식사를 하고 왔다. 원래는 KFC를 먹을 예정이었지만 취소되었고, 시간이 없어 라면을 먹었다.

23:45 ~ 02:15

긴 시간을 고민을 했다… 이제 구체화가 많이 됐으니, 혼자 짜는건 안되는 것 같다. 도입부는 주제 선정 배경으로 시작해서 관심도를 높이고, 진실된 우리의 목표를 소개하는걸로 했다. 그런데 시연시간에 어떻게 하는지 모르겠다. 그래서 일단 팀원과 함류 했다.

나는 각자의 팀원들이 능동적으로 발표에 대한 발표나 각자 본인이 개발한 내용에 대한 요약이라도 정리해서 받을 수 있을 줄 알았다. 저저번주와 저번주도 동일하게 진행했으니… 근데 생각보다 팀원 입장에서는 발표가 내 담당이라서 건드리면 안될것 같다고 생각하고 있었다. 코치님 생각과 같다. 각자의 분야에 대한 존중이 크게 작용해서 나온 생각 같다. 그러한 진실된 권호형이 말을 하시니, 내가 배정을 하거나 같이 하자고 부탁하는 것이 옮다고 생각하는 계기가 되었다.

솔직히 말하자면, 부모님 전화를 받으니 슬퍼졌다. 그리고 바쁜 이 상황에 개인적으로 할 일은 하고 있는게 서운해서 그런 것일 수도 있다. 감정이 복잡해지고 슬퍼졌다. 갑자기 확 피곤해진것 같다… 내일은 발표라서 할 건 많은데…

02:15 ~ 06:45

그래서 팀원 다같이 발표 흐름에 대해서 생각해보기로 했다. 컨디션이 안좋아서 진행을 못해서 권호형이 주로 해줬다.

주로 개발자와 PM을 주력적인 역할군으로 선정해서 이야기 해봤다.

밑의 내용은 발표준비를 하며 조사한 내용이다.

데이터를 정제해서 보내주는데 만약에 정제하지 않은 것의 차이 SummaryAI에서 데이터 정제(Preprocessing)를 하고 AI API로 보내는 것과, 정제하지 않고 “날(raw) 데이터”를 그대로 보내는 것의 속도 차이는 실제 서비스 품질과 비용에 큰 영향을 미칩니다.
1. 정제 전/후의 차이점
- 정제하지 않은 데이터
- 이슈/커밋/댓글/PR 등 모든 원본 텍스트, 중복/불필요/의미 없는 데이터까지 포함
- AI API로 보내는 데이터의 “길이(토큰 수)”가 매우 많아짐
- 네트워크 전송량, AI 모델의 처리 시간, 비용 모두 증가
- 정제한 데이터
- 핵심 정보(제목, 주요 메시지, 대표 이슈/커밋 등)만 추출
- 중복/불필요/스팸/의미 없는 텍스트 제거
- AI API로 보내는 데이터의 “길이(토큰 수)”가 대폭 감소
- 처리 속도, 응답 시간, 비용 모두 절감
  
  2. 실제 속도/비용 차이 예측
  
  (1) AI API의 처리 시간 구조
- AI API(Claude, Gemini, GPT 등)는
  
  “입력 토큰 수 + 출력 토큰 수”에 비례해서 처리 시간이 증가
- 입력이 10,000자(약 2,500토큰) → 2~5초
  
  입력이 100,000자(약 25,000토큰) → 10~30초 이상
  
  (모델/서버 상황에 따라 다름)
  
  (2) 실무 예시
- 정제 전:
- 이슈/커밋/댓글 등 전체 원본을 모두 합치면
  
  10~50KB(수천~수만 토큰) → 처리 시간 10~30초, 심하면 타임아웃/에러
- 정제 후:
- 대표 이슈/커밋 20~30개, 제목/핵심 메시지만 추출
  
  2~5KB(수백~2천 토큰) → 처리 시간 1~3초
  
  (3) 속도 개선률(실제 체감)
- 평균적으로 3~10배 이상 빨라짐
- 예: 15초 → 2초 (약 85% 이상 단축)
- 네트워크 전송/파싱/비용까지 포함하면
- 처리 시간, 비용 모두 70~90% 절감
  
  (4) 실제 서비스에서의 체감
- 정제하지 않으면:
- “분석 중...”이 오래 걸리거나,
- AI API에서 “context length exceeded” 등 에러 빈발
- 정제하면:
- 1~3초 내 응답, UX/비용 모두 개선
  
  3. 정리
- 정제하지 않은 데이터:
- 처리 시간 10~30초, 비용 증가, 에러 위험
- 정제한 데이터:
- 처리 시간 1~3초, 비용 절감, 안정적 응답
- 속도 개선률:
- 최소 70~90% 이상
- 실제로는 3~10배 이상 빨라짐
  
  4. 실무 팁
- “대표 이슈/커밋 20~30개, 제목/핵심 메시지”만 추출해서 보내는 것이
  
  속도/비용/품질 모두에서 최적
- AI API의 입력 토큰 수를 2,000~4,000 이하로 유지하는 것이 가장 안정적
  
  결론:
  
  SummaryAI에서 데이터 정제는
  
  “속도, 비용, 품질, 안정성” 모든 면에서 필수입니다.
  
  정제하지 않은 것 대비 최소 3~10배, 70~90% 이상 빠르고 효율적입니다.
대표 이슈/커밋 20~30개, 제목/핵심 메시지만 추출 여기서 대표 이슈의 기준은 어떻게 판단해? 현재 SummaryAI에서 “대표 이슈/커밋 20~30개”를 추출할 때의 기준은 다음과 같습니다.
1. 현행 기준(코드 기준)
- 대표 이슈/커밋은
  
  “타임라인(events)에서 type이 'issue' 또는 'commit'인 항목을
  
  단순히
  
  최신 순(또는 정렬된 순서)으로 최대 30개까지
  
  잘라서 사용”합니다.
- 즉, 중요도/활동량/댓글 수/상태 등 추가적인 정렬이나 필터링 없이
  
  “최근 생성된 순서”로 30개까지만 추출하는 구조입니다.
  
  코드 예시
```
typescriptApply to email.servic...const issues = events.filter(e => e.type === 'issue').slice(0, 30);const commits = events.filter(e => e.type === 'commit').slice(0, 30);
```
- 여기서 events는 프로젝트 타임라인(이슈/커밋/PR/댓글 등 전체 활동)을
  
  생성일 기준으로 정렬한 배열입니다.
  
  2. 실무적 한계
- 중요도, 댓글 수, 완료 여부, 우선순위 등은 고려하지 않고
  
  “단순히 최근 30개”만 추출합니다.
- 즉, “대표”라는 표현은
  
  “가장 최근의 활동”이라는 의미에 가깝고,
  
  “가장 중요한 이슈/커밋”을 의미하지는 않습니다.
  
  3. 확장/고도화 아이디어
- 실제 대표 이슈/커밋을 뽑고 싶다면
  
  아래와 같은 기준을 추가할 수 있습니다.
- 댓글 수/참여자 수가 많은 이슈/커밋
- 상태(open/closed), 우선순위(priority), 라벨(bug/feature 등)
- 본문 길이(설명이 긴 것), 마감일 임박/지연
- AI 요약/랭킹(텍스트 중요도 분석)
- 예시 코드(댓글 많은 순):
```
```tsx
  Apply to email.servic...
  const issues = events
  
  .filter(e => e.type === 'issue')
  
  .sort((a, b) => b.commentCount - a.commentCount)
  
  .slice(0, 30);
```
```
  4. 결론
- 현재는 “최신 순 30개”가 대표 이슈/커밋의 기준입니다.
- 더 “의미 있는 대표 이슈/커밋”을 뽑고 싶다면
  
  댓글 수, 라벨, 상태, 중요도 등 다양한 기준을 추가로 적용할 수 있습니다.
- 필요하다면,
  
  “대표 이슈/커밋 선정 기준”을 고도화하는 로직도 바로 설계/구현해드릴 수 있습니다!
  
  추가로 원하는 대표성 기준이 있다면 말씀해 주세요.
  
  그에 맞는 코드/설계도 안내해드릴 수 있습니다!

속도, 비용, 응답률 개선율을 수치화해서 설명 AI 분석의 속도, 비용, 응답률이 얼마나 개선되는지 수치로 설명드릴 수 있습니다.

1. 속도(응답 시간) 개선율

정제 전(원본 전체 데이터 전송)
평균 응답 시간: 10~30초 (입력 토큰 10,000~30,000 기준)
대용량/복잡한 프로젝트는 30초~1분까지도 소요
정제 후(대표 20~30개, 핵심 메시지)
평균 응답 시간: 1~3초 (입력 토큰 1,000~2,000 기준)
개선율
최소 70~95% 단축
(예: 20초 → 2초 = 90% 단축, 30초 → 3초 = 90% 단축)

2. 비용(토큰/과금) 개선율
AI API(Claude, Gemini, GPT 등)는 입력+출력 토큰 수에 따라 과금
정제 전:
1회 분석당 10,000~30,000 토큰 사용 → 비용 높음
정제 후:
1회 분석당 1,000~2,000 토큰 사용 → 비용 대폭 절감
개선율
최소 70~95% 비용 절감
(예: 1회 1달러 → 0.1달러, 10회 10달러 → 1달러)

3. 응답률(성공률) 개선율
정제 전:
“context length exceeded”, “timeout”, “rate limit” 등 에러 빈발
성공률 60~80% (대용량 프로젝트는 더 낮음)
정제 후:
에러 거의 없음, 빠른 응답
성공률 99% 이상
개선율
성공률 20~40%p 이상 상승

(실패 20~40% → 1% 미만)

4. 요약 표

구분	정제 전(원본 전체)	정제 후(대표 20~30개)	개선율(절감/단축)
속도	10~30초	1~3초	70~95% 단축
비용	10,000~30,000토큰	1,000~2,000토큰	70~95% 절감
응답률	60~80%	99% 이상	20~40%p 상승

5. 실제 체감 예시

정제 전:
“분석 중...”이 오래 걸리고, 종종 실패/타임아웃/비용 폭증
정제 후:
1~3초 내 응답, 거의 실패 없이 안정적, 비용도 저렴

결론:
SummaryAI에서 데이터 정제를 적용하면
속도, 비용, 응답률 모두 70~95% 이상 개선됩니다.
실제 서비스 품질과 운영비용에 매우 큰 차이를 만듭니다.

계속해서 이어서 PPT와 스크립트를 만들었고, 발표준비는 잠자고 와서하는 것으로 했다.

Devkty

모든걸 기록하며 성장하고 싶은 개발자입니다. 현재 크래프톤 정글 8기를 수료하고 구직활동 중입니다.