1.4 프로젝트 산출물 가이드
1. SW 개발 표준 산출물 가이드
1. 코딩은 결과다.
[1] 연애에서, 고백이 관계의 시작이 아니라,
[2] 관계의 확인이듯
[1] 프로그래밍에서, 코딩은 프로그래밍의 시작이 아니라,
[2] 분석·설계(UI·Logic·Data)를 통해 확정된 결과를 코드로 옮겨 프로그램을 완성하는 단계이다.
개발자가 하는 일은,
컴퓨터로 문제를 해결하는 것이지, 코드를 작성하는 사람이 아닙니다.
2. 프로그램의 본질과 분석 설계 단계
프로그램은 본질적으로 Data(데이터)와 Logic(로직) 그리고 UI(사용자 인터페이스) 가
유기적으로 연결되어 있기 때문에
분석과 설계를 단계별 나누어 진행할 수는 없습니다.
경험이 쌓인 개발자가 되기 전까지, UI(사용자 인터페이스) 를 확정지은 결과를 기반으로
많은 프로그램을 만들어 경험을 쌓고,
이후에 요구사항에 맞춰 분석과 설계 단계를 유동적으로 진행합니다.
3. 프로젝트 산출물 제작 추천 단계
Step 1.기획 의도
Step 2. UI
Step 3. 로직
Step 4. 데이터
Step 5. 일정
Step 1. 기획
└─ 기획 의도, 문제 파악, 타당성 조사
└─ 유스케이스
Step 2. UI
└─ 목업 ( ≒ UI 프로토 타입, StoryBoard, Wireframe)
└─ 화면 구성도 (= 메뉴 구조, 사이트 맵)
└─ 시스템 구성도(인터페이스 구조도)
Step 3. 로직
└─ 요구사항 명세서
└─ 순서도
방법 1. Draw.io 에서 수동으로 직접 작성
방법 2. 플로우차트 만들기 - 무료 순서도 그리기 | Canva(캔바)
방법 3. Eraser
Eraser – AI co-pilot for technical design
Deliver accurate, consistent designs faster.
app.eraser.io
코드 기반 Flow Chart 생성
사용 순서
1) 요구사항 분석
2) GPT 에 요구사항 기반으로 eraser.io 사이트의 Flow Chart 코드 생성해줘
3) eraser.io 붙여넣기
Step 4. 데이터
└─ DB 테이블 명세서
└─ ERD
엔티티와 속성 네모랑, 연결선만 있어도 충분함,
관계(Cardinality) 표시 신경 안씀. 포폴에 보이지도 않음
하지만.. ERD 를 추가하면 무조건 무조건 진짜 채용에 플러스 요인이 됨.
자료1) ERD, 어떻게 설계하는 걸까? — writing up (tistory.com)
자료2) https://youtu.be/Zpg478GBao4?si=BObyLIBvY9ZjAuaF
자료3) https://youtu.be/jsOPr3QfMW0?si=mpLsko6qH8kHFvy3
Step 5. 일정과 계획
└─ 일정표
2. 포트폴리오 예시 (1)
└─ 포트폴리오는 본인만의 전략을 반영해야 합니다.
아래는 하나의 포폴 예시일 뿐입니다.
지원자들 사이에서, 상대적 평가 우위에 서기 위해서는
본인만의 포트폴리오 구성으로, 프로젝트에서 어떤 부분을 어필할 것인지 전략이 필요합니다.
표지, 목차, 개인 프로필
프로젝트 제목 및 소개
초기 1~2페이지에서는 1)프로젝트 제목과 함께 2)기획 의도, 3)시스템 구성도, 4)핵심 프로토타입을 제시하여,
면접관(평가자)가 별도의 설명 없이도 이미지 만으로 프로젝트가 무엇인지, 목표를 쉽게 판단할 수 있도록 구성한다.
분석과 설계
분석·설계 단계에서는 요구사항 분석과 시스템 설계를 통해,
단순 코드 작성에 머무르지 않고 프로그래밍 대상과 현장 운영 환경을 함께 고려하여 요구사항과 시스템 구조를 통해
기능 구현을 넘어, 시스템 전체를 이해하고 서비스 단위의 문제를 해결하는 개발 역량을 보유하고 있음을 어필한다.
스크린샷, 구현 영상, 테스트 케이스 + 개인 어필
세 번째 단계에서는 구현 화면 캡처, 시연 영상, 테스트 케이스를 중심으로 최종 산출물을 체계적으로 정리하고,
프로젝트 전반에서 수행한 개인의 역할과 기여 내용을 구체적으로 제시한다.
장애 상황에 대한 시나리오와 테스트 결과를 포함함으로써 실무 관점의 신뢰도를 높이며,
후기를 통해 협업 경험과 문제 해결 과정, 개인적 성찰을 함께 기술하여 개발자 개인의 태도를 종합적으로 어필한다.
└─ Part 1. 프로젝트 소개
면접관이 프로젝트 설명 없이 내용을 읽지 않아도, 목표를 쉽게 판단할 수 있도록 구성 합니다.
└─ Part 2. 분석 & 설계
단순 코드 작성에 머무르지 않고, 시스템 전체를 이해하고 서비스 단위의 문제를 해결하는 개발 역량을 보유하고 있음을 어필합니다.
└─ Part 3. 개발 과정
분석·설계 이후에는 해당 내용이 실제 구현 과정에 어떻게 반영되었는지를 함께 제시하는 것이 중요합니다.
이를 통해 설계가 단순한 문서 작업에 그치지 않고,
코드 구조와 기능 구현 단계에서 설계와 구현을 일관된 흐름으로 연결할 수 있는 개발 역량을 명확히 보여줄 수 있다.
└─ Part 4. 구현 결과
실제 동작하는 시스템으로 완성되었음을 강조한다.
이는 단순 구현 능력을 넘어, 설계와 구현을 일관된 흐름으로 설계 의도를 이해하고 이를 코드로 옮길 수 있는 실무형 개발 역량을 강조한다.
└─ Part 5. 테스트 결과
(유닛 테스트는 생략한다. 포폴에 담기에 문서가 너무 형식적이다.)
분석·설계 단계에서는 기능 구현 여부뿐 아니라,
실제 서비스 환경에서 발생할 수 있는 장애 시나리오를 현장 관점에서 함께 고려해야 한다.
들어 점심시간 카페 주문 시스템의 경우,
평균 주문량만을 기준으로 설계하면 문제없어 보이지만,
짧은 시간에 트래픽이 폭증하는 피크 타임에는 시스템 병목이 발생할 수 있다.
이러한 상황을 사전에 분석하고 설계에 반영함으로써,
단순히 코드를 작성하는 개발자가 아니라
현실의 운영 환경과 사용자 행동을 이해하고 서비스를 안정적으로 설계할 수 있는 개발자로 성장하고자 했음을 어필해야 한다.
- "분석·설계 단계에서 장애 시나리오를 함께 고려함으로써, 기능 구현을 넘어 실제 서비스 환경에서 안정적으로 동작하는 시스템을 설계하는 관점을 기르고자 했다."
- "이 프로젝트는 왜 아키텍처가 필요한지를, 장애가 발생하는 현실적인 서비스 시나리오를 통해 설명한다."
└─ Part 6. 태도 및 역할 어필
마지막으로 프로젝트는 무엇을 만들었는지뿐 아니라,
개발자로서 어떤 태도로 문제를 대하고 역할을 수행했는지를 함께 보여주어야 한다.
"기술 역량 위에 책임감과 협업 태도를 더해, 현장에서 함께 일할 수 있는 개발자로 성장하고자 했다." 는 관점으로 작성한다.
3. 포트폴리오 예시 (2)
└─ 포트폴리오에 정답은 없지만, 오답은 존재합니다.
글자와 내용이 빽빽하게 많다고, 좋은 평가를 받지 않습니다.
포트폴리오는 정보의 양보다 여백과 가독성을 우선하여 구성합니다.
4. 명심 할 것
이세상 모든 업무는
문서에서 시작해서, 문서로 끝납니다.
소프트웨어, IT 관련 업무도 모두 문서입니다.
소스코드도 문서입니다.
심지어 아키텍처 패턴 조차
소스코드 문서를 카테고리(관심사) 별 폴더로 관리하는 방법일 뿐입니다.
문서 만들기 싫으면 회사원을 하지 말고
개인 사업해서 문서없이 운영하시길 바랍니다.
나는, 내가 받으려는 월급 만큼 회사에 돈을 벌어다 줄 능력이 있는지 생각해보고 노력합시다.
회사는 월급도 주고, 교육도 시켜주는 자원봉사단체가 아닙니다.
공정한 계약관계가 성립될만한 능력을 갖추셔야 합니다.
소프트웨어 개발 과정을 고려 하여, 내가 클라이언트의 요청을 받아 프로젝트를 진행한다고 관점으로 접근합시다.