낭 만 당

버킷리스트 100가지 작성하기

낭만알파카 — Sun, 7 Jun 2026 17:08:55 +0900

2026년 6월 7일, 전략적 의사결정과 문제해결과 21세기 기업의 인재상 온라인 시험을 끝냈다.

2026년 1학기이자, 4학년 1학기가 종강했다..!

올해 상반기동안 이직도 하고, 학교도 다니며 정신없는 5개월을 보냈던 것 같다.

그래서...학업과 직장을 병행하며 한 학기를 보낸 겸, 버킷리스트를 제대로 만들어 보기로 했다.

이미 이룬 것들도 있고, 이룰 것들도 있고, 아직 정하지 못한 것들도 있지만, 100가지를 만들어 보려고 한다.

버킷리스트라는 존재를 만들어서 하나씩 이뤄나가면, 뭔가 조금씩 뿌듯하지 않을까 싶다!

드디어 낭만당이라는 블로그 이름의 닉값을 한다...

4학년 1학기 끝!

Bucket List

1. 강아지 키우기

2. 일본여행 가보기 完

3. 바다 한가운데있는 숙소에서 자보기

4. 1억 모으기

5. 부모님 모시고 해외여행 가기

6. 안반데기 가서 별 보기

7. 운동 1년 이상 꾸준히 하기

8. 야구장 테이블석 가보기

9. 가을야구 직관

10. 흠뻑쇼 가기

11. 스위스에서 패러글라이딩 完

12. 경제적 독립해서 내 명의 집 사기

13. 서핑 배우기

14. 몽골 사막에서 낙타 타고 여행

15. 클라이밍 해보기

16. 고요 콘서트 가기 完

17. 국토여행 (걷거나 자전거로)

18. 정규직 취뽀 完

19. 대학교 동기들과 졸업여행 가기

20. 대학교 졸업

21. 유렵 5군데 이상 여행으로 가보기

22. 패션쇼 런웨이 구경하기

23. 우유니 사막 가보기

24. 친구들이랑 해외여행 가기 完

25. 무한도전 관련 콘서트나 무도런 참여하기

26. 토크콘서트 가보기

27. 농촌활동 체험하기

28. 삿포로 가서 눈사람 만들기

29. 차박 해보기

30. 연인에게 도시락 싸주기

31. 의류 회사 OR 여행 회사 개발자 되기

32. 하프 마라톤 완주하기

33. 비행기 비즈니스석 이상 타보기

34. 블로그 글 100개 쓰기

35. 외국인 친구 만들기

36. 나만의 자동차 사서 애칭 붙여주기

37. 좋아하는 식물 하나 키워보기

38. 1월 1일 일출보러 가기

39. 호텔에서 10만원 넘는 룸서비스 음식 먹어보기

40. 번지점프 도전하기

(2026.06.07 기준)

41.

42.

43.

44.

45.

46.

47.

48.

49.

50.

51.

52.

53.

54.

55.

56.

57.

58.

59.

60.

61.

62.

63.

64.

65.

66.

67.

68.

69.

70.

71.

72.

73.

74.

75.

76.

77.

78.

79.

80.

81.

82.

83.

84.

85.

86.

87.

88.

89.

90.

91.

92.

93.

94.

95.

96.

97.

98.

99.

100.

[회고] 판교 출근 한 달 차, 프론트엔드 개발자의 AI 프로젝트 투입기

낭만알파카 — Wed, 20 May 2026 16:26:44 +0900

첫 출근과 업무 환경 적응 (4월)

입사 첫날인 4월 13일, 4월 1일부터 이미 시작되었다는 인사평가 관리 AI 시스템 개발 프로젝트에 바로 투입되었다. 실무는 일단 현장에 들어가서 부딪히며 배우는 게 가장 빠르다는 걸 느끼게 됬다..

입사일 전 주인가 받은 문자

처음 가본 프로젝트 회사의 사옥은 대기업이라 그런지 시설이 정말 좋았다. 판교 첫 출근이라 긴장해서 20분이나 일찍 출발했는데, 차가 겁나게 막혀서 딱 8시 59분에 간신히 도착했다.

첫날 오전엔 대표이사님과 인사를 나누고 1시간 정도 OT를 진행했다. 회사 소개부터 프로젝트 개요, 같이 일하게 될 분들의 호칭을 정리해 주셨고, 식대용 법인카드와 사원증 목걸이도 받았다 :)

내가 입사한 곳은 대기업 프로젝트를 수주해 IT 기획, SI, SM 사업을 진행하며, 최근에는 AI 기반 SaaS 서비스 런칭을 준비하고 있는 회사다. 사업 특성상 직원들마다 투입되는 프로젝트가 다르다고 한다. 보통 협력사들과 함께 일하는데, 내가 배정된 이번 프로젝트에는 우리 회사 개발자가 나 혼자뿐이었다.

순간 내 미래가 깜깜하고도 깜깜쓰였다.

다른 회사 분들과 일하는 건물 자체도 다르고, 심지어 우리 회사 분들 얼굴은 본 적도 없었다,, 첫날은 대표이사님이 밥도 사주시고 이것저것 챙겨주셨지만, 둘째 날부터는 다른 건물으로 가신다고 하니 진짜 홀로 남겨진 기분이었다.

정말 큰일 났구나 싶었는데, 다행히 같이 일하게 된 협력사 개발자분들이 점심 모임에 끼워주셨다.!!

구내식당은 A, B, C 코스에 샐러드까지 나오는데 퀄리티가 상당히 좋다. 역시 머기업은 다르다.

식곤증을 참아가며 협력사 분들을 따라 쫄래쫄래 판교 산책도 열심히 다니고 있다. (이것이 사회생활인가)

사옥 1층에 임직원 전용 카페도 있어서 근무 인프라는 만족스럽다. (빵이 진짜 맛있는데, 좀 비싸다.)

다만 진짜 우리 회사 사람들을 아직 모른다는 게 좀 그렇긴 했다.. 6월에 신입 한 분이 더 오시면 같이 회식을 한다고 하니, 그때나 정식으로 저녁 회식을 한다고 한다. 사내 단체 메신저 방에서 환영해주셔서 가입 인사라도 고민 겁나 하다가 남겨두었다..

평범해보이기 위한 인사

면접 때 다양한 기술 스택 경험과 빠른 학습 능력을 강조하셨는데, 설마 처음부터 전혀 다른 일을 시키려나 약간 불안하긴 했다.

이번 프로젝트는 프론트엔드 Vite, 백엔드 FastAPI, DB는 PostgreSQL, AI는 RAG 기반 등 낯선 아키텍처들이 섞여 있었다.

분명 프론트엔드 개발자로 들어왔는데, 첫 일주일은 내내 데이터 전처리와 DB 적재 작업만 했다. 솔직하게 ~~정말 재미없었~~

툴도 이전 회사에서 써본 DBeaver와 학교 데이터베이스 수업에서 잠깐 다뤄본 SQL이 전부였다. 낯선 환경이었지만 AI의 도움을 받아가며 어떻게든 이겨냈다. 제미나이 고맙다.

대외비 프로젝트라 보안도 상당히 엄격하다. 파일 첨부나 외부 스크랩이 막혀 있고, 사내망에서는 AI도 코파일럿 정도만 권장한다. 그래서 개인 노트북을 챙겨 다니며 필요할 때마다 제미나이의 도움을 받고 있다. 코드 관리도 기존에 쓰던 방식 대신 사내 보안용 CLI 툴을 사용하는데, 확실히 보안 하나는 철저하다는 느낌을 받았다.

첫 주는 사실상 데이터 프로비저닝만 했다.

데이터 전처리라고는 하지만 내가 주도적으로 할 수 있는 일도 없었고, 재미가 없었다.. 엑셀을 이렇게 많이 다뤄본 건 처음이었는데, 마우스 쓰기도 귀찮아서 단축키를 엄청나게 검색해 댔다. 덕분에 DBeaver 툴이랑 엑셀은 꽤 능숙해졌지만, 다시 하라면 ㅇ.ㅁ,,,,

팀장, 임원에 대한 인사평가시스템 회의록(DOCX) 전처리
인사평가시스템 데이터 이관용 테이블 설계 및 생성
인사평가시스템 데이터를 개발 DB로 1차 적재
인사평가시스템 데이터용 테이블 추가 설계 및 생성
1차 적재한 인사평가시스템 데이터를 개발 DB로 2차 적재
개발 DB로 2차 적재한 데이터를 운영 DB로 최종 이관

-> 엄청 자세한 인사 데이터를 보는거라 초반엔 남의 일기장 보는 기분이라 재밌었다 ~_~

기술 스택 및 주요 담당 업무

Frontend: React, Vite
Backend: FastAPI
Database: PostgreSQL
AI API Server: Amazon EC2, Agents SDK (Supervisor Agent, Note Agent 등)
LLM & RAG: Amazon Bedrock, Claude 4.6 환경, AWS Knowledge Base

주요 담당 업무

프론트엔드 백엔드만 하는건 아니고, AI 프롬프트 관리와 DB 설계, 약간 RAG 개발까지 나름 넓은 범위를 맡아서 하고 있다..

(나 입사 한달차인디..)

프론트엔드/UI 구현: 관리자 화면 전체 메뉴 및 개발 구조 생성, 관리자용 웹 UI 반응형 디자인 구조 개선
관리자 페이지 개발: 관찰 노트 리스트, 연도별 회차 관리, 에이전트 타입별 시스템 프롬프트 관리, 챗봇 사용 기록 관리 페이지 UI 및 기능 구현
백엔드/DB: 챗봇 사용 기록 관리를 위한 DB 테이블 설계 및 생성
AI/RAG 고도화: AI 에이전트별 Jinja 템플릿 기반 시스템 프롬프트 보안 강화 및 업그레이드, 에이전트 도구 Docstring 설정 리스팅 및 최적화, 수정, 약간의 소스코드 수정

실무 적용과 트러블슈팅

매주 고객사 현업 HR 담당자 및 AX 매니저들과 미팅을 진행하며 시스템 요구사항을 구체화하고 있다.

최근에는 실제 테스트 대상인 임원진들에게 시스템 오픈 공지를 진행했는데, 운영기 일부 사용자에게 signature has expired 에러가 발생하는 이슈가 있었다. 평소 실무를 할 때 브라우저 개발자 도구의 Network 탭과 Application 탭을 항상 켜두고 상태를 체크하는 체크리스트 습관이 있는데, 이를 통해 에이전트별 토큰 만료와 관련된 인증 이슈임을 빠르게 파악하고 조치할 수 있었다. 실서비스 환경에서는 정말 예상치 못한 변수들이 튀어나온다는 걸 다시 한번 체감했다.

최근에 본사 직원분들도 만나서 함께 점심 식사도 하고, 프로젝트 팀원분들과도 잘 지내고 있는 것 같아서 좋게 생각하고 있다!

이제 프로젝트 중반부를 향해 가고 있기 때문에 남은 기간 동안 안정적으로 시스템을 고도화하고 성공적으로 런칭하는 데 집중해야한다...

6월 말까지 파이팅!!

신입개발자의 퇴사와 2026 프론트엔드 면접 6곳에 대한 면접 정리

낭만알파카 — Wed, 25 Mar 2026 17:26:00 +0900

2월, 회사에서 갑작스럽게 사무실 이전 소식을 들었습니다.

원래 강남 근무였는데 구로디지털단지로 이전한다는 공지가 이사 2주 전에 나왔거든요.

자취방 이사도 보통 몇 달은 시간을 두고 준비하는데,,, 너무 갑작스러운 일정이라 솔직히 눈앞이 막막했습니다.

그 다음 날, 사수님과 면담을 하게 됐습니다. 여행 업계 특성상 개발 직군의 처우가 아쉬운 부분이 있다는 이야기부터, 지금보다 더 나은 환경을 찾아보는 것도 충분히 좋은 선택이라는 조언까지 해주셨어요. 저 같은 병아리 개발자를 두 달 동안 정말 많이 이끌어주신 분이라,,, 그 말이 더 크게 와닿았습니다.

물론 원래도 아쉬운 점이 전혀 없었던 건 아닙니다. 그래도 저는 고졸이고, 취업 시장도 쉽지 않다고 느끼고 있었고, 무엇보다 25년 차 사수님 밑에서 배울 수 있는 게 많다고 생각해서 버텨보려 했습니다.

하지만 출퇴근 거리가 더 멀어지는 상황에, 이런 중요한 변화가 통보식으로 전달됐다는 점은 꽤 당황스러웠습니다. 결국 바로 사람인 이력서를 최신화하고 지원을 넣기 시작했습니다.

그렇게 서류 결과가 하나둘 나오기 시작했는데, 최종적으로 11곳에서 합격 연락을 받았습니다. 그런데 또 다른 현실적인 문제가 있었습니다. 휴가가 거의 없어서 면접을 보러 갈 시간이 마땅치 않았던 거예요.

퇴사를 먼저 말씀드려야 할지, 아니면 어느 정도 결정이 난 뒤에 말씀드려야 할지 고민이 많았습니다. 하지만 너무 늦게 이야기하면 더 곤란해질 것 같았고, 설령 공백기가 생기더라도 어떻게든 해보자는 마음이 들었습니다. 그래서 다음 날 바로 퇴사 의사를 말씀드렸고, 3월까지만 근무하겠다고 전달했습니다.

다행히 이사님이자 사수님이셨던 개발팀장님, 그리고 과장님이자 멘토처럼 챙겨주셨던 기획 담당자분 모두 제 이야기를 잘 들어주시고 진심으로 상담해주셔서 정말 감사했습니다.

