데이터베이스 시스템

Navicat이 내보낸 파일을 손대지 않고 제출했다. 앞부분 드롭 구문 중 네 줄은 제약 이름이 빈 문자열이라 어떤 PostgreSQL에서도 문법 오류다. 그 앞의 DROP CONSTRAINT·DROP TABLE 20줄도 IF EXISTS가 없어 새 데이터베이스에서는 전부 실패한다. 즉 이 스크립트를 실제로 한 번이라도 돌려본 흔적이 없다.

판매자의 영업일과 영업시간, 서비스의 이벤트 목록이 전부 varchar(255) 한 칸이다. 요일 집합이나 이벤트 목록은 명백한 다치 속성이고, 이 과목이 가르치려는 1NF 분해 대상 그 자체다. "월,화,수" 같은 문자열로 저장하면 "수요일에 여는 가게" 질의를 쓸 수 없다. 별도 BusinessHour(sellerId, day, open, close) 테이블이 정답이다.

같은 파일에서 타입 선택도 여러 군데 어긋난다. Destination.name이 int4로 선언돼 있고, README가 "opened date"라고 설명한 Seller.createdAt은 날짜가 아니라 time(0)(시:분:초)이다.

연락처의 소유자가 판매자인지 구매자인지 배달대행인지를 세 개의 nullable FK로 나타냈는데, "셋 중 정확히 하나만 NULL이 아니다"를 강제하는 CHECK 제약이 없다. 세 개 다 NULL인 고아 연락처, 세 개 다 채워진 연락처를 모두 삽입할 수 있다. 기본키도 없어서 완전히 동일한 행을 무한히 넣을 수 있고, UNIQUE는 buyerId 쪽에만 걸려 있어 판매자·배달대행 연락처는 중복 방지도 안 된다.

덧붙여 README는 이 관계를 일관되게 Contract라고 부르는데(README:71, 74, 77) 실제 테이블 이름은 Contact다. 문서와 스키마가 서로 다른 이름을 쓰고 있고, 제약 이름만 SellersContracts로 문서 쪽 오타를 따라갔다.

README:78은 Order가 Service, Buyer, Agency에 속한다고 적었지만, 실제 Order 테이블(deliveryHY.sql:85–96)에는 buyerId가 없다. paymentId와 destinationId를 거쳐 간접적으로만 구매자에 닿으므로, 결제수단을 지우면 주문의 주인을 잃는다. 문서가 코드보다 앞서 있는 전형적인 예다.

또 Agency.activity_location은 README:46이 "korean-style postal address를 보관"한다고 설명하는데 varchar(8)이다. 한국식 주소는 8자에 들어가지 않는다.

모든 조회·수정·삭제가 거쳐 가는 findIndex가 조건 배열을 np.logical_and에 펼쳐 넣고 뒤에 ones 두 개를 덧붙인다. np.logical_and은 ufunc이라 위치 인자를 최대 3개(x1, x2, out)만 받는다. 조건이 0개면 (ones, ones), 1개면 (cond, ones, ones)로 우연히 맞아떨어지지만 — 뒤쪽 ones가 조건이 아니라 출력 버퍼로 소비되는 것이다 — 조건이 2개가 되는 순간 인자 4개가 되어 TypeError다.

README가 직접 광고한 WHERE [COND, ...] 쉼표 문법이 바로 이 경로를 탄다. 저자가 문서에 적은 사용법대로 쓰면 프로그램이 죽는다.

학생 모드의 커밋이 빈 함수다. 개인 주소록에 대한 create/update/remove는 전부 메모리에만 반영되고 디스크에 쓰이지 않는다. 유일하게 파일을 쓰는 곳은 load()인데, 방금 읽은 프레임을 그대로 되쓰기 때문에 내용이 바뀌지 않는다.

레포에 커밋된 private_2009003125.csv는 실제로 입력 business_cards/Grass_corp.csv와 바이트 단위로 같다(공백 제거만 다름). 반면 명세가 요구한 반영 결과로 제출된 business_cards_updated/Grass_corp.csv에는 main.py가 수행하는 변경(이상해씨→이상해풀, 리피아 추가)이 들어 있으나 main.py가 반드시 수행하는 "임의 1건 삭제"는 반영돼 있지 않다. 즉 프로그램을 돌려서 얻은 파일이 아니라 손으로 편집한 파일이다.

