지나야만 보이는 게 있다: 월간 회고를 시작하며

Date. 2026.08.03–09.11

최근 외부 컨설턴트 분을 통해 좋은 인사이트를 얻었는데, 질문의 종착지는 '지금 나에게 무엇이 중요할까?' 였다. 이 질문에 답할 수 있으려면 첫째, 내가 스스로를 잘 알아야 하고 둘째, 지금 세상이 어떻게 돌아가고 있는지 거시적인 관점을 갖춰야 하고 셋째, 앞의 두 가지를 엮어 나의 길을 계속 가꿔야 한다.

다행스럽게도 나는 나를 잘 안다. 이 박윤혜라는 사람은 글을 읽고 쓰고 생각하기를 좋아하며, 끊임없이 '왜?'를 묻다가 본질을 발견하는 순간을 좋아한다. 체계적인 것도 좋다. 단순한 방 정리부터 시작해서 집단의 시스템을 정립하거나 개선하는 과정을 재밌어한다. 만들기도 좋다. 영화나 책, 달력, 편지 같은 물성 있는 재료도, 홈페이지 같은 디지털 세상도 가리지 않는다. 지금 선택한 직무인 개발은 후자의 일환이다.

일차적으로는 위 요소들을 개발이라는 직함 안에 녹여서 나만의 뾰족함을 천천히, 그러나 꾸준히 쌓는 게 목표다. 엄밀히 말하면 '반드시 개발'일 필요도 없다. 인간 사회의 9 to 6 직장 개념이 고작 100년 역사라는 걸 생각해보면, 프론트/백엔드 구분이 생겼다가 다시 합쳐지고 이마저도 사라질 수 있는 현재의 모습은 지극히 자연스럽다. 지금 우리가 밟고 있는 이 땅에 공룡이 살았던 시절이 있는데 그에 비하면 인간 직업의 역사는, 개발의 역사는, 얼마나 턱없이 짧은가. 물론 소멸을 원하는 건 아니지만, 어떤 식의 변화라도 수용할 준비가 됐다는 의미다.

각설하고, 요새 느낀 문제점들을 정의하고 이를 어떻게 다루고 있었는지, 앞으로는 어떻게 나아갈지를 정리해보자!

Problem

잘하고 싶은데, 무엇을 잘해야 할지 모르겠다

처음 입사한 24년 하반기부터 지금까지 나는 개발자와는 거리가 먼 것 같다, 더 나아가서는 개발과 맞지 않는다는 생각을 자주 했다. 뭐랄까. 남들만큼 기술 공부에 미쳐있는 것 같질 않았다.

와중에 AI가 기하급수적으로 발전하면서 잡음이 커지기 시작했다:

• n년차에는 이정돈 해야 한다
• 프론트엔드 개발자는 경쟁력이 없다
• 웹만으로는 안 된다
• 미국에서 줄기차게 레이오프가 이어지고...
• 개발자는... 미래가 (거의) 없다!

마구잡이로 쏟아지는 생산물을 감당하려면 올바른 판단과 결정을 내릴 기준이 필요하다. 그 기준은 퇴근 후나 주말에 개인적으로 채워야 한다. 그런데 어느 순간 의욕을 잃었다. 회사에선 밀려오는 일을 처리하기 급급했고, 데드라인을 겨우 맞추거나 조금 넘긴 채 끝난 프로젝트는 바로 다음으로 전환됐다. 돌아볼 겨를 없이 달리기만 하니까 제자리걸음만 반복하는 기분이었다.

AI가 생산성을 높인다는 데엔 동감하지만, 생산 효율은 별개였다. 양이 늘어난 만큼 검토할 것도 늘었고, 쉽게 구현할 수 있다 보니 작업 범위도 쉽게 불어났다. 병목이 옮겨졌다고 느꼈다. 무엇을 만들지, 언제까지 어느 범위로 만들지, 결과를 어떻게 검증할지가 관건이었다. 그렇다면 내가 길러야 할 것도 단순히 더 빨리 구현하는 능력만은 아닐 것이다.

이 패턴이 반복되면서 답답함이 쌓였고, 돌파구를 찾아서 시도해봤다. 사이드 프로젝트를 친구와 함께 해보고, 앱도 공부해 보고, 개발자 네트워킹에도 나가면서. 이력서와 포트폴리오를 정리하면서 내가 한 것들의 의미를 찾으려고도 했다. 이 노력들에 힘입어 불이 타오르다가도 차갑게 식기를 여러 번 오갔다.

