스스로에 대한 이해도가 부족해 보여요. 본인의 색깔을 고민하는 시간을 가져 보는 건 어때요?
25년 하반기, 방황하던 나를 보고 컨설턴트님이 해 주신 말씀이다. 그동안 감정적인 서술은 제거하고 수치와 성과를 드러내야 한다는 말을 반복해서 듣다 보니, 강박적으로 매력 없는 이력서와 포트폴리오만을 뽑아내고 있었다. 이 무색무취를 컨설턴트님도 느끼셨던 것 같고, 그렇게 빈 공책을 펼치고 내가 해 온 것과 어떤 부분에서 내 강점이 돋보였는지에 대해 정리하는 기간을 가졌다.
나는 어떤 개발자인가?
사람들과 다양한 견해를 공유하고, 지식의 꼬리를 무는 대화가 늘 재미있었다. 문제가 발생한 뒤 그 문제를 해결하기 위한 목적의 논의가 아니라, 주로 불편함을 먼저 이야기하는 게 그렇게 즐거웠던 것 같다. 예시로, 콜아웃 컴포넌트는 정보 전달과 시각적 강조를 위한 컴포넌트인데 왜 액션 버튼이 필요한지 모르겠다는 질문을 디자이너님께 던진 적이 있었다. 고작 이 질문 한 줄로 앉은 자리에서 디자이너님과 한 시간 넘게 한 컴포넌트에 대해 논의했다.
아래가 그 논의가 반영된 결과물이다. 고작 한 줄의 질문으로 컴포넌트가 명확한 역할을 가질 수 있게 되었다.
| Before | After |
|---|---|
그리고 다른 교집합은 '가독성'이었다. 혼자 작업하는 횟수보다 대외 활동 사이드 프로젝트를 진행하는 횟수가 더 많았다 보니, 늘 내가 읽기도 힘든 코드를 팀원들이 이해할 수 있을까? 라는 질문을 멈추지 않고 코드를 작성했었다. 그래서 이 질문들을 이력서 헤더에 담아 봤다.