명세 6쪽은 "email 열을 local_part 열과 domain_name 열로 분리하여 저장한다"와 "저장 형태가 달라진 이후에도 출력 형태는 변화가 없어야 한다"를 요구한다. 이건 스키마 변경 후에도 뷰가 유지되는지를 묻는, 이 과목의 핵심 개념 문제다.

구현된 것은 도수분포표뿐이다. emailFrequency는 split('@') 결과로 Counter를 만들어 반환할 뿐 컬럼을 바꾸지도, 저장하지도 않는다. 레포 전체에 local_part/domain_name이라는 문자열은 한 번도 등장하지 않고, 커밋된 contacts.csv의 헤더는 여전히 sid,phone,email이다. SQL 버전도 마찬가지로 dbms.sql에 ALTER TABLE이 0회 나온다 — 명세가 힌트로 ALTER TABLE과 CREATE TABLE ... AS ...를 콕 집어 줬는데도 그렇다.

명세 3쪽·5쪽이 반복해서 요구하는 "한양인 주소록 + 개인 주소록을 같이 보여주기"에 대응하는 함수는 elements()뿐이다. 레포 전체에서 이 이름이 등장하는 곳은 정의된 줄 하나가 전부다 — main.py도, REPL도 부르지 않는다.

그리고 실제로 개인 주소록에 대해 호출하면 동작하지 않는다. __values_admin에는 T.business 키 자체가 없어서 KeyError가 난다. 설령 키가 있었더라도 contacts는 3열, business는 4열이라 np.vstack이 실패한다.

students 대신 stdents라는 테이블을 만들어 놓고 이후 모든 INSERT는 students를 대상으로 한다. 존재하지 않는 테이블이다. 파일 마지막 질의도 domain과 count(*) 사이에 쉼표가 빠져 문법 오류다. Step 1의 UPDATE·DELETE는 서브쿼리로 students를 참조하므로 연쇄적으로 전부 실패한다. 이 파일은 단 한 번도 실행된 적이 없다.

1번(강의실 20개 이상인 건물): rooms라는 존재하지 않는 컬럼을 SELECT하고, building_id가 양쪽 테이블에 있어 모호하며, name·admin이 GROUP BY에도 집계함수에도 들어가지 않았다. 표준 SQL과 MySQL ONLY_FULL_GROUP_BY에서 모두 거부된다.

4번(수용인원 100명 이상인 강의실의 건물): FULL OUTER JOIN 뒤에 WHERE Rooms.capacity >= 100을 붙였다. 이 WHERE가 NULL 행을 전부 제거하므로 외부 조인이 내부 조인으로 퇴화한다 — 굳이 FULL OUTER를 쓴 의미가 사라진다. 게다가 MySQL은 FULL OUTER JOIN을 지원하지 않고, DISTINCT가 없어 큰 강의실이 여럿인 건물은 중복 출력된다.

5번(학과별 과목 수를 세어 상위 10개 학과 출력): 정답에 반드시 있어야 할 COUNT(*)와 ORDER BY ... DESC가 둘 다 없다. 출력되는 것은 개수 없는 학과 코드 10개이고, 그 10개는 "가장 많은" 10개가 아니라 임의의 10개다. 그 위의 SELECT course_id FROM Classes는 세미콜론이 없어 다음 문장과 붙으면서 파싱 자체가 깨진다.

맞은 것은 2번(INSERT)과 3번(UPDATE) 두 문제다.

main.py는 실행할 때마다 홍길동 행을 무조건 append한다(중복 검사 없음). 커밋된 students.csv에는 동일한 홍길동 행이 3개, contacts.csv에는 동일한 hong@ 행이 3개 들어 있다. sid는 이 시나리오에서 기본키인데, 제출된 "데이터베이스"에 기본키 중복 행이 3중으로 남아 있다. 원본 raw/students.csv는 21줄, 제출본은 24줄이다.

같은 파일에 다른 학생들의 평문 비밀번호가 그대로 들어 있고(2009003125,125125125 등), main.py:47, 74, 89는 그 비밀번호를 소스에 하드코딩해 로그인한다. 과제 제공 데이터라 해도, 비밀번호 컬럼을 그대로 소스에 박아 넣는 습관은 Assignment 3에서 실제 사고로 이어진다.

main.py:131–163의 입력 루프에는 try/except가 한 줄도 없다. FROM 없는 SELECT는 언패킹 오류, 없는 테이블 이름은 T.fromString이 None을 반환해 KeyError: None, 값에 =나 ,가 들어가면 조건 파싱이 조용히 어긋난다. 한 번 터지면 세션 전체가 종료되고 커밋 안 된 변경은 사라진다.

