끄적끄적 계속 작성중인 글입니다. 이 글은 서비스를 운영하고 있지만, ”도대체 내 서비스를 왜 안쓸까?“ 라고 의문이 드는 사람에게 도움이 될만한 글일 수 있습니다. 회고 서비스를 운영하고 있지만, 간간이 들어오는 유저들에 기쁨을 느끼는 과정에서 내 서비스를 이용하는 유저들이 더 활발해졌으면 하는 바램에 직접 유저가 되어 프로덕트를 매일 사용해보기로 했습니다. 내 서비스를 사용하지 않는 이유 내 서비스를 사용하지 않는 이유는 여러 요소가 있습니다. UX가 불편해서 사용하지 않을 수 있고, 서비스가 너무 느려서 사용하지 않을 수 있고, 굳이 이 서비스를 쓰지 않아도 되는 이유도 있습니다. 서비스는 갑자기 “짠!” 하고 나타나지 않습니다. 서비스를 만드는 사람들 중 어느 누군가가 불편함을 느꼈고, 이 불편함을 서비스로 해결하고자 나오게 된 것입니다. 그래서 아무 이유가 없는 서비스는 존재하지 않는다고 믿습니다. “그렇다면 문제를 해결하기 위해 나온 서비스인데 왜 아무도 사용하지 않을까요?“ 사실 회고 서비스 레이어도 주변 회고를 위한 성장 니즈를 위해 만들어진 서비스였고, 여러 기업이나 단체에서 프로젝트가 종료가 되면 한번씩 찾아주는 서비스였습니다. 찾아와주는 것 자체만으로도 감사하지만 여기서 발생한 문제는 “리텐션” 문제였습니다. 사용자가 일회성으로 사용하고 그 뒤로는 들어오지 않는 서비스가 되었습니다. 그래서 회원 수는 천명을 넘어가지만 유지되는 회원 수는 그리 많지 않았습니다. 처음에는 “기능이 뭔가 부실한가? 추가해볼까?“ 라는 생각으로 여러 기능들을 추가해보았지만, 근본적인 원인은 기능이 아니라는 사실을 알게되었습니다. Clarity를 통해 디자이너와 UX를 개선해보기도 하고, 데스크탑 뷰로 확장을 하면서 데스크탑 환경에서도 SasS 형태로 사용할 수 있도록 제공도 해주었습니다. 그럼에도 유저들은 우리의 기능들을 잠깐 반짝여주고 사라졌습니다. 곰곰이 생각해보니까, 우리 팀원들조차도 생각날 때 하는 회고 서비스이기 때문에 정작 내부에서도 유지가 되지 않는다는 문제점을 발견했습니다. 그리고 서비스를 직접 오래 사용해보고 유저가 되어 유저가 느낄만한 불편함들을 해결해보자라는 생각을 했습니다.

