조직 개편을 맞이하며, 월간 회고

Date. 2026.09.12–10.09

조직 개편이 예정되면서 지난 회고에 계획한 상당수가 해소되었다. 다음주부터 개발팀이 아닌 프로덕트 팀 소속이다. 프로덕트 팀은 두 명의 관리자 PM과 PO가 있고, 하위에 개발 파트와 AX, R&D 파트로 구성된다. 개발팀엔 나를 포함한 두 명의 엔지니어, 그리고 기획자 한 명이 있다.

개편이 확정되기 전에 현황 파악 겸 지난 업무 문제나 이슈들을 나눴다. 특히 고민 많았던 기획 산출물 리뷰를 직접적으로 전할 기회가 있었는데 회의가 끝나고도 찝찝함이 남았다. 피상적인 것만 전달된 느낌. 이번 달 회고를 하면서 알았다. 그동안 문제 정의를 잘못했다는 걸.

Problem, 문제야 문제

혼자 일하는 문화

기획 산출물에 대한 문제 의식을 느낀 건 1년이 조금 넘었다.

1. 화면설계서나 기능정의서를 받았을 때 유저 플로우가 머릿속으로 잘 그려지지 않고
2. 모든 프레임을 하나씩 다 읽어보고 헷갈리는 지점은 앞뒤를 여러번 오가야 하며
3. 이마저도 정확하지 못해 개발 도중에 내가 잘못 이해한 것을 발견했다

기획자와 내가 피드백이나 생각 없이 지난 1년을 보냈는가? 절대 아니다. 서로 아쉬움을 느껴서 주기적으로 리뷰 시간을 가졌다. 리뷰의 결과로, 프로젝트마다 화면설계서가 달라졌다. 시각적으로는 변화가 생긴 것 같았다. 그러나 여전했다.

'화면이랑 설명이 달라요'
'이런 케이스에선 어떻게 보여줄까요?'
'같은 화면인데 이전 프레임이랑 텍스트가 달라졌어요. 어느 쪽이 맞는 걸까요?'

위 같은 코멘트를 프로젝트마다 10~20개 정도 달았다. 피드백이 있었는데도 왜 문제가 반복됐을까? 문제 정의를 잘못했기 때문이다.

나는 개인의 차원에서만 문제를 정의했다. 나와 상대방의 능력 부족. 직무 차이. 성격이나 성향 차이. 그런데 최근 애자일 관련된 책을 읽고, 팀에서 발생한 문제는 개개인의 문제가 아님을 느꼈다.

작업자가 자신의 작업을 까먹을 쯤에야 제시된 피드백

인간은 본디 망각의 동물이다. 오늘 한 말의 상당수는 내일이면 잊어버린다. 그런데 우리는 피드백의 텀이 길었다. 나는 '개발이 다 끝나고 한번에 정리해서 전달을 해드려야지' 판단했고, 내가 제시한 피드백은 다음 화면 설계서에서 확인할 수 있었다. 최소 1달, 최대 3달의 기간. 제대로 반영되는 게 이상할 정도의 주기다.

그러니까, 개인이 1인분의 일을 해내는 것에 급급했지, 팀으로서 사고하지 않았다. 기획이 완성된 후에 개발이 시작된다. 달리 말하면 개발을 한창 하는 와중엔 기획자는 다른 업무를 하고 있다. 모두가 동시에 같은 일을 하긴 어려우니 시차를 최소화한다고 해도 갭은 존재하겠으나, 어떤 방식이 더 좋았을까?

오늘 주고받은 코멘트를 당일에 함께 리뷰 하기가 가장 먼저 떠오른다. 어떤 프로세스로 작업을 진행했는지, 이 실수나 문제를 줄이고자 뭘 시도 해볼지를 주제로. 관건은 시기이다. 대화에서 나온 개선책을 늦어도 이번주 내엔 해봐야 하고, 논의 시간은 20분 내에 끝나면 짧은 피드백과 검증이 가능할 테다. 시도 후에 다시 얘기를 해보는 것도 필수일 테고.

소통을 잘한다는 착각

우리는 소통을 많이 한다. 업무는 기한이 있고, 기한을 맞추기 위해 지금 당장 해야 할 일과 남은 일들이 있다. 그 과정에서 장애물이 생기면 어떻게 해소할지를 논의하고 결정해 구현하는 의사소통은 문제 없다고 생각했다.

