Dorong Dorong 💻😴

이터러블(Iterable)

정의

• 반복 가능한 객체
• `for...of`, `스프레드(...)`, `디스트럭처링 할당` 등에 사용 가능
• 이터러블은 Symbol.iterator 메서드를 가지고 있으며, 이 메서드가 이터레이터를 반환

예시

const arr = [1, 2, 3]; // 배열 (대표적인 이터러블) 
const str = "hi"; // 문자열도 이터러블 
const set = new Set([1, 2, 3]); // Set도 이터러블 
for (const val of arr) console.log(val); // 1, 2, 3

이터레이터(Iterator)

정의

• 이터러블을 실제로 순회하는 메커니즘
• `next()` 메서드를 가지고 있으며 `{ done: Boolean, value: any }`와 같은 형태의 객체를 반환
• `done: true` 가 될 때까지 순회

예시

const arr = [1, 2, 3]; 
const iterator = arr[Symbol.iterator](); 
console.log(iterator.next()); // { done: false, value: 1 } 
console.log(iterator.next()); // { done: false, value: 2 }
console.log(iterator.next()); // { done: false, value: 3 } 
console.log(iterator.next()); // { done: true, value: undefined }

이터러블  ↔  배열 메서드 활용

• 이터러블을 배열로 변환해 `map`, `filter` 같은 고차 함수 활용 가능

const set = new Set([1, 2, 3]); 
const doubled = [...set].map(x => x * 2); // [2, 4, 6]

장점

1. 일관된 반복 프로토콜 제공
   → for...of, 스프레드, 디스트럭처링 등 어디서든 활용 가능
2. 데이터 구조 확장 가능
   → 트리, 그래프 같은 사용자 정의 구조에서도 원하는 순서(DFS, BFS 등)로 순회 정의 가능
3. 유연성
   → 어떤 순서, 어떤 조건으로든 반복 동작을 직접 정의할 수 있음

한계

1. 성능 문제
   • 대규모 데이터 순회 시 next() 호출 비용 누적
   • 복잡한 구조일수록 접근 비용 증가
2. 메모리 사용량 증가
   • 이터레이터는 상태(state)를 저장해야 하므로 동시에 여러 개를 쓰면 메모리 부담

// 상태 누적 예시
  [Symbol.iterator]() {
    this.current = this.from;
    return this;
  },

  3. 배열 메서드 직접 사용 불가

• 이터러블 자체는 map, filter 같은 배열 메서드를 바로 쓸 수 없음 → 배열로 변환해야 함

개선방안

1. 제너레이터(Generator)
   • 이터러블+이터레이터를 쉽게 구현할 수 있는 문법
   • yield를 사용해 필요할 때만 값을 생성 (lazy evaluation)
   • 메모리 효율적
   • `function* numbers() { yield 1; yield 2; yield 3; } for (const n of numbers()) { console.log(n); // 1, 2, 3 }`
2. Lazy Evaluation 기법 활용
   • 전체 데이터를 한꺼번에 메모리에 올리지 않고, 필요한 순간에만 계산/반환

유사 배열(array-like object)

정의

• 인덱스와 `length` 프로퍼티를 가지고 있어 배열처럼 보이지만
• `next()` 메서드를 가지고 있으며 `{ done: Boolean, value: any }`와 같은 형태의 객체를 반환
• 반드시 `Symbol.iterator`가 구현되어 있는 것은 아님 → for...of, 스프레드 불가

예시

const obj = {0: 'a', 1: 'b', length: 2};
console.log(obj[0]); // 'a'
console.log(obj.length); // 2
// [...obj] // Error! 유사 배열은 스프레드 불가

변환 방법

Array.from(obj); // ['a','b']

주의할 점

• 유사 배열과 이터러블을 헷갈리기 쉬움
• 유사 배열이면서 이터러블인 경우도 존재
  • 예: arguments, NodeList, HTMLCollection 등
  • 이런 경우는 for...of나 스프레드(...) 사용 가능

관계 정리

이터러블(Iterable)
 └─ Symbol.iterator 메서드 존재
      └─ 반환 → 이터레이터(Iterator)
             └─ next() 호출로 실제 반복 수행
                 └─ { value, done } 반환

유사 배열(array-like)
 └─ 인덱스 + length만 존재
      └─ Symbol.iterator 없으면 for...of/스프레드 불가
      └─ Symbol.iterator 있으면 이터러블처럼 사용 가능 (예: arguments, NodeList)

정리

• 이터러블(Iterable): “반복할 수 있는 객체” (배열, 문자열, Set, Map 등)
• 이터레이터(Iterator): “실제로 반복을 수행하는 도구” (next() 사용)
• 관계: 이터러블은 Symbol.iterator를 구현해야 하고, 이 메서드가 이터레이터를 반환
• 강점: 일관된 반복 프로토콜, 다양한 구조 지원, 유연한 순회
• 한계: 대규모 데이터에서 성능·메모리 부담
• 보완: 제너레이터와 lazy evaluation 활용

TOAST UI - 터치와 클릭 이벤트 글에서 생긴 의문을 정리하기 위한 글입니다.

터치 이벤트를 달았는데 왜 클릭 이벤트까지 발생하나요?

• 터치가 발생하면 내가 별도로 클릭 이벤트를 달지 않았어도 click 이벤트가 중복으로 발생해 버립니다.
  왜 이런 동작이 일어나는 걸까요?
• 웹은 오랫동안 마우스 클릭 중심으로 설계되고 발전했습니다.
• 지금까지 많은 사이트가 오직 click 이벤트만 듣고 동작하도록 만들어져 있기 때문에, 모바일 브라우저는 호환성 유지를 위해 터치 시 자동으로 click 이벤트도 함께 발생시키도록 설계돼 있습니다. 그렇기에 터치스크린 환경에서도 기존 마우스 중심 사이트들이 별도 수정 없이 동작할 수 있습니다.

터치 이벤트 후 click 이벤트가 발생하는 게 왜 편의일까요?

• 여러 자료에서 이걸 편의라고 하던데 표현이 너무 포괄적으로 느껴져서 그런지 처음에는 이해가 되지 않았습니다. 아래는 제가 찾아본 후 이해한 내용입니다!
  
  • 브라우저는 이 사이트가 터치/클릭 둘 다 지원하는지, 어떤 식으로 의도했는지 알 방법이 없습니다.
  • 그래서 일괄적으로, 터치가 발생하면 반드시 click 이벤트도 같이 발생하도록 만들었습니다.
  • 브라우저는 저희가 만든 사이트만 띄우는 것이 아니라 아주 많은 사이트를 동시에 지원해야 합니다. 모바일 도입 초기엔 대부분 오직 클릭 이벤트만 사용했기 때문에, 터치 이벤트만 발생시 클릭 이벤트가 발생하지 않으면 옛날 사이트들이 모바일에서 먹통이 될 수 있다고 판단했습니다. 그래서 터치 시 자동으로 클릭 이벤트도 발생시키도록 설계되었고 기존 클릭 기반 사이트와의 호환성도 보장합니다.

React 등에서도 클릭 이벤트가 발생할까요?

• 많이 사용하는 React 기준으로 여기서도 브라우저의 이벤트 위임 메커니즘을 그대로 따랐습니다. 브라우저의 네이티브 이벤트 시스템을 그대로 활용했기 때문에 동일한 동작이 발생해요.
• 브라우저가 터치 이벤트 후 자동으로 마우스와 클릭 이벤트를 생성하는건 React 이전 단계에서 일어납니다.
• React는 브라우저의 네이티브 이벤트를 감싸는 SyntheticEvent를 사용하고 있어요. 하지만 브라우저의 기본 이벤트 동작은 변경하지 않습니다.
• 그리고 이벤트 위임을 사용하지만 이건 이벤트 처리 방식을 최적화하는 것이지 브라우저의 기본 이벤트 동작을 바꾸는게 아닙니다.
• 관련 토론인 GitHub 이슈 #9809를 정리해보면,
  
  • preventDefault() 무효화: React의 합성 이벤트에서 e.prevnetDefault()가 클릭 이벤트 방지에 실패
  • 네이티브 DOM API는 작동: addEventListener로 직접 등록하면 preventDefault()가 정상 동작
  • 브라우저별 차이: Chrome, Firefox, Safari에서 각각 다르게 동작 (추가 확인이 필요)
• 위의 내용은 관련 이슈를 직접 보고 상세 내용과 이유를 확인해 보는걸 추천드립니다!
• 이슈에서 제시된 해결책들도 짧게라도 정리해 보겟습니다.

// 방법 1: 네이티브 DOM API 사용
componentDidMount() {
  this.elem.addEventListener('touchstart', e => {
    e.preventDefault(); // 이건 작동함
  });
}

// 방법 2: 플래그 사용
handleTouchStart(event) {
  this.hasBeenTouchedRecently = true;
  setTimeout(() => { 
    this.hasBeenTouchedRecently = false; 
  }, 500);
}

handleMouseDown(event) {
  if(this.hasBeenTouchedRecently) {
    return; // 터치 후 마우스 이벤트 무시
  }
}

 <meta name="viewport" content="width=device-width">

