무엇을 쓰느냐가 아니라, 어떻게 다루느냐가 역량입니다.
도구는 교체됩니다. 방식은 남습니다.
시스템의 깊이와 전체 구조를 함께 보는 풀스택 개발자.
운영을 아는 손으로, AI 시대의 개발 방식을 다시 짭니다.
시스템 운영과 서버 스크립팅에서 출발해, API 설계와 서비스 아키텍처 전반을 다루는 개발자로 성장했습니다. 코드 한 줄보다 그 코드가 놓이는 구조에 더 관심을 가져온 결과, 지금은 마이크로서비스 기반의 풀스택 설계와 구현을 맡고 있습니다.
와이엠엑스에서 책임연구원으로 일하며, 단순히 기능을 구현하는 것이 아닌 운영 가능한 시스템을 설계하는 데 집중해왔습니다. 그 경험 위에 AI 협업 방법론을 더해, 더 빠르고 정확하게 복잡한 문제를 푸는 방식을 만들어가고 있습니다.
운영 환경을 직접 다뤄온 사람만이 아는 것이 있습니다. '왜 이 구조가 문제인가'를 먼저 보고, AI에게 정확한 맥락으로 질문합니다.
자격 정보처리기사 · 한국산업인력공단
다양한 도메인과 규모의 시스템을 설계하고 구축해 온 경력입니다.
책임연구원 · 풀스택 개발 / 아키텍처 설계
마이크로서비스 기반으로 대규모 산업용 실시간 시스템의 백엔드 아키텍처를 설계하고 직접 구현
연구원 · 서버 개발 / 데이터 처리 시스템
위성·우주 관측 데이터를 수집·분석·표출하는 서버 파이프라인을 설계하고 구축
개발자 · 기상·위성·천문 도메인 시스템 개발
기상·천문·우주 분야의 데이터 수집·처리·시각화 시스템을 폭넓게 개발
특정 산업에 갇히지 않고, 새로운 도메인의 문제를 빠르게 이해하여 시스템으로 풀어 왔습니다.
실제 업무에서 시스템 설계와 구조적 문제 해결 역량이 발휘된 대표 사례입니다.
조선 생산 현장의 디지털 전환 수요에 따라, 물리적 설비와 공정을 가상 환경에 실시간으로 연동하는 디지털트윈 플랫폼 구축이 필요했습니다.
저작도구 연결·실시간 데이터 스트림·아키텍처 설계를 독립 서비스 단위로 분해하고, 레이어 간 인터페이스를 사전 명세화하여 병렬 개발과 통합을 체계적으로 진행했습니다. 반복 작업은 AI 보조 도구로 가속하여 설계 품질과 속도를 동시에 확보했습니다.
대규모 엔지니어링 자산 관리가 수작업에 의존하고 있어, 관리 효율을 높이고 유관 부서 간 데이터 흐름을 자동화할 시스템이 필요했습니다.
관리자 인터페이스·데이터 처리 서버·부서 간 인터페이스를 역할 단위로 분리 설계하고, 공통 데이터 규격을 중앙화하여 연동 비용을 최소화했습니다. 재사용 가능한 공통 모듈로 구조화해 유지보수 부담을 줄였습니다.
제조 현장 인력의 반복 교육을 실제 설비 없이 수행할 수 있는 가상 훈련 시스템과, 현장 배포를 자동화하는 운영 체계가 필요했습니다.
실시간 서버·WAS·자동 업데이트 모듈을 독립 단위로 분해하고, 단계별 통합 테스트 게이트를 두어 각 레이어를 순차적으로 검증한 뒤 전체 시스템을 완성했습니다.
어떤 AI를 쓰든, 어떤 도메인에서 일하든 적용되는 7가지 협업 원칙입니다. 각 방법론이 무엇이고, 실제로 어떻게 적용했는지를 정리했습니다.
사실 이 페이지도 아래 7가지 방법론으로 만들었습니다. 각 카드의 이 저장소에서의 실증이 그 흔적입니다.
AI가 올바른 판단을 내리도록 배경·제약·목표를 구조화된 언어로 설계합니다.
디지털트윈 프로젝트에서는 시스템 요구사항과 제약, 인터페이스 규격을 먼저 문서로 정리해 AI에 건넸습니다. 덕분에 API 설계 초안이 거의 한 번에 나왔습니다.
이 저장소에서의 실증: 배경·제약·구조를 CLAUDE.md와 docs/project-context.md에 모아두니, 세션이 바뀌어도 맥락을 다시 설명할 일이 없었습니다.
그만큼 같은 설명을 되풀이하지 않고 첫 시도에서 원하는 결과에 가까워집니다.
복잡한 목표를 AI가 처리 가능한 최소 단위로 나누고 실행 순서를 설계합니다.
대규모 자산관리 자동화 프로젝트에서는 관리자 페이지, 데이터 서버, 부서 인터페이스를 독립된 단위로 나눠 동시에 개발했습니다. 이렇게 짠 구조가 4년 넘게 안정적으로 돌아가고 있습니다.
이 저장소에서의 실증: 큰 목표를 M1-T01 같은 독립 태스크로 쪼개고 선후 관계를 (deps:)로 표시하니, 다음에 뭘 할지가 늘 분명했습니다.
덩치 큰 일도 작은 단계로 끊어 가면 진행 상황이 한눈에 보이고 품질을 챙기기 쉬워집니다.
여러 AI 에이전트 또는 페르소나에 역할을 배분하고 각각의 출력을 하나의 결과물로 통합합니다.
디지털트윈 개발에서는 아키텍처 설계, 코드 초안, 코드 리뷰를 각각 다른 역할로 나눠 AI와 진행합니다. 혼자 일해도 여러 전문가의 시선을 거친 결과물이 나옵니다.
이 저장소에서의 실증: 설계(Architect)·카피(Writer)·구현(Implementer)·검토(Reviewer)를 각각 다른 역할로 두고, 단계마다 그 역할의 결과만 모아 합쳤습니다.
한 사람, 한 모델의 시야에 갇히지 않고 서로 다른 관점이 하나의 결과로 모입니다.
AI 출력물이 다음 단계로 넘어가기 전 사람의 판단이 개입하는 체크포인트를 설계합니다.
가상 훈련 시뮬레이터를 만들 때는 실시간 서버, WAS, 업데이트 모듈을 따로따로 검증한 다음에야 합치도록 단계를 끊었습니다. 그래서 배포 전에 문제를 각 층에서 미리 잡아낼 수 있었습니다.
이 저장소에서의 실증: 구현·검토 중에는 변경을 확정하지 않고, 사람이 한 번 확인한 뒤에만 반영하도록 했습니다. 실제로 공개 노출 위험도 승인을 받고 나서야 손봤습니다.
문제가 쌓이기 전에 걸러내니, 나중에 통째로 다시 만드는 일이 줄어듭니다.
AI가 스스로 자신의 출력을 기준에 따라 반복적으로 검토하고 수정하는 프로세스를 설계합니다.
API 서버를 개발할 때는 AI가 만든 인터페이스 명세를 미리 정해둔 체크리스트로 스스로 다시 보게 했습니다. 사람이 직접 검토하는 횟수가 그만큼 줄었습니다.
이 저장소에서의 실증: 보편성·접근성 체크리스트를 미리 정해두고, 검토 단계에서 그 기준으로 계속 스스로 점검했습니다.
사람이 일일이 보지 않아도 일정 수준의 품질이 먼저 걸러집니다.
AI와의 협업 과정에서 내려진 판단 근거를 구조화된 형태로 추적하고 보존합니다.
MSA 아키텍처를 설계할 때는 구조를 어떻게 정했고 왜 그랬는지를 기록으로 남겼습니다. 같은 논의를 다시 하지 않아도 됐고, 새로 합류한 사람도 맥락을 금방 따라왔습니다.
이 저장소에서의 실증: 무언가 정할 때마다 그 근거를 결정 테이블과 docs/conventions.md에 바로 적어둬서, 나중에 같은 고민을 반복하지 않았습니다.
비슷한 문제가 또 생겨도 그때의 판단 과정을 그대로 되짚거나, 원인을 빠르게 찾을 수 있습니다.
반복 사용 가능한 프롬프트·템플릿·컨텍스트 블록으로 협업 결과를 구조화합니다.
여러 자동화·시뮬레이터 프로젝트에서 공통으로 쓰는 데이터 인터페이스 모듈을 따로 만들어 뒀습니다. 다른 부서와 연동할 때마다 이걸 다시 써서 초기 개발 시간을 아꼈습니다.
이 저장소에서의 실증: 작업 템플릿과 규약 문서를 한 곳에 기준 문서로 모아두고, 사이클을 돌 때마다 그대로 가져다 썼습니다.
새 프로젝트를 시작할 때 처음부터 만들 게 줄고, 결과물의 일관성도 올라갑니다.
앞의 7가지는 따로 노는 원칙이 아닙니다. 실제로는 아래 네 단계로 맞물려 돌아갑니다. 이 페이지도 그 순서대로 설계하고, 구현하고, 검토하고, 기록했습니다.
목표와 제약을 분명히 하고, AI가 제대로 판단하도록 일의 구조를 잡습니다. 이 사이트에서도 배경과 제약을 한 문서에 정리하고, 목표를 독립된 태스크로 쪼개는 단계였습니다.
역할을 나눈 AI와 함께, 다시 쓸 수 있는 자산을 남기며 결과물을 만듭니다. 이때는 변경을 아직 확정하지 않고 만들기와 검증에만 집중합니다.
사람이 확인하는 승인 단계와 AI의 자기 점검을 겹쳐 품질을 두 번 거릅니다. 이 관문을 통과한 변경만 다음으로 넘어가, 문제가 쌓이기 전에 걸러집니다.
협업하며 내린 판단의 근거를 정리해 남기고, 다음 일의 출발점으로 삼습니다. 결정과 규약을 기준 문서로 남겨 두면 다음 사이클이 맥락을 그대로 이어받습니다.