여러 시도를 거치고 나서야 내가 일에서 중요하게 보는 게 재미라는 걸 알았다. 요즘 일이 재미없었고, 그래서 자꾸 다른 곳에서 답을 찾으려 했던 것 같다.

기획 산출물을 읽는 일이 피곤하다

요즘 화면설계서나 기능정의서를 읽다 보면 이전보다 피로도가 높다. AI를 활용하면서 설명은 길고 풍부해졌는데, 그게 꼭 이해에 도움을 주진 않는 것 같다. AI 특유의 말투가 적나라하게 드러나서다. 비슷한 내용이 조금씩 다른 말로 반복되고, 확정된 요구사항과 참고용 설명이 비슷한 무게로 나열된다. 중요한 게 뭔지 알려면 결국 처음부터 끝까지 다 읽어야 한다.

화면과 설명이 다른 경우도 꽤 있다. 상태값은 정의되어 있는데 그 상태에서 실제로 보여줄 화면이 없거나, 버튼을 누른 다음의 흐름이 빠져 있는 식이다. 로딩이나 오류 화면처럼 사소해 보이는 것도 구현하는 입장에서는 그냥 넘길 수 없다. 하나씩 코멘트를 남기고 다시 물어봐야 한다. 구현하다가 뒤늦게 발견하면 이미 만든 걸 되돌아가서 수정하기도 한다.

그동안은 작업자가 꼼꼼하게 보면 되는 일이라고 생각했다. 그런데 프로젝트가 바뀌어도 비슷한 문제가 반복되니 이걸 계속 개인의 주의력으로 메우는 게 맞나 싶다. 사람마다 발견하는 범위도 다를 테고, 누군가 놓치면 그대로 다음 단계로 넘어갈 가능성도 있다.

화면설계서는 기획자와 디자이너, 개발자가 같은 흐름을 보고 있는지 확인하는 문서라고 생각한다. 사용자가 어디서 진입해서 무엇을 끝내야 하는지, 중간에 실패하거나 취소하면 어떻게 되는지, 어떤 정책이 정해졌는지는 구현 전에 확인할 수 있어야 한다. 어디까지 작성되어야 개발을 시작할 수 있는지, 산출물의 완료 기준부터 같이 정해볼 필요가 있겠다.

Keep

아주 작은 업무라도 PRD로 기록하기

'개발'이라는 직무를 달고 있다고 한들 각자의 강점과 관심사는 다르다. 나는 앞서 언급한 대로 만들기를 좋아한다. 내가 개발을 재밌어 하는 핵심 이유는 프로덕트 만들기를 좋아해서다. 기획이나 관리, 설계 같은 큰틀을 짜는 의사결정 말이다. 이걸 업무에 녹여보기로 했다.

기획팀을 타고 온 개발 요청엔 짤막한 배경이 적혀있다. 요청 내용을 구현하기 전에 그 기저에 있는 문제부터 보려고 했다. 이 방식이 정말 불편을 해소하는지, 누가 어떤 상황에서 겪는 불편인지, 버저닝은 왜 필요한지 같은 것들이다. 혼자 답을 내리기 어려우면 기획자에게 묻고, 때로는 다른 방법을 제안했다.

예를 들어, 서비스 신청 프로세스를 전면 개편할 때 한 화면에 너무 많은 정보가 들어가서 사용자 경험이 저하되는 상황이 있다고 하자.

가장 단순한 접근은 아코디언 같은 컴포넌트를 활용하는 것일 테다. 하지만 모든 출발점은 요구사항 확인이라고 생각한다. 이 프로세스가 처음 만들어진 때의 요구사항이 지금은 달라졌을 수도 있기에 각 필드가 누가, 언제, 어떤 판단을 내릴 때 사용하는지 알아야 한다.

이전과 요구사항이 달라지지 않았다면, 다음 스텝이다. 이 모든 것을 반드시 사용자가 입력해야 하는지를 살펴보는 거다. 회사에서 이미 사용자 데이터를 위해 계약한 외부 API 활용 방식을 고민해본다. 사용자는 본인인증이나 기본 식별 정보만 입력하고, 나머지는 API 호출로 처리한다면 사용자는 귀찮은 입력 화면에서 자유로워진다.

사용자 경험 저하 문제가 해소됐는가? 고객 측면에서는 맞다. 하지만 관리자단이 남았다. 담당자는 여전히 많은 필드를 봐야 한다. 내부 담당자 대상으로 프로덕트를 만들 땐 담당자의 워크플로우를 알아야 한다. 엑셀이나 노션 같은 외부 툴에 옮겨 쓰는지, 아니면 업로드된 파일과 이 정보를 실제로 대조해야 하는지 등등. 이 답변에 따라 화면 설계가 달라야 할 것이다.

