Spoko

혼다 프로젝트가 끝나고 다음 프로젝트까지 공백이 있을 것이라는 이야기를 듣고 일본어 강의를 결제하자 마자 새로운 프로젝트에 투입됐다. 회사원으로써 당연히 프로젝트에 집중해야 헀지만, 매니저님의 배려 덕분에 4월은 학원과 프로젝트를 병행할 수 있었다. 그렇게 나는 급작스럽게 Spoko라는 프로젝트에 참여하게 되었다. 아마추어 러너(runner)들이 달리기 자세를 프로 선수들에게 멘토링 받는 서비스를 개발하는 프로젝트였다. 프로젝트가 안정화 된 후 끝까지 딜리버리(delivery)하지 않고 나왔지만, 이 프로젝트에 대한 내용을 회고 글로 정리해본다.

SwiftUI

프로젝트에 급작스럽게 투입되어 컨텍스트(context)를 파악하는 것도 힘들었지만, SwiftUI라는 큰 장벽이 나를 맞이했다. 어떻게 보면 나에겐 행운이기도 했다. 이미 안정된 딜리버리 파이프라인이 구축되어 있었기 때문에 이를 베이스(base)로 많은 것을 배울 수 있을 것이라 기대했다. 프로젝트, 테스트 환경 구성에는 다음과 같은 것들을 사용했다.

• Gitlab CI Runners
  • iOS 애플리케이션의 빌드 자동화를 위해선 MacOS 머신(machine)이 필요
  • Gitlab CI는 MacOS 가상 머신을 제공하지 않으므로 실제 맥북(macbook)을 연결하면 iOS 애플리케이션 개발을 위한 자동화 파이프라인을 구축이 가능
• xcodegen
  • 프로젝트 설정, 의존성 등을 관리할 수 있는 도구
  • 잦은 충돌이 발생하는 iOS 프로젝트 파일(.xcodeproj) 대신 yml 파일로 프로젝트 설정에 대한 형상 관리가 가능
• fastlane
  • 루비 기반 iOS, 안드로이드 배포 프로세스를 자동화하는 도구
• TestFlight
  • 테스터(tester)들이 테스트 버전 애플리케이션을 다운로드 받아 베타 테스트가 가능하도록 돕는 도구

위 내용들은 내가 프로젝트 투입 전에 이미 구축되어 있었기 때문에 손 볼 수 있는 기회가 많이 없었다. 그래도 위 키워드들을 얻고 실제 동작하는 모습을 확인할 수 있다는 것만으로 큰 수확이었다. 나는 프로젝트 환경 구성보다는 SwiftUI 프레임워크를 사용해 iOS 애플리케이션을 잘 개발할 수 있을까 고민했다. iOS 애플리케이션 개발은 완전 초보자나 다름 없기 때문에 너무 많은 것에 집중하지 않았다. 프로젝트 과정에서 얻은 인사이트(insight)나 배운 내용들을 글로 정리하고 있다. 이미 일부 정리한 내용들도 있다.

• Swift 언어의 구조체와 클래스
• SwiftUI 프레임워크의 MVVM 패턴
• iOS 클라이언트의 키-체인(key chain)과 유저-디폴트(UserDefaults) 저장 공간
• 재사용 가능한 컴포넌트 만들기
• 재사용 가능한 디자인 컴포넌트 만들기
• ViewInspector 라이브러리를 이용한 다양한 케이스의 단위 테스트 코드 작성

이 외에도 개발 중 마주친 문제들에 대한 해결 방법들도 함께 정리해 나갈 예정이다. 이미 구축된 프로젝트 환경에서 서포터로 투입되었기 때문인지 마음에 여유를 갖고 새로운 언어와 프레임워크에 대해 많은 것들을 배울 수 있었다. 다음에 기회가 된다면 스크래치(scratch)부터 iOS 애플리케이션을 개발하는 프로젝트에 참여하고 싶다.

Career Advancement

