사내 IaC 템플릿의 리소스가 하나의 main.tf에 집중되어 있어 변경 시 영향 범위를 파악하기 어렵다고 판단했습니다. 네트워크·애플리케이션·데이터베이스 등 역할별로 Terraform 구성을 분리하고 OpenTofu 기반으로 재정비해 인프라 변경과 유지보수가 쉬운 구조로 개선했습니다.

Secrets Manager로 관리하던 RDS 비밀번호가 GitHub Actions 배포 과정에서 `.env`에 기록되고 Artifact에 포함되는 것을 확인했습니다. 비밀값이 CI/CD 산출물에 남지 않도록 애플리케이션 실행 시 Secrets Manager에서 직접 조회하도록 변경했습니다.

개발 환경에 Elastic Beanstalk·EC2·IAM Role 전반의 권한이 부여되어 있어 하나의 자격증명이 침해될 경우 영향 범위가 커질 수 있다고 판단했습니다. 실제 배포와 운영에 필요한 권한을 기준으로 IAM 정책을 재정비하고, 외부 요청도 ALB → Application Server → RDS 경로에서 필요한 통신만 허용하도록 Security Group을 구성했습니다.

Elastic Beanstalk 첫 배포가 완료되지 않는 상황에서 AWS 리소스 생성 문제인지 컨테이너 실행 문제인지 구분하기 위해 CloudFormation 상태부터 EB·컨테이너 로그까지 계층별로 확인했습니다. 이를 통해 인프라 생성은 정상임을 확인하고 nginx 설정과 Rust 빌드 산출물로 원인을 좁혀 배포를 완료했습니다.

나라장터 첨부파일은 원본 URL이 만료되거나 접근이 제한될 수 있어, 모든 상세 데이터를 미리 적재하는 방식으로는 안정적인 문서 제공이 어렵다고 판단했습니다. 공고 목록만 주기적으로 수집하고 상세 정보는 조회 시점에 가져오도록 분리했으며, 첨부문서는 서버에서 수집해 S3에 재호스팅하여 원본 URL 상태와 관계없이 확인할 수 있도록 구성했습니다.

기존에는 Uptime Kuma로 서비스의 정상 동작 여부만 확인할 수 있어, 장애가 발생했을 때 어떤 컨테이너와 구간에서 문제가 생겼는지 파악하기 어려웠습니다. 이를 개선하기 위해 cAdvisor·Prometheus로 컨테이너 메트릭을, Loki로 애플리케이션 로그를 수집하고 Grafana에서 함께 확인할 수 있도록 모니터링 환경을 고도화했습니다.

기존 Docker 배포 과정에서 배포 실패나 컨테이너 교체 시 502 Gateway 오류가 발생해 사용자 요청이 영향을 받는 경우가 있었습니다. 새 버전의 정상 동작을 확인한 뒤 트래픽을 전환할 수 있도록 Blue-Green 배포 구조를 적용해 배포 과정의 서비스 중단 위험을 줄였습니다.

하나의 비즈니스 기능을 여러 솔루션에서 각각 구현하면 기능이 늘어날수록 동일한 로직을 반복 개발하고 검증해야 하는 문제가 생길 수 있다고 판단했습니다. 비즈니스 로직은 원본 서비스의 API를 그대로 호출해 재사용하도록 설계하고, 외부 솔루션의 안전한 API 호출을 위해 서비스 키·요청 시각·본문 해시를 조합한 HMAC-SHA256 서명 검증을 적용했습니다.

스케줄러와 API에 흩어진 구독 로직의 상태 모호성과 예외를 방지하기 위해, 4개 상태와 8개 이벤트의 상태 머신으로 정형화해 복잡한 결제 규칙을 단순화했습니다.

결제·환불 판단 로직에서 데이터베이스와 결제 대행사(PG) 연동을 분리하여, 시간 대기 없이 156개의 예외 및 환불 케이스를 0.91초 만에 확인하는 자동 테스트를 구축했습니다.

상태 머신 기반 검증을 통해 좌석 증설 시 환불 계산 오류와 스케줄러 복구 시 발생할 수 있던 이중 청구 위험을 출시 전 조기에 발견하여 수정했습니다.