이 과정이 프로덕트를 만드는 일이라고 생각한다. 그래서 아무리 작고 단순한 업무라도 PRD를 작성하기 시작했다. 왜 지금 이 업무가 들어왔는지, 무엇을 해결하려는지, 어디까지 만들고 무엇은 만들지 않을지, 예상되는 위험은 무엇인지까지 적었다. 이 과정은 TDD가 주는 효용과도 맞닿는 지점이 있다고 느꼈다. 의도를 먼저 작성하고, 이를 가장 간단한 코드로 만들어가며 불필요한 방어 장치들을 걷어내는 점에서 말이다.

물론 매번 이렇게 생각하다 보면 당장 구현은 늦어진다. 요구사항을 그대로 받아서 작업하는 편이 한 기능만 놓고 보면 빠르다. 프로덕트 전체로 보면 얘기가 다르다. 이 제품에 정말 필요한지 판별하고, 결과를 실제 데이터로 확인할 수 있으니 말이다.

이 기록이 쌓이면 다음에 비슷한 일을 만났을 때 처음부터 다시 고민하지 않아도 될 것 같다. 나중에는 모델에 명세로 넣어볼 수도 있고.

기록물 주기적으로 관리하기

출근하면 켜는 프로그램 중 하나가 옵시디언이다. 오늘 일정은 뭔지, 무얼 끝마쳐야 하는지를 작성하고 업무를 시작한다. 노트도 만들어놓기만 하면 금세 쌓인다. 나중에 다시 찾으려면 검색이나 LLM에 물어보는 방법도 있지만, 큰 그림은 사람이 알고 있어야 찾아보라고 할 때 명확한 질문을 던질 수 있다. 고로 디렉터리 구조를 계속 손봐야 한다.

옵시디언은 자유도가 높기 때문에 사용자가 어떻게 구조화하느냐에 따라 관리 효율성이 달라진다고 본다. 기존에 사용하던 PARA 형식하에 각 Project나 Archieves 항목을 어떻게 관리하는 방향을 선택했다. 자세한 내용은 Obsidian을 다룬 블로그 글을 참고하면 된다.

최근엔 Jira의 epic-task 개념을 따와 상위와 하위 업무를 분류했다. Depth가 깊으면 추적이 어려워서 무조건 one-depth를 유지하는 걸로 해서. 아주 작은 기능 업무는 task만 있고, 분기별로 끝내야 할 일들은 대개 epic 구조가 적절하다.

epic과 task 템플릿은 이런 식이다:

Epic: 문제 배경 및 정의 → 목표와 범위 → 전체 흐름 → 공통 정책과 주요 결정 → 통합 검증 → 결과
Task: Context → 목표와 범위 → 결정 기록 → 구현 → 검증 → 결과

데일리노트의 템플릿도 때마다 변경하는데, 이번엔 인사이트 항목을 추가했다. 업무하면서 떠오르는 생각 조각이나 아이디어를 메모하기 위해서다. 한 줄 요약처럼 핵심부터 적는데 생각보다 효용이 좋다. 블로그, 공부, 프로젝트 아이디어 등 어디에든 써먹을 재료다.

Try

Jira 사용 방식에 대한 고민

컨설팅이 끝나자마자 팀장님이 개발팀에 지라 도입을 추진하셨다.

아직 깊게 파보진 못했지만 오래된 툴답게 용어나 개념에 진입장벽이 있다. 큰 규모에 특화되어서인지 이것저것 만지는 재미가 있을 것 같긴하다. 원래는 PM 분을 새로 모셔올 생각으로 티켓 관리를 이야기하다가, 받은 업무를 결국 클로드를 통해 처리하고 있으니 PM 역할은 이미 우리가 하고 있지 않느냐는 질문을 하셨다.

이 아이디어를 정리하면 이런 식이다:

1. 관리직급이 티켓을 세세하게 쪼개서 업무를 할당한다.
2. 담당자가 업무 배경, 목적, 구현 내용을 본인이 직접 작성한다.
3. 코드베이스에 컨벤션이나 린트, e2e 테스트, 타입 체크 같은 하네싱을 설정한다.
4. 클로드로 구현한다.
5. 명세화된 컨벤션을 기준으로 1차 AI 코드 리뷰를 진행한다.
6. 중요한 로직이나 플로우 위주로 PR 템플릿을 작성해 사람이 필요한 부분만 검증한다.

