QA에서 컴포넌트 아키텍트로

AI 코드 에디터가 이제 대부분의 보일러플레이트 코드를 처리합니다. 이는 위험한 신화를 만들어냅니다. 팀들은 AI가 코드를 작성하고 컴파일만 되면 제대로 작동한다고 생각합니다.

이러한 사고방식은 작은 기능을 구현할 때는 유효합니다. 하지만 디자인 시스템에서는 통하지 않습니다.

디자인 시스템 컴포넌트는 일회성 기능이 아닙니다. 그것은 인프라입니다. 버튼 하나나 입력 필드 하나가 수백 개의 제품에서 수백만 명의 사용자에게 제공됩니다.

진정한 강점은 코드를 얼마나 빨리 작성하느냐가 아니라, 실패를 얼마나 잘 예측하느냐에 있습니다.

빌더(builder)의 사고방식에서 브레이커(breaker)의 사고방식으로 전환해야 합니다. TDD, BDD, 그리고 스펙 기반 개발(Spec-Driven Development)을 통한 테스트를 받아들여야 합니다.

대부분의 팀은 '해피 패스(Happy Path)'를 기준으로 구축합니다. 피그마(Figma) 파일을 맞추는 데서 그치고 맙니다. 하지만 컴포넌트는 현실 세계의 혼란 속에서도 살아남아야 합니다.

강력한 팀은 코드를 작성하기 전에 까다로운 질문을 던집니다:

  • 디자이너: 텍스트 문자열이 400자라면 어떻게 될까요? UI가 깨지나요?
  • 엔지니어: 사용자가 초당 10번씩 토글을 클릭하면 어떻게 될까요? 상태(state)가 손상되나요?
  • 접근성: 키보드만으로 이 드롭다운을 사용할 때 스크린 리더는 어떻게 작동하나요?

AI 도구는 코드는 잘 짜지만 가정을 하는 데는 서툽니다. 그 결과 취약한 컴포넌트를 만들어냅니다.

작업물을 보호하려면 다음 워크플로우를 사용하세요:

  1. 스펙 정의 (Tokens, Accessibility, API).
  2. 경계를 설정하기 위해 테스트와 스토리(stories)를 먼저 작성합니다.
  3. 그 경계 안에서 코드를 생성하도록 AI를 활용합니다.

TDD는 프로세스를 뒤집습니다. 나중에 버그를 수정하는 대신, 미리 경계를 정의합니다. 그러면 AI가 해당 테스트를 통과하도록 코드를 작성합니다.

행동 주도 개발(BDD)도 도움이 됩니다. 인간의 언어를 사용하여 디자인과 엔지니어링 사이의 간극을 메워줍니다.

예시:

  • 사용자의 연결 속도가 느린 상황에서 (Given),
  • 제출 버튼을 클릭하면 (When),
  • 버튼은 로딩 상태를 표시하고 클릭을 비활성화해야 합니다 (Then).

일부 리더들은 테스트가 속도를 늦출까 봐 두려워합니다. 이는 실수입니다.

초기 코딩은 컴포넌트 비용의 5%에 불과합니다. 나머지 95%는 유지보수와 버그 수정에 들어갑니다.

테스트 중심의 사고방식은 다음과 같은 이점을 제공합니다:

  • 리팩터링 시 회귀(regression) 발생 감소.
  • 다른 개발자들을 위한 셀프 서비스 시스템 구축.
  • 조직적 신뢰 확보.

AI 시대에 코딩 속도는 흔한 능력입니다. 시스템 사고(Systems thinking)는 희귀합니다.

더 빨리 만들려고 하지 마세요. 망가질 것에 대비해 만드세요.

여러분의 팀은 속도와 회복 탄력성(resilience) 사이의 균형을 어떻게 맞추고 있나요? 댓글로 알려주세요.

QA에서 컴포넌트 아키텍트로: 코드를 망가뜨리는 것이 세계적인 디자인 시스템을 만드는 비결인 이유