3년간 회사에서 개발하면서 나름 경험을 쌓았다고 생각했습니다.

하지만 돌이켜보면 그 경험은 이미 잘 짜인 구조 안에서 주어진 역할만 수행했었던 것 같습니다.
디자이너와의 협업 방식은 이미 정형화되어 있었고, 디자인 시스템도 구축돼 있어서 시안을 받아 구현하는 데만 집중하면 됐거든요.

이번 프로젝트에서는 모든 걸 처음부터 만들어야 했습니다. 그 과정에서 많은 것들을 새롭게 깨달았고, 특히 디자이너와의 협업에서 여러 배움들이 있었습니다!

갑자기 보이기 시작한 것들

상태에 대한 정의

디자이너님과 같은 "상태"라는 단어를 사용하고 있었는데, 실제로는 다른 방식을 생각하고 있었습니다.

• 디자이너님이 말하는 상태는 주로 시각적인 변화 — 예를 들어 색깔, 테두리, 아이콘 같은 UI 요소들이었고,
• 제가 말하는 상태는 데이터의 상태 혹은 사용자 상호작용 — 예를 들어 에러 여부, 입력 완료 여부, 네트워크 상태 같은 것이었습니다.

아래에서 자세히 설명 하겠지만 개발했던 공통 컴포넌트로 설명해 보겠습니다.

처음 시안에는 "기본, 포커스, 에러, 비활성화" 정도만 정의돼 있었어요.

그런데 실제로 구현에 들어가면서 고민이 커졌습니다.

• 이메일 필드에서 오류 메시지가 뜨는 동시에 포커스가 가면 어떻게 보여줘야 하지?
• 네트워크 오류가 발생하면서 동시에 로딩 상태도 유지해야 한다면?
• 비밀번호 필드에서는 호버 + 에러 상태가 함께 오면 어떤 UI여야 할까?

이렇게 상태 조합 많아지기 시작했어요.
회사는 이미 디자인 시스템과 공통 컴포넌트가 잘 정리돼 있어서, 이런 조합들은 신경 쓸 필요가 거의 없었거든요.
하지만 이번 프로젝트에서는 모든 것을 직접 기획하고, 디자이너님과 논의하고, 구현까지 해보면서 "상태"를 정의한다는게 얼마나 복잡하고 섬세한 일인지 체감할 수 있었습니다.

가장 처음 시작된 소통이 시작된 화면

프로젝트 초기 디자이너님이 로그인 화면 시안을 가져왔습니다. 깔끔하고 직관적인 디자인이었습니다. 하지만 구현을 시작하면서 자연스럽게 몇 가지 궁금한 점들이 생겼어요.

"로그인 실패했을 때는 어떻게 표시할까요?"

디자이너님도 "아, 그러게요. 에러 메시지가 필요하겠네요"라고 해주셨고 함께 고민해봤습니다.

예시 코드는 실제 구현 코드와 차이가 있습니다.

type LoginErrorType = 'INVALID_CREDENTIALS' | 'NETWORK_ERROR' | 'UNKNOWN_ERROR';

interface LoginError {
  type: LoginErrorType;
  message: string;
  field?: 'email' | 'password'; // 개발 환경에서만 사용
}

interface LoginState {
  status: 'idle' | 'loading' | 'success' | 'error';
  error: LoginError | null;
}

// 에러 메시지 상수 분리
const LOGIN_ERROR_MESSAGES = {
  INVALID_CREDENTIALS: '이메일 또는 비밀번호를 확인해주세요.',
  NETWORK_ERROR: '네트워크 오류가 발생했습니다. 다시 시도해주세요.',
  UNKNOWN_ERROR: '알 수 없는 오류가 발생했습니다.',
} as const;

// 개발 환경용 상세 메시지
const DEV_ERROR_MESSAGES = {
  INVALID_EMAIL: '앗! 등록되지 않은 이메일이거나 잘못 입력했어요.',
  INVALID_PASSWORD: '앗! 비밀번호가 틀렸어요. 다시 한 번 확인해주세요.',
} as const;

const useLogin = () => {
  const [state, setState] = useState<LoginState>({
    status: 'idle',
    error: null,
  });

  // 환경별 에러 메시지 처리
  const getErrorMessage = (type: LoginErrorType, field?: 'email' | 'password'): LoginError => {
    const isDevelopment = process.env.NODE_ENV === 'development';
    
    if (isDevelopment && field) {
      return {
        type,
        message: field === 'email' ? DEV_ERROR_MESSAGES.INVALID_EMAIL : DEV_ERROR_MESSAGES.INVALID_PASSWORD,
        field,
      };
    }

    return {
      type,
      message: LOGIN_ERROR_MESSAGES[type],
    };
  };

  const login = async (email: string, password: string) => {
    setState({ status: 'loading', error: null });
    
    try {
      const user = await authService.findUserByEmail(email);
      if (!user) {
        setState({
          status: 'error',
          error: getErrorMessage('INVALID_CREDENTIALS', 'email'),
        });
        return;
      }

      const isValidPassword = await authService.validatePassword(email, password);
      if (!isValidPassword) {
        setState({
          status: 'error',
          error: getErrorMessage('INVALID_CREDENTIALS', 'password'),
        });
        return;
      }

      await authService.setSession(user);
      setState({ status: 'success', error: null });
    } catch (error) {
      setState({
        status: 'error',
        error: getErrorMessage('NETWORK_ERROR'),
      });
    }
  };

  return {
    ...state,
    login,
    isLoading: state.status === 'loading',
    isSuccess: state.status === 'success',
    isError: state.status === 'error',
  };
};

디자이너님은 로그인 화면에서 어떤 방식으로 에러 메시지를 띄울지 고민하고 계셨어요.

흔히 볼 수 있는 "아이디나 비밀번호가 일치하지 않습니다"와 같은 모호한 에러 메시지 대신, "이메일이 잘못되었습니다" 또는 "비밀번호가 잘못되었습니다"처럼 구체적으로 알려주는 게 사용자 입장에서 더 친절한 UX가 아닐까에 대해 논의하였습니다.

그리고 왜 많은 웹사이트들이 로그인 실패 시 "Incorrect username or password" 처럼 모호한 메시지를 사용하는 걸까요? 라는 의문에 도달했어요.

관련해서 찾아본 결과, tarunbatra.com 블로그에서는 보안적인 이유를 강조했습니다.

로그인 오류 메시지를 구체적으로 제공할 경우, 악의적인 사용자가 해당 정보를 기반으로 유효한 계정을 추측하거나 반복적으로 조합을 시도할 수 있게 됩니다.

예를 들어, "비밀번호가 잘못되었습니다"라는 메시지를 보면 해당 사용자명은 유효하다는 것을 알 수 있기 때문에, 공격자에게 단서를 주는 셈이죠. 반면 "아이디 또는 비밀번호가 일치하지 않습니다"처럼 모호하게 처리하면 공격자는 어떤 부분이 잘못되었는지 알 수 없기 때문에 보안상 더 안전해집니다.

하지만 그 당시엔 내부 베타 테스트를 진행할 예정이었던 동물병원 관계자분들의 요청이 있었고, 테스트 편의를 위해 로그인 오류 시 어떤 필드가 잘못되었는지를 분리해서 보여주는 UX를 채택하기로 했습니다.

사용자가 어떤 필드에서 문제가 생겼는지 직관적으로 알 수 있도록, 해당 필드 바로 아래에 에러 메시지를 띄우는 방식으로 협의했고, 실제 사용자 테스트에서도 긍정적인 반응을 얻을 수 있었습니다!

편하게 쓰던 공통 컴포넌트

알리니에서는 다양한 입력 필드가 필요했습니다.

이메일, 비밀번호, 전화번호, 사료명, 브랜드명 등등...

처음에 디자이너님이 만든 텍스트필드는 기본적이 모습이었는데, 구현하면서 함께 다양한 상태를 고민하게 되었습니다.

"비밀번호 필드에서 입력 내용을 확인할 수 있는 눈 모양 아이콘이 있으면 좋겠어요."

"맞아요! 그리고 사료 등록할 때 필수 입력 항목은 라벨에 별표(*)를 표시하면 어떨까요?"

이처럼 하나하나 기능이 추가되며 필요한 상태의 수는 기하급수적으로 늘어났습니다..

예를들어 아래처럼요. (실제 알리니 구현과 차이가 있습니다)

• 기본 상태 4가지
• 호버 상태 추가 → 4 × 2 = 8
• 읽기 전용(read-only) 고려 → 8 × 2 = 16
• 필수/선택 표시 → 16 × 2 = 총 32가지 상태 조합

그런데 가장 어려웠던 건 이런 조합들이 단순히 추가만 되는 게 아니라, 서로 충돌하거나 우선순위가 있다는 점이었어요.
예를 들어 disabled와 readOnly는 동시에 true일 수 있지만, 실제로는 disabled가 readOnly를 무시해요.

즉, disabled > readOnly인 거죠.
이런 상호 의존성과 우선순위는 처음엔 전혀 인지하지 못했고, 디자이너님과 함께 한참을 논의하면서 규칙을 정리해나갔습니다:

• disabled > readOnly (우선순위 존재)
• error와 success는 상호 배타적
• focus는 사용자의 직접적인 상호작용으로만 발생

예시 코드는 실제 구현 코드와 차이가 있습니다.

import { forwardRef, useState, useCallback, useMemo, useId } from 'react';

// 디자인 토큰
const INPUT_COLORS = {
  default: {
    border: '#e1e5e9',
    background: '#ffffff',
  },
  focused: {
    border: '#00b896', // 브랜드 컬러
    background: '#ffffff',
  },
  error: {
    border: '#ff6b6b', // 빨간색
    background: '#ffffff',
  },
  disabled: {
    border: '#f4f4f4',
    background: '#f9f9f9',
  },
} as const;

// 상태 우선순위 명시적 정의
const INPUT_STATE_PRIORITY = {
  disabled: 4,
  error: 3,
  focused: 2,
  default: 1,
} as const;

type InputState = keyof typeof INPUT_STATE_PRIORITY;

// Props 타입 분리
interface BaseInputProps {
  label?: string;
  required?: boolean;
  error?: string;
  disabled?: boolean;
  placeholder?: string;
  value?: string;
  onChange?: (value: string) => void;
  onFocus?: () => void;
  onBlur?: () => void;
}

interface TextInputProps extends BaseInputProps {
  type?: 'text' | 'email' | 'tel';
  leftIcon?: React.ReactNode;
  rightButton?: React.ReactNode;
}

interface PasswordInputProps extends BaseInputProps {
  type: 'password';
  showPasswordToggle?: boolean;
}

type InputProps = TextInputProps | PasswordInputProps;

// 상태 계산 로직 분리
const getInputState = (isFocused: boolean, error?: string, disabled?: boolean): InputState => {
  if (disabled) return 'disabled';
  if (error) return 'error';
  if (isFocused) return 'focused';
  return 'default';
};

const getInputStyles = (state: InputState) => {
  const colors = INPUT_COLORS[state];
  return {
    borderColor: colors.border,
    backgroundColor: colors.background,
  };
};

const TextInput = forwardRef<HTMLInputElement, InputProps>(({
  label,
  required = false,
  type = 'text',
  error,
  disabled = false,
  placeholder,
  value,
  onChange,
  onFocus,
  onBlur,
  ...props
}, ref) => {
  const [showPassword, setShowPassword] = useState(false);
  const [isFocused, setIsFocused] = useState(false);
  
  const inputId = useId();
  const errorId = useId();
  
  const inputType = useMemo(() => {
    if (type === 'password' && !showPassword) return 'password';
    return type === 'password' ? 'text' : type;
  }, [type, showPassword]);

  const currentState = useMemo(() => 
    getInputState(isFocused, error, disabled), 
    [isFocused, error, disabled]
  );

  const inputStyles = useMemo(() => 
    getInputStyles(currentState), 
    [currentState]
  );

  // 이벤트 핸들러들
  const handleFocus = useCallback(() => {
    if (disabled) return;
    setIsFocused(true);
    onFocus?.();
  }, [disabled, onFocus]);

  const handleBlur = useCallback(() => {
    setIsFocused(false);
    onBlur?.();
  }, [onBlur]);

  const togglePasswordVisibility = useCallback(() => {
    setShowPassword(prev => !prev);
  }, []);

  const handleChange = useCallback((e: React.ChangeEvent<HTMLInputElement>) => {
    onChange?.(e.target.value);
  }, [onChange]);

  // 패스워드 토글 버튼
  const passwordToggleButton = type === 'password' && (
    <button
      type="button"
      onClick={togglePasswordVisibility}
      className="password-toggle"
      aria-label={showPassword ? '비밀번호 숨기기' : '비밀번호 보기'}
      disabled={disabled}
      style={{ 
        opacity: disabled ? 0.5 : 1,
        cursor: disabled ? 'not-allowed' : 'pointer'
      }}
    >
      {showPassword ? '🙈' : '👁️'}
    </button>
  );

  return (
    <div className="text-input">
      {label && (
        <label htmlFor={inputId} className="input-label">
          {label}
          {required && (
            <span className="required-indicator" aria-label="필수" style={{ color: '#ff6b6b' }}>
              *
            </span>
          )}
        </label>
      )}
      
      <div 
        className={`input-container input-container--${currentState}`}
        style={{
          ...inputStyles,
          border: `1px solid ${inputStyles.borderColor}`,
          borderRadius: '8px',
          padding: '12px',
          display: 'flex',
          alignItems: 'center',
          gap: '8px',
        }}
      >
        {'leftIcon' in props && props.leftIcon && (
          <span className="input-icon" aria-hidden="true">
            {props.leftIcon}
          </span>
        )}
        
        <input
          ref={ref}
          id={inputId}
          type={inputType}
          disabled={disabled}
          placeholder={placeholder}
          value={value}
          onChange={handleChange}
          onFocus={handleFocus}
          onBlur={handleBlur}
          aria-describedby={error ? errorId : undefined}
          aria-invalid={!!error}
          style={{
            flex: 1,
            border: 'none',
            outline: 'none',
            backgroundColor: 'transparent',
            fontSize: '16px',
          }}
        />
        
        {passwordToggleButton}
        
        {'rightButton' in props && props.rightButton}
      </div>
      
      {error && (
        <span 
          id={errorId} 
          className="error-message" 
          role="alert"
          style={{
            color: '#ff6b6b',
            fontSize: '14px',
            marginTop: '4px',
            display: 'block',
          }}
        >
          {error}
        </span>
      )}
    </div>
  );
});

TextInput.displayName = 'TextInput';

// 사용 예시
const LoginForm = () => {
  const [formData, setFormData] = useState({
    email: '',
    password: '',
  });
  
  const { login, isLoading, error, status } = useLogin();
  
  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    await login(formData.email, formData.password);
  };
  
  return (
    <form onSubmit={handleSubmit} style={{ maxWidth: '400px', margin: '0 auto' }}>
      <TextInput
        label="이메일"
        type="email"
        required
        value={formData.email}
        onChange={(email) => setFormData(prev => ({ ...prev, email }))}
        error={error?.field === 'email' ? error.message : undefined}
        placeholder="이메일을 입력해주세요"
        disabled={isLoading}
      />
      
      <div style={{ marginTop: '16px' }}>
        <TextInput
          label="비밀번호"
          type="password"
          required
          value={formData.password}
          onChange={(password) => setFormData(prev => ({ ...prev, password }))}
          error={error?.field === 'password' ? error.message : undefined}
          placeholder="비밀번호를 입력해주세요"
          disabled={isLoading}
          showPasswordToggle
        />
      </div>
      
      <button 
        type="submit" 
        disabled={isLoading}
        style={{
          width: '100%',
          padding: '12px',
          marginTop: '24px',
          backgroundColor: isLoading ? '#cccccc' : '#00b896',
          color: 'white',
          border: 'none',
          borderRadius: '8px',
          fontSize: '16px',
          cursor: isLoading ? 'not-allowed' : 'pointer',
        }}
      >
        {isLoading ? '로그인 중...' : '로그인'}
      </button>
      
      {error && !error.field && (
        <div style={{ 
          marginTop: '16px', 
          padding: '12px', 
          backgroundColor: '#ffebee',
          borderRadius: '8px',
          color: '#ff6b6b'
        }}>
          {error.message}
        </div>
      )}
    </form>
  );
};

"비활성화 상태일 때는 회색으로, 에러 상태일 때는 빨간색 테두리로 평범하게 가고 포커스 상태에서는 브랜드 컬러인 초록색으로 강조하면 좋겠어요"라는 의견으로 일치했습니다.

알레르기 기록의 시각화

알리니의 핵심 기능 중 하나가 반려견의 알레르기 반응을 기록하고 분석하는 건데, 이 부분에서 정말 많은 대화가 오갔습니다.

현재 구현된 상태와는 다르지만 아래와같은 고민을 했었어요.

"알레르기 정도를 어떻게 표현하면 좋을까요?"

"색깔로 구분하면 어떨까요? 빨간색은 심함, 주황색은 보통, 초록색은 낮음?"

"색약이 있는 사용자도 고려해야 할 것 같아요. 색깔과 함께 텍스트나 아이콘도 넣으면 어떨까요?"

예시 코드는 실제 구현 코드와 차이가 있습니다.

// 디자인 토큰 정의
const COLORS = {
  success: {
    main: '#00b896',
    background: '#e6f8f5',
    light: '#b3f0e6',
  },
  warning: {
    main: '#ffa726',
    background: '#fff3e0',
    light: '#ffd699',
  },
  error: {
    main: '#ff6b6b',
    background: '#ffebee',
    light: '#ffb3b3',
  },
  gray: {
    600: '#666666',
    500: '#999999',
    100: '#f5f5f5',
  },
} as const;

// 알레르기 레벨 타입
type AllergyLevel = 'low' | 'medium' | 'high';

// 알레르기 데이터 인터페이스
interface AllergyData {
  level: AllergyLevel;
  percentage: number;
  ingredients: string[];
  timestamp?: Date;
}

