기억하기 위한 개발노트

스프링 부트(Spring boot) 마이바티스(Mybatis) 에서 쿼리 로그 출력 및 정렬하기.

26 Dec 2018 | Spring Logback SQL 정렬 SQL pretty MyBatis 마이바티스

(이 내용은 Spring boot의 logback(기본로그설정)을 사용하며 mybatis를 사용한다고 가정한다.)

Spring boot 와 Mybatis를 이용하여 초기 셋팅 후 개발을 하다 보면 쿼리가 나오지 않거나 혹은 쿼리가 나오게 mapper 에 해당하는 패키지의 log를 debug 레벨로 두더라도 쿼리가 한줄로 나오거나 파라미터가 ? 로 따로 찍히는 현상이 발생한다. Spring data jpa 를 사용하면 아래 간단한 옵션으로 정렬된 SQL 구문을 볼 수 있으나 Mybatis 사용시엔 그렇지 않다.

spring boot data jpa 사용 시 쿼리 정렬 옵션

spring.jpa.properties.hibernate.format_sql=true

정렬 처리가 되어있지 않을 경우 개발하면서 불편한게 한두가지가 아니다. 아래 내용을 적용하면 쿼리를 보기좋게 하여 좀 더 생산성을 높일 수 있다.

1. pom.xml 에 다음 라이브러리 추가.


<!-- mybatis sql pretty -->
<dependency>
    <groupId>org.bgee.log4jdbc-log4j2</groupId>
    <artifactId>log4jdbc-log4j2-jdbc4.1</artifactId>
    <version>1.16</version>
</dependency>

2. application.yml에서 기존 사용하던 driver 및 url 정보 변경. (주석 참고)

spring:
  datasource:
    #url: jdbc:mysql://localhost:3306/sample  ## 1. 기존 사용하던 jdbc:mysql 로 시작하는 url 주석처리 후 jdbc:log4jdbc:mysql 로 시작하는 url 로 변경.
    url: jdbc:log4jdbc:mysql://localhost:3306/sample
    username: jmlim
    password: 123456
    #driver-class-name: com.mysql.jdbc.Driver ## 2. 기존 사용하던 com.mysql.jdbc.Driver를 net.sf.log4jdbc.sql.jdbcapi.DriverSpy 로 변경.
    driver-class-name: net.sf.log4jdbc.sql.jdbcapi.DriverSpy
    hikari:
      connection-timeout: 5000
      validation-timeout: 1000
      maximum-pool-size: 30
      minimum-idle: 2
      connection-test-query: SELECT 1

3. application.yml 에서 jdbc.sqlonly 패키지에 대한 로깅 레벨 추가. (주석 참고)


logging:
  level:
    jdbc.sqlonly: DEBUG ## 이부분 추가.
    org.springframework.web: DEBUG
    com.zaxxer.hikari.HikariDataSource: ERROR

참고로 log4jdbc는 아래와 같은 옵션들을 제공한다.

 1. jdbc.sqlonly : SQL문 만을 로그로 남기며, PreparedStatement일 경우 관련된 argument 값으로 대체된 SQL문이 보여진다.
 2. jdbc.sqltiming : SQL문과 해당 SQL을 실행시키는데 수행된 시간 정보(milliseconds)를 포함한다. 
 3. jdbc.audit : ResultSet을 제외한 모든 JDBC 호출 정보를 로그로 남긴다. 많은 양의 로그가 생성되므로 특별히 JDBC 문제를 추적해야 할 필요가 있는 경우를 제외하고는 사용을 권장하지 않는다. 
 4. jdbc.resultset : ResultSet을 포함한 모든 JDBC 호출 정보를 로그로 남기므로 매우 방대한 양의 로그가 생성된다. 
 5. jdbc.resultsettable : SQL 결과 조회된 데이터의 table을 로그로 남긴다.

각옵션들의 기능을 정확히 알기 위해서는 직접 하나씩 변경해 보며 구동하는 것이 좋을 것이다.

4. resources 경로 밑에 log4jdbc.log4j2.properties 파일 추가.


log4jdbc.spylogdelegator.name=net.sf.log4jdbc.log.slf4j.Slf4jSpyLogDelegator
log4jdbc.dump.sql.maxlinelength=0

5. 출력결과