그럼에도 따로 논다는 생각을 버리기 어렵다. 이번 회원체계 변경 작업을 하면서 1) 기한 내에 작업하면서 발생한 문제 2) 반영 후에 발견한 문제 두 시점을 고려해 리스트업 해봤다.

먼저 기한 내에 작업을 완료하면서 생긴 문제는 크게 두 가지다:

• 회원 상태와 기능별 동작 매트릭스를 모두 고려하며 개발해야 하는 어려움
• 테이블마다 혹은 같은 테이블 내에서 같은 내용을 다른 명칭으로 표현하면서 발생하는 혼란

나는 일정보다 하루 일찍 개발을 마쳤지만, 기능 간 의존성과 변경 사항을 확인하는 과정이 부족해 일부 연계 처리를 놓쳤다:

• 본인인증 origin 제한 관련 처리
  작업자의 설계에 대해 개발팀이 2~3차례 논의를 했는데 origin을 제한한 사항은 공유되지 않았다. 요구사항에 없지만 필요할 것 같아서 넣은 제약이나 로직은 없는지 논의할 때 꼭 물어봐야겠다.
• 본인인증 관련 기능 간 연계 반영 누락
  다른 담당자의 기능 개발이 완료된 뒤 기존 기능에 반영해야 할 변경 사항을 놓쳤다. TODO로 코드 주석을 달아두었으나, 이 사실을 제때 전달하지 않았다. 이처럼 연계 작업이 필요한 기능은 첫 작업자가 고려사항을 TODO로 넣어둔다는 식의 협업 규칙이 필요할 것 같다.
  혹은 API 명세서가 나오면 개발팀 모두가 모여 각 기능이 서로 어떤 연관을 주는지를 브레인 스토밍하며 화이트보드에 그려보는 것도 좋겠다.
• 회원 탈퇴 관련 연계 반영 누락 및 데이터 처리 명세 미확정
  위랑 비슷한 사례. 서로의 기능이 미칠 영향을 사전에 고려하지 못했다. 기획과의 문제도 있었다. 기획이 작성한 탈퇴 관련 약관은 기업과 개인에 관한 내용이 혼재되어 있어 필드별 처리 기준을 판단하기 어려웠다. 기업·개인 관련 필드를 목록으로 정리해 전달한 뒤 처리 범위를 확정했다. 이것도 사전에 논의가 오갔다면 다르지 않았을까.
• 약관 변경 범위 누락
  서비스 약관과 마케팅 약관의 변경 사항을 회원가입에만 반영하고, 마이페이지와 플랫폼 푸터 약관은 반영하지 못했다. 마이페이지는 개발 과정에서 놓쳤고, 푸터는 기획에서 반영 대상으로 정의하지 않았다.
  처음에는 E2E 테스트의 결함이라고 생각했지만, 테스트 시나리오 역시 사람이 정한 범위에 의존한다. 약관 변경이 영향을 주는 화면과 사용자 흐름을 기획과 개발이 함께 검토했어야 했다. 프로덕트에 관여하는 모두가 주어진 업무 범위를 넘어 제품 전체의 흐름을 이해하고, 변경의 영향을 확인할 필요가 있으니 말이다.
• 이메일 기억하기 테스트 시나리오 누락
  테스트 시나리오에 로그아웃을 포함한 사용 흐름을 고려하지 않아, 기능이 정상적으로 동작하지 않는 케이스를 조기 발견하지 못했다.

지금까지 우리 팀은 이렇게 일해온 것 같다. 프로덕트 전체를 보지 않고, 지금 추가된 디테일 하나하나만 챙겼다. 기능 하나, 기획 하나가 끼칠 사이드 이펙트를 함께 논의하지 않고 혼자 생각하고, 혼자 만들었다. 와중에 마감 기한은 있으니 이 문제를 풀 수 있는 가장 쉬운 방법을 찾아다가 급하게 덧댔다.

결과물은?

하울의 움직이는 성이다. 어디는 검은 연기를 배출하느라 바쁘고, 다른 곳은 기계를 움직이게 하느라 바쁘다. 왜 바쁘겠는가? 각자가 따로 놀긴 해도 이 성을 움직이게 하려고 열심이긴 하다. 얄팍한 다리 두 개에 의지해서 뒤뚱뒤뚱. 넘어질듯 말듯, 걷는다.

Try, 꽤 괜찮은 시도였다

더 나은 팀을 고민한다면 『함께 자라기』

