IT 회사의 개발조직 - 느낀 점

IT 개발 조직의 일원이라면 UX와 DX를 모두 고려해야 한다.
- UX -> 사용자 경험 -> 유입 및 리텐션 상승 -> 매출 증대
- DX -> 개발 생산성 -> 비용 감축 && 더 다양한 시도와 빠른 이터레이션으로 장기적 매출 증대 도모
- UX와 DX는 상충되기도 한다. UX를 위해 무거운 라이브러리를 도입했다가 DX가 훼손되는 경우가 그 예이다. 이런 경우에는 정답이 없다. Trade off를 잘 비교해보되, 비슷하다면 UX의 손을 들어주고 이에 수반되는 기술적 챌린지는 문제해결능력을 발휘해서 해소한다.
 
업무 방식
- 워터폴 방식 vs 애자일 방식
- 워터폴: 기획 > 기획 리뷰 > 디자인 > 디자인 리뷰 > 개발
- 애자일: 왔다갔다 빠른 피드백루프
[GPT: IT 서비스 환경에서는 종종 하이브리드 방식이 효과적일 수 있다. 프로젝트 초기에 워터폴 방식으로 전반적인 계획을 세운 후, 개발 단계에서는 애자일 방식으로 전환하여 신속한 피드백 루프를 만드는 식.]
 
조직 간의 이해관계는 자주 상충된다. (일정 산정의 어려움)
- 회사의 사정과 개발 조직의 사정이 다른 경우가 많다.
- 기술부채가 많이 쌓여 업무 효율이 저하되었다: 기술부채는 점차 더 쌓이기에 개발 조직은 더 늦기 전에 리팩토링 및 마이그레이션을 제안한다.
- 경영진 입장에선 투자 라운드, KPI 달성, 주요 고객사와의 계약 등 사업적으로 더 급한 일 때문에 이를 미루고 싶어할 수 있다.
- 둘 다 중요하다. 그래서 적절히 자원을 분배하고 일정을 조율하는 것이 필요하다.
- 예를 들어서 당장은 회사 매출에 필요한 일을 하되, 일과 시간 중 일부(혹은 주중 하루)를 리팩토링을 위해 보장해서 레거시를 조금씩 리팩토링하는 방법도 있다. 아예 기한을 빼주는 것도 좋다.
- 그런 의미에서, 기획이나 개발이나 서로에게 자주 물어봐주는 게 좋다.(개발 쪽에 이슈가 있나? 프로덕트 개발 외에 계획 중인 내부 사안이 있나?)
[GPT: 경영진에게 기술부채가 쌓일수록 장기적으로 유지보수 비용이 상승하고 신규 기능 추가 시 어려움이 증가한다는 점을 데이터로 설명하면 공감대를 얻는 데 도움이 될 수 있습니다. 주기적으로 기술부채를 시각화한 리포트를 제공해 경영진이 쉽게 이해할 수 있도록 하거나, 기술부채로 인해 발생할 수 있는 구체적인 리스크를 경영진과 공유하는 것도 한 방법]
 
분석의 기반은 미리 잡아놓을수록 유리하다.
- 예를 들어 GA 연결, 개발 모니터링(Grafana, Sentry)
- GA 연결은 이용자 행동 분석에 있어 매우 유용하다. 그 과정에서 프론트엔드 개발자의 도움이 필요하면 주저말고 요청해야 한다.
- 개발 모니터링 툴 셋팅도 중요한 이유는 개발적 문제로 서비스가 다운되는 등의 일이 발생하기 때문. 이때 최대한 빠르게 복구해야 한다.
 
커뮤니케이션 tool을 잘 사용하는 것은 팀의 생산성에 중요하다.
- Jira, Slack(슬랙 봇 등), Google calendar, Notion, Spread sheet
- 개발자들은 Github 까지.
 