하필 다음 주에는 오른쪽 사랑니 발치 일정도 있어서, 남아 있던 연차를 거의 다 써야 했습니다. 그래서 ‘이왕 이렇게 된 거, 그날 면접을 몰아서 보자’는 생각을 하게 됐습니다.

그렇게 이틀 동안 면접을 다섯 개 봤습니다. 어떤 날은 월요일 퇴근 후 바로 마곡으로 이동해서 면접을 보기도 했습니다.

그 중 2군데가 붙었고, 좋은 처우 개선과 함께 이직을 하게 됬답니다..! 하핳

기분 좋은 이직짤

강남에 있던 사무실 이사.. 지금은 을지로로 이사왔습니다 (무려 청계천뷰이지만, 집에서 1시간 40분 걸림)

그러면 이제 그 면접들에 대한 이야기를 하려고 합니다...!

시 - 작

최근 여러 곳의 프론트엔드 포지션 면접을 보면서 느낀 건, 회사마다 분위기는 달라도 결국 확인하는 포인트는 꽤 비슷하다는 점이었다.

단순히 “React 할 줄 아세요?”를 묻는 게 아니라, 지금까지 어떤 방식으로 일해왔는지, 실무에서 어떤 판단을 했는지, 그리고 앞으로 어떤 개발자가 될 사람인지를 함께 보려는 질문이 많았다.

이 글은 여러 회사 면접에서 받았던 질문들을 회사명 없이 종합해서 정리한 기록이다. 프론트엔드 면접을 준비하는 사람이라면, 기술 질문만 외우기보다 어떤 맥락에서 이런 질문이 나오는지 같이 보면 훨씬 도움이 될 것 같다.

프론트엔드 이직 면접에서 실제로 많이 나왔던 질문들 정리

최근 여러 곳의 프론트엔드 포지션 면접을 보면서 느낀 건, 회사마다 분위기는 달라도 결국 확인하는 포인트는 꽤 비슷하다는 점이었다.

이 글은 여러 회사 면접에서 받았던 질문들을 회사명 없이 종합해서 정리한 기록이다.

프론트엔드 면접을 준비하는 사람이라면, 기술 질문만 외우기보다 어떤 맥락에서 이런 질문이 나오는지 같이 보면 훨씬 도움이 될 것 같다.

1. 가장 많이 나오는 질문은 결국 자기소개였다

어느 면접이든 거의 빠지지 않았던 건 자기소개였다.

그런데 여기서 중요한 건 화려한 표현보다, “나는 어떤 개발자인가”를 한두 문장으로 분명하게 말할 수 있느냐였다.

예를 들면 이런 식의 질문들이 반복됐다.

- 본인을 어떤 개발자라고 생각하는지

- 어떤 지향점을 가지고 있는지

- 왜 프론트엔드를 선택했는지

- 왜 지금 이직하려고 하는지

- 조기 취업을 하려는 이유는 무엇인지

- 학업과 실무를 병행할 수 있는지

- 현재 회사를 왜 나오려고 하는지

이 질문들은 사실 다 연결되어 있다. 면접관은 기술보다 먼저, 이 사람이 자기 선택에 대해 얼마나 납득 가능한 설명을 할 수 있는지를 본다.

특히 재학 중이거나 첫 이직인 경우에는 “왜 지금 취업/이직을 하려는지”를 굉장히 자주 물었다.

그래서 자기소개는 단순한 경력 요약보다 아래 흐름으로 준비하는 게 훨씬 좋다.

- 내가 어떤 개발자인지

- 어떤 경험을 통해 그렇게 생각하게 됐는지

- 지금 왜 이 회사를 선택했는지

- 앞으로 어떤 방향으로 성장하고 싶은지

2. React와 Next.js는 ‘써봤다’보다 ‘어디까지 이해했는지’를 본다

프론트엔드 포지션이다 보니 React, Next.js 관련 질문은 정말 자주 나왔다.

특히 인상적이었던 건, 문법을 아는지보다 “실무에서 판단 가능한 수준인지”를 보려는 질문이 많았다는 점이다.

자주 나온 질문은 이런 것들이었다.

- React는 어느 정도 수준으로 다룰 수 있는지

- Next.js를 실제로 얼마나 써봤는지

- React와 Next.js의 장단점은 무엇인지

- Next.js에서 배포는 어떻게 하는지

- React 앱 배포와 Next.js 배포는 뭐가 다른지

- useCallback은 왜 쓰는지

- 하이드레이션은 무엇인지

- 리렌더링 최적화 경험이 있는지

- 상태 관리는 어떤 기준으로 선택하는지

이 질문들에서 느낀 건, 면접관은 “기술 이름을 아는 사람”보다 “기술을 왜 그렇게 썼는지 설명할 수 있는 사람”을 찾는다는 점이었다.

예를 들어 React와 Next.js 비교는 단순히

“Next.js는 SSR 되고 React는 안 된다”

이 정도로 끝내면 부족하다.

실제로는 이런 정도까지 생각해두는 게 좋다.

React는 라이브러리라서 구조 자유도가 높고, CSR 중심으로 가볍게 시작하기 좋다.

Next.js는 React 기반 프레임워크라 라우팅, SSR/SSG, 서버 컴포넌트, 배포 구조 등 풀스택에 가까운 기본 틀을 제공한다.

대신 Next.js는 구조와 런타임 개념을 더 이해해야 해서 초반 진입 난이도는 조금 더 있다.

프로젝트 규모, SEO 필요 여부, 초기 렌더링 전략, 서버 연동 구조에 따라 선택이 달라진다.

useCallback도 마찬가지다.

“함수 메모이제이션입니다”로 끝나는 게 아니라, 언제 의미가 있고 언제 과한지까지 말할 수 있어야 한다.

예를 들면 이렇게 정리할 수 있다.

useCallback은 함수를 재생성하지 않게 해서 자식 컴포넌트 리렌더링을 줄일 때 의미가 있다.

하지만 무조건 쓰는 건 아니고, React.memo와 함께 실제 병목이 있는 경우에 쓰는 게 낫다.

최적화 도구이지 기본값은 아니다.

하이드레이션 질문도 자주 나왔다.

이건 Next.js를 건드려본 사람인지 확인하기 좋은 질문이라 그런 것 같다.

핵심은 이 정도로 정리하면 자연스럽다.

서버에서 먼저 렌더링한 HTML에 클라이언트 JavaScript가 붙으면서 상호작용 가능한 상태가 되는 과정

서버 HTML과 클라이언트 렌더 결과가 다르면 하이드레이션 에러가 날 수 있음

시간, 랜덤값, 브라우저 전용 객체 접근 같은 부분이 대표적인 원인

3. TypeScript 질문은 생각보다 기본에서 많이 갈린다

TypeScript 관련 질문은 오히려 어려운 문법보다 기본 개념에서 많이 나왔다.

대표적으로 이런 것들이다.

- 제네릭은 언제 쓰는지

- interface와 type 차이는 무엇인지

- null과 undefined 차이는 무엇인지

- 타입 안정성을 실무에서 어떻게 확보했는지

이런 질문이 반복된 이유는, 결국 실무에서 타입을 “문법”이 아니라 “설계”로 썼는지 알고 있는지 확인하려는 의도 같았다.

예를 들어 제네릭은 아래처럼 설명하면 깔끔하다.

타입을 고정하지 않고, 사용하는 시점에 타입을 전달받아 재사용 가능한 구조를 만들 때 사용한다

API 응답 타입, 공통 훅, 테이블/폼 컴포넌트처럼 입력과 출력은 달라질 수 있지만 구조는 비슷한 경우에 유용하다

결국 유연성과 타입 안정성을 동시에 확보하려는 도구다

interface와 type 차이도 면접에서 꽤 자주 나왔다.

실무적으로는 이렇게 정리하면 충분하다.

interface는 객체 구조를 정의하는 데 직관적이고 확장에 유리하다

type은 유니온, 인터섹션, 튜플, 원시 타입 별칭 등 더 넓은 표현이 가능하다

팀 컨벤션에 따라 다르지만, 객체 중심 구조는 interface, 조합형 타입 표현은 type으로 나누기도 한다

null과 undefined 차이도 기본 같지만 은근 자주 물어본다.

undefined는 값이 아직 할당되지 않았거나, 존재하지 않음을 의미하는 경우가 많다.

null은 의도적으로 비어 있음을 명시할 때 사용한다.

실무에서는 API 응답, 폼 초기값, optional 필드 처리에서 이 차이가 꽤 중요하다.

4. 네트워크, 인증, 브라우저 저장소 질문은 거의 필수였다.

생각보다 많은 회사가 프론트엔드 지원자에게 브라우저와 네트워크 기본기를 중요하게 봤다.

특히 단순 UI 개발자가 아니라, 실제 서비스 환경을 이해하는 사람인지 확인하려는 느낌이 강했다.

많이 나온 질문은 아래와 같다.

- CORS 에러가 무엇인지

- CORS 에러가 나면 프론트엔드/백엔드에서 어떻게 해결하는지

- 쿠키, 세션, 로컬스토리지 차이

- 로컬스토리지가 쿠키보다 불리한 점은 무엇인지

- 다른 도메인에서 기존 쿠키가 보이는지

- 로그인은 구현해본 적이 있는지

- 했다면 토큰 기반인지 세션 기반인지

- 인증 상태를 어떻게 관리했는지

이런 질문은 외워서 대답하는 것보다, 실제 구현 경험과 연결해서 말하는 게 훨씬 좋다.

예를 들어 로그인 질문에는 이렇게 붙일 수 있다.

- 액세스 토큰/리프레시 토큰 구조를 사용했는지

- 토큰 저장 위치를 왜 그렇게 선택했는지

- 만료 처리나 재발급은 어떻게 했는지

- 로그인 실패/권한 에러 시 UX는 어떻게 처리했는지

- 브라우저 저장소는 특히 자주 나온다.

- 기본적으로 아래 정도는 정리해두는 게 좋다.

쿠키는 요청마다 서버로 자동 전송될 수 있고 만료/도메인/path 설정이 가능하다.

세션은 서버가 상태를 관리하고, 브라우저는 세션 식별자만 들고 있는 구조다.

로컬스토리지는 브라우저에 직접 저장되고 자동 전송되지 않는다.

로컬스토리지는 XSS에 취약할 수 있어서 민감한 토큰 저장에는 신중해야 한다.

쿠키는 도메인/서브도메인/path/sameSite 설정에 따라 접근 범위가 달라진다.

5. 실무 경험을 물을 때는 “무슨 기능을 했나”보다 “어떻게 일했나”를 본다

면접에서 실무 이야기가 나오면 단순히 프로젝트 소개를 시키는 게 아니었다.

실제로는 아래를 확인하는 질문이 많았다.

- TypeScript로 구체적으로 어떤 작업을 했는지

- 맡았던 역할이 무엇인지

- 기존 코드를 분석할 때 어떤 방식으로 접근하는지

- 레거시를 개선한 경험이 있는지

- 로그인, 버전관리, 대시보드, 위젯 관리 같은 기능을 어떻게 설계했는지

- 사용자 편의성과 운영 안정성을 어떻게 같이 봤는지

여기서 중요했던 건 “내가 뭘 만들었다”보다 “그 상황에서 어떤 판단을 했다”를 말하는 것이었다.

예를 들어 관리자 대시보드를 두 명이 동시에 편집하는 상황 같은 경우도 좋은 사례가 된다.

이런 경험은 단순한 UI 구현이 아니라, 상태 충돌과 동시성 문제를 이해하고 있다는 신호가 되기 때문이다.

이럴 때는 아래처럼 풀면 좋다.

소켓 통신으로 현재 편집 중인 사용자 정보를 실시간 공유했다

브라우저별 식별을 위해 브라우저 ID를 두고, 같은 리소스를 누가 보고 있는지 추적했다

같은 대시보드를 두 명이 동시에 수정할 수 있는 경우, 편집 잠금 또는 충돌 감지 전략이 필요했다

예를 들어 한 사용자가 편집 중이면 다른 사용자는 읽기 전용으로 보거나, 특정 위젯 단위만 잠그는 방식으로 설계할 수 있다

저장 시점에는 마지막 수정 시간이나 버전 값을 비교해 충돌 여부를 확인하고, 필요하면 사용자에게 알리는 방식도 고려했다

이런 답변은 “소켓 써봤습니다”보다 훨씬 실무적으로 들린다.

6. AI 활용 질문은 이제 거의 빠지지 않는다

이번 면접들에서 확실히 느낀 건, 이제 AI 활용 경험은 선택지가 아니라 검증 항목에 가까워졌다는 점이다.

실제로 많이 나온 질문은 이랬다.

- Cursor, Claude Code, Antigravity 같은 도구를 써봤는지

- CLI로 Claude Code를 쓸 때 서브 에이전트나 MCP를 써봤는지

- AI가 짠 코드를 어디까지 이해하고 책임질 수 있는지

- AI 결과물의 품질은 어떻게 검증하는지

- AI 시대에 개발자의 방향성은 뭐라고 생각하는지

- 새로운 AI 도구를 회사에 제안할 생각이 있는지

이 질문들에서 중요한 건 “저 AI 잘 써요”가 아니었다.

오히려 “AI를 통제하면서 쓰는 사람인지”를 보는 느낌이 강했다.

그래서 답변도 이런 결이 좋다.

AI는 속도를 올려주는 도구지만, 최종 책임은 개발자에게 있다