앞서 언급한 애자일 관련 도서, 『함께 자라기』는 몇 년 전에 처음 들었는데 이제야 읽었다. 출간은 2018년인데 집필 시점이 이세돌과 알파고의 바둑 대전으로 이슈가 되었을 무렵인 것 같다. 거의 10년에 가까워지는 책이지만, 메시지는 유효하다.

좋은 내용이라서 링크드인에 짧은 소감문도 올렸다. 책 내용을 다 담기엔 한없이 짧은 단락이지만, 내 가치관을 견고하게 만들어 줄 인사이트는 링크드인이나 블로그 회고에 꼭 적어두려고 한다.

풀스택 전환, 역할 인식부터 바꾸자

올해 들어서 개발팀 엔지니어 둘은 서로 업무 경계 없이 풀스택으로 전환하기로 했다. 이를 위한 인수인계 과정도 겪고, 회원체계 변경 작업 때엔 기능 단위로 업무를 할당해 프론트엔드와 백엔드 모두를 경험했다.

우리의 멘탈 모델은 어떨까? 여전히 '나는 프론트엔드'가 머리에 박혀있는 것 같다. 백엔드도 한다고 말하기엔 백엔드를 너무 모른다. 사실이긴 하나, 못한다는 말 뒤에 숨으면 영원히 발전은 없다. 부족한 걸 인정하고, 어떻게 채울지를 고민하기로 방향을 틀었다.

엔지니어 회의 때 이 고민을 나눴다. 서로 메인파트처럼 하나를 점유하고 있는데 이 경계를 어떻게 허물면 좋을지에 대해서 말이다. 내 아이디어를 제시했다. 프론트든 백이든 하나의 주제를 정해서 같이 공부하고 나누는 방법도 있을 테고. 혹은 서로의 메인파트를 한 사람이 공부해 오고, 이를 발표하면서 토론 해볼지.

접근은 나쁘지 않았으나, 공부는 누적 시간이 필요하다. 달리 말해 지금 당장 해보고 피드백을 주고받기 어렵다. 바로 할 수 있는 걸 생각해보다가 다음주 화요일과 수요일, 이틀 내에 끝내야 할 업무에 적용해보기로 했다. 새 프로젝트 리포를 파고, DB 연결, CI/CD 자동화까지 세팅해서 hello world를 화면에 띄우는 일이다.

기존 프로젝트에서의 아쉬움을 바탕으로 새 프로젝트 스펙을 짜다보니 스펙 문서는 자연스럽게 익숙한 파트인 사람이 작성하게 되었다. 하지만 실행은 반대 사람이 해보는 거다. 각자 파트를 따로 해서 붙이지 말고, 여기에 페어 프로그래밍을 섞는다.

상대적으로 해당 업무가 낯선 사람이 업무를 주도하고, 막히거나 놓쳤을 때 서포터로서 본래 파트 담당자가 도움을 준다.

다만 페어 프로그래밍은 끊임없이 티키타카가 오가는 환경이라 정신적인 소모가 큰 걸로 안다. 게다가 익숙치 않은 일을 주도하는 건 더욱이. 중간중간 쉬는 시간을 의식적으로 만들어 리듬 있게 업무를 완성해보기로 했다.

사소한 의문이더라도 해소하기

기존 플랫폼을 대체할 올인원 프로젝트이다보니 기획 과정에서 청사진을 그리는 것도 일이다. 팀장님이 전체 사이클을 볼 수 있게 바이브코딩으로 만드신 걸 잠깐 봤는데, 그 PoC를 보면서 방향이 의문스러웠다. PoC인데 랜딩이 무척 화려했고, AI 특유의 디자인 때문에 페이지마다 어떤 걸 보여주는지 시각적으로 구분이 어려웠다.

그 당시엔 말을 아꼈지만, 의문이 드는 건 얘기해 보는 게 맞다고 생각했다. 그래서 다음날에 의견을 제시했다.

1. 저번 회의에선 CSS 없이 PoC 만드는 걸로 이해했는데, AI 디자인 방식이면 디자인에 신경이 분산되진 않을지
2. 전체 기능을 다 고려하는 방식인지, 아니면 MVP만 고려한 건지

