AI로 촉발된 개발 패러다임의 변화가 이것을 가능하게 했습니다. 예전에는 공통 모듈을 만들고 커스터마이징하는 방식이 효율적이었다면, 지금은 각 프로젝트의 맥락에 맞는 코드를 빠르게 생성하고 검증하는 방식이 더 효율적인 경우가 많아졌습니다.

실제 케이스를 하나 들어보자면, SOLID는 커스텀 기능을 원하는 Cafe24 쇼핑몰 클라이언트를 위해 자동화되고 정밀한 제어가 가능한 안정적인 솔루션을 제공합니다. 이미 다수의 고객들로부터 검증된 자체 제작 컴포넌트와 더불어, 완전한 클라이언트 맞춤 지원 시스템입니다. "이 기능은 Cafe24에서 안 돼요"라는 말 대신 "어떻게 구현하면 될까요"라고 말할 수 있게 된 것, 그게 SOLID의 역할입니다.

모바일로의 확장

2025년, 저희는 웹을 넘어 iOS와 Android 앱 개발에도 본격적으로 뛰어들었습니다. 그리고 프로덕션 앱을 성공적으로 런칭했습니다.

모바일은 언제나 매력적인 영역이었습니다. 사용자의 손 안에서 직접 작동하는 소프트웨어, 푸시 알림 하나로 다시 돌아오게 만드는 경험, 네이티브 기능과의 긴밀한 연동―웹에서는 느끼기 어려운 즉각적인 피드백이 있습니다. ―솔직히 말하면, 앱스토어에 저희가 만든 앱이 올라가는 순간의 뿌듯함은 웹 배포와는 또 다른 차원이었습니다.

Flutter와 Native 코드를 넘나들며 모바일 앱 개발에 큰 진척을 보였고, 저희의 포트폴리오를 한 단계 넓힐 수 있었습니다. 웹에서 쌓아온 UI/UX에 대한 감각과 시스템 설계 경험이 모바일에서도 유효하다는 것을 확인한 한 해였습니다. 2026년에도 더 많은 앱 프로젝트를 진행할 예정이며, 이제 저희는 클라이언트에게 "웹으로 할까요, 앱으로 할까요?"가 아닌 "어떤 플랫폼이 사용자에게 가장 적합할까요?"라고 물을 수 있게 되었습니다.

AI, 또 다른 동료로서

여기서 중요한 점을 짚고 넘어가야 할 것 같습니다.

저희는 개발의 모든 측면에 AI를 적극적으로 사용하고 있습니다. 하지만 '의존'이 아닌 '협업'입니다. 코드 리뷰, 문서 생성, 테스트 개발 등에서 AI는 한 명의 또 다른 동료처럼 작동합니다. ―처음에는 저도 "이거 우리 일자리 없어지는 거 아닌가" 싶었는데, 실제로 함께 일해보니 오히려 더 재미있어졌습니다.

다만 경계해야 할 것도 있습니다. AI가 생성한 코드를 그대로 복사해서 붙여넣는 것, 그것은 협업이 아닙니다. 저희가 AI를 사용하는 방식은 능동적입니다. 질문하고, 검토하고, 수정하고, 때로는 "아니, 이건 좀 아닌 것 같은데?"라고 피드백을 주기도 합니다.

비용도 무시 못해

기존에는 '안정적', '빠른', '거대한' 앞에는 항상 '큰 비용'이 따라왔습니다. 하지만 이는 클라이언트도 저희도 지속 가능하지 못합니다.

AI로 가속화된 온라인 생태계는 초효율을 지향합니다. 저희는 소프트웨어를 가장 효과적으로 돌리기 위한 가격 대비 성능의 최적점을 찾는 데 오랜 연구를 해왔고, 이를 우선시하고 있습니다. 좋은 시스템이 반드시 비싼 시스템일 필요는 없습니다. ―물론 공짜로 좋은 시스템을 만들 수는 없지만, 적어도 불필요하게 비쌀 필요도 없습니다.

변하지 않는 것들

그럼에도 불구하고.

소프트웨어로 클라이언트의 문제를 해결한다는 본질은 변하지 않았습니다. 그리고 그 과정에서 접근 방식을 설계하고, 문제를 정의하고, 아키텍처를 구상하는 것―이것들은 여전히 인간이 해야 하는 일입니다. AI가 코드를 빠르게 생성해준다고 해서 "왜 이 구조여야 하는지"를 이해하지 않아도 되는 것은 아닙니다.

