Intent 기반의 개발

AI에게 기능을 구현해달라고 할 때는 무엇을 만들지 설명한다. 입력과 출력, 화면의 동작, 예외 처리까지 적으면 구현 결과를 확인할 기준이 생긴다. 그런데 그 기능이 내가 만들고 싶은 제품에 맞는지는 무엇으로 판단할까.

사용자가 원하는 일을 대신 처리해줄 수도 있고, 사용자가 스스로 해낼 수 있도록 도울 수도 있다. 어느 쪽을 원하는지에 따라 같은 기능도 다르게 만들어야 한다. 이 선택에는 제작자의 철학이 들어간다.

그래서 제품이 맡을 일과 지킬 원칙을 기록하고, 다음 기능을 고를 때도 그 기록을 참고하려고 한다. 구현을 맡기기 전에 원하는 방향을 구체화하는 일부터 시작했다.

제품이 맡을 일을 먼저 정한다

먼저 제품이 사용자에게 무슨 일을 해주려는지 정한다. 누구의 어떤 문제를 다루는지, 사용자가 무엇을 할 수 있게 만들고 싶은지 적는다. 이 글에서 mission이라고 부르는 것은 그 임무다.

제품이 맡을 일에는 제작자의 가치 판단이 들어간다. 어떤 변화가 좋은 변화인지, 그 과정에서 사용자에게 무엇을 맡기고 무엇을 대신할지는 내가 선택해야 한다. 기능 목록을 늘리기 전에 그 방향을 정해두고 싶었다.

임무를 정해도 선택할 여지는 남는다. 사용자에게 무엇을 추천할지 정하는 제품이라면, 추천을 반드시 따르게 할지 사용자가 바꿀 수 있게 할지 결정해야 한다. 사용자의 선택권을 지키겠다는 원칙이 있다면 후자가 기능의 조건이 된다.

mission에서 출발해 이런 조건을 남겨야 다음 작업에서도 같은 방향으로 판단할 수 있다.

개발 의도를 다음 작업의 판단 기준으로 남긴다

이때 기록하는 개발 의도를 intent라고 부른다. 만들려는 변화, 그 과정에서 지킬 조건, 결과를 확인할 질문을 함께 적는다. 여기서 말하는 intent 기반의 개발은 이 기록을 기능의 선택과 구현, 결과 판단에 이어 쓰는 방식이다.

예를 들어 사용자의 선택권을 지키고 싶다면, 추천을 수정하거나 거절할 수 있게 만든다는 조건을 남길 수 있다. 그렇게 만들었을 때 사용자가 실제로 선택권을 느끼는지는 확인할 질문으로 둔다. 지키기로 한 원칙과 설계의 효과를 구분하는 것이다.

오래 유지할 제품의 방향과 개별 작업의 의도도 구분한다. 제품의 철학은 여러 작업에서 참고할 기준이다. 한 작업의 intent에는 그 기준을 따라 이번에 무엇을 바꾸고 어떤 결과를 확인할지 적는다.

개인의 철학을 mission과 intent로 구체화해 제품의 선택 기준으로 만든다.

개발 흐름에 의도를 연결한다

이 연결을 개발 절차에 넣은 도구가 harness-maker다. AI가 조사하고 명세를 쓰고 구현을 검토하는 작업 절차를 프로젝트에 맞게 구성한다. 제품의 목적과 원칙, 목표를 확인할 지표와 열린 질문을 기록하는 부분을 intent layer라고 부른다.

여기에 코드만으로 알 수 없는 프로젝트의 사실과 현재 작업의 진행 상태를 함께 묶은 것이 world model이다. 다음 작업에서 “무엇을 원했고, 무엇을 알게 됐고, 어디까지 했는가”를 참고할 수 있게 한다. Maker는 이 상태를 읽고 작업을 시작하거나 이어갈 절차로 연결하는 진입점이다.

intent를 연결한 작업에서는 명세를 정할 때 이 작업이 어떤 의도를 위한 것인지 고른다. 조사 → 명세 → 계획과 구현 → 리뷰 → 검증 → 마무리로 이어지는 동안 관련 관측을 모은다. 리뷰에서는 계획이 그 의도와 범위를 벗어나지 않았는지도 확인한다. 마무리할 때는 근거를 확인한 뒤 내가 반영에 동의한 내용만 목표와 질문의 상태에 반영하고, 반영된 상태를 다시 읽어 다음 판단에 쓴다.

이렇게 mission과 intent에서 출발해 결과의 근거를 다음 판단으로 돌려주는 소프트웨어 개발 생애주기(SDLC)로 연결했다. 작업을 끝내도 의도의 달성은 따로 판단하며, 근거가 부족하면 미확인으로 남기거나 관측을 더 기다린다.

SpotOn의 철학을 제품의 조건으로 바꾼다

내가 만드는 테니스 제품 SpotOn의 현재 임무는 플레이어에게 다음에 고칠 한 가지를 알려주는 것이다. 이 임무를 수행하면서 플레이어에게 어떤 경험을 주고 싶은지도 정했다.

• 자신이 수긍하는 목표를 고르고 행동하는 경험. 이를 자율성이라고 한다.
• 무언가를 해낼 수 있고 숙련해간다고 느끼는 경험. 이를 유능감이라고 한다.
• 다른 사람과 연결되어 서로 관심과 돌봄을 주고받는 경험. 이를 관계성이라고 한다.

이 세 가지를 기본 심리 욕구로 다루는 자기결정성 이론(Self-Determination Theory, 이하 SDT)을 SpotOn의 제품 철학으로 택했다. 이를 테니스 제품에 적용하면서, 플레이어가 목표를 고르고 근거가 있는 성장 변화를 확인하며 그 경험을 파트너나 코치와 나누는 방향으로 해석했다.

