굿뉴스에너지 · AX 세션
평범한 개발자의
AI 사용법
그런데 직접 코딩, 코드 리뷰
안 하는 방법을 곁들인
나는 평범한 개발자입니다
2017년에 시작해, 지금은 테크리드
회원 150만 · 15년+ 레거시
2017개발 시작
이후백엔드 · 프론트
ML · 창업
2022~테크리드
2025육아휴직 1년
2026.4복직
목차
- 다른 개발자의 하루 들여다보기
- 마음 편하게 코딩을 위임하는 방법
- 마음 편하게 코드 리뷰를 위임하는 방법
- 프로덕트 팀 재정의
① 다른 개발자의 하루
- 코드 작성 = Claude Code / Codex (나는 큰 틀만 설명 → 결과물)
- 코드 한 줄 한 줄 리뷰 = LLM (개발용 / 리뷰용 다른 모델)
- 나 = 스펙·계획·아키텍처의 모호함을 지운다
- 제품 논의 = 더미데이터 MVP를 띄워놓고 본다
여기까진 여러분도 마찬가지
코드를 치는 시간 ≈ 0
그래서 진짜 질문은,
그럼 나는 뭘 하지?
②
마음 편하게 코딩을 위임하는 방법
- 모호함을 제거
- 테스트, 테스트, 테스트
- 멘탈 모델 — 불완전함을 인정하기
② · 1 모호함을 제거 — 왜
LLM은 슬롯머신
슬롯도 옵션도 ∞로 두면 계속 꽝 → 둘 다 좁혀야 당첨
스펙·계약·구조로 제약 = 슬롯도 옵션도 좁혀 당첨 확률을 높이는 일
② · 1-1 모호함을 제거 — 스펙
스펙을 SSoT로
제품 컨텍스트를 한 곳에 모은다 — 단, user surface 위주로
② · 1-2 모호함을 제거 — 계약
계약은 세 가지로
API contract
- FE / BE 사이의 계약
- OpenAPI · protobuf 같은 것
스펙 contract
- 스펙의 기능 · 테스트가 코드에 실제 존재하는지
- 스펙↔코드 양방향 sync 검증
아키텍처 contract
- 코드가 아키텍처 rule을 지키는지
- 레이어 · 의존 방향 등
BE는 결과를 webhook으로 나중에 주는데
FE는 바로 받는 줄 알고 화면·상태관리를 다 짜둠 → 흐름째 다시
스펙엔 없는데 추가된 기능 ·
스펙엔 있는데 빠진 기능
도메인 코드가 DB를 직접 부르거나,
막아둔 방향으로 몰래 import
② · 1-3 모호함을 제거 — 설계 (아키텍처)
설계도 과하게
사람에겐 과잉인 규율이, LLM에겐 일관성의 유일한 방법
아키텍처
- DDD · FC/IS 도입
- 테스트와 대규모 협업에 좋은 구조를 솔로 · 소규모 팀에도 그대로
lint · format
- lint · formatting을 과하게 설정
- 스타일이 흔들릴 틈을 없앤다
② · 2 테스트, 테스트, 테스트
테스트는 층으로 쌓는다
- unit도메인 로직을 의존성과 분리해 테스트
- integration의존성들이 제대로 맞물리는지 테스트
- fake e2e개발 환경에서 빠르게 확인하는 용도
- full e2estage에서 FE/BE 연동된 채 실제 사용자처럼 (QA까지 커버)
- stress동시성이 중요하고 트래픽이 몰릴 것으로 예상될 때 — optional
② · 3 멘탈 모델
LLM은 인간처럼
실수한다
인간의 지식·경험으로 만들어졌으니까.
1~3을 아무리 빡빡하게 해도 실수는 남는다 → 불완전함을 인정하자
② · 3 이렇게 보자 ① 추상 layer
LLM = 또 하나의 컴파일러
- 컴파일러 : 코드 → 어셈블리 · 기계어
- LLM : 자연어 → 코드
자연어를 코드로 바꾸는 추상 layer로 보면 된다
② · 3 이렇게 보자 ② 사람도 똑같다
사람 개발자는
실수를 안 하나?
사람도 급하면 layer 침범하고, 테스트 빼먹는다
② · 3 이렇게 보자 ③ 완벽은 없다
100% 완벽한 코드가
현실에 존재하나?
버그를 100% 없애는 건 불가능 — 사람 코드도 마찬가지
③
마음 편하게 코드 리뷰를 위임하는 방법
- 이종 모델에게 맡긴다 (+ 리뷰 봇)
- 중요한 건 계속 물어본다
- 테스트, 테스트, 테스트 (②·2와 같다)
③ · 1 이종 모델에게 맡긴다
리뷰는 개발한 모델이 아닌, 다른 모델로
- 리뷰 모델용 md 파일(리뷰 기준)도 따로 작성
- 리뷰 내용이 없을 때까지 계속 반복
③ · 2 중요한 건 계속 물어본다
"이 부분,
제대로 됐어?"
- 중요한 부분이 잘 구현됐는지 반복해서 묻는다
- 코드를 line by line으로 읽어 리포팅해달라고 한다
③ · 3 테스트, 테스트, 테스트
리뷰도 결국 테스트로 닫는다
- 이종 모델 리뷰 · 반복 질문으로도 못 잡는 건 테스트가 잡는다
- ②에서 쌓은 unit · integration · e2e가 리뷰의 마지막 안전망
- 테스트 케이스를 직접 리뷰하거나 전부 리포팅받아 리뷰하는 것도 방법
테스트 케이스가 정상이면 production 코드에 문제가 있기 어렵다
② 정리
스펙계약설계테스트
→
AI를 믿는다
사람이 책임지는 건 코드가 아니라
스펙 · 계약 · 설계 · 테스트
layer를 겹겹이 쌓았다면 — 이제는 AI를 믿을 때
④
프로덕트 팀 재정의
- 더미데이터 MVP 기반 커뮤니케이션
- 역할 재정의
- 병렬작업 — 과한 설계의 또 다른 이유
- 팀 plugin — 결과물 수준 균일화
④ · 1 더미 MVP로 논의
문서 말고,
더미 MVP로 논의한다
문서로 논의
→
화면 보며 논의
"의도한 건 이게 아닌데요"가 사라진다 = 회사 비용이 사라진다
④ · 2 모두의 역할이 바뀐다
모두의 역할이 바뀐다
기존 workflow·역할에 AI를 끼워넣는 게 아니라,
AI를 잘 쓰도록 workflow·역할을 다시 짜는 것
- 개발자 = 제품 거의 모든 영역을 어느 정도 다룸 → 더 근본적인 문제에 집중
- PM / PO → 제품 · 비즈니스 전략
- 디자이너 → UX 전략 · 리서치 · 사용자 경험
④ · 3 과한 설계가 필요한 또 다른 이유
병렬 작업
- AI가 빨리 쏟아내자 → 변경 한 번의 영향 범위를 알 수 없어짐
- 과하게 설계(BC 격리) → 영향 범위가 갇힘
- → 여러 작업을 병렬로 = 팀 속도
④ · 4 팀 plugin 개발
누가 시켜도,
결과물이 균일하게
AI에게 누가 지시하든 결과물 수준이 비슷하게 나오도록
팀 공용 plugin·규칙으로 굳힌다.