저는 수년간 QA(Quality Assurance) 엔지니어로 일하며 무언가를 망가뜨리는 데 인생을 바쳤습니다. 제 업무는 소프트웨어가 어떻게 작동하는지 확인하는 것이 아니라, 어떻게 하면 그것을 작동하지 않게 만들 수 있는지를 찾는 것이었습니다.

하지만 컴포넌트 아키텍트로 직무를 전환하면서, 저는 이 "파괴적인" 사고방식이 단순히 버그를 찾는 것을 넘어, 세계적인 수준의 디자인 시스템을 구축하는 데 핵심적인 역할을 한다는 것을 깨달았습니다.

QA의 사고방식을 아키텍처로 가져오기

많은 개발자가 컴포넌트를 만들 때 "이것이 어떻게 작동할 것인가?"를 먼저 생각합니다. 하지만 QA 출신의 아키텍트는 "이것이 어떻게 망가질 것인가?"를 먼저 생각합니다.

디자인 시스템은 단순히 예쁜 버튼과 색상 팔레트의 집합이 아닙니다. 그것은 수천 명의 개발자가 사용하는 견고한 인프라입니다. 인프라가 견고하려면, 설계 단계부터 실패를 염두에 두어야 합니다.

1. 엣지 케이스(Edge Cases)의 힘

QA 엔지니어는 항상 극단적인 상황을 찾습니다.

  • "사용자가 입력창에 10,000자 이상의 텍스트를 넣으면 어떻게 될까?"
  • "네트워크 속도가 극도로 느려지면 로딩 상태는 어떻게 보일까?"
  • "사용자가 버튼을 미친 듯이 연타하면 어떻게 될까?"

컴포넌트 아키텍트로서 저는 이러한 질문을 컴포넌트 설계 단계로 가져옵니다. 단순히 '해피 패스(Happy Path)'를 구현하는 것이 아니라, 시스템이 예상치 못한 입력을 받았을 때 어떻게 우아하게(gracefully) 대응할지를 설계합니다.

2. 접근성(Accessibility)은 '기능'이 아니라 '제약 조건'이다

QA 관점에서 접근성은 단순히 체크리스트가 아닙니다. 그것은 시스템이 반드시 지켜야 하는 엄격한 규칙입니다. 컴포넌트를 설계할 때, "이 컴포넌트가 스크린 리더 사용자에게 어떻게 들릴까?" 또는 "키보드만으로 모든 기능을 사용할 수 있는가?"를 초기 설계 단계에서 고려해야 합니다.

코드를 작성한 후에 접근성을 수정하는 것은 임시방편에 불과합니다. 처음부터 접근성을 고려하여 설계하면, 접근성은 더 이상 '추가 작업'이 아니라 컴포넌트의 본질적인 일부가 됩니다.

3. 파괴적 테스트(Destructive Testing)를 통한 견고함 확보

세계적인 디자인 시스템은 단순히 코드가 잘 돌아가서가 아니라, 코드가 깨졌을 때 어떻게 반응하는지를 정의했기 때문에 강력합니다.

  • 속성(Props)의 한계 테스트: 잘못된 데이터 타입이나 예상치 못한 값이 전달될 때 컴포넌트가 전체 애플리케이션을 중단시키는지, 아니면 적절한 경고를 내보내는지 확인합니다.
  • 시각적 회귀 테스트(Visual Regression Testing): 작은 스타일 변경이 의도치 않게 다른 컴포넌트에 영향을 미치는지 확인합니다.

결론: 파괴는 창조의 시작이다

컴포넌트 아키텍처는 단순히 코드를 쌓아 올리는 과정이 아닙니다. 그것은 발생 가능한 모든 실패 시나리오를 예측하고, 그에 대비한 방어 기제를 구축하는 과정입니다.

여러분의 코드를 작성한 후, 스스로에게 물어보세요. "내가 이 코드를 망가뜨리려 한다면, 어디를 공격해야 할까?"

그 질문에 답할 수 있을 때, 여러분은 단순한 개발자를 넘어 진정한 아키텍트로 거듭나게 될 것입니다.