2018-12-26 18:31:57.381 [pool-2-thread-1] DEBUG jdbc.sqlonly [223] - com.zaxxer.hikari.pool.ProxyPreparedStatement.execute(ProxyPreparedStatement.java:44)
1. /* [TEST] io.jmlim.sample.mapper.SampleMapper#selectSampleList */
  SELECT CODE
       , NAME
       , START_DATE
       , END_DATE
       , GRADE_TYPE
       , GRADE_VALUE
    FROM JM_SAMPLE
   WHERE USE_FLAG = 'Y'
     AND CODE = 'JM00001'

참고자료

  • https://www.leafcats.com/45
  • https://modunote.tistory.com/143

[마소콘 2018] 기술부채의 늪 탈출기 - 개발문화의 완성 강연 내용 후기.

25 Dec 2018 | MASOCON 마소콘 기술부채 데브옵스 개발문화

이번 후기는 좀 늦었지만.. 일단 정리한 내용이기에 글로 적어본다. 다음 강연은 럭스로보의 데브옵스 방법에 대해 소개하는 강연이었다.

강연내용 정리

현재 강연자분은 럭스로보에서 데브옵스 역할을 하고 있음.

럭스로보는?

  • 교육용 소프트웨어 납품. 아이들이 코딩을 쉽게 배울 수 있도록 도와주는 회사.

데브옵스란 무엇인가?

  • 개발, QA, 운영 의 교집합.

처음 회사에 들어왔을 때 문제점.

  • 레거시 코드
  • 이슈관리
  • 코드리뷰 X

하나하나 해결해나가기 시작.

1. 지라(Jira), 컨플루언스(confluence) 도입..

  • 칸반(Kanban) 방법론을 택함..
  • 매주 컨퍼런스 콜 - 이슈를 누구한테 할당을 할 것인지.
  • 데일리 스탠드업 미팅 - 의사소통 : 슬랙. - 매일아침 할일을 공유.
    • 어제한일.
    • 오늘할일.
    • 불편한점.
  • 버전기반으로 스켸줄링.
  • VOC 가 있을 때 Jira에 작성.

2. 깃랩(gitlab) 사용.

  • 깃 플로우 (자세한 내용은 링크 참조 : http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html)
    • hotfiex 브랜치 : 버그픽스. 버그 단위로 여러개가 따임.
    • feature 브랜치 : 버그 제외 모든 이슈. 기능단위로 여러개가 따임.
    • release 브랜치 : 릴리즈 할 기능이 모아져있는 브랜치.
    • master 브랜치 : 운영 브랜치.
    • develop 브랜치 : 개발 브랜치.
  • master, develop는 gitlab은 MR을 거치지 않으면(코드리뷰를 거치지 않으면) 들어갈 수 없음. (github의 PR)
  • 번개표시를 달면 코드리뷰 받은대로 처리했다라는 답변과 같음. (LGTM emoji)
    • 어떻게 보면 하나의 재미 요소.
  • 코드리뷰어는 자질구레 한 것들에 집중하는걸 피해야함.
    • 코드리뷰는 코드를 전체적으로 보고 더 큰 체계에 들어맞는지 보는 것.
    • 사소한 코드에 초점을 맞춰서는 안됨.

3. Jenkins

  • 빌드 자동화.
    • Jenkinsfile : groovy 언어로 작성. (스크립트 대로 빌드 되고 배포됨.)
  • 젠킨스 쓰는 이유 : 자동배포.
    • 푸시 이벤트
    • 머지 리퀘스트
    • 코멘트
  • 젠킨스가 처음에 다 확인을 하고 머지까지 해주도록 함. 파이프라인이 깨지면 아예 코드리뷰로 넘어가지 않음.
  • 빌드가 되면 알림이 감. (테스터, 담당자.)
  • 클라우드 프론트에서 캐시 무효화 까지 함.
  • 젠킨스가 각 단계별로 파악을 해줌. (어디서 에러가 났는지 등등.)

관리자의 역할은??

  • 개발자가 코드만 편하게 작성할 수 있도록 돕는 것.