홈서버에서 메일 발송까지 직접 운영하려 했지만, 주거용 인터넷 환경의 SMTP 포트 제한과 메일 서버 운영에 필요한 네트워크 조건을 확인했습니다. 메일 인프라까지 직접 관리하는 것은 운영 비용이 크다고 판단해, 메일 발송은 외부 SMTP에 위임하는 구조로 변경했습니다.

홈서버의 공인 IP와 관리 포트를 외부에 직접 노출하지 않기 위해 Proxmox와 서버 관리 접근은 Tailscale VPN으로 제한했습니다. 배포한 웹 서비스는 서버 포트를 직접 개방하지 않고도 인터넷에서 접근할 수 있도록 Cloudflare Tunnel을 통해 공개했습니다.

초기에는 로그인 이후에만 서비스를 확인할 수 있도록 구성했지만 실제 사용자들이 가입 단계에서 이탈하는 것을 확인해, 인증보다 서비스의 핵심 기능을 먼저 경험할 수 있도록 진입 흐름을 변경했습니다.

Investing.com은 검색 페이지와 기사 본문의 구조가 달라 수집 방식을 나눴습니다. 검색 결과 탐색은 Selenium으로, 기사 본문은 requests·BeautifulSoup으로 처리하고 Alpha Vantage 데이터까지 LangChain Document 형식으로 맞춰 하나의 파이프라인에서 다룰 수 있도록 구성했습니다.

여러 종목의 뉴스가 검색 결과에서 섞이지 않도록 뉴스를 700자 단위로 나누고 100자 overlap을 적용했습니다. ChromaDB에서는 symbol metadata filter와 top-k 5 검색을 사용해 선택한 종목의 문맥만 RAG에 전달했습니다.

로컬 sLM의 감성 분류 결과가 모델과 입력에 따라 흔들리는 문제를 줄이기 위해 출력 검증·재시도·neutral fallback을 적용했습니다. 이후 Financial PhraseBank 50개 샘플로 모델별 정확도를 비교해 실제 파이프라인에 사용할 모델과 설정을 검증했습니다.

생성된 요약을 감각적으로 비교하지 않도록 10개 종목을 대상으로 정확성·완성도·간결성을 평가하는 LLM-as-Judge를 구성했습니다. 모델별 점수와 승자·판단 근거를 JSON으로 저장해 모델 간 품질 차이를 확인할 수 있도록 했습니다.

주제 작성 > 댓글 참여 > 실시간 세션 > 결과 아카이브로 이어지는 협업 흐름을 설계해 지속적인 지식 공유 경험을 구현했습니다.

TanStack Start 기반 서버 함수 구조를 활용해 인증, 주제 작성, 세션 제어, 댓글·인사이트 저장 등 주요 동작을 타입 안정성이 있는 API 흐름으로 구성했습니다.

Polling 방식에서 6명 참여 기준 세션당 1만 건 이상의 요청이 발생하는 문제를 확인하고, Server-Sent Events(SSE) 기반 실시간 통신 구조로 전환했습니다. 이를 통해 불필요한 반복 요청을 줄이고, 여러 사용자가 동시에 참여하는 세션에서도 상태 변경, 댓글, 인사이트가 실시간으로 동기화되도록 구현했습니다.

팀원들의 사용 의견을 수렴한 결과, 웹사이트에 직접 접속해야 하는 과정에서 세션 참여와 알림 인지가 늦어진다는 문제를 확인했습니다. 이를 해결하기 위해 Tauri 기반 데스크톱 실행 환경과 알림 기능을 도입하여 기존 웹 서비스를 데스크톱 사용 흐름으로 확장하고, 새로운 세션과 주요 이벤트를 즉시 인지할 수 있도록 개선했습니다.

Playwright E2E 테스트로 주제 작성, 권한별 세션 참여, 실시간 동기화, 결과 확인, 삭제 흐름까지 주요 사용자 시나리오를 검증했습니다.

HWP 문서는 항목과 양식을 사용자가 직접 이해해야 작성할 수 있다는 진입 장벽이 있다고 판단했습니다. HWP Schema에서 필요한 필드를 질문으로 변환하고, 이전 답변에 따라 다음 질문이 달라지는 채팅형 입력 흐름을 설계해 문서 구조를 몰라도 순서대로 작성할 수 있도록 구성했습니다.

