존중은 검토를 생략하는 일이 아니다

디자인을 받아 개발을 시작했는데, 코드를 쓰다가 다시 디자인을 묻게 된다.

화면이 좁아지면 어떻게 배치해야 하는지, 기존 컴포넌트와 다른 값은 의도된 것인지, 디자인 시스템이 지원하지 않는 부분은 무엇을 기준으로 구현해야 하는지. 개발을 진행하려면 답이 필요하지만, 개발자가 혼자 결정할 수 있는 질문은 아니다.

확인해서 수정하고, 기존 컴포넌트에 별도의 스타일을 덧씌워 맞춘다. 그렇게 구현한 화면은 QA에서 다시 검토된다. 그 과정에서 앞서 정의되지 않았던 부분이 드러나거나, 임시로 맞춘 구현과 디자인 사이의 차이가 문제가 된다. 다시 묻고, 다시 고친다.

한 번의 누락이라면 실수로 받아들일 수 있다. 어떤 작업이든 빠뜨리는 부분은 생긴다. 나도 코드를 작성하며 놓치는 것이 있고, 다른 사람의 검토를 통해 발견한다.

그런데 비슷한 문제가 다음 작업에서도 반복되면 생각이 달라진다.

이번 화면을 수정하는 것으로 끝내도 되는 걸까. 다음에는 같은 질문을 조금 더 앞에서 확인할 수 없을까.

내가 답답했던 것은 디자인이 완벽하지 않다는 사실보다, 부족함을 확인하는 일이 계속 개발 이후로 밀려난다는 점이었다.

모두 바쁘다는 설명만으로는 충분하지 않았다

함께 일하는 환경에서는 한 명의 디자이너가 두 개발팀을 지원하고 있었다. 디자인 기준과 최종 결정은 별도의 조직에 있었고, 현장의 개발자가 그 기준을 임의로 바꿀 수는 없었다.

디자이너의 어려움도 이해했다. 두 팀의 다음 작업을 준비하면서 현재 개발 중인 화면에 답해야 하고, QA에서 돌아오는 수정도 처리해야 한다. 기존 디자인 시스템으로 해결되지 않는 요구가 생기면, 자신이 바로 결정할 수 없는 부분까지 확인해야 한다.

그 상황에서 누락이 생겼다고 디자이너 개인에게 더 꼼꼼해지라고 말하는 것만으로는 충분하지 않다. 이미 부족한 시간 안에서 일하는 사람에게 주의력을 더 요구한다고 해서 처리할 수 있는 일이 늘어나는 것은 아니기 때문이다.

하지만 이해한다는 이유로 지금의 방식을 그대로 두는 것도 이상했다.

디자인에 쓸 시간이 부족해서 생략한 확인은 개발 과정에서 다시 필요해졌다. 개발자가 찾아가 질문하면 디자이너도 하던 일을 멈추고 답해야 했다. QA에서 문제가 발견되면 이미 작성한 코드를 수정하고, 바뀐 화면을 다시 확인해야 했다.

앞에서 쓰지 않은 시간이 뒤에서도 필요 없어지는 것은 아니었다. 내가 겪은 작업에서는 오히려 여러 사람의 일정 사이로 흩어져 있었다.

일정을 맞추기 위해 우선 대략 구현하고 진행하자는 판단도 이해할 수 있다. 어떤 상황에서는 완성도를 낮추거나 일부 결정을 미루는 선택이 필요하다. 다만 무엇을 미루었는지, 그 때문에 어떤 재작업을 감수하는지까지 함께 알아야 한다고 생각한다.

그 비용이 보이지 않으면, 앞에서는 빨리 진행한 일이 뒤에서는 개발자의 반복 수정으로만 남는다.

나는 사람을 원인으로 지목하는 일을 가능한 한 뒤로 미루려 한다. 그 전에 작업 방식에서 바꿀 수 있는 것을 먼저 찾고 싶다.

이번에도 먼저 묻고 싶었던 것은 누가 일을 못했느냐가 아니었다.

왜 우리는 준비되지 않은 부분을 개발을 시작한 뒤에야 확인하고 있을까.

이미 정해진 것을 다시 묻는 일