느낀점

  • 이전 devops의 강의가 협업의 중요성을 강조했다면 이번 강의는 구체적인 방법에 대한 말씀을 해 주셨다.
    강연자분께서 콘퍼런스 마지막에 들어오셔서 지루할 수 도 있는 시간이었는데 설명을 잘 해주셔서 지루하지 않았다. 스타트업이나 작은 규모의 회사에서 처음 프로세스를 잡을 때 위 내용 그대로 진행해도 좋을것 같다라는 생각이 들었다.

관련자료

  • https://www.imaso.co.kr/archives/4481
  • http://it.chosun.com/site/data/html_dir/2018/12/15/2018121500979.html

[마소콘 2018] 더 웨더 컴퍼니의 데브옵스 강연내용 후기.

20 Dec 2018 | MASOCON 마소콘 더 웨더 컴퍼니 데브옵스 DevOps 사일로

다음 강연은 IBM 에서 인수한 미국 최대의 날씨 회사인 더 웨더 컴퍼니의 데브옵스 문화에 대해 소개하는 강연이었다.

강연내용 정리

더 웨더 컴퍼니에 대한 소개

  1. 일단 스타트업은 아님. 미주지역의 방송국. 82년도의 시작됨 더 웨더 채널.
  2. IBM 이 인수 (IT 분야만)
  3. 세계에서 가장 정확한 기상예보를 냄.
  4. 좁은 지역 단위로 날씨예보를 냄. API 도 제공함.
  5. 넘버 원.
  6. 한국 마켓에서는 그렇지 않지만 글로벌 업체중에 탑.
  7. 시간별 예보(15분마다 갱신), 10일 예보, 월별 예보.
  8. 다양한 이미지 레이어. (지도상에서 레이어 정보를 선택하여 변화되는 부분을 확인할 수 있음.)
  9. 특색있는 정보 (알러지 수치정보, 감기 발생정보)
  10. API 레벨에서 보면 교통정보, 번개정보도 알 수 있다.

트래픽 규모가 엄청나다. (하루에 억단위의 요청이 있음..)

데브옵스란?

  1. 개발 방법론으로 보긴 어려움.
  2. 개발 라이프 사이클을 단축시키는게 목적. 더 빨리, 더 자주 업데이트를 할 수 있게 하는것.
  3. 빨리, 그리고 더 자주 고객들을 위한 서비스 업데이트.
  4. 비즈니스 목표와 연관 되어야함.

CAMS 소개 (데브옵스를 바라보는 관점)

  1. Culture
  2. Automation
  3. Measurement
  4. Sharing

사실 오토메이션에 관한 내용 말고 어떻게 액션을 해야할지가 모호함.

1. Culture(문화)

  1. 문화가 가장 중요!!
  2. 사일로의 해체가 필요하다.
    • 사일로란?
      • 곡식 및 사료를 저장해 두는 굴뚝 모양의 창고.
      • 조직내 다양한 부서들이 서로 다른 부서와는 마치 담을 쌓은 것처럼 교류하지 않고 자기 부서의 내부적인 이익만을 추구하는 현상.
      • 참고자료 : http://politicstory.tistory.com/1436
    • 운영을 하는 조직, 개발하는 조직, 테스트 하는 조직이 나누어지면서 커뮤니케이션이 단절되는 문제 발생..
  3. 리더십의 지원
    • 사일로의 해체를 위해 필요하다.
  4. 비즈니스 목표가 공통된 목표
    • 사일로의 해체를 위해 필요하다.
  5. 조직의 구조

2. Automation (자동화)

  1. 인프라에서 서비스까지 모든 것을 자동화한다.
  2. 라이프 사이클의 각 단계를 파이프 라인화
  3. 실수를 최소화
  4. 다양한 도구의 활용이 필요.
  5. 하지만 자동화가 데브옵스의 전부가 아니다.

3. Measurement (측정)

  1. 시스템 모니터링.
  2. 시스템 로그.
  3. 사용자의 피드백.
  4. 라이프 사이클 추가.

4. Sharing (공유)

  1. 지식과 경험의 공유.
  2. 자유로운 접근.
  3. 사일로 탈피.
    • 조직과의 벽을 허무는 것
  4. 리더십의 지원.

더 웨더 컴퍼니의 데브옵스.