STT를 위해 원본 음성을 서버로 그대로 전달하면 민감한 음성 데이터가 불필요하게 서버까지 이동한다고 판단했습니다. 클라이언트와 서버의 처리 범위를 다시 나누고, Rust/WebAssembly로 VAD·RMS 계산·WAV 인코딩 등 전처리를 브라우저에서 수행한 뒤 필요한 음성 데이터만 STT 서버로 전달하도록 구성했습니다.

음성 분리는 기능이 동작하는 것보다 실제 발화 속도와 주변 소음에서도 안정적으로 끊어지는지가 더 중요하다고 판단했습니다. 별도 플레이그라운드에서 다양한 환경을 반복 테스트하며 VAD 임계값과 발화 구간 파라미터를 조정해 STT 입력 품질을 검증했습니다.

채팅과 음성 입력만으로는 키보드 사용이 어렵거나 종이에 익숙한 사용자의 입력 방식까지 포괄하기 어렵다고 판단했습니다. 손글씨 OCR과 모바일 입력 흐름을 추가하고, 실제 모바일 시연 과정에서 발생한 file input·touch event·animation 충돌을 수정해 입력 방식과 사용 환경의 범위를 확장했습니다.

초기 단일 측정에서 도메인 구조 비용이 56% 감소했으나 5회 반복 측정 후 평균 +1.8%(비용 +11.3%, 토큰 +13.6%)로 수렴하는 것을 관찰하여 단일 결과가 아닌 반복 측정의 필요성을 입증했습니다.

전역 루트 AGENTS.md 단일 배치(비용 -3.4%)보다 작업 위치와 가까운 17개 로컬 AGENTS.md 지역화 배치(비용 -9.8%)가 AI Agent의 비용과 토큰을 더 효과적으로 절감함을 입증했습니다.

AI가 직관적 폴더 트리보다 심볼 앵커 맵, 책임 경계, 금지 패턴과 대안, 코드 밖의 함정을 중심으로 맥락을 파악한다는 점을 정립하고 AGENTS.md 작성 원칙을 제시했습니다.

ZIP, RAR, 7z, tar 등 주요 압축 포맷을 지원했습니다.

드래그앤드롭 업로드, 출력 경로 선택, 진행률 표시, 변환 전후 트리 비교 기능을 구현했습니다.

rayon과 crossbeam을 활용해 병렬 처리를 적용했고, ZIP 기준 최대 32배까지 처리 속도를 개선했습니다.

AI Agent를 활용해 테스트 케이스와 예외 상황을 확장하면서 QA 범위를 넓혔고, QA 기간과 출시 일정을 단축했습니다.

App Store 배포 과정에서 심사 지연을 직접 겪으며 기능 완성도뿐 아니라 일정 관리의 중요성을 체감했습니다.

메인 화면 진입 시 약 60건의 콘텐츠 요청이 한꺼번에 발생해, 반복 새로고침 시 WAF에 차단되는 문제를 확인했습니다. 콘텐츠를 스크롤 위치에 따라 필요한 시점에 불러오도록 렌더링 구조를 개선해 초기 요청을 20건 미만으로 줄이고, 안정적인 콘텐츠 탐색이 가능하도록 최적화했습니다.

프론트엔드에 정적 데이터로 관리되는 콘텐츠를 매 검색마다 전체 순회하지 않도록, Bi-gram 토큰화와 Bitset 역색인을 활용한 클라이언트 검색 엔진을 직접 구축했습니다.

프론트엔드, API, 데이터베이스의 변경 주기와 장애 영향 범위가 서로 다르다고 판단해 Kubernetes 워크로드를 역할별로 분리했습니다. 사용자·관리자 프론트엔드는 하나의 앱 워크로드로, API는 별도 Pod로 구성하고 PostgreSQL은 데이터 영속성을 고려한 상태 저장 영역으로 분리했습니다.