디자인 시스템이 있다는 점은 이 의문을 더 크게 만들었다.

공통 컴포넌트와 기준이 있다면, 반복되는 화면에서는 그 기준을 재사용할 수 있어야 한다고 생각했다. 이미 정해진 버튼의 크기나 간격을 화면마다 다시 해석하고, 그 차이를 맞추기 위해 개발 코드에 예외를 추가하는 일은 줄어들어야 하지 않을까.

물론 디자인 시스템만으로 모든 화면이 완성되지는 않는다.

버튼과 입력창이 있다고 해서 복잡한 업무 흐름까지 정해지는 것은 아니다. 표를 좁은 화면에서 어떻게 보여줄지, 여러 기능 중 무엇을 먼저 드러낼지, 기존 규칙으로 설명되지 않는 상황을 어떻게 처리할지는 별도의 설계가 필요할 수 있다.

내가 디자인에서 모르는 어려움도 있을 것이다. 컴포넌트를 가져다 쓰면 된다는 개발자의 시선만으로 실제 작업 전체를 설명할 수는 없다.

그래서 더 구분하고 싶었다.

새로운 판단이 필요한 부분과, 이미 내려진 판단을 정확하게 적용해야 하는 부분을.

기존 기준과 다른 값이 있다면 그것이 의도된 예외인지, 적용 과정에서 생긴 누락인지 알아야 한다. 필요한 규칙이 디자인 시스템에 없다면 누가 결정할 것인지 드러나야 한다. 아직 정하지 못했다면 미정이라고 표시되어 있어야 한다.

그 원인을 매번 개발자가 구현하면서 추적하는 대신, 전달 전에 한 번 확인할 수는 없을까.

내가 기대한 것은 모든 디자인 문제를 복사와 붙여넣기로 해결하는 일이 아니었다. 이미 정해진 것까지 다시 묻느라 시간을 쓰지 않는 일이었다.

전문성을 존중하는 것과 검토를 면제하는 것은 다르다

개발에는 어떻게 구현할지 설명하고 검토받는 과정이 있다.

어떤 방식을 선택할지, 기존 코드에 어떤 영향을 주는지, 예상되는 위험은 무엇인지 공유한다. 코드를 작성한 뒤에도 다른 사람이 읽고 질문한다. 놓친 조건이 없는지, 기존 기준을 지켰는지, 이후에 변경하기 어려운 구조는 아닌지 확인한다.

나는 그 과정을 개발자의 전문성을 부정하는 일이라고 생각하지 않는다. 전문적인 판단에도 설명이 필요하고, 작성한 사람이 보지 못한 부분이 있을 수 있기 때문이다.

그렇다면 디자인에도 대응되는 과정이 필요하지 않을까.

무엇을 기존 기준으로 해결할 것인지, 어디에 새로운 판단이 필요한지, 개발에 넘기기 전에 무엇을 확인했는지 설명하는 과정 말이다.

이 생각을 정리하다가 오래 남겨두고 싶은 문장이 생겼다.

디자인의 전문성과 결정권은 존중한다. 그렇다면 기존 기준을 준수했는지, 무엇이 미정인지, 개발에 전달할 준비가 됐는지도 확인해야 한다. 개발이 코드 리뷰를 받듯 디자인 산출물도 검토 대상이어야 한다.

내가 요구하는 것은 디자인 결정권이 아니다.

개발자가 디자인의 좋고 나쁨을 최종 판정하거나, 구현하기 편하다는 이유로 사용자 경험을 마음대로 바꾸자는 뜻도 아니다. 디자인의 방향과 예외는 그 권한을 가진 사람이 결정하면 된다.

검토는 결정을 여러 사람에게 흩어놓는 절차도 아니다. 어떤 작업에도 최종 의사결정권자는 있어야 한다. 그 일을 실제로 추진하는 DRI(Directly Responsible Individual)가 의견과 검토 결과를 모아 결정하고, 실행과 결과에 책임져야 한다.

DRI가 있다는 이유로 질문을 막을 필요도 없고, 여러 사람이 검토했다는 이유로 책임이 흐려져서도 안 된다. 검토자는 빠진 근거와 위험을 드러내고, DRI는 그것을 받아들일지 예외를 둘지 결정한 뒤 그 이유를 남긴다.