알고보니 PoC 용도라기보단 내부 공유였다. 청사진이 아직 명확하지 않은 상태에서 스스로 확인하면서 기능을 덧대거나 빼는 용도이기도 했고. 이 과정에서 내가 얻은 건 두 개다: 팀장님이 지금 어떤 일을 무슨 의도로 하시는지 파악했다. 무언가를 보여주거나 설명할 때 의도를 먼저 얘기한 후에 공유해야겠고, 역으로 의도를 못 들었을 땐 먼저 물어보는 게 좋겠다.

사소한 피드백은 업무 외에서도, 그냥 삶의 태도로서 중요하다고 생각한다. 며칠 전에 구글폼을 제출하는데, 연락처의 예시(하이픈 포함)와 실제 동작(숫자만 입력 가능)이 달랐다. 기능의 문제는 없다. 하지만 '연락처 작성'과는 무관한 생각이 사용자에게 발생했으니, 보완이 필요하다고 생각했다.

별거 아니지만 사용자에게 조금 더 정교한 경험을 제공하고 싶은 건 직무 다 떠나서 프로덕트 만드는 이들의 공통 목표일 테니까.

주말 계획은 포스트잇으로

타이핑이 그냥 눈으로 읽는 것보다 학습에 도움 된다는 건 들었다. 손으로 직접 쓰는 건 거기에 추가적인 효과가 있다고 한다. 개인적으로 일하면서도 그림이 잘 안 그려지거나 헷갈릴 땐 노트와 펜을 꺼낸다. 그럼 한결 낫다.

일상적으로는 계획 세울 때 포스트잇을 적극 활용 중이다.

예전엔 플래너 같은 걸 많이 썼는데 수기의 최대 단점은 데이터화가 어렵다는 점이다. 어느 페이지의 어떤 영역에 썼단 걸 어렴풋이 기억할 순 있지만, 효율적이진 않은 것 같다. 고로 상세 내용은 옵시디언으로 정리하되, 주말이나 연휴에 뭐할지는 포스트잇에 키워드로 나열하고, 요일마다 원래 있던 일정을 생각해서 배치한다.

여러 사람에게 짧은 기간 내에 피드백 받기

새 프로젝트 프론트엔드 기술 스펙을 짜면서 피드백을 4번 받았다. 처음은 AI. 첫 피드백을 반영하고서 과장님께 한 번 받았다. 거기서 또 보완 후에 팀장님을 보여 드렸다. 수정을 또 거치고, 다른 엔지니어 분께 보여 드렸다. 그날 받은 피드백으로 다시 한번 전체 스펙을 검토했다.

하루에 한 번 꼴로 피드백을 받았다. 업무하면서 피드백을 의식적으로 요청하면서 과정을 돌이켜 보는 건 처음인데, 확실히 받을수록 내용의 퀄리티가 나아진다. 가독성은 덤이다. 물론 글 쓰는 사람이 기준 없이 피드백만 따르면 어영부영 될 테지만, 그게 아니면 피드백은 여러 사람에게 받을수록 좋다!

Keep, 앞으로 확인할 가설들

AI 시대에 변하지 않는 것

최근 철학과 입학 경쟁률이 118:1이라는 뉴스를 봤다. 그럴 만도 하다. 철학가들이나 좋아하던 주제들이 자본주의 현대인의 삶에 깊숙이 들어왔다.

변하지 않는 것
혹은 변하기 어려운 것

자신의 능력이나 직업을 이 범주에 넣어야 생존에 도움이 된다고 한다. 그런데 나는 이걸 개인 대신에 조직의 차원에서 바라보고 싶다. 그러면 신기하게도 얼어붙었다던 채용 시장이나 경제, 사회가 절망적으로 보이진 않는다.

채용 공고는 개인과 관련된 메시지로 구성되었다. 자격요건과 우대사항 같은 것들. 지원자가 개인이기 때문이다. 그런데 채용하는 입장은? 개인이 아니다. 조직이다.

채용 시장의 조직은 어떤 집단인가? 영리를 추구한다. 언제나 돈을 벌어야 하고, 이전보다 더 많이 벌어야 한다. 인플레이션이 있으니까. 돈을 많이 번다는 건 두 방향이다. 많이 팔거나 비용을 줄이거나. 이걸 같이 만들어 줄 사람을 뽑고자 한다.

다르게 표현하면:

기업은 팀/조직 기반 사고방식을 갖춘 사람을 원한다.

여기서 말하는 기업의 범주에서 지금 당장 이윤을 내는 것에 급급해서 혼자 일당백 해주길 바라는 곳은 제외다. 구직자는 그런 회사를 목표 삼지 않으므로 고려 대상이 아니다.

