항해99 실전 프로젝트를 앞두고

항해99의 커리큘럼도 이제 종막을 향해 나아가고 있다. 처음 항해를 시작할 때의 나를 돌아보면 VS Code를 처음 사용하며 신기해하고 HTML 태그만을 이용해서 정적인 페이지를 만들고 자바스크립트를 통해 간단하게 움직이는 페이지를 만들고 기뻐하던 순간들이 떠오른다.

아직은 갈길이 멀게 느껴지지만 확실하게 두달 전의 나와는 다른 사람이 되었음을 느낀다. 어느정도 자신감도 생기고 시간만 충분하다면 뭐든지 할 수 있을 것 같은 기분이다. 함께 수강중인 동료들과 많은 선배들과 멘토분들이 도와주신 덕분이다.

독학했다면 겪어보지 못할 협업 과정을 통해 많은 것을 배우고 있다. 프론트 엔드 개발자라고 내 주특기인 리액트만 공부해서는 소통을 할 수 없다는 것을 깨닳는다. 최소한 API를 호출하면 어떤 일이 벌어지는지 알아야하고 구현해야할 기능을 위해 API를 만들어 줄 것을 요청하기 위해서라도 어떤 것이 가능하고 어떤 것이 불가능한지 그리고 내가 할 수 있는 것은 없는지 꼼꼼히 체크한 뒤 요청해야만한다. 그래야 서로 얼굴 붉힐 일도 생기지 않고 근거가 있는 요청으로 상대방을 설득할 수 있기 때문이다.

2주간의 조별 클론 코딩

우리는 유명한 플랫폼 채용 공고 사이트를 클론 코딩하기로 했고 나는 채용 공고 작성을 위해 텍스트 에디터 기능을 구현하는 일을 맡았다.

기존의 라이브러리를 사용해서 빠르게 구현을 마친 후 무한 스크롤과 호버 위젯을 만들어볼 계획이였으나 뜻대로 되지 않았다.

텍스트 에디터는 어떻게?

처음 선택한 라이브러리는 lexical text editor 였다. 마크다운을 지원하면서 기능도 강력하고 커스터마이징도 자유로워보였기 때문에 마음에 들었다. 그러나 이틀 정도 공식 문서를 읽고 관련된 자료를 찾아봤지만 안타깝게도 사용하지 못했다. 지금이라면 조금만 더 시간을 들이면 할 수 있겠지만 커스터미이징이 너무 자유로워 내가 원하는 형태를 구현하지 못했다.

그래서 대안으로 TOAST UI를 사용하기로 방향을 전환했다. 2주 안에 동작하는 앱을 만들어야했기 때문이다. TOAST UI를 선택하게 된 이유는 문서가 자세하게 작성되어 있는 점과 국내의 사용자가 많아 참고할 자료가 많았기 때문이다.

사용할 라이브러리가 정해졌기 때문에 이제 API를 어떻게 설계해야할지 논의하게 되었다.

에디터로 작성한 글을 String으로 저장하여 서버에 저장하기로 정했다. 그러기 위해서는 에디터로 작성한 글을 HTML로 변환해서 서버에 보내줄 필요가 있었다. 여기까지는 순조로웠으나, 이미지를 업로드하는 과정에서 문제를 발견하게 되었다.

이미지를 어떻게 저장할 것인가?

HTML로 데이터를 저장하려면 이미지 URL이 필요했다. TOAST UI의 에디터는 이미지를 넣는 두가지 방법을 제공하는데 하나는 로컬에서 파일을 선택하는 방법과 URL을 입력하는 방식이다. 외부의 URL을 입력해서 이미지를 삽입하는 것은 문제가 되지 않았다. 처음부터 URL을 입력 받았기 때문에 그대로 삽입하면 되기 때문이였다. 파일을 선택하면 TOAST UI는 이미지 파일을 BASE64로 인코딩하여 삽입하도록 되어 있었다. 그렇다면 BASE64 코드를 포함한 어마어마하게 긴 String 데이터를 서버에 저장하는 것이 옳은가에 대한 의문이 생겼다. 문자가 너무 길어 마크다운으로 편집하고자 할때 너무나 불편했고 무엇보다 이미지의 해상도가 커지면 커질수록 텍스트의 길이가 기하급수적으로 늘어날 것이라는 문제였다.