더 웨더 컴퍼니의 릴리즈 주기.

  • 애자일 방식으로 개발 수행
    • 스프런트 ,스크럼 ,코드리뷰,
    • 일반적으로 2주 +- 단위로 릴리즈 수행
      • 신규 api 와 같은 경우는 개발기간이 길어질 수 있으므로 충분한 품질 점검 과정을 거쳐 릴리즈 수행.
      • 개발팀 단위로 업무시간 내에 다운타임 없이 릴리즈 수행.
      • SI 프로젝트와 차이가 많이 나는 부분.. 보통 SI 프로젝트는 한달의 한번씩 밤새면서 시스템 셧 다운 시키고 릴리즈해서 난리를 치면서 배포.
  • 오토스케일링 자동화

더 웨더 컴퍼니의 Culture(문화)

  1. 데브옵스 엔지니어 : 현재 수행하고 있는 역할의 이름(직무)
  2. 현재 수행 업무 내용은 Ops 쪽에 가까움.
    • SI 프로젝트의 사일로 화 된 조직구성과 다르다.
    • 개발자, QA, DevOps 엔지니어들이 전부 수정내용이 공유가 된다.
    • 매우 액티브하게 운영환경에 반영하고 있다.
  3. SI 팀구성과 비교.. 팀을 쪼개고 그들의 대표만 미팅을 하며 그들만의 리그가 존재한다.
    • 커뮤니케이션 비용을 높이고 서로간의 이해를 하는데 쉽지 않다.
  4. SLACK 이 큰 역할을 하고 있음. 모든 팀의 구성원들이 스랙채널에 참여해서 같이 공유를 함.
    • 커뮤니케이션 비용이 많이 줄어들음.
    • 히스토리가 다 나와 있음. (1년전 2년전에 있던일도 검색이 가능.)
  5. 리더십.
    • silo 간에 벽을 허무는데 있어 중요한 역할자가 되어야함.
    • 개발팀관 또는 다른 조직간의 협업을 지원한다.
    • 적은 부담으로 릴리즈를 수행할 수 있어야한다.
    • 릴리즈의 주기를 짧게 할 수 있다.
    • 필요한 변경사항을 빠르게 릴리즈 할 수 있다.

더 웨더 컴퍼니의 Automation (자동화)

  1. 자동화의 범위에 대하여 생각.
  2. 테라폼
  3. Chef
  4. 도커와 쿠버네티스 도입 시 테라폼이나 Chef 의 역할이 줄어듬.

더 웨더 컴퍼니의 Measurement (측정)

  1. 릴리즈 소요시간
  2. 시스템 퍼포만스
  3. 에러율
    • 4xx , 5xx
  4. 모니터링 : 데이터도그(Datadog)
  5. 알림 : 페이져듀티(pagerduty).

더 웨더 컴퍼니의 Sharing (공유)

  • 슬랙으로 공유함.
    • 메신저.
    • 화상 회의.
    • 자료공유
    • 히스토리
    • 주제별 채널.
    • 데이터도그와 페이져 듀티의 슬랙연동.

데브옵스를 하고싶은데 혼자 하기 힘들경우엔?

  • IBM Cloud Garage Method 소개
    • 실제 고객에게 뭐가 중요한지에 대해서 고민을 하여 아이템을 개발하기 위한 아이디어를 창출하기 위한 방법론.
    • 조직이 빠르게 릴리즈를 하기 위한 방법.
    • 애자일 방법론.

마지막으로..

  • 어떻게 더 빠르고 더 자주 그리고 안정적으로 고객에게 딜리버리 할 것인가?
  • 어떻게 더 잘 협업할 것인가?
  • 어떻게 더 잘 커뮤니케이션 할 것인가?
  • 어떻게 더 잘 공유할 것인가?

를 고민해야 한다.

결국엔 … 구체적으로 잘 풀어 갈 것인가 잘 커뮤니케이션 할 것인가를 다시 질문 할 수 밖에 없다. 그러면서 “개선포인트를 찾고 데브옵스로 나아가자” 라고 마무리 하셨다.

질문 1)

  • 사일로 탈피하는 방법에 대해… 회사에서 파트가 많이 있음. 기획, 마케팅, 개발, 그안에서 개발도 쓰리디, 웹, 서버 등 이렇게 나눠져 있는 회사일 경우 파악해야 할 분량이 많을거 같은데 이거에 대한 해결책은?