기존 임무는 유지하고, 그 일을 수행하는 기준을 개발 의도를 기록하는 파일에 더했다. SpotOn에서 쓰는 항목 이름과 내용은 다음과 같다.

기록할 내용	파일의 항목	SpotOn에 남긴 예시
원하는 사용자 변화	vision	자율성·유능감·관계성을 기르며 테니스를 더 오래, 깊이 즐긴다
기능이 지킬 조건	rules	AI 추천을 수정·거절할 수 있게 한다. 능력 표시에는 관측 근거가 있어야 한다. 공유할 항목은 플레이어가 고른다
아직 확인할 가정	open_questions	플레이어가 목표를 직접 고르길 원하는가. 이 설계가 실제 성장과 지속적인 사용으로 이어지는가

철학 전체를 별도 작업 intent로 만들지는 않았다. 이번에 무엇을 바꾸고 어떤 결과를 확인할지 범위가 정해져야 하나의 작업으로 다룰 수 있기 때문이다. 우선 여러 작업이 참고할 방향과 조건, 열린 질문으로 남겼다.

판단 기준을 기능의 명세로 옮긴다

이 기록으로 기능을 설계하려면 구현 결과에서 확인할 수 있는 조건까지 내려가야 한다. 목표 선택 기능에서는 플레이어가 직접 목표를 고르고 AI 추천을 수정하거나 거절할 수 있어야 한다. 명세에 이 조건을 적으면 구현을 검토할 때 추천이 나오는지만 보는 데서 그치지 않고, 사용자가 바꾸거나 거절할 수 있는지도 확인하게 된다.

성장을 보여주는 기능에서는 매력적인 예시에도 제약이 필요했다. 철학 원문에는 게임처럼 능력을 하나씩 얻고 다음 능력의 잠금을 푸는 Skill Tree가 있었다. 그런데 예시로 든 능력 중에는 라켓 센서가 관측할 수 없는 것도 있었다. 그대로 제품에 가져와 표시하면 실제로 확인하지 못한 실력을 확인한 것처럼 보이게 된다.

그래서 제품 범위 안에서 어떤 센서 측정으로 능력을 확인할 수 있는지 검증된 경우에만 그 능력을 표시하거나 잠금을 풀도록 조건을 정했다. 원문을 그대로 적용하는 대신, 제품이 근거를 댈 수 있는 범위에 맞춰 설계 조건을 고쳤다. 사용자가 성장했다고 느끼기를 바란다는 이유로 확인할 수 없는 성장을 보여줄 수는 없다.

코치와 성장 기록을 나누는 기능에도 선택권을 반영했다. 플레이어가 공유할 항목을 직접 고르는 조건이다. 사람 사이의 관계를 도우면서도 공유할 내용의 결정권을 플레이어에게 남기려고 했다.

플레이어가 스스로 해낼 수 있는 일이 늘었다면, AI가 같은 도움을 계속 주기보다 직접 판단하고 실행할 여지를 넓혀주고 싶다. 숙련한 영역에서 AI의 도움을 줄이려는 방향도 여기서 나왔다. 그래서 자동 코칭을 만드는 작업에는 플레이어가 충분히 숙련했다고 판단할 근거와, AI의 어떤 도움을 어떤 조건에서 줄일지 명세에 적도록 했다.

이것들은 다음 기능이 충족해야 할 설계 조건이다. 이 조건을 지키면 플레이어의 능력이 얼마나 좋아지는지, 언제 AI의 도움을 줄여도 되는지는 앞으로 확인할 일로 남아 있다.

구현의 완료와 의도의 달성을 구분한다

명세대로 구현했다면 기능의 동작을 확인할 수 있다. 그다음에는 그 기능으로 원하던 변화가 생겼는지 확인해야 한다. 추천을 거절할 수 있게 구현했어도 플레이어가 선택권을 느끼는지는 사용자 경험을 봐야 한다.

SDT를 철학으로 택했다고 SpotOn의 효과까지 확인된 것은 아니다. 목표를 직접 고르는 일이 어떤 플레이어에게는 부담이 될 수 있고, 능력을 보여주는 방식이 성장보다 평가받는 기분을 만들 수도 있다.

앞서 기록한 열린 질문이 여기서 다시 필요해진다. 목표 선택이 첫 사용을 어렵게 만들지는 않는지 확인해야 한다. AI 개입 없이도 개선이 유지되는지, 파트너와 다시 테니스를 치는지 같은 결과를 어떻게 확인할지도 정해야 한다.

자율성을 지키고 싶다는 것은 내 선택이다. 내가 고른 설계가 그 선택을 잘 실현하는지는 사용자의 경험과 측정으로 판단해야 한다. 기능이 완성됐다는 이유만으로 질문까지 닫을 수는 없다.

다음 작업에도 같은 의도를 연결한다

다음에 만들 기능 하나를 고르고, 구현을 맡기기 전에 세 가지를 적어보면 된다.

1. 이 기능은 제품이 맡은 일 중 어떤 부분을 돕는가.
2. 지키려는 원칙은 무엇이고, 그 원칙 때문에 기능에 어떤 조건이 필요한가.
3. 구현이 끝나면 동작 외에 어떤 사용자 변화를 확인할 것인가.

세 질문의 답을 함께 기록해두면 다음 작업을 검토할 때도 어떤 의도로 만들었는지 돌아볼 수 있다. 기록이 실제로 읽히고 판단에 쓰이는지는 작업 과정에서 확인해야 한다.

지킬 원칙을 다음 기능의 선택 기준으로 써보자.