개발자 어썸블로그

시스템 엔지니어링

2026-07-07T08:58:22+09:00

시스템 엔지니어라는 역할을 새롭게 맡게 되었습니다. 그 동안 소프트웨어 개발에 집중해 왔는데, 이제 더 넓은 관점에서 다양한 파트의 일들을 접하게 될 것 같습니다. 회사 면접에서 시스템 엔지니어링과 관련된 짧은 발표를 요청받았는데 발표를 준비하며 시스템 엔지니어의 중요한 역할에 대한 생각을 정리해 보았습니다. (여담이지만 이렇게 글로 생각을 정리하고 AI에게 PPT로 만들어 달라고 하니 꽤 괜찮은 퀄리티의 발표자료가 나와서 놀라네요)

1. 팀이 미션을 이해하도록

시스템 엔지니어링의 시작은 우리의 미션을 구체적인 언어로 정의하고, 이를 모든 이해관계자들과 공유하는 일이라고 생각합니다. 개발 조직이 미션을 이해하는 충분한 과정 없이 시스템을 개발해 나가면 중요한 기술적인 결정의 순간에 목적에 벗어나는 결정을 하기 쉽습니다. 시스템의 요구사항은 초기에 완전하게 정의되지 않고, 여러 설계 결정사항들도 프로젝트를 진행하며 결정되는데 이때 미션에 대한 이해는 여러 결정의 순간 우리가 길을 잃지 않도록 돕는 등대와 같은 역할을 합니다. 시스템 엔지니어는 개발조직이 미션에 대해 잘 이해하고 스스로 목표를 달성하기 위한 올바른 결정을 할 수 있는 토대를 만들어 주어야 합니다.

2. 사용자의 필요를 공학적인 요구로 재해석하기

사용자의 요구사항은 그대로 엔지니어링 영역에 와 닿을 수 없습니다. 사용자는 순수한 필요를 말하지만 엔지니어는 그것을 구현하는데 여러 제약사항을 가집니다. 따라서 시스템 엔지니어는 사용자의 필요를 공학적인 제약사항 위에서 공학적인 요구로 재정의 할 수 있어야 합니다. 사용자의 언어와 엔지니어가 안고 있는 제약 사항을 함께 이해하여 둘이 공존할 수 있는 언어로 문제를 재정의 하는 것입니다. 시스템 엔지니어는 이를 통해 사용자와 엔지니어를 잇는 가교 역할을 합니다.

3. 테스트 가능한 요구사항

시스템 엔지니어는 요구사항을 정의하는 프로젝트 초기 단계부터 테스트 가능한 시스템을 고민합니다. 시스템을 어떻게 테스트할지 고민하는 과정은 반드시 요구사항을 구체적으로 정의하도록 유도합니다. 테스트 가능한 시스템을 고민함으로 불확실한 프로젝트의 건강한 초석을 다질 수 있습니다. 시스템 엔지니어는 프로젝트 전 과정에서 이 테스트에 대해 고민하고 실제 테스트 계획과 결과가 올바른지 점검도 합니다. 테스트에 대한 고민은 시스템 엔지니어링의 꽃이라고 부를 만큼 중요한 것이라고 생각합니다.

4. 안정적이지만 경제적인 결정하기

프로젝트는 무언가를 ‘결정’하는 일의 연속입니다. 이 모든 결정의 순간에 시스템 엔지니어는 안정적이지만 동시에 경제적인 것을 선택해 나가야 합니다. 경제적이라는 것은 프로젝트의 미션을 달성하는데 불필요한 것들을 찾아 제거하고, 반드시 필요한 것만 남기는 것이라고 다르게 표현 할 수 있습니다. 사용자들은 대게 프로젝트 초기에 자기가 원하는 것을 구체적으로 정의하지 못하는 경우가 많은데, 이로 인한 불안감으로 실제로 필요한 것보다 과도하게 무언가를 요구하는 경우가 있습니다. 시스템 엔지니어는 사용자의 상황과 목적을 잘 이해하고 그 필요를 세밀하게 분석하여 정말 필요한 것만 남을 수 있도록 사용자와 소통해야 합니다. 또한 시스템 엔지니어는 목적을 이루는 방법을 결정할 때 더 쉽고 확실한 방법이 없는지 자신과 조직에게 다시금 질문을 던져보아야 합니다. 한 번 더 생각해 보면 더 쉽고 확실한 해결책이 있을 때가 많습니다.

5. 조기 설계 검증

시스템 엔지니어는 핵심적이고 리스크가 높은 기능을 가능한 프로젝트 초기에 식별하고 설계 컨셉이 생각한 대로 동작하는지 시험하고 개선할 수 있는 구조를 만들어야 합니다. 일반적으로 시스템의 개발은 분석, 설계, 구현, 시험이라는 단계를 거치는데, 우주 분야의 제품은 이 단계들이 순차적으로 진행되는 경우가 많습니다. 그래서 프로젝트 막바지인 시험 단계에 설계 결함이 발견되면 이미 너무 많은 것들이 진행되어 문제를 해결하는데 비용이 과도하게 들거나, 어떤 경우에는 거의 불가능한 경우가 발생하기도 합니다. 시스템 엔지니어는 중요하지만 리스크가 높은 기능들을 조기에 식별하고 설계 단계부터 검증하여 적은 비용으로 수정할 수 있는 기회를 얻게 해야 합니다. 이를 통해 핵심적인 기능이 최종 완성품에서 실패하는 리스크를 크게 줄일 수 있습니다.

6. 인터페이스의 주인

소프트웨어 공학에는 ‘의존성 역전’이라는 설계 원칙이 있습니다. 위성 개발은 주관 기관을 중심으로 다양한 하위 기관들의 협력을 통해 만들어집니다. 이때 하위 기관들의 시스템 사이에 인터페이스 설계가 중요한 업무가 되는데, 주관 기관이 하위 시스템들을 잘 이해하고 적극적으로 인터페이스 요구사항을 내지 못한다면 하위 기관이 인터페이스를 주도해서 정의하고 주관 기관은 그저 하위 기관이 만들어 주는 대로 사용하는 의존 구조를 가지게 됩니다. 이렇게 되면 대게 주관 기관이 원했던 목적에 최적화된 인터페이스 설계가 이루어지지 못하고 프로젝트 후반부에 아쉬운 부분이 있더라고 이를 그대로 수용해야하는 결과를 가져오곤 합니다. 시스템 엔지니어는 서브 시스템들의 동작을 이해하고 인터페이스 설계에 적극적으로 참여하여 시스템의 인터페이스가 목적에 맞게 잘 설계 될 수 있도록 해야합니다.

7. 소통

위성 시스템은 기계, 광학, 전자, 소프트웨어 등 정말 다양한 파트의 전문가 그룹에 의해 개발됩니다. 그리고 그 모든 파트가 원활히 소통하며 한 방향으로 나아가지 못하면 프로젝트는 성공할 수 없습니다. 많은 사람들이 프로젝트가 실패하거나 큰 어려움을 겪는 이유가 조직의 기술적인 역량 부족 때문이라고 생각하지만, 실제로 프로젝트가 실패하거나 큰 어려움을 겪는 결정적인 이유는 소통의 실패에서 오는 경우가 너무나 많습니다. 시스템 엔지니어는 여러 파트들이 원활하게 정보를 교환하고 신속한 의사결정을 내리며 나아갈 수 있도록 그들 사이에 원활한 소통 채널을 만들고 소통을 주도해야 합니다.

제가 생각하는 시스템 엔지니어의 중요한 역할들에 대해 생각해 보았습니다. 저도 이것을 마음에 두고 앞으로 새로운 환경에서 잘 적응하고 조직에 꼭 필요한 일을 할 수 있도록 노력하겠습니다.

2026 Devchat Night+ 세미나 후기

2026-07-10T09:03:31+09:00

일시: 2026년 7월 7일(화)
장소: HAESO 해소 (서울 성동구 성수이로24길 31)
주최: Devchat

Why We Gather

김경환 (네이버), 김상기 (SK텔레콤), 이동현 (카카오페이)
진행: 황국화

Q. 지금까지 가졌던 데브챗 모임 중 가장 기억에 남는 모임은?

이동현 (카카오페이)

장소로는 엘타워가 가장 먼저 떠오름 - 롯데 이커머스 후원으로 열린 모임
- 전망 좋은 곳에서 일하는 기분에 대한 생각, 분위기가 좋았던 기억
최근에는 배민(우아한형제들)에서 함께한 모임도 기억에 남음
장소보다 기억에 남는 자리는 내부 팀장들이 모여 발표했던 시간
- 서로 다른 회사에서 일하며 얻은 좋은 점과 고충을 나누며 공감대를 형성

