AI 시대, 개발자들에게 필요한 것은 기획 능력

들어가며

LLM 에이전트 시대에 개발자는 AI 팀원들을 데리고 일하는 팀장이 돼야 합니다. 코딩은 AI 에이전트들이 훨씬 빠르게 할 수 있기 때문에, 사람의 역할이 달라진 것입니다. 이제 코딩 능력만큼이나 AI 팀원들이 올바른 방향으로 나가고 있는지 아는 능력이 중요합니다.

기획 능력이 중요한 이유는 개발자들이 AI 에이전트 팀원들을 데리고 비교적 완결적인 작업들을 해야 하기 때문입니다.

이전에 주니어들이 하던 작업단위는 한 기능의 부분에 해당하는 작업이곤 했습니다. 예컨대 모바일 웹사이트 디자인 갱신 프로젝트라면 “제목 아래 부제 줄간격 넓히기” 같은 작업입니다.

그러나 앞으로는 “TTS 기능 구현” 같은 식으로 진행하는 작업이 더 많아질 것입니다.

기획의 원리 자체는 AI 시대에도 달라지지 않습니다. 다만 AI는 우리 조직의 목적이나 이용자들의 맥락을 저절로 알지 못합니다. 우리가 알고 있는 맥락을 살피고 판단해 AI에게 전달하는 일이 중요해졌습니다.

이런 능력이 이 글을 읽는다고 단숨에 길러지지는 않을 것입니다. 그러나 기획 능력 또한 원리를 통해 배울 수 있다는 점을 강조하고 싶습니다. 간단한 이야기지만, 나름의 방향을 잡는 데 도움이 될 수 있을 것입니다.

1. 목적이 가장 중요하다

기능의 목적

기능을 기획할 때, 혹은 프로젝트를 진행할 때 가장 중요한 것은 목적입니다. 이를 설명하기 위해서 몇 가지 프로젝트의 목적을 예로 들어 보겠습니다.

어떤 교육 기관이 나뉘어 있던 기관 소개 사이트와 교육 자료 사이트를 통합한다고 해 봅시다. 목적은 단지 자료를 제공하는 곳이 아니라 교육 프로그램을 운영하는 기관이라는 점을 보여 주는 것입니다. 이를 위해 가장 중요한 것은 메인 내비게이션일 수 있습니다. 사람들이 웹사이트를 둘러볼 때 가장 먼저 살펴 보는 곳에 기관의 활동을 드러내야 하기 때문입니다.

어떤 시스템이 초창기 설계 미흡으로 이름을 ID로 관리하고 있었다고 해 봅시다. 이제 모든 상품에 ID를 부여하기로 결정했습니다. 이 때 이 작업의 목적은 운영 효율화와 데이터 신뢰성입니다. 기존에는 상품명이 변경되면 데이터 정합성이 깨져 통계를 신뢰할 수 없게 되고, 이를 보정하기 위해 수동으로 데이터를 바로잡아야 해 커다란 비효율이 발생했던 것입니다. 그렇다면 상품을 ID로 관리하는 작업은 사이트 전체에 걸쳐 새 데이터와 옛 데이터 모두에서 데이터 신뢰성을 확보하는 방향으로 나가야 합니다.

구현할 때 이야기긴 합니다만, 기획을 AI에게 전달할 때도 “상품을 ID로 관리하게 바꿔 줘”라고만 하기보다, “상품명이 바뀌면 통계가 틀어지고 수작업 보정이 필요하다. 이름이 바뀌어도 기존·신규 통계의 일관성을 지키도록 ID 기반으로 바꾸자”라고 목적과 이유를 함께 전달할 수 있습니다.

이렇듯, 목적은 단순하고 당연해 보이지만 기능이 나아갈 방향을 잡아 줍니다. 아무리 간단해 보이고 당연한 목적이라도 기획을 할 때 명문화해서 적어 보는 것이 도움이 됩니다.

조직의 목적

목적을 생각할 때 조직의 목적, 이를 통해 우리 조직이 이루려고 하는 것은 무엇일까 하는 점도 생각해야 합니다. 기업으로 치면 비즈니스 목적입니다. 앞의 통합 사이트라면 자료를 찾으러 온 사람들이 교육 프로그램에도 참여하게 하는 것이 조직의 목적일 수 있습니다. 상품 ID 관리는 데이터 신뢰성 확보를 통해서 담당자들의 업무를 효율화하는 데 있습니다. 틀린 통계와 씨름하거나 이를 보정하는 데 들이는 시간을 줄이면, 그만큼 다른 활동에 시간을 쓸 수 있습니다.

