이번주 수요 코딩회 회고
1. AI 에이전트 사용 관련
1.1. 작업 방식
- 한 컴퓨터에서 팀원들과 함께 프롬프트를 작성하고, 확인 및 수정 과정을 거쳐 공통 문서를 만들었음.
- 이후 각자 컴퓨터에서 같은 프로젝트를 진행할 수 있도록 문서를 기반으로 Codex를 활용했음.
- 팀원 수만큼 역할을 분배하고, 각 Codex 에이전트에게 역할별 규칙을 부여해 작업을 진행했음.
1.2. 진행 중 발생한 문제
1) 초기 세팅 부족
DB를 서로 공유하지 않았고, 처음에 DB를 생성하지 않은 상태에서 바로 작업을 시작했음.
그 결과 프론트 작업이 진행되지 않았고, 의존성 문제가 발생했음.
Codex도 현재 필요한 기능이나 환경이 준비되지 않았기 때문에 작업할 수 없다는 식의 메시지를 출력했음.
GPT의 답변
이건 매우 핵심적인 문제였음. AI 에이전트를 여러 명처럼 굴리더라도, 결국 공통 환경과 선행 작업이 정리되지 않으면 막힐 수밖에 없음.
다음에는 시작 전에 아래 항목을 먼저 맞추는 것이 좋음.
- 공통 DB 또는 더미 데이터 준비
- 환경변수(.env) 규칙 통일
- API 명세 / 요청·응답 형식 확정
- 백엔드/프론트 선행 의존성 정리
- 실행 순서 문서화
즉, “개발 전에 작업 가능한 상태를 먼저 만든다”가 중요함.
2) 구현 순서를 정하지 않고 시작한 점
이번 프로젝트를 하면서 처음에 구현 순서를 정하고 시작하는 것이 중요하다고 느낌.
특히 백엔드 작업이 완료된 뒤 프론트 작업을 진행해야 훨씬 매끄럽게 진행될 것 같았음.
GPT의 답변
방향 자체는 맞음. 다만 “백엔드가 완전히 끝난 뒤 프론트를 시작해야 한다”로까지 생각하면 조금 위험할 수 있음.
실무나 팀 프로젝트에서는 보통 아래 방식이 더 효율적임.
- 먼저 API 규격을 정함
- 백엔드는 핵심 API부터 구현함
- 프론트는 mock 데이터나 임시 응답으로 먼저 화면 작업을 시작함
- 이후 실제 API와 연결하면서 맞춰감
즉,
정정하면:
백엔드가 전부 끝난 뒤 프론트를 시작하는 방식만이 정답은 아님.
더 정확히는 “의존성이 큰 부분부터 우선 정리하고, 프론트와 백엔드가 연결 가능한 최소 기준을 먼저 만드는 것”이 중요함.
3) 컴퓨터 용어와 개발 개념 이해 부족
문제가 발생했을 때 Codex가 요구하는 내용을 이해하고 해결하려면 컴퓨터 용어를 잘 알아야 한다고 느낌.
GPT의 답변
맞는 생각임.
AI를 잘 쓰는 능력도 중요하지만, 결국 다음 개념들을 사람이 이해해야 AI가 내놓은 지시를 해석하고 문제를 해결할 수 있음.
- 의존성
- 환경변수
- 포트
- DB 스키마
- API
- 로그
- 빌드 / 배포
- 인증 / 권한
즉, AI 활용 능력은 기초 개발 지식 위에서 더 강해짐.
이번 경험은 오히려 부족한 개념이 어디인지 드러났다는 점에서 의미 있었음.
4) Codex의 쓰레드를 어떻게 활용해야 할지 잘 모르겠음
Codex의 쓰레드를 어떻게 나눠야 할지, 어떤 기준으로 관리해야 할지 잘 감이 오지 않았음.
GPT의 답변
쓰레드는 보통 기능 단위, 역할 단위, 맥락 단위로 나누는 것이 좋음.
예시로 나누면 아래와 같음.
- 쓰레드 1: 인증 / 로그인 관련
- 쓰레드 2: 게시글 CRUD 관련
- 쓰레드 3: 프론트 UI 컴포넌트 작업
- 쓰레드 4: 배포 및 인프라 작업
- 쓰레드 5: 버그 수정 및 디버깅 전용
핵심은 한 쓰레드 안에 너무 많은 목적을 섞지 않는 것임.
그래야 Codex도 맥락을 덜 잃고, 사람도 추적하기 쉬움.
정리하면:
쓰레드는 “대화 저장 공간”이 아니라, 작업 단위를 분리해서 문맥을 유지하는 도구라고 생각하면 좋음.
5) AWS 배포 관련 Codex 활용 한계
AWS 배포 관련해서는 아직 Codex에 AWS 스킬이 부족하다고 느꼈고, 스킬 크리에이터를 통해 별도로 만드는 것이 좋을 것 같았음. AWS CLI를 사용하면 가능할 것 같다고 생각했음.
GPT의 답변
이 생각도 꽤 타당함.
특히 반복적으로 해야 하는 작업이 있다면 다음을 템플릿처럼 정리해두는 것이 좋음.
- EC2 접속 방법
- 환경변수 세팅 방법
- 빌드/실행 명령어
- 배포 순서
- 롤백 방법
- 에러 발생 시 점검 순서
다만 AWS 스킬이 없어서 배포를 못 한다기보다는,
실제로는 배포 절차가 명확하게 문서화되지 않았기 때문에 AI도 안정적으로 수행하기 어려운 경우가 많음.
정정하면:
문제의 핵심은 “Codex에 AWS 능력이 아예 없음”이라기보다,
배포 절차와 실행 조건이 구조화되어 있지 않으면 AI도 일관되게 작업하기 어렵다는 쪽에 더 가까움.
6) Codex를 사용할 때 중요한 점
Codex를 사용할 때 중요한 점은, Codex의 작업 내용을 사람이 정확하게 파악할 수 있어야 한다는 점이라고 느낌.
GPT의 답변
아주 중요한 포인트임.
AI는 작업 속도를 높여주지만, 책임지고 판단하는 것은 결국 사람임.
그래서 아래 능력이 중요함.
- 지금 무엇을 수정했는지 파악하는 능력
- 왜 이 코드가 필요한지 설명할 수 있는 능력
- 에러가 났을 때 원인을 추적하는 능력
- 잘못된 방향일 때 중단시키는 능력
즉, AI를 잘 쓰는 사람은 AI에게 맡기는 사람이 아니라, AI의 작업을 검수하고 조율할 수 있는 사람임.
2. 기획
2.1. 기획 진행 순서
- 키워드 던지기
- 각자 생각한 아이디어 투표
- 세부사항 디벨롭
2.2. 좋았던 점과 아쉬웠던 점
1) 키워드 던지기 단계
아이디어가 잘 떠오르지 않았음.
그래서 평소에 문제점이나 불편한 점이 보이면 기록해두는 습관이 필요하다고 느낌.
GPT의 답변
좋은 방향임.
아이디어는 회의 자리에서 갑자기 짜내기보다, 평소 불편함이나 개선점을 메모해둔 것에서 나오는 경우가 많음.
간단하게 아래처럼 관리하면 도움 됨.
- 불편했던 경험
- 반복적으로 귀찮았던 일
- 주변 사람이 자주 말하는 문제
- 이미 있는 서비스의 아쉬운 점
즉, 아이디어는 창의성만으로 만드는 것이 아니라 관찰과 기록에서 쌓이는 경우가 많음.
2) 아이디어 투표 과정
각자 생각한 아이디어를 투표하는 과정은 좋았음.
GPT의 답변
이 부분은 실제로도 좋은 방식임.
짧은 시간 안에 여러 생각을 비교하고 방향을 정할 수 있기 때문임.
다만 투표 전에 아래 기준을 같이 두면 더 좋아짐.
- 구현 가능성
- 시간 대비 완성도
- 발표하기 쉬운지
- 시연하기 좋은지
- 문제 해결 가치가 있는지
그냥 “재밌어 보이는 아이디어”보다 “이번 시간 안에 끝낼 수 있는 아이디어”를 고르는 데 도움이 됨.
3) 세부사항 디벨롭 과정의 문제
이번 수요 코딩회에서는 세부사항을 디벨롭하는 과정에서 문제점이 많았음.
- 서로 다르게 이해한 부분이 많았음.
- 문제 발생 시 의견 수렴이 어려웠음. 서로 중요하게 생각하는 요소가 달랐기 때문임.
- 문제를 해결하기 위해 내용을 수정하면 다른 문제가 발생했음.
GPT의 답변
이건 기획 초반에 흔하게 나오는 문제임.
핵심은 말로만 합의한 상태였기 때문일 가능성이 큼.
사람마다 같은 단어를 다르게 이해하기 쉬움.
다음에는 아래 내용을 짧게라도 문서화하면 훨씬 좋아짐.
- 이 서비스가 해결하려는 문제 1문장
- 핵심 사용자 1명
- 꼭 필요한 기능 / 없어도 되는 기능 구분
- 입력 / 출력 예시
- 시연 시나리오
- 구현하지 않을 것
특히 “우리가 이번에 안 할 것”을 정하는 것이 생각보다 중요함.
그래야 수정할 때 범위가 무한정 커지지 않음.
정정하면:
세부사항 디벨롭이 어려웠던 이유는 단순히 팀원들의 중요도가 달라서만은 아닐 수 있음.
더 근본적으로는 공통 기준과 문서화된 정의가 부족해서 서로 다른 해석이 생긴 것일 가능성이 큼.
3. 발표
3.1. 발표 준비 부족
발표 준비 시간을 충분히 가져야 할 것 같았음.
연습이 많이 부족했음.
GPT의 답변
맞는 판단임.
발표는 내용 준비와 별개로 전달 연습이 꼭 필요함.
특히 팀 발표에서는 아래 3가지만 맞춰도 안정감이 많이 생김.
- 누가 어떤 순서로 말할지
- 각 파트 핵심 문장 1~2개
- 시연 실패 시 대체 설명
3.2. 발표 당시 정신없었음
시간 압박과 긴장 때문에 발표할 때 정신이 없었음.
GPT의 답변
자연스러운 반응임.
이건 실력이 없어서라기보다, 연습량이 부족하면 누구나 쉽게 겪는 문제임.
그래서 발표는 “잘 말하기 연습”보다 먼저 “흐름이 안 끊기게 하는 연습”이 중요함.
3.3. 대본과 프리스타일 발표의 어려움
대본을 참고해서 자연스럽게 프리스타일로 발표하려고 했는데, 긴장해서 아무것도 눈에 잘 안 들어왔음.
사실 대본 없이 프리스타일로 하는 게 맞는 것 같기도 한데, 그게 어려웠음.
GPT의 답변
여기에는 조금 정정이 필요함.
대본 없이 프리스타일로 하는 것이 무조건 더 좋은 발표 방식은 아님.
많은 경우 가장 좋은 방식은 아래 중간 형태임.
- 전체 문장을 외우지 않음
- 대신 슬라이드마다 핵심 키워드 2~3개만 기억함
- 연결 문장은 자연스럽게 말함
즉,
완전 대본형도 아니고 완전 프리스타일도 아닌,
핵심 문장 중심 발표가 가장 안정적임.
정정하면:
대본 없이 프리스타일로 하는 게 맞는 것이 아니라,
핵심 흐름과 키워드를 충분히 익혀서 자연스럽게 말하는 방식이 더 현실적이고 안정적임.
3.4. 시연 중 오류 대처 부족
시연할 때 작동이 안 되는 경우 차분하게 대처해야 하는데 그러지 못했음.
GPT의 답변
이건 발표 실수라기보다 사전 대비 부족에 가까움.
시연은 항상 실패 가능성을 전제로 준비하는 것이 좋음.
추천 방식은 아래와 같음.
- 시연 전 캡처 이미지 준비
- 핵심 기능 동영상 준비
- 더미 데이터 준비
- 오류 발생 시 말할 멘트 준비
예시:
“현재 시연 환경에서 예상치 못한 문제가 발생했지만, 핵심 동작은 미리 준비한 화면에서 보실 수 있음”
이런 식으로 넘어가면 훨씬 안정적임.
3.5. 전달 부족
내용을 충분히 전달하지 못했음.
특히 AI 협업 방법을 설명했어야 했는데 까먹고 못 했음.
GPT의 답변
이 부분은 발표 전에 “반드시 말해야 하는 핵심 3가지”를 정해두면 해결 가능함.
예를 들면 이번 발표에서는 아래처럼 정리할 수 있었음.
- 어떤 문제를 해결하려는 서비스인지
- 어떤 방식으로 구현했는지
- AI와 어떻게 협업했는지
발표 전에 이 3가지를 체크리스트로 두면 빠뜨릴 가능성이 많이 줄어듦.
4. 전체적으로 느낀 점
이번 수요 코딩회를 통해 느낀 점은,
AI를 활용한다고 해서 개발이 자동으로 쉬워지는 것은 아니라는 것이었음.
오히려 팀 단위로 AI를 잘 활용하려면 사람 쪽에서 더 명확한 역할 분배, 작업 순서, 공통 환경, 기획 정리, 발표 정리가 필요했음.
특히 아래가 중요하다고 느낌.
- 시작 전에 공통 환경과 의존성을 먼저 정리할 것
- 구현 순서를 정하고, 최소 기능 단위부터 맞출 것
- 세부사항은 말로만 합의하지 말고 짧게라도 문서화할 것
- 발표는 대본 전체보다 핵심 흐름 중심으로 연습할 것
- AI는 대신 해주는 도구가 아니라, 사람이 이해하고 조율해야 제대로 활용할 수 있는 도구라는 점을 인식할 것
PS. 다음 수요 코딩회에서 바로 적용할 수 있는 개선안
-
시작 전에 20~30분 정도 써서 아래만 먼저 정리하면 좋음.
- 기능 우선순위
- DB/환경변수/API 명세
- 역할 분담
- 구현 순서
- 발표용 핵심 메시지
-
프론트와 백엔드를 완전히 따로 보기보다,
“연결 가능한 최소 기능”을 먼저 만드는 방향으로 가는 것이 좋음. -
Codex는 역할별/기능별 쓰레드로 나누고,
각 쓰레드의 목표를 한 줄로 적어두면 관리가 쉬워짐. -
발표는 대본 전체 암기보다
슬라이드별 핵심 키워드 암기 + 2번 정도 실제 말로 연습이 효율적임. -
시연은 실패를 전제로 준비해야 함.
캡처본, 영상, 더미 데이터 중 하나는 꼭 준비하는 것이 좋음.
