What Happens When Everyone Can Build Software

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

What Happens When Everyone Can Build Software를 중심으로, AI 코딩은 제작자의 범위를 비개발자와 현장 전문가로 넓힌다. 금융업 경험자의 개인 재무 도구와 브라질 택시 기사의 지역 앱은를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. AI 코딩은 제작자의 범위를 비개발자와 현장 전문가로 넓힌다. 금융업 경험자의 개인 재무 도구와 브라질 택시 기사의 지역 앱은, 해결할 문제를 아는 사람이 직접 구현에 나서는 사례다.
2. 제작자 확대는 데이터베이스 수요로 이어진다. Supabase는 가입자 1,300만 명, 매주 100만 개 이상의 데이터베이스 생성, 신규 활동의 약 70%가 에이전트에서 발생한다고 설명한다. 기존 개발자의 제작량 증가와 새로운 제작자 유입이 함께 성장에 기여한다는 해석이다.
3. 에이전트가 제품을 선택하고 사용하면서 접점도 달라진다. Supabase는 코드·CLI 중심 사용을 강화하고 있으며, 소스 접근성, 복구 방법을 알려주는 오류 메시지, 실제 사용 사례에 기반한 평가가 중요해진다. 내부 AI 코딩 확대와 함께 테스트 수요도 늘고 있다.
4. 개인용 소프트웨어는 데이터 소유와 검색의 가치를 높인다. 금융·건강·관계 정보를 별도 데이터베이스에 보관하면 여러 에이전트를 연결할 수 있다. Gbrain은 RAG와 그래프 탐색을 결합해 방대한 자료에서 필요한 정보를 찾아 제공하는 접근을 보여준다.
5. 구현이 쉬워져도 목표 설정과 운영의 과제는 남는다. 무엇을 만들지 판단하고 결과를 검증해야 하며, 공급자는 작은 개인용 데이터베이스부터 대규모 기업 워크로드까지 지원해야 한다. 버티컬 SaaS에서는 투자 유치보다 적은 인원으로 지속적인 이익을 만드는 방식이 매력적일 수 있다는 관점도 제시된다.

🧩 배경과 문제 정의

• AI 코딩 도구의 발전으로 소프트웨어 제작자가 전문 개발자에서 비개발자와 분야 전문가로 확대되고 있다. Supabase의 성장도 기존 개발자의 제작량 증가와 새로운 제작자 유입이 함께 이끈다.
• 에이전트가 도구를 선택하고 사용하는 비중이 커지면서, 데이터베이스 제품의 핵심 접점도 대시보드에서 코드·CLI로 이동하고 있다. 오픈소스와 소스 접근성은 문제 해결과 보안 검토 측면에서 중요해진다.
• 개인이 금융·건강·관계 데이터를 직접 보유하고 여러 에이전트를 연결하는 사용 방식이 등장한다. Supabase는 작은 개인용 데이터베이스를 대량으로 제공하면서 성장한 기업의 대규모 워크로드까지 지원해야 하는 과제를 안고 있다.

🕒 시간순 섹션별 상세정리

1. 에이전트와 새로운 제작자가 데이터베이스 수요를 확대한다

• 신규 활동의 약 70%가 에이전트에서 발생한다. 가입자는 현재 1,300만 명으로, 약 12개월 전의 대략 300만 명에서 크게 늘었으며 올해 매출은 4배 성장할 전망이다 [01:13]
• 매주 100만 개가 넘는 데이터베이스가 생성되고, 관리 중인 데이터베이스는 전년 약 800만 개에서 현재 5,000만 개에 접근하고 있다 [01:55]

2. 코드 중심 인터페이스와 오픈소스가 에이전트의 선택을 돕는다

• Supabase는 대시보드 중심에서 API 중심을 거쳐 코드 중심으로 이동했다. 에이전트가 주로 원하는 CLI와 코드 기반 작업 방식을 지원하며, LLM의 기본 데이터베이스 선택지가 된 시점도 성장에 유리하게 작용했다 [02:50]
• 오픈소스가 없었을 경우와 직접 비교하기는 어렵지만, 모든 작업을 공개하고 Postgres 등 기존 생태계 도구를 지원하는 방식은 여러 커뮤니티로 확산하는 데 큰 도움이 됐다는 판단이다 [03:24]