다행히 TOAST UI에서 이미지를 업로드할때 BASE64로 변환하지 않고 이미지 객체를 가로챌 수 있는 훅을 제공하고 있었다. 이 훅을 이용해서 서버에 이미지를 저장하고 URL를 반환해주는 API와 연결한다면 문제를 해결 할 수 있을 것 같았다. 이 사실을 백엔드 조원에게 공유하고 API를 어떻게 설계할 것인지 논의했다. 나의 요구사항은 이미지 객체를 리퀘스트에 담아 호출하면 이미지의 파일명을 무작위로 변경하여 저장한 뒤 이 이미지 파일의 URL을 반환해주는 API를 만들어 줄 것이였다.

서버에 대한 무지로 API가 한개만 추가로 필요할 것이라고 생각했으나 잘못된 생각이였다. URL을 반환해서 보내준다고 해도 파일에 접근할 권한이 없어 이미지를 가져올 수 없었다. 파일에 접근할 수 있는 권한을 열어달라고 거듭 요청했지만 백엔드에서는 그 방법으로는 도움을 줄 수 없었다. 파일을 아마존 EC2에 저장하고 있었기 때문에 파일을 받아올 새로운 API가 또 필요했던 것이다. S3에 파일을 저장하도록 하는 것과 기존처럼 EC2에 저장하는 것 중 무엇이 나을지 의논한 끝에 EC2에 저장하는 것을 유지하고 새로운 이미지를 다운로드 받는 API를 설계하기로 했다.

그렇게 해서 이미지를 서버에 저장한 뒤 파일명을 응답으로 받는 API와 파일명을 요청에 담아 파일을 받는 API로 두개의 API가 만들어졌다. 두 API를 활용해 이미지를 성공적으로 저장하고 삽입하는 것에 성공할 수 있었다.

아쉬운 점과 뿌듯한 점?

우선 아쉬운 점으로는 백엔드 개발에 대한 무지로 인해 요청사항을 좀 더 명확하게 설명하지 못했던 점이다. 나름 명확하게 요구사항을 전달했다고 생각했지만 백엔드 팀에서 여러번 요구사항을 되물어보는 일이 있었고 구현된 API 는 요구사항을 충족했으나, API로 받은 데이터를 활용할때 추가 문제가 발견되어 새로운 API를 더 만들어야만하는 문제가 생겼다. 그 탓에 기능 구현이 많이 지연되고 말았다. 처음부터 요구사항이 더 명확하고 발생될 문제를 예상할 수 있었다면 더 나은 방법을 제인하거나 두번 째 API를 함께 요청할 수 있었을 것이다.

뿌듯한 점이라고 한다면 비록 시간은 걸렸지만 소통을 통해 기능 구현에 필요한 API를 요구할 수 있었고 내가 생각했던 요구사항이 정확히 반영된 API가 작성되 기능이 정상적으로 동작했을 때는 뿌듯함을 느꼈었다. 이미지가 정상적으로 저장되고 에디터에 첨부되는 것을 보며 육성으로 만세를 외쳤었다.

앞으로의 일

이제 앞으로 7주간 실전 프로젝트를 진행하게 된다. 현업 디자이너 또는 디자이너 지망생과 함께 실제로 서비스 가능한 앱을 만들어 배포하고 서비스를 제공해야한다. 지금까지는 디자인을 배우지 않아 다른 웹 서비스의 디자인을 참고해 비슷하게 만들어보거나 대충 그럴싸해보이도록 만들어서 작업했지만 전문적인 디자이너님의 디자인이 적용된다면 얼마나 멋질지 기대된다.

실전프로젝트에서 팀장을 해보고 싶다고 신청했기 때문에 꼭 성공시키고 싶다.