답

  1. 상대가 연애 상대라고 생각한다면?
    • 무조건 많이 만나라고 조언.
  2. 누구 한명이라도 더 자주 얘기하고 커피라도 마시고 행동을 해야한다.
    • 누군가를 엮어서 같이 행동하는것도 좋은 방법.
    • 결국엔 많이 만나야함….

질문 2)

  • 그렇다면 위의 이유로 사람을 많이 만나게 될 때 그에 따른 스트레스 관리 방법

답

  • 퇴근하고 맘이 맞는 사람들을 만나서 스트레스를 풀자.

느낀점.

데브옵스 하면 떠올랐던 것이 CI, 도커, 자동화, 모니터링 같은 것들이었는데 강연자 분께서 그런 기술적인 얘기보단 그걸 하기 위한 문화와 조직, 그리고 커뮤니케이션에 대한 얘기를 많이 해주셨다.
아무리 뛰어난 툴도 협업의 위에 있을 때 실질적으로 데브옵스가 지향하는 방향으로 동작한다는 점을 설명하신 것이 매우 인상깊었다.

관련자료

  • https://www.imaso.co.kr/archives/4481
  • http://it.chosun.com/site/data/html_dir/2018/12/15/2018121501054.html

[마소콘 2018] SW품질 프로세스로 보는 SI프로젝트 기술부채 강연내용 후기.

19 Dec 2018 | MASOCON 마소콘 기술부채 SI 프로젝트 지옥의 피라미드 갑질

지금 다니고 있는 회사 이전에 다녔던 회사가 통신사 관련 SI 를 하는 회사였고 마지막 프로젝트가 꽤 규모가 있었던거라 이번 파트에 대해선 많은 공감을 하면서 들었다. 허나 강연하신 기술사님이 말씀한 핵심 내용들은 분명 SI 업체에서 일하고 있는 임직원들은 이미 인지한 것이라고 생각한다.

강연내용 정리

SI 란??

나무위키에 자세한 설명이 나와있다..

  • https://namu.wiki/w/SI

System Integration(시스템 구축)의 약자. 전산시스템을 필요로 하는 곳으로부터 하청을 받아, 시스템의 기획, 개발, 유지보수, 운영 등을 대신 해주는 업종이다. 아무래도 개인보다는 기업이나 관공서가 주된 고객이다. 고객의 요청에 따라 제안서를 작성하고, PM과 개발자를 투입하여 프로젝트를 수행한 뒤, 소요된 인건비와 솔루션의 단가 등을 수임료로 벌어들이는 형태의 산업이다. 따라서 도급 시스템과 파견 업무를 그 특성으로 한다.

SI 산업은 갑(甲)인 고객이 자신들이 필요로 하는 시스템을 발주하고, 을(乙)인 개발업체가 사업을 수주하여 개발을 진행하는 구조다. 그러나 이것이 갑과 을로만 끝나는 단순한 관계라면 그나마 문제가 덜하겠지만, 갑으로부터 사업을 따낸 을이 영업에만 관여하고 구체적인 개발은 병(丙)에게 맡기고, 심지어 병(丙) 조차도 여건상 스스로는 사업을 감당하지 못해 다시 정(丁)에게 일을 넘기고… 이렇게 해서 단순한 갑을관계가 아니라 갑을병정무… 이런 복잡한 구조가 만들어 지는 것이 많다. 즉 주인과 노예의 피라미드가 구성되면서 진정한 헬게이트를 연다는 게 이 망할 업종의 문제인 것이다.

암튼.. 이와 같은 현실로 인해… 많은 프로젝트들이 개발 중 또는 그 이후에 엄청난 기술부채가 쌓인다.

SI 프로젝트 특성 상 분석설계 할 시간이 없음.. 시간에 쫒김.

  1. 분석하고 설계하고 고민하고 그 상태에서 다음 시스템을 생각해야 하나 그럴시간 없음..
  2. SI 프로젝트는 대부분 시간을 주지 않음.
  3. 개발하면서 계속 바뀌므로…

ex) 성능테스트 할때

  • 로드런너, 제이미터
  • 하지만 그거에 맞춰서 비즈니스 로직까지 바꿈… 그걸 설계단계까지 바꾸자고함…그럼 분석설계를 다시하자는건데??

SI 일의 구조는?