나는 프로젝트에 투입되자마자 스프링 시큐리티 프레임워크로 구성한 인증 구조를 고치는 일을 맡았다. 하나의 백엔드 서비스가 OAuth2 인증 과정에 참여할 때 웹 애플리케이션 인증 프로세스인지 iOS 애플리케이션의 인증 프로세스인지에 따라 역할이 달라지면서 이후 진행되는 비즈니스 로직이 복잡해지기 시작했다. 인증 흐름에 따라 사용자 인스턴스가 서로 달랐기 때문에 사용자 스텁(stub)을 바꿔주는 등 단위 테스트를 작성도 함께 복잡해졌다. 조금 더 자세히 정리하면 다음과 같은 작업들을 했다.

• 웹 애플리케이션, iOS 애플리케이션 OAuth2 인증 프로세스를 통합하는 작업
• 서비스 자체 인증 프로세스를 구축
• OAuth2 인증 후 자체 인증 프로세스로 연결하는 작업

언뜻 보기엔 어려울 것 같지만, 스프링 시큐리티 프레임워크 구조를 이해하고 있다면 크게 어렵지 않은 일이다. 그래서인지 요즘 스프링 시큐리티 관련된 작업은 나에게 맡겨진다. 맡은 프로젝트 뿐만 아니라 다른 팀이나 블로그를 통해 스프링 시큐리티 관련된 문의가 종종 들어온다. 나는 작년부터 커리어 발전을 위해 스프링 시큐리티에 관련된 책을 쓰고 있다. 책을 쓰기 위해 프레임워크를 샅샅히 훑어본 경험 덕분인지 비즈니스 요구 사항에 맞는 구현과 검증이 비교적 쉬웠다. 내가 만드는 좋은 결과들은 더 다양한 요구 조건들이나 비즈니스 케이스에 대한 문의가 들어오게 만들었고 나의 경험치는 더욱 풍성해지고 있다.

굉장한 선순환이다. 난 평가가 좋아지는 것이 일종의 커리어 발전이라고 생각한다. 처음 집필을 결심했을 땐 책이 나올 때 쯤 나의 커리어가 크게 한번 도약할 것이라고 생각했다. 이번 프로젝트 회고 글을 쓰다보니 커리어 발전을 위한 나의 노력과 지식들이 나도 모르는 사이 나의 평가를 슬며시 올려주고 있다는 생각이 문득 들었다. 나에 대한 평가가 지금도 계속 높아지는 중이라면 책이 나올 때 쯤 나의 커리어 도약은 생각보다 크지 않다고 느낄 것 같다.

ChatGPT

나는 여태 프로젝트에서 능동적으로 ChatGPT를 사용해 본 적이 없다. 보통 함께 페어링하는 엔지니어가 ChatGPT에게 질문하면 옆에서 답변을 살펴본 것이 전부다. 크게 필요성을 못 느꼈다. 그도 그럴게 나는 스프링(spring) 프레임워크에 대한 숙련도가 높은 편이기 때문에 딱히 찾아보지 않더라도 웬만한 기능은 개발이 가능했다. 프로젝트에서 발생한 문제에 대한 내 진단은 ChatGPT의 답변보다 정확했다. 컨텍스트를 알고 있고 문제가 발생한 지점과 상호 작용하는 컴포넌트들에 대한 정보를 알고 있기 때문이겠지만, 스프링 프레임워크에 관한 문제 해결은 항상 ChatGPT와 함께하는 다른 개발자들보다 빨랐던 것 같다. 든든한 레퍼런스인 내 블로그의 글들도 한 몫 해준 것 같다.

이번 프로젝트에서 ChatGPT의 엄청난 효용성을 경험했다. 한번은 시간 계산을 위한 비즈니스 로직을 구현하고 있었다. 함께 페어링 중인 엔지니어가 “이런 건 머리 비우고 ChatGPT에게 물어보면 빠릅니다.”라면서 구현 코드와 테스트 코드 작성을 요구했다. 10초도 안 되는 사이 코드들이 작성됐다. 코드를 리뷰하고, 복사 후 적절한 클래스에 붙여 넣었다.

