단순 결과가 아닌 "과정"과 프론트엔드 개발자인 "나"를 보여주는 포트폴리오를 만들어 보자이게 포트폴리오를 만든 시작 이었다.
새로운 포트폴리오
취업준비를 시작하며 프론트엔드 개발자인 걸 회사에 어필하는 방법 자체에 고민을 많이 해봤다.
어떤 기술을 사용하고, 어떤 기능을 구현해서, 어떤 결과물을 만들어 내는 것이 포트폴리오의 전부 인것처럼 생각 했었다.
그런 생각의 꼬리에 꼬리를 물때쯤 결국 회사에서 보고 싶은건 "이사람을 돈내고 쓸 만큼의 가치가 있는가" 라고 생각이 들었고
그 가치를 잘 보여주는 게 포트폴리오 라고 생각이 닿았다.
내가 회사 사장이면 어떤 사람을 돈 주고 쓰고 싶을까? 개발 보조 AI는 이미 왠만한 개발자 만큼의 실력을 가지고 있고,
그런 사람보다는 어떤 서비스를 시작할때 작게는 개발하는 전체 과정, 설계 과정을 이해 하는 사람이 더 매력적일 거라고 생각했고
거기에 더해 나는 프론트 엔드 개발자 니까 웹서비스로 나를 보여주면 좋겠다는 생각에 이르러
웹 서비스를 "설계"해 나가서 프론트엔드 개발자인 "나"를 보여주는 과정과 결과물 모두를 보여줘야 겠다고 생각했다.
어떤 방향으로 가야하는가?
- 단순한 UI 구현이 아니라 설계 부터 해나가는 개발
- 데이터 흐름을 파악할 수 있는 구조
- 확장 가능성을 고려한 구조
이렇게 방향을 잡았고, 데이터를 담으면서 그거 하나로도 포트폴리오 처럼 보일 수 있는 Markdown 기반으로 관리하고자 생각했다.
기술적 설계 방향
유지보수, 확장성을 고려하는 방향으로 설계했다.
그러기 위해서 용도에 맞게 파트를 분리 했다.
- content -> Markdown 기반의 데이터
- lib -> 데이터를 처리 하고 변환하는 로직을 담으려고 했다.
- app -> UI 레이어
개발 방식 (TDD + PR)
인강으로 배웠던 것들을 모두 한번정도는 더 써보고 싶었고, TDD를 하면서 불편함도 없지 않아 있었지만, 에러를 최소화 할 수 있는 방안이라고 생각했다.
그리고 개발해 나가는 과정 역시 "설계"의 한 부분이라고 생각해 혼자 개발하지만 협업 환경을 가정하고 PR 할때는 내가 작성 했던 내용을 복기 해본다고 생각했다.
- TDD(Test Driven Development)를 기반으로 로직 설계
- Github PR 을 통해 작업 단위 관리
- 설계 의도를 문서화
목표
프로젝트의 목표는
"어떻게 만들었는가" 와 "프론트엔드 개발자인 나"를 보여주는 것
이 과정을 통해 프론트엔드 개발자로서의 사고 방식을 전달하는 것 이다.