// 아이콘 컴포넌트들 (실제로는 아이콘 라이브러리 사용)
const CheckCircleIcon = ({ size = 16 }: { size?: number }) => (
  <svg width={size} height={size} viewBox="0 0 24 24" fill="currentColor">
    <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm-2 15l-5-5 1.41-1.41L10 14.17l7.59-7.59L19 8l-9 9z"/>
  </svg>
);

const AlertCircleIcon = ({ size = 16 }: { size?: number }) => (
  <svg width={size} height={size} viewBox="0 0 24 24" fill="currentColor">
    <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm1 15h-2v-2h2v2zm0-4h-2V7h2v6z"/>
  </svg>
);

const XCircleIcon = ({ size = 16 }: { size?: number }) => (
  <svg width={size} height={size} viewBox="0 0 24 24" fill="currentColor">
    <path d="M12 2C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2zm5 11H7v-2h10v2z"/>
  </svg>
);

// 알레르기 레벨 설정
interface AllergyLevelConfig {
  color: string;
  backgroundColor: string;
  text: string;
  icon: React.ReactNode;
  severity: number;
  description: string; // 접근성을 위한 설명 추가
}

const ALLERGY_LEVEL_CONFIG: Record<AllergyLevel, AllergyLevelConfig> = {
  low: {
    color: COLORS.success.main,
    backgroundColor: COLORS.success.background,
    text: '알레르기 낮음',
    icon: <CheckCircleIcon size={16} />,
    severity: 1,
    description: '알레르기 반응이 낮은 수준입니다',
  },
  medium: {
    color: COLORS.warning.main,
    backgroundColor: COLORS.warning.background,
    text: '알레르기 보통',
    icon: <AlertCircleIcon size={16} />,
    severity: 2,
    description: '알레르기 반응이 보통 수준입니다',
  },
  high: {
    color: COLORS.error.main,
    backgroundColor: COLORS.error.background,
    text: '알레르기 높음',
    icon: <XCircleIcon size={16} />,
    severity: 3,
    description: '알레르기 반응이 높은 수준입니다',
  },
} as const;

// Props 인터페이스
interface AllergyItemProps {
  level: AllergyLevel;
  percentage: number;
  ingredients?: string[];
  showDetails?: boolean;
  className?: string;
  onToggleDetails?: () => void;
}

// 퍼센티지 포맷팅 함수
const formatPercentage = (value: number): string => {
  return `${Math.round(value)}%`;
};

// 메인 컴포넌트
export const AllergyItem: React.FC<AllergyItemProps> = ({
  level,
  percentage,
  ingredients = [],
  showDetails = false,
  className = '',
  onToggleDetails,
}) => {
  const config = ALLERGY_LEVEL_CONFIG[level];
  
  return (
    <div
      className={`allergy-item ${className}`}
      style={{
        backgroundColor: config.backgroundColor,
        border: `1px solid ${config.color}20`, // 20% 투명도
        borderRadius: '12px',
        padding: '16px',
        marginBottom: '8px',
        transition: 'all 0.2s ease', // 부드러운 전환
      }}
      role="article"
      aria-label={`${config.description}, ${formatPercentage(percentage)}`}
    >
      <div 
        className="allergy-header"
        style={{
          display: 'flex',
          alignItems: 'center',
          justifyContent: 'space-between',
          marginBottom: showDetails && ingredients.length > 0 ? '12px' : '0',
        }}
      >
        <div style={{ display: 'flex', alignItems: 'center', gap: '8px' }}>
          <span 
            className="allergy-icon" 
            style={{ color: config.color, display: 'flex', alignItems: 'center' }}
            aria-hidden="true"
          >
            {config.icon}
          </span>
          <span 
            className="allergy-text" 
            style={{ 
              color: config.color, 
              fontWeight: '600',
              fontSize: '14px',
            }}
          >
            {config.text}
          </span>
        </div>
        
        <div style={{ display: 'flex', alignItems: 'center', gap: '8px' }}>
          <span 
            className="allergy-percentage"
            style={{
              fontWeight: '700',
              fontSize: '16px',
              color: config.color,
            }}
          >
            {formatPercentage(percentage)}
          </span>
          
          {ingredients.length > 0 && (
            <button
              onClick={onToggleDetails}
              style={{
                background: 'none',
                border: 'none',
                cursor: 'pointer',
                padding: '4px',
                borderRadius: '4px',
                color: config.color,
                fontSize: '12px',
                transition: 'background-color 0.2s ease',
              }}
              aria-expanded={showDetails}
              aria-label={showDetails ? '세부사항 숨기기' : '세부사항 보기'}
            >
              {showDetails ? '▲' : '▼'}
            </button>
          )}
        </div>
      </div>

      {/* 색약 사용자를 위한 추가 시각적 요소 */}
      <div 
        style={{
          width: '100%',
          height: '4px',
          backgroundColor: `${config.color}30`,
          borderRadius: '2px',
          marginBottom: showDetails && ingredients.length > 0 ? '12px' : '0',
          overflow: 'hidden',
        }}
      >
        <div
          style={{
            width: `${percentage}%`,
            height: '100%',
            backgroundColor: config.color,
            borderRadius: '2px',
            transition: 'width 0.3s ease',
          }}
          role="progressbar"
          aria-valuenow={percentage}
          aria-valuemin={0}
          aria-valuemax={100}
          aria-label={`알레르기 수준 ${formatPercentage(percentage)}`}
        />
      </div>

      {showDetails && ingredients.length > 0 && (
        <div className="allergy-details">
          <h4 
            style={{ 
              margin: '0 0 8px 0',
              fontSize: '12px',
              color: COLORS.gray[600],
              fontWeight: '600',
            }}
          >
            관련 성분 ({ingredients.length}개)
          </h4>
          <ul 
            className="allergy-ingredients"
            style={{
              margin: 0,
              padding: 0,
              listStyle: 'none',
              display: 'flex',
              flexWrap: 'wrap',
              gap: '6px',
            }}
          >
            {ingredients.map((ingredient, index) => (
              <li 
                key={`${ingredient}-${index}`}
                className="allergy-ingredient"
                style={{
                  backgroundColor: `${config.color}15`,
                  color: config.color,
                  padding: '4px 8px',
                  borderRadius: '12px',
                  fontSize: '12px',
                  fontWeight: '500',
                  border: `1px solid ${config.color}30`,
                }}
              >
                {ingredient}
              </li>
            ))}
          </ul>
        </div>
      )}
    </div>
  );
};

// 알레르기 목록 컴포넌트
interface AllergyListProps {
  allergies: AllergyData[];
  title?: string;
}

export const AllergyList: React.FC<AllergyListProps> = ({ 
  allergies, 
  title = "알레르기 분석 결과" 
}) => {
  const [expandedItems, setExpandedItems] = React.useState<Set<number>>(new Set());

  const toggleDetails = (index: number) => {
    setExpandedItems(prev => {
      const newSet = new Set(prev);
      if (newSet.has(index)) {
        newSet.delete(index);
      } else {
        newSet.add(index);
      }
      return newSet;
    });
  };

  // 데이터 정렬 (심각도 순)
  const sortedAllergies = React.useMemo(() => {
    return [...allergies].sort((a, b) => {
      const configA = ALLERGY_LEVEL_CONFIG[a.level];
      const configB = ALLERGY_LEVEL_CONFIG[b.level];
      return configB.severity - configA.severity; // 심각한 것부터
    });
  }, [allergies]);

  if (allergies.length === 0) {
    return (
      <div style={{ 
        textAlign: 'center', 
        padding: '40px 20px',
        color: COLORS.gray[500],
      }}>
        알레르기 데이터가 없습니다.
      </div>
    );
  }

  return (
    <div className="allergy-list" style={{ maxWidth: '600px', margin: '0 auto' }}>
      <h3 style={{ 
        fontSize: '18px', 
        fontWeight: '700', 
        marginBottom: '16px',
        color: COLORS.gray[600],
      }}>
        {title}
      </h3>
      
      {sortedAllergies.map((allergy, index) => (
        <AllergyItem
          key={index}
          level={allergy.level}
          percentage={allergy.percentage}
          ingredients={allergy.ingredients}
          showDetails={expandedItems.has(index)}
          onToggleDetails={() => toggleDetails(index)}
        />
      ))}
    </div>
  );
};

// 사용 예시
export const AllergyExample = () => {
  const sampleData: AllergyData[] = [
    {
      level: 'high',
      percentage: 85,
      ingredients: ['닭고기', '쌀', '옥수수'],
    },
    {
      level: 'medium',
      percentage: 45,
      ingredients: ['연어', '고구마'],
    },
    {
      level: 'low',
      percentage: 15,
      ingredients: ['당근', '브로콜리', '사과'],
    },
  ];

  return <AllergyList allergies={sampleData} title="우리 강아지 알레르기 분석" />;
};

"월별 통계를 보여줄 때 그래프로 표현하면 더 직관적일 것 같아요"라는 디자이너님의 제안에 어느정도 화면이 변경되었습니다!

마치며