근데 반년이 지난 시점에서 보니까 솔직히 마음에 들지는 않는다....
자연스레 공백기가 길어지고 있는 게 싫어서 대외 활동을 여러 번 했다. 항상 좋은 기회가 있으면 달려갔던 것 같다. 부트캠프에서 프로젝트 컨설팅이 끝나고 시간이 나면 어떻게든 기회를 놓치지 않고 기업 멘토님께 포트폴리오 피드백을 받았고, 인스타 스토리까지 공개적으로 올려서 교류가 없거나 새로 알게 된 사람, 다른 업계 사람들에게도 가리지 않고 피드백을 받았다. 그리고 이 개선을 긍정적으로 평가해 주는 사람들이 많아졌다.
진짜 많이 좋아졌다!
이 한 마디가 그렇게 좋더라. 사실 하루 종일 이력서만 들여다보고, 수십 번을 수정하다 보니 깔끔해진 것 말고는 스스로 체감하지 못했는데 전반적으로 내가 드러나게 됐다는 평을 받을 수 있게 되어 기뻤다. 덕분에 용기를 얻어 다시 서류를 제출하기 시작했고 다음 전형의 연락을 꽤 많이 받을 수 있었다. 물론 운도 작용했겠지만.
신기하게도 1년 동안 취업의 문턱을 넘지 못하고 있던 내가 서류를 본격적으로 넣기 시작하고 한 달 만에 현재 회사에 입사하게 됐다. 재직 중인 회사 외에도 좋은 소식을 들을 수 있었어서 입사할 회사를 결정하고 있는 상황이 꿈처럼 느껴졌다.
입사 뒤 좋은 분들을 많이 만났고, 지금까지도 문제 없이 다니고 있지만 내 생각과 다른 것들이 많았다.
각자 다른 사업을 맡아서 하는 구조라 전임자가 퇴사한 업무의 인수인계가 어려웠고, 한창 바쁜 시기에 입사해 제대로 된 온보딩도 이루어지지 않았다. 회사에 대한 기초적인 설명과 관련 문서만 전달받고 그 외 업무 파악은 온전히 신입의 몫이었다. 그렇게 나흘 동안 전달받은 문서와 서비스 코드, 방침들을 정신없이 따라가다보니 의문이 드는 지점들이 여러 개 생기게 됐다.
왜 서비스 일일 점검을 모두 수동으로 진행하지?
인터페이스 문서를 스웨거랑 비교하면서 엑셀에 일일이 타이핑하고 있다고?
위 문제들의 교집합은 '불편함'이었다. 당장 이런 식으로 진행해도 문제는 없으니까, 모두가 불편함을 감수하고 묵묵히 수행했을 사소한 지점들이었다. 그래서 신규 업무가 생기기 전까지 일정 공백이 있었기 때문에 팀장님께 조심스럽게 제안드렸다.
나: 이런 지점들은 자동화가 가능할 것 같은데, 업무를 맡기 전까지 진행해 봐도 될까요? 왜 이렇게 생각했냐면 (구구절절...)
팀장님: 그렇게 되면 너무 좋을 것 같아요!
그렇게 입사 4일차에 모두의 시간을 효율적으로 활용하기 위한 계획을 세우기 시작했다.
이를 결심한 이유는, 점검 항목들을 체크하기 위해 점검자가 매일 아침 각 서비스에 접속해 모든 페이지의 네트워크 탭을 확인하며 일일이 작성하고 있었기 때문이었다. 선임님께 인수인계를 받고 정말 기겁했다. 업무가 바쁠 때 신경 쓰기에는 시간 소모가 상당해 보였고, 너무나도 비효율적으로 보였기에 반드시 자동화가 필요한 부분이라 느꼈다.
회사에서 수동으로 진행하고 있던 점검들은 playwright 도입으로 해결 가능할 것 같아 점검해야 할 항목부터 정리하기 시작했다. 자세히는 말할 수 없지만 대략적으로 다음과 같았다:
게다가 하나의 경우에 수에도 시간이 꽤 소요되다 보니, 모든 지역의 모든 월을 검사하지 않고 로테이션으로 하루에 한 지역만 점검하고 있었다. 즉, 그날 점검한 곳에서 문제가 터지지 않더라도 다른 곳에서 문제가 발생할 수 있는 잠재적 위험이 내포된 점검 방식이었다.
그래서 모든 지역을 대상으로 다음과 같이 테스트를 진행했다:
그리고 이걸 어떻게 전달받을지가 주요 고민이었는데, 사내 메신저로 mattermost를 사용하고 있어 웹훅을 이용하기로 했다. 테스트 결과를 축약해 채널에 보내고 싶어서 마크다운으로 한차례 가공해 보내기로 했다. 대략적인 흐름은 다음과 같다:
내가 적용한 건 하나의 서비스였는데, 이 점검 방식이 회사의 다른 서비스에도 적용되면 좋을 듯했다. 다만, 독단적으로 진행할 수 없는 일이고 혼자 모든 걸 진행하기보다 공유 후 함께 적용해 보면 좋을 것 같다 판단했다. 어떻게 보면 일 하나를 만든 거지만, 장기적으로 봤을 때 다른 불편한 지점을 이런 방식으로 해결할 수 있겠다는 의식을 공유하고 싶은 것도 있었다.
다행인 건 팀장님도 내 의견에 동의하셨고, 선임님과 입사 동기 분께서도 흔쾌히 작성해 둔 문서를 보며 뒤따라 진행해 주셔서 성공적으로 병목 하나를 제거할 수 있었다. 회사에서의 첫 기여라 들뜬 일주일을 보냈던 기억이 난다.
기획과 디자인이 내려오고 설레는 마음으로 기존 프로젝트 업무에 들어갔는데, 가장 처음 느낀 감정은 이랬다.
이 코드로 서비스가 돌아가고 있었다고?
관심사 분리가 하나도 진행되지 않아 한 파일에 3000줄이 넘어가는 건 기본이었고, 같은 기능을 공유하고 있음에도 공통 컴포넌트로 선언되지 않아 QA 하나가 터지면 모든 페이지의 해당 부분을 수정해야 하는 일이 부지기수였다. (실제로 디자인 QA만 이런 식으로 약 278개가 나왔었다.... 충격적인 수치) 파일과 내부 함수, 변수명의 네이밍도 제각각이거나 의미 파악이 어려울 만큼 축약된 것들이 많아 작업을 진행할 때 정말 애를 먹었던 기억이 난다.
그래서 AI한테 정말 많이 부탁했다. "관심사 분리해", "공통 컴포넌트로 분리 후 재사용해", "사용되지 않는 데드 코드 제거해" 등... 나중 가서는 귀찮아서 별다른 지시 없이 알아서 리팩토링하라고 시키기만 한 적도 있다. 그런데 이런 명령들이 반복되다 보니 문득 이런 생각이 들었다.
나 지금 AI 너무 비효율적으로 사용하고 있는데?
사용은 하고 있는데, 내가 알고 있는 지식 선에서 반복해서 같은 작업을 요청하고 있었다. 그것도 매일. 근데 내가 같은 말을 일주일 넘게 하더라도 AI는 같은 결과를 내지 않았다. 어떤 때는 잘만 했던 걸, 다른 날에는 이상하게 작업하고 당당히 다 했다고 말했다. 그거 아니라고, 전에 이렇게 하라고 했었는데 분명 메모리에 저장해 달라고 하지 않았어? 하면 저장해 뒀는데 못 봤다고 자기 실수라고 말하는 날들이 반복됐다.