오히려 역설적으로, AI 시대에 진짜 공부의 가치가 더 명확해졌다고 느낍니다. 도구가 강력해질수록 그 도구를 제대로 쓰기 위한 기본기가 중요해지는 것처럼요.

저희는 더 빠르게 발전하고 있고, 더 빠르게 가속하고 있습니다. 하지만 결국 디자인 스튜디오 바톤이 지향하는 하나―사용자의 문제를 아름답고 우아한 방식으로 해결하고, 기술과 디자인, 기획의 균형을 맞춘 엔지니어링 철학―은 계속됩니다.

실제로 바톤에서 하는 개발

앞서 소개한 바와 같이 저희는 프로젝트를 성공시키기 위해 기술이 필요한 모든 것을 합니다.

대부분의 개발 작업은 포트폴리오 상에 직접적으로 드러나지 않습니다. 저희의 가장 큰 역할은 기획과 디자인을 거쳐 완성된 결과물―Figma는 여전히 잘 쓰고 있습니다―을 다양한 디바이스와 실행 환경을 고려하여 섬세하게 구현하는 것입니다. 그리고 이 과정에서 표면에 드러난 기능 뒤의 성능, 관리, 편의성 등 고객사의 특성에 따라 다양한 부분을 만들어 내는데, 이때 신경 쓸 부분과 작업들이 많아집니다. 몇 가지 예를 들어보죠.

• 고객사의 기존 시스템이 어떤 스택이든, SOLID를 기반으로 해당 환경에 최적화된 솔루션을 설계합니다. Next.js가 기본이지만, 상황에 따라 유연하게 대응합니다.
• 규모 있는 쇼핑몰이 Cafe24 플랫폼을 이용한다면 관련 스킨을 개발합니다. Cafe24에서 지원하지 않는 기능을 원한다면 AWS와 같은 별도의 공간에 웹서버를 띄우고 DB―주로 Aurora MySQL―를 연동해 Cafe24용 앱을 제작합니다. 트래픽이 많아지면 오토스케일링을 걸고 Redis 캐시를 태우거나 Lambda를 이용해 이미지를 동적으로 리사이징 하기도 합니다.
• 모바일 앱이 필요하다면 Flutter를 기반으로 iOS와 Android를 동시에 개발하고, 필요한 경우 Native 코드로 깊이 들어갑니다.
• AI를 활용한 자동화 도구, 데이터 분석 대시보드, 내부 운영 시스템 등 3년 전에는 상상하기 어려웠던 것들도 이제는 저희의 구현 대상입니다.

좀 더 실제 케이스를 중심으로 살펴볼까요?

Kiaf SEOUL은 2002년 처음 문을 연 한국 최초의 글로벌 아트페어이며, 바톤은 2020년부터 지금까지 Kiaf SEOUL의 웹사이트를 담당하고 있습니다.

저희는 Kiaf SEOUL 웹사이트에서 이루어지는 모든 과정을 설계하고 구현합니다.

• 수백 개의 갤러리와 연계된 수천 건의 작품을 업로드할 수 있는 신청 플랫폼
• 신청된 정보를 바탕으로 평가하고 승인한 뒤, 동적으로 작성된 공문을 관리, 전송할 수 있는 시스템
• 각 갤러리들의 OVR을 제공하고 이를 관리하기 위한 인터페이스와 시스템
• 행사 시즌에 등록된 모든 아트웍에 대한 글로벌 트래픽을 받아내는 캐싱 시스템

그리고 이 시스템의 상당 부분이 이제 SOLID 기반으로 운영되고 있습니다.

즉, 디자인 포트폴리오 이면에 숨어있는 수많은 어드민 인터페이스와 기능도 저희의 구현 대상입니다.

좋은 동료와 효율적으로 일한다는 것

기획자와 디자이너, 개발자가 같은 프로젝트 안에서 '잘' 일하는 방법에 대한 이야기는 여전히 현재진행형입니다. AI가 등장했다고 해서 이 문제가 해결된 것은 아닙니다. ―오히려 'AI도 팀원이라면 어떻게 협업해야 하나'라는 새로운 질문이 추가되었습니다.

저희는 지난 13년간 각 팀들이 서로 효율적으로 '함께' 일하는 방법에 대해 계속해서 실험하고 개선시켜 왔습니다. 많은 시행착오 끝에 지금은 각 팀의 전문성을 높이면서 병목은 제거하고 역할과 범위를 명확하게 구분해 팀 작업의 집중도를 높이는 나름의 시스템을 정착시켰습니다.