3. 비개발자 제작자의 유입이 전환 지표까지 끌어올린다

• 가입 증가가 가속되면 활성화율이나 전환율이 떨어지는 일반적인 양상과 달리, 올해는 관련 지표가 함께 상승하고 있다. 모델의 제작 능력이 좋아지면서 비개발자도 실제 결과물을 만들 수 있게 된 영향으로 읽힌다 [04:42]
• 개발자는 여전히 큰 비중을 차지하지만, 다른 사람을 설득해 구현을 맡겨야 했던 제작자 집단이 빠르게 성장하고 있다. 제품 주도 성장의 매출 상한을 예상했던 초기 투자자들의 전망과 달리, 현재까지는 뚜렷한 한계가 보이지 않는다는 입장이다 [05:39]

4. 구현 능력이 보편화되면서 무엇을 만들지 아는 전문성이 중요해진다

• 금융회사 창업 경험자는 과거 엔지니어의 도움이 필요했던 개인 재무제표·추적 소프트웨어와 은행 연동을 직접 만들고 있다. 금융업 지식이 구현 능력과 결합하면서, 불과 2년 전이라면 만들어지지 않았을 소프트웨어가 등장한다 [06:29]
• 분야 전문가는 자신의 영역에서 해결되지 않은 문제를 정확히 알고 있어, 개발자를 공동 작업에 끌어들이지 않고도 틈새 문제를 공략할 수 있다 [07:08]

5. 현장 경험을 가진 비개발자에게 새로운 제작 기회가 열린다

• 브라질의 한 택시 기사는 휴대전화로 지역 시장을 위한 작은 우버 형태의 택시 앱 전체를 만들었다. 구체적인 제작 동기는 알 수 없지만, 현업 종사자가 직접 서비스를 구현했다는 사례다 [08:49]
• 약 50세로 보였던 이 제작자는 새로운 능력을 얻은 데 큰 활력을 보였다. 일의 미래에 대한 불확실성 속에서도, 기존에는 이런 기회와 거리가 있었던 현장 노동자가 제작 기술과 가능성을 발견할 수 있다는 기대가 나온다 [09:18]

6. 개인용 소프트웨어에도 UI와 데이터베이스가 필요해진다

• 모든 일을 채팅과 마크다운으로 처리하려던 시도는 일정 규모에서 한계에 부딪혔다. 이메일 분류, 지출, 체중과 운동 기록을 한곳에서 관리하는 개인용 ‘컨트롤 타워’에는 UI와 데이터베이스가 유용해졌다 [10:03]
• 개인 재무 기능은 기존 금융 앱과 비슷하거나 일부 면에서 더 낫다는 평가다. 자신의 인물 정보와 거래 내역을 함께 활용해 거래 상대를 식별하고 분류하는 등, 다른 사용자의 요구를 고려할 필요 없이 개인 맥락에 맞출 수 있다 [10:50]

7. 개인 데이터베이스가 여러 에이전트를 연결하는 기반이 된다

• 생활 습관과 CRM 정보가 하나의 에이전트에 갇히는 것을 우려해 데이터를 별도 저장소로 옮기는 사용 방식이 등장한다. 데이터를 직접 보유하면 필요에 따라 서로 다른 에이전트를 연결할 수 있다 [12:09]
• 과거에는 코딩 능력 없이 개인 데이터베이스를 만들어도 활용하기 어려웠고, 개인 CRM 구축에도 많은 노력이 들었다. AI는 개인이 데이터베이스를 보유할 실질적인 이유와 활용 수단을 만들어 준다 [12:53]

8. 모두가 제작자가 되는 시나리오는 데이터베이스 공급 규모를 바꾼다

• AI에 접근할 수 있는 사람은 누구나 어떤 형태로든 제작자가 될 것이라는 전망이다. 앱이나 UI를 원하는 대로 수정할 수 있으면 다른 사람이 변경해 주기를 기다릴 필요가 줄어든다 [14:29]
• Supabase의 목표는 기업이 시작하는 첫날부터 함께하는 것이었다. 초기에는 YC 기업 확보에 집중했지만, 제작자층이 넓어지면서 같은 목표가 훨씬 다양한 사용자를 지원하는 문제로 확장됐다 [14:46]

