프로젝트
대표 프로젝트 — localization.md
언어가 정보와 기회의 장벽이 되지 않게 — 문서를 원본 서식 그대로 다른 언어로 옮기고, 번역 뒤 깨진 부분까지 바로잡아 주는 서비스.
개인 프로젝트
문서 플랫폼 PoC 시리즈 — localization.md의 전신
포맷마다 번역기·편집기·검수기를 따로 만들면 비용이 포맷 수만큼 늘어난다. 모든 문서를 하나의 공통 표현으로 다루면 기능 하나를 모든 포맷에 쓸 수 있다는 가설을, 구조를 바꿔 가며 여섯 번 다시 구현해 검증했다.
- 가설: PDF·PPTX·DOCX·EPUB를 페이지 기반 공통 JSON(Unified Layout JSON)으로 바꾸고, 웹은 이 JSON만 읽고 고치고 저장한다. 원본 포맷은 가져오기·내보내기에서만 다룬다.
- 검증 과정: 화면만 있는 PoC로 사용자 흐름을 확인 → 포맷 어댑터·익스포터 구조 검토 → 번역·변환·뷰어·편집기를 서비스로 분리한 구조까지 단계적으로 다시 만들었다.
- 얻은 설계 결정: 포맷 처리 엔진과 플랫폼을 분리하고, 공통 JSON을 단일 기준으로 둔다. DOCX·EPUB처럼 흐르는 문서도 검수 목적에서는 페이지 고정 스냅샷으로 정규화한다.
- 확장 방향: 같은 공통 표현 위에서 원본을 유지하는 '변환'과, 원본을 자료로 새 문서를 만드는 '생성'(PDF 보고서 → 발표 PPT, 설명서 → 교육 EPUB, 표 → Excel)을 구분했다.
- 결과: 이 결정들이 그대로 localization.md의 구조가 됐다.
GitHub 단일 파일 연산 라인 챌린지
'코드 몇 줄'처럼 단순해 보이는 지표도 규칙을 정확히 정의하지 않으면 공정하게 잴 수 없다. 누구나 같은 조건에서 재현·검증할 수 있는 챌린지 규격을 설계했다.
- 규칙: a = 1, b = 1에서 파생된 중복 없는 실제 연산 라인을 단일 소스 파일에 최대한 많이 담고, 최종 출력은 2. 언어는 자유.
- 공정성: 모든 인정 라인은 입력과 직접·간접으로 연결되어야 한다. 단순 별칭, 중복, 빈 줄, 주석, 선언만 있는 줄은 제외하고, 긴 줄도 1줄로만 센다.
- 재현 가능한 검증: Azure Standard_D4s_v5(4 vCPU, 16GiB, Ubuntu 24.04)에서 10분 이내 실행, 표준출력 2, 종료 코드 0. 라인 기반 검증기와 테스트를 함께 제공한다.
- 규칙 변화 대응: GitHub 단일 파일 크기 제한이 바뀌면 등급을 다시 정하고, 과거 기록은 당시 제한·커밋·파일 해시와 함께 보존한다. 제한이 다른 기록끼리는 MiB당 라인 수로 비교한다.
- 구성: 언어별 예시(각 100줄 이상), 항등 변환 패턴, 제약 조건 JSON, 언어별 적합성 표.
데이터 플랫폼 프로젝트
- PPAS 백업·복구 시스템 / 데이터 레이크하우스 — KT의 PostgreSQL(PPAS) 백업을 HDFS 위 Parquet·Apache Iceberg 테이블로 구성해 백업 스토리지를 150TB에서 7.53TB로 약 95% 줄였다.
- 실시간 분석 플랫폼 고도화 — KT Skylife의 750만 가구 대상 실시간 분석 플랫폼을 CentOS 7에서 Rocky Linux 8 HA 아키텍처로 무중단 이전하고 20노드로 확장했다.
- MartDB 생성형 AI 데이터 에이전트 (GPT-4o) — KT의 PostgreSQL MartDB에 RAG와 text-to-SQL로 자연어 질의에 답하는 GPT-4o PoC를 만들어 질의 소요를 수 시간에서 수 초로 줄였다.
- Airflow DAG 배치 스케줄링 환경 — KT의 Crontab 기반 Spark·프로시저 배치를 Docker 위 Airflow DAG로 전환해 명시적 태스크 의존성과 웹 기반 모니터링을 갖췄다.
- 보험 시스템 온프레미스 → AWS 마이그레이션 — 보험사 핵심 서비스를 온프레미스 Docker 호스트에서 AWS EC2로 이전하고 보안 그룹·최소권한 IAM·EBS 스냅샷 백업을 구성했다.
- iOS/Android QA 자동화 — 하나은행 뱅킹 앱의 수동 테스트 시나리오 3,300개 중 우선순위 높은 케이스를 Appium·Pytest로 자동화해 Android 3대·iOS 3대에서 동시 실행했다.
글 — AI 에이전트와 아키텍처에 대한 생각
- 하네스 엔지니어링 실무 적용
- 저장소 구조, 에이전트 지침 파일, 린터, CI/CD, 테스트, 권한·승인 흐름, 실행 루프, 세션 인계까지 12개 항목을 Microsoft·GitHub 공식 문서와 실제 코드 예시로 정리했다.
- Spec-Driven 멀티 에이전트 오케스트레이션
- 'AI는 발전하는데 왜 내 업무 방식은 그대로인가'에서 출발해, 에이전트를 실제로 업무에 들여온 조직들이 쓰는 방식을 정리했다.
- AIDE² — AI가 자기 작업 환경을 스스로 개선할 수 있는가
- 사람 개입 없이 8일 동안 100회 개선 루프를 돈 연구를 Azure Data & AI 현장의 관점에서 해석했다.
- AI 아키텍트가 필요한 이유 — IT 산업 구조로 보기
- 대기업이 개발을 외부에 맡기고 외부 조직은 구현 중심으로 움직이는 구조에서, AI 시스템의 설계가 왜 비어 있기 쉬운지 짚었다.
- AI 발전 속도 조절 논쟁
- 'Pace the Frontier'를 둘러싼 업계 리더들의 입장을 정리하고 소버린 AI 관점에서 바라봤다.
- 유출 코드 재배포에 대한 윤리
- 유출된 상용 소스를 '클린룸'이라 주장하며 재배포하는 행위를 비판했다. 가장 많이 읽힌 글(노출 약 2.7만).
- Everything is a Function (영문)
- 처치의 람다 계산에서 프로그래밍 언어, Java 람다까지 — 세상을 함수로 모델링하려는 전통에 대한 에세이.
- AI 코딩 에이전트의 멀티유저 협업 공백 (리포트)
- Claude Code와 Codex의 공개 이슈를 근거로, 하나의 에이전트 세션을 여러 사람이 실시간으로 함께 쓰지 못하는 공백을 분석했다.