이제 프론트앤드 개발자로 전향후 일을 시작한지 약 6개월이 다 되어간다.

구직시장에 본격적으로 뛰어들때만큼의 열정이 비록 지금은 조금 시들었지만,
그래도 온기만은 여전히 남아서 열정의 불씨는 살아있다.

프론트앤드 개발자라는 꿈을 이루고, 서서히 시들어가는 열정에 마른장작을 넣어 불씨를 살리고자
지난 6개월동안의 내가 크게 배운 것들을 몇가지 꼽아서 회고를 해보기로하였다.


프로의식을 가져야되는 작업 환경

회사의 업무환경은 개인적으로 매우 좋았다. 서로 하고자하는 작업에 대해 눈치보지않고 시도할 수 있었고, 재택을 통해 효율적이고 유연한 업무 컨트롤이 가능했다.

하지만 업무를 맞게되면 그 이후부터는 혼자서 업무를 드라이브 해야됐었고,
티켓으로 받은 업무에 대한 문제 정의, 설계, 계획을 스스로 수립하고, 유관부서나 기획자들과의 소통 또한 내가 주도적으로 진행을 해야만 했었다.

지난 6개월간 이러한 환경에 적응하기위해 노력했고, 처음에는 내가 일을 하고있는지 아무도 모르기 때문에 잘 하고있는것인지에 대한 걱정이 앞섰지만, 지금은 주어진 업무에 최선을 다하고있다.
적응을 꽤 잘 했는지 업무를 하고 그 외의 남는시간에는 자잘한 기술공유나 코드리뷰, 특히 기존 프로젝트 분석글을 쓰면서 나름의 제품 이해와 개선방향, 취약사항 등을 정리해보고도있다.

지금은 이러한 환경이 프로로써 일을 하는느낌이 들어서 매우 만족하고 있으며, 책임이 주어지는 만큼 큰 성장을 할 수 있으리라 생각하고 있다.


성장에 환경이 중요한가

항상 생각하지만 성장한다는 것은 어떤 업무환경에서든 본인이 하기 나름이라는 생각이 자꾸만 든다.
지금의 이 환경도 누군가에게는 너무 자유롭고 책임감이 크기 때문에 힘들 수 있고, 누군가에게는 나와 같은 생각을 할수도있고, 천직처럼 알맞을 수도 있다고 생각한다.

하지만 업무 환경에 대한 것은 잘 맞지않더라도 돈을 받고 일을하는 프로이니 만큼 본인이 적응을 해나가고 회사와 팀에 맞춰가야된다고 생각하고
성장은 어떤 환경이든지 정말 본인이 하기에 따라서 다르다는것이 나의 생각이다.


나는 그래서 어떤걸 배웠나

1. 서비스 운영 경험

가장 크게 한 경험은 당연히 실 서비스를 운영해보고 개발해봤다는 것이다. 짧은 시간이었지만 그동안 궁금했던 큰 회사의 개발 시스템을 몸소 느껴볼 수 있었고 시스템이 잘 정립되어있고 발전하고있구나고 많이 느꼈다.

우리 팀 같은 경우는 리드분의 방향성이 그런것도 있겠지만, 서비스를 원활하게 운용하는 것에 보다 관심도가 높아서
서비스 운용을 원활하게 하는 것에 대해 경험을 좀 쌓을 수 있었다.

CS를 처리하는것도 서비스 운영에 있어 굉장히 중요한 부분이었는데,
고객이 준 정보를 단서로 다양한 로거들에 남겨진 로그를 검색하고 분석하여 고객이 어떤 테스크를 했는지 사용자 추적을 하면서 인과관계를 파악하는 등의 일을 해볼 수 있었고,

이러한 경험을 토대로 고객의 사용과정을 추적할 수 있는 로그의 중요성을 새삼 다시한번 깨닫고
로그는 왜 남겨야되는지, 어디에 남겨야되는지, 무엇을 어떻게 남겨야되는지 등을 생각해 볼 수 있었다.

리드분의 기술세션으로 많이 배웠다.

개인적인 경험으로는 로그는 무엇보다 탐색이 편해야 된다는 생각이다. 때문에 로그 또한 정책이나 설계를 탐색 편리성을 고려하면서 디테일하게 가져가야 된다고 생각한다.