김상기 (SK텔레콤)

2023년 데브챗 모임 시작 이후 매달 스터디 형태로 진행하다가, 그해 12월 연 데브챗 컨퍼런스가 가장 기억에 남음
2024년에는 데브챗 멤버들과 함께 책을 집필 - 코드 너머, 회사보다 오래 남을 개발자 (한빛미디어, 2025년 출간)

김경환 (네이버)

2023년 1월 팀 리더를 맡게 되면서 개발 문화/조직 문화에 대한 관심으로 데브챗 스터디에 참여
첫 세션은 온라인(Zoom)으로 진행, 다소 낯설었지만 그때 받은 영향력 덕분에 지금까지 애정을 갖고 참여 중

Q. AI 시대에 오프라인 모임/커뮤니티가 갖는 힘은 무엇인가?

김상기 (SK텔레콤)

"여러분은 오늘 왜 오셨나요?"
사람을 만나면 상대에게 먼저 관심을 갖는 습관은 과거 코칭 활동에서 비롯됨

이동현 (카카오페이)

연결의 소중함 - AI와 연결하는 것보다 사람과 연결하는 게 중요해서 이 모임이 더 소중하게 느껴짐
데브렐은 원래 개발자와의 연결을 다루는 일이었는데, AI 시대에는 비개발자도 개발자와 같은 역할을 할 수 있게 되면서 개발자/비개발자 구분 없이 "만드는 사람들"과 연결되는 게 중요해짐
비슷한 고민을 하는 사람들끼리 연결돼 생각을 확장해 나갈 수 있는 기회라는 점에서 오프라인 모임이 소중함

김경환 (네이버)

커뮤니티에 모이는 가장 큰 힘은 관계에서 오는 동기
각자의 고민을 나누다 공통점을 찾고, 관계가 점점 따뜻해지면서 커뮤니티의 온기로 나타남
데브렐이라는 주제를 벗어나 실제 회사 업무, 살아가는 이야기까지 나누게 되는 점이 좋음

Q. 회사에서 진행 중인 AX와 데브렐은 어떤 관계인가?

김상기 (SK텔레콤)

AX는 결국 AI를 잘 이해하게 만드는 일 - AI를 다루는 데 가장 능숙한 건 개발자
비개발자가 개발자들이 쓰는 용어를 익히게 만드는 것이 관건 - 그래야 AI에게 원하는 걸 제대로 시킬 수 있음
본인이 속한 전사 HR 조직은 대부분 비개발자
- Claude, GPT 등 AI 도구를 쓰다 개발자 용어에 막히면 그걸 잘 아는 개발자와 연결해주는 역할을 함
데브렐이 개발자 간 관계를 만들던 일을, AX 시대에는 비개발자를 개발자로 연결/성장시키는 일로 확장해서 하고 있음 - 결과적으로 AX 팀은 데브렐과 협업할 수밖에 없는 구조
본인도 AX 팀에 합류했고, 전사/사업부별로 AX 조직이 계속 늘어나는 추세

Q. 데브챗 모임에서 나눈 이야기가 실무에 도움이 된 적이 있는가?

이동현 (카카오페이)

모임마다 기록을 남겨 참석자들에게 공유하고, 사내에도 별도로 기록해 둠
특정 사례를 콕 집어 말하긴 어렵지만, 쌓인 이야기들이 업무 어딘가에 반영되는 느낌을 받음
다른 회사의 이벤트/행사 기획 사례를 들으며 "언젠가 써먹어야지" 하고 아이디어를 얻은 경우가 많음

Q. 데브챗을 가장 잘 설명하는 키워드는 "집단지성"과 "심리적 안정감" 중 무엇인가?

김경환 (네이버)

앞서 말한 "온기"와 이어지는 맥락
- 심리적 안정감 쪽이 더 잘 맞는 표현
안정감 있는 관계 안에서 집단지성도 좋은 형태로 나온다고 생각

이동현 (카카오페이)

둘 중 하나를 고르고 싶지 않음, 둘 다 중요
훌륭한 발표자를 섭외해 이야기를 듣고, 이후 네트워킹으로 서로 회사 사례를 비교하며 아이디어를 나누는 과정에서 집단지성을 느낌
회사 안에는 데브렐 역할을 하는 사람이 몇 없어 고민을 나눌 곳이 마땅치 않은데, 데브챗에 오면 다양한 연차/직무/회사의 사람들이 모여 있어 여러 아이디어가 촉발됨

김상기 (SK텔레콤)

집단지성은 AI 때문에 오히려 약해지고 있다고 생각
심리적 안정감은 프라이빗 모임이기 때문에 가능
- 회사 안에서 못할 이야기도 나눌 수 있고, 밖에서 있었던 일이라 발설 부담이 없음
데브챗에서 얻는 정보는 AI나 책에서는 구할 수 없는 정보라 집단지성 역시 유효 - 결국 둘 다에 해당

Build Mode, AX in Reality - AI Native 개발문화 정착을 위한 기술리더들의 고군분투기

박성우 (한국디지털에셋), 박용권 (당근마켓), 서동민 (두들린)
진행: 강상윤 (야놀자)

Q. AI를 도입하면서 계획과 실제가 달랐던 점, 겪었던 시행착오는?

서동민 (두들린)

올해 초부터 본격 도입, 그 전에도 GPT-4o 즈음부터 조직 내에서 조금씩 실험
세상이 변하는 속도를 빠르게 못 따라간 것이 가장 후회되는 지점
처음 만든 건 단순 요약 기능이었는데, 당시엔 "이것도 잘 못한다"며 AI를 부정적으로 봤음
- 지금 보면 AI를 보는 눈높이 자체를 너무 낮게, 제한적으로 잡았던 것이 아쉬움

박성우 (한국디지털에셋)

AI로 인한 변화를 미리 예상하려 하지 않음
- "바이브"라는 말이 처음엔 유치하다고 생각했다가, 어느 순간부터 이 시대의 흐름을 가장 잘 표현하는 단어라고 느낌
그래서 바이브에 몸을 맡기고 바이브를 타는 게 가장 편했음

박용권 (당근마켓)

작년 2월 클로드 코드 출시 이전부터 AI와 일함, 이후로는 에이전트와 함께 일하는 게 일상화된 지 1년 반 이상
기대와 달랐던 점은 "생각보다 그렇게 빨라지지 않았다"는 것
무언가를 만드는 행위 자체는 압도적으로 줄었지만, 문제를 발견하고 검증 가능한 해결책으로 바꾸는 사고 과정, 디자인 영역은 아직 AI가 크게 못 함

Q. AI를 잘 쓰는 엔지니어들의 특징이나 패턴은?

박용권 (당근마켓)

한계를 스스로 정해두지 않고 "될 때까지" 끝까지 시켜보는 사람이 잘 씀
최근엔 출근해서 미팅/계획을 짜고 퇴근 전 AI에게 작업을 맡긴 뒤, 다음 날 아침 결과물을 확인하는 식으로 거의 24시간 활용하는 구성원도 있음

박성우 (한국디지털에셋)

한계를 두지 않는 사람, 업무 영역 경계에 얽매이지 않는 사람이 좋은 성과를 냄(개발자인데 디자인에도 관심, 백엔드인데 프론트도 시도 등)
다만 빠르고 과감한 초기 성과 이후에는 결국 책임감과 기본기가 탄탄한 사람이 진짜 의미 있는 제품을 만듦

서동민 (두들린)

테크(개발자)와 No테크(비개발 직군)를 나눠서 설명
개발자 쪽에서는 모호한 요구사항을 구체적 목표와 작은 테스트 단위로 쪼개고, 각 단위가 어떤 결과물에 도달해야 완성인지 정의하는 능력
- 추상적인 것을 구체적/정량적 표현으로 바꾸는 "문제 구체화 능력"이 뛰어난 사람일수록 AI 결과물이 의도한 것과 일치
비개발 직군 쪽에서는 결국 시도하는 능력
- 전사적으로 "전부 다 AI로 만들어보시라"고 독려 중인데, "이거 만들 수 있나요?"라고 물으러 오면 일단 AI에게 직접 시켜보고 안 되면 그때 다시 오시라고 안내
- 그렇게 하면 대부분 결과물이 나옴
한번 도전해보고 안 되면 왜 안 되는지 파악하면서 끊임없이 도전하는 사람이 성과를 냄