생성된 코드는 반드시 직접 읽고, 타입/로직/부수효과를 검증해야 한다

프로젝트 규모가 커질수록 AI에게 수정 범위와 제약을 명확히 줘야 한다

공식 문서, 네트워크 탭, 실제 데이터 흐름으로 교차 검증하는 습관이 중요하다

개인적으로는 이 부분이 앞으로 더 중요해질 것 같다.

이제는 코드를 “직접 다 쓰는 사람”보다, 도구를 활용하면서도 품질을 지킬 수 있는 사람이 더 강한 개발자가 될 가능성이 크다.

7. 회사가 진짜 궁금해하는 건 조직 적응력이다

기술 질문만큼 많이 나왔던 게 협업, 태도, 조직 적응 관련 질문이었다.

예를 들면 이런 질문들이다.

- 개발자가 기획이나 도메인 지식에 참여하는 것에 대해 어떻게 생각하는지

- 팀의 방향과 내 생각이 다를 때 어떻게 행동하는지

- 시니어 개발자와 커뮤니케이션은 어땠는지

- 팀 프로젝트 중 의견 충돌은 어떻게 해결했는지

- 신입을 왜 뽑아야 한다고 생각하는지

- 야근이나 지방출장에 대한 생각은 어떤지

- 새로운 스택을 맡게 되면 어떻게 공부할 건지

- 적성과 조금 안 맞는 업무를 맡아도 할 수 있는지

- 이 질문들에 대한 공통된 답은 결국 하나였다.

“잘하려고 하는 사람”보다 “같이 일하기 괜찮은 사람”을 찾는다는 것.

특히 좋은 인상을 줄 수 있는 포인트는 아래와 같았다.

모르는 걸 숨기지 않고 빠르게 공유하는 태도

본인 주장만 세우지 않고 근거를 가져오는 태도

시키는 일만 하지 않고, 필요한 걸 먼저 찾아보는 태도

새로운 기술을 배우는 데 거부감이 없는 태도

기획/디자인/운영의 맥락까지 이해하려는 태도

8. 희망 연봉, 출근 가능일, 근무 조건 질문도 생각보다 중요하다

많은 지원자가 기술 준비에만 집중하지만, 실제 면접에서는 처우와 근무 조건도 꽤 구체적으로 확인한다.

주로 이런 것들을 물었다.

- 희망 연봉은 얼마인지

- 계약직 후 정규직 전환이 가능한지

- 출근 가능일은 언제인지

- 출퇴근 거리 문제는 없는지

- 지방출장 가능 여부

- 야근에 대한 생각

- 회사 규모나 문화가 본인과 맞는지

이 부분은 너무 전략적으로만 접근하기보다, 현실적으로 답하는 게 중요하다.

특히 희망 연봉은 시장가, 본인 경력, 현재 조건, 회사 규모를 고려해서 일관된 기준을 갖고 말하는 게 좋다.

9. 결국 면접은 ‘암기’보다 ‘정리’ 싸움이었다

여러 면접을 보면서 느낀 건, 질문 자체가 아주 특별해서 어려운 건 아니었다.

오히려 기본적인 질문을 얼마나 자기 경험과 연결해서 말할 수 있는지가 더 중요했다.

예를 들면 이런 것들이다.

“제네릭이 뭔가요?”

이걸 사전식으로 말하는 사람보다, 실제 API 응답 타입이나 공통 컴포넌트 설계 경험과 연결하는 사람이 더 설득력이 있다.

“하이드레이션이 뭔가요?”

정의만 말하는 사람보다, 서버 렌더링과 클라이언트 상태 불일치 때문에 에러가 날 수 있다는 실무 감각을 보여주는 사람이 더 기억에 남는다.

“AI를 어떻게 쓰나요?”

그냥 많이 쓴다고 말하는 사람보다, 검증 루프와 책임 범위를 같이 말하는 사람이 더 신뢰를 준다.

결국 면접 준비는 질문을 외우는 게 아니라, 내 경험을 기술 언어로 다시 정리하는 과정에 더 가깝다.

마무리

프론트엔드 면접이라고 해서 화면 구현 이야기만 나오는 시대는 이미 지난 것 같다.

이제는 React/Next.js 같은 프레임워크 이해도는 기본이고, 브라우저/네트워크/인증/타입 시스템에 대한 감각, 실무에서의 판단력, 협업 태도, AI 활용 방식까지 함께 본다.

면접을 준비하면서 가장 크게 느낀 건 하나였다.

좋은 답변은 멋있는 말에서 나오지 않고, 내가 실제로 해본 일을 스스로 정리해본 사람에게서 나온다.

그래서 앞으로 면접을 준비한다면, 질문을 많이 모으는 것보다 먼저 아래를 정리해보는 걸 추천한다.

1. 나는 어떤 개발자인가

2. 어떤 문제를 어떤 방식으로 해결해봤는가

3. 왜 그 기술을 선택했는가

4. 협업에서 나는 어떤 태도를 보였는가

5. AI와 같은 도구를 어디까지 이해하고 통제할 수 있는가

이 다섯 가지만 정리돼 있어도, 대부분의 질문은 훨씬 덜 흔들리게 된다.

(실제로 저는 많은 질문에 제대로 답변을 못했기 때문에, 이 글을 보시는 분들은 좋은 결과가 있기를 바랍니다...)

끝!

3개월 개발 업무, 기억에 남는 업무 Key points

낭만알파카 — Wed, 25 Mar 2026 16:01:14 +0900

1. 식별의 정밀도: 사용자 ID를 넘어 oxuid 도입하기

일반적인 서비스는 유저 ID만으로 사용자를 식별하지만, 실제 운영 환경에서는 한 사용자가 여러 브라우저를 쓰거나 여러 개의 탭을 띄워놓고 작업하는 경우가 비일비재합니다. 이때 동일 계정 내에서 발생하는 데이터 충돌을 제어하기 위해 oxuid(Browser-level Unique ID)를 도입했습니다.

브라우저 세션이나 로컬 스토리지에 고유 키를 생성하여 저장하고, 모든 API 요청 헤더에 이를 포함시켰습니다. 이를 통해 로그 추적 시 어떤 사용자가 수정했는지를 넘어, 어느 브라우저 컨텍스트에서 발생한 행위인지 명확히 분리할 수 있게 되었습니다. 이는 CS 인입 시 클라이언트의 로컬 상태와 서버의 타임라인을 매칭하는 결정적인 단서가 됩니다.

2. 소켓 기반의 실시간 동시 편집 제어

관리자 대시보드에서 두 명 이상의 관리자가 동일한 항목을 편집할 때 발생하는 덮어쓰기 문제는 서비스의 신뢰도와 직결됩니다. 이를 해결하기 위해 단순 HTTP 요청이 아닌 웹소켓 기반의 실시간 상태 동기화 구조를 설계했습니다.

핵심은 세 가지입니다. 먼저 유저 ID와 oxuid를 조합하여 누가 어떤 브라우저에서 편집 중인지 식별합니다. 이후 입력 시작, 저장, 취소 같은 이벤트를 소켓으로 전파하여 다른 편집자의 화면에 즉시 반영합니다. 마지막으로 동일 항목 수정 시 잠금 표시나 경고 문구를 띄워 사용자가 현재 상태를 이해하고 안전하게 복구할 수 있는 UX를 제공합니다. 동시 편집에서 중요한 건 충돌을 0으로 만드는 것보다, 충돌 상황에서도 데이터가 안전하게 보존된다는 확신을 주는 것이었습니다.

3. 타입 시스템의 엄격함: any 배제와 제네릭의 경계

타입스크립트는 단순한 장식이 아니라 프로젝트의 설계도여야 합니다. 모든 변수와 함수에서 any 타입을 완전히 배제하고 명확한 인터페이스나 타입을 선언하는 것을 원칙으로 삼았습니다. 이는 협업 시 동료가 내 코드를 직관적으로 이해하게 만드는 최소한의 약속입니다.

특히 제네릭은 단순히 타입을 재사용하기 위한 문법을 넘어, 함수나 컴포넌트가 책임지는 입력과 출력의 경계를 분명히 해주는 도구로 활용했습니다. 이를 통해 기능이 커질수록 발생할 수 있는 런타임 에러를 컴파일 단계에서 차단하고 유지보수 효율을 극대화했습니다.

4. 도구와 습관: 집중력을 유지하는 기술

배열이나 객체 처리에서 매번 비슷한 로직을 새로 작성하면 실수가 늘어납니다. Lodash 같은 검증된 라이브러리를 적절히 활용해 반복 패턴을 줄이고 코드 가독성을 높였습니다. 또한 터미널 활용과 단축키 숙달은 단순히 속도를 높이는 것이 아니라 사고의 흐름을 유지하기 위한 전략입니다. 창 전환이나 파일 검색에 들어가는 에너지를 줄여 맥락 전환 피로를 최소화했습니다.

공식 문서를 읽을 때도 처음부터 끝까지 읽기보다는, 지금 해결해야 할 질문을 먼저 정의하고 필요한 섹션 중심으로 파고드는 방식을 택했습니다. 읽은 내용을 즉시 코드와 체크리스트에 반영할 때 지식은 비로소 내 것이 되었습니다.

UX와 환경의 디테일: 보이기보다 버티기

1. 반응형 레이아웃과 터치 인터페이스

반응형 작업의 본질은 화면 크기에 맞춰 예쁘게 보이는 것을 넘어, 어떠한 해상도에서도 레이아웃이 깨지지 않고 사용자 동선이 유지되는지에 있습니다. 브레이크포인트마다 텍스트 배치, 간격, 버튼의 우선순위를 확인하는 과정을 체크리스트에 넣었습니다. 특히 데스크톱의 마우스 클릭과 모바일의 터치 인터페이스가 각 환경에서 오동작 없이 정확히 트리거되는지 전 기기에서 교차 검증합니다.

2. 개발자 도구의 입체적 활용

문제 원인이 코드가 아닐 때도 많다는 것을 배웠습니다. 네트워크 탭을 통해 요청과 응답, 페이로드, 응답 시간을 집요하게 파악하고, 애플리케이션 탭에서 로컬 스토리지나 세션 값이 의도대로 들어가는지 확인하는 것을 습관화했습니다. 이를 통해 특정 상황에서만 발생하는 간헐적 이슈를 훨씬 빠르게 잡아낼 수 있게 되었습니다.

배포 전후 체크리스트: 마지막 방어선

배포 전: 환경의 분리와 정합성 점검

로컬 및 CI 환경에서 빌드 에러 없이 깔끔하게 완료되는지 확인하는 것은 기본입니다. 가장 중요한 것은 운영 환경용 API 엔드포인트, DB 접속 정보, 보안 키가 누락 없이 적용되었는지 점검하는 것입니다. 개발용 데이터와 운영용 데이터가 섞이지 않도록 환경 변수를 철저히 분리하고, 내가 구현한 기능이 기존의 타 플랫폼이나 모듈에 부정적인 영향을 주지 않는지 영향도를 평가합니다.

배포 후: 실시간 모니터링과 피드백

배포 직후 스테이징 서버에서 테스트했던 핵심 시나리오가 운영 환경에서도 동일하게 작동하는지 즉시 확인합니다. 브라우저 콘솔 창에 예기치 못한 에러 메시지가 출력되지 않는지, API 응답 속도가 사용자 경험을 저해할 정도로 느려지지는 않았는지 실시간으로 모니터링합니다. 마지막으로 배포 완료 상황을 팀에 공유함으로써 전체 공정의 마침표를 찍습니다.

첫 3개월, 프론트엔드개발자로의 첫 사회 생활..기술적 회고

낭만알파카 — Wed, 25 Mar 2026 15:05:38 +0900

2026년 1월, 회사에 입사하면서 처음으로 “회사에서 웹을 만드는 사람”이 됐습니다.

첫 출근 주에 느낀 감정은 생각보다 단순했습니다..

빨리 도움이 되고 싶고, 동시에 문득문득 “내가 알고 있던 것들이 여기서도 진짜 통할까?” 하는 불안도 같이 따라왔죠.

학교 과제나 개인 프로젝트에서는 일정이 조금 밀려도 “내가 감당하면 그만, 다시 하면 그만”이라는 여지가 있었는데, 회사에서 만든 웹은 운영팀/CS/영업/그리고 고객의 시간이 같이 걸려 있었습니다. 그게 체감되는 순간, ‘같은 코드를 짜도 결이 다르다’는 걸 자연스럽게 알게 됐어요.

저에게 할당된 이슈는 온전희 "저만의 것"이었습니다. 제가 짠 코드의 책임은 제가 감당하는 것이었죠,,, (몇번 사고쳤습니다 허헣)

돌이켜보면 지난 3개월은 “기능을 만드는 법”보다 “기능이 살아있게 만드는 법”을 배우는 시간이었습니다.

이 글은 그 과정에서 제가 자주 부족함을 느꼈고, 결국 어떤 방식으로 스스로를 메웠는지 정리해보려는 회고입니다.

실무 JavaScript, 이론 말고 ‘현장 감각’

1) 비동기는 await 문제가 아니라 “상태” 문제였다

입사 초반에는 저도 당연히 “요청 보내고 성공하면 토스트 띄우고 끝”처럼 접근했어요. 그런데 항공 견적/신청/관리 플로우를 만들다가 운영에서 바로 문제가 터졌습니다.

사용자 입장에서는 화면이 한 번에 끝나는 것처럼 보이는데, 실제로는 이런 것들이 한 흐름으로 연결돼야 하더라고요.