드라마 미생이 절로 떠오른다. 철강팀 신입 강백기 사원. 훌륭한 스펙을 갖춘 인재다. 그러나 모든 관점이 자신이다. '내'가 보기에 부족한 것, '내'가 보기에 아쉬운 것, '내'가 보기에 맞는 것. 우리 팀을 생각하지 않고, 우리 조직을 이해하지 않는다.

조직 입장에선 골칫거리다. 조직 내부에서 모든 개인은 어떤 일이든 단독으로 해낼 수 없는데 혼자 책임지고 혼자 다 하려고 드니까. 신입에겐 1인분을 바라지 않는다는 말도 여기서 나왔을 거라고 생각한다. 1인분이 되려고 하면 오히려 위험하다. 자신을 조직의 부품으로서 껴넣을 줄 알아야 한다.

조직의 톱니바퀴. 이 표현에 경기를 일으키는 사람이 많다. 나도 그랬다. 특별하고 대단한 일을 하고 싶지 누가 꼭두각시처럼 있으나 마나한 존재가 되고 싶겠는가? 하지만 인간 사회에서 부품으로서 동작하지 않는 인간은 생존할 수 없다. 예외는 없다. 전세계에 영향을 끼치는 기업의 총수도 중소 기업의 말단 직원과 똑같이 자신에게 주어진 역할을 해낼 뿐이다.

그러니 인간 사회에서 살아남기를 원한다면, 내가 속한 팀이 어떻게 하면 더 효율적으로 일할 수 있을지를 고민해야 한다고 본다. 동료가 느끼는 불편함을 어떻게 같이 해소할 수 있을지. 우리가 서로의 일을 어떻게 하면 더 잘 이해할 수 있을지.

어떻게 할 수 있을까? 팀 단위의 피드백 루프를 만들어야 한다고 본다. 새로운 업무 방식이나 문제 의식을 제시하고, 방법을 결정한 후에 실행하고, 피드백하고, 또 새롭게 해보는 것. 한마디로 애자일하게 일하는 것이다. 월간 회고의 목적이기도 하다. 다음달 회고가 어떻게 전개될진 몰라도 페어 프로그래밍 소감은 반드시 포함될 거다.

함께 그려보기

개인 업무에 들어가기 전에 팀원 모두가 화이트보드에 브레인 스토밍하면서 놓친 부분을 점검하는 과정은 꼭 해보고 싶다. 전문가와 비전문가의 차이 중 하나는 계획에서 나온댔다. 사전 계획을 세우고, 전체 관점에서 수정하는 것. 분명 도움이 될 거라고 생각한다.

의도를 가지고 바라보기

살면서 가장 열심히 살았던 순간을 떠올리면 이십대 중반이 떠오른다. 영화 동아리를 운영할 때인데, 말이 동아리지 나는 비영리 조직으로서 관리했던 것 같다.

머릿속엔 항상 이 생각뿐이었다: 어떻게 하면 영화 퀄리티를 높일 수 있을까. 뭘 더 배워야 할까. 새로 들어온 신입들이나 기존 멤버들 모두가 만족할 스터디 방식은 뭘까. 좋은 영화란 뭘까. 좋은 동아리란 뭘까. 촬영 시간을 어떻게 운영해야 딜레이가 줄어들까. 촬영 중에 애들 밥은 뭘 먹일까..

무엇을 보고 듣든 다 연관지어서 생각했다. 그때 배운 것 같다. 의도를 가지고 보면, 아무것도 아닌 평범한 순간에서도 수많은 아이디어를 발견한다. 그 시간들이 쌓여 퀄리티, 즉 가치를 만든다.

2년 간 공들인 노력이 완전히 붕괴된 경험을 해봤기 때문에 몇 년 동안 실패를 두려워했다. 다시 말해, 무언가에 열과 성을 다하고 싶지 않았다.

하지만 이러나저러나 삶은 계속 된다. 이제는 영화나 글쓰기를 비롯한 문화 예술에서 많이 멀어졌다고 생각하지만, 나는 여전히 만들고 있다. 프로덕트를 개발하면서. 협업 방식을 개선하면서. 일정을 관리하면서.

'잘하는 팀'이 최대 관심사인 요즘, 이 관점으로 새로운 도전을 해보며 다음 한 달을 채워가야지.