만약 100억 이상의 프로젝트를 할 경우… (겪어본 바론 진짜 거의 놀라울 정도로 비슷했다..)

  1. 커다란 파이의 분할..
  2. 모든것을 대화하며 풀기에는 시간이 부족하다. 말을 하면서 할 시간이 없음.
  3. 최근엔 PMD나 시큐어프로그램 돌려서 철수하기 직전에 고치게 함.
  4. 나갈때 코드를 작성하지 않는 개발자도 있었음 .. 처음에 그 개발자한테 욕을 함.. 하지만 나중에 알게됨. 설계가 없어서 결과물이 나오지 않은 것.
  5. 기술부채가 엄청나게 쌓인채로 개발자한테 넘어옴.
  6. QA는 막판에 들어와서 개발을 잘합시다~! 설계를 잘합시다~! 잔소리..
  7. ……..총체적 난국…………..

기술부채가 초래한 결과

  1. 개발단계에서 시작되는 AS-IS 분석.
    • 이 문구를 보고 이전에 했던 프로젝트에서 분석 설계 시 제대로 된 메뉴얼도 없어 결국엔 소스를 깐 경우가 생각났다..
    • 자바 개발자 잔뜩 뽑아놓고 C++ 이나 플랙스로 된 소스 다 까서 분석하는 경우였다.. 이 부분에서 꽤 큰 기술부채가 쌓였다.
  2. 개발단계에서 시작되는 TO-BE 설계. (ㄷㄷㄷ 오픈직전에도 그랬다.)
  3. AS-IS 소스 재활용. (ㄷㄷㄷㄷㄷㄷㄷㅋㅋㅋㅋㅋㅋ)

SI 쪽은 그래서…

  • 너희들은 절대 SI 하지마라.

그럼 어떻게 해야하나?

  1. Agile 방법론 vs 기존 방법론&SLDC 에 대한 고민.
  2. 산출물의 의미 : 무언가를 이해하고 그려내고 써 내려가는 과정에서의 고민의 결과.
    • 보여주기식 문서가 되면 안됨.
    • 개발하기 전 그림으로 그릴 수 있어야 함.
  3. 되도록이면 요구사항이 제대로 정의가 되어 있어야함.
  4. 건설쪽은 철저하게 옵션계약을 해서 돈을 더 받아냄 : 계약변경을 계속 할 때마다…
  5. 하지만 IT는 그런거 없다. 이런 부분을 자주 얘기를 해서 해결하여야 할 것이다.

기술부채를 제거하기 위해 분석단계에서 해야할 일.

  1. 요구명세.. 같이 읽어보고 고민하자.
  2. 뭔가 부족한건 없는지 체크하고 같이 얘기하는 시간을 가져보다.
  3. agile은 데일리미팅으로 계속 공유를 하자. agile 을 하자는게 아니고 많이 대화를 하여 어려움을 풀어보자.
    • 현재는 많은 프로젝트들이 PL들만 회의에 참석 한다. 밑으로 제대로 내용 전달이 되지 않는다..
  4. 모든개발자가 참석할 수 있는 회의실을 잡고 대화를 많이 했으면 좋겠다.

설계단계에서 해야할 일.

  • 설계는 설계답게. 고객과의 대화에서 정립한 것을 구체적으로 제대로 설계한다.

개발단계에서 해야할 일.

  1. 개발 : 진척률 기반 관리의 맹점 확인.
  2. 테스트 : 최대한 고객이 적극참여, 검증데이터의 사전준비.
  3. 결함관리 : 결함조치 및 확인 프로세스. 테스트를 통한 재 검증.

결론

  1. 모든사람이 하나의 일원으로 같이해야 잘 끝난다.
  2. 위와같이만 되도 기술부채는 많이 없어질 것이다.

질문

  • 시간이 부족 할 경우 분석설계를 어떤식으로 해야하나?

답변

  1. 설계 수준에 대한 난이도를 둬서 우선순위를 둠. (EX : 인터페이스 부분에 대한 것은 우선순위가 높다.)
  2. 중요하지 않거나 쉬운 부분에 대해선 설계를 하지 않고 개발단계에서 설계
  3. 그럴경우 개발하는 사람들 수준에 맞게 설계를 시킴.
    • 중급 초급: 조회성 단위 화면에 대한 설계를 시킴, 고급 : 어려운것 설계

느낀점