목적과 구현 사이에서 목적이 훨씬 중요한 층위입니다. 구현이 목적을 이기지 못한다는 것이죠. 아름답고 훌륭한 코드지만 조직의 목적을 충족시키지 못하는 구현과, 투박한 코드지만 목적을 충족시키는 구현이 있다면 당연히 후자가 낫습니다. 때때로 엉망으로 보이는 소프트웨어가 멋들어진 소프트웨어를 이기는 이유 중 하나입니다.

예컨대 2011년 어느 지하철역의 보증금환급기에 A4 용지로 큼지막하게 “500 원 받는 곳”이라고 붙어 있는 것을 보고 박수를 친 적이 있습니다. 띄어쓰기도 틀렸고 중앙 정렬도 안 맞았지만 지하철 노동자들의 수고를 덜어준다는 목적에 딱 맞는 구현이었습니다.

신한은행의 ATM기 디자인 변경 사례도 목적에 맞는 구현 사례로 참고할 만합니다. 신한은행은 ATM기를 이제는 주로 노인들이 사용한다는 점에 착안해 심플하게 UI를 수정했습니다. 주요 기능 4가지를 강조하고, 버튼색상도 노인들의 시인성을 고려했습니다. 투박해 보이지만 목적에 대한 고려가 들어간 디자인입니다.

다시 말해 기획이란 목적을 구체적인 UI와 UX로 번역하는 작업이라고 할 수 있을 것입니다. 이것은 이용자들을 염두에 둬야 한다는 두 번째 원칙으로 우리를 이끕니다.

2. 이용자들의 입장에서 생각해야 한다

일반 원칙

기획에서 두 번째로 중요한 것은 이용자들의 입장에서 생각해야 한다는 점입니다. 이용자들의 목적, 이용 상황, 그리고 이용자들이 UI를 어떻게 이해하고 사용할지 고려해야 합니다. 물론 기능에 따라 각각의 비중은 달라질 수 있습니다.

예컨대 TTS(Text to Speech) 기능을 만든다면, 사람들은 언제, 어떤 상황에서 왜 이 기능을 사용할지 생각해 봐야 합니다. TTS 버튼을 사람들이 어떻게 생각할지 떠올려 봐야 합니다.

검색 기능을 만들 때도 사람들이 단일한 목적으로 검색을 사용하는 것이 아니라는 점을 염두에 둬야 합니다.

폭넓게 찾기
- 특정 주제나 인물, 사건
- 볼 만한 영화나 책
좁게 찾기
- 특정 주제를 잘 다루는 하나의 글
- 예전에 봤던 어렴풋한 기억 속 기사
- 제목이나 구절을 명확히 아는 기사
- 특정 인용구 전문

학습과 토론

목적과 상황에 대해 생각할 때 일단 나 자신의 경험에서 출발할 수 있습니다. 나 자신이 그 서비스의 이용자라면 말입니다. 특히 소수가 쓰는 서비스인데 내가 핵심 이용자일 때는 기획이 매우 훌륭해질 수 있습니다.

그런데 사용자층이 넓어질 때는 나만의 경험으로는 한계가 있습니다. 학습과 토론이 필요합니다.

우선 학습으로 익힐 수 있는 웹사이트의 기본 원리들이 있습니다. 사람들이 익숙한 UI를 어떻게 이해하고 사용하는지 정리해 둔 것입니다. 이런 것들은 잘 정리된 책을 보면 됩니다.

예컨대 다음은 기본적으로 고려할 관례들입니다. 모든 상황에 똑같이 적용되는 법칙은 아니지만, 대체로는 적용됩니다.

웹사이트 본문에서 색깔이 다르거나 밑줄이 있는 글자는 링크로 받아들이기 쉽다
버튼은 클릭할 수 있다는 것을 알아볼 수 있게 보여야 한다
움직이는 것은 시선을 빼앗는다
검색창처럼 한 줄로 입력하는 폼은 엔터로 제출할 수 있어야 한다
숫자만 입력할 수 있는 필드에는 숫자 키패드를 띄워 줘야 한다
기능 오류가 발생했을 때 폼에 입력된 것을 모두 초기화하는 것은 이용자를 쫓아내는 일이다
폼 입력을 취소하는 버튼은 보통 필요 없다
등등

그러나 일반적이지 않은 기능을 만들 때는 토론이 필요합니다. 사람이 많아질수록 이용자들에 대한 정보도 많아지므로 토론이 도움이 됩니다.

