CLIPEDU

1. 01

   문제 상황

   인스타그램 사전 점검에서 실제 리포트에는 값이 채워졌는데, 앞선 점검은 같은 작업을 장애로 알리는 오경보가 있었습니다.

2. 02

   원인 분석

   사전 점검과 리포트가 응답을 기다리는 기준이 달랐습니다. 값이 늦게 도착했을 때의 상태도 무응답과 충분히 구분하지 못했습니다.

3. 03

   해결 방법과 기술적 선택

   두 흐름의 대기 기준을 맞추고, 늦게 도착한 정상 값과 끝내 응답하지 않은 작업을 다른 상태로 분류했습니다. 기존 무응답 정보는 유지했습니다.

4. 04

   검증 과정

   개정2 PDF p.12의 테스트 확인 항목에서 지연 응답·일정 시간 후 정상 응답·워커 무응답을 구분했습니다. 당시 로컬 확인 기록을 근거로 하며 운영 오경보 감소율은 측정하지 않았습니다.

5. 05

   결과와 검증 근거

   지연 응답과 워커 무응답을 나누어 로컬 확인 항목으로 검토했습니다. 이번 포트폴리오 작업에서 사내 실행 테스트를 다시 수행한 결과는 아닙니다.

6. 06

   배운 점과 남은 한계

   응답이 느린 것과 실패한 것은 다른 사건입니다. 알림은 실제 데이터가 도착하는 흐름과 같은 기준으로 판단해야 합니다.

근거 · 범위 개정된 인턴십 기록의 문제·보완·확인 항목. 사내 식별자와 운영 설정값은 제외했습니다.

1. 01

   문제 상황

   장소 검색이 지연되거나 지도 창이 열리지 않으면 글 발행 자체가 멈추는 초기 처리였습니다.

2. 02

   원인 분석

   지도 삽입을 발행의 필수 단계로 취급했습니다. 선택적 보조 정보의 실패가 핵심 작업까지 중단시키는 경계 설정이었습니다.

3. 03

   해결 방법과 기술적 선택

   초기 구현은 발행 전 중단이었고, 기존 개발자의 코드 리뷰를 반영해 지도 없이 발행하며 누락을 표시하는 정책으로 바꿨습니다. 지도 검색 재시도도 제거했습니다.

4. 04

   검증 과정

   개정2 PDF p.12의 초기 코드·리뷰 후 변경·당시 로컬 확인을 대조했습니다. 검색 실패 뒤 지도 창을 닫고 누락을 표시하는 부분 성공 정책을 확인한 기록이며, 이번 작업에서 사내 서비스를 실행하지 않았습니다.

5. 05

   결과와 검증 근거

   최종 코드와 리뷰 기록에 변경된 정책이 반영됐습니다. 이 포트폴리오에서 실제 사내 게시를 재현하거나 운영 성공률을 측정하지 않았습니다.

6. 06

   배운 점과 남은 한계

   자동화의 실패 조건은 기능의 중요도와 운영 정책을 함께 고려해야 합니다. 최종 판단에는 사내 리뷰가 결정적인 역할을 했습니다.

근거 · 범위 개정된 인턴십 기록의 초기 처리와 리뷰 후 변경 내용. 서비스 화면과 내부 경로는 공개하지 않습니다.

1. 01

   문제 상황

   대용량 영상을 기존 단일 업로드 흐름으로 처리하면 요청 시간과 임시 저장 크기의 한계가 문제가 됐습니다.

2. 02

   원인 분석

   브라우저의 전송 진행, API가 받은 바이트, 저장소에 실제 남은 바이트를 하나의 성공 상태로 볼 수 없었습니다.

3. 03

   해결 방법과 기술적 선택

   영상을 순차 청크로 나누고 업로드 상태와 수신 위치를 확인해 이어 보냈습니다. 서버는 저장 위치와 길이를 대조하고 마지막 청크까지 확인한 뒤 메타데이터를 기록하도록 했습니다.

4. 04

   검증 과정

   개정2 PDF p.10 및 공개 아키텍처 자료의 청크 경계·부분 업로드·수신 위치·재시도 테스트 작성 기록을 확인했습니다. 테스트 파일 존재와 이번 실행 통과는 구분합니다.

5. 05

   결과와 검증 근거

   당시 구현·테스트 작성 기록으로 업로드 흐름을 설명합니다. API 재시작 뒤 메모리 기반 세션이 사라지는 한계가 남아 있으며, 이번 웹 작업에서 사내 테스트를 재실행하지 않았습니다.

6. 06

   배운 점과 남은 한계

   클라이언트의 재시도와 저장소의 복구는 별개입니다. 완료 표시도 전송 종료가 아니라 저장 확인 뒤에 해야 합니다.

근거 · 범위 인턴십 아키텍처·테스트 기록의 공개용 요약. 내부 API·저장 키·파일명은 제외했습니다.

1. 01

   문제 상황

   기존 자동화 워커가 외부 채널 작업을 실행하는 동안 관리자가 진행 상태를 확인하기 어려웠습니다. 실시간 관찰 기능이 필요했지만 캡처가 본 작업을 방해하면 안 됐습니다.