여기에 덧붙여 CSS를 일일이 읽지 않고도 넘길 수 있는 워크플로우를 만들고 싶다. stylelint로 규칙을 주입하고 Playwright로 화면을 테스트하는 방법을 생각해 봐야겠다. 결국 어떤 것이든 시작하려면 명세가 필요한 것 같다.

수면과 운동 루틴을 지키며 평일에 공부하기

잠과 운동을 제외하거나 제한하면 삶의 질이 급격히 저하되고, 집중력도 자연스럽게 떨어진다. 이 상태에서 인풋을 쏟아넣는다고 한들 스트레스만 커질 게 분명하다.

야근을 꺼리는 이유도 여기에 있단 걸 알았다. 출근 준비와 출퇴근 왕복에 하루 세 시간을 쓴다. 정시 퇴근하고 집에 와서 저녁을 먹고 운동만 해도 이미 9시가 넘는다. 회사는 아무리 편해도 내 공간이 아니고, 집과는 에너지가 회복되는 속도가 다른 것 같다.

뭐든 시작보다 유지가 더 중요하다고 생각하기에 나에게 잘 굴러가는 시스템을 만들고 싶다. 우선 다음 날까지 피로가 이어지지 않도록 잠드는 시간을 지키고, 운동한 날에는 공부량을 줄여보려고 한다. 천천히, 꾸준히가 삶의 모토다.

월간 회고 시작

과정 중에 배우는 것을 최대한 기록하는 편인데도, 돌이켜 생각해봐야 깨닫는 게 있다. 플레이어가 필드 위에서 순간순간 배우는 것들이 있고, 필드 밖에 나와서 리뷰하면서 배우는 게 있듯이 말이다.

원래는 이력서 갱신용으로만 생각했는데, 생각은 AI가 대신해줄 수 없다. AI가 도움은 줄 수 있어도 결국 내가 내 뇌를 써야만 남는다는 생각이 강해졌다. 생각하는 도구로서 회고를 애용해 보려고 한다.

기획 산출물 리뷰

큼지막한 프로젝트가 끝날 때마다 화면설계서 리뷰를 했던 것 같은데, 아직 개선할 여지가 있다. 특히 고민되는 건 사소하고 디테일하지만 작업자 눈에는 보이는 것들이다. 화면과 설명이 다르거나, 상태값에 따라 다른 화면이 노출되어야 하는데 데이터만 있고 실제 화면은 없는 경우가 있다. 색상이 다를 때도 있다.

우선 피그마 파일별로 코멘트 개수와 유형을 정리해 볼 생각이다. 필요한 의사소통과 개선해야 할 항목을 나누고, 이 문제가 왜 발생하는지 의견을 주고받아야겠다. 원래는 대안을 가져갈 생각이었는데, 상황부터 파악한 다음에 각자 생각하고 다시 얘기해 보는 게 좋을 것 같다.

또 하나 드는 생각은 화면설계서가 얼추 완성되면 개발상 이슈는 없는지 확인하고자 기획과 개발이 가볍게 회의하는데, 이때 화면을 다 볼 순 없는 노릇이다. 전체 프로세스에 대한 흐름도, 각 세부사항에 대한 흐름도가 있으면 좋을 것 같다곤 생각한다. 근데 개발자에겐 어렵지 않은 게 기획자에겐 낯선 일일 수 있으니... 제시하고 싶은 흐름도가 있는데 이것도 의견을 들어봐야겠다.

TypeScript 전환

타입스크립트를 쓰는 프로젝트가 많지만, 메인 프로젝트는 여전히 자바스크립트를 사용 중이다. 필요성을 느끼지 못해서였다. 남들이 다 쓴다고 해서 우리도 쓸 이유는 없지 않은가? 이유가 분명하지 않으니 추진할 생각도 들지 않았다.

그런데 최근 들어 생각이 바뀌었다. AI에게 구현을 맡길수록 사람이 확인할 지점이 분명해야 했다. 타입은 데이터 형태와 함수의 약속을 코드에 남기고, 잘못된 사용을 실행 전에 알려준다. 이게 곧 명세다. 쫌쫌따리로 타입스크립트의 배경 공부부터 시작했는데, 이번 달 주요 업무를 마치고 나면 전환 계획부터 세워볼 생각이다.

---

정리하며

이번 회고를 쓰기 전까지는 여전히 개발을 계속하는 게 맞는지 고민하고 있다고 생각했다. 그런데 막상 적어놓고 보니 앞으로 개발하면서 해보고 싶은 일만 잔뜩이다. 큰 그림은 계속 그려보고, 일단은 내가 재밌어하는 방식으로 좀 더 해보며 올해 남은 시간들을 보내볼 것이다. 12월 리뷰가 벌써 기대된다.