고졸 신입 개발자의 출근 2주차 회고

입사 2주차(1월 12일~16일)를 회고하며, 이번 주에 작업한 기능들과 그 과정에서 배운 점들을 정리해보려 합니다.

아직 많이 부족하지만, 하나하나 배워가는 과정이 의미 있었던 것 같습니다.

---

주요 작업 요약

이번 주는 크게 예약 관리 기능 개발과 중국 의료관광 사이트 UI/UX 개선 두 축으로 업무가 진행되었습니다.

기능 개발

• BMS 확정 대상 조회 및 일괄 확정 기능[1]
• 예약 관리 좌석/마감 선택 적용 기능[2]
• 감동여행 여행객 정보 입력 폼[3]
• 위챗 ID 복사 기능[4]

UI/UX 개선

• 중국어 폰트 설정 (Noto Sans SC)[5]
• 협력 병원 컴포넌트 Swiper 적용[6]
• 개인정보 동의 체크박스 추가[7]
• 반응형 디자인 개선 등 다수의 CSS 작업

---

기술적 깨달음

1. 체크박스 기반 일괄/선택 처리 로직의 복잡성

이번 주 가장 많은 고민을 한 부분은 체크박스를 활용한 선택 처리 로직이었습니다.

예약 관리 좌석/마감 선택 기능에서는 날짜별로 체크박스를 두고, 사용자가 전체 선택하면 '일괄적용', 일부만 선택하면 '선택적용'으로 동작하도록 구현했습니다. 단순해 보이는 기능이지만 실제로 구현하면서 여러 가지를 고려해야 했습니다:

// 전체 선택 여부에 따라 버튼 텍스트와 스타일이 달라져야 함
- 일괄적용: Contained/Primary 스타일
- 선택적용: Outlined/Secondary 스타일

 

처음에는 "그냥 버튼 두 개 만들면 되지 않나?"라고 생각했는데, 실제로는 하나의 버튼이 상태에 따라 동적으로 변하는 게 UX 측면에서 훨씬 직관적이더라고요. 사용자 입장에서는 버튼이 하나만 있어야 혼란스럽지 않고, 체크박스 선택 상태에 따라 버튼의 의미가 자연스럽게 바뀌는 것이 더 명확했습니다.

 

BMS 확정 대상 조회 기능에서도 비슷한 패턴이 적용되었습니다. 개별 확정 버튼과 일괄 확정 버튼이 있지만, 체크박스 선택 여부에 따라 동작이 달라지도록 설계했습니다. 이 과정에서 배운 점은:

• 상태 관리의 중요성: 어떤 항목이 선택되었는지, 전체 선택인지 부분 선택인지를 명확하게 관리해야 함
• 사용자 피드백: 선택 상태에 따라 버튼 스타일을 바꿔주면 사용자가 어떤 동작이 일어날지 예측할 수 있음
• 확인 절차의 필요성: 일괄 작업은 되돌리기 어려우므로 실행 전 확인 다이얼로그를 추가하는 게 안전함

2. 컴포넌트 분리의 기준

BMS 확정 기능을 구현하면서 SearchBmsConfirmButton.tsx라는 별도 컴포넌트로 분리했습니다. 처음에는 "이 정도는 그냥 부모 컴포넌트에 넣어도 되지 않을까?"라고 생각했는데, 실제로 분리하고 나니 여러 장점이 보였습니다:

• 가독성: 부모 컴포넌트의 코드가 훨씬 깔끔해짐
• 재사용성: 비슷한 기능이 다른 곳에 필요할 때 쉽게 가져다 쓸 수 있음
• 책임 분리: 확정 버튼에 관련된 로직과 상태가 한 곳에 모여 있어 유지보수가 편함

아직 명확한 기준은 없지만, "이 부분이 독립적인 역할을 하는가?", "코드가 50줄 이상 넘어가는가?" 정도를 기준으로 분리를 고려해봐야겠다는 생각이 들었습니다.

3. 조건부 렌더링과 비즈니스 로직

감동여행 여행객 정보 입력 폼을 구현할 때, "이용권 상품인 경우에만" 폼이 나타나야 했습니다. 이런 조건부 렌더링을 구현하면서 배운 점은:

• 조건이 복잡해질수록 조건을 판단하는 함수를 따로 분리하는 게 좋다는 것
• 백엔드에서 내려오는 데이터 구조를 정확히 이해해야 올바른 조건문을 작성할 수 있다는 것
• 조건에 해당하지 않는 경우의 처리도 신경 써야 한다는 것 (null, undefined, 빈 화면 등)

예를 들어, "여행자정보 폼이 포함된 경우"라는 조건을 체크하려면 해당 상품 데이터에서 어떤 필드를 봐야 하는지, 그 필드의 타입이 무엇인지 명확히 알아야 했습니다.

4. 국제화(i18n)와 폰트 설정

중국 의료관광 사이트 작업을 하면서 중국어 폰트 설정[5]이 생각보다 까다롭다는 걸 알게 되었습니다.

• 같은 한자여도 한국, 중국, 일본에서 미묘하게 다르게 표현됨
• Windows 환경에서 중국어가 제대로 보이려면 Noto Sans SC 같은 중국어 전용 폰트가 필요함
• font-family에서 fallback 순서도 중요함 (중국어 폰트 → 한글 폰트 → 기본 폰트)