그리고 이러한 시스템 외에 팀 구성도 한몫하고 있습니다. 디자이너 출신 개발자, 개발자 출신 기획자, 코딩 역량을 가진 디자이너 등 바톤에는 다양한 배경의 팀원들이 많습니다. 이런 팀원의 존재는 팀 간의 이해도와 문화 형성에 큰 기여를 하게 됩니다. 당연하게도 많이 알수록 서로를 존중하게 됩니다.

그 밖에도 여러 요소들이 있지만 개발 사이드에서 언급해보자면 단편적으로 개발팀은 개발 과정에서 고객사와 커뮤니케이션하지 않습니다. 전화를 받을 일도, 이메일을 보내거나 미팅을 가는 일도 거의 없습니다. 간혹 어드민 인터페이스를 직접 디자인하는 경우는 있지만, 외부 디자이너가 전달한 (=의도를 확인하기 위해 다시 커뮤니케이션을 해야하는) PC 버전 시안의 태블릿 버전을 상상하며 구현하는 일은 없습니다. 다시 말해 개발 효율을 떨어트리는 일, 개발자가 고객사 담당자를 설득하느라 시간을 보내는 것과 같은 일은 바톤에서 발생하지 않습니다. ―이건 3년 전에도 강조했던 부분인데, 여전히 강조해도 모자랍니다.

당연한 것을 당연하게 잘하는 것, 이것이 지속 가능하려면 구성원 간에 평등하고 존중하는 문화가 반드시 필요합니다. 이 부분에 대해서는 정말 자랑하고 싶은 부분이 많지만, 문장으로 표현하자니 좀 쑥스럽네요. 바톤의 인스타그램과 이어질 내용, 개발팀 TMI를 확인해주시기 바랍니다.

프론트와 백-엔드 개발자 비율?

여전히 채용 면접에서 가장 자주 듣는 질문입니다. 그리고 여전히 답은 같습니다. 저희 개발팀은 풀-스택을 지향합니다.

다만, 3년 전과 달라진 점이 있다면 이제 그 '풀-스택'의 의미가 확장되었다는 것입니다. 단순히 프론트와 백을 모두 다룰 수 있다는 것을 넘어서, AI 도구를 효과적으로 활용할 수 있는 능력, 시스템 전체를 조망하고 설계할 수 있는 관점, 그리고 웹과 모바일을 아우르는 시야까지 포함됩니다.

이게 참.. 풀-스택이라고 하면 뭔가 거창해 보이지만―마치 마검사 같달까요― 저희가 하는 프로젝트는 '네카라쿠배' 규모가 아니어서 특성상 풀-스택을 지향하는 게 맞다고 생각합니다. Node.js 등장 이후로 흐릿해진 프론트와 백의 경계는 이제 거의 의미가 없어졌습니다. Next.js의 Server Components, Edge Functions 같은 것들을 보면 "어디까지가 프론트고 백인지"라는 질문 자체가 구시대의 유물처럼 느껴집니다.

바톤의 개발팀은 각자가 더 좋아하고 잘하는 분야는 있지만 한 명 한 명이 올라운드 플레이어를 지향합니다. 그래야 이슈가 있을 때, 같은 선상에서 같이 고민하며 함께 성장할 수 있다고 믿고, 그를 위해 계속해서 노력하고 있습니다.

실제 개발 프로세스

웹 프로젝트에서 개발 프로세스는 대부분 3단계로 진행됩니다. (물론, 유형과 일정에 따라 일부 생략되거나 추가되기도 합니다.)

Step 1 : 프로젝트의 모든 것, 개발 가이드

• 기획팀으로부터 'OOO 프로젝트 개발 가이드'라는 약 20-30페이지 분량의 구글 프리젠테이션 URL을 공유 받는 것으로 시작합니다.
  

  

• 이 개발 가이드는 말 그대로 개발 매뉴얼입니다. 사전에 요청한 운영서버, 도메인, 써드 파티 앱, 라이브러리, 관련 서비스 계정 등 모든 것이 들어있고 UI디자인팀에서 전달한 Figma URL이 각 디바이스별로 포함되어 있습니다.

• 나머지 페이지에는 각 페이지별로 구현할 때의 특이사항과 주의할 점 등이 작성되어 있고 이것을 리뷰하며 보다 상세한 개발 일정과 계획을 수립합니다.

Step 2 : 코드 작성