야......
그래서 오픈소스로 공개되어 있는 에이전트나 스킬 md 파일들 중 우리 프로젝트에 사용하면 좋아 보이는 것들을 수집하기 시작했다. 그리고 적용해 봤는데 AI가 똑똑해져 있었다. 그럼 이걸 우리 프로젝트에 맞게 재가공하면 더 똑똑해지려나? 해서 하루 종일 문서를 붙잡고 수정해 봤더니, 정말 그랬다. 그러면 이 프로젝트에 필요한 스킬에는 뭐가 있지? 하고 막 만들어 봤더니, AI한테 더 이상 문장으로 시키지 않고 refactor, feature, commit, test, review 등... 커맨드 하나로도 작업을 명령할 수 있었다. 심지어 결과도 안정적으로 변했다.
다만, 여전히 이상한 부분들은 있었다. 분명 순서대로 진행해 달라고 했는데 테스트를 빠트린다거나, 커밋을 빠트린다거나. 축약 네이밍을 지양하라든지, margin 사용을 지양하라든지 하는 것들도 어느 순간 다시 생겨 있었다. 그러면 늘 이거 하지 말라고 했잖아. 그러니까 앞선 상황의 반복이었다.
진심 일단 시도함 뭔가 나오긴 함

그래서 훅으로 변수들을 고정하고, 스킬 하나에 여러 과정이 필요한 거라면 오케스트레이션을 만들었다. 오픈소스도 도움이 많이 됐지만, 테크 기업들의 AI 사용법을 많이 참고했다. 적용한 뒤에는 토큰 사용량 대비 결과물이 만족스러워 나만 알 수 없다는 생각으로 팀원들에게 주간 회의 때 소개하기도 했다. 덕분에 지금은 내가 적용한 방식을 회사 내부의 프로젝트에 모두 순차 적용 중이다.
이 덕분에 최근 착수한 사업 개발도 엄청나게 빠르게 진행될 수 있었다. (같은 대시보드인데 나흘 만에 끝남) 외에도 코드 품질이 나아지면서 1차 릴리즈에 비해 2차 릴리즈 QA 양이 대폭 감소했다. (278 -> 60) 그것도 디자인과 달라서 나오는 QA는 거의 사라졌고, 대부분 변경점이나 예외 처리를 빠트려 발생하는 기능 오류, 신규 요구 사항이 대부분이었다.