또 README는 "you can write query to execute insert, update, remove"라고 적었지만 REPL에는 INSERT 분기가 없다. 그리고 제출 코드에 print("WTF", ...)가 남아 있다.

req.session은 레포 전체에서 app/routes/index.js 한 파일에만 등장한다 — 로그인 시 쓰기 3회, 세션 덤프 엔드포인트 1회. 어떤 라우터도, 어떤 컨트롤러도 세션을 읽어 "이 사람이 이 자원의 주인인가"를 묻지 않는다. 미들웨어는 하나도 없다(next()가 앱 코드에 단 한 번도 나오지 않는다).

동시에 모든 index 컨트롤러가 req.query를 그대로 Sequelize where에 넣고 attributes 필터 없이 전체 행을 JSON으로 뱉는다. Customer·Seller·Delivery 모델은 모두 passwd 컬럼을 가지고 있고 비밀번호는 해싱 없이 평문으로 저장된다(로그인이 passwd: req.body.password로 직접 비교한다). 따라서 로그인하지 않은 누구든 GET /customer 한 번으로 전 고객의 이름·전화번호·이메일·평문 비밀번호·카드번호와 계좌번호 JSON·현재 좌표를 통째로 받는다.

이건 가정이 아니라 앱이 실제로 밟는 경로다. 배달부 화면이 주문마다 바로 그 요청을 보낸다.

PUT /seller/:seller_id가 m.Seller.update(req.body, ...)를 호출한다. 본문에 어떤 컬럼이 들어오든 그대로 반영되는 mass assignment이고, 앞서 말했듯 세션 검사가 없다. 판매자 화면의 "개인정보 변경"이 실제로 이 엔드포인트에 {name, passwd}를 보낸다. 같은 요청을 로그인 없이 임의의 seller_id로 보내면 그 계정을 탈취할 수 있다. PUT /customer/:id/payment도 마찬가지로 경로 이름과 달리 passwd를 포함한 모든 컬럼을 갱신한다. DELETE /seller/:id, DELETE /order/:id, DELETE /menu/:id도 전부 무인증이다.

orders.menus 하나를 세 클라이언트가 서로 다른 형식으로 읽는다. 구매자는 {메뉴ID: 수량} 객체를 JSON.stringify해서 쓰고, 구매자 화면과 배달부 화면은 JSON.parse로 읽는다. 그런데 판매자 화면만 그 문자열을 쉼표로 잘라 parseInt한다. {"3":2,"5":1}을 쉼표로 자르면 ['{"3":2', '"5":1}']이고 parseInt는 둘 다 NaN이다. 결과적으로 필터가 항상 빈 배열을 반환한다.

음식을 만들어야 하는 사람이 주문 내역을 못 보는 것이므로 이 앱의 핵심 흐름이 끊긴다. 판매자 화면을 한 번만 열어봤으면 바로 보였을 것이다. 같은 파일 안에 정답(JSON.parse)이 두 벌이나 있는데도 세 번째 구현만 다르다.

명세 7쪽은 구매자에게도 판매자와 동일한 개인정보 관리(이름·비밀번호 변경)를 요구한다. 프런트는 PUT /customer/:customer_id를 부르는데 라우터에는 GET /와 PUT /:customer_id/payment만 등록돼 있다. 매칭되는 라우트가 없으므로 404가 떨어지지만, jQuery success 콜백이 없는 오류 처리 탓에 사용자에게는 아무 일도 일어나지 않는다. 판매자 쪽 동일 기능은 라우트가 있어서 동작한다 — 두 화면을 복사·수정하다 한쪽만 라우트를 빠뜨린 것으로 보인다.

명세 6쪽: "주문 확인 시: 가장 가깝고, 배달 개수(Stock)가 4개 이하인 배달부를 5명 표시." 서버는 배달부마다 현재 배달 건수를 stack으로 정확히 계산해 내려보내고, 프런트는 그 값을 화면에 표시까지 한다. 그런데 정렬 후 5명을 자를 뿐 stack <= 4 조건을 어디서도 걸지 않는다. 필요한 데이터를 다 만들어 놓고 마지막 한 줄을 안 쓴 것이다.

