서비스 / 03
프로덕트 엔지니어링 및 구축
실제로 코드를 짜는 단계입니다.
고객용 서비스든 내부 시스템이든, 2주마다 프로덕션에 내보내는 교차기능 스쿼드로 일합니다.
이 역량이 나머지 전부를 정직하게 만듭니다. 저희 엔지니어는 고객사 인력과 한 스쿼드로 일합니다. 프로덕트 매니저, 디자이너, 엔지니어, 그리고 보고서가 아니라 결과물이 프로덕션에 올라가는 것에 책임지는 딜리버리 리드.
세로로 얇게 자른 조각 단위로 일합니다. 첫 릴리스는 일부러 좁게 잡습니다. 여정 하나, 세그먼트 하나, 실제 사용자, 실제로 오가는 돈. 이렇게 하면 범위를 아직 싸게 바꿀 수 있을 때 연동 문제와 보안 심사, 운영 이슈가 먼저 튀어나옵니다.
테스트를 쓰고 문서를 남깁니다. 고객사 팀이 그대로 받아서 쓸 수 있는 상태로 코드를 넘깁니다. 모든 프로젝트에 1주 차부터 저희 PR을 리뷰할 고객사 엔지니어를 지정합니다.
핵심 역량
디지털 채널
규제와 접근성 기준, 실제 사용자들이 쓰는 단말 환경을 전제로 웹·모바일 서비스를 만듭니다.
코어 인접 시스템
아직 못 바꾸는 코어를 감싸는 오케스트레이션·API·이벤트 계층을 올려 조금씩 현대화합니다.
내부 플랫폼
언더라이터, 계획자, 상담사, 운영자가 쓰는 도구. 서비스 원가를 실제로 결정하는 건 이쪽입니다.
품질 엔지니어링
테스트 전략과 CI/CD, 성능·보안 테스트를 오픈 직전에 몰아서 하지 않고 파이프라인에 상시로 넣어둡니다.
함께 읽을 자료
운영 모델4 분
아키텍처는 결국 조직도를 닮는다
콘웨이가 1968년에 정리한 이야기입니다. 60년이 지났지만 목표 아키텍처를 그릴 때 '누가 누구와 대화할 수 있는가'를 먼저 확인하는 곳은 여전히 드뭅니다.
출처: Melvin E. Conway, How Do Committees Invent?, Datamation, 1968
레거시 현대화4 분
빅뱅 재구축의 대안에는 20년 전부터 이름이 있었습니다
파울러는 숙주를 감싸고 자라 그 자리를 대신하는 식물의 이름을 붙였습니다. 실패한 리플랫포밍 대부분은 이 패턴을 무시한 경우입니다.
출처: Martin Fowler, Strangler Fig Application, martinfowler.com, 2004, rewritten 2024
딜리버리 성과5 분
응답 23,000건을 견뎌낸 네 개의 지표
속도와 안정성은 맞바꾸는 관계가 아닙니다. 지난 20년간 소프트웨어 딜리버리에 관해 나온 이야기 중 가장 쓸모 있는 발견입니다.
출처: Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and DevOps, IT Revolution, 2018
다음 서비스
클라우드 및 플랫폼 현대화
보고서와 실제 출시 사이에서 멈춘 프로그램이 있으신가요?
어디서 막혔는지 알려주세요. 영업일 기준 이틀 안에 저희 생각을 정리해 회신드립니다. 저희가 맞는 파트너가 아니라면 그것도 그대로 말씀드립니다.