2. 02

   원인 분석

   기존 작업 제어와 브라우저 화면 전달은 별도 책임이었습니다. 모든 프레임을 쌓거나 시청자 없이 캡처하면 전송 지연과 불필요한 자원 사용이 커질 수 있었습니다.

3. 03

   해결 방법과 기술적 선택

   워커에서 WebSocket으로 JPEG를 전송하고 API는 작업별 최신 한 장만 보관하도록 확장했습니다. 관리자 브라우저는 인증 중계를 거쳐 HTTP 폴링으로 조회합니다. 시청 신호가 있을 때 캡처하고 전송 버퍼가 밀리면 캡처를 건너뛰며 간격을 늘립니다. 중계 실패와 본 작업의 수명을 분리했습니다.

4. 04

   검증 과정

   개정2 PDF p.9와 공개 아키텍처 분석의 로컬 측정·프로브 기록을 확인했습니다. 이 기능 전용 자동 테스트나 운영 자원 사용률 개선 수치는 확인되지 않았습니다.

5. 05

   결과와 검증 근거

   화면 전송·최신 프레임 보관·브라우저 조회 경로를 연결한 구현 기록이 있습니다. 로그인 창의 네이티브 캡처는 기존 개발자의 기여이며, 브라우저가 WebSocket을 직접 받는 구조로 표현하지 않습니다.

6. 06

   배운 점과 남은 한계

   관찰 기능의 품질보다 본 작업의 안정성이 우선입니다. 화면을 저장하는 대신 최신 프레임만 유지하는 선택은 과거 프레임 재생 기능과의 트레이드오프입니다.

근거 · 범위 개정2 PDF p.9 및 기존 공개 아키텍처 지도. 실제 회사 프레임·내부 주소·코드 식별자는 공개하지 않습니다.

1. 01

   문제 상황

   다량의 사진을 한 요청으로 처리하는 기존 흐름은 요청 본문과 API 메모리에 부담을 주었습니다.

2. 02

   원인 분석

   이미지 묶음 전송과 작업 연결을 한 번에 처리하면 큰 바이너리가 API를 거쳐 이동합니다. 기존 DB 바이너리 저장 구조도 고려해야 했습니다.

3. 03

   해결 방법과 기술적 선택

   사진을 5장 단위로 나누어 순차 적재하고, 임시 적재한 데이터를 DB 내부에서 복사해 작업에 연결했습니다. 기존 데이터 구조를 유지하면서 API로 전체 이미지를 다시 읽는 이동을 피했습니다.

4. 04

   검증 과정

   공개 아키텍처 자료와 기존 분석의 이미지 크기·순서·적재 테스트 작성 기록을 확인했습니다. 이번 작업에서 사내 테스트를 실행하거나 메모리 감소율을 측정하지 않았습니다.

5. 05

   결과와 검증 근거

   단계 적재와 DB 내부 복사 경로를 확장한 기록을 공개합니다. DB 바이너리 보관에 따른 저장 용량 부담은 남아 있습니다.

6. 06

   배운 점과 남은 한계

   저장소를 전면 교체하는 대신 기존 계약을 보존하며 데이터 이동을 줄이는 범위를 선택했습니다. 요청 부담 분산과 DB 용량 문제는 별도로 평가해야 합니다.

근거 · 범위 공개 아키텍처 지도 「사진 단계 적재」 및 제공 아키텍처 분석. SQL 원문·운영 테이블·사내 식별자는 제외했습니다.

1. 01

   문제 상황

   운영 중인 기존 서비스에 기능을 추가할 때 AI가 작성한 코드가 기존 정책과 실패 처리에 맞는지 검토해야 했습니다.

2. 02

   원인 분석

   코드 생성만으로 운영 맥락이나 선택 기능의 실패 경계를 결정할 수 없었습니다. 지도 삽입 실패를 전체 작업 실패로 처리한 초기 구현이 대표 사례입니다.

3. 03

   해결 방법과 기술적 선택

   기존 구조와 요구사항을 분석하고 Claude Code를 활용해 구현·수정을 진행했습니다. 로컬 확인과 테스트 작성 후 기존 개발자에게 리뷰를 요청하고, 피드백을 반영해 통합했습니다.

4. 04

   검증 과정

   개정2 PDF p.7·12의 요구사항·구현·리뷰·보완·통합 기록을 대조했습니다. 모든 테스트의 단독 작성·실행 또는 모든 변경의 운영 검증을 주장하지 않습니다.

5. 05

   결과와 검증 근거

   지도 없이 발행하는 부분 성공 정책처럼 초기 판단이 리뷰로 바뀐 과정을 확인했습니다. AI 활용과 본인의 검증 책임, 기존 개발자의 최종 정책 판단을 구분합니다.

6. 06

   배운 점과 남은 한계

   AI 도구는 구현을 보조하지만 서비스 맥락과 검증을 대신하지 않습니다. 리뷰에서 바뀐 판단도 결과와 함께 설명해야 합니다.

근거 · 범위 개정2 PDF p.7·12의 공개 가능한 개발 과정. 내부 브랜치·티켓·계정·커밋 식별자는 공개하지 않습니다.