1. 작품 수보다 한 작품의 연결 과정을 본다

공개 포트폴리오에는 졸업작품과 프로젝트실습 시연영상이 구분되어 있고, 다양한 주제의 소프트웨어가 소개됩니다. 작품이 많다는 사실은 학습 결과를 살펴볼 넓은 표본을 제공하지만, 그 숫자만으로 각 작품의 완성도나 교육 효과를 단정할 수는 없습니다. 지원자와 재학생에게 더 유용한 질문은 ‘한 작품이 문제에서 서비스까지 어떻게 이어지는가’입니다.

시연 영상은 소프트웨어가 실제로 움직이는 모습을 확인하는 자료입니다. 다만 영상만으로 소스 코드의 품질, 데이터의 정확성, 팀원별 기여, 운영 안정성을 모두 알 수는 없습니다. 화면에서 확인되는 사실과 설명이 더 필요한 부분을 구분해야 작품을 과장하거나 과소평가하지 않습니다.

공식 학과 페이지가 교육과정과 졸업작품을 별도 항목으로 제공하는 이유도 함께 생각해 볼 수 있습니다. 교육과정은 배울 범위를 보여 주고, 공개 작품은 여러 기술을 하나의 문제에 적용한 사례를 보여 줍니다. 두 자료를 나란히 보되, 특정 작품 하나를 모든 학생의 결과로 일반화하지 않습니다.

근거 자료 · 빅데이터소프트웨어공학과 · 포트폴리오 홈 · 서울강서캠퍼스 · 빅데이터소프트웨어공학과

2. 첫 질문은 ‘무엇을 만들었나’보다 ‘누구의 어떤 문제인가’다

좋은 프로젝트 설명은 기능 목록보다 사용자의 상황에서 시작합니다. 졸업생 프로젝트 아카이브에는 교육, 이동권, 환경, 의료와 행정처럼 서로 다른 문제 영역이 소개됩니다. 예를 들어 교통약자의 이동을 돕는 서비스라면 ‘지도 기능이 있다’에서 멈추지 않고 누가 어떤 상황에서 기존 정보에 접근하기 어려웠는지 설명해야 합니다.

문제 정의를 읽을 때는 대상 사용자, 발생 상황, 현재 방식의 한계, 개선 여부를 판단할 기준을 찾습니다. ‘편리하게 만든다’는 목표는 측정하기 어렵습니다. 검색 단계 수, 정보 갱신 시간, 잘못된 입력 처리, 접근성 지원처럼 관찰할 수 있는 기준으로 바꾸면 설계와 평가가 연결됩니다.

자신의 프로젝트를 시작할 때도 한 문장으로 문제를 적어 보세요. ‘사용자 A가 상황 B에서 겪는 문제 C를 데이터 D와 기능 E로 줄인다’는 구조를 쓰면 불필요한 기능을 구분하기 쉽습니다. 이 문장은 실습을 위한 제안이며 공개 작품의 실제 기획 문장을 대신하지 않습니다.

근거 자료 · 빅데이터소프트웨어공학과 · 졸업생 프로젝트 아카이브

3. 기술 이름은 데이터 흐름 속에서 확인한다

포트폴리오에는 Java, Spring Boot, Python, NLP, OpenCV, 클라우드와 공공 API 같은 기술이 표시됩니다. 이름을 많이 나열했다고 좋은 설계가 되는 것은 아닙니다. 각 기술이 입력을 받고 어떤 출력을 다음 단계로 넘기는지 연결해서 설명할 수 있어야 합니다.

공공데이터 기반 서비스라면 외부 API에서 JSON을 받고, Python 또는 Java가 값과 자료형을 검증하고, SQL 데이터베이스가 정규화한 정보를 저장하고, 백엔드 API가 화면에 필요한 형태로 반환할 수 있습니다. AI가 있다면 학습·추론 입력과 모델 버전, 결과의 신뢰도 또는 실패 처리도 흐름에 포함됩니다. 클라우드는 완성된 코드를 올리는 장소에 그치지 않고 비밀키, 로그, 장애 복구를 관리하는 단계입니다.