다만 그 결정을 이어받아 구현하는 사람은 질문할 수 있어야 한다.

기존 기준과 다른 이유가 무엇인지, 아직 정하지 않은 동작은 무엇인지, 이 정보만으로 구현을 시작해도 되는지 확인하는 것은 권한에 대한 도전이 아니다. 자신의 작업에 필요한 조건을 확인하는 일이다.

반대로 개발자가 검토에 참여한다는 이유로 디자인의 기본적인 점검까지 전부 맡아야 하는 것도 아니다. 코드 리뷰가 작성자의 사전 확인을 대신하지 않듯, 구현 가능성 검토가 디자인 담당자의 셀프체크를 대신해서는 안 된다고 생각한다.

각자 확인해야 할 부분이 있고, 함께 보아야 할 부분이 있다. 그 경계가 지금보다 명확했으면 했다.

체크리스트를 만든 뒤에도 결정은 남는다

그래서 디자인에도 작업 계획과 전달 전 체크리스트, 필요한 컨펌 절차가 있어야 한다고 생각하게 됐다.

처음부터 긴 보고서를 떠올린 것은 아니다. 기존 컴포넌트를 어떻게 사용할지, 새로 정해야 할 부분은 무엇인지, 다른 조직의 확인이 필요한지 정도만 먼저 드러나도 도움이 될 것 같았다.

작업을 마친 뒤에는 기존 기준을 맞게 적용했는지, 필요한 화면 대응과 상태가 정의되어 있는지, 예외와 미정 사항이 표시되어 있는지를 확인한다.

모든 경우를 새로 그릴 필요도 없다. 기존 규칙으로 충분한 부분은 그 규칙을 참조하면 된다. 중요한 것은 화면의 수가 아니라, 다음 사람이 어떤 기준을 따라야 하는지 알 수 있는가다.

그런데 여기서 멈추면 체크리스트도 디자이너의 할 일 하나를 늘리는 데 그칠 수 있다.

확인해 보니 준비되지 않은 부분이 있다면, 그다음에는 누가 무엇을 해야 할까.

디자인 결정이 필요하면 그 일을 맡은 DRI가 답하고 결과에 책임져야 한다. 한 명이 두 팀의 요구를 감당할 수 없다면 우선순위를 조정해야 한다. 이번 작업에 필요한 결정이 제때 나오지 않는다면 범위를 줄이거나 일정을 다시 논의해야 한다.

그런데 체크 결과와 관계없이 결국 같은 범위와 같은 일정으로 진행해야 한다면, 미정 사항을 표시하는 것만으로 현실이 달라지지는 않는다. 부족한 부분은 다시 개발자와 디자이너가 작업 도중 메우게 될 것이다.

따라서 내가 바라는 점검은 누락을 발견해 담당자에게 돌려주는 절차만은 아니다. 발견된 문제에 따라 실제로 결정하고, 일을 조정할 수 있는 과정이어야 한다.

완벽한 디자인이 나올 때까지 모든 개발을 멈추자는 뜻도 아니다. 아직 미정인 부분과 독립적으로 진행할 수 있는 작업은 먼저 할 수 있다. 다만 결정되지 않은 UI까지 완성하기로 약속한 뒤, 남은 판단을 구현 과정에 맡기는 방식은 구분하고 싶다.

이 과정이 생기면 개발자는 분명 편해질 것이다.

나는 그것이 잘못된 결과라고 생각하지 않는다. 줄이고 싶은 것은 필요한 협의가 아니라, 같은 누락을 반복해서 확인하는 일이기 때문이다.

디자이너에게 질문하지 않겠다는 것이 아니다. 다음 작업에서도 같은 질문을 처음부터 다시 묻고 싶지 않은 것이다.

AI로 코드를 빨리 만들어도 남는 것

AI를 활용하는 지금은 이 문제가 더 눈에 들어온다.

나는 코드를 더 빠르게 작성하고, 여러 작업을 효율적으로 진행하는 방법에 관심이 많다. 그런데 구현 속도를 높이는 일에 집중할수록, 그 앞에서 정해져 있어야 하는 것이 무엇인지도 다시 생각하게 된다.

