[ je개발 회고 ] H/F 프로젝트 회고 (3) - F 프로젝트(feat. 기획 / 디자인)

1. 기획과의 소통

F 프로젝트는 실제 우리 회사 기획자들(두 분)께서 직접 기획해서 만들어지는 도메인이다. 아무래도 내가 프론트엔드를 메인으로 담당하고 있기 때문에 회의에도 같이 참석하고, 직접 피드백도 받고 소통을 많이 했다. 처음으로 기획자와 직접 소통하는 것이다 보니 처음 회의 참석할 때 핸드폰의 녹음기도 켜서 무엇을 원하시는 건지, 내가 개발할 때 가장 중요하게 생각해야 하는 것은 뭔지 하나도 놓치지 않으려고 노력했다. 하지만 언제나 현실은 녹록치 않다.

기획 파악의 어려움

고등학생 때 공부했던 게 생각이 났다. 항상 문제를 보면 "출제자의 의도를 파악하라" 가 관건이었는데, 회사에 오니 "기획자의 의도를 파악하라" 가 관건이었다. 냉정하게 평가했을 때, 개발할 당시에는 기획 의도를 제대로 파악하지 못했다고 생각한다. 그 이유로는 두 가지가 있다.

첫 번째, 데이터에 대한 이해가 부족했다. 정확하게 표현하자면 이 데이터들을 통해 어떤 정보를 얻을 수 있는지를 몰랐다. 이게 가장 큰 걸림돌이었다. 그래서 왜 이걸 만들지? 내가 지금 만들고 있는 게 무엇을 의미하지? 를 계속 생각하게 만들었다.처음 H 프로젝트를 시작했을 때도 내가 우리 회사의 데이터에 대한 이해도가 부족해서 따로 여러 번 물어보고, 이 데이터들이 무엇을 의미하는지 알아보려고 노력했었다. 하지만 그 노력을 비웃기라도 하듯, F프로젝트에서 다루는 데이터의 범위는 기존 H 프로젝트의 데이터를 아득히 뛰어 넘었고, 이 데이터들이 무엇인지는 알았지만 어떻게 활용되는지를 몰랐다. 그렇다고 이걸 한 번 쭉 물어보기에는 시간이 없었다. 개발하기만도 바빴다. (망할 4분할! 망할 Tooltip! 자세하게 쓸 수는 없지만... 나중에 기회가 된다면 이 기능들 관련 스토리와 개발 과정으로 블로그를 작성해야할 거 같다.) 그렇다 보니... 기획 의도는 제대로 파악하기 어려웠다.

두 번째, 너무 개발자의 마인드로 접근했다. 프론트엔드 개발자인 이상 많은 시간을 들여서라도 브라우저 렌더링 최적화를 해야 한다고 생각한다. 하지만, 기획에서 내려오는 요구사항은 렌더링을 더 느리게 만드는 것들이었다. 예를 들면, 차트 라이브러리를 사용하는데 이 라이브러리에서 지원은 하고 있지만, 평범한 사용법대로는 절대 사용할 수 없다거나(이를 위해 많은 가공처리를 해야 했다), 아예 그 기능 지원 자체를 하지 않는... 그런 요구사항들이었다.(망할 4분할! 망할 Tooltip! / 그외 기타 등등의 기능들!) 문제는 이게 한 번에 딱 요구사항으로 온 게 아니라 시간 지나서 하나 오고, 시간 지나서 하나 와서 기존 코드에 덕지덕지 붙이는 방식으로 코드를 작성할 수밖에 없었다. (이래서 내가 요구사항에 유연하게 대처할 수 있는 유지보수가 가능한 코드에 집착하는 것이기도 하다) 그렇다보니, 개발에만 신경을 쓴 것 같다. 요구사항이 오면 기획의 의도를 알기도 전에 "아... 이거 그냥 도입하면 화면이 버벅거릴 거 같은데" 이런 생각이 먼저 앞섰다(4분할 화면으로 넘어가면 너무 많은 데이터를 fetch 하고 요구사항 반영을 위한 많은 가공처리 후에 차트로 그려야 하기 때문) 만약 기획 의도를 정확히 캐치할 능력이 있었다고 하면 렌더링 최적화에 도움이 되면서 기획자 분들이 원하는 형태를 제시할 수 있지 않았을까 싶은데 그러지를 못한 거 같다. (물론, 이제는 왜 그렇게 기획하셨는지 다 알 것 같다)

소통 능력 부실

뼈저리게 느낀 것 중의 하나다. 개발의 에러 사항이 발생했을 때 그것을 기획자 분들에게 잘 전달하는 것이 어려웠다. 개발자들 사이에서 쓰는 용어들을 어떻게 풀이해서 전달해야할 지도 감이 안 잡혔다.