9. 작은 개인용 워크로드와 페타바이트급 확장을 함께 지원한다

• 모든 워크로드에 고성능 데이터베이스 자원을 제공해야 하는지는 의문이며, 컴퓨팅 자원 확보도 어려워지고 있다. 인수한 Turso의 Postgres·SQLite 호환 아키텍처를 활용해 초기 워크로드용 ‘Supabase Spark’ 계층을 제공할 계획이다 [16:02]
• 사용자는 같은 경험으로 시작하고, 사업이 성장하면 페타바이트 규모까지 확장할 수 있어야 한다. 작은 시제품 단계부터 성장한 기업까지 계속 지원하는 것이 제품 방향이다 [16:38]

10. AI 코딩 도입 확대와 함께 테스트 수요도 증가한다

• 코드의 80%를 코딩 에이전트로 작성하는 엔지니어의 비중이 6개월 사이 10%에서 60%로 늘었다. 회사는 별도의 AI 사용 방침을 강제하기보다 각자 원하는 도구에 접근할 수 있게 했다 [17:58]
• 도입 확대에는 모델이 더 많고 수준 높은 작업을 할 수 있다는 신뢰가 작용했다. 내부에서도 복잡한 작업을 AI로 구현하며, 결과의 품질을 확보하기 위해 테스트 양과 관련 도구 활용을 늘리고 있다 [18:30]

11. 대시보드·API·코드 중심 전환은 사용 방식의 변화에 대응했다

• 초기 대시보드는 개발자조차 데이터베이스 사용에 어려움을 겪는 문제에서 출발했다. Postgres 위에 Airtable 같은 UI를 제공하면 데이터베이스를 더 쉽게 다룰 수 있다는 접근이었다 [20:22]
• API는 많은 데이터베이스를 자동으로 생성하려는 연동 고객의 요구로 만들었으며, 그 시점은 아마 2021년경이었다. 이 선택은 2024년 Bolt와 Lovable 같은 서비스가 Supabase 위에 구축될 때 적합한 기반이 됐다 [21:00]

12. 이전 플랫폼들이 독립 데이터베이스 사업의 길을 열었다

• Parse와 Firebase, 이후 Atlas 같은 서비스는 데이터베이스를 대형 클라우드 사업자에게서만 공급받을 필요가 없다는 인식을 넓혔다. Supabase가 독립적인 데이터베이스 사업을 시작할 수 있었던 데에는 이런 시장 변화의 시점도 중요했다 [22:03]
• 이전 세대 서비스의 성장에는 NoSQL에 대한 관심과 모바일 확산이라는 변곡점이 있었다. Supabase도 여러 변화의 물결을 만났으며, 현재는 새로운 전환의 한가운데 있다는 인식이다 [23:07]

13. 첫날 확보한 고객과 함께 성장하려면 확장성을 유지해야 한다

• 좋은 개발 경험으로 초기 사용자를 확보해도, 앱이 커질 때 성능 요구를 충족하며 계속 함께 성장하기는 어렵다. Supabase는 작은 프로젝트 시장의 확대에 더해 대규모 확장도 추구하며, Postgres의 확장 한계를 보완할 도구를 구축하고 있다 [23:33]
• AWS 매출의 약 40%가 초기에 시작해 성장한 스타트업에서 나온다는 수치는 정확하지 않을 수 있어 확인이 필요하다는 단서가 붙는다. 지향하는 모델은 데이터베이스 이전의 어려움을 감안해 고객의 첫날부터 좋은 경험을 제공하고 계속 머물게 하는 것이다 [24:52]

14. 개인과 개인 에이전트가 별도의 고객 시장을 형성한다

• 과거에는 데이터베이스를 개인에게 직접 판매한다는 발상이 낯설었지만, 이제 초기 기업과 개인 또는 그 에이전트라는 두 고객군이 생긴다. 개인용 금융 앱이나 지역 사업용 앱은 스타트업처럼 급성장하지 않아도 오랫동안 사용될 가능성이 있다 [26:13]
• 개인의 생활이 확장되고 정보가 쌓이면 저장하는 데이터도 늘어난다. 이런 프로슈머 시장은 기업 고객의 성장과 별개로 Supabase의 성장 경로가 될 수 있다 [26:53]