이전에는 폰트를 "디자인 요소" 정도로만 생각했는데, 실제로는 사용자가 콘텐츠를 제대로 읽을 수 있는지를 결정하는 중요한 기능적 요소라는 걸 느꼈습니다.

5. Swiper 라이브러리 활용

협력 병원 컴포넌트[6]에 Swiper를 적용하면서, 라이브러리를 단순히 "가져다 쓰는 것"과 "제대로 이해하고 커스터마이징하는 것"의 차이를 느꼈습니다.

처음에는 공식 문서의 예제를 복붙했는데, 우리 디자인에 맞게 조정하려다 보니:

• slidesPerView, spaceBetween 등 옵션의 의미를 정확히 알아야 함
• 반응형으로 만들려면 breakpoints 옵션을 활용해야 함
• CSS와의 상호작용 (특히 높이, 너비 계산)을 이해해야 함

단순히 "슬라이드 만들기"가 아니라, 라이브러리의 구조를 이해하고 우리 프로젝트에 맞게 조정하는 능력이 필요하다는 걸 배웠습니다.

---

아쉬웠던 점

1. 로그와 디버깅

API 연동 과정에서 console.log로 예약 번호를 출력하도록 했는데, 나중에 생각해보니 더 체계적인 로그 관리가 필요할 것 같습니다. 개발 환경에서만 로그를 남기고, 프로덕션에서는 제거하는 방식 등을 고민해봐야겠습니다.

2. 테스트 케이스 고려

기능을 구현할 때 "정상 동작"만 생각하고 만들었는데, 실제로는:

• 예약이 0건일 때는 어떻게 보여줄까?
• 체크박스를 하나도 선택하지 않고 버튼을 누르면?
• API 호출이 실패하면 사용자에게 어떤 피드백을 줄까?

등등 예외 상황에 대한 고려가 부족했습니다. 다음부터는 기능을 구현하기 전에 이런 케이스들을 미리 정리해보려고 합니다.

3. CSS 작업의 일관성

이번 주에 CSS 작업이 10건 이상 있었는데, 매번 특정 컴포넌트의 스타일을 수정하는 방식이었습니다. 근본적으로는:

• 디자인 시스템이나 공통 스타일 가이드가 있으면 좋겠다는 생각이 들었음
• 매번 픽셀 단위로 조정하는 게 아니라, 정해진 spacing, color palette 등을 사용하면 더 일관성 있을 것 같음

물론 제가 이런 걸 제안할 수준은 아니지만, 나중에 기회가 되면 팀 차원에서 논의해보면 좋을 것 같습니다.

---

느낀 점

개발은 결국 "사용자 입장에서 생각하기"

이번 주 작업들을 하면서 가장 크게 느낀 점은, 좋은 개발자는 코드를 잘 짜는 사람이 아니라 사용자를 생각하는 사람이라는 것입니다.

• 체크박스 로직도 "사용자가 헷갈리지 않으려면 어떻게 해야 할까?"에서 시작
• 위챗 ID 복사 기능도 "사용자가 한 번의 클릭으로 쉽게 복사할 수 있게"하기 위한 것
• 개인정보 동의 체크박스도 "사용자가 명확히 인지하고 동의할 수 있게"하기 위한 것

코드를 짜는 시간만큼, 이 기능이 왜 필요한지, 사용자가 어떻게 사용할지를 고민하는 시간이 중요하다는 걸 배웠습니다.

작은 기능 하나에도 많은 고민이 필요하다

"체크박스 하나 추가하는 거 금방 되겠지"라고 생각했던 작업이 실제로는:

1. 전체 선택 로직 구현
2. 개별 선택 시 전체 선택 해제 처리
3. 선택 상태에 따른 버튼 스타일 변경
4. 버튼 클릭 시 선택된 항목만 필터링
5. API 호출 및 에러 처리
6. 확인 다이얼로그 추가

등등 생각보다 훨씬 많은 작업이 필요했습니다. 단순해 보이는 기능도 실제로는 여러 레이어의 로직이 얽혀 있다는 걸 체감했습니다.

기록의 중요성

이번 회고를 쓰면서, 제가 어떤 작업을 했는지 업무기록 데이터베이스를 보며 하나하나 떠올렸습니다. 만약 기록을 안 해뒀다면 "이번 주에 뭐 했더라...?"하며 막막했을 것 같습니다.

작업할 때는 귀찮아도, 간단하게라도 기록을 남기는 습관이 나중에 큰 도움이 된다는 걸 다시 한번 느꼈습니다. 특히 기술적인 고민이나 배운 점을 메모해두면, 나중에 비슷한 상황에서 참고할 수 있을 것 같습니다.

---

다음 주 목표

1. 예외 처리 강화: 정상 케이스뿐만 아니라 예외 상황도 고려하며 개발하기
2. 컴포넌트 설계 고민: 어떤 단위로 컴포넌트를 나눌지 미리 설계하는 습관 들이기
3. Material UI 학습: 회사에서 Material UI를 사용하는데, 공식 문서를 좀 더 꼼꼼히 읽어보기
4. 백엔드 API 이해: 프론트엔드 개발자지만 API 구조를 이해하면 더 효율적으로 일할 수 있을 것 같음

---

아직 많이 부족하지만, 매일 조금씩 배워가는 과정 자체가 즐겁습니다. 다음 주에도 열심히 배우고 성장하는 한 주가 되었으면 좋겠습니다!

내가 개발한 페이지..!