진행하며 고민한 디테일들은 회사에선 이미 디자인 시스템이나 공통 컴포넌트에 반영되어 있어서, 별다른 고민 없이 가져다 쓰기만 했던 것들이었어요.

이번 프로젝트에서는 그런 요소들을 직접 기획하고, 디자인에 녹여내고, 컴포넌트로 구현하는 과정을 하나하나 경험해보니, 겉으로만 알고 있었던 UI 구성 요소들이 얼마나 많은 의도와 고민 속에서 만들어졌는지를 새삼 느낄 수 있었어요.

무엇보다 그런 과정이 생각보다 꽤 재밌었습니다!

글 초반에 이야기했던 ‘상태’에 대한 정의를 스터디원들과 함께 고민하고 찾아보던 중, 아래의 블로그 글을 접하게 되었고 큰 도움을 받았습니다. 👉 The Sorry State of States - velog.io/@tap_kim

저희가 겪고 있던 고민과 같은 내용을 보며 정말 반가웠고,
덕분에 막연했던 문제들을 조금 더 빠르게 정리하고, 명확한 기준을 세울 수 있었습니다.

오늘은 별도 컨텍스트를 가진 새 창을 띄우는 개발을 하며 알게된 내용을 정리해보려 합니다.

왜 아직도 window.open이 필요한가?

시작전에 팝업과 모달의 본질적 차이부터 알아보겠습니다.

팝업창

• 브라우저가 완전히 분리된 새 창(또는 탭)으로 동작
• 브라우저의 팝업 차단 기능에 영향을 받고
• 부모 페이지와 별도의 브라우저 컨텍스트를 갖습니다.
• 창의 위치, 크기, 스크롤바 등 다양한 속성을 제어할 수 있습니다.
• 부모 창이 새로고침되거나 이동해도 팝업은 유지됩니다.
• 브라우저 팝업 차단 기능에 의해 사용자가 팝업을 못 볼 수 있으므로, 반드시 필요한 경우에만 사용하는게 좋습니다. 그 외에는 모달이 권장됩니다.

모달창

• 기존 페이지 위에 오버레이 레이어로 구현
• 부모 페이지에 종속되어 있습니다.
• 브라우저의 팝업 차단 기능과 무관합니다.
• 부모 페이지가 이동 또는 새로고침되면 모달도 사라집니다.
• 별도의 브라우저 컨텍스트가 아니므로, 외부 도메인 페이지를 직접 포함할 수 없습니다. 이때 iframe을 생각하실 수 있는데 보안상 제약이 많아 불편합니다.

React에서는 상태(state)를 활용한 조건부 렌더링으로 팝업을 구현하거나, Toss의 오버레이 키트(Overlay Kit)같은 라이브러리를 사용하는 경우가 많습니다.

그런데도 여전히 window.open()이 편리하거나 필요한 상황이 있습니다.

1. 외부 도메인과의 연동: OAuth 인증, 결제 시스템 연동 등 다른 도메인의 페이지를 열어야 할 때
   
   • OAuth 인증이나 외부 결제 시스템 연동 시, 보안이나 사용자 인증 후 콜백등의 UX 적인 이유로 별도 창이 필요합니다.
   • 이때 window.open()을 사용하면 부모-자식 창 간 통신이나 창 닫힘 감지 등의 처리가 쉬워져요.
   • 모달로는 외부 도메인 페이지를 iframe으로 띄우는 것이 CORS, X-Frame-Options 또는 Content-Security-Policy 등의 보안 정책등의 이유로 불편합니다.
2. 프린트 기능: 특정 콘텐츠만 프린트하기 위한 별도 창이 필요할 때
   • 새 창에 해당 콘텐츠만 렌더링하고 window.print()를 호출하는 방식이 많이 사용됐습니다.
   • 모달이나 오버레이로는 전체 페이지의 일부만 깔끔하게 인쇄하는 인쇄 범위 제어가 어려워 기존 페이지 전체가 인쇄됩니다.
   • 따라서 새 창이 가장 간단하고 확실한 방법이라 생각합니다.
3. 멀티태스킹 UX: 사용자가 두 화면을 동시에 보며 작업해야 할 때
   • 두 개의 창을 동시에 화면에 띄워 상호 비교 작업하려면 창 분리가 필요합니다.
   • 모달은 항상 부모 창 위에 떠 있기 때문에 두 화면을 동시에 볼 수 없습니다.
   • 따라서 새 창을 띄우는 것이 유일한 방법입니다.
4. 레거시 시스템 통합: 기존 시스템과의 호환성을 위해 필요한 경우
   • 기존 시스템에서 팝업 창을 통한 데이터 교환이나 인증 등의 구조가 이미 window.open()에 맞춰져 있다면, 이를 모달로 대체하는 경우 호환성 이슈가 발생할 수 있습니다.
5. 별도 윈도우 기능: 부모 창의 새로고침이나 이동에도 유지되어야 하는 독립적 기능
   • 모달이나 SPA 컴포넌트로는 구현이 불가능합니다.
   • 새로운 팝업창만이 완전히 별도의 브라우저 컨텍스트를 제공합니다.

이런 경우에는 window.open()을 사용해야 하는데, 안전하고 올바른 방법을 알아보겠습니다.

window.open('javascript:focus()', 'myPopup', 'width=800,height=600');

겉보기엔 잘 작동할 수 있지만, 이 방식은 보안상 문제가 있으며 공식적으로 권장되지 않는 방식입니다.

이번 글에선 그 이유에 대해 적어보려합니다! 또한 어떤 방식이 안전하고 표준에 부합하는지도 알아보겠습니다.

javascript:focus() 방식의 위험성

이 방식은 javascript: URL 스킴을 이용해 새 창을 열면서 focus() 함수를 실행하려는 의도입니다. 하지만 이런 방식은 보안상 취약합니다.

MDN 공식 문서에서는 다음과 같이 명확히 경고하고 있습니다.

"Use of javascript: URLs on the web is discouraged as it may lead to execution of arbitrary code, similar to the ramifications of using eval()."

또한, ESLint에서도 no-script-url 규칙을 통해 javascript: URL 스킴 사용을 금지하거나 경고하고 있습니다. 이는 코드가 외부 입력에 의해 조작되거나 악용될 수 있기 때문입니다.

요약하자면

• 보안상 위험 (임의 코드 실행 가능성)
• XSS(크로스 사이트 스크립팅) 공격의 벡터가 될 수 있음
• 최신 브라우저 및 린터 차단 대상
• 유지보수와 의도 파악이 어려움

표준적이고 안전한 방법: about:blank 또는 빈 문자열

팝업을 안전하게 열고 싶다면, 권장되는 방식은 다음과 같습니다.

const popup = window.open('about:blank', 'myPopup', 'width=800,height=600');
if (popup) {
  popup.location.href = '/your-target-page';
  popup.focus(); // 필요 시 포커스 이동
}

또는 아예 빈 문자열도 사용할 수 있습니다.

const popup = window.open('', 'myPopup', 'width=800,height=600');

이 방식은 다음과 같은 장점이 있습니다.

• 보안상 안전함
• 표준 웹 API 사용법을 준수
• 코드 의도가 명확함
• 공식 문서(MDN, W3C 등)에서도 권장하는 방식

javascript:focus()의 목적과 오해

많은 개발자들이 javascript:focus()를 초기 URL로 넣는 이유는 다음과 같습니다.

• 빈 창을 열 때 팝업이 차단되는 현상을 우회하려고
• 창을 연 직후 자동으로 포커스를 주려고

하지만 최신 브라우저는 다음과 같은 특성이 있습니다.

1. 사용자 클릭 이벤트 내부에서 window.open()을 호출하면 대부분 차단하지 않습니다
2. 포커스가 필요하다면 popup.focus()를 명시적으로 호출하는 것이 훨씬 더 명확하고 안전합니다
3. 일부 최신 브라우저에서는 보안 정책으로 인해 javascript: URL이 작동하지 않을 수 있습니다

즉, javascript:focus()는 과거에는 통했을지 몰라도, 현대 웹 보안 환경에서는 적절하지 않은 방식입니다.

URL 객체와 javascript: URL은 완전히 다릅니다

혹시 URL이라는 단어 때문에 다음과 같은 문법을 떠올리신 분도 계실 텐데요?!

const url = new URL(window.location.href);
const tag = url.searchParams.get('tag');

이건 URL 정보를 분석하고 조작하기 위한 객체로, 주소 파싱을 위해 아주 유용하게 쓰입니다. 예를 들어 쿼리 파라미터 추출, 경로 조작 등에 자주 사용됩니다.

반면 'javascript:...'는 브라우저에 자바스크립트를 직접 실행하라고 명령하는 스킴이기 때문에, 목적도 쓰임도 완전히 다릅니다.

항목설명 - 사용 용도

부모-자식 창 관계와 제어

window.open()으로 열린 팝업은 부모 페이지와 밀접한 관계를 가집니다. 이를 활용하거나 주의해야 할 점이 있습니다.

부모 페이지에서 자식 창 제어하기

팝업을 연 부모 페이지는 반환된 참조를 통해 자식 창을 완전히 제어할 수 있습니다.