견적 요청 입력(유효성)
요청 생성(로딩/중복 방지)
요청 상태 변화(대기/확정/반려 등)
리스트/상세/수정/취소 같은 화면 전환

문제는 여기서였어요. 예를 들어 사용자가 저장 버튼을 연속으로 누르면 중복 요청이 생길 수 있고, 네트워크가 느리면 로딩 상태가 꼬이면서 사용자가 “저장됐는지” 확신을 못 하게 됩니다. 또 실패했을 때 메시지가 애매하면 CS로 바로 문의가 들어오기도 하고요.

그래서 이후에는 구현 순서를 바꿨습니다.

먼저 실패 시나리오를 적었어요. 중복 클릭, 타임아웃, 권한 오류, 입력 누락 같은 것들. 그리고 그 다음에 “그 실패가 화면에서는 어떻게 보여야 하는지”를 정했습니다. 버튼 disabled는 언제 걸지, 스피너는 어디에 둘지, 에러 문장은 어떤 톤으로 줄지, 재시도 UX는 어떻게 만들지요. 그 다음에 API 호출 코드를 붙였습니다.

그때 확실히 느꼈습니다. 비동기는 결국 “코드가 기다리는 것”이 아니라 “사용자가 기다리는 동안의 정합성”이더라고요.

2) 최적화는 성능 수치보다 ‘손맛’에 더 가까웠다

2월 초에 이미지 관리 화면을 개선하면서 밀러컬럼(Miller Columns) 형태의 컴포넌트를 새로 만들었어요. 요구사항대로 기능도 구현했고, 운영에 붙이고 나서 “고도화”가 시작됐습니다.

처음엔 단순히 “컬럼을 늘려가며 탐색하는 UI”가 되면 된다고 생각했는데, 실제 데이터가 쌓이고 클릭이 빠르게 이어지니까 문제가 드러났습니다.

선택이 바뀔 때마다 리스트 전체가 다시 렌더링되면서 클릭 반응이 느려지고
스크롤 위치가 예상과 다르게 튀면서 사용자가 “내가 뭘 선택했지?”를 놓치기도 했고요

그래서 결론은 이거였어요. 성능보다 중요한 건 “반응”이었습니다. 사용자가 느끼는 끊김을 없애는 게 핵심이었고, 결국 저는 아래처럼 접근을 바꿨습니다.

상태를 덩어리로 들고 가지 말고 컬럼 단위로 나눠서 변경 범위를 줄이고, 무거운 렌더는 메모이제이션/키 설계를 다시 손봤습니다. 그리고 빈 상태/로딩 상태/에러 상태를 각각 분명하게 보여주면서, UI가 적어도 “지금 무슨 일이 일어나고 있는지”를 말해주게 만들었습니다.

그때 처음으로 “몇 ms 줄이기”가 아니라 “끊기지 않는 경험”이 최적화라는 걸 제대로 이해했어요.

memozation의 중요성...깨달았습니다.

3) TypeScript는 ‘안전장치’라기보다 경계를 세우는 도구였다

초반에는 타입 오류를 없애는 것 자체가 목표였는데, 시간이 지나니까 TypeScript가 ~~저한테 계속 말 걸어주는 느낌이 들더라고요.~~ “너 여기서 뭐가 뭔지 모호하지 않게 분리해봐”라고요. (주접,,)

디자인 에디터에서 템플릿/페이지별 백업 및 버전 관리 기능(3/3~3/4)을 만들 때 이게 특히 크게 왔습니다. 처음엔 API 응답 형태를 그대로 화면 상태로 들고 가려 했는데, 금방 한계가 왔어요. 백업 단위(템플릿/페이지)랑 버전 규칙(정렬/식별), 그리고 복원/비교/삭제 권한 같은 것들이 한 화면 로직 안에서 서로 섞이면서 복잡해졌거든요.

그래서 결국 세 덩어리로 나누는 쪽을 택했습니다.

서버 응답 타입
UI에서 실제로 필요한 도메인 모델(화면에서 최소 형태)
폼 입력 상태(사용자 편집 상태)

타입을 나눈다는 건 결국 “레이어가 뭘 책임질지”를 정하는 일이더라고요. 그 이후로 기능 추가가 훨씬 덜 무섭게 느껴졌습니다.

협업을 하면서 배운 ‘함께 만드는 소프트웨어’

신입 때 제가 가장 힘들었던 건 기술 자체라기보다, “내가 만든 변경이 다른 팀 일에 어떤 영향을 줄까?”를 상상하는 일이었습니다. 기획/디자인/운영과 대화하면서 반복해서 같은 교훈을 얻었어요.

1) 요구사항은 구현 전에 한 번 더 다시 써야 한다

예를 들어 고객센터 1:1 문의를 계층형 쓰레드 구조로 바꾸는 작업은 단순히 UI만 바꾸는 문제가 아니었습니다. “대화가 흐름으로 이어져야 한다”는 요구는 결국 추상적이었고, 그걸 그대로 구현하면 사람마다 해석이 달라지더라고요.

그래서 처음엔 저도 기획 문장을 그대로 코드로 옮기려 했는데, 계속 흔들렸습니다.

부모 문의/답변 구분이 어디서부터 확정되는지
운영자는 어디를 어떤 단위로 찾아야 하는지
사용자는 어떤 순서로 읽어야 하는지

기본 정의가 없으니 구현이 흔들리는 건 당연하더라고요.

그래서 그 다음부터는 이해한 요구사항을 제가 다시 “내 말로” 정리해서 공유했습니다.

사용자가 보는 흐름(읽는 순서)
운영자가 처리하는 흐름(검색/정렬/상태)
예외 케이스(삭제된 글, 비공개, 답변 지연)

그리고 이걸 문장으로 정리해서 확인받고 나서 코드를 썼더니, 중간 수정이 줄고 커뮤니케이션 비용도 확 내려갔습니다.

2) UX는 ‘있다/없다’가 아니라 “찾을 수 있느냐”였다

1월 말 메시지 센터에서 필터/검색 기능을 붙였고(1/28), 1월에는 쿠폰 삭제/회수/검색/필터링 및 UI도 구현했습니다(1/26). 기능을 추가했다고 생각했는데, 현장에서는 그게 “업무 속도”로 평가되더라고요.

제가 초반에 놓쳤던 디테일은 결국 이런 것들이었습니다.

빈 결과일 때 무엇을 보여줄지
검색 조건이 남아 있을 때 사용자가 “왜 안 나오지?”를 이해할 수 있는지
필터 초기화/해제 흐름이 직관적인지
회수/삭제 같은 위험 작업에서 실수를 막는 문장과 확인 UX가 있는지

결국 제품 신뢰도는 화려한 기능이 아니라, 사용자가 실수하지 않게 만드는 작은 장치에서 나온다는 걸 배웠습니다.

기술적 한계를 마주하고 극복한 사례

제가 “이건 혼자 머리로 들고 가면 위험하겠다”라고 느낀 순간은 주로 데이터와 정책이 복잡해지는 기능에서 왔어요. 가장 기억에 남는 건 디자인 에디터 백업/버전 관리(3/3~3/4)였습니다.

백업이 템플릿 단위/페이지 단위로 나뉘고, 버전이 쌓이며(정렬/식별) 복원/삭제 같은 되돌리기 어려운 작업도 생길 수 있고, 운영자가 실수하면 고객 화면이 바로 망가질 수도 있는 구조였거든요.

그래서 “일단 만들고 고치자”가 잘 통하지 않는 영역이었습니다.

그때 제가 했던 대응은 두 가지였어요.

먼저 규칙을 정했습니다. 백업의 단위, 버전 이름 규칙, 기본 정렬, 삭제 가능 조건 같은 정책을 먼저요.
그 규칙을 코드가 아니라 UI에도 반영했습니다. 사용자가 규칙을 어길 수 없게, UI가 자연스럽게 흐름을 따르도록 만든 겁니다.

그리고 이 과정에서 제일 도움이 됐던 건 ‘혼자 판단하지 않기’였습니다. 중간중간 더 경험 많은 동료에게 설계를 보여주고, 애매한 부분은 빨리 질문해서 피드백을 반영했어요. 신입일수록 “잘 모르겠다”를 빨리 꺼내는 게 팀 전체의 비용을 줄인다는 걸 배웠습니다.

컨디션이 안 좋은 날도 있었고(사랑니…ㅠ), 그럴수록 생산성보다 “사고 확률”을 낮추는 쪽으로 방향을 잡게 됐습니다. 그래서 이후엔 아래 원칙을 개인 규칙처럼 지키려고 했어요.

하루 단위로 “오늘 끝낼 수 있는 최소 단위”를 정의하기
막히는 작업은 숨기지 않고, 현재 상태/리스크/다음 액션을 문장으로 공유하기
에너지가 떨어진 날은 신규 기능보다 리팩터링/문서화/예외 케이스 정리처럼 실수를 줄이는 작업으로 무게중심을 옮기기

다음 3개월의 목표

이제 앞으로의 3개월은 “돌아가는 코드”보다 “지속 가능한 코드” 쪽에 더 힘을 주려고 합니다.

변경 비용을 줄이는 구조(경계, 책임, 도메인 모델)를 먼저 고민하고 기능을 붙이기
사용자와 운영을 함께 보기. 실패/예외/권한/로깅까지 포함해서 “운영 가능한 화면”을 기본값으로 만들기
협업의 언어를 더 단단하게 만들기. 요구사항을 내 말로 다시 쓰고 의사결정 근거를 남겨서 팀이 같은 그림을 보게 만들기

지난 3개월은 “나는 개발자다”라는 확신을 주기보다는, “배워야 할 게 너무 많다”는 사실을 선명하게 보여준 시간이었습니다.

다만 그 불안이 방향을 만들어줬다는 점에서, 저는 이 시간동안 많은 것들을 배우고 경험한 것 같습니다.

했던 작업을 기술적으로 풀어쓴 기록 (업무기록 기반)

아래는 “무슨 기능을 했다”가 아니라, 제가 실제로 어떤 식으로 설계/구현했는지(데이터, 상태, 예외, UX, 유지보수 관점) 기준으로 정리한 내용입니다.

1) 쿠폰 삭제/회수/검색/필터링 기능 + UI 구현

- 문제: 쿠폰 데이터는 많고, 운영자가 원하는 건 “빠르게 찾고, 실수 없이 회수/삭제하는 것”이었습니다. 단순 검색만으로는 작업 속도가 안 나왔고, 위험한 액션(회수/삭제)에서 실수가 나올 가능성이 컸습니다.

- 구현 포인트

- 검색: 검색바 좌측에 ‘필드 선택 드롭다운’을 넣고, 전체/ID/쿠폰코드/쿠폰명/할인가격/주문최소금액/사용방식/메모/비고/생성일/상태 등으로 스코프를 제한해 검색 정확도를 올렸습니다. 필드에 따라 placeholder가 동적으로 바뀌게 해서 사용자가 “지금 어떤 기준으로 찾는지”를 잊지 않게 했습니다.

- 회수(일괄 처리): 테이블 체크박스로 다건 선택 후 일괄 회수하도록 했고, 이미 사용된 쿠폰(status: 100)은 선택 불가로 막아서 ‘불가능한 작업’ 자체가 UI에서 안 일어나게 만들었습니다.

- 삭제(가드레일): 회수된 쿠폰(status: 99)만 삭제 가능하도록 정책을 걸었습니다. 즉 “삭제”는 단독 기능이 아니라 “회수 → 삭제”라는 워크플로우로 강제해서 데이터 무결성과 운영 안정성을 확보했습니다. 삭제 전 확인 다이얼로그로 실수 방지도 추가했습니다.

- 상태 모델링: 회수됨(status: 99)을 추가해서 쿠폰의 생명주기가 코드로도 명확히 보이도록 했고, 미구현 상태는 주석 처리/정리로 혼선을 줄였습니다.

2) 메시지 센터(카카오 알림톡/SMS·MMS/이메일) 필터 및 검색

- 목표: 운영자가 발송 내역을 “기간 + 상태”로 빠르게 좁히고, 수신자 정보(이름/전화/이메일)로도 바로 찾을 수 있게 하는 것이었습니다.

- 구현 포인트

- 공통 필터 설계: 3개 탭(카카오/SMS·MMS/이메일)이지만 필터 UX는 통일되게 가져가되, 탭별로 유효한 검색 필드만 활성화되게 구성했습니다.

- 날짜 필터: 발송일 기준으로 기본값을 넉넉하게 잡고(예: 2025-01-01~오늘), 전체/오늘/이번주/이번달/지난 7일/지난 30일 같은 프리셋을 제공해 운영자가 반복 작업을 빠르게 하게 했습니다.

- 검색 필드: 수신자/전화번호/이메일로 검색이 가능하도록 했고, 리스트 컬럼에도 분류/수신자/전화/이메일을 명시해서 “검색 결과가 왜 나왔는지”가 화면에서 설명되게 했습니다.

- 수신 실패 토글: 날짜 조건 안에서 실패 케이스만 모아 보는 토글을 추가해서, 운영 이슈 대응(실패 재처리/확인)이 빨라지도록 했습니다.

3) 이미지 관리 카테고리 분리 + 밀러컬럼 컴포넌트(탐색 UI) 구현

- 배경: 기존 이미지 관리 카테고리가 ‘상품코드 여행 지역’ 분류와 결합되어 있었는데, 이러면 이미지 분류 정책이 상품 정책에 종속되어 운영이 어려워집니다. 다만 기존 분류 DB는 보존해야 했고, 이후에 카테고리를 이동시킬 수 있어야 했습니다.