15. 음성으로 작업을 맡기는 개인 에이전트가 제품 설계를 바꾼다

• 비서가 자리를 비운 일주일 동안 개인 에이전트의 능력을 경험한 뒤, 이를 위한 제품 개발에 대한 기대가 커졌다. 코드 중심 제품의 직접 사용자는 점차 사람보다 에이전트가 될 것이라는 전망이다 [27:29]
• 실제 제작에서는 Dots와 계속 통화하며 변경 사항을 요청한다. 사용자 경험을 직접 검증하기 위해 코드와 아키텍처를 가급적 보지 않고, 구현이 제대로 되는지 확인할 때를 제외하면 대화만으로 무엇을 바꿀 수 있는지 시험한다 [27:56]

16. 기능 학습과 제품 활용의 주체도 에이전트로 확장된다

• 사용자가 새 기능을 모두 이해하는 대신, 에이전트가 콘퍼런스 내용을 학습해 자신의 코드베이스에 적용하도록 맡기는 구상이 나온다. 에이전트 전용 콘퍼런스와 에이전트 간 활용 팁 교환도 아이디어로 계속된다 [28:48]
• 참석한 에이전트에게 마크다운 자료를 전달하는 방식까지 상상하지만, 이는 실제 운영 사례가 아닌 대화 중의 구상이다 [29:31]

17. 에이전트가 오류에서 복구하도록 제품과 평가를 설계한다

• 단순한 500 오류 대신 해결 방법이나 참고 문서를 오류 메시지에 담으면 에이전트가 직접 복구할 수 있다. 구체적인 사용 사례를 반복 실행하며 메시지를 개선하는 방식이 한 번의 요청으로 작업을 완수할 가능성을 높인다. [30:08]
• 에이전트 대상 경쟁에는 모델의 선택을 받는 단계와, 막혔을 때 다른 도구로 이탈하지 않게 하는 단계가 있다. 에이전트도 결국 문제에 부딪히므로 기존의 인간 개발자용 인터페이스를 복구에 필요한 도구와 안내 중심으로 다시 설계해야 한다. [31:02]

18. Gbrain은 큰 컨텍스트보다 필요한 정보를 찾아주는 중간 계층에 집중한다

• Gbrain의 출발점은 기사·정책·논문을 읽고 종합하는 에이전트 뉴스룸이었다. 이를 OpenClaw용 오픈소스 검색으로 발전시키면서, 모든 LLM 호출을 비싸고 위험한 작업으로 통제하던 방식에서 에이전트에 데이터와 기능을 제공하는 방식으로 관점이 바뀌었다. [32:24]
• 100만 토큰도 매 순간 적절한 자료를 담아두기에는 한계가 있다. 약 50만 개의 마크다운 파일에 개인의 소통 기록이 쌓여 있어도 당장 필요한 것은 두 페이지일 수 있으므로, 핵심 문제는 전체 자료를 넣는 일이 아니라 필요한 자료를 검색하는 일이다. [33:28]

19. 에이전트가 검색 구조를 조사하고 작업에 맞게 최적화할 수 있다

• Gbrain의 구현 방향은 에이전트에 Exa로 RAG·그래프 데이터베이스·텍스트 검색 연구를 수집하고, 에이전트의 자료 접근이라는 용도에 맞춰 요약하도록 요청하는 과정에서 구체화됐다. [35:47]
• 반복 검색에 10초가 걸린다면 에이전트가 적합한 인덱스를 찾거나 새로운 인덱스를 만드는 작업을 반복해 1초 미만으로 줄리는 방안이 드러난다. 이는 현재 달성한 성과가 아니라 검색 패턴에 맞춰 데이터 구조를 바꾸자는 아이디어이며, 충분히 똑똑한 코드 생성이 가능해지면 동적 검색도 구현될 것이라는 전망이다. [36:21]

20. 실사용 평가와 실패 기록이 지속적인 자동 개선의 기준이 된다

