lowerCamelCase와 PascalCase 차이
lowerCamelCase는 첫 단어를 소문자로 시작하고 이후 단어 첫 글자를 대문자로 만듭니다. JavaScript 변수나 Java 필드에 흔히 사용됩니다.
PascalCase는 첫 단어부터 대문자로 시작하며 클래스·타입명에 자주 사용됩니다.
- GRN_FEE_AMT → grnFeeAmt
- GRN_FEE_AMT → GrnFeeAmt
여러 DB 컬럼 일괄 변환
컬럼명을 한 줄에 하나씩 입력하면 원래 줄 순서를 유지한 결과를 만들 수 있습니다. 변환 후 입력 줄 수와 결과 줄 수가 같은지 확인하세요.
공백·하이픈·언더스코어는 단어 구분자로 처리되므로 SELL-CLIENT-CD와 SELL_CLIENT_CD가 같은 형태로 정리될 수 있습니다.
약어와 숫자 확인
API_URL이나 IP_ADDR 같은 약어는 일반 단어처럼 ApiUrl, IpAddr로 변환될 수 있습니다. 프로젝트 규칙이 apiURL처럼 약어 대문자를 유지한다면 결과를 직접 수정해야 합니다.
숫자가 포함된 이름과 이미 카멜케이스인 입력도 예상한 결과인지 샘플 몇 개로 먼저 확인하세요.
코드에 반영하기 전 점검
DTO 필드명만 바꾸고 getter·setter·매퍼·JSON 키를 함께 바꾸지 않으면 연동 오류가 발생할 수 있습니다. 전체 프로젝트 검색으로 참조 위치를 확인하세요.
자동 변환 결과는 복사 편의를 위한 초안이며 팀 코딩규칙과 외부 API 계약이 최종 기준입니다.
변환 규칙을 프로젝트 전체에서 먼저 합의
snake_case를 lowerCamelCase로 바꾸는 기본원칙만으로는 약어, 숫자, 이미 대문자가 섞인 이름을 일관되게 처리하기 어렵습니다. user_id를 userId로 할지 userID로 할지, api_url을 apiUrl로 할지 apiURL로 할지 팀 규칙을 정하세요. DB 열, API JSON, TypeScript 모델과 화면 폼에서 서로 다른 규칙을 쓴다면 변환 경계를 문서화해야 합니다.
PascalCase는 클래스·타입명에, lowerCamelCase는 변수·속성에 주로 쓰지만 기존 코드베이스의 관례를 우선합니다. 자동 변환 전에 예약어, 선행 숫자, 연속 밑줄, 하이픈, 공백과 비ASCII 문자가 있는 샘플을 모으세요. 단순한 문자열 치환으로 생성한 이름이 해당 언어의 유효한 식별자인지도 확인해야 합니다.
- 약어 ID·URL·API 표기 규칙 합의
- DB·API·코드 계층의 변환 경계 문서화
- 예약어·숫자·특수문자 샘플 준비
여러 컬럼을 변환하고 결과를 검토하는 순서
컬럼 목록을 한 줄에 하나씩 붙여 넣고 원하는 lowerCamelCase 또는 PascalCase 형식을 선택합니다. 빈 줄과 앞뒤 공백을 제거한 뒤 결과 행 수가 원본 행 수와 같은지 확인하세요. created_at, updated_at처럼 비슷한 열이 변환 후에도 각각 createdAt, updatedAt으로 구분되는지 보고 중복이 생기지 않았는지 검사합니다.
USER_ID, user__id, user-id처럼 원본 표기가 다르면 모두 userId가 되어 충돌할 수 있습니다. 중복 결과가 있으면 자동 적용하지 말고 어느 원본을 유지할지 결정합니다. SQL 별칭, ORM 매핑, 직렬화 설정으로 이름을 바꾸는 경우 데이터베이스 실제 열명을 변경하는 작업과 구분하세요.
- 입력·출력 행 수 대조
- 변환 뒤 중복 식별자 검사
- 표시용 매핑과 실제 DB 스키마 변경 구분
코드 생성에 넣을 때 생기는 흔한 오류
숫자로 시작하는 2fa_enabled는 단순 변환 뒤 2faEnabled가 되어 JavaScript 식별자로 직접 쓸 수 없습니다. class, default, delete 같은 예약어도 언어와 위치에 따라 문제를 만들 수 있습니다. 필요한 경우 안전한 접두어를 붙이거나 문자열 키로 사용하고 코드생성 규칙에 예외를 추가하세요.
대소문자를 구분하지 않는 파일시스템이나 데이터베이스에서는 userID와 userId처럼 사람 눈에는 비슷한 결과가 충돌할 수 있습니다. 공개 API의 필드명을 바꾸면 기존 클라이언트가 깨질 수 있으므로 내부 모델만 변환하고 입출력에서 매핑하거나 버전 변경절차를 따라야 합니다. 마이그레이션에는 롤백과 호환기간을 계획합니다.
- 선행 숫자와 예약어 확인
- 대소문자 차이만 있는 이름의 충돌 검사
- 공개 API 변경은 호환성과 버전 계획 필요
적용 전 테스트와 유지관리 체크리스트
대표 열 5개만 보지 말고 전체 스키마에서 변환결과를 생성해 고유성, 유효한 식별자, 약어 일관성을 자동 검사하세요. null 값이나 데이터 내용은 이름 변환과 무관하지만 ORM 모델을 다시 만들 때 타입·nullable·기본값이 유지되는지 별도로 비교해야 합니다. 생성된 코드는 포맷터와 타입검사를 통과시킨 뒤 작은 범위부터 적용합니다.
변환 규칙을 README나 코드생성 설정에 남기고 새 컬럼 리뷰 때 같은 기준을 사용하세요. 사람이 매번 결과를 손으로 고치면 다음 자동생성에서 다시 달라질 수 있으므로 예외 사전과 테스트를 도구 설정에 포함하는 편이 좋습니다. 바로툴 결과는 초안이므로 운영 DB나 공개 API에 적용하기 전 백업과 코드리뷰가 필요합니다.
- 전체 스키마의 고유성·식별자 유효성 검사
- ORM 타입·nullable·기본값 보존 확인
- 규칙·예외·회귀테스트를 함께 관리