사실 내용 자체는 엄청나게 공감하면서 들었다.
SI 프로젝트를 하면서 많은 생각이 들었던 부분은 고생할게 아닌일을 상당히 수고롭게 일을 한다는 것이었다.
강연하신 기술사님이 말씀하신대로만 진행된다면 많은 SI 프로젝트들이 많은 개선이 될 거라 생각한다.
하지만 사실 명확한 설계가 나오지 않는것은 고객도 사실 뭘 원하는지 모른다는 것이기 때문인 것 같다.
뭔가 개발된 것이 우선 보여져야 생각이 나온다 해야하나 … 사실 그건 PM 이나 개발자들도 마찬가지었었던 걸로..
그리고 제일 문제는 말도 안되는 기간.. SI 업체들의 수익은 얼마나 짧은 시간내에 얼마나 비용을 줄여서 프로젝트를 종료하고 남기는 것이냐로 결정되기 때문에 이런 문제가 나올수 밖에 없을 것 같다는 것이다..

그래도 비록 개발자들이 주로 참석한 컨퍼런스지만 이렇게 문제점들에 대하여 언급해 주신다는 것이 매우 감사한 느낌을 받았다.

그리고… 가능하면 SI는 안하고 싶다..

관련자료

  • https://www.imaso.co.kr/archives/4481
  • http://it.chosun.com/site/data/html_dir/2018/12/15/2018121501019.html

[마소콘 2018] 빚을 탕감하기 위해 없애야 할 3가지(서버, 융통성, 그리고..) 강연내용 후기.

18 Dec 2018 | MASOCON 마소콘 기술부채 Serverless 융통성 Surprise

다음 강연은 빚을 탕감하기 위해 없애야 할 3가지 방안을 소개하였다.

여기서 빚을 탕감하기위해 없애야 할 3가지란..?

  1. 서버.
  2. 융통성..
  3. 그리고…

실제 코스모체인 기반의 파일럿 서비스를 짧은 시간내에 개발, 운영하면서 생긴 기술부채를 어떻게 갚아 나갔는지에 대한 내용이었다.

다음은 없애야 할 3가지에 대한 설명 및 이유이다.

1. 서버

Serverless로 개발한 이유.

  • 기획이 구체적이지 않고 기획이 짧을땐 간단한게 좋다라고 판단.

Serverless를 통해 기술부채를 감소한 부분.

  1. Serverless : 클라우드 서비스(AWS) 사용. 매니징할 서버가 없다는 의미.
  2. 클라우드 프론트, API Gateway, Lambda, DynamoDB 를 주로 사용하여 개발. (EC2 사용안함. 로드밸런싱 등등 따로 설정 필요 X. )
  3. 빚은 애초에 덜 지는게 좋다고 생각. 우리는 언제? 급할 때 진다. 기술부채라고 다르지 않음.
  4. Serverless 일 경우 스팩변경 부담 감소.
    • 의존성 관리 생각보다 큰일 (패키지 버전업.. 모듈 업데이트 마다 연관된 패키지가 많음. 큰 패치라도 있으면 큰 맘먹고 하는일이 되어버림.)
    • 람다 기반의 서버리스 펑셔널 기반의 구조: input/output 명확.
  5. 각 Function은 독립된 프로세스로 동작 (기존 동작을 보장한다.)
  6. 연관된 모든 모듈의 개발 및 테스트가 완료될 때 까지 기다리지 않고 순차적으로 적용 가능.
  7. 간편한 배포 : 오류가 많았으나… 배포가 간단하여서 빨리 해결하고 배포 하는데 무리가 없었음. 무중단 배포는 덤.
  8. 적재적소로 최적의 spec 구성가능. Spec 변경의 부담 감소.
  9. 오토스케일링.

위 장점을 공유하며 빠른 피드백을 요구하는 서비스엔 Serverless 라고 강조하였다.

2. 융통성

서비스 개발이나 일정에 융통성, 예외 사항을 두지 않기.

EX ) 우리는 왜 빚을 질까

  • 갚을능력되면 빚을 짐.
  • 시장 선점.
  • 비즈니스 성장.
  • 일단 동작하게 만듬.
  • 당장 App 사용에 문제가 있으니 융통성을 발휘하여 error 부터 막음.

그러나 빚쟁이한텐 자비가 없고 기술부채도 마찬가지이다.