서비스가 다운되었을 때는?
- 최근에 배포가 나갔다면 일단 롤백해서 재배포한다. 서비스가 무중단 상태를 유지하는 것이 최우선이다.
- 개발자의 능력, 모니터링 툴을 활용해서 최대한 빠르게 원인을 파악한다.
- 개발 서버, 스테이지 서버에서는 문제가 없었는데 DB나 의존성 캐시 문제로 프로덕션 환경에서만 문제가 생길 수도 있다.
- 기획은 가능하면 옆에 붙어서 필요한 지원을 해준다. 보수 작업 중 정책이 필요한 부분을 지원한다든지, 하다못해 QA라도 봐준다.
- 그런 의미에서, 스테이지 서버를 프로덕션 서버와 (가능하면)완벽히 동일한 환경을 구축해놓고 문제를 사전에 발견할 수 있도록 하는 것이 운영 안정성 측면에서 매우 중요하다.
- 또한 장애 발생시 이를 문서화해서 재발되지 않도록 체계를 구축하는 것이 중요하다.
[GPT: 서비스 안정성에 있어 다양한 장애 시나리오에 대한 대응 매뉴얼을 미리 갖추는 것이 중요합니다. 일반적인 롤백과 재배포 외에도, 장애 복구 시나리오별 우선순위(예: 고객에게 직접적 영향을 주는 기능, 결제 기능 등)를 미리 정의하고, 팀 내 역할 분담을 명확히 해두면 서비스 중단 시간 최소화에 도움이 됩니다.]
 
DX를 위한 노력(프론트엔드)
- API 토폴로지 작성
- 스토리북, 테스트코드 작성, 디자인 시스템
- 모노레포 등 레포지토리 구조를 잘 가져가는 것도 중요함.
- 빌드 전략도 매우 중요하다. 빌드 효율화 안되어있으면 한번 테스트하기 위해서 10분 넘는 빌드 시간이 소요된다.
- 주기적인 meet up, 컨퍼런스 참여 독려, 스터디 진행을 통해 개발 실력 상승을 도모한다.
- 더 좋은 툴이 있다면 사이드이펙트를 점검하고 시범적으로 도입해본다.
- 버전업은 매우 성가신 경우가 많다. 버전이 올라가면서 의존성이 얽혀있는 다른 라이브러리가 문제가 되거나, 기존에는 드러나지 않았던 문제(사실 기술부채)가 수면 위로 드러나는 경우도 있다.
- 그러나 기한을 길게 잡으면 늘어진다. 버전업과 같은 사안은 개발자가 고생해야 한다. 적정한 기한을 잡고 무조건 그 안에 사이드이펙트까지 잡고 끝내야한다.
 
기획
- IT 서비스에서 UI를 어떻게 구성하고, 접근성을 어떻게 높이는지는 어느정도 공식화되어있다.
- 회원가입, 자유게시판 등 변수가 많고 정책이 많이 필요한 경우가 있다. 이럴 때 각 단계를 정확하게 짚어줘야 개발자가 상상으로 구현하는 일이 없다. 모든 단계를 꼼꼼히 설계해야 한다. 예를 들어 드롭다운이 있으면 각 항목은 무엇이고 각각 무엇이 목적인지까지 머리 안에 있어야 한다.
- 상상만으로 기획하면 안된다. 개발자들의 능력과 현재 개발쪽 상황을 고려해야 한다. 잘 모르겠으면 물어본다('이런 기획안이 있는데 예상되는 사이드이펙트가 있는지?').
- 아무리 작은 정책 결정이라도 근거가 있어야 한다. (사용자의 특성, 우리 서비스 내부의 통일성, 권위있는 레퍼런스, GA 분석 결과 등)
- 커뮤니케이션을 위해 정확한 용어를 아는 것이 중요하다. 예를 들어 UI 컴포넌트나 인터랙션 이름(뱃지, 드롭다운, 호버링)
- 기왕이면 개발에 착수한 이후에는 기획 변경이 없을 수록 좋다. 따라서 초기부터 꼼꼼함과 짬에서 나오는 예측력이 요구된다. 만에 하나 중간에 바꿔야한다면 추가적인 리소스가 얼마나 투입될지를 고려해야하며(필요하다면 일정 연장), 충분히 실무진들에게 설명해주는게 좋다.

- 개발적 문제라고 생각되지만, 기획자가 정책을 정해주면 좋은 부분들이 많다. (e.g. 닉네임 변경 -> 사용자가 중복확인을 눌렀을 때 DB에 저장하고 lock을 걸 것인지? 저장 버튼을 눌렀을 때 할 것인지? 등)
- 레퍼런스로 참고할 국내외 좋은 서비스를 많이 확보해두고 공유해주기
 
주요 타겟이 B2C인지 B2B인지에 따라 업무는 많이 달라진다. 근본은 똑같다. 최고의 제품을 합리적인 가격에 제공하는 것.