2. Frontend에서의 Proxy Server

우리 회사에서는 보안정책상 내부 API를 노출시켜서는 안되기 때문에 프론트에서 API 호출에 대한 Reverse Proxy 서버를 구축해서 사용하고 있다. Proxy Server를 Express를 이용해서 구축하다보니 간접적으로나마 백엔드 경험을 할 수 있어서 좋았고 Express 경험이 있었던 터라 다행이 잘 적응할 수 있었다.

그동안 잘 몰랐지만 이런 Proxy 서버를 이용해서 다양한 걸 할 수 있었는데, 여러 조각 나뉜 API들을 mashup하고 가공하면서 BFF로 활용할 수도 있고, 외부 API를 이용할 때에도 다양하게 활용할 수 있다고 느꼈다.

예를들어서, 화면을 호출하는 외부 API를 이용할 경우에 보통 returnUrl을 parameter로 전송하게 되는데,
이 returnUrl을 Proxy Server에 라우팅된 경로로 넘겨서 외부 API 화면에서 작업한 결과를 백앤드 도움 없이 프론트에서 직접 받아 처리할 수 있는 등의 활용을 할 수 있다.

화면을 호출하는 외부 API는 예를들어 본인인증 pass 팝업, 소셜로그인 등이 있겠다.

추가로 프론트단에서 못잡는 post의 body데이터 등을 Proxy Server를 통해서 캐치할 수 있고, middleware단에서 로깅이나 특정 경로를 잡아서 redirect등의 다양한 작업도 처리 할 수 있는 것을 알게되었다.


3. Next 사용

사실 Next는 어떤것인지만 알았지 입사전에는 사용해본적이 없었는데 Next로 구축된 제품의 프로젝트에 involve 되면서 사용해볼 수 있었다.

Next의 경우 Proxy Server없이 Next 자신의 API Routing을 통해 Proxy API를 구축할 수 있었었는데,

Next 자체의 API Routing, Middleware를 구축할 수 있지만,
우리 팀의 경우 Custom Server 패턴을 통해 express integration을 해서 사용하고 있었다.

다른 프로젝트의 express로 구축된 Proxy Server와 동일한 패턴으로 코드베이스가 생성되는 것 같았고, 보다 서버사이드에서 low한 처리를 해볼 수 있다고 생각하게되었다.


4. 사용자의 입력도 비동기 처리다

프론트앤드 개발을하면, 특히나 중요한게 비동기 처리인 것 같다. 싱글스레드로 이루어진 Javascript Engine (V8)을 탑재한 브라우저로 병렬처리를 하기 위해서는 비동기 방식을 사용할 수 밖에 없기 때문이다.

이 중요한 비동기 처리방식에 대해 한단계 확장되는 생각을 하게된일이 있었는데, 우리팀에서 진행했던 테크세션에서 팀원분이 한 발표였다.

바로 사용자의 입력도 비동기 처리로 볼 수 있다는 것이었는데,

const handleButtonClick = () => {
  somePopupOpen();// 새로운 작업을 위한 팝업 오픈 (화면을 호출하는 외부 API 등)
}

...
 
// 팝업에서 post message 를 통해 작업 결과 전달
window.addEventListener('message', (event) => {
  const { result } = event;
  nextProcess(result); // 다음 작업 수행...
  ...
});

위 코드를 보면 사용자의 입력인 버튼 클릭을 하고 나서 팝업을 오픈하고 이후의 결과를 message listener에서 받아 진행하지만 코드량이 많고 복잡할 경우에, 코드레벨에서 진행상황을 쫒아가기 어렵다는게 문제가 있었다.

결국에는 사용자의 입력도 비동기이고, 위 post message를 통해 값을 받고 실행하는 부분이 일종의 callback 함수로 볼 수 있는데, 이러한 같은상황에서 async awiat과 비슷하게 동기적으로 코드를 작성 할 수 있₩다면 작업자가 아니라도 다른 사람이 볼 때 작업 프로세스를 쫒아갈 수 있게 된다.

let popupWorkCompleteResolver;