예컨대 읽기 설정 기능을 만든다면 글자 크기, 문단 간격, 줄바꿈 방식 등 여러 설정을 떠올릴 수 있습니다. 기획안을 가지고 토론하다 보면 문단 간격, 줄바꿈 방식 설정은 우리 제품에는 굳이 필요하지 않다고 의견이 모여 제거할 수도 있습니다. 이용자들이 많이 쓸 만한 기능에 집중하고 기능 자체도 집중성을 갖게 하자는 것입니다.

버튼에 사용하는 단어도 이용자의 입장에서 생각해 봐야 합니다. 예컨대 “정기구독” 버튼은 종이 잡지 구독인지, 뉴스레터 구독인지 알기 어려울 수 있습니다. 이제 사람들에게 구독이란 단어가 종이 매체만을 연상시키지 않기 때문입니다. “지면 구독”처럼 무엇을 구독하는지 밝히는 단어를 사용할 수 있습니다.

이용자들의 반응에 따라 버튼의 순서를 변경할 수도 있습니다. 예컨대 메신저 채널과 뉴스레터를 함께 운영한다면, 뉴스레터를 구독하고 있고 좋았다는 반응이 많을 때 뉴스레터 구독 버튼을 먼저 보여 주는 것을 생각해 볼 수 있습니다.

사람을 직접 앉혀 놓고 작업하는 것을 뒤에서 관찰하는 것은 통찰을 얻는 좋은 방법입니다. 가족이나 동료에게 기능을 사용해 보라고 하고 관찰하는 것만으로 사람들이 기능에서 어떤 부분을 어려워하는지 금세 알 수 있습니다.

기능 구현 전 기획을 그림으로 그려 보여 주고 사용해 보라고 하는 것만으로도 도움이 됩니다. 그림을 여러 장 그려서, 클릭하면 종이를 바꿔가면서 실제 인터페이스처럼 흉내낼 수도 있습니다. 요즘은 AI를 활용해서 프로토타입 HTML을 작성하게 해볼 수도 있습니다. AI 시대의 장점입니다.

이때 핵심은 관찰하는 동안 사용법을 먼저 설명하지 않는 것입니다. “이 버튼을 눌러 봐라” 하고 말하면 테스트의 효과는 사라집니다. 예컨대 “이 기사를 소리로 들어 보세요” 하고 이용자에게 목표를 제시해야 합니다. 그래야 이용자가 어디서 막히는지 알 수 있습니다.

데이터 수집 기능을 이용해 이용자를 간접 관찰하는 방법도 있습니다. 촘촘한 로그로 이룰 수 있습니다.

조금 다른 이야기지만, 같은 맥락에서 사람들의 요구를 귀 기울여 들어야 하기도 합니다. 긴 글에 “읽던 위치에서 이어 읽기” 기능을 만들어 달라는 요구가 있다면, 사람들이 긴 글을 한 번에 읽기 어려워한다는 필요를 살펴볼 수 있습니다. 글 하단의 맨 위로 화살표나 글자 크기 조절 단계도 사람들의 요구를 민감하게 듣고 반응해 기획할 수 있는 기능입니다.

개발자 자신이 핵심 이용자일 때

검색 로그나 이용자들의 요구를 살피면 이미 제공하는 기능을 사람들이 어떻게 쓰는지, 무엇을 불편해하는지 알 수 있습니다. 하지만 아직 제공하지 않는 기능에 대한 필요가 이런 기록으로는 잘 드러나지 않습니다.

개발자 자신이 서비스를 자주 쓰는 사람이라면, 직접 사용하며 발견한 필요에서 새로운 기능을 제안할 수 있습니다. 이 경험은 두 방향으로 이어질 수 있습니다. 기술과 이용 환경이 바뀌는 흐름을 보며 앞으로 필요해질 기능을 예상할 수도 있고, 개발자가 핵심 이용자로서 느낀 필요가 다른 이용자들의 필요와 맞을 수도 있습니다.

예컨대 글을 깔끔하게 인쇄해 보고 싶은 개발자라면 인쇄 기능을 기획할 수 있습니다. 온라인에 올라온 글을 집중해 읽게 하려는 목적도 있겠지만, 자신이 자주 쓰는 기능이기에 필요한 것을 잘 알 수 있습니다. 자신의 필요가 다른 이용자들의 필요와도 맞을 수 있는 경우입니다.

전자책 리더기에서 글을 읽는 개발자라면 epub 생성 기능을 생각해 볼 수 있습니다. 10년 전에 만들었다면, 당시에는 큰 반향을 얻지 못했더라도 태블릿 이용자가 늘고, 전자책 앱에 읽어주기 기능이 생기고, 긴 글이 많아지면서 사용하는 사람들이 늘어났을 것입니다. 개인의 읽기 방식에서 출발해 기술과 이용 환경의 변화를 내다보는 기획입니다.