또 한번은 미리 학습된 객체 모델을 사용해 달리는 사람의 스켈레톤(skeleton)을 추출하는 서비스 구현이 필요했다. 나는 파이썬(python) 프로젝트 경험이 없기 때문에 간단한 예제 코드들과 적절한 라이브러리를 찾아볼 생각이었다. 나와 다르게 페어링 중인 엔지니어가 ChatGPT에게 스켈레톤 추출 코드를 요청했다. ChatGPT 완벽하게 동작하는 코드를 10초도 안 되는 사이에 만들어줬다. 내가 하는 일이라곤 각 코드 라인이 무슨 일을 하는지, 어떤 라이브러리를 사용했는지 살펴보는 일 뿐이었다. 오늘 하루라면 충분히 끝낼 수 있을 것이라 예상한 일이었지만, 오전 중으로 끝냈다.

정말 대단했다. ChatGPT는 완벽히 동작하는 결과를 순식간에 내놓았다. 정말 조만간 인공지능이 개발자를 대체할 날이 오겠구나 생각하니 섬뜩했다. 쉬지 않고 계속 학습하는 이 대단한 인공지능에 대체되지 않을 개발자가 될 수 있을까? 아직 내가 ChatGPT보다 나은 것들이 무엇일까 곰곰히 생각해봤다.

• 문제가 발생했을 때 인공지능은 구체적인 컨텍스트를 모르기 때문에 범용적인 답들을 내준다.
  • 대답 중 정답이 있을 수도 있고 없을 수도 있다.
  • 프로젝트 코드와 사용하는 프레임워크의 이해도가 높다면 내가 문제에 대한 진단을 더 정확히 내릴 수 있다.
• ChatGPT는 부분적인 컴포넌트 개발에 대한 코드를 즉시 내놓지만, 그 코드를 사용할지 아닐지 결정하는 것은 개발자가 한다.
  • 문제가 발생할 수도 있는 코드를 동작한다는 이유로 그대로 사용하는 것은 좋지 않다.
  • ChatGPT에게 전달하지 않은 컨텍스트로 인해 문제가 발생할 확률도 있기 때문에 테스트와 검증이 필요하다.
• 비즈니스 변화에 유연하고 확장이 쉬운 구조를 만들기 위해 시스템 구조는 개발자가 결정 한다.
  • 현실 세계는 변화 무쌍하기 때문에 프로젝트에 관련된 모든 컨텍스트를 인공지능이 알더라도 전체 시스템을 구축하는 것을 기대하긴 어려울 것 같다.
  • 비선형적인 사고가 가능한 사람들의 경험과 인사이트가 필요하다.
• ChatGPT보다 이해하기 쉬운 설명이 가능하다.
  • 다소 어려운 이야기라도 내가 충분히 이해한 내용이라면 그림이나 구체적인 예시와 경험을 바탕으로 함께 일하는 사람들에게 이해하기 쉬운 설명을 할 수 있다.

내 생각에 소프트웨어 개발을 100% 인공지능에게 맡기는 미래는 조금 멀리 있는 것 같지만, 어찌 됐든 ChatGPT는 정말 대단하다. 잘 활용할 수 있도록 자주 사용해 봐야겠다. 짧은 시간 더 많은 것들을 배울 수 있는 훌륭한 도구임에는 틀림 없다.

Lean XP Developer

우리 팀은 비즈니스 측면에서 린 스타트업(lean startup), 개발 측면에선 XP(extreme programming) 방법론을 따른다. 랩스의 이 플랙티스를 매니저님은 린 XP(lean XP)라고 부르기도 한다. 우리는 린 XP 방법론을 실천하기 위해 밸런스 팀(balanced team)으로 일한다. 최고의 프로덕트를 만들기 위해 PM, 디자이너, 개발자들이 한 팀으로 일한다. 내 프로젝트 경험을 바탕으로 이보다 효율적인 조직 구조는 없었던 것 같다.

밸런스 팀은 효율적인 조직 구조이지만, 이번 프로젝트에선 밸런스 팀이기 때문에 이야기가 길어진 경우가 종종 있었다. 누구의 말도 틀리지 않았기 때문에 논의가 더 길어진 것 같다. 특정 기능을 개발할 때 PM, 디자이너의 결정이 개발자들과의 의견과 충돌했다. 그럴 때마다 PM, 디자이너의 결정에 이견이 있는 개발자들은 린 스타트업 정신에 대해 이야기를 했다.