영상을 보며 입력, 처리, 저장, 출력, 피드백을 다섯 칸으로 그려 보세요. 영상에서 확인되지 않는 칸은 추측해 채우지 않고 질문표시를 남깁니다. 그러면 기술 스택을 외우는 관람에서 시스템 구조를 검증하는 관람으로 바뀝니다.

3. 기술 이름은 데이터 흐름 속에서 확인한다
단계확인할 질문남길 근거
입력출처와 갱신 주기는 무엇인가데이터 명세·샘플
처리결측·중복·오류를 어떻게 다루나정제 규칙·테스트
저장테이블 관계와 이력은 남는가ERD·SQL
분석/AI기준 방법보다 나은가평가표·실패 사례
서비스잘못된 요청과 장애를 다루나API 문서·로그
운영비밀정보와 복구 방법은 무엇인가배포·복구 절차
# 프로젝트를 읽는 데이터 흐름 예시
공공 API → 입력값·시간·중복 검증 → SQL 저장
→ Python 분석/AI 추론 → Java API 응답
→ 웹 화면 → 사용자 수정·오류 로그 → 다음 개선

4. 팀 프로젝트에서는 ‘담당 역할’을 산출물로 확인한다

졸업생 아카이브는 프로젝트별 담당 역할과 기술 구성을 살펴볼 수 있다고 안내합니다. 팀 프로젝트의 역할은 ‘백엔드 담당’, ‘AI 담당’이라는 직함만으로 충분하지 않습니다. 어떤 입력과 출력을 책임졌고, 다른 팀원의 구성요소와 어떤 규칙으로 연결했는지가 드러나야 합니다.

백엔드 담당이라면 API 경로와 요청·응답 예시, 데이터베이스 스키마, 입력 검증과 오류 처리 테스트가 근거가 될 수 있습니다. 데이터 담당이라면 원본 출처, 정제 코드, 전처리 전후 행 수와 제외 기준을 남길 수 있습니다. AI 담당은 학습 데이터 분리 기준, 기준 모델, 평가 지표와 틀린 사례를 설명해야 합니다.

공동 작업의 흔적도 중요합니다. Git 커밋 수만으로 기여도를 판단하면 큰 파일을 한 번 올린 사람과 설계·리뷰를 꾸준히 한 사람을 제대로 비교하기 어렵습니다. 이슈, 코드 리뷰, 회의 결정, 인터페이스 문서, 장애 해결 기록을 함께 보면 협업 과정이 더 정확하게 보입니다.

근거 자료 · 빅데이터소프트웨어공학과 · 졸업생 프로젝트 아카이브

5. 시연 성공 한 번과 검증된 소프트웨어는 다르다

시연은 정상 사용 흐름을 짧게 이해하는 데 효과적입니다. 그러나 사용자가 빈 값을 보내거나 네트워크가 끊기거나 외부 API가 늦게 응답하는 상황은 영상에서 생략되기 쉽습니다. 따라서 정상 화면을 확인한 뒤에는 어떤 입력에서 실패하는지, 실패가 사용자에게 어떻게 표시되는지, 데이터가 중복 저장되지 않는지를 질문해야 합니다.

AI 프로젝트는 특히 결과 한두 개만 보고 성능을 판단하기 어렵습니다. 학습에 쓰지 않은 평가 데이터가 있는지, 단순 규칙이나 기존 방법과 비교했는지, 범주별 오류가 어떻게 다른지 확인해야 합니다. 생성형 AI라면 사실과 다른 답변, 개인정보 입력, 출처 표시와 비용 한계를 함께 기록합니다.

검증 결과는 실제 측정값과 앞으로의 목표를 구분해 씁니다. ‘정확도 95%’라고 적으려면 데이터 범위, 분할 방법, 표본 수와 계산 코드를 제시해야 합니다. 아직 측정하지 않았다면 목표값처럼 보이게 쓰지 말고 ‘평가할 항목’으로 표시합니다.

6. 일주일 재현 실습으로 작품을 보는 눈을 만든다