• 대다수의 프로젝트들이 초기 기획과정에서 기술 스택을 정합니다. 하지만 점점 내용이 구체화되며, 실제 개발 단계에서는 다른 스택으로 변경될 수 있습니다. 2단계의 시작은 개발 서버를 설정하며 시작합니다.

• 저희는 가급적 새로운 방법과 기술을 지향합니다. 물론, 저희 모두가 모든 것을 다 아는 고오급 개발자는 아닙니다. 하지만 시스템의 안정성을 해치지 않는 범위 내에서 새로운 시도를 하는 것을 즐기며, 더 나은, 더 멋진, 더 편리한 시스템을 만드는 데 주저하지 않으려 노력합니다.

• UI디자인팀이 만든 Figma 프로토타입은 매우 상세합니다. 개발 과정을 고려한 디자인과 사용성에 대한 고민의 흔적이 고스란히 결과물에 담겨있습니다. 저희는 이 이미지와 느낌이 그대로 고객에게 전달될 수 있도록 UI디자인팀과 계속 소통하며 완성해나갑니다.
  

  

• 버전 관리는 Git을 사용하며, 매일 아침 스탠드업 미팅을 통해 하루 작업을 설계하고 공유합니다. 내부 이슈 트래커를 통해 이슈를 등록하고 작업을 진행합니다. 그리고 이제는 AI가 코드 리뷰의 1차 관문을 담당하기도 합니다.

• 개발팀 내의 협업 방식은 계속해서 발전시켜 나가고 있습니다. 지금의 방식이 어느 정도 정착되기는 했지만 충분히 더 개선할 수 있다고 생각하고 꾸준히 시도하는 중입니다.

Step 3 : 가완성본 그리고 배포

• 개발 서버에 가완성본을 올려 내부 공유를 합니다. 기획팀과 UI디자인팀의 내부 검수를 통해 고객사에 공유되며, 이후 QA 과정이 시작됩니다. 이 과정이 사이트의 디테일과 성능을 끌어올립니다.
• QA 종료 후에는 배포에 앞서 부하테스트를 진행하고, 각 프로젝트별 배포 전략에 맞게 배포를 진행합니다.
• 배포 후의 유지관리는 저희가 하는 경우도 있고 외부 다른 업체가 맡는 경우도 있습니다. 대부분은 저희가 진행하지만 신규 개발과 유지보수의 비율은 대략 9:1 정도로 유지보수 업무가 크지는 않습니다.

바톤에서 만든 사이트 수 대비 유지보수 업무가 크지 않은 이유는, 제작 시 대부분 고객사에서 수정이 가능한 형태로 만드는 것을 우선하기 때문입니다. 어떤 면에서는 유지보수 수익이 줄어드는 단점도 있지만, 고객사는 편리해서 좋아하고 저희는 신규 개발에 더 집중할 수 있어 장기적으로 더 효율적입니다.

주로 사용하는 기술

팀 작업에서 주로 사용하는 기술과 이유를 간략하게 소개해보겠습니다.

TypeScript + Next.js

typescript is the new baseline.

3년 전에는 "JavaScript is everywhere"라고 썼는데, 이제는 TypeScript가 기본값이 되었습니다. 타입 안정성이 주는 이점은 특히 AI와 협업할 때 더욱 빛을 발합니다. AI가 생성한 코드의 오류를 빠르게 잡아낼 수 있고, 의도를 명확하게 전달할 수 있거든요.

그리고 저희는 이제 완전히 Next.js를 기반으로 작업합니다. 어떻게 하면 더 효율적이고 빠른 시스템을 만들 수 있을지 늘 시도하고 연구 중입니다. Server Components, App Router, Edge Runtime 등 Next.js가 제공하는 새로운 기능들을 적극적으로 활용하고 있고, SOLID 역시 이 생태계 위에서 만들어졌습니다.

Flutter + Native

2025년부터 본격적으로 모바일 앱 개발에 뛰어들면서 Flutter가 저희의 주요 기술 스택에 추가되었습니다. 크로스 플랫폼의 효율성과 네이티브에 가까운 성능, 그리고 무엇보다 아름다운 UI를 만들 수 있다는 점이 바톤과 잘 맞았습니다.

물론 Flutter만으로 모든 것을 해결할 수는 없습니다. 디바이스의 깊은 기능에 접근해야 할 때는 Swift나 Kotlin으로 Native 코드를 작성하기도 합니다. ―웹에서 프론트와 백을 넘나들었듯이, 모바일에서는 Flutter와 Native를 넘나듭니다.