같은 함수에 별개 버그가 하나 더 있다. #order-delivery 셀렉트를 비우지 않고 append만 하므로, 주문 A의 확인 모달을 열었다가 닫고 주문 B를 열면 B의 배달부 목록에 A의 후보가 그대로 남는다.

init.sql은 orders → customers / stores / destinations에 InnoDB FK를 제대로 걸었다. 그런데 배달 앱에서 가장 중요한 관계인 orders → deliveries만 int(11) DEFAULT '0'짜리 맨 정수다. 배달부를 삭제해도 주문은 사라진 ID를 계속 가리키고, 존재하지 않는 delivery_id를 넣어도 DB가 막지 않는다. 실제로 "미배정"을 NULL이 아니라 0이라는 매직 넘버로 표현하기 때문에 FK를 걸 수 없는 구조가 됐다.

여기에 orders.menus(주문-메뉴 다대다)는 varchar(512) 직렬화, customers.payments·stores.phone_nums·stores.schedules·stores.tags는 전부 JSON 컬럼이다. 결제수단은 bid로 banks를 가리키지만 JSON 안이라 FK가 없다. 관계형 모델링을 평가하는 과목에서 관계 대부분을 문자열로 우회한 셈이고, 그 대가로 "특정 메뉴가 이번 달에 몇 번 팔렸나" 같은 질의는 SQL로 쓸 수 없다. (명세가 JSON 컬럼을 예시로 준 부분도 있으나, 주문-메뉴 다대다는 명세에 없는 본인 선택이다.)

가게 이름·주소·설명·태그·메뉴 이름이 전부 이스케이프 없이 템플릿 리터럴에 들어가고 $(...)로 파싱된다. jQuery의 $(htmlString)은 실제 DOM을 생성하므로 <img src=x onerror=...> 같은 값이 즉시 실행된다. 같은 화면에서 메뉴 이름도 동일하게 처리되는데(customer.js:108), POST /menu는 인증이 없으므로 누구든 임의의 가게에 name을 심을 수 있다. 그리고 그 스크립트가 실행되는 페이지는 고객의 결제수단이 떠 있는 화면이다.

package.json의 repository URL이 네이버 사내 GitHub의 웹툰 CIC 프로젝트를 가리킨다. 같은 맥락에서 app/lib/io.js 65줄은 재귀 mkdir/rmdir, rename, Promise 기반 read/write 같은 파일 시스템 유틸 15개를 정의하는데, 이 앱에서 실제로 쓰이는 것은 writeSync와 hash 둘뿐이다(index.js:10). 나머지 13개는 호출자가 없다. 스캐폴딩 재사용 자체는 합리적이지만, 제출 전에 쓰지 않는 것을 걷어내고 남의 레포 주소를 지우는 정리는 필요했다.

같은 줄에 secretString이 const/let 없이 대입되는 암묵적 전역이라 strict mode나 ES 모듈에서는 ReferenceError다. 그리고 config.app.port를 읽어 놓고 app.listen(80, ...)으로 하드코딩해 설정값이 죽어 있다(80번 포트라 root 권한도 필요하다).

routes/index.js는 디렉터리를 훑어 router.use('/'+name, route)로 자동 마운트하는데, 시드 객체가 { router }라서 첫 반복에서 router.use('/router', router)가 실행된다. 라우터가 자기 자신의 하위에 붙어 /router/router/router/...가 무한히 매칭된다. 아래 if (route.associate) 분기는 associate를 정의한 라우트 파일이 하나도 없어 죽은 코드다.

한편 controllers/stores.js의 create·destroy는 routes/store.js가 GET 두 개만 등록하므로 도달할 수 없다. 명세 6쪽의 "가게 설명·태그 관리"에 대응하는 UI도 없어서, 가게 정보 편집 기능은 컨트롤러만 있고 실제로는 미구현이다.

GET /session은 "Session debug"라는 주석과 함께 세션 객체를 통째로 JSON으로 내보낸다. 세 화면이 모두 이 엔드포인트에 의존하므로 지울 수 없게 설계됐다.

로그인은 Seller → Customer → Delivery를 .catch()로 이어 붙인 3단 체인이다. 명세의 "세 역할이 같은 로그인 화면"을 만족시키는 접근 자체는 맞지만, DB 연결 실패나 res.sendFile 오류까지 전부 다음 단계로 흘러가 최종적으로 "Invalid email or password"가 된다. 원인 진단이 불가능하고, 첫 단계가 응답을 보낸 뒤 예외가 나면 두 번째 단계가 두 번째 응답을 시도한다.