모호한 디자인을 AI에 넘겨 그럴듯한 화면을 얻었다고 하자. 화면이 만들어졌다는 사실만으로 빠져 있던 결정까지 승인된 것은 아니다.

좁은 화면에서 무엇을 숨겨야 하는지, 기존 디자인 시스템과 다른 값을 써도 되는지, 특정 동작이 제품의 의도와 맞는지는 여전히 확인해야 한다. AI가 빈칸을 채울 수는 있어도, 그 빈칸을 채울 권한까지 저절로 생기는 것은 아니다.

AI가 맡을 수 있는 일은 결정권을 대신하는 것보다, 합의한 기준을 같은 방식으로 먼저 대조하는 데 가깝다. 필요한 상태가 빠졌는지, 기존 컴포넌트와 다른 값이 있는지, 미정 사항이 표시되어 있는지를 작업자와 관계없이 확인할 수 있다.

코드 리뷰 도구가 테스트 실패와 규칙 위반을 먼저 보여줘도 최종 리뷰는 사람이 하듯, AI가 발견한 차이도 대화의 시작이어야 한다. 예외가 필요한 이유를 설명하고, 기준 자체가 잘못됐다면 함께 고쳐야 한다.

개발자인 나에게도 같은 기준이 적용된다. AI가 코드를 작성했다고 해서 구현 방식을 설명하고 결과를 검토할 책임이 없어지지는 않는다.

그래서 나는 AI를 도입하는 일과 작업의 전달 기준을 정리하는 일이 떨어져 있지 않다고 생각한다. 빠르게 만드는 능력을 얻었다면, 무엇을 만들고 있는지 확인하는 과정도 함께 살펴봐야 한다.

코드를 쓰는 시간이 줄어도, 정해지지 않은 것을 되묻고 다시 만드는 시간이 그대로라면 내가 기대하는 생산성과는 거리가 있다.

이번에는 전달하는 방식도 고쳐보고 싶다

아직 이 절차를 도입해 어떤 효과가 있었는지 말할 수는 없다. 지금 정리한 것은 검증된 성공 사례가 아니라, 반복되는 문제를 보며 먼저 바꿔보고 싶어진 지점이다.

실제로 적용한다면 체크 항목을 얼마나 많이 채웠는지보다 개발 중에 다시 묻는 일이 줄었는지 보고 싶다. QA에서 뒤늦게 결정해야 하는 일이 줄었는지, 디자이너가 두 팀의 질문 사이를 오가며 같은 내용을 반복해서 설명하는 일이 줄었는지도 확인하고 싶다.

검토 시간이 늘었는데 재작업은 그대로라면 그 절차 역시 다시 바꿔야 할 것이다. 프로세스를 만들었다는 사실만으로 개선했다고 말하고 싶지는 않다.

답답함이 쌓이면 사람에게 시선이 간다. 왜 이 정도 확인이 안 되어 있는지, 왜 같은 일이 반복되는지 묻게 된다. 그 감정이 없었다고 쓰고 싶지는 않다.

다만 내가 오래 붙잡고 싶은 질문은 다른 쪽에 있다.

누군가 더 꼼꼼해지기를 기다리는 것 말고, 지금의 방식에서 고칠 수 있는 것은 무엇일까. 기존 기준을 확인하고 미정 사항을 드러내는 일을 개인의 여유나 성향에만 맡겨두지 않을 수는 없을까.

전문성을 존중한다는 말은 상대의 일을 묻지 않겠다는 뜻이 아니라고 생각한다. 서로의 판단을 이해하고, 다음 사람이 이어서 일할 수 있도록 필요한 설명과 확인을 주고받는 쪽에 더 가깝다.

나는 이번에도 화면을 고치게 될 것이다. 다만 이번에는 코드만 고치고 끝내지 않고, 그 코드를 다시 고치게 만든 전달 과정도 함께 살펴보고 싶다.

검토를 시작하면 서로 다른 기준이 드러나고 마찰이 생긴다. 다음 질문은 그 마찰을 누군가의 기분과 기억에만 남기지 않는 방법이다.

다음 글: 마찰은 시스템에 남아야 한다 →