- 구현 포인트

- 데이터 전략: ‘기존 카테고리/DB는 유지’하면서, 이미지 관리 전용 카테고리 체계를 별도로 운영할 수 있게 분리했습니다(마이그레이션 강제 X, 점진적 이동 가능).

- UI 모드 2가지 제공

- 계층 구조(밀러컬럼): 폴더를 따라가며 탐색하는 구조로, 파일 정보 조회(이름/형태/생성/수정/위치), 파일명 수정, 삭제, 이동, 업로드까지 한 흐름에서 처리할 수 있게 했습니다.

- 테이블 구조: treeview UI로 전체 구조를 한눈에 보면서 이동/정리가 가능하도록 제공했습니다.

- 컴포넌트 설계: 탐색 UI 특성상 상태가 커지기 쉬워서 “선택 경로(컬럼 스택)”와 “선택된 노드/파일 리스트”를 분리해 관리하는 방향으로 설계했습니다.

4) 밀러컬럼 공용 컴포넌트 구현

- 핵심: 운영 데이터가 커졌을 때 클릭/선택/스크롤이 끊기지 않게 하는 쪽에 초점을 맞췄습니다.

- 개선 포인트(정리)

- 상태 범위를 줄이기 위해 컬럼 단위로 변경 영향도를 제한하고,

- 렌더링이 무거운 리스트는 메모이제이션과 key 설계를 조정해 불필요한 리렌더를 줄였습니다.

- 빈 상태/로딩 상태/에러 상태를 명확히 분리해 “현재 무슨 일이 일어나고 있는지”가 UI에서 설명되게 만들었습니다.

5) OAAS1 → OAAS2 항공 및 견적요청 관리 페이지 기능 구현

- 구현한 핵심 기능 중 하나는 ‘통합 검색(Full-Text Search) 로직’이었습니다.

- 구현 포인트

- 기존에는 특정 필드만 비교하는 방식이었다면, postId/title 같은 기본 정보 + 상세 JSON 전체를 문자열로 병합(JSON.stringify)해서 하나의 검색 타겟을 만들었습니다.

- 코드값으로 저장되지만 화면엔 한글 라벨로 보이는 값(진행상태/견적유형 등)도, 사용자가 입력하는 검색어와 매칭될 수 있도록 라벨 매핑을 포함시켰습니다.

- 최종적으로는 정규화(lowercase) 후 포함 여부로 필터링해, 비고/상세 일정 같은 “데이터 깊은 곳”도 누락 없이 찾을 수 있게 했습니다.

6) 고객센터 1:1 문의 ‘계층형 쓰레드’ 구조로 개편

- 목표: 기존에는 문의/답변이 평면적으로 보여 맥락 추적이 어렵고, 재문의가 쌓일수록 흐름이 끊기는 문제가 있었습니다.

- 구현 포인트

- 루트 질문을 ‘최상위 댓글 헤더’처럼 렌더링해서 전체 UI 톤을 통일했습니다.

- 질문 아래 답변들은 들여쓰기(pl) + left border로 물리적인 트리 구조가 화면에서 바로 인지되게 했습니다.

- 루트 질문 하단에 ‘답변 달기’ 버튼을 둬서, 질문에 답변을 다는 경험도 댓글 작성 UX와 동일하게 맞췄습니다.

- 파일 첨부도 대화 맥락에서 끊기지 않게, 질문 본문과 함께 묶어 보여주도록 정리했습니다.

7) 항공 견적 페이지 신청/관리 플로우 구현 및 고도화

- 핵심: 단순 CRUD 화면이 아니라, 역할(운영사 vs 판매점)에 따른 정책과, 운영자가 “많은 요청을 빠르게 처리”할 수 있는 UI가 동시에 필요했습니다.

- 구현 포인트

- 거대한 폼 분리: 수백 줄의 견적 폼을 기능 단위 컴포넌트로 분리(BasicInfo/Airline/Schedule/Remark 등)해서 변경 비용을 줄였습니다.

- RBAC(역할 기반 권한): 운영사만 댓글 작성/삭제가 가능하고, 판매점은 조회만 가능하도록 UI 레벨에서도 제약을 걸었습니다.

- 비밀 댓글(노출 제어): 운영사가 작성한 댓글 중 파트너 노출 여부에 따라 판매점 화면에서 민감 정보가 보이지 않도록 필터링 로직을 구성했습니다.

- 상태 동기화: 상세 Drawer에서 댓글을 작성/수정하면 리스트의 commentCount가 즉시 반영되게 해서, 사용자가 “저장됐나?”를 의심하지 않게 만들었습니다.

- 전역 상태(zustand): 목록 로딩 시 메타 데이터(조회수/댓글수/리액션 등)를 파싱해 객체에 주입하는 전처리 로직을 확장해 데이터 처리 흐름을 정리했습니다.

- 트러블슈팅: 기타 요청사항(remark)의 글자 수를 댓글 수로 잘못 표기하던 오류를 찾아 실제 commentCount 도메인 데이터를 사용하도록 수정했습니다.

8) 디자인 에디터 템플릿/페이지별 백업 및 버전 관리

- 목표: 페이지/위젯 단위로 “현재 버전 저장 → 기록 확인 → 복구 → 서버 즉시 저장”이 안정적으로 이어지는 버전관리 워크플로우를 만드는 것이었습니다.

- 구현 포인트

- 타입 안정성: any를 제거하고 인터페이스를 명확히 해서 런타임 오류 가능성을 줄였습니다.

- KST 파일명: toISOString() 기반 파일명은 날짜가 어긋날 수 있어, 로컬 시간 기준으로 파일명을 만들도록 수정했습니다.

- 경로 안전성: 다운로드/삭제 요청에 encodeURIComponent를 적용해 특수문자/슬래시가 있어도 안정적으로 동작하게 했습니다.

- 백업 전략 이원화

- 페이지 백업: 레이아웃/메타 포함 전체 JSON 백업

- 위젯 백업: HTML/CSS/JS 등 핵심 설정만 추출해 순수 데이터로 백업

- Re-wrap: 위젯 복구 시 백업된 순수 데이터를 현재 위젯 객체 구조로 다시 감싸 데이터 깨짐을 방지했습니다.

- 저장 버튼 활성화: 버전 불러온 직후 저장 버튼이 비활성화되어 새로고침 시 데이터가 휘발되는 문제를, “복구 직후 즉시 저장 가능”하도록 UX/로직을 보완했습니다.

9) 판매점 전용 홈페이지 디자인 GNB 생성/관리 기능

- 목표: ‘저장 안 됨’ 같은 운영 이슈를 줄이고, 설정 토글/저장 흐름이 예측 가능하게 만드는 것이었습니다.

- 구현 포인트

- 토글 버그 수정: 홈페이지 사용 O/X가 X로 바꿔도 다시 O로 돌아오는 문제는 상태/저장 로직이 두 단계로 분리되면서 레이스/덮어쓰기 위험이 있었고, 이를 단일 핸들러로 통합해 한 번의 흐름으로 끝나게 만들었습니다.

- 서버 데이터 정규화: SITE.homepage가 "false" 같은 문자열로 올 때도 정확히 boolean으로 해석하도록 유틸(getHomepageUseFlag)을 추가했습니다.

- GNB 저장 이슈 보완: 템플릿 없이 GnbManageForm을 재사용할 때 diff 기준이 없어 저장 흐름이 깨지는 케이스가 있어, compareGnb 옵션을 추가해 기준 데이터가 없을 때도 diff를 만들 수 있게 보완했습니다.

- 검증: 린트 에러 없이 정리했고, 프로덕션 빌드까지 확인했습니다.

한달이 지난 고졸 신입개발자의 주간 회고 (설 연휴 맞이!)

낭만알파카 — Fri, 13 Feb 2026 17:56:25 +0900

[회고] 운영과 신규 개발 사이에서 균형 잡기: 2월 1~2주 차 개발 일지

2026년 2월 2일부터 13일까지, 주식회사 오예커뮤니케이션 플랫폼개발실에서의 2주는 운영 이슈 대응부터 내부 리뉴얼, 컴포넌트 고도화까지 업무 범위가 상당히 넓었습니다. 아직 배워야 할 것이 많지만, 작은 수정 하나가 사용자 경험과 서비스 신뢰도에 어떻게 연결되는지 실전에서 체감할 수 있었던 기간이었습니다.

1. 운영 이슈는 ‘작아 보여도’ 결코 작지 않았다

이번 기간에는 UI 변경, CSS 조정, 번역 문제, 템플릿 노출 오류 같은 운영성 이슈를 꾸준히 처리했습니다. 겉보기에는 라인 색상 변경이나 문구 수정 같은 단순한 작업처럼 보이지만, 실제 운영 환경에서는 곧바로 고객 문의로 이어지거나 서비스의 전체적인 신뢰도에 영향을 주는 요소들이었습니다.

단순히 빠르게 고치는 것에 급급하기보다, 먼저 재현 가능한 시나리오를 확보하는 데 집중했습니다. 재현이 된 이후에는 UI 로직, 데이터 흐름, 권한 및 상태값, 캐시 여부 등을 층별로 분리하여 원인을 파악했습니다. 같은 문제가 반복되지 않도록 발생 원인을 정리해 두는 습관이 결국 장기적으로 시간을 아끼는 길이라는 점을 배웠습니다.

2. UX 개선과 기능 개발은 결국 같은 목표를 향한다

사용 편의를 높이기 위한 작은 기능 개선 요청들을 여럿 수행했습니다. 예를 들어 상담 완료 화면에서 특정 정보를 즉시 복사할 수 있게 하는 기능처럼, 기능 자체는 작아도 실제 업무의 뎁스를 줄여주고 실수를 예방하는 작업들이었습니다.

특히 인쇄 출력 화면 관련 요청을 처리하며 느낀 점이 많습니다. 화면 UI와 달리 출력물은 인쇄된 결과가 최종 산출물이기에 레이아웃의 안정성이 무엇보다 중요했습니다. 작은 스타일 수정이 줄바꿈이나 가독성에 큰 영향을 줄 수 있으므로, 요구사항의 범위를 명확히 확인하고 영향 범위를 최소화하는 방식으로 접근했습니다.

3. 프론트-백 연동 이슈에서 배운 ‘상태는 약속’이라는 감각

예약 상태가 조건에 따라 자동 변경되는 기능처럼, 프론트와 백엔드의 상태 로직이 밀접하게 얽힌 작업을 진행했습니다. 이 과정에서 상태값은 단순히 화면에 보이는 텍스트가 아니라, 양측이 데이터를 어떻게 해석할지에 대한 '약속'이라는 점을 깊이 이해하게 되었습니다.

상태 관련 기능은 예외 케이스가 늘어날수록 암묵적인 규칙이 많아지기 쉽습니다. 이를 방지하기 위해 가능한 한 조건을 읽기 쉬운 형태로 정리하고, 화면의 상태와 서버의 데이터가 어긋나지 않도록 검증했습니다. 사전에 QA 시나리오를 최소한이라도 잡아두는 것이 추후 리소스를 크게 절감해 준다는 실무적인 교훈도 얻었습니다.

4. 컴포넌트 개발: 밀러 컬럼 구현과 고도화

기술적으로 가장 비중이 컸던 작업은 밀러 컬럼(Miller Column) 형태의 컴포넌트 구현 및 고도화였습니다. 단순히 보기 좋은 UI를 만드는 것을 넘어, 사용자가 실제로 탐색하고 선택하는 흐름에 맞춰 상호작용을 설계하는 과정이 핵심이었습니다.

선택 상태 동기화, 하위 컬럼 갱신, 스크롤 및 포커스 제어, 로딩과 에러 상태 처리 등이 유기적으로 맞물려야 했기에 '동작' 이상의 완성도가 필요했습니다. 시행착오를 거치며 기능을 완성해가는 과정에서, 컴포넌트를 일반화하고 재사용 가능하게 다듬는 프론트엔드 개발자로서의 즐거움을 느낄 수 있었습니다.

5. 내부 작업: 홈페이지 리뉴얼과 AI 디자인 어시스턴트 적용

내부 프로젝트로는 홈페이지 리뉴얼(메인 화면, 반응형 적용, GNB 설정 등) 작업을 지속했습니다. 리뉴얼은 운영 대응과 달리 초기 구조를 잡는 성격이 강해, 이후의 유지보수를 고려하여 레이아웃과 스타일 구조를 최대한 단정하게 가져가려 노력했습니다.

또한 여러 위젯에 AI 디자인 어시스턴트를 적용하는 업무도 병행했습니다. 각 위젯마다 구조와 데이터 흐름이 다르기 때문에, 빠르게 맥락을 파악하고 안전하게 반영하는 역량이 요구되었습니다. 일정이 타이트할수록 영향 범위 파악과 커밋 단위 준수 같은 기본기를 지키는 것이 가장 빠른 길임을 다시 한번 상기했습니다.

6. 배포와 코드 리뷰: 개발은 코드로 끝나지 않는다

주간 프로덕션 배포와 이슈 대응, 코드 리뷰 피드백 반영을 거치며 개발의 범위가 단순히 코드를 작성하는 것에 그치지 않음을 배웠습니다. 코드가 실제 서비스에 안전하게 반영되고 운영되는 순간까지가 개발자의 책임 영역임을 선명하게 이해하게 되었습니다.

특히 코드 리뷰 피드백을 반영할 때는 지적된 부분만 수정하는 데 그치지 않고, 팀이 지향하는 기준과 그 근거를 이해하려 노력했습니다. 이러한 과정을 통해 팀의 컨벤션을 체화하는 속도를 높여가고 있습니다.