• Gbrain은 운영 인스턴스의 실행 기록에서 평가 데이터를 추출하고, 별도 저장소에서 검색 유형·검색 효율·비용 효율·지연시간 등 40개 범주를 관리한다. 이 평가 점수를 개선한 변경을 기본적으로 master에 반영하도록 에이전트에 반복 연구를 맡긴다. [37:04]
• 효과가 없었던 시도는 실패 이유를 마크다운으로 남긴다. Cappy의 ‘captain’을 나눠 하나는 새 평가 범주를 만들고, 다른 하나는 기존 범주를 순회하며 매일 개선 방법을 찾도록 계속 실행한다. [37:42]

21. 대화형 개발은 구현을 줄여주지만 원하는 결과에 대한 판단은 필요하다

• 미래에는 평가 체계를 몰라도 Claude와 친구처럼 대화하면서 머릿속의 제품을 구현할 수 있다는 비전이 드러난다. [39:25]
• openusd.dev 사이트를 만들 때 컴퓨터와 휴대전화로 대화하며 개발을 진행했고, 생태계와 사용 사례 사이의 정보 구조 개선을 요청했다. 제안을 승인한 뒤 약 20초 만에 변경이 반영됐으며, 페이지 연결과 SEO 관련 작업도 함께 처리됐다. [39:41]

22. 모델 능력의 급성장과 이를 활용할 사람의 부족이 동시에 나타난다

• 모델이 이미 학습한 작업은 자동으로 수행할 수 있지만, 아직 익숙하지 않은 작업에는 짧은 마크다운 안내나 소량의 프롬프트가 필요하다는 판단이다. 코드 도구 안의 반복 개선을 RSI의 초기 현실화로 보는 해석도 나오지만, 이는 대화 참여자의 전망이다. [41:27]
• 모델의 능력은 급격히 커지는 반면, 무엇을 만들고 어떻게 요청해야 사회에 영향을 줄 수 있는지 아는 사람의 수는 크게 늘지 않는다는 진단이다. 활용 목표와 판단 역량이 기술 발전을 따라가지 못하는 병목이 된다. [42:10]

23. 버티컬 SaaS는 투자 유치보다 적은 인원으로 내는 이익이 중요해질 수 있다

• 버티컬 SaaS는 연간 반복 매출(ARR)이 500만~1,000만 달러여도 시리즈 A 투자 유치에 어려움을 겪는다는 관찰이다. 9~12개월 전에는 강한 투자 근거였던 매출 규모의 평가가 달라졌고, 수평형 제품과 AI 투자에 비해 투자자의 관심도 낮아졌다는 진단이다. [43:32]
• 동시에 10~15명으로 ARR 1,000만~1,500만 달러, 경우에 따라 2,500만·3,000만·5,000만 달러에 도달할 수 있다는 관점이다. 15명 조직에서 인당 ARR 200만 달러와 이익률 50%를 가정하면 인당 연간 100만 달러의 이익에 해당하므로, 작은 조직에도 매력적인 성과가 가능하다. [44:05]

24. 오래 지속될 시장을 선택하고 새로운 개발 방식에 빠르게 적응한다

• 데이터베이스는 약 50년 동안 존재해왔고 앞으로도 50년은 남을 것이라는 기대가 Supabase의 사업 선택을 뒷받침한다. AI 발전 이후에도 데이터베이스가 필요할 것이라는 확신을 바탕으로, 인생을 걸 사업이라면 오래 지속되고 투자할 가치가 있다고 믿는 분야를 선택해야 한다는 조언이다. [45:34]
• 빠르게 변하는 환경에서는 모든 답을 미리 갖추기보다 가장 빠르게 적응하는 일이 중요하다. 개발자 중심 도구가 대기업 고객 중심으로 이동하며 정체되는 패턴을 경계하고, 새로운 제작 방식에 대한 관심과 팀이 신속하게 방향을 바꿀 여력을 유지해야 한다. [46:05]

25. 직접 사용과 파트너 피드백, 실험 여력이 다음 변화에 대비하는 방법이다