• 빠르게 만들어 검증하자
• 불필요한 빌드는 피하자

맞다. 빠르게 만들어 검증해봐야 하기 때문에 불필요한 빌드는 최대한 피하는 것이 좋다. 그런데 어디까지 불필요한 빌드일까? 한번은 디자이너가 값을 변경할 때 화면 아래에서 올라오는 휠 피커(wheel picker)를 요구했다. 린 스타트업 정신을 이야기 한 개발자는 이 기능이 불필한 빌드라는 이유로 기본으로 제공하는 컴포넌트를 사용하자는 쉬운 방법을 제안했다. 나는 이 의견에 반대했다. 린 스타트업 정신은 지킬 수 있겠지만, 최고의 프로덕트를 만들기 위해 UX 관점을 고려한 디자이너의 결정을 무시하는 것은 좋지 않다고 생각했다. 간단한 컴포넌트이기 때문에 테스트 코드 없이 만드는데 30분도 걸리지 않았다. 이 정도마저 불필요한 빌드로 취급한다면 퀄리티 높은 프로덕트는 어떻게 만들 수 있을까.

또 한번은 달리기 영상으로부터 사람의 스켈레톤 정보를 추출하는 기능을 개발하기로 결정했다. 불필요한 빌드를 줄이기 위해 SwiftUI 프레임워크에서 제공하는 API를 사용하자는 의견이 있었지만, 나는 다음과 같은 이유로 이를 따르지 않았다.

• SwiftUI 프레임워크 API를 사용하면 클라이언트 기기에 너무 종속적이다.
  • 버전 문제, 안드로이드 개발 등의 이슈가 추후에 있을 것이다.
• 현재 잘 동작하고 비즈니스 로직에 많은 변화를 줄 것이다.
  • 비디오 촬영에 대한 비즈니스 로직이 크게 변경된다.
  • 원본 비디오와 스켈레톤이 적용된 비디오를 따로 처리하는 것에 대한 복잡도가 높아진다.
  • 스켈레톤 정보를 저장하기 위한 새로운 API 엔드-포인트 개발이 필요하다.
  • 스켈레톤 기능이 필요 없다고 판단되어 정리할 때 기능을 없애는 일이 어렵다.

나는 향후 로드맵을 위해선 서버 사이드에서 비디오 프로세싱이 이뤄져야 한다고 생각했다.

• 파이썬으로 비디오 프로세싱 서비스를 구현한다.
• AWS S3 버킷에 발생한 이벤트를 감지하면 비동기로 비디오 프로세싱 서비스를 트리거한다.
• 비디오 프로세싱이 완료되면 해당 결과를 새로운 데이터베이스 테이블에 저장한다.

개발 진행은 내가 맡았기 때문에 내 생각대로 서버 사이드에서 비디오 프로세싱이 이뤄지도록 시스템을 구현했다. 이렇게 설계하면 AWS 클라우드에 대한 의존성은 커지고 시스템 복잡도가 높아지지만, 기존 비즈니스에 전혀 영향을 주지 않고 비디오 프로세싱을 처리할 수 있다. 기존 비즈니스 로직과 전혀 결합(coupling)이 없는 상태로 구축하기 때문에 비즈니스 로직에 복잡도가 늘어날 필요가 전혀 없었다.

새로운 기술 스택을 늘리고 싶지 않은 마음은 이해하지만, 이런 트레이드-오프(trade-off)라면 나는 비즈니스 로직의 결합도와 복잡성을 늘리지 않는 방향이 꾸준히 빠른 빌드 속도를 지향하는 XP 정신에 맞다고 생각했다. 빠르게 만들고 불필요한 빌드를 줄이자는 린 스타트업 정신의 불필요한 것이 어디까지인지 사람마다 다르겠지만, 더 나은 시스템 구조나 사용자 경험을 위한 필요한 작업이였다고 생각한다. 난 고품질의 프로덕트를 만들 수 있다면 어떤 귀찮은 일도 기쁘게 받아드릴 수 있다.