다음 활동은 공개 작품을 복제하거나 실제 성과를 검증했다는 뜻이 아닌 교육용 제안입니다. 시연영상에서 관심 있는 작품 하나를 골라 문제와 핵심 기능을 세 문장으로 요약합니다. 영상에서 직접 확인한 사실과 제목·설명에서 확인한 정보를 구분하고, 알 수 없는 구현은 질문 목록으로 남깁니다.

그다음 같은 분야의 가상 데이터 30행을 직접 만들거나 이용 조건이 명확한 공개 데이터를 사용합니다. Python으로 결측값과 중복을 검사하고 SQLite에 저장한 뒤 SQL로 두 가지 집계를 만듭니다. Java 또는 간단한 웹 API는 한 개의 조회 기능과 잘못된 입력 응답을 제공합니다. 클라우드 배포가 어렵다면 로컬 실행 절차와 환경변수 설정까지만 재현합니다.

마지막 날에는 원작과 기능 수를 비교하지 말고 자신의 학습 결과를 평가합니다. 다른 사람이 README만 보고 실행할 수 있는지, 데이터 기준과 SQL 집계를 설명할 수 있는지, 정상·오류 사례가 각각 있는지, 다음 단계의 한계를 적었는지 확인합니다.

  • 시연에서 직접 본 사실과 추측을 분리했는가
  • 문제·사용자·성공 기준을 한 문장씩 적었는가
  • Python 정제 결과와 SQL 집계를 재현할 수 있는가
  • API의 정상 응답과 오류 응답을 모두 기록했는가
  • 측정 결과와 개선 제안을 구분했는가

근거 자료 · 빅데이터소프트웨어공학과 · 시연영상 아카이브

7. 포트폴리오는 완성품 목록보다 성장 기록이다

좋은 포트폴리오는 모든 기능이 성공한 기록만 모으지 않습니다. 첫 설계에서 놓친 문제, 데이터 품질 오류, 팀 간 인터페이스 충돌, 배포 실패와 수정 과정을 남기면 다음 프로젝트에서 같은 실수를 줄일 수 있습니다. 버전별 결정 이유가 있으면 결과 화면만으로 알 수 없는 문제 해결 능력도 드러납니다.

공개 범위는 신중해야 합니다. API 키, 비밀번호, 실제 사용자 개인정보와 내부 주소는 저장소나 영상에 노출하지 않습니다. 팀원의 이름과 역할을 공개할 때도 동의와 범위를 확인해야 합니다. 공개용 자료에서는 필요한 경우 이름을 가리고, 데이터는 비식별화하거나 가상 예제로 바꿉니다.

학생 작품 아카이브는 다양한 주제와 작동 화면을 탐색하는 출발점입니다. 한 작품을 문제 정의, 데이터 흐름, 역할, 검증, 운영, 회고의 여섯 관점으로 다시 읽고 작은 재현 실습을 해보면 무엇을 배워야 하는지 구체적으로 보입니다. 이것이 작품 수나 기술 이름보다 오래 남는 프로젝트 학습입니다.

근거 자료 · 빅데이터소프트웨어공학과 · 포트폴리오 홈 · 빅데이터소프트웨어공학과 · 시연영상 아카이브

LEARNING CHECKPOINT

학생이 이 이슈에서 확인할 것

  • 화면에 보이는 사실과 확인되지 않은 구현을 구분했나요?
  • 기술 이름을 입력·처리·저장·출력 흐름으로 설명할 수 있나요?
  • 팀 역할을 코드·문서·테스트 같은 산출물로 증명했나요?
  • 정상 시연뿐 아니라 오류·한계·복구 과정도 기록했나요?

공개 시연영상 한 편을 골라 문제·데이터 흐름·검증 질문을 정리하고, 가상 또는 공개 데이터 30행으로 핵심 흐름을 축소 재현하세요. Python 정제, SQL 집계, API 정상·오류 응답과 README를 제출하세요.

관심 기술을 대학의 프로젝트로 연결하세요.

전공의 학습 흐름을 이해하고 학생이 직접 만든 결과를 확인한 뒤, 자신에게 맞는 입학 계획을 세워 보세요.