Cafe24 System

Cafe24 Eco-System은 여전히 중요합니다. 국내 이커머스 솔루션 업계에서 압도적인 점유율을 차지하고 있고, 저희가 작업하는 쇼핑몰의 대부분은 여전히 Cafe24 환경에서 작업됩니다.

Cafe24는 국내 쇼핑몰 솔루션 중에서는 API를 가장 적극적으로 지원하고 있습니다. 그리고 바톤은 Cafe24 커스터마이징으로 제법 알려져 있습니다. 별도의 서버와 DB를 이용해 기본적으로 제공하는 Cafe24 스킨의 한계를 확장해 기능을 구현합니다. SOLID의 Cafe24 모듈은 이러한 경험이 집약된 결과물입니다.

굳이 말하자면 우리는 여전히 사파?

물론 하나의 언어만 사용하는 기업은 없겠습니다만, 적어도 자사 프로덕트가 있는 기업이라면 주가 되는 언어는 있기 마련입니다. ―그것이 CTO의 취향이든 인력 구성의 영향이든― 하지만 저희는 프로젝트 주기가 상대적으로 짧고 포커스는 고객사이기 때문에 특별히 언어에 대한 고집이 없습니다. 쉽게 말해 이길 수 있다면 어떤 무공이든 상관없달까요. 그런 면에서 개발 업계가 무림이라면 '에이전시 디벨로퍼'인 저희는 여전히 정파보다는 사파에 가깝습니다. ―다만 이제는 AI라는 강력한 아이템을 장착하고, 모바일이라는 새로운 전장까지 확보한 사파입니다.

주로 하는 작업들

바톤의 공식 사이트 또는 인스타그램에 가시면 느끼시겠지만 감사하게도 정말 다양한 분야의 고객사가 찾아주셔서 특별히 어떤 분야, 작업을 주로 한다고 이야기하기가 어렵습니다.

하지만, 한 가지 공통점은 디자인에 대한 가치를 중시하고 기민한 고객사들이 주를 이룬다는 것입니다. 웹 사이트를 만들지만 동시에 한 명의 사람으로서 다른 분야의 전문가들에게 많이 배우게 됩니다. 실제로 고객사 관계자 분들이 더 편리하고 효율적으로 일할 수 있는 시스템을 제작하기 위해서는 그분들이 일하는 방식을 이해해야 하고 해당 도메인에 대해 공부해야 합니다. 이 과정에서 발생하는 경험과 인사이트가 저에게는 굉장히 소중하게 다가옵니다.

물론, 모든 작업들이 그런 경험을 가져다 주지는 않습니다. 그리고 실제 업무도 언제나 이상적으로 흘러가지는 않습니다. 하지만 저희는 지금까지 멋진 고객사들과 함께 성장해왔고 앞으로 만나게 될 새로운 분야가 늘 기대됩니다.

AI 시대의 바톤 개발자

앞서 언급했듯이 저희는 풀-스택, 올-라운드 플레이어를 지향합니다. ―여기까지 읽으신 분이라면 저희가 이야기하는 풀-스택이 어떤 의미인지 아시리라 믿습니다!― 그리고 여기에 한 가지가 추가되었습니다. AI와 효과적으로 협업할 수 있는 능력입니다.

다만 오해하지 마세요. "AI 프롬프트를 잘 쓸 수 있다"는 것이 아닙니다.

AI를 제대로 활용하려면 기본기가 탄탄해야 합니다. AI가 생성한 코드가 맞는지 틀린지, 좋은 방향인지 아닌지를 판단하려면 결국 그 분야에 대한 이해가 필요합니다. AI가 제안한 아키텍처가 우리 프로젝트에 적합한지 평가하려면 시스템 설계에 대한 경험이 필요합니다.

그래서 역설적으로, 바톤의 개발자는 AI 시대에 더욱 CSS 전문가여야 하고, JavaScript의 기본 원리를 더 깊이 이해해야 합니다.

웹 개발자의 근간을 논할 때, 가장 저평가되어있는 요소가 CSS라고 했던 말은 여전히 유효합니다. CSS는 경험이 필요합니다. 문법의 구성 원리가 쉬운 만큼 자유롭고 그래서 방대합니다. AI가 CSS를 생성해줄 수 있지만, 그것이 실제로 다양한 브라우저와 디바이스에서 어떻게 동작할지 예측하는 것은 여전히 인간의 몫입니다. 다양한 브라우저와 파편화된 모바일 디바이스, 윈도우와 맥, 같은 모양 다른 구현, "제 컴퓨터에서는 되는데요!?"의 대표적인 언어가 바로 CSS입니다.