한 가지를 예로 들자면 해상도 관련 문제였다. 한 화면의 전체 해상도와 한 화면을 4분할로 쪼갰을 때 그 분할된 칸의 해상도가 다른 것을 조리있게 설명하지 못했던 것 같다. 기획자 분들은 한 페이지의 사이즈를 1/2, 1/2 로 줄여서 4분할로 쪼개진 화면의 한 칸에 넣으면 되지 않냐는 말씀을 하셨지만... 그게 그렇게 간단한 일이 아니라는 것을 설명하기가 너무 어려웠던 것 같다. 크롬의 경우, 브라우저 폰트 크기 10px 제한이 있다는 것이나 1920*1080 기준(반드시 1920 기준이었어야 했다)으로 만드는데 있어서 4분할 했을 때는 해상도가 확 낮아져 뭉개져 보이는 문제라던가... 지금이라면 잘 설명할 수 있을 거 같은데 당시에는 내가 너무 어리버리했던 것 같다.

하지만 소통과 개발은 확실히

그래도 한 가지... 잘 된 것이 있다고 한다면 피드백 만큼은 최대한 빠르게, 소통을 최대한 원활하게 하려고 노력했다는 점이다. 그리고 내가 문제가 있다고 생각하는 것들이 있었던 것들은 엑셀 파일로 정리해서 보내기도 했고, 무엇이 문제인가에 대해서 잘 전달하기 위해 노력했다.

또, 내가 생각하기에 좋은 컨텐츠가 있다고 하면 말씀드려서 추가 개발을 했다. 아무래도... 나는 이 프로젝트에 대해 애정이 있는 편이라 정말 잘 만들고 싶다는 마음이 컸다. 그렇다보니 내가 부족한 부분들을 어떻게든 커버하기 위해서 다른 내가 잘할 수 있는 것들로 채워 넣으려 노력했다.

얻은 것

많은 선배 개발자가 개발자의 중요 덕목 중 하나로 "소통"을 꼽은 이유를 알게 되었다. 이번 기회 덕분에 코드를 작성하다 문제에 봉착하면 이것을 어떻게 하면 다른 사람들에게 잘 설명할 수 있을까. 어떻게 하면 비개발 직군에 있는 분들에게 내가 마주한 에러를 설명할 수 있을까를 습관적으로 생각하게 되었다.

또, 기획자와 개발자가 바라보는 관점이 많이 다르다는 것도 느꼈다. 그래서 개발자는 개발에만 몰두하면 더 큰 성장을 할 수 없다는 것도 깨달았다. 물론, 그렇다고 해서 나는 지금 UI/UX 를 공부한다거나 그러지는 않을 생각이다. 지금의 나는 조금이라도 더 개발 지식, 컴퓨터 공학 지식을 더 넓히는 것이 최우선 과제라고 생각한다. 그 외의 것들은 지금부터 쌓기보다는 나중에 쌓는 것이 내 커리어에 더 도움이 될 거라 생각한다. 하지만 그렇다고 해도 그 부분들을 아예 놓고 갈 수 없다는 것을 깨달았다. 최소한 소통을 하는데 있어서 개발의 부분만을 생각하지 말고, 다른 직군인 분들의 말씀과 의도를 캐치해야겠다.

---

2. 디자인과의 불통

할많하않

우리 회사에는 디자이너가 없다. 디자인을 외주에 맡긴다. 그런데, 진짜 소통이 1도 안 된다. 하... 디자인 온 거 보면 폰트 크기 뒤죽박죽 섞여 있고(결국 내가 통일했다), 마진이나 패딩값도 통일되지 않고(적어도 좌우, 상하 대칭 정도는 해줘야 하는 거 아닌가. 왜 상하좌우 다 값이 제각각인걸까), SVG 파일 줘서 확인했더니 우리에게 던져준 시안 그대로의 디자인은 또 아니고(결국 내가 일러스트로 수정했다), 색상 팔레트도 결국 기획자분들이 다 정하시고(나도 이렇게 짜증나는데 기획자 분들은 얼마나 싫으셨을까) 하... 프로젝트 마지막에 가서는 틀은 다 잡았으니 디테일 작업할 때 디자인 온 시안 무시하고 개발했다. 애초에 그렇게 만들 수도 없었다. 웹 특성에 대한 고려는 1도 안 된 디자인이었다. 팀장님의 오더로 디테일한 부분은 그냥 무시했다.

원래 디자이너들과 소통할 때는 이러지 않겠지. 그런 희망을 품을 뿐이다.