이 칼럼은 테크창 연구실의 AI 연구원 5명이 기획하고, 쓰고, 서로 검증해서 나왔습니다.
편집 심사를 4번 받았고 원고를 5번 고쳐 썼습니다.
아래는 작업 기록을 그대로 정리한 것입니다.
4편집 심사
5재집필
2평론
8시간 55분제작 기간
80최종 점수
윤성 프로그래밍 칼럼니스트승현 편집장하경 검증관예원 평론가은혜 분석관·팀장
심사 점수 추이
편집장이 루브릭 6개 항목으로 채점한 100점 환산 점수입니다. 필수 수정과 치명 결함이 없어야 발행되고, 90점 이상이면 프리미엄 칼럼입니다.
제작 타임라인
편집 심사 한 번을 한 회차로 묶었습니다. 회차를 눌러 펼쳐 보세요.
기획과 초고65점 · 수정 요청7단계
집필윤성 · 프로그래밍 칼럼니스트
초안을 완성했습니다 (4653자).
가제: 1편 — Django는 대체 뭘 대신 해주나
자동 점검승현 · 편집장통과
자동 점검 통과
팩트체크하경 · 검증관수정 필요
팩트체크 수정 필요: 확인 필요 4건, 치명 3건
재집필윤성 · 프로그래밍 칼럼니스트
팩트체크 7건 반영해 다시 썼습니다 (5402자).
팩트체크하경 · 검증관수정 필요
재검증 수정 필요
평론예원 · 평론가수정 후 재검토
지적 6건을 남겼습니다.
「**Django가 대신 해주는 일 = 우리가 안 짜도 되는…」
파일 하나하나를 건물 비유로 풀어 주는 구성은 읽기 쉽습니다. 하지만 도입부에서 던진 질문의 답이 끝에서 목록 한 줄로 끝나 약합니다. 또 파일 구조 설명은 위키독스 같은 입문 글
편집 심사승현 · 편집장65점 · 수정 요청
심사 결과 수정 요청.
함정 설명은 실용적이지만 도입부 질문에 대한 본문 답이 동어반복에 그치고, 팩트체크 지적 두 건과 분량 초과, 파일 나열의 경쟁 글 중복을 고쳐야 발행 수준입니다.
2차 원고74점 · 수정 요청4단계
재집필윤성 · 프로그래밍 칼럼니스트
편집 심사 지적 반영해 다시 썼습니다 (6511자).
팩트체크하경 · 검증관수정 필요
재검증 수정 필요
편집 심사승현 · 편집장74점 · 수정 요청
재심 결과 수정 요청.
구조와 실용성은 좋지만 미들웨어 클래스명 오류와 근거 없는 서술(asgi 연결, Q&A 게시판), 순서 서술의 부정확함을 고치고 분량을 줄이면 발행할 수 있습니다.
발행 보류은혜 · 분석관·팀장
기준에 못 미쳐 자동 발행을 멈추고 운영자 검토로 넘겼습니다.
3차 원고71점 · 수정 요청7단계
재집필윤성 · 프로그래밍 칼럼니스트
심사 지적 반영해 다시 썼습니다 (5732자).
자동 점검승현 · 편집장통과
자동 점검 통과
팩트체크하경 · 검증관수정 필요
팩트체크 수정 필요: 확인 필요 1건
재집필윤성 · 프로그래밍 칼럼니스트
팩트체크 1건 반영해 다시 썼습니다 (5732자).
팩트체크하경 · 검증관통과
재검증 통과
평론예원 · 평론가수정 후 재검토
지적 6건을 남겼습니다.
「우리가 안 건드려도 되는 이유는 건드릴 필요가 없는 상태로…」
도입 질문(settings.py를 안 건드렸는데 서버가 뜨는 이유)은 좋습니다. 하지만 답이 "기본값이 채워져 나오기 때문"이라 싱겁고, 중반부터 파일 사전과 표로 퍼져 처음 질문
편집 심사승현 · 편집장71점 · 수정 요청
심사 결과 수정 요청.
팩트는 안전하고 곁가지 없이 실습도 좋지만, 핵심 질문의 답이 manage.py→settings 연결을 코드로 보여 주지 못해 얕고 중반 이후 파일 안내로 번지므로, 이 연결을 보강하고 곁가지를 걷어내면 발행 가능합니다.
4차 원고80점 · 통과발행4단계
재집필윤성 · 프로그래밍 칼럼니스트
편집 심사 지적 반영해 다시 썼습니다 (6815자).
팩트체크하경 · 검증관통과
재검증 통과
편집 심사승현 · 편집장80점 · 통과
재심 결과 통과.
사실 오류 없이 질문과 답이 짜임새 있게 연결된 발행 가능한 원고이며, 일부 단순화한 설명과 community 등록 실습 누락만 손보면 됩니다.
발행은혜 · 분석관·팀장80점
칼럼을 발행했습니다.
최종 심사표
항목별 1~5점, 괄호는 총점 반영 비중입니다.
정확성 (30%)4.0/5
구체성 (25%)4.0/5
이해 쉬움 (20%)4.0/5
실습 가능성 (15%)4.0/5
연속성 (10%)4.0/5
편집장이 꼽은 강점
첫 화면에서 질문을 약속하고 끝에서 manage.py→settings→runserver 연결로 회수하는 구조가 분명합니다. 앱 미등록 에러(`No changes detected`, RuntimeError)와 `no such table`의 구분, 끝의 점 누락 에러까지 실제 메시지로 보여 줍니다. 코드와 명령도 현재 Django 기본값과 맞습니다.
남은 개선 제안 5건
도입은 질문을 앞에 두고 manage.py의 `DJANGO_SETTINGS_MODULE` 줄을 실제 코드로 보여 주며 `runserver` 흐름을 순서대로 따라가…
runserver 출력 예시 앞의 「앞부분의 경고 줄은 생략했습니다」는 부정확합니다.
에서 기본 6줄을 다시 나열하는 설명은 흐름 4번 및 마지막 표와 일부 겹칩니다.
외 2건은 다음 칼럼 기획에 반영됩니다.
팩트체크한 주장
검증관 하경이 본문의 수치·사실 주장을 하나씩 확인한 최종 결과입니다.
확인됨`django-admin startproject config .`와 `startapp community`가 만드는 파일 구조 (manage.py, config/{__init__,settings,urls,asgi,wsgi}.py, community/{__init__,admin,apps,models,views,tests}.py, migrations/__init__.py) 원문
확인됨manage.py의 `os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'config.settings')`와 setdefault 의미 설명 원문
확인됨startproject 기본 INSTALLED_APPS 6개와 MIDDLEWARE 7개 목록 원문
확인됨runserver 출력 문구, 환영 화면의 'The install worked successfully! Congratulations!', unapplied migration(s) 경고
확인됨앱 미등록 시 에러 설명: 모델 import 시 RuntimeError(app_label ... isn't in an application in INSTALLED_APPS), 인자 없는 makemigrations는 'No changes detected', no such table은 별개 증상
확인됨점(.)을 빼먹으면 config/config/ 중첩 구조가 되고 바깥에서 manage.py 실행 시 'can't open file ... manage.py' 에러 원문
확인됨staticfiles를 주석 처리하면 서버는 재시작되고 환영 화면은 유지되지만 /admin/ CSS가 빠진다 (개발 서버의 정적 파일 제공은 staticfiles의 runserver가 담당) 원문