마무리하며: 빠르게 처리하되, 천천히 단단해지기

지난 2주를 돌아보면, 다양한 요구사항을 신속하게 처리하면서도 시스템의 안정성을 해치지 않는 균형점에 대해 끊임없이 고민했던 것 같습니다. 아직은 배워야 할 점이 훨씬 많지만, 실전에서의 경험들이 쌓이면서 개발자로서의 감각이 조금씩 자리 잡고 있음을 느낀 기간이었습니다.

향후 개선 방향:

수정 속도뿐 아니라 재발 방지를 고려한 원인 분석 및 정리
상태와 정책이 복잡하게 얽힌 기능에서의 예외 케이스 설계 능력 강화
UX와 유지보수성을 동시에 확보하는 컴포넌트 작성 습관
리뷰와 배포 과정에서 팀의 기준을 더 기민하게 흡수

다음 주도 겸손하게 배우며, 조금씩 더 단단한 개발자로 성장해 나가겠습니다.

다들 설 연휴 잘 보내세요..!!

신입 개발자의 입사 4주차 회고

낭만알파카 — Fri, 30 Jan 2026 17:42:39 +0900

입사 4주차(1월 26일~30일)를 회고합니다.

이번 주는 29일 회사 자체 상품인 중국인들을 위한 의료 관광 플랫폼 한성미 서비스 운영 시작을 앞두고 정말 바쁜 한 주였습니다. QA를 진행하며 시술 안내 세부페이지 퍼블리싱 작업을 다수 진행했고, 내부 UX 기능 개선도 병행했습니다. 특히 이번 주에는 소켓 통신을 활용한 실시간 동기화와 백엔드 API 개발까지 경험하며 풀스택에 한 걸음 더 다가간 한 주였습니다.

주요 작업 요약

이번 주는 한성미 서비스 런칭 준비, 기술적 복잡도가 높은 기능 개발, 내부 시스템 개선 세 가지 축으로 업무가 진행되었습니다.

서비스 런칭 준비 (한성미 의료관광)

시술 안내 세부페이지 퍼블리싱 (한글/중문) 다수
- 모발이식 절개/비절개, 눈밑 지방 재배치, 이중턱 지방흡입, 레이저제모 등
자주 묻는 질문 섹션 구축[1]
환율 정보 표시 (위엔화)[2]
이용약관/개인정보처리방침 모달
의사 소개 영역 퍼블리싱 (20개 게시물)

기술적 복잡도가 높은 기능

쿠폰 관리 시스템 (프론트엔드 + 백엔드)[3]
메시지 센터 필터/검색 (프론트엔드 + 백엔드)[4]
실시간 예약 정보 동기화 (소켓 통신)[5]

내부 UX 개선

위챗 상담 정보 복사 기능[6]
웹 회원 엑셀 다운로드[7]
메시지 센터 날짜 필터 개선[8]

기술적 깨달음

1. 소켓 통신과 실시간 동기화의 복잡성

이번 주 가장 기술적으로 흥미로웠던 작업은 판매점 예약관리 Drawer에서 실시간 업데이트 감지[5] 기능이었습니다.

문제 상황

여러 관리자가 동시에 같은 예약을 조회하고 수정할 때, A가 수정한 내용을 B가 모르고 덮어쓰는 문제가 발생할 수 있습니다. 특히 Drawer(사이드 패널)를 열어둔 상태에서는 다른 곳의 변경사항을 알 수 없었죠.

해결 방법: 소켓 기반 실시간 감지

서버에서 onTourReserveUpdate 소켓 이벤트를 브로드캐스트하면, 모든 연결된 클라이언트가 이를 수신합니다. 하지만 여기서 까다로운 점이 있었습니다.

내가 수정한 경우 vs 타인이 수정한 경우를 구분해야 한다는 것.

[예시코드]

// 의사 코드
const lastSaveTime = useRef<number>(0);

// 저장 시
const doSaveAction = async () => {
  await axios.put('/api/reserve', data);
  lastSaveTime.current = Date.now(); // 저장 시점 기록
};

// 소켓 수신 시
socket.on('onTourReserveUpdate', (data) => {
  const isMyUpdate = data.oxuid === profile.browserUid;
  const isRecent = Date.now() - lastSaveTime.current < 2000;
  
  if (isMyUpdate && isRecent) {
    // 내가 방금 저장한 거니까 무시
    console.log('[Socket] Skip fetch...');
    return;
  }
  
  // 타인이 수정했거나, 내가 다른 탭에서 수정한 경우
  if (confirm('다른곳에서 예약정보가 수정되었습니다. 최신정보로 조회하시겠습니까?')) {
    refreshData(); // 최신 데이터 다시 불러오기
  }
});

핵심 로직

내가 저장한 직후 (2초 이내): 내 browserUid가 소켓 데이터와 일치하고, 저장한 지 2초 이내면 무시
타인이 수정한 경우: Confirm 다이얼로그로 사용자에게 알리고 선택 받기
내가 다른 탭에서 수정한 경우: browserUid는 같지만 lastSaveTime이 갱신되지 않았으므로 자동으로 최신 데이터 반영

배운 점

browserUid의 활용: 각 브라우저 세션마다 고유 ID를 부여하면 "누가 수정했는지" 구분 가능
시간 기반 필터링: lastSaveTime을 활용해 "내가 방금 저장한 액션"인지 판단
사용자 경험 고려: 내 액션은 조용히 무시하고, 타인의 액션만 알림
멀티 탭 처리: 같은 사용자가 여러 탭을 열었을 때도 자연스럽게 동기화

이 작업을 통해 실시간 협업 시스템에서 충돌을 방지하는 패턴을 배웠습니다. 단순히 소켓으로 데이터를 받는 것을 넘어서, "누구의 액션인지", "언제 발생한 액션인지"를 구분하는 로직이 핵심이었습니다.

2. 프론트엔드에서 백엔드까지: 쿠폰 관리 시스템

쿠폰 관리 시스템[3] 작업은 이번 주 가장 복잡하고 완성도가 높았던 작업이었습니다. 프론트엔드뿐만 아니라 백엔드 API도 직접 구현했습니다.

요구사항

검색 기능: 전체/ID/쿠폰코드/쿠폰명/할인가격/주문최소금액/사용방식/메모/생성일/상태 중 선택 검색
쿠폰 회수 기능: 체크박스로 여러 쿠폰 선택 후 일괄 회수 (사용된 쿠폰은 제외)
쿠폰 삭제 기능: 회수된 쿠폰만 삭제 가능
상태 관리: 발급 → 사용됨(100) / 회수됨(99) → 삭제

프론트엔드 구현

// 필터 드롭다운 + 검색바
<Select value={searchField} onChange={setSearchField}>
  <MenuItem value="all">전체</MenuItem>
  <MenuItem value="id">ID</MenuItem>
  <MenuItem value="code">쿠폰코드</MenuItem>
  // ... 기타 필드
</Select>
<TextField 
  placeholder={getPlaceholder(searchField)} // 선택한 필드에 따라 동적 변경
  onKeyDown={handleEnter}
/>

동적 Placeholder가 인상적이었습니다. 사용자가 "쿠폰코드"를 선택하면 "쿠폰코드를 입력하세요", "생성일"을 선택하면 "YYYY-MM-DD 형식으로 입력하세요" 같은 식으로 힌트가 바뀝니다.

백엔드 구현

백엔드에서는 동적 쿼리를 구현해야 했습니다.

// 의사 코드
const searchCoupons = async (field: string, keyword: string) => {
  let query = 'SELECT * FROM coupons WHERE 1=1';
  const params: any[] = [];
  
  if (field === 'all') {
    // 모든 필드에서 검색
    query += ` AND (code LIKE ? OR name LIKE ? OR memo LIKE ?)`;
    params.push(`%${keyword}%`, `%${keyword}%`, `%${keyword}%`);
  } else if (field === 'status') {
    // 상태는 정확히 일치
    query += ` AND status = ?`;
    params.push(keyword);
  } else {
    // 특정 필드에서만 검색
    query += ` AND ${field} LIKE ?`;
    params.push(`%${keyword}%`);
  }
  
  return await db.query(query, params);
};

배운 점

동적 쿼리 작성: 사용자가 선택한 필드에 따라 쿼리를 동적으로 생성
SQL Injection 방지: Prepared Statement(Parameterized Query) 사용
상태 머신 설계: 발급 → 회수 → 삭제 순서를 강제해서 데이터 무결성 보장
UI 피드백: 회수 모드에서는 사용된 쿠폰을 비활성화해서 실수 방지
확인 다이얼로그: 삭제 같은 위험한 액션은 반드시 확인 절차 추가

처음으로 프론트엔드와 백엔드를 모두 구현해보니, API 설계가 프론트엔드 구현에 얼마나 큰 영향을 주는지 체감했습니다. 좋은 API는 프론트엔드 코드를 간결하게 만들고, 나쁜 API는 프론트엔드에서 복잡한 가공 로직을 요구합니다.

3. 메시지 센터: 복잡한 필터링과 검색

메시지 센터[4][8] 작업도 백엔드 API 구현이 포함된 작업이었습니다.

요구사항

카카오 알림톡, SMS/MMS, 이메일 3가지 탭
날짜 필터: 전체/오늘/이번주/이번달/지난 7일/지난 30일
검색 필드: 수신자명, 전화번호, 이메일
수신 실패 토글: 실패한 메시지만 필터링

기술적 도전

날짜 필터와 검색, 토글이 조합되어야 한다는 점이 까다로웠습니다.

// 의사 코드
const filters = {
  dateRange: { start: '2026-01-01', end: '2026-01-30' },
  searchField: 'receiver',
  searchKeyword: '홍길동',
  failedOnly: true
};

// 백엔드에서 조합된 쿼리 생성
SELECT * FROM messages 
WHERE sent_date BETWEEN ? AND ?
AND receiver LIKE ?
AND status = 'failed';

특히 날짜 필터 버튼의 상태 관리가 흥미로웠습니다.

필터 버튼 클릭: 해당 버튼 활성화 표시
달력으로 직접 수정: 모든 버튼 비활성화 (커스텀 날짜이므로)
스위치 토글: 즉시 검색 실행 (별도 검색 버튼 클릭 불필요)

배운 점

복합 필터 설계: 여러 조건이 AND로 결합되는 구조
UI 상태 동기화: 날짜를 바꾸면 필터 버튼 상태도 함께 업데이트
즉시 반영 vs 버튼 클릭: 토글은 즉시 반영, 텍스트 검색은 Enter 키나 버튼 클릭
기본값 설정: "전체" 날짜가 기본값이지만, 성능을 위해 실제로는 합리적인 범위(예: 최근 3개월)를 쿼리

4. 다국어 환경에서의 조건부 렌더링

위엔화 환율 표시[2] 작업은 간단해 보였지만 의외로 고려할 점이 많았습니다.

요구사항

중국어 언어 설정인 경우에만 위엔화 표시
KRW 위에 표시
원화와 동일하게 끝에 ~ (물결) 표기
color: #666, font-weight: 500

// 의사 코드
const PriceDisplay = ({ priceKRW }) => {
  const { language } = useLanguage();
  const priceYuan = convertToYuan(priceKRW);
  
  return (
    <div>
      {language === 'zh' && (
        <div style= color: '#666', fontWeight: 500 >
          ¥{priceYuan.toLocaleString()}~
        </div>
      )}
      <div>
        ₩{priceKRW.toLocaleString()}~
      </div>
    </div>
  );
};

기술적 고려사항

환율 계산: 실시간 환율 API를 사용할지, 고정 환율을 사용할지
표시 순서: 위엔화를 위에 둘지 아래 둘지 (중국 사용자 입장에서는 위엔화가 더 친숙)
스타일 일관성: 원화와 같은 포맷팅(천 단위 콤마, 물결 표시)
조건부 렌더링: 한국어 사용자에게는 불필요한 정보이므로 렌더링 자체를 안 함

배운 점

현지화(Localization)는 단순 번역이 아님: 가격 표시 방식, 통화 단위, 문화적 맥락까지 고려
조건부 렌더링 최적화: {condition && <Component />} 패턴으로 불필요한 DOM 생성 방지
사용자 입장에서 생각하기: 중국 고객은 위엔화로 환산해서 "대략 얼마인지" 파악하고 싶어 함

5. 동적 콘텐츠 렌더링: 자주 묻는 질문

자주 묻는 질문 영역[1] 구축은 관리자 편의성과 사용자 경험을 모두 고려해야 했습니다.

구조

관리자가 게시글 ID만 입력하면, 해당 게시글을 하단 고정 영역에 자동으로 렌더링합니다.

// 의사 코드
const FAQSection = ({ pinnedPostIds }) => {
  const [faqs, setFaqs] = useState([]);
  
  useEffect(() => {
    // 관리자가 입력한 ID 목록으로 게시글 조회
    const fetchFAQs = async () => {
      const posts = await Promise.all(
        pinnedPostIds.map(id => fetchPost(id))
      );
      setFaqs(posts);
    };
    fetchFAQs();
  }, [pinnedPostIds]);
  
  return (
    <div className="faq-section">
      {faqs.map(post => (
        <FAQItem key={post.id} title={post.title} content={post.content} />
      ))}
    </div>
  );
};

배운 점