const handleButtonClick = async () => {
  somePopupOpen();
  const popupPromise = new Promise((resolve) => popupWorkCompleteResolver = resolve)
  const result = await popupPromise(); // 동기적으로 작업을 대기할 수 있음
  nextProcess(result); // 다음 작업 수행...
  ...
}
  
// 팝업에서 post message 를 통해 작업 결과 전달
window.addEventListener('message', (event) => {
  const { result } = event;
  popupWorkCompleteResolver(result);
});

위 코드를 보면 분산되어있던 로직이 handleButtonClick에 모아졌음을 볼 수 있다.

물론 message listener에서 popupWorkCompleteResolver를 실행하는 부분은 있어야 한다.

이 처럼 사용자의 입력또한 비동기작업과 같고, Promise나 Future등을 활용하면 이러한 부분들도 동기적으로 작성할 수 있다는 점을 배울 수 있었다.


5. 프론트앤드 로깅

로깅은 앞서 1. 서비스 운영경험에서 일부 작성하였지만 너무도 중요한 부분같아서 별도 배운점으로 적어두려고 한다.

일을 하면서 로그를 남기는 이유가

  • 서비스 정상작동 확인
  • 서비스 오류 확인
  • 사용자 추적 및 서비스 흐름 파악
  • 서비스 운용지표로 활용
  • CS 업무 대응

등이 있다는 것을 알게되었고, 실제로 운영해보면서 많이 중요하다는 것을 느꼈다.

로그 스택은 우리 팀에서는 클라이언트 사이드로 Kinesis를, 서버사이드로는 Application 로그를 활용한 Cloud Watch를 사용하고있고, 애러상황은 Sentry Browser, Node를 통해서 추적하고 있어서 이와 관련된 경험을 해볼 수 있었다는것도 굉장이 좋았다.


6. TDD 경험

팀에서 온보딩 겸해서 진행한 첫 프로젝트를 TDD를 활용해서 개발을 진행했었었다.

먼저 테스트코드를 작성하고 개발을 하려니 상당히 어색했지만 찐 TDD를 실제로 경험해 볼 수 있었고 다양한 장단점을 생각하게 되었던 것 같아서 좋았다.

물론 많이 경험해보지 못해서 제대로 느낀건 아니겠지만,

내가 TDD를 하고 느낀것은 아래와 같다.

  • 그냥 테스트코드를 막 적어서는 안된다. TDD도 테스트하려는 모듈이나 컴포넌트의 충분한 설계를 하고나서 진행해야 된다는 것.
  • 그렇다고 처음부터 너무 완벽하게 설계할 필요는 없다는 것. TDD는 사이클을 계속 돌기 때문.
  • 컴포넌트 테스트는 과연 필요할까에 대한 생각
    -> 지금은 공통 컴포넌트에 대해서만 테스트코드가 필요하다고 생각하고 있다.
  • 테스트코드의 description을 통해 모듈에 대한 스팩정리가 된다는 점.
    -> 사실 이게 TDD에서 가장 좋았던 부분이다.
    -> 스팩을 별도 문서 없이 코드로 나타낼 수 있다.

7. 커뮤니케이션

6개월 동안 일을하면서 커뮤니케이션을 할 때 중요하다고 생각하게된 것이 있다.

  1. 커뮤니케이션을 주도적으로 해야한다.
  2. 질문에 수용적이어야한다.
  3. 답변을 들었다면 항상 감사의 말을 전하자.

위 내용들인데,

커뮤니케이션을 주도적으로 해야된다는건 업무 환경 자체가 주도적으로 일을 해야되기 때문에 당연히 자연스럽게 길러지고 있지만,
왜 주도적으로 커뮤니케이션을 하는것이 중요한지 느낀 순간순간들이 있었다.

처음에 입사해서는 이런거 물어봐도 되려나 하면서 망설이고 했던 것들이 있었는데,
고민하는 시간동안에 나의 리소스는 줄어들고, 생산성 저하가 발생하였고,
적극적으로 커뮤니케이션하지않고 넘어갔을 때 오히려 더 큰 후폭풍으로 되돌아 올 수 있다는 것을 알게되었다.

