매달 KPT로 잘한 점과 아쉬운 점, 다음 액션을 기록합니다.
2026
05월
20개 항목
온보딩을 통해 서비스와 레포지토리의 전체 흐름을 파악하고 업무 이해도를 높였다.
레거시 코드를 단순히 오래된 코드로 판단하지 않고, 현재의 구조가 만들어진 배경과 맥락을 이해하려고 노력했다.
코드 중복을 무조건 줄이기보다 컴포넌트의 역할과 책임이 명확하게 드러나는 구조를 선택했다.
AI를 코드 생성뿐만 아니라 요구사항 분석, 문서화, 이슈 대응, 커밋과 PR 작성 등 다양한 업무에 활용했다.
팀의 불편함과 문제를 개선의 기회로 바라보고 적극적으로 의견을 나누려고 했다.
기존 코드를 그대로 받아들이기보다 왜 그렇게 작성되었는지, 현재도 적절한 선택인지 고민했다.
단기적으로는 서비스와 기술 스택을 이해하고, 장기적으로는 팀과 서비스 전체로 시야를 확장하려는 방향을 세웠다.
온보딩 초기에 새롭게 접한 기술과 서비스 구조를 연결해서 이해하는 데 시간이 필요했다.
레거시 코드와 여러 버전의 라이브러리를 처음 접했을 때 코드의 배경과 의도를 빠르게 파악하기 어려웠다.
기능을 구체적으로 정의하지 않은 상태에서 AI에게 구현을 요청해 재작업이 반복되었다.
캐시 정책이나 상태 관리처럼 설계가 필요한 부분에서도 AI가 제안한 구현을 그대로 참고하려는 경향이 있었다.
익숙하지 않은 영역에서는 기존 코드를 비판적으로 검토하기보다 그대로 받아들이는 경우가 있었다.
아직까지 서비스 전반의 도메인 및 기술 지식이 아직 부족하다고 느꼈다.
서비스의 주요 도메인과 페이지 흐름, 데이터 흐름을 문서화하고 지속적으로 업데이트한다.
AI에게 구현을 요청하기 전에 요구사항과 예외 상황, 상태 구조, 캐시 정책, 성능 기준을 먼저 정의한다.
효과가 있었던 프롬프트와 작업 절차를 AI skill과 rule로 정리하고 팀원들과 공유한다.
공통 컴포넌트에 prop을 추가하기 전에 컴포넌트의 역할이 유지되는지 검토하고, 역할이 달라지면 별도 컴포넌트로 분리한다.
구현 단계에서부터 번들 크기와 dynamic import, 코드 분할, 네트워크 요청 수를 점검하는 체크리스트를 적용한다.
성능을 개선할 때 번들 크기뿐만 아니라 네트워크 요청 증가와 초기 렌더링, SEO에 미치는 영향까지 함께 비교한다.
AI 활용 전후의 작업 시간과 재작업 횟수, 결과 품질을 측정해 실제 생산성 향상 여부를 확인한다.
2026
04월
14개 항목
지원을 마친 공고에만 집중하도록 범위를 좁혀 분산되지 않고 몰입했다.
새로운 개념을 쌓기보다 기존에 정리한 문서를 다시 살펴보며 개념 간 연결점을 찾는 방식으로 학습 방식을 바꿨다.
AI 초안을 노션에 옮기던 수작업과 n8n 이슈 트래커 파이프라인을 MCP로 연동해 반복 작업을 줄였다.
셀렉터 기반 자동화 대신 의도 단위로 테스트하는 방식을 Playwright와 AI로 새롭게 시도했다.
완벽하게 준비된 상태에서 시작하려던 관점에서, 부족함을 인정하고 부딪히며 성장하는 방향으로 관점을 바꿨다.
개념을 JavaScript, React, Browser 같은 카테고리 내부에서만 연결해 카테고리 경계를 넘는 통합적 이해에는 이르지 못했다.
코딩 테스트에서 초기 구현 단계의 사소한 실수를 바로잡는 데 예상보다 많은 시간을 썼다.
문제 발생 시 가설을 세우고 입출력 범위를 좁혀가며 원인을 추적하는 체계적인 디버깅 접근과 디버거 활용 습관이 부족했다.
스스로의 강점을 막연하게만 인식했을 뿐, 그 강점이 왜 강점인지와 어떤 성과로 이어지는지 구체적 근거로 설명하지 못했다.
다음 달에는 개념을 카테고리 안에서만 연결하지 않고 프론트엔드, 브라우저, 백엔드 영역을 넘나들며 연결점을 정리한다.
다양한 디버깅 도구의 사용법을 익히고 가설을 세워 입출력 범위를 좁혀가는 논리적 에러 추적 과정을 의식적으로 연습한다.
AI가 현재 작성 중인 문서의 맥락을 파악하고 관련된 과거 해결 방식을 함께 제안하도록 MCP 활용 방식을 더 정교하게 다듬는다.
Playwright와 AI 테스트 자동화를 더 다양한 시나리오에 적용해 보며 사람의 개입이 필요한 지점과 협업 방식을 정리한다.
입사 전까지 자신이 가장 깊이 몰입하는 상황, 우선순위를 정하는 기준, 팀에서 잘할 수 있는 일을 구체적으로 점검한다.
2026
03월
15개 항목
n8n으로 "매일메일" 자동화 워크플로우를 구성해, 면접 질문 메일을 파싱하고 Gemini로 추천 답변 / 핵심 개념 / 실수 포인트를 가공해 데이터베이스에 저장하는 경험을 확장했다.
CodeRabbit과 SonarQube를 도입해 혼자 개발하면서도 팀원이 옆에서 피드백을 주는 것과 비슷한 코드 리뷰 환경을 만들었다.
처음에는 도구의 제안 중 일부를 대충 넘기려 했지만, 제안의 이유를 먼저 살펴보고 납득한 뒤부터는 왜 그런 제안을 하는지 이해하고 수용하는 방식으로 태도를 바꾸었다.
도구가 반복적으로 같은 유형의 접근성 이슈를 지적하다 보니, 나중에는 코드를 작성하는 시점부터 자연스럽게 웹 접근성을 고려하는 감각이 쌓였다.
온라인으로 진행되는 다양한 세미나를 틈틈이 챙겨 들으며, 이론보다 실무에서 직접 부딪히며 얻은 사례 중심의 인사이트를 얻는 습관을 유지했다.
매일 무언가를 하고 있었지만 "할 일이 많은 것"과 "의미 있는 일을 하는 것"을 구분하지 못한 채 시간을 흘려보내, 명확한 우선순위를 가진 목표의 부재를 느꼈다.
직무만 맞으면 무작정 서류를 지원했고, 떨어졌다는 사실보다 자신이 뭘 하고 싶은지조차 명확하지 않다는 점이 더 답답하게 느껴졌다.
목표 없이 남들이 하는 것을 따라가기 바빴고, 비교와 조급함이 판단을 흐리며 악순환의 본질적인 원인이 되었다.
이력서에서 문제를 어떻게 바라보고 해결했는지는 이전보다 선명하게 전달되었지만, 기술적 판단을 드러내는 부분은 아직 부족하다고 느꼈다.
지원 과정이 일단락되면 한두 달간 처음부터 끝까지 나만의 프로젝트를 만들어, 기존에 약했던 테스트 코드를 정교하게 짜고 실무 지향적인 기술들을 깊이 익힌다.
CS 지식을 단순히 새로 쌓는 데 그치지 않고, 제대로 이해하고 다시 꺼내볼 수 있는 형태로 꾸준히 정리한다.
하루 30분에서 한 시간은 AI 활용법을 공부해, AI와 함께 더 빠르고 정확하게 문제를 해결하는 방식을 터득한다.
개념을 새로 접할 때마다 "언제 이런 상황을 겪었지", "그때 왜 그런 선택을 했지", "다른 방법은 없었을까"와 같은 질문을 스스로 던지는 습관을 들인다.
새로운 내용을 쌓는 데만 집중하기보다, 이미 배운 것을 직접 설명해보거나 관련 코드를 다시 짜보는 방식으로 의식적으로 다시 꺼내본다.
세미나에서 얻은 인사이트를 조금씩이라도 실제 상황에 적용해보며, 직접 경험 속에서 새로운 인사이트를 만들어간다.