관리자 친화적 설계: 새 FAQ를 추가하려면 게시글을 작성하고 ID만 입력하면 됨 (별도 UI 개발 불필요)
동적 로딩: ID 목록이 바뀌면 자동으로 해당 게시글들을 불러와서 렌더링
확장성: 나중에 FAQ가 100개가 되어도 시스템 변경 없이 ID만 추가하면 됨
재사용성: 일반 게시글 시스템을 활용하므로 에디터, 이미지 업로드 등의 기능을 그대로 사용 가능

이 패턴은 **"기존 시스템을 영리하게 재활용"**하는 좋은 예시였습니다. 새로운 시스템을 만드는 것보다, 기존 게시판 시스템을 활용해서 특정 게시글을 특별하게 표시하는 방식이 훨씬 효율적이었습니다.

6. 퍼블리싱 작업에서 배운 일관성의 중요성

이번 주에 시술 안내 세부페이지를 정말 많이 만들었습니다. 모발이식 절개/비절개, 눈밑 지방 재배치, 이중턱 지방흡입, 레이저제모 등등...

처음 3~4개를 만들 때까지는 각 페이지마다 조금씩 다른 스타일을 적용했는데, 나중에 보니 일관성이 없어서 어색했습니다.

개선 과정

컴포넌트 분리: 반복되는 섹션(시술 과정, 주의사항 등)을 컴포넌트로 분리
스타일 시스템 정리: 제목 크기, 간격, 색상 등을 변수로 관리
레이아웃 템플릿: 기본 레이아웃 구조를 템플릿으로 만들고 내용만 바꾸기

// Before: 각 페이지마다 하드코딩
<h2 style= fontSize: '28px', marginBottom: '16px' >시술 과정</h2>

// After: 공통 컴포넌트 사용
<SectionTitle>시술 과정</SectionTitle>

배운 점

반복 작업에서 패턴 찾기: 비슷한 작업을 3번 이상 하면 공통 패턴을 추출해야 함
디자인 시스템의 필요성: 제목, 본문, 버튼 등의 스타일을 미리 정의해두면 일관성 유지가 쉬움
템플릿 기반 개발: 구조는 같고 내용만 다른 페이지는 템플릿으로 만들어서 재사용

특히 한글/중문 페이지를 동시에 만들 때, 컴포넌트 구조가 같으면 번역 작업이 훨씬 수월했습니다.

아쉬웠던 점

1. 소켓 에러 처리 부족

소켓 통신 구현은 성공했지만, 연결이 끊어졌을 때의 처리가 부족했습니다. 네트워크가 불안정하거나 서버 재시작 시 자동으로 재연결하는 로직이 필요할 것 같습니다.

// 아직 구현 안 한 부분
socket.on('disconnect', () => {
  // 재연결 시도?
  // 사용자에게 알림?
});

2. 백엔드 테스트 부족

백엔드 API를 직접 구현했지만, 단위 테스트를 작성하지 못했습니다. 프론트에서 수동으로 테스트했지만, 엣지 케이스(빈 문자열, SQL Injection 시도 등)를 체계적으로 테스트하지 못한 게 아쉽습니다.

3. 퍼블리싱 초반의 시행착오

퍼블리싱 작업 초반에 컴포넌트화와 일관성을 고려하지 않고 진행해서, 나중에 리팩토링 시간이 추가로 들었습니다. 처음부터 패턴을 고민했으면 더 효율적이었을 것 같습니다.

느낀 점

풀스택 개발의 매력

이번 주에 프론트엔드와 백엔드를 모두 구현해보면서, 전체 데이터 흐름을 이해하니 훨씬 더 좋은 설계를 할 수 있다는 걸 느꼈습니다.

프론트만 할 때는 "API가 이 데이터를 주면 좋겠는데..."라고 바라기만 했다면, 이제는 "이렇게 API를 설계하면 프론트에서 쓰기 편할 거야"라고 직접 만들 수 있게 되었습니다.

물론 아직 백엔드 지식이 부족하지만, 전체 시스템을 이해하려는 노력이 결국 더 나은 개발자가 되는 길이라고 생각합니다.

실시간 기능의 복잡성

소켓 통신을 구현하면서, 실시간 기능이 단순히 "빠른 것"이 아니라 "동기화 문제"를 해결하는 것임을 배웠습니다.

누가 수정했는지
언제 수정했는지
내가 보고 있는 데이터가 최신인지
충돌이 발생하면 어떻게 해결할지

이런 문제들을 하나씩 해결해가는 과정이 어려웠지만, 매우 재미있었습니다.

서비스 런칭의 긴장감

29일 한성미 서비스 운영 시작을 앞두고, 실제 사용자가 쓸 서비스를 만든다는 긴장감을 느꼈습니다.

퍼블리싱 하나하나가 "중국 고객이 실제로 볼 페이지"이고, 환율 계산이 틀리면 "실제 예약에 영향을 줄 수 있다"는 생각에 더 신중해졌습니다.

테스트할 때도 "내가 고객이라면 이 페이지를 보고 예약하고 싶을까?"를 계속 생각했습니다. 단순히 "작동하는 코드"가 아니라 "사람들이 실제로 사용할 서비스"를 만든다는 것의 무게감을 느낀 한 주였습니다.

반복 작업에서 효율을 찾는 법

퍼블리싱 작업을 많이 하면서, 반복 작업을 효율화하는 패턴을 배웠습니다.

처음 1~2개: 천천히 만들면서 패턴 파악
3~4개부터: 반복되는 부분을 컴포넌트로 분리
5개 이상: 템플릿 기반으로 빠르게 작업

이런 과정을 거치면서, "일을 열심히 하는 것"과 "일을 똑똑하게 하는 것"의 차이를 배웠습니다.

다음 주 목표

소켓 통신 고도화: 재연결 로직, 에러 처리 학습
백엔드 테스트: Jest나 다른 테스팅 프레임워크로 API 테스트 작성법 공부
디자인 시스템 제안: 팀 차원에서 공통 컴포넌트/스타일 정리 필요성 논의
한성미 서비스 피드백 수집: 실제 운영 후 개선사항 파악

입사 4주차를 마무리하며, 이제는 단순히 "할당받은 작업을 완료하는 것"을 넘어서 "더 나은 구조는 무엇일까", "사용자 경험을 어떻게 개선할까"를 고민하게 되었습니다.

소켓 통신, 백엔드 개발, 서비스 런칭... 하나하나가 새로운 도전이었지만, 그만큼 많이 배우고 성장한 한 주였습니다. 다음 주에도 계속해서 기술적으로 깊이 있게 공부하며 발전하는 개발자가 되고 싶습니다!

개발자의 입사 3주차 회고

낭만알파카 — Fri, 30 Jan 2026 14:24:49 +0900

입사 3주차(1월 19일~23일)를 회고합니다. 이번 주는 UX 개선과 다국어 처리, 그리고 데이터 표현 방식에 대해 많이 고민했던 한 주였습니다. 여전히 배울 게 많지만, 작은 디테일 하나하나가 사용자 경험에 얼마나 큰 영향을 주는지 체감한 시간이었습니다.

주요 작업 요약

이번 주는 UX 개선과 다국어 처리, 데이터 표현 개선 세 가지 축으로 업무가 진행되었습니다.

기능 개발 및 UX 개선

BMS 상품 알림톡 요금 숨김 및 확정번호 표시[1]
카테고리 탭 이동 애니메이션 적용[2]
일정표 에디터 링크/아이콘 삽입 기능 추가[3]
예약 현황 기본값을 '접수일'로 설정[4]

데이터 표현 개선

관리자 캘린더 수기 예약 시 성인/아동 수량 반영[5]
판매점 관리자 테이블에 성인/아동 별도 표기[6]

다국어 및 레이아웃

중국어 번역 미작동 텍스트 개선[7]
모아시스 가입인사 게시판 레이아웃 조정[8]
기타 다수의 CSS 및 반응형 작업

기술적 깨달음

1. 애니메이션이 UX에 미치는 영향

카테고리 탭 이동 애니메이션[2] 작업을 하면서 애니메이션의 중요성을 새삼 깨달았습니다.

처음에는 "탭 클릭하면 내용만 바뀌면 되는 거 아닌가?"라고 생각했는데, 실제로 좌우 슬라이드 애니메이션을 추가하니 사용자가 어디로 이동했는지 훨씬 명확하게 인지할 수 있더라고요.

// 단순 교체 vs 애니메이션이 있는 전환
// 1. 탭 A → 탭 B로 갑자기 바뀜 (어색함)
// 2. 탭 A → [슬라이드 애니메이션] → 탭 B (자연스러움)

이 작업을 통해 배운 점:

방향성의 중요성: 오른쪽 탭으로 가면 왼쪽에서 오른쪽으로, 왼쪽 탭으로 가면 오른쪽에서 왼쪽으로 슬라이드되어야 직관적
타이밍 함수: ease-in-out 같은 타이밍 함수가 자연스러운 움직임을 만듦
성능 고려: 애니메이션은 transform을 사용해야 부드럽고, left나 top 같은 속성은 성능이 안 좋음
과하지 않게: 애니메이션 시간이 너무 길면 오히려 답답함. 0.3초 정도가 적당한 것 같음

애니메이션은 단순한 장식이 아니라 사용자가 인터페이스를 이해하는 데 도움을 주는 기능적 요소라는 걸 배웠습니다.

2. 조건부 UI와 비즈니스 로직의 복잡성

BMS 상품 알림톡[1] 작업이 가장 복잡했습니다. 같은 알림톡 화면이지만 상품 유형에 따라 다르게 보여야 했거든요.

요구사항:

BMS 상품인 경우: 요금 안내 숨김, 확정 번호 표시
일반 상품인 경우: 요금 안내 표시, 확정 번호 숨김
확정 번호가 입력되지 않은 경우: 빈 값으로 표시

// 의사 코드
if (isBMS) {
  // 요금 안내 숨김
  if (confirmNumber) {
    // 확정 번호 표시
  } else {
    // 빈 입력란 표시
  }
} else {
  // 요금 안내 표시
}

처음에는 "그냥 조건문 하나면 되겠지"라고 생각했는데, 실제로는:

데이터 구조 파악: BMS 여부를 어떤 필드로 판단하는가?
중첩 조건 처리: BMS이면서 확정번호가 있는 경우, 없는 경우
레이아웃 유지: 요금 안내가 숨겨져도 레이아웃이 깨지지 않게
폰트 스타일 일관성: 확정번호 텍스트가 다른 정보와 일관된 스타일을 유지

이 과정에서 배운 점:

조건의 우선순위: 어떤 조건을 먼저 체크해야 할지 순서가 중요함
엣지 케이스: "BMS인데 확정번호가 null이면?", "빈 문자열이면?" 같은 경우들을 미리 고려해야 함
유지보수성: 조건이 복잡하면 주석이나 별도 함수로 분리하는 게 나중을 위해 좋음

3. 데이터 표현 방식의 중요성

이번 주에 성인/아동 수량을 분리해서 표기하는 작업을 두 곳에서 했습니다.

관리자 캘린더[5]에서는 수기로 예약을 추가할 때 총 인원은 맞지만 성인/아동 구분이 안 되는 버그가 있었고, 판매점 관리자 테이블[6]에서는 아예 성인/아동 구분 없이 총 인원만 표시되고 있었습니다.

// Before: 총 5명
// After: 성인 3명 / 아동 2명

단순해 보이지만 실제로는:

데이터 구조 이해: 백엔드에서 adultCount, childCount를 따로 내려주는지, 아니면 계산해야 하는지
기본값 처리: 아동이 0명일 때 어떻게 표시할지 ("성인 3명" vs "성인 3명 / 아동 0명")
레이아웃 조정: 한 줄에 표시할지, 두 줄에 표시할지
일관성: 여러 화면에서 같은 정보를 다루는데, 표현 방식이 일관되어야 함

이 작업을 통해 같은 데이터라도 어떻게 표현하느냐에 따라 사용자가 받는 정보의 질이 완전히 달라진다는 걸 배웠습니다. 관리자가 "오늘 어린이 3명 예약이 있네"라고 빠르게 파악할 수 있으려면, 데이터를 명확하게 구분해서 보여줘야 합니다.

4. 기본값의 힘

예약 현황 기본값을 '접수일'로 설정[4]하는 작업은 코드로는 몇 줄 안 되는 간단한 작업이었습니다.

// 기본 정렬 기준을 '접수일'로 변경
defaultSort: 'receiptDate'

하지만 이 작은 변경이 판매점 관리자의 업무 효율에는 큰 영향을 줍니다.

Before: 페이지 열 때마다 정렬 기준을 '접수일'로 바꿔야 함

After: 페이지 열면 바로 최신 접수 순으로 정렬되어 있음

이 작업에서 배운 점:

사용자 워크플로우 이해: 판매점 관리자는 "오늘 들어온 예약"을 가장 먼저 확인함
마찰 최소화: 매번 클릭 한 번을 줄이는 것만으로도 사용자 경험이 개선됨
적절한 기본값: 80%의 사용자가 원하는 설정을 기본값으로 해야 함

"기본값 하나 바꾸는 게 뭐 대수냐"고 생각할 수 있지만, 좋은 기본값은 사용자가 의식하지 못하는 사이에 편의를 제공합니다.

5. 다국어 처리의 까다로움

중국어 번역 미작동 텍스트[7] 개선 작업을 하면서, 다국어 처리가 단순히 "텍스트만 바꾸면 되는 거"가 아니라는 걸 다시 한번 느꼈습니다.

문제가 발생한 부분들:

모달 메시지 ("닫으시겠습니까?", "신청하시겠습니까?")
개인정보 동의 항목
페이지 위젯 명칭
위챗 ID 복사 영역
병원명 및 주소