GitHub Actions·Argo CD 기반 GitOps 흐름에 맞춰 Kubernetes Manifest와 이미지 태그를 관리하며 배포 변경사항을 반영했습니다. 또한 해당 경험을 GitOps와 Kubernetes 배포 관점에서 정리해 사내 개발자 발표로 공유했습니다.

기존 데이터를 그대로 이전하는 것보다 이후 운영과 유지보수 비용을 줄이는 것이 중요하다고 판단해, 마이그레이션 과정에서 사용되지 않는 컬럼과 중복 데이터를 함께 정리했습니다.

신청 과정에서 인증·임시저장·제출·결제마다 필요한 데이터와 저장 시점이 다르다고 판단해, 인증 정보와 작성 중인 신청서, 제출이 완료된 신청서를 분리해 관리하도록 설계했습니다.

경연곡을 저장할 때 최대 20번의 개별 API 요청이 발생하는 구조는 일부 요청만 실패할 경우 데이터 정합성을 보장하기 어렵다고 판단했습니다. 이를 bulk-save API 한 번으로 통합하고 트랜잭션으로 전체 작업의 성공과 실패를 묶어, 중간 데이터가 남는 문제를 방지하고 저장 대기 시간도 줄였습니다.

DB 레코드와 S3 첨부 파일을 함께 삭제하는 과정에서 두 작업을 완벽하게 원자적으로 처리할 수 없기 때문에, 어떤 데이터를 우선적으로 보장할 것인지가 중요했습니다. 서비스의 기준 데이터인 DB 삭제를 먼저 확정하고 파일 정리는 후속 작업으로 분리해, 파일 삭제 실패가 핵심 데이터의 삭제까지 막지 않도록 설계했습니다.

쉬운 글 변환 효과를 정확하게 전달하기 위해, 사용자가 원문을 입력하고 변환 결과를 같은 화면에서 비교하는 체험형 인터페이스를 핵심 진입점으로 구현했습니다.

초기에는 Intro.js로 온보딩 튜토리얼을 구현했지만, 라이선스를 검토하는 과정에서 상용 서비스에 적용하기에는 제약이 있을 수 있다는 점을 확인했습니다. 이에 라이선스 부담이 적고 React 환경에서 활용하기 쉬운 react-joyride로 교체해 온보딩 튜토리얼을 구현했습니다.

입력, 변환 결과, 테마 전환과 튜토리얼 동작을 Vitest로 검증하고 테스트 커버리지 100%를 유지하였습니다.

Safari iOS 환경에서 PG 결제가 앱 정책과 충돌하는 문제를 마주했고, 정책을 변경하기보다 가능한 구현 범위를 중심으로 결제 플로우를 구성했습니다.

외부 PG 페이지로 이동하면서 서비스 Header와 화면 제어 흐름이 끊기는 문제를 해결하기 위해 결제창을 iframe으로 구성했습니다. 결제 완료 페이지가 iframe 내부에 마운트되면 postMessage로 완료 이벤트를 부모 페이지에 전달하고, 부모가 이를 수신해 iframe을 종료한 뒤 결제 완료 화면으로 전환하도록 설계하여 외부 결제 UI의 생명주기를 서비스 내부에서 일관되게 제어했습니다.

네트워크와 DEX별 시세 조회를 순차 처리할 때 탐색 시간이 누적되는 문제를 해결하기 위해 작업 단위를 분리하고 병렬 프로세스 수에 따른 처리 시간과 무료 계층 자원 사용량을 비교했습니다.

토큰을 정점, 교환 경로를 간선으로 모델링하고 시작 자산으로 되돌아오는 교환 사이클의 예상 수익을 계산해 후보 경로만 남기는 차익거래 사이클링 알고리즘을 구현했습니다.

경로 탐색 과정에서 이미 손실이 확정된 분기와 중복 경로를 조기에 제외해 전체 조합을 모두 계산하지 않도록 최적화하고 결과 생성 시간을 600ms 이내로 줄였습니다.

RPC 연결, 풀 데이터 정규화와 수수료 계산을 네트워크 어댑터로 분리해 핵심 탐색 로직을 변경하지 않고 신규 체인과 DEX를 추가하도록 모듈화했습니다.