강상윤 (야놀자, 진행)

하나 덧붙이면, 회사에서 AX 프로젝트를 많이 해본 경험상 AI를 활용하지 않던 시대에도 지금도 공통적으로 잘하는 엔지니어의 특징은 직군과 스택을 넘어 공유를 잘하는 사람
- 이런 사람이 항상 회사에서 더 많은 가치를 만들어냄

Q. AI 시대, 연차(주니어/시니어/팀장급)별로 어떤 방향으로 성장하면 좋은가?

서동민 (두들린) - 주니어 대상

예전엔 책이나 강의로 먼저 공부한 뒤 회사 문제에 적용했다면, 이제는 책/강의 없이 회사에서 가장 어려운 문제부터 풀어보라고 제안
풀다가 모르는 게 나오면 AI에게 계속 물어보면서 새로운 개념을 확장해 나가는 방식으로 자연스럽게 성장 가능

박용권 (당근마켓) - 시니어 대상

"짬(연차)으로 밀어붙이는 시니어"는 이제 의미가 없음
- 1, 2년 전 본인이 작성한 코드 퀄리티를 지금은 2, 3년 차 엔지니어도 쉽게 재현
코드 레벨보다 앞으로 "어떤 방향으로 뾰족하게 성장할지"에 초점을 맞춰야 함
- 프로덕트 엔지니어냐 플랫폼 엔지니어냐 등 일하는 영역에 따라 AI 시대에 기대받는 전문성이 조금씩 다름
최근 인상적이었던 것은 오픈AI 코덱스 팀이 엔지니어에게 기대하는 역량으로 "프로덕트 취향(product taste)"을 정확하게 짚은 것
- 이 시대에 어떤 문제를 해결해야 할지, 어떤 취향을 담아 고객에게 전달해야 우리 제품을 쓰게 할지 고민할 수밖에 없는 시대(토스도 2, 3년 전에 했던 말이고, 꽤 많은 조직이 해온 이야기지만 지금 와서 훨씬 중요해짐)
(진행자의 "목적 조직을 어떻게 리드하는가" 추가 질문에) 특정 목적 조직 외에도 여러 조직을 겸하고 있음. 제품 리뷰/기술 리뷰/운영 이슈 등 방향을 정하는 흐름으로 조직을 리드하며, 예전엔 테크 직군과 주로 대화했다면 최근엔 기술과 AI를 함께 논의하는 경우가 늘어남

박성우 (한국디지털에셋) - 팀장급 대상

본인 팀은 팀원 전원이 팀장급 개발자(농담 반 진담 반)
- AI로 개인이 감당할 수 있는 업무 범위가 크게 넓어지면서 기존의 "팀" 개념 자체가 달라짐
"한 명 한 명이 팀으로 일해야 한다"는 이야기를 팀에 하고 있음
제품 방향 고민이나 커뮤니케이션 범위, 기술적 의사결정의 폭과 속도가 모두 넓고 빨라져, 기존처럼 팀 리드가 조언/코칭/리뷰를 해주기엔 속도가 따라가지 못하는 상황
- "나는 도대체 뭘 하는 사람인지" 회의감이 든 적도 있음
결국 개개인이 넓어진 범위에서 일할 수 있는 방향과 환경을 더 치열하게 고민해야 하는데, 팀원들이 그 속도에 지쳐가고 있진 않을까 걱정되는 시기

Q. AI 시대에도 변하지 않는 개발자의 핵심 역량은?

박용권 (당근마켓)

20년 내내 말해온 것 - 오늘의 나보다 내일의 나를 조금이라도 더 나아지게 하려는 태도. 그 성장 포인트를 끊임없이 찾아가며 노력하는 마음가짐은 AI 시대에도 동일

박성우 (한국디지털에셋)

책임감
- "마침표를 찍을 줄 아는 사람"이 가장 같이 일하고 싶은 사람. AI로 속도는 빨라져도 일을 완수하는 책임은 결국 그 사람의 몫

서동민 (두들린)

설계 - 코드를 짜는 행위 자체는 AI가 하지만, 무엇을 어디부터 어디까지 만들지, 다른 코드에 어떤 영향을 미칠지, 어떤 방향성으로 만들지 정의하는 것은 아직 AI가 못 하는 사람의 영역
그래서 "내가 이걸 어떻게 만들 것인가"를 설명하는 능력이 점점 더 중요해질 것

Q. 내일부터 회사에서 딱 한 가지를 바꿀 수 있다면?

박성우 (한국디지털에셋)

보안 특성상 운영 환경까지는 AI를 활용하지 못하고 있는 게 아쉬움 - 운영 환경 데이터 활용 방법을 고민 중

서동민 (두들린)

소스 관리, 제안(PR)/리뷰, 디자인 협업 등 기존 개발 프로세스를 AI 시대에 맞게 아예 무(無)에서부터 새로 만들고 싶음
- 지금의 프로세스는 사람 중심으로 짜여 있어 AI를 잘 쓰기엔 맞지 않는다고 봄
AWS의 AI DLC 프레임워크를 예로 들며, 직군별로 인원수를 다투던 시대는 끝났고 PM/엔지니어/디자이너 정도의 최소 구성으로도 충분히 만들 수 있는 시대라고 봄

AI DLC (AI Development Life Cycle): AWS가 제시하는, AI 활용을 전제로 재설계한 소프트웨어 개발 생명주기 프레임워크.

Inside Silicon Valley's Build Mode - Notion COO와 나누는 제품, 팀, 일하는 방식

Akshay Kothari(Notion 공동창업자 겸 COO)
진행: 이상아 (쿠팡)

Q. 노션 COO이기 전에, 실리콘밸리의 파운더이자 오퍼레이터로서 자기소개를 한다면?

인도에서 자라 미국에서 학사/석사를 마친 뒤, 스탠포드를 나오자마자 Pulse라는 회사를 창업
- 2013년 LinkedIn에 인수돼 약 5년 재직
2018년 노션에 여덟 번째 직원으로 합류해 다양한 역할을 거쳤고, 현재는 프로덕트/디자인/스토리텔링/브랜드를 맡고 있음

Q. 노션의 오리지널 비전 중 AI 때문에 바뀐 것은?

원래 비전은 소프트웨어 제작의 민주화
- 2천만 명의 개발자만 소프트웨어를 만들고 나머지는 쓰기만 해야 하는 구조를 바꾸고 싶었음
레고 블록에서 영감
- 동일한 블록으로 누구나 자신이 원하는 걸 조립할 수 있듯, 문서(docs) -> 데이터베이스 -> 자동화 -> 에이전트 순으로 "소프트웨어 블록"을 확장해 옴
AI 이전엔 사용자가 블록을 직접 조립해야 했다면, 이제는 원하는 언어로 말하면 AI가 대신 블록을 조립해줌
- 이걸 malleable software라고 부름

Malleable Software (말랑말랑한 소프트웨어): 플라스틱처럼 사용자가 자유롭게 변형/커스터마이징할 수 있는 소프트웨어라는 의미.

Q. 지난 1년간 노션의 의사결정과 가정은 어떻게 바뀌었나?

3, 4개월 전 출시한 개발자 플랫폼이 가장 큰 변화
1년 전 노션은 MCP/제대로 된 API/워커/액션이 없는 폐쇄적 플랫폼이었음
AI는 컨텍스트가 많을수록 좋아진다는 판단 아래, 노션을 "AI를 강제하는 폐쇄형"에서 "어떤 AI든 자유롭게 붙일 수 있는 완전 개방형"으로 전환
- 노션 자체는 기록의 시스템(system of record) 역할

Q. 여러 툴(슬랙/클로드/코덱스 등)을 오가며 일하는 개발자에게 노션은 어떻게 쓰이나?

개발자 플랫폼의 3가지 핵심 기능
- 임의의 데이터 소스 연결
- 특정 액션의 코드화
- 다른 에이전트를 노션 위로 불러오기
사내 소프트웨어 엔지니어링 팀은 노션을 하나의 "공장"처럼 사용 - 칸반 보드로 작업을 시각화하고, 클로드가 계획을 짜고 코덱스가 코드를 작성하고 또 다른 에이전트가 검수/배포하는 식
이 오케스트레이션 방식은 엔지니어링뿐 아니라 세일즈/마케팅 등 워크플로가 있는 모든 영역에 적용 가능
일부 고객은 노션 팀 자신보다도 이 방식을 더 잘 활용하고 있음