사이트의 모양새와 세부 디테일을 결정하는 가장 큰 요소 중 하나가 CSS이며, 이는 전문 영역입니다. 저희 팀은 이런 CSS와 같은 기본기를 우대합니다. JS도 React의 상태관리나 Virtual DOM의 구현원리를 이해하는 것도 물론 중요하지만 JavaScript라는 언어의 기본 문법과 브라우저 API, 비동기 처리, 이벤트 핸들링 등 원칙에 대한 이해가 우선되어야 한다고 생각합니다.

그리고 성장에 대한 동기부여를 스스로 할 줄 알아야 합니다. AI가 많은 것을 대신해주는 시대에, "그럼 나는 뭘 배워야 하지?"라는 질문에 스스로 답할 수 있어야 합니다. 작업을 개인의 성장으로 연결할 수 있어야 합니다. 이것은 매우 중요합니다. 이 부분에 따라서 바톤은 최고의 놀이터가 될 수도 있고, 매 프로젝트가 고통일 수도 있습니다.

그렇다고 바톤의 개발자가 모두 기본기가 출중하고 어마어마한 풀-스택 개발자인가?! 물론 아닙니다. ―저 역시 매일 좌절하고 배우고 노력합니다. AI한테 "그건 아닌 것 같은데?"라고 말하다가 제가 틀린 걸 알게 될 때도 많습니다. 하지만 **성장의 방점을 이렇게 설정하고 나아가고 있다!**고 봐주시면 될 것 같습니다.

실용주의 프로그래머와 성장

저희 팀은 여전히 새로운 멤버가 합류하면 두 권의 책을 권합니다. 한 권은 앤드류 헌트와 데이비드 토마스의 "실용주의 프로그래머(The Pragmatic Programmer)"이고 다른 한 권은 김창준 님의 "함께 자라기 : 애자일로 가는 길"입니다. ―3년 전에도, 지금도, 아마 3년 후에도.

대부분의 경우 **바톤이 하는 일은 결국 '문제를 해결하는 것'**입니다. AI가 코드를 빠르게 생성해주는 시대가 되었지만, 문제를 정의하고, 접근 방법을 설계하고, 결과를 검증하는 것은 여전히 인간의 일입니다. 디자이너와 개발자가 다른 점이 있다면, 우리는 그것을 코드를 통해서 할 뿐입니다.

바톤의 개발팀은 실용주의적 관점에 완벽히 동의하며 빠르게 변화하는 환경에서 유연함을 갖추기 위해 노력합니다. 언제나 효율을 중시하지만 개인의 성장이 곧 팀의 성장임을 인지하고 실전과 훈련을 구분 짓지 않습니다. 성장의 기회를 위해 서로를 배려하고 신뢰할 수 있는 문화를 만들어 갑니다.

그리고 이 모든 것의 종점에는 각자의 행복이 있습니다. 하루 중 가장 많은 시간을 함께 한다는 것은 곧 1년 중 가장 많은 시간을 보내는 것과 같고, 그 시간들을 좋은 사람들과 재밌는 일을 하면서 보내기를 희망합니다. 즐겁게 개발하는 것, 저희 팀에서 가장 중요하게 생각하는 가치입니다. ―AI가 아무리 발전해도 이 부분만큼은 대체할 수 없을 것 같습니다.

Next

이 긴 글을 여기까지 읽어주셔서 감사합니다. 3년 전 글과 비교해보면 달라진 것도 많고, 그대로인 것도 많습니다. 기술은 빠르게 변하지만, 좋은 개발자가 갖춰야 할 덕목은 크게 다르지 않다는 것을 새삼 느낍니다.

2026년 현재, 저희는 채용 계획이 없습니다. 하지만 저희의 개발 문화나 일하는 방식에 관심을 갖고 계시다면 언제든 메일을 보내주세요. 저희는 때때로 외부 개발자들과 협업하기도 하고, 함께 만들어가는 생태계에 큰 관심을 갖고 있습니다. 좋은 인연은 언제나 예상치 못한 곳에서 시작되니까요.

그리고 개발팀 TMI를 통해 사소하게나마 궁금하실 수 있는 저희 팀의 이모저모도 확인해보세요!