개발환경에 대해셔 설명부탁드립니다.

Question

현재 GPT 창과 로컬 개발환경에서 작업을하시는데 로컬 환경은 어떤 환경이신지요? 설치하신것은 코덱스 CLI인지...궁금합니다. 그리고 데이터베이스 설계나 화면 설계에 대해서 티켓을 어떻게 설게 할지 예시가 있을까요? 그리고 UI를 별도로 개발해야 한다면 만약 넥사크로 라던가 기타 UI 툴로 개발해야 한다면 어떻게 소스코드 가이드를 만들어 줘서 티켓을 만들수 있을까요?

knodark74 · Answer

좋은 질문 감사합니다. 강의에서 사용한 로컬 개발환경은 일반적인 로컬 IDE 환경입니다. 별도의 Codex CLI를 기준으로 진행한 것은 아니고, GPT 창에서 분석·설계·티켓 초안을 만들고, 로컬 개발환경에서는 Cursor를 사용해 프로젝트 파일을 읽고 티켓 단위로 구현하는 방식으로 진행했습니다. 즉 구조는 대략 다음과 같습니다. GPT: 문제 분석 / SSOT 초안 / 티켓 설계 / 검토 Cursor: 실제 소스코드 분석 / 티켓 실행 / 수정 / 검증 로컬 프로젝트: 기존 레거시 코드와 docs 폴더, SSOT, 티켓 문서 보관 DB 설계나 화면 설계도 티켓으로 나눌 수 있습니다. 예를 들어 DB 설계라면 “사용자 즐겨찾기 기능을 위한 테이블/컬렉션 설계”, “기존 주문 테이블에 상태 이력 구조 추가”, “마이그레이션 없이 읽기 모델만 추가”처럼 범위를 작게 자릅니다. 화면 설계도 “목록 화면 필터 영역 추가”, “상세 화면의 상태 표시 컴포넌트 분리”, “관리자 등록 화면의 입력 검증 UI 추가”처럼 한 화면 전체가 아니라 화면 내 변경 단위로 티켓을 만드는 편이 안전합니다. Nexacro 같은 별도 UI 툴을 쓰는 경우에도 방식은 같습니다. 먼저 AI에게 바로 개발을 시키기보다, 해당 프로젝트의 UI 구조를 분석하게 해서 다음 기준 문서를 만드는 것이 좋습니다. 화면 파일 구조 공통 컴포넌트 사용 규칙 데이터셋 / 바인딩 규칙 이벤트 핸들러 작성 방식 API 호출 방식 화면 이동 규칙 금지할 수정 범위 그 다음 티켓에는 “어떤 화면의 어떤 이벤트/데이터셋/컴포넌트를 수정할지”를 명확히 적어줍니다. UI 툴일수록 AI가 임의로 구조를 바꾸면 깨질 가능성이 높기 때문에, 소스코드 가이드를 먼저 만들고 그 가이드 안에서만 티켓을 실행하게 하는 방식이 더 안전합니다. 정리하면, 핵심은 Codex CLI 여부가 아니라 “AI에게 바로 개발을 맡기지 않고, 로컬 프로젝트 구조를 먼저 읽히고, SSOT/가이드/티켓으로 작업 범위를 제한한 뒤 실행시키는 것”입니다.