Q. 파운더 겸 오퍼레이터로서, 빠르게 변하는 AI 앞에서 전략을 어떻게 조정하나?

AI-필드 (AI-pilled): 실리콘밸리에서 쓰이는 표현으로, AI라는 새 기술의 힘을 의심 없이 받아들이고 적극 활용하는 사람을 가리킴.

예전엔 6개월 단위로 헤드카운트 계획과 제품 로드맵을 세웠는데, 이제는 사실상 실시간(just-in-time) 운영
- 매달 새 모델이 나오기 때문에 미리 계획하기 어려움
내부적으로 "모델과 싸울 수 없다, 강물이 흐르는 방향에 올라타야 한다"는 표현을 씀
- 로드맵도 향후 4-6주 정도만 구체적으로 그림
세 가지 축으로 방향을 유지
- 코어(문서/데이터베이스 등 시스템 오브 레코드)
- 에이전트 운영체제(에이전트/플랫폼웨어)
- 노션 링(문제 해결형 패키징 솔루션)
인원 수 기준 예산 대신 달러 기준 예산으로 전환
- 투자 결정도 실시간으로 이뤄짐
연례 컨퍼런스를 폐지하고 3개월마다 온라인으로 큰 런칭을 진행
- 물리적 행사는 준비에 6-9개월이 걸려 빠른 변화에 대응하기 어려움

Q. IC는 에이전트를 매니징하고 매니저도 IC 역량이 필요해지는 시대, 하이퍼포밍 팀은 어떻게 구성/운영돼야 하는가?

IC (Individual Contributor): 매니저 직책 없이 실무로 기여하는 개인 기여자.

아직 확실한 답은 없지만, 하나의 거대 팀보다 작은 팀 여러 개가 더 많은 프로젝트를 맡는 방향을 지향
코딩 에이전트를 제대로 다루는 2, 3명이면 상당한 힘을 낼 수 있음
- 실제로 노션의 개발자 플랫폼 전체를 12명 미만의 인원이 만듦(피자 두 판 팀 원칙)
기존 인력이 에이전트를 충분히 활용하도록 스킬업시키거나, 이미 익숙한 사람을 새로 채용해야 함
노션도 처음엔 소수의 AI-필드 직원에서 시작해, 지금은 전 직원이 AI 기반으로 사고하는 수준까지 확산됨

Q. (청중 질문) AI로 인한 "생산성 향상"이 실제 제품/서비스 생산성에 미치는 영향을 어떻게 측정하나?

Data Scout: 노션 사내에서 만든 커스텀 에이전트. 노션의 컨텍스트, MCP로 연결된 스노우플레이크(Snowflake) 데이터, 컴퓨터 사용 권한을 갖춰 데이터 사이언티스트가 하던 쿼리 작업을 누구나 할 수 있게 해줌.

노션의 초점은 개인이 아니라 "팀" 단위
- 한 사람이 만든 커스텀 에이전트를 회사 전체가 쓸 수 있다는 점이 핵심 힘
사례: 사내 엔지니어 한 명이 만든 "Data Scout" 에이전트를 하룻밤 사이 전사에 공유
- 이후 전 직원이 사실상 개인 데이터 사이언티스트를 갖게 됨
- 쿼리 1회당 3-4달러 비용에도 그만한 가치가 있다고 판단
데이터 사이언티스트 채용은 계속하지만, 역할이 "개별 쿼리 수행"에서 "시스템을 유지/고도화하는 역할"로 바뀜

Developer Reality Check - 개발자들은 진짜로 어떻게 생각할까?

김수빈 (당근마켓), 강현구 (센드버드), 성한영 (우아한형제들)
진행: 김만수 (센드버드)

Q. AI 사용 전후로 개발자로서의 하루가 많이 바뀌었다고 느끼는가?

성한영 (우아한형제들)

개발과 매니징을 병행하는데, AI를 쓴 뒤 처리할 수 있는 일의 양 자체가 늘어 요구받는 것도 많아짐
하루 업무가 여러 갈래의 짧은 단위로 잘게 쪼개질 만큼 달라짐

강현구 (센드버드)

목적에 다다르기 위한 행위(방법)는 많이 바뀌었지만, "무언가를 만든다"는 목적 자체는 그렇게 바뀌지 않음
AI 시대가 되면서 오히려 일이 많아지고 결국 해야 할 야근은 여전히 해야 해서, 하루가 크게 바뀌진 않았다고 봄

김수빈 (당근마켓)

원래도 팀에서 운영하는 개발자 플랫폼/서비스 제품이 많아, AI 도입 이전부터 여러 제품을 오가며 컨텍스트 스위칭하는 운영 업무가 많았음
AI가 이런 작업을 가속화하긴 했지만, 체감하는 컨텍스트 스위칭이나 개발량 자체는 이전과 비슷한 수준

강현구 (센드버드) - 자체 툴 제작 사례

슈퍼셋, 시냅스처럼 여러 터미널을 통합해 작업하는 툴이 나왔을 때도 "병렬로 일하는 게 정말 효율적인가" 의문이 있었음
직접 필요에 맞는 도구를 만들어보니 "도구가 없어서 그렇게 일을 못 했던 것"임을 깨달았고, 이후 일하는 방식이 많이 바뀜

성한영 (우아한형제들) - 매니저 관점

툴링을 직접 만드는 팀원을 볼 때, 문제 해결이 아니라 "도구를 위한 도구"를 만드는 자아실현으로 빠지는 경우를 경계함
그 경우가 아니라면 직접 도구를 잘 만드는 것 자체는 팀에 도움이 된다고 봄

Q. AI가 만든 결과물에 대한 신뢰도가 높은가?

강현구 (센드버드)

모델이 점점 좋아지면서 맡길 수 있는 일의 수준이 계속 올라가는 중
- 앞으로 더 좋아질 거라는 예측 아래 "지금 믿지 않고 쓰면 나중엔 믿을 수 있을까" 싶어 신뢰하려는 입장
다만 지금 당장 결과물이 늘 만족스러운 건 아니어서, 어떻게 지시해야 더 잘 쓸 수 있을지에 관심을 두는 편

김수빈 (당근마켓)

AI 신뢰도와 리스크는 저울질이 필요
- 본인이 개발하는 사내 플랫폼은 잘못된 결과물이 배포되면 인터페이스 롤백이 어려운 경우가 있어 한 번 더 검증하는 습관을 유지
코딩은 99% 이상 AI 에이전트로 생성하지만, 로컬/스테이징/운영 등 여러 검증 레이어를 리스크 수준에 따라 다르게 쌓아서 신뢰도를 관리
- 예: 로컬 시뮬레이션, 스테이징 배포 후 시뮬레이션, 운영 환경 성능 테스트, 다양한 에이전트를 통한 코드 리뷰 등

성한영 (우아한형제들)

사내 AX 도구를 직접 개발하는 입장이라, AI에게 일을 시켰을 때 원하지 않는 방향으로 나오는 경우를 계속 마주하며 개선 포인트를 찾게 됨
다만 목표는 신뢰도가 높은 상태를 만드는 것

Q. 신뢰도를 높이기 위한 가드레일이나 팁이 있는가?

강현구 (센드버드)

원하는 결과가 나오도록 인풋(지시사항)을 최대한 구체적으로 명시
SDK 개발 특성상 특정 부분 수정 시 사이드 이펙트 발생 여부가 중요한데, 에이전트 10개 정도를 병렬로 띄워 사이드 이펙트를 체크하고 재현율이 높은 것들을 추려 추적 - 대부분의 경우 문제 지점이 높은 확률로 드러남

Q. AI 도입 후 컨텍스트 스위칭이 늘었다고 느끼는가?

성한영 (우아한형제들)

코드를 손으로 직접 치지 않게 되면서 물리적으로 확보되는 시간이 늘어, "이것도 해보고 싶고 저것도 해보고 싶은" 일이 많아짐
- 그 결과 컨텍스트 스위칭도 자연히 늘어남

김수빈 (당근마켓)

컨텍스트 스위칭의 "종류"가 달라졌을 뿐, 종합적으로는 오히려 줄어든 느낌
예전엔 개발자 요청이나 이슈를 그때그때 바로 처리해야 했다면, 지금은 에이전트가 미리 처리하거나 빠르게 대응하는 경우가 늘어, 단순 업무에 쓰는 시간은 줄고 플랫폼 고도화/재설계처럼 깊은 고민이 필요한 일에 더 오래 집중하는 쪽으로 바뀜