때문에 생산성과 더 나은 프로덕트를 위해서라도 적극적으로 커뮤니케이션해야된다고 생각하게 되었으며, 노력해야된다고 생각하고있다.

질문에 수용적인 태도를 갖춰야 된다는건 지난 6개월 동안 일을 할 때의 커뮤니케이션은 주로 질문과 답변으로 이루어졌었는데,
질문에 수용적인 태도를 갖추신분들과 일을 할 때가 업무효율도 좋고 업무의 진행도 가장 좋았었다.

때문에 나도 질문에 수용적인 태도를 갖춰서 다른사람들이 나에게 편하게 질문을 할 수 있는 대상이 되고싶다고 생각하였다.

마지막으로 답변에 감사의 말을 전하는건 그냥 내가 살아가면서 감사의 표현을 하는것이 중요하다고 생각하는것도 있지만,
업무적으로 나와 일을 같이 하는것이 좋은경험으로 남을것 같다고 생각한다.

실제로 감사표현을 했을 때 상대방도 더불어 감사표현을 한다던지, 다음에 그 상대방과 일을 할 때 커뮤니케이션이 보다 수월해진다던지, 내가 보다 일을 즐겁게 하게된다던지 등의 경험을 하게되었다.


### 8. 모나드... 찐 함수형 프로그래밍 경험

팀 내부에서 관리하는 제품 중에 엄청 잘 활용되고있는 것 같지는 않지만 Monad가 사용된 프로젝트가 있는데, 이 소스를 보면서 진정한 함수형프로그래밍을 보게된 것 같다.

지금껏 js로 함수형을 해봤자 순수함수를 만들고 불변성을 지키고 등등의 것들만 해왔는데 이것은 진정한 함수형 프로그래밍이 아니다 라는것을 깨닫게 되었고, 나중에 한번 함수형 프로그래밍에 도전해보고싶다는 생각을 하게되었다.

모나드는 설명을 보고 지금도 봤지만 아직 정확하게 뭔지 모르겠다… 나중에 꼭 이해하고싶다.


9. SaSS 설계를 위한 12 Factors

팀 내부 채널에서 공유된 내용인데,

를 보면서 많은 생각을 했던 것 같다.

특히나 팀에 합류하고 기대와 다른 코드들을 보면서 레거시와 기술부채는 존재할 수 밖에 없다고 생각했었는데, 이 기술부채를 줄이는 시점을 잘 판단하기도 해야되지만 우선 설계부터 독립적이고 점진적으로 발전시켜나갈 수 있는 형태라면 레거시나 기술부채가 쌓여있더라도 괜찮다라는 생각을 최근에 하게되었었다.

그러던 중에 12Factor라는 설계방법론을 알게되고 이런 원칙을 지키면 충분할 것 같다고 생각하게 되었다.


앞으로 무엇을 발전시키고 싶나

서비스 운용능력

지금 이제 막 능력치를 올려가고 있다고 생각하지만 로그를 활용한 사용자 추적이나 애러 추적, 데이터 모니터링등과 같은 능력을 포함해서 서비스를 운용하는데 필요한 능력을 계속해서 발전시켜나가고 싶다.

물론 개발적인 부분도 놓치지 않을거다.


커뮤니케이션 스킬

커뮤니케이션 스킬은 협업할 일이 많아서 커뮤니케이션이 많은 프론트앤드 개발자이기 때문에 계속해서 발전시켜나가고 싶다.

특히 유관부서 관계자나 기획자 분들 등 협업하는 사람들이 나에게 편안하게 질문을 할 수 있는 대상이 되고싶고 적극적으로 의견 개진을 할 수 있는 사람이 되고싶다.


개발능력

당연히 개발자로써의 근본인 개발능력 또한 계속해서 발전시켜나갈 생각이다.

개발 생산성을 좀 늘려보고싶고, 프론트엔드에서의 애러핸들링, 올바른 설계 부분에 있어서 고민하고 알아가고싶다.


마무리하며

개인적으로 지난 6개월간의 회고에 대한 경험이 너무 좋아서 반기별로 회고글을 투고하고자한다.

앞으로 회고가 이따끔씩 나의 불씨에 마른장작을 넣는 일이 되었으면 좋겠다.