실시간 주가 데이터의 미세한 가격 변동을 효과적으로 표현하기 위해 현재 가격 기준 ±0.1% 범위로 Y축을 동적으로 구성하고, 새로운 데이터가 유입될 때 차트가 연속적으로 갱신되도록 구현했습니다.

실시간 주가 데이터를 지속적으로 조회하면서 발생할 수 있는 불필요한 요청을 줄이기 위해, 종목과 화면 활성화 여부를 기준으로 SWR 요청을 조건부로 실행하고 3초 주기의 재검증과 key 기반 캐싱으로 데이터 갱신 흐름을 구성했습니다.

AI 분석 데이터 조회 실패가 전체 투자 화면의 오류로 이어지지 않도록 예외를 분리하고, 분석 데이터를 불러오지 못한 경우에도 주가 그래프와 뉴스 정보를 이용할 수 있도록 구성했습니다.

데이터 등록 시 발생하는 가스비가 사용자 진입 장벽이 될 수 있다고 판단해 사용자는 EIP-712 구조화 데이터에만 서명하고, 릴레이어가 서명을 검증한 뒤 트랜잭션을 실행하는 메타 트랜잭션 흐름을 구현했습니다.

서명 메시지에 사용자 주소, 요청 데이터와 nonce를 포함하고 스마트컨트랙트에서 서명자와 nonce를 검증해 다른 사용자의 요청 위조와 동일 서명의 재전송을 방지했습니다.

의료 원문을 블록체인에 직접 기록하지 않고 암호화된 데이터와 검증에 필요한 정보만 온체인에 저장하도록 역할을 분리해 공개 원장의 프라이버시 노출과 저장 비용을 줄였습니다.

프론트엔드에서 지갑 연결→구조화 데이터 서명→릴레이 요청→트랜잭션 결과 확인 단계를 상태로 관리해 사용자가 가스비를 직접 준비하지 않아도 등록 과정을 완료하도록 구현했습니다.

유전 알고리즘의 초기 해 품질이 전체 탐색 성능에 영향을 준다고 보고, 초기 집단 생성 방식을 Random → Greedy → A* 순으로 개선해 더 나은 시작점을 확보했습니다.

토너먼트·룰렛 휠·순위 기반·공유 기반 선택 연산을 직접 구현해 비교하고, 수렴 안정성과 결과를 기준으로 토너먼트 선택을 채택했습니다. 돌연변이율도 0.01~0.5 범위에서 실험해 0.1일 때 약 47%의 개선 효과가 가장 크게 나타나는 것을 확인했습니다.

고정된 돌연변이율만으로는 세대가 진행될수록 로컬 옵티멈에 머무를 가능성이 있다고 판단해, 탐색 후반부에 돌연변이율을 높이는 동적 전략을 적용했습니다.

강화학습 방식도 함께 비교해 Value Iteration은 약 40회 반복 후 거리 27.178로 수렴했고, TD Q-Learning이 Monte Carlo 방식보다 안정적으로 수렴함을 확인했습니다. DQN은 상태·행동 공간이 빠르게 커지면서 학습에 실패했고, 샘플 효율성과 보상 설계의 한계를 분석했습니다.

forknexec 시스템 콜 번호와 사용자 스텁, 커널 디스패치 테이블을 연결하고 proc.c에서 자식 프로세스 생성과 프로그램 적재가 한 호출로 이어지도록 구현했습니다.

프로세스 구조체에 우선순위와 실행 횟수 정보를 추가하고 스케줄러가 runnable 프로세스를 순회하면서 우선순위가 높고 실행 횟수가 적은 대상을 선택하도록 수정했습니다.

동일 우선순위 프로세스에는 실행 횟수를 함께 비교하는 규칙을 적용해 특정 프로세스가 계속 선택되거나 장기간 대기하는 starvation을 완화했습니다.

fork 시 물리 페이지를 즉시 복제하지 않고 부모·자식 페이지 테이블이 읽기 전용 페이지를 공유하도록 변경했으며, 참조 수를 관리해 페이지 해제 시점을 제어했습니다.

쓰기 page fault가 발생하면 원본 내용을 새 페이지로 복사하고 해당 프로세스의 PTE를 쓰기 가능하게 교체하는 Copy-on-Write 처리 경로를 구현했습니다.