• 새로운 도구를 자사 제품과 함께 직접 사용하면 사용자가 막히는 지점을 구체적으로 알 수 있다. 자기 도구에서 직접 문제를 겪는 경험이 제품의 빈틈을 찾는 중요한 피드백이다. [47:34]
• 주요 생태계 기업과 협력하면 그들이 만드는 제품에 관한 피드백을 얻을 수 있다. 팀에 일부 여력을 남겨두는 일은 어렵지만, 새로운 아이디어가 나왔을 때 실제로 시도할 수 있게 한다. [47:51]

🧾 결론

• 소프트웨어 제작의 저변 확대는 분야 전문성이 실제 제품으로 이어질 기회를 늘린다. 구현 접근성이 높아질수록 해결할 문제를 고르는 판단이 중요해진다.
• 에이전트를 주요 사용자로 보는 제품은 코드 접근, 오류 복구 안내, 반복 평가를 통해 작업을 끝까지 수행할 수 있도록 설계해야 한다.
• 개인 데이터베이스는 여러 에이전트가 공통으로 활용하는 기반이 될 수 있다. 필요한 정보를 찾아주는 검색 계층도 함께 중요해진다.
• 지속적인 성장을 위해서는 새로운 제작 방식을 직접 사용하고, 실패 기록과 사용자 피드백을 다음 실험에 반영할 여력이 필요하다.

📈 투자·시사 포인트

• 데이터베이스 시장은 초기 기업과 개인·개인 에이전트라는 서로 다른 고객군으로 확장될 가능성이 있다. 고객 수 확대가 실제 매출과 장기 사용으로 이어지는지 살펴볼 필요가 있다.
• 대량의 작은 데이터베이스를 경제적으로 공급하면서 성장한 고객의 확장도 지원하는 구조가 사업의 핵심 과제다. Supabase Spark와 대규모 확장 전략은 이 두 수요에 대응하려는 방향으로 제시된다.
• AI가 만드는 코드가 늘수록 테스트·CI·에이전트 평가와 오류 복구를 돕는 도구의 수요도 커질 수 있다. 제작량 증가와 품질 검증 부담을 함께 봐야 한다.
• 버티컬 SaaS는 투자 유치 규모와 함께 소규모 조직의 매출 생산성·이익률을 평가할 필요가 있다. 다만 제시된 인당 성과는 가정에 따른 계산이다.

⚠️ 불확실하거나 확인이 필요한 부분

• Supabase의 가입자·데이터베이스·에이전트 활동 수치는 대화에서 제시된 값이다. 올해 매출 4배 성장은 전망이며, 기준 시점과 집계 정의는 별도 확인이 필요하다.
• ChatGPT 주간 활성 사용자 12억 명이라는 언급과 월 12억 개 데이터베이스 계산은 검증된 현재 수요가 아니다. 사용자 수 언급을 전제로 모두가 매달 하나씩 만든다고 가정한 규모 시나리오다.
• Turso 인수, Postgres·SQLite 호환 구조, Supabase Spark 제공 계획은 원문에 서술된 내용이다. 실제 거래·제품 상태와 제공 범위는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자신의 업무에서 반복되는 미해결 문제 하나를 골라 AI 코딩으로 작은 도구를 만들고, 실제로 쓸 수 있는지 확인한다.
• 만든 도구의 대표 사용 사례와 실패 사례를 정리하고, 변경 후에도 결과가 유지되는지 반복 검증한다.
• 에이전트가 사용하는 제품의 CLI·코드 접근과 오류 메시지를 점검하고, 실패했을 때 복구에 필요한 안내를 제공하는지 확인한다.
• 개인 금융·건강·관계 데이터 중 직접 보유할 범위를 정하고, 여러 에이전트에서 활용할 수 있는 저장·검색 방식을 검토한다.

❓ 열린 질문

• 구현 능력이 더 보편화될 때, 분야 전문가가 해결할 문제를 고르고 제품의 유용성을 검증하는 과정은 어떻게 달라질까?
• 개인용 데이터베이스가 대량으로 늘어날 경우, 공급자는 낮은 자원 사용량과 장기간 유지되는 고객 관계를 어떤 과금 구조로 연결할 수 있을까?
• 에이전트의 도구 선택에서 기본 선택지로 채택되는 효과와 오류 복구 경험은 각각 얼마나 큰 영향을 미칠까?