Q. 노트 테이킹과 업무(태스크) 관리는 어떻게 하는가?

성한영 (우아한형제들)

매니저로서 우선순위 관리가 어려운 자리인데, 주간 단위로 클로드 등 AI 자동화를 활용해 컨텍스트를 정리
팀원이 업무 내용을 글로 잘 정리해서 공유해줄수록(컨텍스트가 풍부할수록) 더 잘 이해하고 해결할 수 있는데, 컨텍스트 정보가 적은 팀원의 업무는 파악하는 데 더 고민이 필요

강현구 (센드버드)

매니저가 아니라 개인 업무 자체는 AI 이후로도 크게 달라지지 않음 - 기존처럼 티켓 기반으로 생성/관리
부가적으로 들어오는 업무는 슬랙 "나에게 메시지 보내기"로 간단히 기록
- 슬랙에 클로드를 연동해두면 바로 실행하거나 컨플루언스 문서 업데이트까지 가능해 편리

김수빈 (당근마켓)

메신저는 슬랙, 문서화는 노션, 티켓/이슈 관리는 리니어(원문 "미디어", 정확한 툴명 확인 필요)를 사용
슬랙/구두로 논의된 업무가 노션에 정리되고, 그 주/그 달에 실행하기로 확정된 것은 이슈로 등록
- 이슈 하나가 에이전트 하나가 실행하는 작업 단위가 됨
필요하면 서브 이슈를 만들어 서브 에이전트에게 맡기고, 에이전트가 작업한 로그를 다시 이슈 코멘트로 남기는 방식

Q. IDE 없이 터미널(클로드 코드 등)만으로 작업이 가능한가?

강현구 (센드버드)

IDE는 거의 열지 않게 됨
- 회사에서 지원하던 커서도 비용이 아까워 정리하려는 중
최근엔 "에이전틱 IDE"로 불리는 컴포저/슈퍼셋/오르카 같은 도구로 터미널 기반 작업을 하면서, 필요할 때만 간단히 코드를 보는 정도

김수빈 (당근마켓)

IDE 사용 비중은 업무의 약 10% 정도
- 코드 리뷰나 직접 검증이 필요할 때, 터미널에서 눈으로 코드를 따라가기 어려운 부분을 IDE로 파악하는 용도로만 사용

Q. 회사에서 AI 도구를 얼마나 지원해주는가?

성한영 (우아한형제들)

클로드를 전사에 지원 중이며 전 직원이 사용
- 개발자들의 활용 속도가 매우 빠름

김수빈 (당근마켓)

개발자와 비개발자가 동일하게 지원받고, 원하는 것을 지원해주는 정책
사내에서 효용이 검증된 도구(앤트로픽 클로드, GPT/코덱스, 커서) 중 예산에 맞게 선택
- 클로드 맥스만 쓰거나, GPT와 코덱스를 반반 쓰거나, 코덱스 200달러 플랜을 쓰는 식
서비스에 사용하는 LLM API는 특별한 제한 없이 원하는 모델을 사용

강현구 (센드버드)

대부분의 툴을 지원하는 방향
- 클로드 코드는 팀 플랜이 열리자마자 전사 제공, 코덱스도 성능이 좋아진 이후 지원 시작
비용 측면에서 너무 비싸지지 않게 효율적으로 지원할 방법을 계속 고민 중

Q. AI를 잘 쓰는 개발자가 일도 잘한다고 느끼는가?

성한영 (우아한형제들)

반대라고 생각
- AI를 잘 써서 일을 잘한다기보다, 일을 잘하는 사람이 AI를 잘 가르치고 다루는 경우가 많음
결국 AI가 만든 코드 중 무엇을 채택할지는 사람이 정하는 것
- 이 도구를 어떻게 잘 다룰지 깊게 고민하고 접근하는 사람 자체가 희소하고, 그 고민이 이 시대에 가치 있는 것

강현구 (센드버드)

어느 쪽이라고 답해도 차이가 없을 것 같아 고민했는데, 시간이 지날수록 AI를 잘 쓰는 개발자가 고민도 잘한다고 느낌
결국 일을 잘하는 사람이 AI도 잘 쓴다는 쪽으로 둘 다 해당

김수빈 (당근마켓)

AI를 잘 쓰는 것은 일을 잘하기 위한 여러 조건 중 하나일 뿐, AI를 잘 써도 일을 못 할 수 있다고 봄
AI를 다루는 능력 자체는 점점 평준화되고 있다고 느낌
원래 일을 잘하던 사람에게 AI는 "날개를 달아주는 것"일 뿐
- AI를 위한 도구, 에이전틱 워크플로를 만드는 일 자체에 매몰되는 것을 경계

What's new in SwiftData (feat. WWDC 2026)

2026-07-12T18:36:37+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 WWDC 2026에서 나온 SwiftData 부분에서 업데이트 사항들에 대해 살펴보고 정리해보겠습니다

Sectioning your fetches

먼저 SwiftData에서 섹션별로 데이터를 가져오는 방법을 보겠습니다.

이제는 이렇게 쿼리에서 옵션을 주어 그룹별로 묶을 수 있어요.

각 섹션에선 ID 속성이 있고 이걸 활용하게 됩니다.

Using custom types

모델에 커스텀 타입을 저장하는 기능 향상을 살펴볼께요.

SwiftData는 로드될 때 모델에 대한 스키마를 자동으로 생성합니다.

스키마는 모델 클래스와 엔티티간 매핑을 정의하죠.

대부분의 타입에선 이게 자동으로 작동해요.

그렇지만 모델 매크로로 어노테이션 되지 않은 클래스는 자동으로 검사할 수 없기에 SwiftData는 스키마 생성에 실패합니다

만약 그렇다고 구현체에 접근할 수 없을 수 있잖아요?

그런 경우 이렇게 어트리뷰트 codable을 사용하여 주면 해결됩니다.

이 속성은 SwiftData에 타입의 인코딩된 표현을 저장하도록 알려주는 역할을 합니다.

타입에 대한 스키마를 추론하는 대신에요.

다만 염두해둬야할게 있는데, codable 속성의 내용은 SwiftData에 불투명합니다.

이는 Predicate에서 결과를 필터링하는데 사용할 수 없음을 나타내요.

또는 정렬도 사용할 수 없어요.

또한 codable 형태가 변경되면 속성을 추가하거나 제거하는 경우 마이그레이션이 트리거되지 않아요.

이 점을 주의해야 합니다!

Codable 속성 사용은 SwiftData가 기본적으로 지원하지 않는 타입을 저장하는 탈출구라고 생각하면 좋습니다.

직접 정의했다면 왠만해선 Codable 사용을 금해야 합니다.

Observing data stores

스토어를 모니터링하고 데이터 변경 시 알림 받는 방법을 살펴볼께요.

SwiftUI에서는 이렇게 데이터가 변경되면 뷰가 쿼리의 새로운 결과를 반영해 다시 렌더링합니다.

만약 SwiftUI가 아닌 부분은 어떨까요?

이걸 위해 이번 2027 릴리즈에선 ResultsObserver를 도입했습니다.

SwiftUI 쿼리처럼 데이터 가져오고 관찰하고 반영시키는 Swift Observation을 사용해요.

이런식으로 사용될 수 있습니다.

withContinuousObservation은 ObservationTracking 토큰을 반환합니다.

이 토큰이 관찰의 수명을 정의하죠.

여기서 더 나아가 이번 업데이트에서는 히스토리 관찰도 지원해줍니다.

데이터 스토어가 저장될 때마다 SwiftData는 히스토리 트랜잭션을 기록합니다.

여기에는 변경된 내용에 대한 정보가 포함됩니다.

그리고 변경이 어디서 왔는지 조차도 포함되죠.

히스토리에서 트랜잭션을 고유하게 식별하는 토큰도 있습니다.

ModelContext.fetchHistory() 이 API와 토큰을 함께 사용할 수 있어요.

HistoryObserver는 스토어의 변경 사항에 쉽게 반응할 수 있게 해줍니다.

지속적 히스토리 관찰과 새로운 트랜잭션 추가 시 코드가 반응하도록 해주죠.

특정 종류의 변경만 관찰하고 대응하고 싶다면 물론 HistoryObserver를 사용해 모델 타입과 트랜잭션 작성자로 필터링할 수 있어요.

외부 서버와 같은 다른 시스템과 연동 시 효과적이죠.