정리 for 문과 for .. of 문은 순차 함수이기에 await 비동기 함수를 순차적으로 실행할 수 있습니다. forEach 문에서는 왜 await 비동기 함수를 기다려주지 않을까? 위 코드는 processItem 이라는 함수가 끝나기 전에 "완료"를 출력할 수 있습니다. 왜냐하면 forEach문은 아래와 같이 동작할 수 있기 때문입니다. forEach 문은 콜백이 반환한 Promise를 기다리지 않습니다. 콜백 내부 상황에서 보았을 때 await 자체는 정상 작동하지만, 바깥의 forEach 문에서는 그 Promise를 수집하거나 기다리지 않기 때문에 전체 작업 완료를 추적할 수 없습니다. 정리하면 각 콜백 내부에서는 await이 적용되기는 하지만, 바깥 함수도 forEach의 완료만을 확인할 뿐 비동기 작업의 완료는 확인하지 못한다는 말입니다. map도 await를 자동으로 기다려주지 않는다. 위 코드에서 results 실제 결과 배열이 아니며, Promise[] 형태로 리턴이 됩니다. map 역시 콜백의 Promise를 기다리지 않고, 그대로 배열에 담아 리턴을 해주기 때문에 모든 작업을 병렬로 실행하고 기다리려면 Promise.all로 래핑해주며 사용해야합니다. 왜 이런 방식으로 동작이 되는지, "순차 실행"과 "병렬 실행"의 관점에서 이해해보자. 다음은 순차 실행코드에 대한 예제입니다. 순차 실행 코드는 하나의 작업이 끝난 뒤 다음 작업을 시작하는 방식입니다. 각 작업이 1초씩 걸린다고 가정했을 때, 총 3번의 작업이 이뤄진다면 총 3초가 걸리게 될 것입니다. 이 방식이 필요한 경우에는 아래와 같습니다. 앞 작업의 결과가 다음 작업에 필요할 때 API 호출 순서를 보장해야할 때 서버 요청 제한 때문에 한 번에 하나씩 호출해야할 때 DB 작업을 순차적으로 처리해야할 때 다음으로 아래는 병렬 실행 코드에 대한 에제이다. 병렬 실행 코드는 모든 작업이 거의 동시에 시작됩니다. 각 작업이 1초씩 걸린다고 가정했을 때 총 3번의 작업이 이뤄진다면 모든 작업이 동시에 수행되기 때문에 총 1초가 걸리게 됩니다.

레이아웃 테스트 중에 가장 까다로운 부분 중 하나는 코드 로직 상의 부분도 물론 중요하지만, 레이아웃을 클릭하고 원하는 결과 값을 잡아내는 일입니다. 특정 해상도에서는 버튼이 잘리거나, 목록이 겹쳐보이고, 핵심 정보가 노출되지 않는 등의 일반적인 단위 테스트만으로는 발견하기 어려운 경우가 있습니다. 특히 사내에서는 기능 개발 전 SRS(소프트웨어 요구사항 명세서)로 정리되는 요구사항이 많으면 많을수록, 놓치는 구현사항들이 생기기마련인데 이를 Jira DC(Data Center) MCP와 Brower Skill을 함께 사용하여 요구사항 분석부터 실제브라우저에서의 레이아웃 검증까지 연결하여 이를 해결하고자 했습니다. 테스트 하기 전 제약사항으로는 사내의 업무망은 일반적인 회사와 다르게 폐쇄망으로 구성이 되어있어 내부 프록시에서 허용한 URL만 접근이 가능하고, 인터넷이 차단되어 서비스기업처럼 자유롭게 무언가를 이용하지 못한다는 제한점을 가지고 있었습니다. 요구사항이 매번 흐려진다. SRS를 작성하고, 소프트웨어 요구사항들을 개발자가 파악할 때 텍스트가 길어지면 길어질수록 놓치는 요구사항들이 분명히 생깁니다. 예를 들어 아래와 같은 요구사항들이 명시되어있다고 가정해봅시다. 관리자 화면의 검색 영역을 개편한다. 좁은 화면에서도 필터와 검색 버튼이 깨지지 않아야한다. 목록의 주요 컬럼은 가로 스크롤 없이 확인할 수 있어야한다. 저장 버튼은 화면 크기와 관계없이 접근 가능하다. A 데이터 조건이 왔을 때 B 데이터가 노출되어야하고, C 데이터 조건이 왔을 때는 D 데이터가 노출되는 것과 같이 조건부 렌더링이 성립해야한다. … 그 외 N개가 넘는 요구사항들이 존재합니다. 위 요구사항들이 모두 충족되었다고 해도, 수정 이후 기존 기능에 사이드 이펙트가 발생했는지 기존 화면에 대해서도 회귀 검증을 진행해야합니다. TF에서 공식적인 팀으로 변화되기까지 정식적인 QA 절차가 없다보니 점점 늘어나는 메뉴에 핫픽스 빈도는 점점 늘고있기 때문에 이를 해결하고자 했습니다. Browser Skill의 채택 이유