발견한 패턴:

하드코딩된 텍스트: 번역 함수를 거치지 않고 직접 한글로 작성된 부분들
조건부 번역: 특정 조건에서만 번역이 안 되는 경우
동적 텍스트: API에서 받아온 텍스트가 번역되지 않는 경우

이 과정에서 배운 점:

번역 키 관리: 모든 사용자 대면 텍스트는 번역 키로 관리해야 함
테스트의 중요성: 언어를 바꿔가며 모든 화면을 확인해봐야 누락된 부분을 발견할 수 있음
일관성: 같은 의미의 텍스트는 같은 번역 키를 사용해야 일관성 유지

다국어 처리는 처음부터 설계되어야 하는 부분이고, 나중에 추가하려면 많은 부분을 수정해야 한다는 걸 배웠습니다.

6. 에디터 커스터마이징

일정표 에디터에 링크/아이콘 삽입 기능 추가[3] 작업을 하면서, 라이브러리를 "있는 그대로 쓰는 것"과 "필요에 맞게 확장하는 것"의 차이를 느꼈습니다.

요구사항은 간단했습니다:

에디터 툴바에 "링크 삽입" 버튼 추가
에디터 툴바에 "아이콘 삽입" 버튼 추가

하지만 실제로는:

에디터 API 이해: 툴바에 버튼을 추가하는 방법
이벤트 핸들링: 버튼 클릭 시 링크 입력 다이얼로그 표시
커서 위치: 현재 커서 위치에 링크/아이콘 삽입
스타일 일관성: 새로 추가한 버튼이 기존 버튼들과 동일한 스타일을 유지

특히 커서 위치에 삽입하는 부분이 까다로웠습니다. 에디터의 내부 상태를 이해하고, 적절한 메서드를 찾아서 사용해야 했거든요.

이 작업을 통해:

라이브러리의 공식 문서를 꼼꼼히 읽는 것의 중요성
에디터 같은 복잡한 컴포넌트는 내부 동작 원리를 어느 정도 이해해야 커스터마이징이 가능함
작은 기능 추가도 에디터 전체의 동작에 영향을 줄 수 있으니 테스트가 중요함

을 배웠습니다.

아쉬웠던 점

1. 조건부 로직의 테스트 부족

BMS 알림톡 작업에서 "BMS인 경우"와 "아닌 경우"는 테스트했는데, "BMS인데 확정번호가 빈 문자열인 경우", "null인 경우" 등 세부적인 케이스를 충분히 테스트하지 못했습니다. 다행히 큰 문제는 없었지만, 좀 더 꼼꼼하게 엣지 케이스를 체크했어야 했습니다.

2. 애니메이션 성능 고려 부족

탭 애니메이션을 구현할 때 처음에는 left 속성을 사용했는데, 나중에 찾아보니 transform: translateX()를 쓰는 게 성능상 더 좋다는 걸 알았습니다. 다행히 바로 수정했지만, 처음부터 성능을 고려했으면 더 좋았을 것 같습니다.

3. 다국어 누락 체크리스트

중국어 번역 누락을 찾는 과정이 "눈으로 하나하나 확인"하는 방식이었습니다. 더 체계적으로 번역 누락을 찾을 수 있는 도구나 방법이 있는지 찾아보고 싶습니다. 예를 들어, 한글 텍스트를 자동으로 찾아주는 스크립트 같은 것 말이죠.

느낀 점

디테일이 만드는 차이

이번 주 작업들은 대부분 "작은 개선"들이었습니다. 탭에 애니메이션 추가, 성인/아동 구분 표시, 기본값 변경... 하나하나는 작아 보이지만, 이런 디테일들이 모여서 사용자가 느끼는 "완성도"를 만든다는 걸 배웠습니다.

애니메이션 하나가 "어디로 이동했는지" 명확하게 만들고
데이터 구분이 "얼마나 빨리 정보를 파악할 수 있는지" 결정하고
기본값 하나가 "매일 몇 번씩 하던 클릭"을 줄여주고

"대충 작동하는 기능"과 "잘 만들어진 기능"의 차이는 바로 이런 디테일에 있다는 걸 느꼈습니다.

사용자 입장에서 생각하는 연습

예약 현황 기본값을 바꾸는 작업을 하면서, "판매점 관리자는 어떤 순서로 일을 할까?"를 고민했습니다. 그들은 아침에 출근해서 "오늘 새로 들어온 예약"을 먼저 확인할 것이고, 그렇다면 접수일 순 정렬이 기본값이어야 합니다.

이렇게 사용자의 워크플로우를 상상해보는 것이 좋은 UX를 만드는 출발점이라는 걸 배웠습니다. 내가 편한 대로가 아니라, 사용자가 편한 대로 만들어야 한다는 것.

문제 해결 과정의 즐거움

중국어 번역 누락을 찾아서 하나하나 고치는 과정이 처음에는 지루할 줄 알았는데, 의외로 재미있었습니다. 마치 숨은 그림 찾기처럼 "여기도 한글이 남아있네", "이건 조건부로 번역이 안 되는 거였구나" 하며 패턴을 찾아가는 과정이 흥미로웠습니다.

버그를 찾고 고치는 것도 일종의 문제 해결이고, 그 과정 자체를 즐길 수 있다면 개발이 훨씬 즐거워지는 것 같습니다.

다음 주 목표

애니메이션 성능 학습: CSS 애니메이션 최적화 기법 공부하기
다국어 처리 베스트 프랙티스: 번역 누락을 방지하는 방법 찾아보기
엣지 케이스 체크리스트: 조건부 로직 구현 시 체크해야 할 항목 정리하기
사용자 관찰: 가능하다면 실제 사용자가 시스템을 어떻게 사용하는지 관찰해보기

3주차를 지나며, "작동하는 코드"를 넘어 "좋은 경험을 주는 코드"에 대해 고민하게 되었습니다.

아직 갈 길이 멀지만, 하나씩 배워가는 과정이 즐겁습니다. 다음 주에도 디테일에 집중하며 성장하는 한 주가 되었으면 좋겠습니다..!

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

낭만알파카 — Fri, 30 Jan 2026 14:15:57 +0900

입사 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 복사 기능도 "사용자가 한 번의 클릭으로 쉽게 복사할 수 있게"하기 위한 것
개인정보 동의 체크박스도 "사용자가 명확히 인지하고 동의할 수 있게"하기 위한 것

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

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

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

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

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

기록의 중요성

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

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

다음 주 목표

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

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

내가 개발한 페이지..!

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

낭만알파카 — Fri, 30 Jan 2026 14:06:07 +0900

들어가며

2026년 1월 5일, 자바스크립트 개발자로서의 첫 출근을 했다. 여행 관련 ERP와 사이트 빌더 기반의 B2B 서비스, 그리고 중국 의료관광 플랫폼을 개발하는 회사다. 신입 개발자로서의 첫 주는 어땠을까? 그 기록을 남겨본다.

Day 1: 입사 첫날 (1월 5일)

첫날은 주로 업무 인수인계와 환경 세팅에 집중했다.

회사 레포지토리 구조 파악

가장 먼저 한 일은 회사의 레포지토리 구조를 이해하는 것이었다. 사이트 빌더 기반의 시스템이라는 점이 흥미로웠다. 각 클라이언트마다 커스터마이징된 여행 사이트를 제공하는 구조였고, 공통 컴포넌트와 클라이언트별 커스터마이징이 어떻게 분리되어 있는지 파악하는 데 시간을 썼다.

페이지 개발 실습

백엔드 구조를 파악한 후, API CRUD 연습을 진행했다. 단순히 프론트엔드만 다루는 것이 아니라 백엔드까지 이해해야 한다는 점에서, 풀스택에 가까운 업무 환경임을 느꼈다. TypeScript와 React를 기반으로 한 프론트엔드 코드와, API 엔드포인트를 직접 만들어보며 전체적인 흐름을 익혔다.

주간 업무 회의

매주 월요일 오후 1시에 진행되는 주간 업무 회의에 참여했다. 팀원들이 진행 중인 작업과 이슈를 공유하는 시간이었고, 앞으로 내가 어떤 일들을 하게 될지 감을 잡을 수 있었다.

Day 2: Material UI 학습 (1월 6일)

회사에서는 Material UI를 주요 디자인 시스템으로 사용하고 있었다. 이전에 다른 UI 라이브러리를 사용해본 경험은 있었지만, Material UI는 처음이었다.

공식 문서를 읽으며 주요 컴포넌트들의 사용법을 익히고, 회사 코드베이스에서 실제로 어떻게 활용되고 있는지 확인했다. 특히 테마 커스터마이징과 반응형 디자인을 위한 Grid 시스템에 주목했다.

Day 3: 첫 실무 작업 (1월 7일)

드디어 실제 작업을 시작했다.

관리자 페이지: 모바일 메뉴 개선

중국 의료관광 플랫폼의 관리자 페이지에서, 하단 모바일 메뉴의 구조를 개선하는 작업이었다. 기존에는 아이콘과 텍스트가 하나의 이미지로 결합되어 있었는데, 이를 분리하여 각각 등록할 수 있도록 변경했다.

이 작업을 통해 회사의 CSS 작성 컨벤션과 컴포넌트 구조를 자연스럽게 익힐 수 있었다.

비즈니스 로직 파악

오후에는 사이트 빌더의 핵심 기능인 예약 관리와 상품 관리의 비즈니스 로직을 파악하는 데 집중했다. 여행 상품의 특성상 날짜, 인원, 옵션 등 복잡한 변수들이 많았고, 이를 어떻게 관리하고 있는지 코드를 따라가며 이해했다.

Day 4: 버그 수정과 UX 개선 (1월 8일)

버그 수정: GNB 그룹 추가 에러

GNB(Global Navigation Bar) 관리 페이지에서 사전 관리 메뉴의 그룹을 추가할 때 TypeError가 발생하는 이슈를 발견하고 수정했다.

에러의 원인은 예상치 못한 undefined 값이 처리되지 않았기 때문이었다. TypeScript를 사용하고 있었지만, 런타임에서 발생할 수 있는 예외 케이스를 방어적으로 처리하는 것의 중요성을 다시 한번 느꼈다.

// 에러가 발생하던 부분을 옵셔널 체이닝과 null 체크로 방어
if (data?.groups) {
  // 안전한 처리
}

UX 개선: 모바일 반응형

클라이언트 사이트 중 하나인 "기쁨"의 모바일 화면에서 본문 내용이 불필요하게 노출되는 문제를 수정했다. visibility: none을 적용하여 모바일 화면에서는 본문을 숨기도록 처리했다.

간단한 CSS 작업이었지만, 각 클라이언트마다 다른 요구사항을 어떻게 처리하는지 배울 수 있었다.

Day 5: 사용자 경험 개선 (1월 9일)

상담 신청 버튼 하단 고정

중국 의료관광 플랫폼의 상품 상세 페이지에서, 상담 신청 폼의 UX를 개선하는 작업을 진행했다.

주요 개선 사항:

상담 신청 버튼을 하단에 고정하여 접근성 향상
모바일 반응형 레이아웃 최적화
버튼 폰트 강조로 시각적 위계 개선
불필요한 스크롤바 제거 (컴포넌트와 CSS가 중복 적용되어 스크롤바가 2개 생기던 문제 해결)

이 작업에서 특히 인상 깊었던 점은, 단순히 디자인만 고치는 것이 아니라 사용자의 실제 행동 흐름을 고려해야 한다는 것이었다. 상담 신청은 전환율에 직결되는 핵심 액션이기 때문에, 버튼의 위치와 가시성이 매우 중요했다.

텍스트 조정

한성미 소개 페이지의 중문 버전에서 텍스트가 제대로 표시되지 않는 문제를 수정했다. 중국어 폰트와 레이아웃 관련 세밀한 조정이 필요했다.

첫 주를 마치며

배운 것들

1. 기술 스택

TypeScript + React 기반의 프론트엔드
Material UI를 활용한 컴포넌트 디자인
반응형 웹 디자인의 실무 적용
프론트엔드와 백엔드를 아우르는 풀스택 접근

2. 업무 프로세스

매주 월요일 오후 1시 주간 회의
화요일 오후 2시 스테이징 빌드 & 배포
업무 기록 데이터베이스를 통한 작업 추적

3. 도메인 지식

여행 ERP의 예약/상품 관리 로직
사이트 빌더 기반 B2B 서비스의 구조
중국 의료관광 플랫폼의 특수성 (중문 폰트, 다국어 처리 등)

느낀 점

신입 개발자로서 가장 크게 느낀 것은 코드를 읽는 능력의 중요성이었다. 새로운 코드베이스에서 길을 찾는 것은 마치 미로 탐험 같았다. 하지만 며칠간 코드를 따라가다 보니, 점차 전체적인 구조가 보이기 시작했다.

또한, 작은 작업도 소홀히 하지 않는 태도가 중요하다는 것을 배웠다. CSS 한 줄, 버그 하나라도 실제 사용자에게는 큰 영향을 미칠 수 있었다.

무엇보다 스스로 학습하고 문제를 해결하는 자세가 필요했다. Material UI 문서를 읽고, 에러 메시지를 분석하고, 코드를 디버깅하는 모든 과정이 성장의 기회였다.

다음 주 목표

더 복잡한 기능 구현에 도전하기
코드 리뷰를 통해 더 나은 코드 작성법 배우기
팀원들과의 협업 강화하기

첫 주를 무사히 마쳤다. 앞으로가 더욱 기대된다.