외부와 연동하는 예시를 볼까요?

이렇게 간단히 코드로 나타내서 사용할 수 있습니다.

References

SwiftData의 새로운 기능 - WWDC26 - 비디오 - Apple Developer

SwiftData의 최신 개선 사항을 확인하세요. Codable을 사용하여 맞춤형 및 타사 유형을 유지하는 방법과 가져온 데이터를 SwiftUI 앱의 섹션으로 그룹화하는 방법을 안내합니다. 또한 ModelResultsObserver와

developer.apple.com

느즈막히 올려보는 쿠팡에서의 회고 (feat. 또다른 시작)

2026-07-06T13:39:50+09:00

안녕하세요. 그린입니다

이번 포스팅에서는 사실 기술적인 부분보다 회고를 하나 해볼까 합니다.

제가 근 1년 6개월 정도 근무했던 쿠팡을 떠나게 되었는데, 사실 쿠팡 입사 직후와 3개월쯤 되었을때 각각 쿠팡 이직기라던지 쿠팡에서의 일상 회고를 해보려 했는데, 일과 개인적인 바쁨에 치여 결국 쿠팡을 나올때 이렇게 회고를 올려보네요

그래서, 이번 회고는 역시나 무근본 무형식으로 그냥 두서없이 한번 적어보려고 합니다

쿠팡 입사

25년 2월에 쿠팡으로 이직을 하게 됩니다.

왜 이직했는지 그냥 지금와서 간단히 정리해보면, 정말 글로벌 서비스를 하는것과 글로벌 회사에서 일하는것을 경험해보고 싶었어요.

이전까지는 iOS 개발자 1인으로 내 할일을 다하는것에 초점이였다면 앞으로의 성장을 생각했을때 그걸 넘어서 정말 일을 잘하는 사람이 되고 싶었어요.

개발에 국한된게 아니라 일을 잘하는 사람이요.

그랬을때 좀 더 큰 대규모의 서비스를 경험해보면서 다국가 인종과 일하는 경험 이 두가지가 쿠팡을 지원하고 입사를 하게된 가장 큰 이유였습니다

그래서 쿠팡에서 쿠팡이츠라는 O2O 배달 앱 서비스의 시니어 iOS 엔지니어로 근무를 하게 됩니다.

그럼 쿠팡에서의 1년 6개월을 돌이켜봤을때 어떤것을 해왔고 어떤걸 배웠는지 한번 정리해볼까해요.

Life in Coupang

우선 일은 굉장히 굉장히 하드워킹이긴 했습니다.

그렇다고 밤낮이 없는 삶, 원양어선 그런건 아니였어요.

그냥 주어진 시간에 정말 1초도 쉬지 않고 일하면 다 끝날 수 있는 그런 정도..?

제가 맡은 TF는 주로 Ads TF였습니다.

배달 앱의 특성 상 배달이나 플랫폼 수수료 같은걸로는 정부 규제도 있고 단가가 그렇게 크지 않아 사실상 사업적인 부분에서 큰 이익이 되지 않는다고 생각해요.

그렇기에 또 다른 비지니스적인 부분을 고려할때 광고를 무시할 수 없습니다.

점포나 메뉴 광고가 주인데 어떤 부분에 배치하거나 어떤 시간대에 어떤걸 배치하면 이 점포를 가장 극대화되어서 CPC나 CPS를 올릴 수 있을지 같이 고민하고 여러 실험을 해보는 그런 TF입니다.

광고라는 도메인이 익숙치도 않고 처음 해보는거였지만 그만큼 재밌었어요.

직접적으로 주간으로 광고를 통해 얼마나 많은 매출에 기여했는지 확연하게 눈에 보일 수 있었기에 더 동기부여가 되었습니다.

또한, 광고 TF말고도 두루 경험해봤던것도 큰 기억으로 남아요.

핵심인 음식 배달과 요즘 밀고 있는 쇼핑(마트나 편의점, 꽃집 등등 - 푸드가 아닌 모든것) 그리고 고객들의 VOC나 편의성을 개선하기 위한 CRM TF 등 한 팀에 정말 다양한 TF가 로테이션으로 돌아가며 일을 하게 되는데 이 모든것의 비지니스 태스크를 한번씩은 해본것 같습니다.

그러다보니 자연스레 다양한 코드들을 보게되고 깊게 이해하게 되었어요.

이렇게 거시적으로 볼 수 있는 비지니스적인 일은 어떻게 했는지에 대해 간단히 회고를 해본다면 이제는 팀에 대한 회고를 해볼까해요.

사실상 가장 많이 짧다면 짧은 시간에 성장할 수 있게 된 원동력이 바로 소속된 iOS 팀이였습니다.

솔직하게 지금까지 나름 다양한 회사도 다녀보고 여러 동아리도 해보고 컨퍼런스도 다녀보면서 교류해봤지만 개발자 개개인의 역량으로는 쿠팡이 가장 월등하다고 느꼈어요.

쿠팡의 채용 과정이 정말 복잡하고 난이도가 큰 편이라 더 그런지는 몰라도 개발자의 능력은 어느 회사보다도 뛰어나다고 확신할 수 있습니다.

그렇기에 같이 부딪히며 토론하고 때론 설전도 벌이면서 일을 하면서 성장한것 같아요

쿠팡에서 일하기 전까지의 저를 돌이켜보면 iOS 개발 맡은거 능히 해낼 수 있는 개발자라고 말할 수 있다면, 여기서 배운건 그건 당연히 해야되는거고 그거 말고도 너가 더 뭘할 수 있는데?에 대한 푸시가 많고 그걸 잘 끌어올려줄 매니저와 팀원들이 존재했습니다.

너가 1인분 하는건 당연히 시니어 개발자가 아니라 주니어 개발자여도 당연히 해야되는거고, 그걸 넘어서 시니어 개발자라면 팀에 어떤 영향을 미칠 수 있는지 고민하고 iOS 뿐만 아니라 더 스펙트럼을 넓혀서 안드로이드, 웹을 포함한 프론트 그리고 백엔드까지 비지니스 스펙을 받으면 고려해서 테크적인 리드를 할 줄 알아야 하며 그런 부분을 하드 트레이닝을 많이 했던것 같아요.

그래서 일감이 주어지면 항상 어떻게 개발해야하지? 라는 생각보다 이게 정말 괜찮은 실험인지 이 실험을 성공시키기 위해서 각 파트에서 어떤 노력을 기울이면 좋을지 그리고 그게 제일 효과적인 방법일지를 고민하게 저의 일을 접근하는 방식 자체가 많이 변화한것 같아요.

그전에는 iOS 앱 개발 부분에서만 고민했다면 이제는 백엔드와의 트레이드오프도 생각해보고 좀 더 크로스 플랫폼에서 일하기 적절한 방법과 그리고 기능 개발 대비 어느정도 인력 코스트가 들어가는지 그런것들까지 고민하고 제안을 하게 되는 개발자로 성장했어요.

그리고 그건 제가 원하지 않아도 쿠팡에서 일을 하면 자연스럽게 요구되는 역량이고 그렇게 변하게 만들어주더라구요

그리고 팀적으로도 매주 테크 미팅을 통해 서로 기술을 공유하고 새로 맡은 비지니스 일감이 있다면 항상 먼저 테크 디자인을 한 후 공유해서 더 나은 방향이 있는지를 모바일 팀 자체적으로 더 체크를 합니다.

이렇게 꼼꼼하고 다양한 의견을 듣다보면 자연스럽게 시야도 넓어지게 되더라구요.

쿠팡에서는 이렇게 정말 많은 미팅과 룰과 일이 존재해요.

그러다보니 눈코 뜰 새가 없는건 사실이지만 어떻게 보면 가장 이상적인 시스템이라곤 생각이 되더라구요.

그 시스템에서 번아웃이 안오고 버티는게 힘든것 뿐이지만 회사적인 측면으로만 보면 합리적이고 비지니스가 성장할 수 있는 시스템이란 생각이 많이 듭니다.

그리고 또 많이 성장했던 부분은 바로 영어일것 같아요.

사실 영어를 잘하지 못했고 지금도 그렇지만 하나 달라진건 자신감인것 같아요.

회사에선 공식적으로 한국어로 일하는것 자체가 없어요.

공용 언어가 영어이기에 슬랙, 위키 등등 모든것이 영어죠.

그리고 미팅도 통역이 제공되는 경우도 있지만 기본이 영어입니다.

그러다보니 사실 살려면 해야됐었어요.