내가 느끼는 불편 지점들을 시간이 날 때마다 개선하며 근무하고 있다. 회사에 입사한 지 이제 막 4개월이 되어 가는데, 회고 글을 작성하기 위해 캘린더를 뒤적여 보니 기간에 비해 정말 많은 일을 만들어서 했다 싶었다. 문제를 개선해 누군가의 불편함을 줄여 주는 것이 즐겁고 재미있어서 퇴근하고 집에서도 손보고, 출근하면 테스트해 보고... 이런 생활을 반복하니 눈 깜짝할 새에 4개월이나 지나 버렸다.
굉장히 만족하며 다니고 있는 것 같지만, 회사를 다니면서 내가 지향하는 바를 알게 되고 자연스레 미래를 고민하게 되는 시기로 접어들고 있다. 회사 특성상 한 명이 하나 이상의 프로젝트를 단독으로 맡아 진행하기 때문에 코드 리뷰 문화가 전무하다. 내가 입사하기 전까지 테스트 코드도 없었으니, 사실상 버그가 발생해도 누군가 발견하기 전까지는 잠재적으로 남아 있을 확률이 컸다.
또한, 방치되고 있는 문제가 많았다. 이런 건 내가 해결하면 되고 좋아하니 상관없지만, 모두가 큰 불편함에도 문제를 제기하지 않으니 지식을 공유하는 상황마저 어색해져 버리더라. 서비스도 일단 동작하면 두고, 클라이언트가 문제를 제기하면 그제서야 고치고. (살짝 충격받음)
위와 이어지는 문제점으로, 개발자가 제시한 문제는 문제가 아니다. 예를 들어, 이 부분은 불필요해 보인다거나 사용자가 불편할 수 있을 거라는 의견을 이야기해도 논의가 아닌 "일단 해 주세요"가 되는 게 힘들었다. 이러다 보니 나도 문제 의식을 가지지 않게 되고 점점 분위기에 휩쓸리는 느낌이 들었다.
애초에 오래 계신 분들은 이미 이걸 알아서 문제를 제기하지 않게 되신 것 같았다.
늘 이런 사람이 되고 싶다고 소개하고는 한다. 그렇지만 회사에 와서 모두가 나와 같이 생각하는 건 아니라는 것을 알게 됐다. 일은 결국 개발이기 때문에 어떤 것이든 즐겁고 재미있지만, 성장할 수 없을 것 같다고 느껴질 때마다 현재 회사가 나와 맞지 않다고 느끼게 된다.
대외 활동에서는 시간이 없더라도 서로의 코드를 읽고 코멘트를 남기고, 서로의 관점을 끊임없이 공유하는데 이게 너무 좋아서 더 이상처럼 좇게 되기도 한다. 스스로 성장하고 싶다는 욕구는 늘 있는데, 이런 욕구를 가진 사람이 많을수록 동력은 커지니까.

실제로 숫자가 커질수록 희열을 느낌....
그래도 상반기가 참 소중했다. 나를 더 자세히 알게 되고, 꿈에 그리던 취업에 성공하고, 더 나아가 회사 업무를 하며 내가 어떤 걸 목표하고 있는지 재정립할 수 있는 기회를 가질 수 있었으니까. 이 소중한 것들을 안고 하반기에는 내가 지금보다 더 나은 모습으로 2027년의 나를 맞이할 수 있었으면 좋겠다.

소희님, 오랜만이에요!
평소 자주 보던 커뮤니티에서 소희님 게시글이 소개된 걸 보고, 익숙한 아이디가 너무 반가워서 댓글 남겨요.
즐겁게 개발하시는 모습 보고 저도 덕분에 자극받고 갑니다! 취뽀 축하드려요 🎉🎉
다음에 뵐 때는 명함도 교환해요 ㅎㅎ
그때까지 잘 지내셔용 ❣
크으 불편함을 개선하는 개발자!! 너무 멋지시네요!! 앞으로가 너무 기대됩니다!!!!