쉬는 날, 가족과 함께 시간을 보내면서 진로에 대한 고민을 했다. 3년간 개발을 해왔는데 “완성된 프로젝트가 하나도 없다” 는 사실이 계속 마음에 걸렸다. 적성을 잘못 잡은 건 아닐까, 다른 길을 찾아야 하는 건 아닐까. 그 의문을 AI에 던지면서 시작한 대화가, 의외로 내 개발 방식 자체를 바꾸는 결론으로 이어졌다.
Table of contents
Open Table of contents
시작 — “내가 잘하는 게 뭔지 모르겠다”
AI에게 “잘하는 일을 어떻게 찾나” 를 물어봤다. 돌아온 답: 남이 부탁한 일, 시간 가는 줄 모르고 몰입한 일, 성과를 낸 일을 적어보라. 적어보려고 했는데 막막했다. 떠올린 경험들도 “다들 겪는 일 아닌가” 싶어 적을 게 없어 보였다.
그래서 그냥 직장에서 한 일을 시간순으로 쭉 적어봤다. 문과 출신으로 시작해 임베디드 하드웨어 설계를 배우고, OrCAD로 PCB 디버깅을 했고, C 언어를 독학하면서 자격증을 땄고, 임베디드 SW를 유지보수했고, 엣지 AI 가능성을 보기 위해 객체 인식 / 화재 감시 모델 전이학습을 직접 만들어 개발보드에 올려봤다는 흐름.
쓰면서도 “이게 다 특별한 일은 아닐 거야” 라고 생각하면서 적었다. 그런데 돌아온 답이 완전히 예상 밖이었다.
진단 — “적성의 문제가 아니라 자기 평가 회로의 문제”
“본인은 지금 적성을 못 찾는 게 아니라, 잘한 걸 잘했다고 인정하는 회로가 망가져 있는 거예요.”
“1등이 아니면 0점으로 처리하는 채점 방식이에요. 이건 적성의 문제가 아니라 자기 평가 기준의 문제예요.”
머리를 한 대 맞은 느낌이었다. 한 줄 한 줄이 다 와닿았다.
- 노래를 잘한다는 말을 들어도 “나보다 잘하는 사람이 있으니 나는 부족하다” 고 해석했다. 이 기준이면 세상 누구도 잘하는 게 없다.
- 3년간 일했는데 포트폴리오가 하나도 없는 건, 만든 게 없어서가 아니라 “완성·납품” 단 하나의 기준을 통과 못 하면 전부 없는 셈 치기 때문이다.
- 프로젝트를 시작했다가 마음에 안 들면 전부 지우고 처음부터 — 이 패턴도 결국 같은 뿌리. “완벽하지 않을 걸 알면서 차라리 없애버리는 방어 행동.” 그러면 미완성을 마주할 필요가 없으니까.
이걸 듣고 또 하나 깨달았다. 내가 “완벽주의를 없애려고” 노력해온 것 자체가 완벽주의가 하는 일이었다. 완벽주의자는 자기 결점도 완벽하게 해결하려고 한다. 그러다 안 되면 또 자기를 깎아내린다. 무한 루프.
전환 — “완벽주의를 없애지 말고 활용하자”
발상을 바꿨다. 완벽주의가 사라지지 않는다면, 그 에너지를 어디에 흘려보낼지를 설계하는 게 훨씬 현실적이다. 그러기 위해서는 내가 어떤 방식으로 일할 때 완벽주의가 독이 아니라 약이 되는지를 알아야 한다.
다행히 그 패턴은 내 경험 속에 이미 있었다. 나는 막연한 한 줄짜리 큰 그림에서 출발해서, 그걸 점점 작게 쪼개면서 방향이 또렷해질 때 가장 즐겁게 일했다. 작은 한 덩어리를 완성하면 거기서 성취감을 얻고, 그 힘으로 다음 덩어리로 넘어갔다.
이 방식을 가리키는 용어가 있었다.
수직 슬라이스(vertical slice) / 점진적 개선(incremental development).
핵심 — 가로로 쌓지 말고 세로로 자른다
이 그림이 내가 잡고 가야 할 핵심을 한 장에 담고 있었다.
가로 쌓기 — 완벽주의의 함정
1주차: 모터 제어를 완벽히
2주차: 카메라 검출을 완벽히
3주차: 판단 로직을 완벽히
4주차: 여기서야 처음으로 전체가 한 번 돌아감4주차까지 “작동하는 것” 이 없다. 그 전에 지치면 남는 게 0이다. 내가 매번 빠지던 패턴.
세로 자르기 — 수직 슬라이스
슬라이스 1: 카메라: 대충 봄
판단: 대충
모터: 살짝 움직임
→ 엉성해도 작동!
슬라이스 2: 카메라: 더 정확히
판단: 더 똑똑히
모터: 부드럽게
→ 더 나아짐!
슬라이스 3: 장애물 회피 추가
속도 조절 추가
ROS로 정리
→ 완성에 가까워짐슬라이스 1부터 “작동하는 전체” 가 손에 있다. 어디서 멈춰도 굴러가는 게 남는다.
핵심: 기능을 “완성도”가 아니라 “끝에서 끝까지 관통하는 얇은 한 줄”로 자른다. 카메라 → 판단 → 모터 라는 전체 경로를 엉성하게라도 먼저 한 번 잇는 것 이 시작점.
내가 이 방식과 맞는 이유
이 방식이 내게 맞는 이유는 분명하다. 완벽주의의 핵심 동력 — “이 부분은 더 잘하고 싶다” — 가 슬라이스 2, 3, 4로 자연스럽게 흘러간다. 가로 쌓기에서는 “이 부분이 완벽해질 때까지 다음으로 못 넘어가” 가 발목을 잡는데, 세로 자르기에서는 같은 완벽주의가 “이번 슬라이스에서 더 좋게 만들 부분이 있다” 라는 개선 동력으로 바뀐다.
또 한 가지 — 이미 한 일이 “0이 되지 않는다.” 슬라이스 1이 엉성해도 그 자체로 “작동하는 무언가” 다. 다음에 더 안 한다 해도 거기서 멈출 수 있고, 멈춰도 결과물이 남는다. 포트폴리오가 0개일 일이 없어지는 것.
정리
- 완벽주의는 없애지 못한다. 인정하고, 작동하는 방향으로 흘려보낼 설계가 필요하다.
- 가로 쌓기(단계별 완벽 추구) 는 완벽주의자의 함정. 작동하는 것이 마지막에야 나오므로 중도에 지치면 0.
- 세로 자르기 / 수직 슬라이스 — 엉성해도 끝에서 끝까지 관통하는 얇은 한 줄을 먼저 만들고, 슬라이스마다 점점 두껍게.
- 이 방식의 진짜 가치는 “완성품을 빨리 보는 것” 보다 “이미 한 일이 0이 되지 않게 잡아주는 것”.
더 공부해볼 것
1. 소프트웨어 공학에서의 Vertical Slice / Walking Skeleton
- Walking Skeleton 패턴 (Alistair Cockburn) — 가장 얇은 end-to-end 동작 가능 시스템부터 시작
- Tracer Bullet 개발 (Pragmatic Programmer) — 같은 사상의 다른 표현
- 애자일에서 user story를 자를 때 “horizontal slice vs vertical slice” 논쟁
- 참고: Walking Skeleton — Alistair Cockburn
2. MVP / 점진적 출시 방법론
- Lean Startup 의 MVP 정의와 흔한 오해 (“최소”가 “형편없음” 이 아니라 “검증 가능”)
- Continuous delivery, feature flags 를 활용한 점진적 출시
- Phase 1 → Phase 2 식 개발에서 각 Phase의 release 기준을 어떻게 정할지
3. 완벽주의와 생산성의 관계 (메타)
- 건강한 완벽주의 (Adaptive Perfectionism) vs 부적응적 완벽주의 의 구분
- “Done is better than perfect” 원칙이 실제로 적용되는 사례
- 자기 평가 기준이 학습 결과에 미치는 영향 (성장 마인드셋 vs 고정 마인드셋)
4. 직접 실험해볼 것
- 진행 중인 1인 앱 개발과 부산 공공데이터 대회 프로젝트에 수직 슬라이스 원칙을 의식적으로 적용해보기
- Phase 정의 시 “이 슬라이스만으로 작동하는 데모가 나오는가” 를 통과 기준으로 강제
- 슬라이스 1 → 2 사이에 결과물을 누군가에게 보여주는 단계 끼우기 (검증 + 외부 피드백)
5. 자기 평가 회로 다시 잡기
- “1등이 아니면 0점” 패턴이 나타나는 순간을 의식적으로 카운트
- 작은 슬라이스를 완성할 때마다 “이것도 결과물이다” 로 명시적으로 기록 (이 블로그가 그 도구)
회고
이 글을 쓴 목적은 “내가 개발할 때 어떤 방식이 맞는지” 를 기억하기 위해서다. 다음에 또 막연해질 때, “가로로 쌓고 있지는 않은가?” 를 자문할 기준점.
완벽주의가 약점이 아니라 잘 흘려보내면 동력이 되는 에너지 라는 게 오늘의 결론. 없애려고 싸우는 데 쓰던 힘을, 슬라이스 다음 슬라이스로 흘려보내는 데 쓴다. 그러면 손에 남는 게 0이 될 일이 없다.