바탕체 글꼴을 선호하는 개발자라면 글꼴 선택 기능을 제안할 수도 있습니다. 고해상도 디스플레이가 보편화하면서 웹에서도 바탕체 글꼴이 의미 있게 된 상황을 근거로 댈 수 있습니다. 화면 기술의 변화 속에서 바탕체를 찾는 사람도 늘어날 수 있다고 보는 것입니다.

TTS 기능도 자신의 이용 경험에서 필요를 찾아 기획해 볼 수 있습니다. 내가 언제 글을 소리로 듣고 싶은지 살펴보고, 그 상황과 목적을 정리해 보는 것입니다.

이렇게 흥미로워 보이는 기능이 있다면 기획을 제안해 보는 것도 좋습니다. 우리 자신이 바로 핵심 이용자이고, 또한 개발자로서 원하는 기능을 직접 구현하는 것은 보람이 있습니다. 여유가 되고 좋은 기능이라면 구현할 수 있습니다. 이런 기능은 별 반향이 없을 수도 있습니다. 일종의 모험이죠. 그러나 의외로 반응이 좋을 수도 있습니다.

AI의 취약성

제가 생각하는 가장 중요한 기획 원칙 두 가지, 목적과 이용자에 대해 살펴 봤는데요. 이 부분은 AI에게 몹시 취약한 부분입니다. 우리 자신의 목적과 우리 자신의 이용자들에 대해 AI는 아는 바가 적기 때문입니다. 이런 점을 잘 설명해 주면 AI는 좀더 나은 구현을 할 수 있을 것입니다. 맥락을 설명하면서 AI에게 기획 자체에 대한 도움을 받을 수도 있습니다.

3. 기획안 작성하기

목적과 이용자를 생각했다면, 이제 무엇을 어떻게 만들지 적어 봐야 합니다. 필요하면 그림을 그립니다.

이 때 반가운 소식은 긴 문서가 필요한 것은 아니라는 점입니다. TTS라면 다음처럼 시작할 수 있습니다.

목적: 글을 눈으로 읽기 힘든 상황에서도 내용을 접하게 한다.
상황: 잠자기 전, 운전중, 집안일 중, 컨베이어 벨트 작업중.

이건 예시인데요. 이렇게 목적과 상황을 그려 보면 기능에 대한 생각이 따라오기 쉽습니다.

주로 집중력을 발휘하기 힘든 상황에서 들을 것 같으니, 읽기 속도 조절 기능은 필수적일 듯합니다. 집중력을 발휘하기 힘든 상황에서는 천천히 읽어 주는 것이 나으니까요. 어쩌면 한 문장을 두 번씩 읽게 하는 기능도 필요할지 모르겠습니다. 이런 식으로 떠오르는 생각을 두서없이 적습니다.

이후 정리를 해야 하는데요. 분류를 하고 충돌하는 것을 제거합니다. 그러면 기능의 얼개가 잡힙니다.

정리한 내용을 구현 범위와 비교해 봅니다. 구현 범위는 기획 전에 어느 정도 정했을 텐데요, 이 시점에 한번 다듬는 것입니다. 목적을 이루는 데 꼭 필요한 것이 빠졌다면 범위 조정을 제안하고, 있으면 좋지만 당장 필요하지 않은 것은 뒤로 미룹니다.

이후 실제 UI를 그려 사용자 경험을 설계합니다. UI 그림에는 설명을 붙입니다. 이 단계에서는 손으로 종이에 그리는 것을 권합니다. 종이는 컴퓨터와 달리 여러 알림으로 우리를 방해하지 않고, 코드에 대해 생각하지 않게 도와 주기 때문입니다.

여러 페이지를 기획할 때 반복되는 UI는 사진을 찍어서 나중에 컴퓨터에서 조합할 수 있습니다. 물론 프린터를 해서 반복 활용하는 방법도 있습니다만 꼭 없어도 됩니다. vFlat 같은 앱은 종이를 스캔한 것처럼 사진을 찍어 주니 도움이 됩니다. 손으로 그린 UI들 옆에 직접 손글씨로 설명을 붙여도 되는데, 컴퓨터로 그림만 옮긴 다음에 타이핑을 쳐도 됩니다. 이 때는 Figma 같은 툴이 유용합니다. 하지만 그냥 자신이 편한 툴을 사용하면 됩니다. 그림판도 좋습니다.