Twil 소개 (This week I Learned) : 한 주간 개발자가 공부한 내용을 공유하는 자리.

  1. 데일리 미팅 후 5~15분
  2. 기술블로그 발행 ( engineering.huiseoul.com)
  3. 많이 모인김에 컨퍼런스도 열어봄
  4. 특징 : 노 융통성! -> 서비스 오픈날에도 함.

Twil을 하면서 사람들은 뭘 공부할까 궁금하여 통계를 내봄.

  1. 기본적으로 궁금한것들을 공부 함.
  2. 5월에 Lambda에 빠짐. 람다 기본개볌 핸들러 로컬테스트
    • 람다와 관련한 프레임워크 apex, aped up…
  3. 잘하고 싶은것 공부 (찜찜한것)
    • 반영한지 오래되서 다시보고 싶은 코드 구조.
    • 기능 추가/개선이 까다로운 코드 구조.
    • 똥이되는것.
  4. 자산으로 남기고 싶은것
    • 시행착오
    • 구글에 안나오는것.

제품과 직접적인 관련 있는것들이 77%
결국엔 개발자들의 업무 능력 향상으로 기술 부채 상환이 이루어짐.

마지막으로..

3. Surprise

  • Surprise는 놀라게 하다. 경악하게 하다의 뜻…

개발자가 많이하는 Surprise.

  1. 로컬에 몰래 따놓은 브랜치. 고독한 실험. 예고없이 올라온 PR
  2. 프로젝트 방향성과 조금 다른 개발
    • ex) 기획에 없는 개발…
  3. 최최최최신기술, 핫핫핫핫한기술
    • 검증 불가.

Surprise 시엔 미리 동료들에게 공유 할 것을 요청하였다.

갑툭튀 노노…

번외로 팀으로 일해서 좋은 이유를 설명하였다.

  1. 내 프로그램 X : 책임이 분담되고 혼자서는 못 이뤄낼 결과물이며 동료의 재능을 이용 할 수 있다는 점. 생각지 못한 아이디어를 줄 것이라고 하였다.
  2. 혼자서 다 하지 않아도 됨. -> 규모가 크거나 팀에 필요한 일이라면 분담하게 될 것.

결론 : 빚도 자산이다.
갚아나가는 과정에서 기술 노하우도 쌓고 팀원들하고도 가까워질 수도 있다~!

Q & A

  1. 팀웤다지는방법?
    • 데일리미팅 (10시 정각에 만남, 컨디션, 오늘 무슨일했는지, 내일 무슨일했는지.. 실제는 목소리를 듣는것이 목적.)
    • 리뷰 (깃랩사용. 껄그러운 일이 없도록 치열하게 리뷰를 함. 하지만 나쁜소리만 할 수는 없으니 칭찬도 곁들인다.)
  2. 서버리스 불편한점.. 문제점.?
    • 불편한점은 러닝코스트 필요.. 컴퓨팅을 대신해주는걸 지는 대신에 AWS 계속 알아야 하는 단점.
    • 생태계가 많이 올라오지 않음. 레퍼런스
  3. 람다쓰시면서 마이크로서비스를 올리면.. 비용차이면에선?
    • 람다가 차지하는 비율이 전체에서 20%밖에 안듬. 하지만 서비스에 따라 다르므로 검토가 필요.

느낀점

강연자분이 매우 명확한 3가지의 방법을 제시해주었다.
실제로 기술공유에 대한 부분이나 갑툭튀 개발을 하는 경우에 대한 부분에 대하여 많은 공감을 하였다. 서버리스에 대한 부분은 들으면서 .. “아 저렇게도 할 수 있겠구나.” 라는 생각이 들어 서비스가 그렇게 크지 않을 경우 시도해 볼만 하다는 생각이 들었다.
(다른것 보다 부하에 대해 신경을 조금 덜 써도 된다는 기대가 좀 들긴했다., 최근에 맡은 서비스가 종종 트래픽이 몰려오는 서비스라..)
일단 공부차원에서 먼저 저 구성에 대하여 찾아봐야겠다. (사실 클라우드 프론트랑.. 람다만 조금 써봤다..)

관련자료

  • https://www.imaso.co.kr/archives/4481
  • http://it.chosun.com/site/data/html_dir/2018/12/15/2018121500760.html