저도 처음에 입사해서 "아 이거 일보다 커뮤니케이션이 영어라 따라갈 수 있나?" 싶었어요.

그래서 슬랙도 그렇고 번역기에 번역하고 하고 싶은 말도 번역해서 떠듬떠듬 치고 그랬죠.

그런데 이게 일상에 녹아드니 별다른 영어 공부를 하지 않아도 자연스럽게 익숙해지기 마련이더라구요.

그 전에는 예를 들어 "이거 확인해주실 수 있나요?" 라는걸 영어로 말해야된다 생각하면 머릿속에서 문법부터 생각하고 완성한 다음 이게 진짜 맞나 고민하고 그런것들때문에 영어가 입 밖으로 더 안나왔던것 같아요.

그런데 이제는 일단 문법이 다 맞지 않고 그렇더라도 이 바쁜 일상에서 우선 커뮤니케이션이 우선이고 먼저 말해야된다는 압박이 있다보니 자연스레 "Could you check this?"와 같이 나오게 되더라구요.

물론 더 좋은 표현도 있고 하겠지만 배운 한가지가 자신감이라 했잖아요?

이 자신감은 확실히 익힌것 같아요.

이제 말로 표현하고 문장으로 쓰는게 내가 틀렸다 하더라도 두렵지가 않게 되었습니다.

그리고 앞서 계속 말했지만 팀원들 정말 훌륭하고 귀중한 팀원들 그리고 타 팀의 교류하는 사람들 모두 좋은 인프라를 쌓을 수 있어 감사했어요.

일이 빡센만큼 전우애가 더 많이 생기게 되는 쿠팡이였어요.

나간다니 이런 것까지 해주는 팀원들인데 어떻게 잊을 수 있을까 싶어요.

그래서 정리해보면 쿠팡에서 생활하면서 성장한 부분은 이렇습니다.

1️⃣ 기술적인 견고함과 더 넓게 바라볼 수 있는 시야

2️⃣ 개인 혼자만이 아니라 팀 전체에 영향을 미칠 수 있는 사고

3️⃣ 영어 의사소통

4️⃣ 정말 비지니스적으로 어떤것들이 도움되는지에 대한 고민

이 외에도 서버 드리븐적인 설계, 대쉬보드들을 구축해서 모니터링을 강화하는 방법, 장애 대응, AI 오너로써 팀을 이끌어본 경험 등등 기술적으로나 팀에 영향을 주는 부분으로나 정말 다양한 포인트들이 있지만 그거까지 쓰면 한도 끝도 없을것 같아 우선 쿠팡에서의 라이프는 간략하게 이정도로 마칠까 합니다.

그럼 가장 중요한 포인트인데 왜 쿠팡을 떠나는지에 대해 간단히 정리하고 마쳐보려고 해요.

Why am I leaving Coupang?

당연히 이직이 쉬운 선택도 아니고 또 새로운 도전을 하는것은 더더욱 쉬운 선택이 아닙니다.

그리고 그런 결정을 하기까지에는 정말 큰것부터 정말 사소한것까지 많은 복합적인 부분이 상호작용 할거에요.

여기선 몇가지 핵심적인 이유를 전해볼까해요.

우선, 쿠팡이 다니기에 좋지 않은 회사다 라는것은 전혀 아닙니다.

일이 힘들 순 있지만 그거때문에 이직하는건 도피라고 생각해요.

어딜가나 힘든건 있기 마련이고 일이 바쁘다고 나가는건 근로자의 덕목이 아니라 생각하기 때문이죠.

1️⃣ 더 넓은 글로벌 서비스

가장 큰것중 하나는 바로 이 항목이에요.

쿠팡이츠를 개발하면서 현재는 한국과 일본을 타겟으로 서비스하고 있는데, 일본을 고려해서 글로벌한 서비스를 구축하고 운영하다 보니 정말 더 많은 나라들 나아가서 대륙들을 타겟으로 하는 더 큰 글로벌 서비스들이 궁금해졌어요.

그리고 글로벌 서비스를 해보니 재미가 있더라구요.

같은 앱이지만 각 문화 환경에 따라 원하는 화면과 폰트 배치들이 다르다는것도 세삼 느끼게 되면서 뭔가 리전을 바꿀때마다 여행하는 느낌이 들었어요.

직간접적으로 그 나라를 체험해보는거죠.

그래서 이를 충족하는 서비스를 해보고 싶다는 생각이 컸습니다.

2️⃣ 컨텐츠 플랫폼에 대한 니즈

그리고 저는 사실 개발자를 처음 해올때부터 사용자들이 몰두할 수 있는 컨텐츠 플랫폼을 해보고 싶었어요.

지금까지는 주로 커머스, O2O와 같은 사용자들이 앱에 들어와서 빠르게 확인하고 구매하고 나가는 그런 동선으로 비지니스를 이끄는 서비스였어요.

그러다보니 한 화면에서 애니메이션이나 더 심미적인 부분보다는 탐색 플로우나 결제 플로우에서 로직과 빠른 구매가 더 중요해지더라구요.

그래서 한편으로는 그런 부분들을 많이 다룰 수 없었어요.

여담이지만 저는 KWDC 2023에서 SwiftUI 애니메이션 관련 세션을 발표할 정도로 심미적인것과 사용자의 더 아름다운 경험을 구현하는걸 원하고 좋아하는 개발자에요.

그래서 그런 부분을 채울 수 있는 컨텐츠 플랫폼 서비스를 꼭 해보고 싶었어요.

그럼 왜 여태까지 그런거 안했냐? 라고 한다면 안한게 아니라 못했던거라고 할 수 있어요

사실 알려진 컨텐츠 플랫폼 앱이 몇개 되지도 않지만 제가 원한다고 내일부터 그 회사에 들어가서 해볼 수 있는건 아니잖아요..?

무튼 그래서 컨텐츠 플랫폼을 향한 저의 개발자로서의 니즈가 이직의 큰 몫을 했습니다.

3️⃣ 거리

마지막으로 누군가한테 사소할 수도 있지만 저한테 큰 부분이였던건 회사와의 거리였어요.

사실 쿠팡에 입사한것도 처음엔 하이브리드로 재택이 존재했기에 공고나 계약도 그렇게 진행되었어요.

그래서 선릉까지 출퇴근하는게 매일이 아니니 부담스럽지 않고 현실적으로 가능했죠.

그런데 작년부터 풀출근으로 근무제도가 변경되면서 이는 적지 않은 부담으로 다가왔어요.

(물론 모든 쿠팡 부서가 그런건 아니고 근무제도는 조직장에 따라 모두 부바부입니다.)

그러다보니 출퇴근 하는데 드는 시간, 체력소모, 비용 그런것들까지 트레이드 오프 되는것을 생각해볼때 쿠팡이 큰 메리트가 되지 않는단 생각이 문득 들더라구요.

그래서 사소할 수 있지만 저한텐 어떻게 보면 심리적으로 가장 큰 부분이였어요.

이런 대표적인 이유 + 말하진 않았지만 더 많은 이유들이 상호작용하여 이직을 결심하게 되었습니다.

(혹시 말하지 않았지만 더 많인 이유들이 궁금하시다면 연락주세요 ㅋㅋㅋ)

그래서 이번엔 어딜 가는데?

이번에는 1과 2그리고 3번의 이직 이유들을 충족할 수 있는 곳으로 가게되었어요.

네이버웹툰에서 글로벌 웹툰 iOS 앱 개발에 기여하게 되었습니다.

아직 출근전이고 이 글이 나가는 시점에서 한 주 후 첫출근을 하게 될 예정이라 떨리네요 ☺️

인터뷰들을 진행하며 제가 더 다른 성장하고 싶은 포인트와 해소하고 싶은 포인트들을 네이버 웹툰에서 더 다양하게 해볼 수 있을것 같아 많은 기대가 됩니다!

아 그리고 현재 쿠팡에서 해당 제 포지션의 채용이 열려있어요!

관심 있으시거나 궁금한 부분이 있으신 분은 언제든 편하게 연락주시면 제가 아는선에서 알려드리고 도와드릴께요

제가 장담하건데 꼭 다녀봐야할 회사라고 생각합니다.

Sr Mobile Engineer (Eats iOS)

쿠팡이츠(Coupang Eats)는 쿠팡의 음식 배달 서비스이자,대한민국에서 빠르게 성장하고 있는 배달 서비스입니다. 2019년 국내 배달 업계에 혜성처럼 등장한 쿠팡이츠는 2024년 ‘무제한 무료배달’로