const popup = window.open('about:blank', 'myPopup');
// 자식 창 내용 변경
popup.document.body.innerHTML = '<h1>부모가 변경한 내용</h1>';
// 자식 창 크기/위치 조정
popup.resizeTo(500, 300);
popup.moveTo(100, 100);
// 자식 창 종료
popup.close();

자식 창 종료 시나리오

여러 상황에서 자식 창이 자동으로 종료될 수 있습니다.

1. 부모 페이지 이동 또는 새로고침 시

   // 페이지 이동 전에 자식 창 닫기
   window.addEventListener('beforeunload', () => {
     if (popup && !popup.closed) {
       popup.close();
     }
   });

    

2. 다른 SPA 라우트로 이동 시
    

   // React Router 등의 라우트 변경 이벤트에 연결
   router.beforeEach((to, from, next) => {
     if (window.myPopup && !window.myPopup.closed) {
       window.myPopup.close();
     }
     next();
   });

자식 창이 부모 페이지 감지하기

자식 창에서는 부모 창의 존재와 상태를 확인할 수 있습니다.

// 자식 창에서 부모 창 확인 및 대응하기
if (window.opener && !window.opener.closed) {
  // 부모 창이 존재하고 열려있음
  console.log('부모 창 URL:', window.opener.location.href);
} else {
  // 부모 창이 닫혔거나 없음
  console.log('독립적으로 실행 중');
}

브라우저 호환성과 추가 고려사항

최신 브라우저들은 window.open()에 대해 점점 더 엄격한 정책을 적용하고 있습니다.

• Chrome, Safari: 사용자 제스처(클릭 등) 없이 window.open()을 호출하면 차단됩니다
• Firefox: 팝업 차단 설정에 따라 동작이 달라집니다
• 모바일 브라우저: 많은 모바일 브라우저에서 팝업 자체를 제한적으로 지원합니다

따라서 팝업 대신 모달이나 인라인 콘텐츠를 고려하는 것도 좋은 대안이 될 수 있습니다:

// 특별한 이유가 없다면 팝업 대신 모달을 고려해보세요
document.getElementById('openModal').addEventListener('click', () => {
  document.getElementById('myModal').style.display = 'block';
});

요약 및 결론

• 모던 프레임워크가 주류인 지금도 OAuth, 결제 연동, 프린트 기능 등을 위해 window.open()이 필요한 상황이 있습니다.
• javascript:focus() 방식은 보안상 위험하고, MDN 및 ESLint에서도 사용을 권장하지 않습니다.
• 팝업을 열 때는 about:blank나 빈 문자열을 사용하고, 그 이후에 popup.location.href와 popup.focus()를 사용하는 방식이 가장 표준적이고 안전합니다.
• 부모 페이지에서는 팝업 창을 완전히 제어할 수 있으며, 페이지 전환 시 팝업 창을 적절히 관리(종료)해야 합니다.
• React 같은 프레임워크에서는 useRef와 useEffect를 활용해 팝업의 생명주기를 컴포넌트와 연동할 수 있습니다.
• URL 객체와 javascript: URL은 개념이 완전히 다르므로 혼동하지 마세요.

특정 상황에서는 window.open이 여전히 적절한 선택일 수 있습니다. 이런 경우에도 더 안전한 방식으로 코딩해 보시는 건 어떨까요?!

궁금하신 점이 있다면 언제든지 댓글로 남겨주세요! 

프론트엔드 개발자로서 AI를 학습하고 활용하던 중 문득 궁금해졌습니다.

"AI/ML 엔지니어들은 자신들이 만든 복잡한 모델의 결과를 어떻게 확인하고 공유할까?" 그리고 "비개발자들은 어떻게 AI를 활용해 원하는 것을 만들어낼까?"

이 궁금증으로 '스파르타에서 주관하는 AI와 100인의 용사들 - 해커톤'에 참가해 봤어요.
프론트엔드 개발자로서 AI 생태계에 발을 담가보고 싶었습니다.

해커톤에서 만난 Streamlit

해커톤에 참가하면서 처음으로 Streamlit이라는 프레임워크를 접하게 되었습니다.

AI/ML 개발자들 사이에서는 꽤 유명한 도구더라구요?!

처음에는 'Django나 React, Next 같은 웹 프레임워크의 일종인가?' 하고 생각했지만, 실제로는 좀 다른 용도로 사용되고 있었습니다.

Streamlit은 파이썬 개발자, 특히 데이터나 ML 엔지니어가 복잡한 웹 개발 지식 없이도 데이터 기반 애플리케이션을 빠르게 제작할 수 있게 도와주는 프레임워크였습니다.

파이썬 코드만으로 웹 인터페이스를 구축할 수 있다니, 프론트엔드 개발자로서 상당히 흥미로운 개념이었어요.

문서 링크입니다!

AI 엔지니어와 비개발자의 활용법

해커톤에서 관찰한 바로는, AI/ML 엔지니어들이 Streamlit을 사용하는 주된 이유는 다음과 같았습니다.

1. 빠른 프로토타이핑: 복잡한 모델의 결과를 즉시 시각화하고 상호작용 가능한 형태로 만들 수 있습니다.
2. 협업 용이성: 비기술적 팀원들에게 모델의 동작을 직관적으로 설명할 수 있습니다.
3. 배포 용이성: 몇 번의 클릭만으로 웹에 공개할 수 있어 공유가 쉽습니다.

가장 놀라웠던 점은 비개발자들도 이 도구를 활용해 자신만의 AI 애플리케이션을 만들어내었다는 사실입니다..!!

마케터, 디자이너, 심지어 의사나 교사와 같은 전혀 다른 도메인의 전문가분들도 간단한 파이썬 코드를 배워 자신의 아이디어를 구현하셨습니다!!

내 경험! Streamlit으로 서비스 구축하기

저도 평소 사용하던 React, Vue 진영이 아닌 Streamlit을 사용해 간단히 아이디어 구현을 보기로 했습니다. 프론트엔드 개발자로서 HTML, CSS, JavaScript에 익숙한 저에게는 굉장히 재밌었어요!

기본적인 설정은 놀라울 정도로 간단했습니다. (설명을 위한 코드로 실제 Github에 게시한 코드와는 전혀 다릅니다!)

import streamlit as st
import pandas as pd
import custom_nlp_model  # 내 커스텀 모델

st.title("텍스트 감정 분석기")
user_input = st.text_area("분석할 텍스트를 입력하세요:")

if st.button("분석하기"):
    result = custom_nlp_model.analyze_sentiment(user_input)
    st.write(f"현재 상황 분석: {result['sentiment']}")
    st.bar_chart(result['confidence_scores'])

이 코드만으로 작동하는 웹 앱이 생성되었습니다! React 컴포넌트를 구성하고, CSS를 작성하고, 상태 관리를 설정하는 등의 작업 없이 말이죠. 자동 배포는 더더욱 쉬웠습니다!!

프론트엔드 개발자로써 느낀 불편한 점

그러나 프로젝트가 진행될수록, 프론트엔드 개발자로서의 본능이.. 조금씩.. 깨어났습니다. "이 버튼의 스타일을 바꾸고 싶은데...", "이 차트를 더 인터랙티브하게 만들 수 없을까?", "페이지 전환 애니메이션은 어떻게 추가하지?" 같은 생각들이 들기 시작했어요.

Streamlit은 기본적인 스타일링 옵션을 제공하지만, 프론트엔드 개발자가 기대하는 수준의 커스터마이징은 어려웠습니다. 결국 HTML과 CSS를 직접 삽입하기 시작했습니다. (애초에 목적이 이쁘게 꾸미는 프레임워크가 아닙니다!! Streamlit이 잘못된게 아니에요!!)

custom_html = """
<div class="result-card" style="border-radius: 10px; box-shadow: 0 4px 6px rgba(0,0,0,0.1); padding: 20px; margin: 20px 0;">
    <h3 style="color: #333; font-family: 'Segoe UI', sans-serif;">분석 결과</h3>
    <div class="sentiment-meter" style="background: linear-gradient(to right, #ff4b4b, #ffff4b, #4bff4b); height: 20px; border-radius: 10px;">
        <div class="marker" style="position: relative; left: {}%; transform: translateX(-50%); width: 10px; height: 30px; background-color: #333; border-radius: 5px;"></div>
    </div>
</div>
"""

st.markdown(custom_html.format(sentiment_score * 100), unsafe_allow_html=True)

이런 방식은 작동은 했지만,  익숙한 컴포넌트 기반 개발 방식과는 거리가 멀었습니다. 마치 오래된 웹사이트를 유지보수하는 느낌이었어요.

페이지네이션과 DOM 컨트롤

특히 고전했던 부분은 페이지네이션과 DOM 컨트롤이었습니다.

React나 Vue에서는 상태 관리와 컴포넌트 라이프사이클을 통해 쉽게 구현할 수 있는 기능들이 Streamlit에서는 상당히 번거로웠습니다.

(물론 제가 제대로 찾아보지 못한 것일 수도 있습니다!!)

예를 들어, 분석 결과를 페이지로 나누어 표시하려면 이런 식으로 접근해야 했습니다.