www.coupang.jobs

또 어떤 재밌는 일들이 벌어지고 경험하게 될지 모르겠지만, 언젠가 또 좋은 회고로 찾아오도록 하겠습니다

브라우저의 메인 스레드는 비싸다

2026-07-12T09:00:00+09:00

프론트엔드 최적화라고 하면 무엇이 떠오르는가? 대체로 네트워크 요청을 줄이거나 번들 크기를 줄이고 캐시를 잘 쓰는 일을 떠올린다. 그 외에는 리렌더링 줄이기나 리소스를 불러오는 타이밍쯤이 떠오를 것이다. 보통 메인 스레드를 떠올리기는 쉽지 않은데…

Cloudflare Tunnel 다운로드 속도 100배 높이기 (QUIC → HTTP/2)

2026-07-09T22:40:00+09:00

수십억대의 장비에서 동작하는 DBMS엔진의 개발자, 리처드 힙(Richard Hipp)

2026-07-13T00:00:00+09:00

힙은 조지아 공대(조지아테크)에서 전기공학을 전공하고, 듀크대학에서 음성 자연어 대화 처리 시스템에 대한 연구를 수행한 후 전산학 박사 학위를 받습니다. 이후 AT&T 벨 연구소에서 스태프 엔지니어로 C/Unix 프로그래밍 관련 업무를 담당했으며, 이후 DARPA 및 제너럴 다이나믹스사 등 회사 고객에 맞춤화된 솔루션은 전문적으로 제공하는 Hipp, Wyrick & Company, Inc(줄여서 Hwaci라 쓰고, 와치라 읽습니다)를 설립합니다.

HWACI사는 2000년 봄 미 해군의 유도미사일 구축함 프로그램용 소프트웨어 개발 계약을 따냅니다. 이런 종류의 프로젝트에서는 데이터를 처리하기 위해 데이터베이스 시스템이 필요합니다. 기존에는 인포믹스와 같은 RDBMS를 따로 구축하여 사용했는데, 해군 함정에서 사용하기는 너무 번거로웠죠. 그래서 미 해군은 관리부담을 최소화시킨, 별도의 설정 작업 없이 배포할 수 있으면서도 안정적인 성능을 제공하는 내장가능한 SQL 데이터베이스 엔진을 요구합니다. 힙은 이 과제를 수행하기 위해 공개 도메인 데이터베이스를 개발하는데, 이것이 바로 SQLite의 시작입니다.

원래 미 해군이 개발하던 소프트웨어는 DDG-79 오스카 오스틴 전함에 탑재될 예정이었습니다. 이런 전함은 매우 크고 복잡한 시스템이빈다. 따라서 각 부품의 연결 정보 등을 기반으로 바뀌는 환경에 대해 바로 대응할 수 있는 제어/판단 시스템이 필요합니다. 그런 시스템의 기반에는 전함의 배관 정보 및 밸브 정보 등이 저장되어야 합니다. 그렇다고 전함에 DBMS를 설치하면 프로그램을 사용할 사용자 말고 DBA도 탑승해야 합니다. 그렇지 않으면 프로그램을 실행했는데 "데이터베이스에 연결할 수 없습니다"라는 경고창이 표시될 테니깐요. 이 문제를 해결하기 위해 리처드 힙이 뛰어듭니다.

미 해군의 요구사항은 SQLite의 핵심 기능이 됩니다. 서버리스 방식으로 작동하므로 별도의 서버 프로세스를 실행하지 않고 애플리케이션에 라이브러리 형태로 내장됩니다. 설정 파일도 지원되지만, 별도의 설정을 하지 않아도 내장하면 바로 사용할 수 있습니다. 데이터베이스 기능을 제공하지만 라이브러리의 크기는 900KB 보다 작은 크기로, 소형 단말에서도 자유롭게 사용할 수 있습니다. 그 덕분에 SQLite는 iOS/AOS 스마트폰, 웹 브라우저, 자동차, 의료기기 등 수많은 애플리케이션에 내장되어 역사상 가장 많이 배포된 데이터베이스 엔진으로 자리잡게 됩니다.

SQLite로 알려진 힙이지만, 여러 다양한 소프트웨어 프로젝트도 진행합니다. 그중에서 Fossile SCM은 git과 유사한 분산 버전 관리 시스템 소프트웨어입니다. SQLite 개발도 Fossil 기반으로 진행됩니다. 또한 Tcl 스크립트 언어의 발전을 위해 주요 확장 기능과 도구를 개발해 오고 있습니다. 트리 위젯, 노트북 위젯, HTML 위젯 등 다양한 Tcl/Tk 모듈을 개발해 왔습니다. (TCL의 아버지 존 아우스트하우트 이야기도 읽어보세요.)

복잡함은 당신의 적입니다. 최대한 단순하게 유지하세요
처음 떠오르는 해결책을 바로 사용하지 마십시오, 문제를 좀 더 생각해 보면 더 나은 접근 방법을 찾을 수 있는 경우가 많습니다.
코드, 특히 데이터 구조와 변수 정의에 대해 꼼꼼히 주석을 다세요. 다른 사람이 읽고 이해하여 유지 관리할 수 있는 코드를 작성하세요. 내용을 명확히 설명하세요.
테스트를 고려하여 설계하세요. 작동하는 소프트웨어를 작성하는 것만으로는 충분하지 않습니다. 검증이 쉽고, 작동 여부를 금방 테스트할 수 있는 소프트웨어를 작성해야 합니다.
(좋은 소프트웨어 설계 원칙에 대한 질문에 대한 답변)

인공지능은 분명 유용합니다. 앞으로 인공지능의 새로운 활용법이 발견될 것이고, AI기술은 귀중한 시간 절약 도구가 될 것이라고 확신합니다. 하지만 인공지능이 세상을 완전히 장악할 것이라는 종말론적 예측에는 회의적입니다.

문제를 만드는 것보다 더 많은 문제를 해결하세요.
할 수 있는 한 많은 문제를 해결하세요. 작은 일부터 시작하세요. 침대를 정리하고, 쓰레기를 주워 쓰레통에 버리고, 가게 계산원에게 친절하게 대하세요. 이런 작은 일들은 더 큰 문제를 해결하는 데 좋은 연습이 됩니다. 작은 일들에 익숙해지면 더 큰 문제에 도전해 보세요. 가족과 친구를 돕고, 고객을 돕고, 지역 사회에 기여하세요. 문제를 일으키는 것보다 더 많이 해결할 수 있다면, 직업, 친구, 사랑, 행복이 부족할 일은 없을 것입니다.

진정으로 자유롭고 싶다면 스스로 행동해야 한다는 뜻입니다.

풀 리퀘스트(PR)는 공짜가 아닙니다. 사실상 제게 요구를 하고 있는 겁니다. 이렇게 멋진 기능을 내가 개발했으니, 당신이 그걸 유지보수하고 문서도 작성하고 테스트하면서 계속 유지보수해 주길 바라는 겁니다.
리누스가 한 명언이 있습니다. Free라는 단어는 무료 맥주를 의미하거나 표현의 자유를 의미할 수 있습니다. 하지만 또다른 Free가 있습니다. '내가 공짜 강아지를 한마리 입양해 줄게"
풀 리퀘스트는 누군가가 당신에게 강아지 한마리를 입양해 주는 것과 같습니다. 당신은 그 강아지를 버릴 수도 없습니다. 도덕적인 책임감 때문에 강아지가 죽을 때까지 돌봐야 합니다.
나는 그런 공짜 강아지를 원하지 않습니다.

당시 전문가들에게 물어보면 "불가능해. 절대 안 될 거야. 말도 안 되는 생각이야."라고 했을 겁니다. 다행히 저는 그런 전문가들을 알지 못했고, 그래서 그냥 해냈습니다. 이런 일도 종종 일어나는 거죠. 제 생각에는 전문가들의 말에 너무 귀 기울이지 말고, 스스로 이치에 맞는 일을 하는 게 중요한 것 같습니다. 문제를 해결하세요.

Home Page for D. Richard Hipp

www.hwaci.com

The Untold Story of SQLite

On today's show, I'm talking to Richard Hipp about surviving becoming core infrastructure for the world. SQLite is everywhere. It's in your web browser, it's in your phone, it's probably in your car, and it's definitely in commercial planes. It's where you

corecursive.com

Entrevista a Richard Hipp

Creador de SQLite

camilocs.substack.com