(배포한 코드와는 차이가 있습니다! - 페이지네이션 제거)

import streamlit as st
import pandas as pd

# 세션 상태를 사용한 페이지네이션
if 'page_number' not in st.session_state:
    st.session_state.page_number = 0
    
# 데이터 로드
data = pd.read_csv("large_results.csv")
items_per_page = 10
total_pages = len(data) // items_per_page + (1 if len(data) % items_per_page > 0 else 0)

# 현재 페이지 데이터 계산
start_idx = st.session_state.page_number * items_per_page
end_idx = min(start_idx + items_per_page, len(data))
current_page_data = data.iloc[start_idx:end_idx]

# 현재 페이지 데이터 표시
st.write(f"결과 {start_idx+1}–{end_idx} / 총 {len(data)}개")
st.table(current_page_data)

# 페이지네이션 컨트롤
col1, col2 = st.columns(2)
if col1.button("이전 페이지") and st.session_state.page_number > 0:
    st.session_state.page_number -= 1
    st.experimental_rerun()
    
if col2.button("다음 페이지") and st.session_state.page_number < total_pages - 1:
    st.session_state.page_number += 1
    st.experimental_rerun()

이 방식은 작동은 하지만, 페이지 전환 시 전체 앱이 새로고침되어 사용자 경험이 매끄럽지 않았습니다.

React에서 라이브러리를 사용하지 않더라도 useState와 조건부 렌더링으로 간단히 해결할 수 있는 문제가 훨씬 복잡해진 느낌이었죠.

웹과 AI의 접점

해커톤과 팀 프로젝트를 통해 느낀 점은, Streamlit이 '웹 개발'과 'AI/ML 개발' 사이의 간극을 메우기 위한 도구라고 생각합니다.

완벽한 프론트엔드 솔루션은 아니지만, AI/ML 엔지니어와 비개발자들이 자신의 아이디어를 빠르게 시각화하고 공유하는 데는 탁월한 도구였어요.

위에서도 언급했지만 저에게 가장 놀라웠던 점은 비개발자들도 Streamlit을 통해 자신의 아이디어를 AI 생태계 안에서 구현해볼 수 있다는 것입니다. 아이디어가 있지만 기술적 장벽 때문에 실현하지 못했던 사람들이, 이제는 간단한 파이썬 코드만으로도 자신의 아이디어를 프로토타입으로 만들어 초기 검증을 할 수 있게 된 것이죠.

이런 초기 검증 과정에서 가능성이 확인되면, 그 후에는 스스로 더 깊게 학습하거나 전문가를 찾아 협업함으로써 더 완성도 높은 서비스로 발전시킬 수 있게 됩니다. 진입 장벽이 낮아지면서 AI 기술을 활용하는 접근성이 크게 향상된 것입니다! 이는 마치 워드프레스나 아임웹등의 서비스가 웹 개발을 모르는 사람들에게 웹사이트 제작의 문을 열어준 것과 비슷한 변화라고 생각합니다.

Streamlit의 진짜 목적

이번 해커톤을 경험하며 생각한건, Streamlit을 프론트엔드, 웹 개발 도구의 관점에서 바라보는 것 자체가 잘못된 접근이라는 점입니다! Streamlit은 애초에 화려한 UI/UX나 복잡한 인터랙션을 위한 도구가 아닙니다.

사실, 스타일링이나 페이지네이션의 한계는 Streamlit의 '단점'이라기보다는 그냥 이 도구의 범위를 벗어난 기능입니다.

이건 마치 망치로 나사를 박으려고 하면서 망치가 나쁘다고 말하는 것과 비슷하다 생각해요.

Streamlit의 진짜 목적은 ML 엔지니어들이 자신이 만든 모델을 쉽고 빠르게 시각화하고 상호작용할 수 있게 하는 것이었습니다.

ML 엔지니어들에겐 완벽한 UI보다 모델의 성능과 결과를 확인하는 것이 훨씬 중요하니까요.

프론트엔드 개발자인 저로서는 처음에 이 점을 놓기가 힘들었습니다. 모든 것을 '좋은 UI/UX'의 관점에서만 바라봤거든요. 하지만 해커톤을 통해 AI/ML 엔지니어의 이야기나 다양한 사람들과 대화하면서, 그들에게 필요한게 화려한 애니메이션이나 완벽한 반응형 디자인이 아니라 '모델이 제대로 작동하는지 빠르게 확인하고 팀원들과 공유할 수 있는 방법'이라는 걸 깨달았습니다.

그래서 Streamlit은 ML 엔지니어들이 웹 개발 없이도 자신의 작업 결과를 확인하고 공유할 수 있게 만들어주는, 정확히 그 목적에 최적화된 도구입니다!!

FSD 아키텍처와 함께 생각해보기

Vue3에서 React.js로 프로젝트를 마이그레이션하면서 Feature-Sliced Design(FSD) 아키텍처를 도입하기로 결정했습니다. 그 과정에서 배럴 파일(barrel files)에 대한 고민이 생겼고, 최근 몇 년 사이에 이에 대한 관점이 많이 바뀌었다는 것을 발견했습니다.

배럴 파일이란?

배럴 파일은 여러 모듈을 하나의 파일(주로 index.js 또는 index.ts)에서 다시 내보내는 패턴입니다. 이 패턴은 코드 정리와 import 문을 단순화하는 데 도움이 됩니다.

배럴 파일 없이:

// 각 파일에서 개별적으로 가져오기 
import { Button } from "../components/Button"; 
import { TextField } from "../components/TextField"; 
import { Checkbox } from "../components/Checkbox";

배럴 파일 사용 시:

// 하나의 경로에서 모든 컴포넌트 가져오기 
import { Button, TextField, Checkbox } from "../components";

배럴 파일의 실제 구현

일반적인 배럴 파일 (components/index.ts):

// 와일드카드 내보내기 (권장하지 않음) 
export * from './Button'; 
export * from './TextField'; 
export * from './Checkbox'; 

// 또는 명시적 내보내기 (권장) 
export { Button } from './Button'; 
export { TextField } from './TextField'; 
export { Checkbox } from './Checkbox';

배럴 파일의 성능 문제

Marvin의 JavaScript 생태계 속도 개선: 배럴 파일 문제 글에서 지적한 바와 같이, 배럴 파일은 다음과 같은 성능 문제를 일으킬 수 있습니다:

1. 모듈 그래프 복잡성 증가: 배럴 파일이 증가할수록 모듈 간 의존성 그래프가 복잡해집니다.
2. 불필요한 모듈 로딩: 특히 와일드카드 내보내기(export * from)를 사용할 경우, 실제로 필요하지 않은 모듈까지 로드될 수 있습니다.

모듈 그래프 비교

배럴 파일 없이:

App.js
├── Button.js
├── TextField.js
└── Checkbox.js

배럴 파일 사용 시:

App.js
└── components/index.js
    ├── Button.js
    ├── TextField.js
    └── Checkbox.js

성능 테스트 결과 예시

모듈 수배럴 파일 없음배럴 파일 사용차이

참고: 이 수치는 예시용이며, 실제 프로젝트에서는 다양한 요인에 따라 달라질 수 있습니다.

FSD 아키텍처에서의 배럴 파일

Feature-Sliced Design(FSD)은 배럴 파일과 유사한 패턴을 의도적으로 활용합니다. 이는 단순히 코드 작성의 편의성을 위한 것이 아니라, 아키텍처의 구조와 목적을 반영한 결정입니다.

FSD는 애플리케이션을 기능 단위로 분할하고 계층화된 구조를 만드는 것을 목표로 합니다. 이 구조에서 각 레이어(layer)와 슬라이스(slice)는 명확한 책임과 역할을 가집니다. 배럴 파일과 유사한 패턴을 사용함으로써, FSD는 다음과 같은 이점을 얻습니다:

• 캡슐화: 각 모듈의 내부 구현을 숨기고 공개 API만을 노출합니다.
• 의존성 관리: 상위 레이어가 하위 레이어에만 접근할 수 있도록 제한합니다.
• 재사용성: 공통 기능을 쉽게 공유하고 재사용할 수 있게 합니다.
• 유지보수성: 코드 구조를 일관되게 유지하여 개발자가 쉽게 이해하고 수정할 수 있게 합니다.

이러한 구조는 대규모 프로젝트에서 코드의 조직화와 관리를 용이하게 만들어, 장기적으로 프로젝트의 확장성과 유지보수성을 향상시킵니다. 따라서 FSD에서 배럴 파일과 유사한 패턴의 사용은 단순한 편의성을 넘어서, 아키텍처의 핵심 원칙을 실현하기 위한 전략적 선택이라고 볼 수 있습니다.

FSD에서의 배럴 파일 활용 - 실제 경험과 팁

FSD 아키텍처를 실제 프로젝트에 적용해본 경험에 따르면, 배럴 파일(Public API)의 주요 이점 중 하나는 유지보수성 향상입니다. 이에 대해 이너서클 재직자 과정에서 만난 동료 개발자분께서 다음과 같은 인사이트를 공유해주셨어요:

"FSD를 사용하면서 느낀 바로는, Public API를 활용하는 주된 이유 중 하나가 유지보수에 있습니다. 예를 들어, entities/user의 스키마가 일부 변경되더라도 features/loginUser, features/registerUser 등에서 import 구문을 변경할 필요가 없어집니다."

이는 FSD의 핵심 원칙 중 하나인 모듈 간 의존성 관리와 일치하는 관점입니다.

배럴 파일 생성 자동화

대규모 프로젝트에서 매번 수동으로 배럴 파일(Public API)을 관리하는 것은 번거로울 수 있습니다. 이를 해결하기 위한 실용적인 접근 방법으로, 배럴 파일을 자동으로 생성하는 스크립트를 활용할 수 있습니다.

예를 들어:

pnpm api features/loginUser

이러한 CLI 명령어를 통해 features/loginUser 내부의 모듈을 자동으로 분석하고, 명시적으로 내보내는 배럴 파일을 생성할 수 있습니다. 이때 _로 시작하는 파일이나 폴더는 내부용으로 간주하여 자동으로 제외할 수 있습니다.

명시적 내보내기의 중요성

앞서 언급했듯이, 와일드카드 내보내기(export * from './module')는 권장되지 않습니다. 대신, 명시적 내보내기를 사용하면 성능 이슈를 최소화하면서도 FSD의 이점을 충분히 활용할 수 있습니다.

// Good: 명시적 내보내기
export { LoginForm } from './LoginForm';
export { useAuth } from './useAuth';
export type { User } from './types';

이러한 접근 방식은 모듈의 공개 API를 명확히 정의하고, 불필요한 의존성을 방지하며, 코드의 가독성과 유지보수성을 향상시킵니다. 좀 더 상세한 예시를 들어볼게요.

스크립트에 대한 폴더 구조 예시:

project-root/
├── src/
│   ├── features/
│   │   └── loginUser/
│   │       ├── ui/
│   │       ├── model/
│   │       └── index.ts (자동 생성될 파일)
│   └── ... (다른 FSD 폴더들)
├── scripts/
│   └── generate-barrel.ts
├── package.json
└── tsconfig.json

scripts/generate-barrel.ts 파일의 내용:

import fs from 'fs';
import path from 'path';

function generateBarrel(directory: string) {
  const files = fs.readdirSync(directory);
  const exports: string[] = [];

  files.forEach(file => {
    if (file.startsWith('_') || file === 'index.ts') return;

    const filePath = path.join(directory, file);
    const stats = fs.statSync(filePath);

    if (stats.isDirectory()) {
      exports.push(`export * from './${file}';`);
    } else if (file.endsWith('.ts') || file.endsWith('.tsx')) {
      const name = path.parse(file).name;
      exports.push(`export { ${name} } from './${name}';`);
    }
  });

  const content = exports.join('\n') + '\n';
  fs.writeFileSync(path.join(directory, 'index.ts'), content);
}

const targetDir = process.argv[2];
if (!targetDir) {
  console.error('Please specify a target directory');
  process.exit(1);
}

const fullPath = path.resolve(process.cwd(), targetDir);
generateBarrel(fullPath);
console.log(`Barrel file generated for ${fullPath}`);

package.json에 스크립트 추가:

{
  "scripts": {
    "api": "ts-node scripts/generate-barrel.ts"
  }
}

이제 pnpm api features/loginUser 명령어를 실행하면, src/features/loginUser/index.ts 파일이 자동으로 생성되거나 업데이트됩니다! 아래부터는 좀 더 일반적인 예시를 들어볼게요.

FSD 기본 폴더 구조:

src/
├── app/        # 글로벌 설정, 스타일, 프로바이더
├── processes/  # 비즈니스 프로세스
├── pages/      # 페이지 컴포넌트
├── widgets/    # 복합 UI 블록
├── features/   # 사용자 인터랙션
├── entities/   # 비즈니스 엔티티
└── shared/     # 공유 유틸리티, UI 키트

FSD에서의 배럴 파일 사용 예시

features/auth/index.ts (적절한 배럴 파일 사용):

// 명시적 내보내기 - 공개 API를 명확히 정의
export { LoginForm } from './ui/LoginForm';
export { useAuth } from './model/useAuth';
export type { AuthUser } from './model/types';

균형 잡힌 접근법: 실제 구현 예시

1. 구조화된 배럴 파일 사용:

features/
├── auth/
│   ├── ui/
│   │   ├── LoginForm.tsx
│   │   └── RegisterForm.tsx
│   ├── model/
│   │   ├── useAuth.ts
│   │   └── types.ts
│   └── index.ts  # 아키텍처 경계에만 배럴 파일 사용
└── userProfile/
    ├── ui/
    ├── model/
    └── index.ts

2. 명시적 내보내기:

// features/auth/index.ts
// 명시적 내보내기로 공개 API 정의
export { LoginForm } from './ui/LoginForm';
export { RegisterForm } from './ui/RegisterForm';
export { useAuth } from './model/useAuth';
export type { User, AuthCredentials } from './model/types';

3. FSD 아키텍처 규칙에 따른 가져오기:

// 잘못된 방식: 레이어 우회
import { Button } from '@/shared/ui/Button';

// 올바른 방식: 아키텍처 경계 존중
import { Button } from '@/shared/ui';

4. 실제 React 컴포넌트 예시:

// features/auth/ui/LoginForm.tsx
import { useState } from 'react';
import { Button, TextField } from '@/shared/ui';
import { useAuth } from '../model/useAuth';
import type { AuthCredentials } from '../model/types';

export const LoginForm = () => {
  const [credentials, setCredentials] = useState({
    email: '',
    password: ''
  });
  const { login, isLoading } = useAuth();

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    login(credentials);
  };

  return (
    
      <TextField
        label="Email"
        value={credentials.email}
        onChange={(e) => setCredentials(prev => ({
          ...prev,
          email: e.target.value
        }))}
      />
      <TextField
        type="password"
        label="Password"
        value={credentials.password}
        onChange={(e) => setCredentials(prev => ({
          ...prev,
          password: e.target.value
        }))}
      />
      
        {isLoading ? 'Logging in...' : 'Login'}
      
    
  );
};

현대적 도구의 영향

최신 빌드 도구들은 배럴 파일의 성능 문제를 일부 완화할 수 있습니다:

번들러별 최적화 설정:

Vite 설정 예시:

// vite.config.js
export default {
  build: {
    target: 'esnext',
    minify: 'esbuild',
    rollupOptions: {
      output: {
        manualChunks(id) {
          // 최적화된 청크 설정
        }
      }
    }
  }
}

Webpack 설정 예시:

// webpack.config.js
module.exports = {
  optimization: {
    usedExports: true, // 트리 쉐이킹 활성화
    moduleIds: 'deterministic',
    splitChunks: {
      chunks: 'all',
    }
  }
}

성능 측정 - 실시간 프로젝트 모니터링

// build-analyzer.ts
import { performance } from 'perf_hooks';

export function measureBuildTime(taskName: string, task: () => void) {
  const startTime = performance.now();
  task();
  const endTime = performance.now();
  console.log(`Task "${taskName}" took ${endTime - startTime}ms`);
}

// 사용 예시
measureBuildTime('Module compilation', () => {
  // 빌드 로직
});

결론 - 프로젝트 규모별 권장 접근법

소규모 프로젝트 (10,000줄 이하)

src/
├── components/
│   └── index.ts  # 배럴 파일 사용 가능
├── hooks/
│   └── index.ts  # 배럴 파일 사용 가능
└── utils/
    └── index.ts  # 배럴 파일 사용 가능

중간 규모 프로젝트 (10,000~50,000줄)

src/
├── features/
│   ├── feature1/
│   │   └── index.ts  # 아키텍처 경계에만 배럴 파일
│   └── feature2/
│       └── index.ts
└── shared/
    ├── ui/
    │   └── index.ts  # 명시적 내보내기 사용
    └── lib/
        └── index.ts  # 명시적 내보내기 사용

대규모 프로젝트 (50,000줄 이상)

src/
├── app/
├── processes/
├── pages/
│   └── index.ts  # 엄격하게 제한된 배럴 파일
├── widgets/
│   └── index.ts  # 엄격하게 제한된 배럴 파일
├── features/
│   └── [각 기능별]/
│       └── index.ts  # 공개 API만 명시적 내보내기
├── entities/
│   └── [각 엔티티별]/
│       └── index.ts  # 공개 API만 명시적 내보내기
└── shared/
    └── [각 모듈별]/
        └── index.ts  # 성능 측정 후 결정

배럴 파일의 사용은 결국 개발 경험과 성능 사이의 균형을 찾는 문제라 생각합니다.

FSD 아키텍처를 도입한다면, 배럴 파일의 장단점을 인식하고 프로젝트의 규모와 팀의 필요에 맞게 적절히 조절하는 것이 중요할 것 같아요.

명확한 아키텍처 경계, 명시적인 내보내기, 그리고 현대적인 빌드 도구를 활용한다면, 배럴 파일의 이점을 취하면서도 성능 문제를 최소화할 수 있습니다!